Ah, the good ‘ole days. The days when we only read the chapters pertaining to auditing and security in the systems administration training guides in preparation to pass a test, or when trying to diagnose why a system wasn’t functioning properly.
Not so much lately. We as sysadmins need to be proficient in understanding our audited environments for both compliance and security reasons. We have to monitor logs generated by dozens of systems, devices, applications, and components either to demonstrate appropriate controls for audit compliance, or to perform forensics and rapidly piece together details from their audited environment in order to answer key questions their organizations may have after a data breach.
But, the biggest challenge I hear is how to bucket – or group – events so I can better prioritize their remediation.
Let me give you a couple tips so you can simplify the arduous process of auditing changes without losing your mind.
To discover more, download the white paper, "5 Tips for Simplifying Active Directory Auditing & Security".
Group 1 – Things I Know Should Happen
Most organizations have some level of predictable business automation. One example would be that new hires always load into the system on Sunday nights one week prior to starting in a disabled state. The following Sunday the account is enabled and moved from the staging area to a production OU by the automation process.
This type of activity you know when it will happen, the account that will perform the action, and the source IP the changes will come from. Additionally, you can cross reference the newly-created account with HR and paper trails to confirm they are correct if required.
You can create rules and alerts to see when these activities occur outside the known conditions.
Group 2 – Things I have Concerns About When They Happen
Whether the driver is security or compliance there are some actions that when – or if – they occur there needs to be a paper trail to explain to auditors. Using a shared DBA account or modifying the membership of a group that has access to legal documents, HR information, or access to PCI data would raise a red flag.
While the actions may occur regularly the point is to be able to find them and ensure the proper business process was followed so an audit incident is not created, and to ensure – worse yet – a security incident is not happening.
Group 3 – Things That Should NEVER Happen
There are certain events where it is more likely that you win the lottery than this event occurring. This will differ for each organization, but a few examples include changing the membership of the Schema Administrators group, setting a password to never expire, creating trust relationships, or adding new domains.
It is not that actions like these don’t occur, but in many organizations they occur so rarely that when they happen it is likely that a number of conversations will occur so the entire team is anticipating the action. Should the operation happen out of the blue that is obviously something that requires investigation.
Group 4 – Things That Happened Outside of an Expected Time, Location, or Pattern
Being a 24/7 organization means that many operations occur around the clock. Historically, you may know that accounts in a specific region that become locked outside of normal business hours happen, but the frequency of that occurring is rare. What would raise a red flag, however, is identifying a specific pattern like a 15% increase in account lockout after hours, or a user in Singapore having their account showing a failed login attempt in Germany, New York, and Argentina.
Group 5 – Things That Happen by Unusual Actors
There are likely users that have the rights to perform certain operations but never do unless specifically asked to do so. Therefore, if you see one of those users modifying specific security settings in a Group Policy, for example, that will peak some interest. You may have a handful of user who always make the policy changes but many more with the rights to do so and never do.
Finally, there is the remaining catch all bucket. Likely this catch all bucket will contain 90+% of all activity. It is not that the other buckets will have little activity, rather native auditing has a drawback of a single action generating multiple audit events. On highly active servers it is not uncommon for a single server to produce 10 million or more events daily. It is this level of volume that drives the need to have some level of focus on the activity you are to catch.
Interested in how capabilities in the PowerBroker Auditing & Security Suite can help with the bucketing and remediating of these events? You’ll have to read the white paper for that. For more on how we can help you greatly simplify your auditing efforts, contact us today!
Rod Simmons, Director Product Management, BeyondTrust
Rod Simmons brings more than 15 years of system security experience to BeyondTrust, designing solutions for the company’s portfolio of Privileged Account Management solutions for enterprise environments. Prior to his role at BeyondTrust, Rod spent more than four years with Dell/Quest software, where he served as the director of technical strategy. Earlier in his career, Rod was the director of product management at Netpro Computing, where he managed the technical and business direction of all products for the Microsoft Platform.