Things fall apart. Entropy gets everyone, in the end, and no sooner has a security feature been implemented than exceptions, and one-offs, and workarounds start to appear, like mushrooms after a rain. A security feature that was well implemented 18 months ago may not still be functioning as you planned. But who has the time to run around checking work that’s already been done? That doesn’t cross anything off the To-Do list, nor does it impress any “what have you done for me today” executives.
Yes, time and attention is scarce. But a well-designed and executed IT audit program will more than repay the effort. It can both improve your security as well as show executives that your IT shop is continually improving. That said, all audits are not created equal. While each organization will choose very different audit plans, here’s some ideas to keep in mind while choosing what and how to audit:
●Select worthwhile controls to audit: The audit’s results should tell you something meaningful about your security. The control that you audit should both have a likelihood of being mis-applied and a security impact if so. For example, auditing physical access to the data center may not be worthwhile, if all badges are promptly returned – so what if someone is still in the access system when they have no badge? On the other hand, a laptop that’s missing encryption may easily slip onto the network, and cause no end of grief when it’s lost. Key controls will vary between organizations, but make sure that you’re auditing a control that makes a difference.
●Audit exceptions regularly: It’s very common for workarounds to be granted and forgotten, and to persist long after the need for them has passed. Ideally you have a management group that approves and documents exceptions to policy (such as an obsolete product that can’t handle usernames). But regardless of who grants them, exceptions should be reviewed regularly to determine if the need still exists and the risk is still acceptable.
●Audit something you can fix: If your EMR is hosted, there’s little return on auditing the hosting company’s operations – they won’t accept your kind suggestions, however valid. (Unless you make up 40% of their revenue, in which case go ahead). Similarly, auditing physical controls can be an exercise in frustration if you lease your building and have to deal with the landlord.
●Audit important controls more often: Many organizations perform continual auditing via Active Directory tools, such that every change to the Domain Administrators group triggers an email. While continuous control monitoring is often a very ambitious goal, the more important a control, the more frequently you should verify that it’s working as planned.
●Automate: As mentioned above, audit isn’t glamorous: The more you can automate your audits, the more you can spend on more high-profile initiatives. Where automation isn’t an option, try to plainly document the audit steps and offload it elsewhere, such as Compliance or an intern.
●Seek the root cause: Say you find that contractor’s accounts on the VPN are not being terminated promptly. Is the root cause that the user management process is not being executed, or is the root cause a flaw in the process itself? Are tickets to terminate contractors not being acted on, or are they not being created in the first place? A common root cause of this is poor communication between HR and IT. The distinction between “our process is not being followed” and “our process has gaps” is a vital one to make.
●Document your response: For each audit finding (where the results differed from what you expected) either accept the findings and develop a plan to fix it, reject the findings and record why, or transfer the responsibility to another part of the organization. Most audit findings should have an action plan, a deadline, and a responsible party. Some audit findings should be bumped back on, but only when done by outside groups; if you’re rejecting your own audit findings as low-value, you need to rethink how you’re auditing.
●Track trends over time: After the action plan is completed, you should re-audit again, a short time thereafter, to make sure that the fix has taken. Not just once, but a few times at regular intervals thereafter. After a few instances of a “clean audit”, you can conclude that the particular control is fixed, and audit it less frequently thereafter.
●Show your work: At a minimum, an audit program should include an audit plan, which identifies what controls you’ll audit and how frequently; audit procedures, which include how the audit will be performed, what you expect to find, and how to record the results; and an audit response, which includes all findings and your organization’s action plan to fix them. A longitudinal look at a particular control can also be powerful – “Control X had 10 findings four quarters ago, but the three subsequent quarters showed 4, 2, and zero problems”.
Auditing your controls can prevent a tiny hole in your defenses to sink you; the “I thought we were watching that” syndrome is both organizationally destructive and personally embarrassing. It can also help you find the root cause of problems– you can avoid playing whack-a-mole with problems that continually crop up, and actually find permanent fixes. And if consistently implemented over time, an audit program becomes a powerful tool to show your security improvement to executives and other non-IT audiences.