We continue the series of articles by Nick Cavalancia on our blog. The previous post was dedicated to Event Logging, today we are going to talk about general approach to IT Audit.
An IT Audit is, generally speaking, a reactive activity. Some compelling event occurs – a security breach, a critical system has issues, or it’s that time of year again to care about compliance – and you’re going to be required to produce copious amounts of meaningful reports to answer every question an auditor presents you with.
Before we jump into discussing an audit, let’s look at fundamentally why IT is being audited in the first place.
It’s a simple reason, really – changes.
Think about it – if IT made zero changes in a year (as impossible as that sounds), there would be nothing to audit. You would simply tell the auditor “Same as last year!” and head out to lunch. But that’s just not reality. IT is making changes… constantly. According to our 2014 State of IT Changes survey, an average of 41% of IT organizations today make changes that impact security or system availability on a daily or weekly basis.
Can’t get around it – you’re definitely going to get audited. At some point in time, for some reason, but it’s going to happen. So how do you prepare?
To prepare, you need to think about what the auditor is going to be asking for and work backwards. Here are a few suggestions:
- Start with data and move towards security – In compliance and security audits, the auditors are concerned about whether sensitive data is protected or not. Begin with the data sets that need protecting and determine whether you have the answers to questions like:
o Who has access to this data?
o Who had access to this data?
o How did those people get access?
o Who granted permissions? When?
Remember that this should apply to data residing on file servers, in databases, in email, on SharePoint, etc. It can, quite literally, be anywhere across the entire IT infrastructure.
- Prepare for very specific questions – Each question an auditor asks peels back another layer of even more detailed questions. So if you’re asked “Who is in the database admins group?” and you answer with the 2 people in the group, the next question could be “Who has been in the group in the past year?” See? Another layer. And if you can find the answer to that question, others will spring up like “What changes did those individuals make?” or “Who added them to the group in the first place? Why?” And the onion just keeps peeling back, making you cry more and more with each layer.
- Realize this is going to cover a long time – I’m not talking about it taking a long time (it will if you don’t have a proper tool for change auditing). I mean the audit itself may cover months or years of IT changes. When a data leak or security breach is discovered, one of the first issues to address is the scope of the breach – how long has it been going on (which can mean going back years in time to see when the breach first occurred). This means you need to plan ahead and have a long-term archiving strategy for the data you plan on using as the basis for your answers.
Your goal is to pass an audit (although some believe failing an audit may be helpful), so you need to put a plan in place to collect the needed audit trails so that when you are audited you have a data set to attempt to pull answers from. An audit will never be easy, but it can be easier. To answer the detailed, long-term questions an auditor will ask, having change auditing in place provides you the ability to quickly and easily answer the question. This means for each layer of the onion peeled back, you know you have the answer before the question is ever asked.
The audit is coming. Get ready now.
