Last week a story broke about a former Fannie Mae IT contractor accused of planting malicious code that would have taken down systems and destroyed data right at the epicenter of today’s global financial crisis. The accused former employee has since surfaced claiming innocence so I prefer not to go into that specific case but rather use it to consider the likelihood that similar crimes could take place in other companies.
Well of course the probability is 100 percent simply because similar crimes HAVE taken place in other companies. It happens all the time at an annual cost of BILLIONS.
IT crimes go grossly under-reported because they are so embarrassing to their victims who convince themselves that saying something will only embolden the bad guys and lead to further losses. In one sense this is true, but in another it creates a false sense of safety. This is one area where we really SHOULD feel vulnerable yet most companies don’t and have lax procedures as a result.
So just in case you are interested in this topic or have some influence in data security, here are my overkill ideas on how to lock things down. It is doubtful that any company or agency would do all these things, but doing at least some of them makes good sense to me.
Many years ago good business practice was to put all critical systems on an internal, isolated network that did not have a path to the Internet. This would prevent someone from the Internet accessing a bank’s ATM network, or a chemical company’s process control system, or a power utility, etc. Recently I’ve been amazed to find how many firms are not doing this anymore and worse, they don’t understand why they should even try.
So here are my recommendations to avoid those nasty logic bombs. Your mileage may vary.
1) Route admin access to all systems through a logging proxy server. Each administrator must be authenticated by the proxy server and their access to systems logged. Keep the logs and check them on a regular basis.
2) All admin personnel will be assigned two user IDs. One will be a normal, non-privileged ID they will use for routine things like email and office applications. The other ID will be privileged and include a special character, maybe a “$.” You can’t check your email or run a business application with this ID. All admin access is done with the special ID. Use of generic root or administrator accounts is not allowed after the system is set up and running.
3) Scripts are run on each server (or domain) to check user IDs. All privileged IDs must have the special character and the right rules. All non-privileged IDs must not have the special character. Logs are checked for login by generic root or admin accounts. All deviations from policy are flagged and investigated. Scripts automatically disable all out-of-policy accounts.
4) After a system is set up, install a script to reset weekly the generic root or admin password. No one is supposed to use this account and no one knows the password. If you need access to the generic system ID, then run a tool that will tell the password of the week. This is a logged event too.
5) All admin access to a system should be logged and recorded in the change control system. If you fixed something or changed something, you need to note it by editing the record of your access (you can’t delete the record, only add to it.). On important systems run a trip-wire tool and post its report in change control too.
6) Privileged IDs must have their passwords changed at least once a month. Longer password expirations are acceptable for non-privileged IDs. There are password rules on content and length. Manage all IDs with LDAP.
7) HR manages user IDs. In the case of a departure or termination, the user’s IDs are disabled. The passwords are changed. Their managers are given access to the IDs and new passwords. All IDs are maintained in a database. When each system is checked, the IDs on it are checked against the HR database. Exceptions are flagged and investigated. When someone leaves the company for any reason, reports are created showing all their system access and changes.
Now would these seven steps stop a determined and talented former employee or contractor? Nah. And that’s the part that’s really distressing, because I am sure we have built into our IT overhead 5-10 percent simply to cover sabotage – a crime we otherwise try never to mention.