Print Page | Contact Us | Sign In | Become a Member
Quarterly: Summer 2020 - Ben Thompson & Kayvon Zadeh

Cybersecurity Auditing—Experience of Starting with a Single Department


By Ben Thompson and Kayvon Zadeh

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.

First, a little context. King County’s Metro Transit Department (KCMT) operates our local public transit system and provides drivers and maintenance services to other regional transit providers. Unlike most other public transportation agencies around the United States, KCMT is part of the county government. In 2010, King County consolidated IT departments across the county into a single entity called King County Information Technology, or KCIT for short. In addition to many other responsibilities, KCIT has the job of ensuring that county devices and applications work and are appropriately protected from cybersecurity threats.

Our audit focused on answering two questions:

  • To what extent are technology vulnerabilities identified and addressed?
  • To what extent is access to technology limited to appropriate individuals and at the appropriate levels?

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.

While we had some trepidation with KCIT conducting the scans for us, it ended up being a useful exercise. It allowed both our office and KCIT to get the results of the scans, which was useful for the audit, and to learn firsthand of any hiccups in the scanning and remediation processes.

One challenge we had with scanning was how to evaluate the results. To address this, we compared the list of vulnerabilities identified in the scanning results with lists of published exploit kits so that we could tie specific risks to the vulnerabilities identified by scanning as opposed to just saying how many vulnerabilities exist, since not all flaws are worth fixing. This way you can present the risks in a more concrete way by indicating whether they were connected to previous cyberattacks.

 

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.

Overall, despite some of the challenges we faced, I am glad we did this audit for a few reasons. First, cyberattacks are and will continue to be a significant threat to local governments. Auditors have to examine these risks in order to stay relevant in our jurisdictions. Second, given the high turnover in this field (we are on our third chief information and security officer in the last two years), auditors can play a role of providing continuity in this complex area. Third, while cyberattacks and other potential computer malfeasance are significant threats, they are ones that policymakers find easy to ignore. One role auditors can play is to highlight and provide context to these threats so that we can help policy-makers avoid under- or overpreparing for cyber threats.

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.

Kayvon Zadeh is a Senior Management Auditor with King County, where he has worked for about four years and conducted audits on topics ranging from homelessness to involuntary treatment and detention. Prior to working with King County, Kayvon worked in Seattle Public Utilities Risk and Quality Assurance Division, where he conducted both policy and audit work. Kayvon went to the University of Washington for both undergraduate and graduate school where he graduated with a bachelor’s degree in psychology and a master’s degree in public administration.