There were a whole bunch of suspicious things. I'll mention the most obvious.
1. Table A had summary data that was used for reports. Table B had trade detail data, which nobody normally looked at, but we were using it for a special project. There was a discrepancy between the two, and I was investigating. I was concerned that someone had edited Table A. I mentioned to a manager Y "I couldn't reconcile the difference between the two tables. Maybe we should file a Suspicious Activity Report?" A couple weeks later I followed up with Y. I asked what happened. He said "I asked S to look into it. S said that he met with FSK and pointed out the error in his calculation." But S never met with me! Why did S tell Y that he discussed the problem with me, but he never actually did it?!
That's a common social engineering trick. You tell two people two different things, and they usually won't compare notes.
2. For a couple of weeks, I shared an office with S. We were in the risk reporting group. Almost every day, S had a conversation with X on the production team. S spoke in a whispered angry voice, in a language other than English! (I never could figure out which one.) That was really weird, because S was from Russia and X was from China. If it was an "official" daily meeting, there would have been several people on the call, due to the nature of the bureaucracy. I was wondering if S and X were conspiring to forge records, and the phone call was them coordinating their efforts.
3. Table C had daily end-of-day positions. Table D had a list of all the trades. However, if you took Wednesday's end-of-day positions, and added all the new trades and subtracted the stuff that settled, the result was not Thursday's end-of-day position! I thought this was nuts, but S had all sorts of excuses for why this was necessary and desirable. For example, he said that some trades were reported after the end-of-day cutoff, but then shouldn't those trades show up in the table with a later timestamp?
If I was designing a system to facilitate funny business, I would make sure there were all sorts of weird bugs. Then, if I ever got caught, I could pass it off as a bug.
But S was the business' hero! He had singlehandedly written all their key software! He was Untouchable and a Valuable Employee! Of course, I was wondering if he intentionally put abusable Easter Eggs into their system (and maybe some other people were helping him).
When you buy and sell stock/bonds, it's just a number in a database. But if someone has DBA/root, and they're clever about covering their tracks, and a group of people are working together, they can never get caught!
Another weird thing is that I added up all the shares bought in one day per stock and added up all the shares sold in one day per stock, and compared them. Those two numbers should be the same, but they almost never were! I was wondering why nobody added such an obvious checksum to the system. I also added up the number of long failure-to-delivers and added up the number of short failure-to-delivers, and those numbers didn't match either! (A short failure-to-deliver is when someone naked short sells and doesn't deliver stock on the settlement date. A long failure-to-deliver is when someone should have received stock on the settlement date, but didn't, because someone else failed to deliver.)
A regular H1-b visa employee from Russia or China just earns a salary. If there are some people planted by the Russian or Chinese government, they get their salary, plus whatever they can steal, plus whatever their backers are paying them. So these bottom-of-the barrel wages paid to H1-b visa employees are most attractive to someone who's doing something dishonest. Also, if even one person slips through the cracks, then he'll be recommending his associates for jobs, and some of them will inevitably get hired (and eventually promoted). These people don't want the system to completely crash; they want it to appear to run smoothly while they quietly sabotage it.
1. Table A had summary data that was used for reports. Table B had trade detail data, which nobody normally looked at, but we were using it for a special project. There was a discrepancy between the two, and I was investigating. I was concerned that someone had edited Table A. I mentioned to a manager Y "I couldn't reconcile the difference between the two tables. Maybe we should file a Suspicious Activity Report?" A couple weeks later I followed up with Y. I asked what happened. He said "I asked S to look into it. S said that he met with FSK and pointed out the error in his calculation." But S never met with me! Why did S tell Y that he discussed the problem with me, but he never actually did it?!
That's a common social engineering trick. You tell two people two different things, and they usually won't compare notes.
2. For a couple of weeks, I shared an office with S. We were in the risk reporting group. Almost every day, S had a conversation with X on the production team. S spoke in a whispered angry voice, in a language other than English! (I never could figure out which one.) That was really weird, because S was from Russia and X was from China. If it was an "official" daily meeting, there would have been several people on the call, due to the nature of the bureaucracy. I was wondering if S and X were conspiring to forge records, and the phone call was them coordinating their efforts.
3. Table C had daily end-of-day positions. Table D had a list of all the trades. However, if you took Wednesday's end-of-day positions, and added all the new trades and subtracted the stuff that settled, the result was not Thursday's end-of-day position! I thought this was nuts, but S had all sorts of excuses for why this was necessary and desirable. For example, he said that some trades were reported after the end-of-day cutoff, but then shouldn't those trades show up in the table with a later timestamp?
If I was designing a system to facilitate funny business, I would make sure there were all sorts of weird bugs. Then, if I ever got caught, I could pass it off as a bug.
But S was the business' hero! He had singlehandedly written all their key software! He was Untouchable and a Valuable Employee! Of course, I was wondering if he intentionally put abusable Easter Eggs into their system (and maybe some other people were helping him).
When you buy and sell stock/bonds, it's just a number in a database. But if someone has DBA/root, and they're clever about covering their tracks, and a group of people are working together, they can never get caught!
Another weird thing is that I added up all the shares bought in one day per stock and added up all the shares sold in one day per stock, and compared them. Those two numbers should be the same, but they almost never were! I was wondering why nobody added such an obvious checksum to the system. I also added up the number of long failure-to-delivers and added up the number of short failure-to-delivers, and those numbers didn't match either! (A short failure-to-deliver is when someone naked short sells and doesn't deliver stock on the settlement date. A long failure-to-deliver is when someone should have received stock on the settlement date, but didn't, because someone else failed to deliver.)
A regular H1-b visa employee from Russia or China just earns a salary. If there are some people planted by the Russian or Chinese government, they get their salary, plus whatever they can steal, plus whatever their backers are paying them. So these bottom-of-the barrel wages paid to H1-b visa employees are most attractive to someone who's doing something dishonest. Also, if even one person slips through the cracks, then he'll be recommending his associates for jobs, and some of them will inevitably get hired (and eventually promoted). These people don't want the system to completely crash; they want it to appear to run smoothly while they quietly sabotage it.