Internal fraud coupled with IT savvy is a killer combination
Summary: As any auditor knows internal fraud is as old as business. The classic case involves the secretary who is responsible for accounts payable as well as procurement.
As any auditor knows internal fraud is as old as business. The classic case involves the secretary who is responsible for accounts payable as well as procurement. He generates bogus invoices and pays them to bogus companies. I have a friend in
Modern accounting controls are supposed to prevent this kind of fraud. The real danger is that controls are not keeping pace with technology. Since the introduction of the first commercial computer (UNIVAC, on this date in 1951) computers have been used to make the fraudster’s job easier. This article mentions three cases of admittedly low tech fraud but involving IT staff. In one case a mid level IT manager at the Canadian Defense Department created bogus orders for Tempest Terminals that were funneled through a supplier, HP, to front companies from which he would get kick backs. The point is that IT staff are not above sneaking a buck out of the till now and then. Imagine the consequences if a developer or internal admin monkeys with the workings of your automated billing and receivables software?
What could an insider accomplish with a few simple credentials? Access to the treasury system for instance. Most large organizations swap millions into overnight instruments to take advantage of the best interest rates only to swap them back into their working accounts during the day. Skimming a piece of that transaction could be simple.
It is probably a good time to review internal controls at your organization. Rolling out a new layer of authentication could cut short any existing fraudulent operations. Strong authentication for any treasury function should be mandated. Monitoring of transactions and data transmissions is another step. And an audit of existing controls, including a test would be good.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Rounding error
Thieves may not be as clever as idiots (Remember the old saying, Nothing is idiot-proof because the idiots are so damned clever.) but they are just as determined.
Hah!
-RS
This is one thing where IT doesn't matter at all
But they won't be able to solve the problem - after all, someone [b]does[/b] hold the key to the safe, so to say. And this human is [b]the[/b] weakest link in the chain.
Disagree
If someone is being watched they are much less likely to steal. Thus, cameras over the shoulder of the bank teller and web pages that inform someone when they are violating company policy.
So?
As another poster had said already - its humans who ultimately make decisions about fraudulent activities and act upon it. As long as it stays true - technology won't solve the problem, it will only offer a reasonable deterrent.
Checks and balances
Bank tellers.
Another teller was $400 short in a single day. There was a careful review of the tapes with no idea how it happened.
Neither teller was suspected of dishonesty at any time; the intent was to find a successful scam.
This sort of thing happens all the time. Please don't expect technology, even supplemented by human judgment, ever to be a perfect brake on criminal action.
Of course not perfect
real world example
Now if I was really unscrupulous... what is to stop me from logging every username and password to SMTP without anyone ever knowing it was in the code? I could compile an external library, to which nobody else would know what it did, and I could simply say it was a necessary library I downloaded as open source. Now then, I don't do anything until I make an entry in the config file.
We do monthly release cycles. We build it, then hand it off to production admins-- who do what we tell them. Copy here, copy that, etc. What is to stop me from on, July 1st, activating that SMTP logger for one month, by providing a config file with the right entries, then deactivating next month?
This is why admins/developers MUST have the highest ethics, and MUST be tested for that sort of thing.
Furthermore, I would never hire anyone who had been convicted of any crime, regardless of when, nor even accused of anything close to it-- for that very reason.
Great knowledge in the wrong hands is extremely destructive, and that example above is one scenario that I'm SURE has been realized numerous times by IT folks.
The even scarier part: there's nothing that can be done about it because at the end of the day, we have to rely on humans, whether its the IT guy or the auditor, or whoever-- is up to another human to decide.
Absolutely agree
There're no real technical means to deter me from doing this, save for a full-blown code security audit - and even that won't necessarily find the hole - I know pretty well how such audits are done and will, of course, take necessary precautions.
But of course I'll never do such a thing - my professional ethics and self-esteem do not allow for such behavior. But I know of several less scrupulous fellows who now make quite a decent living by leaving such backdoors in the systems they develop.
Yikes
When does organized crime get into this? They could *Hire* people to put back doors in ATM software or whatever.
Non-negotiable audit trails....
Also....
Not just fraud, retribution
When he found his name on the "bye-bye" list, he opened up permissions to the directory to all employees as a goodbye present to the company.
The surprise tap on the back wasn't such a surprise to a lot of people.
You need proof and a white knight in a bullet proof vest