- The Quarterly
- Audit Excellence
|Quarterly: Summer 2020 - Ben Thompson & Kayvon Zadeh|
Cybersecurity Auditing—Experience of Starting with a Single Department
Doing a cybersecurity audit has always felt like going to the dentist. I know I need to, but don’t really want to. After attending a few ALGA training sessions on IT auditing for non-IT auditors, and at the insistence of the county auditor, my team and I embarked on our first audit dedicated to cybersecurity. To narrow the scope of this work, we chose to concentrate on a single agency and landed on our Metro Transit Department. Hopefully our experience and some of the lessons we learned along the way will help you and your shop decide whether you want to do a cybersecurity audit and, if so, how you might approach it.
The answers to both questions are confidential. The point of this article is not to tell you what you will find, but to offer some tips that might help you develop your findings.
Clarify who is responsible for what.
One of the primary challenges we faced at the beginning of our audit was just figuring out who owns cybersecurity risk. The main issue we encountered was that the people who knew the most about the systems and users were not the same people responsible for securing them. This created challenges as we were doing our work and allowed for some finger-pointing between the IT and transit departments when we shared our draft findings. It is vital to determine if there are clear lines of authority before you start talking about deficiencies. Nobody wants to claim responsibility for something that you are saying does not work well. Early on in your audit, ask direct questions about who is responsible for what. We found it most useful to ask these types of questions when all the parties were in the room so they could respond to one another.
Agree on criteria early.
We did quite a bit of research around what criteria to use when we started our audit. Much of the criteria we came across was overly private sector focused. This can be a challenge because in many cases it assumes that there is unitary control over systems. We settled on using criteria from the Center for Internet Security (CIS) and the National Institute for Standards and Technology (NIST), specifically the CIS Top 20 and NIST 800-53. These seemed to be some of the most generally agreed upon and useful cybersecurity criteria available. Our state auditor uses CIS to conduct cybersecurity audits and several ALGA trainings have discussed the usefulness of NIST. Even when settling on these frameworks, we had to narrow down which controls within them we would audit, but we found that these two sets of criteria provided us with the standards we needed to really understand what solid IT controls look like. Fortunately, the auditees were receptive to these standards and are planning on using the CIS framework in their day-to-day work. This agreement around criteria facilitated our conversations about draft findings as we were easily able to track our findings and recommendations back to the standards, thus minimizing conflict.
Consider the physical aspects of cybersecurity.
Even virtual servers exist somewhere in physical form. Where are the machines that hold our most precious data and applications? How well are they secured? Ask some questions, develop a checklist, and make a site visit to see how physically protected your cybersecurity infrastructure actually is. We looked at the extent to which access to server rooms was controlled and considered whether cameras, doors, and keys were operating as they should. A nice part about this type of question is that it requires little to no IT expertise to evaluate and answer.
Conduct vulnerability scans, if they are not already happening.
One of the consistent components of the cybersecurity criteria we used, and more broadly, all the criteria we reviewed, is effective identification of IT vulnerabilities. In mature organizations, this is done through regular vulnerability scans of applications (software and other systems) and devices (computers, servers, etc.). We wanted to conduct similar scans in King County to get a better idea of what vulnerabilities we are facing and what, if anything, had been done to address them. We initially looked into having consultants conduct these scans for us; however, the consultants we spoke with wanted to sell us both scans and ongoing monitoring and remediation services. This presented a host of independence and other challenges for our office; therefore, we discussed scanning with our IT department to understand what tools it could offer. We then walked through our options with a peer jurisdiction, experienced in IT auditing, and decided that working with our IT department was a solid way to move forward. KCIT agreed to provide the raw results to us at cost, and we jointly signed a memorandum of agreement on the scope of work and timeframe.
Find out what’s confidential.
Washington state, where we live and conducted this audit, has some of the broadest public disclosure rules in the country. Under these regulations, we are required, upon request, to provide all documents and working papers associated with a published audit. Given the sensitive nature of this topic, we had significant concerns at the beginning of the audit that we would need to share the findings of our audit publicly. Fortunately, upon consultation with our attorneys, we found there were exemptions for public records related to cybersecurity. Given the potential for your audit to reveal critical weaknesses in your government’s cybersecurity infrastructure, it’s important to clarify what information you can keep confidential to avoid creating new risks.
About the Authors
Ben Thompson is the Deputy King County Auditor. He has been an auditor at the local and federal levels for fifteen years. Ben went to the University of Maryland School of Public Policy.