Deciding what data to log, how long to retain it and how it will be analyzed are all important points. You must also conduct log reviews to look for exceptions. In some cases, automation may help. In other cases, someone may need to scan certain logs looking for anomalies. When a discrepancy is found, an incident record should be opened to investigate what happened and why.
Other scenarios for user access management include people going on medical leave, maternity leave or sabbaticals. How will their rights be suspended during their absence? Will they have access to some services such as Web email and Microsoft Exchange or will they have access to nothing at all? Again, all this needs to be planned in advance.
Access management process implementation
Once the enterprise-wide access management process is finalized, it needs to be deployed. Whenever you introduce or change a process, the culture has to change as well. To make this happen, Windows managers must ensure that all stakeholders who are directly involved with the new process receive proper training.
At the same time, an awareness campaign should be launched to inform other people in the organization about the new process. If people are going to follow the process, then they need to understand where to find the access request forms, who needs to sign off on requests and the timeframes involved.
If the process is overly complex, confusing or otherwise poorly deployed, then people are less likely to follow it over time.
Steering clear of booby traps during the access management design processIn designing the process, Windows admins should be aware of the challenges and develop plans to mitigate them. The following are common pitfalls to avoid:
- Skipping requirements definition – In order to properly manage access, the process must reflect the needs of the business. This requires investigating the regulatory requirements, reviewing contracts and discussing risks and what is needed with senior management. In the end, it is senior management that should approve or reject the type of access management controls put in place.
- Designing multiple processes -- Resist the urge to write different processes for different services, sites or groups. One enterprise access management process should ensure that risks are properly managed, enable cross-training and make it possible to share best practices.
- Developing a draconian process – One reason to understand requirements is to avoid creating a process that is so harsh and burdensome that it incurs more costs than benefits. Strike a balance.
- Forgetting about cultural change – You can't just write a process document, publish it and then tell people to read it. You need senior management to support it and stakeholders to buy into it, and you need to have proper training and awareness campaigns. Not paying enough attention to cultural change can result in no one adopting the new process.
- Not allowing for exceptions – There should be relatively few exceptions to the policy. Instead of not planning for them, though, put a process in place to document exceptions and any appropriate management approvals. For example, say a Windows domain has the password expiration date set at 90 days. But suppose a vendor goes out of business and the application's password is hardcoded and can't be re-set. Replacing the application is cost prohibitive so the password remains unaltered. Rather than ignoring the exception, it should be documented along with the risks, and the appropriate managers should formally approve the exception.
All said, the two most important elements are first to understand requirements and then to address the need for cultural change. Regulatory compliance and improved security are the overall objectives, so Windows managers should design the enterprise-wide access management process accordingly.
George Spafford is a principal consultant with Pepperweed Consulting and helps IT organizations in the areas of technology and process implementation. Spafford is an experienced practitioner in many aspects of IT operations, including strategy and audits. He is a speaker on topics that range from security and IT governance to IT process improvement. He is the co-author of The Visible Ops Handbook.
This was first published in April 2008