There are all kinds of blunders and mistakes both users and system administrators alike make with their IAM systems; not only in misusing them, but also in deploying and configuring them incorrectly. Let's take a look at a few of these worst practices and see how to turn them around into best practices.
Poor password management
There is what could be called the "sticky note" problem. These are users who either can't remember their passwords, don't want to remember their passwords, or think it's more efficient to post them in a highly visible location, like on the proverbial sticky note attached to monitors or on scraps of paper sitting out on in the open. There is even an urban legend about a password written on a ceiling above someone's desk.
Why do employees still write down passwords despite being told repeatedly not to? This happens when people collect too many of them. There is a direct relationship between the number of passwords employees have to remember and the likelihood that they'll start writing them down. As the number of applications requiring authentication grows, the likelihood of passwords on sticky notes – or other places – goes up.
The solution to the problem
Another common password blunder is not changing passwords regularly. Passwords, like food, can get stale and moldy if they sit too long, and stale passwords are just what hackers look for. There is a simple answer to this one too: change passwords in regular cycles of 60 to 90 days, based on each system's risk profile. Password ages should be inversely proportional to risk. Systems with access to high-risk data or mission-critical functionality should have shorter password expirations.
Along the same lines is the ghost password -- authentication credentials of long-gone employees that are still active. These gems are popular with disgruntled insiders no longer with the company. Not only is this a poor authentication practice, it can also run afoul of regulations and industry standards such as Sarbanes-Oxley (SOX), the Health Insurance Portability and Accountability Act (HIPAA) and Payment Card Industry Data Security Standard (PCI DSS), which is required by the credit card industry.
User accounts should be audited on a regular basis to check for inactive users, escalated privileges and group memberships. These often change jobs and get different assignments. If an employee no longer uses a specific system, his or her access should be revoked, and new access for new roles should only be permitted while that employee is in the new job. If the access of long-time employees isn't regularly reviewed; they tend to get "access creep" into more systems than needed.
Also, every employee should have his or her own unique user ID and password. If someone uses shared access to a workstation for malicious reasons, an incident response team would have no way of determining which user was responsible. No matter how small the application, how few the users or how isolated the workstation, unique credentials for every user are a must.
Closely related to the sticky note problem is the unattended, unlocked computer. In this scenario, the user blissfully walks away from his or her desk for a meeting or office errand, leaving a computer desktop open to any passerby. A logged-in username can be a source of real mischief for a malicious insider, as he or she can remain anonymous by using someone else's open workstation.
The solution to this one is quite simple and can be as easily built into the standard desktop of a company's workstations. Password-protected screensavers that are set to automatically lock after a pre-set time period can protect the desktops of even the most absent-minded employees.
Another common mistake is to give developers access to production systems. Despite this being written in many companies' IT security standards, few organizations police this practice. While there are times when a production application goes down and a developer will need access to fix the issue, suggest giving developers temporary access while they're working on the issue. After the issue has been resolved, revoke access and close the temporary account.
There are also plenty IAM mistakes made by system administrators. Default passwords on routers and other networking gear should be changed as soon as equipment is deployed. Lists of default passwords for common equipment are all over the Web -- hackers know where to find them, and they will use them. This is often the first "test" a malicious user will conduct to get into a network.
Then there is the misuse of multifactor authentication. This includes sharing of smart cards or one-time password (OTP) tokens. This is the same as the shared password example just described. As with ordinary user ID and password systems, user accounts and their activity should be audited on hardware for smart cards and OTP tokens.
Help desk staff should receive training on social engineering tactics and should have written procedures for verifying employees who call to request password resets. Social engineers take advantage of the anonymity of big companies to pose as legitimate employees and steal authentication credentials. A quick check of some random piece of data from the legitimate user's profile – a birthday, title, address, supervisor name – can stop these tactics.
Access management blunders happen at all levels, with users, administrators, IT staff and even on help desks. But with a little thought and planning, these issues can be resolved and access to the company secured.
About the author:
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP, specializing in web and application security, and is the author of The Little Black Book of Computer Security available on Amazon. He also hosts a regular radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at http://www.theitsecurityguy.com.
This was first published in March 2008