Wednesday, June 25, 2008
I wanted to use this blog post to discuss the ways our DirectControl and DirectAudit solutions can be used to audit your UNIX and Linux environment. Many vendors bandy about that they do auditing, but many just simply interpret and/or write to log files regarding successful and unsuccessful logon attempts. What they don't do is deal with what today's auditors and security professionals must increasingly address which is auditing user-level activity. For example, the Payment Card Industry Data Security Standard (PCI DSS) section 10.2.2 requires that organizations audit "all actions taken by any individual with root or administrative privileges" not just their logon attempts. Fortunately Centrify can help with the both high-level and more detail levels of auditing required to meet organization's compliance requirements.
Stepping back for a minute, let's first define Auditing in the context of the classic "Triple As" of identity and access management (IAM) Authentication, Authorization and Audit. They basically mean, "Who is it?" "What can they do?" and "What did they do?".
DirectControl provides the first two pieces. Here's Jane the admin logging onto a UNIX system using her Active Directory credentials:
Clearly the authentication piece is working, as Jane had to enter her username and password; in this case her Active Directory password. If we look in the DirectControl Console we can see her in the default Zone (a Zone among other things is a logical grouping of computers that a given user can access):
How about Authorization? Well the fact that she could connect at all shows the inherent authorization model of DirectControl's Zones. We can see that in another way by looking at a report from DirectControl:
This report shows that Jane has access to several machines; including the one she just connected to (paul-es5).
At a more detailed level Jane is an admin and so she has unrestricted sudo rights (if you look back at the first screen shot you will see her querying the contents of /etc/shadow). This is granted to her by using our sudo group policy:
All well and good, but how about the final 'A', Auditing; can we find out what she did?
First of all looking in the Windows event log we can see that she logged onto your UNIX systems (just like an XP system, all Centrified UNIX systems will write login attempts to the appropriate Domain Controller's event log):
This means that event log management tools such as Microsoft's SCOM will see this information. Secondly we can look in the UNIX syslog:
So this means that syslog oriented tools will see this data.
But neither of this lets us see what she really did on that UNIX system (e.g. did she edit the cron file, change the /etc/passwd, restart a service, change the init.ora file and what values were changed in the file, etc.??). You need DirectAudit to do that.
Here is DirectAudit's view of Jane's activity:
We can see that Jane logged on several times to that machine. Let's playback (like a VCR or Tivo does) her last session:
And, hey presto, we see exactly what she was doing during that session (sadly you cannot see that it's actually replaying what she was doing in my blog post, but trust me, it looks really nice or look at the DirectAudit 5 minute demo for an example). DirectAudit lets you slice and dice this information in many ways; we can look for sessions belonging to particular users and machines, between certain dates, that contain certain text, etc.
Now that's the type of auditing that the auditors really want to see, and in the case of a growing number of compliance initiatives, must see - they need to see "all actions" (input and output) taken by "any individual with root or administrative privileges." Pretty clear. But syslog scrapers or the NT event viewer does not give you that, DirectAudit does. So vendors who say they can help you meet PCI really can't address one of the 12 sections, namely section 10 which is the section on ... Auditing.
Think of DirectAudit as the "black box" (think of what a black box on an airplane does) for your UNIX system, so if something happens on the system, you can playback exactly who did what. Or think of it as the security cameras at a bank or casino, but in this instance it is capturing the activity of the privileged users on your systems vs. the actions of a bank teller or card dealer. Shouldn't the sys admin for a set of mission-critical UNIX servers that handle millions of dollars of transactions be audited just as much as a bank teller handing out $20s? Not that any of these people are going to do anything wrong, but if your job is to deal with money or sensitive information it makes for your organization to "trust but verify."
Now that's real auditing!!!
[Special thanks to one of my co-founders, Paul Moore, for the screenshots and helping me with some of the text on this one.]