How to pass that audit

As promised, here’s my quick and dirty guide to the inventory of digital and physical assets you need to have handy whenever compliance or security auditors come calling. I have some lovely and grotesque true stories behind some of these, but we’ll tackle those another time. This is indeed the Cliff’s Notes version.

These are the things that auditors will ask for directly, or in some cases I’ve included items which, if you have them, you will indirectly provide something else they’ll bug you for.

Inventory of assets: servers, app servers, APPS, databases, directories (LDAP), load balancers, firewalls, web servers (including plug-ins), identity-authentication-authorization mechanisms, and so on. In other words, the systems that run your business as well as the systemsthat PROTECT those systems.

Authoritative sources: the things that say what you can have. For example, “If a user is in the HR system with a status of employed=Y, then they automatically get email and a phone.” HR and payroll systems are common authoritative sources. It’s common to have more than one, but bad practice to have MANY. By the way, a person cannot be an authoritative source.

Policies, processes: how things happen. A policy is, we make users change passwords every sixty days. The process is, our IAM system is configured to enforce this policy. How do you enable and disable users. How and when are reports generated. And CHANGE MANAGEMENT. Promotions, demotions, transfers, and the really big one, terminations, whether nice or for cause.

Legacy systems: they’re often left out because the cranky old guys who run them don’t like it when you include them in IAM architectures. “You’re not installing that %#^$ on MY box, Junior,” a guy told me in Indy once.

Dev and test procedures: how do you launch new apps or systems, whether homegrown or store-bought? Do you test code? Penetration testing, for example. If you use production data for testing, do you MASK that data to conceal PII for dev and test teams?

Data security: are you encrypting sensitive data? I can’t believe the goobers who end up in the news when they allow the escape of data that was in the clear. It needs to be scrambled in production, over the wire, and in backup. And how are you auditing? Do you watch who does what with the data? This includes DBAs and other privileged users. Do we not trust DBAs? No, we love them to death. But we worry about their accounts being compromised. And yeah, once in a while one of them DOES do something naughty.

Segregation of Duties: how do you develop those policies, how do you review them, how do you enforce them.

Privileged users: do temporary duties get an end-of-life? Do you audit what privileged users do? Do you watch service accounts to make sure they ONLY do what they’re supposed to do?

Reporting: is anybody tasked with reading exception and other reports and looking for anything actionable? Do you review alerts, even the non-critical ones? They often point to potentially bad behavior early on.

Exceptions: are they documented? Most of them are acceptable, if you are aware of them AND you’ve documented them. “It’s in my head” is not documentation.

Certifications: access reviews, in other words. How often do you conduct them, and do you take action against them. And make sure you’re not just rubber-stamping people to keep existing access without an actual review.

Disaster recovery plan: in chaos comes opportunity, often for bad guys. A customer of mine copied live data to an unsecured machine, and bad stuff nearly happened, while they were attempting to get back online after a meltdown.

Threats: do you know yours? Are people trying to hack your grid, steal your credit card info, muck with your servers? Have you identified your most likely enemies? Because all this leads to …

Risk assessment: How do you determine risk? Do you grade it (here’s a yellow alert, here’s a red alert, etc.)? Risk must be calculated, and re-calculated, dynamically. Also transactionally. You might assign a risk score to a privileged user, and also to a privileged app account. But don’t forget the other factors. The trusted CFO looking at financial data is a little riskier if he’s doing it at 2 am on the weekend from a mobile device. Is that really him?

DOCUMENTATION: everything needs to be captured. Everything I just talked about needs to be in a doc, or set of docs. Don’t EVER let an auditor tell you something about your environment you didn’t already know. It’s what auditors call “proof of compliance.” All the security and compliance in the world are meaningless if you can’t prove it, at least in terms of an audit.

There is WAY more to this subject, of course, but these are the high level must-haves. If you’re really sweating your audit and/or the aftermath, then it’s probably well worth your while to bring in help to take a pre-inventory and get you on the rails. Failing an audit is costly and embarrassing. It brings me a lot of business, but at the expense of my customers. Don’t be one of those guys.