Tuesday, February 3, 2009

Cringley's Top 7 ways to prevent an internal IT attack

Bob Cringely had an awesome post recently about the top 7 ways to prevent an internal IT attack. It was prompted by a recent story about how Fannie Mae IT contractor had created scripts that would have deleted millions of dollars worth of data.

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.

1 comment:

  1. none of these are going to prevent a really serious hacker, but it's a good start.