Last updated at Mon, 06 Nov 2017 21:41:58 GMT
Sooner or later, your organization will likely be the subject of an IT audit. But as ominous as that sounds, it doesn’t have to be something to dread. If you’re a network administrator, you’ll have a specific role in an audit. Since audits are rarely small projects, you’ll likely be working with others throughout the process. The best way to fulfill your specific role well is to be prepared for an audit before it happens. Simply put, an audit is an examination to determine if controls are sufficient to meet policy and externally mandated objectives. They should help to identify security or service gaps that increase organizational risk to make your organization safer.
For real world example, suppose you say that you want to follow a low sodium diet. You may have come to this conclusion on your own after reading about the benefits of such a diet, or perhaps your doctor has recommended it. How do you know if you’re doing well or not in keeping with the diet? You could just compare what you’ve been eating to the guidelines of a low sodium. That’s really just a diet audit. If it turns out that you’re eating a bag of chips each day, then you aren’t really eating a low sodium diet. What does that mean? Did you fail the diet audit? Well, yes, but that isn’t the important part. It is more important that departing from the low sodium diet guideline increases your risk of sodium related diseases and disorders. The goal of any audit is simply to see if your organization is complying with stated goals that reduce risk.
One of the best first steps to preparing for an IT audit is to understand what kind of audit is being conducted and who is conducting the audit. Most audits aren’t surprises. In fact, many organizations have audits mandated by regulation, legislation, industry, or other external requirements. For example, does your organization accept payment cards? Depending on the annual number of transactions, you may be required, under PCI DSS, to conduct periodic audits. Lots of other external requirements exist that can trigger audits, such as FISMA, HIPAA, and SOX. Regardless of the external drivers for audits, you’ll probably benefit greatly from adopting a standard IT control framework, such as COBIT . COBIT provides a comprehensive framework and set of control objectives for IT management and governance. If you have adopted a framework, or simply have documented your own control objectives, you should map your infrastructure against the control objectives so that you can easily determine what is in scope for the audit. That step alone will help you manage the scope of work you’ll have to do. For example, if you’re facing a SOX section 404 audit, you could use COBIT to help focus on controls in three initial key areas, including:
- Change management process
- Access control / separation of duties
- Backups / archive storage
An IT auditor is also interested in collecting documentation of activity. Much of this documentation is in the form of log files. But that isn’t everything of interest to an auditor. Activity logs aren’t much help unless there is something to compare with. Additional information can include policies, procedures, or even previously examined activity logs. Auditors are looking for evidence of activity over some period of time. They want to examine what was supposed to happen (policies, objectives, and procedures) against what actually happened (log files and other artifacts.) So how do you know what specific information an auditor wants? Just ask.
One of your first steps in preparing for any audit is to determine who will be conducting the audit. This information should be easy to find out. Then, ask the auditors what they will need from you. They’ll generally let you know what artifacts they’ll need to carry out their work. That information should help you determine whether you are ready. If you are, great! If you aren’t, you’ll need to make some changes to ensure the auditors have what they need when they need it. That may include adding logging features or keeping more log file contents. Review your logging policies and procedures to ensure that you’ll have the information the auditors need – and that any changes you recommend don’t violate other parts of your security policy. In some cases, auditors may require information that exceeds your organization’s information retention policy. In such cases, management will have to review the security policy and potentially change it to align with external requirements.
There are lots of online resources as well to help you prepare for an audit. Once you know the specific type of audit, such as an annual PCI DSS audit, use your favorite search engine to help prepare. In this case, searching for “PCI DSS audit preparation” is a good place to start. A little research should provide you with guidance that is specific to the type of audits that apply to you. Use other peoples’ experiences to help you avoid pitfalls.
Although it sounds like a lot of work, preparing for an audit helps your organization in several ways. First and foremost, actively preparing for an audit greatly increases the likelihood of receiving a positive audit outcome. Secondly, finding and removing gaps yourself before an auditor finds them reduces risk to your organization. And reduced risk means reduced probability of a breach. Preparing for an audit is effort and time well spent. Don’t dread an audit – it isn’t a final exam. It is just an opportunity to validate that either your risk is as low as possible, or that there are gaps you need to address. And being well prepared means there will probably be fewer gaps in the audit report.
