Part the last. It has been well over a month since part 5. I wanted to finish this overview before I do ny talking about specific solutions.
I’ve read several papers lately that provide an overview similar to what I’ve attempted. Better than this. Most focus on planning an IAM project. They generally identify three goals: cost reduction, security and compliance. Hopefully there has been information on all three of those goals peppered into my blogs until now.
Today is specifically about auditing and compliance. Through every part of this I’ve mentioned keeping a log, but mostly focused on a change log. The full auditing that is required for your IAM solution will likely be greater than that.
When you look at this there are four areas of logging to consider:
1) User activity – both normal and abnormal. User activity would be authenticating, authorizing, password changes and self-managed data changes. Abnormal activity is attempts to access unauthorized data or resources, authentication attempts outside of allowed windows, multiple logon failures, logons from unauthorized terminals, etc. Normal activity should have a policy for retention. Additionally you will want to give some thought to how the data will be used. If you want to use the data to form a trail of the users activity it will need to be mined from the complete logs. This might require additional tools or functionality in you IAM solution. Normal data can also be used for capacity management for the system or for the systems that the IAM solution is protecting. Abnormal data will need to be actively monitored with threshholds for investigation and alerting. You might need different policies on alerting and investigation for normal accounts vs. privileged accounts. Or normal accounts attempting access on privileged data or resources.
2) Object Administration – This will fall into two pieces. Change logs from the change management system and audit logs of changes within the IAM solution itself. In general this is simply another form of normal activity for the product so all the guidelines I just mentioned apply. Think about what reports will be needed and what will need active alerting.
3) Configuration Changes – Once again there will be two pieces. The change logs and audit logs for the product. Some configuration might be done outside the product as well – OS, database, configuration files, etc. Another item to consider for both this and object administration is whether you want to have configuration management controls. That is controls within the product or integrated into the product that prevent changes without approval. A basic form of this exists in Windows – an object can be marked to prevent deletion. The prevent deletion box needs to be unchecked explicitly. The concept can be expanded to any change within the tool. The main reason for such a change is to prevent accidents. Mass deletions or adding ‘Everyone’ to a priviliged access group.
4) Access tracking – none of the activity logs will be able to produce some of the basic reports you will need. Can Suzy access resource X? Who can access resource X? What are all the resources Suzy has access to? These questions range from simple to difficult. For instance in Windows the first can be answered by looking at the ACL and seeing if Suzy is explicitly there or a member of any listed groups. With group nesting this might take a few minutes, but can be done by hand petty quickly. The second question is much trickier and will take a while to do by hand, but is pretty easy to script. The third is nearly impossible in Windows. Either a 3rd party product is needed or a script that can walk all the acls looking for anywhere Suzy or her groups SIDs are located – this is both hugely time and resource intensive. In other systems the questions might be much easier to answer or harder.
When answered what is needed it is important to also determine what isn’t. The volume of auditing data can potentially be huge. Turning on all auditing could be a resource hog and produce so much data as to be practically useless. If there are legislative or other compliance regulations or security policies look to them. Determine what will be needed to troubleshoot normal problems. Determine what will be needed to demonstrate ongoing efficient and secure operation of the system. Resist the urge to turn on logging in addition to this.
If additional logging will be needed during change implementation or troubleshooting determine what the impact of enabling it will be.
Also remember that the auditing data is also part of a person’s personal information and will need to comply with the privacy regulations you are under. In particular that means don’t collect what you don’t need, don’t disclose and delete when it is no longer required.
That is all I have to say about that. If I do any additional IAM blogs they will be about specific issues and/or products.