Auditing for FISMA and HIPAA: Lessons Learned Performing an In-house Cybersecurity Audit

Within the last two years, the author’s research-oriented company installed a commercial, off-the-shelf (COTS) tool within its Moderate network to use for survey work. The company developed the Moderate network to meet the US National Institute of Standards and Technology (NIST) SP 800-53 security controls after determining that all the information it would process would be classified as “moderate” under US Federal Information Processing Standards (FIPS) 199.¹

The product has modules that can be programmed to create field instruments for different projects and different modes of data collection, including computer-assisted telephone interviews. The application is available only to project developers and testers and to call center personnel who use it while interviewing respondents.

The process took place in the three phases illustrated in figure 1.

Phase 1: Selecting a COTS Tool or Product

In general, companies often begin searching for tools that have features that will help them deliver products and services effectively and efficiently. During this prepurchase exploration, companies also look at the tool’s installation requirements in terms of the necessary hardware and software. For example, some applications may require certain size servers and base software for support, while other products may have different requirements. Part of phase 1 is, of course, selecting the product based on as many requirements as it can fill.

However, a key part of the review that may be missing is the cybersecurity review, i.e., if and how the application will fit into the company’s cybersecurity stance. The company’s COTS team was determined to ask many questions and keep in mind security best practices.² The team was also supported by management, as corporate executives are increasingly recognizing the need for cybersecurity audits and reviews.³

To ensure that a tool or product is adaptable to the company’s existing cybersecurity environment, a detailed review of the organization’s cybersecurity implementation should become a more integral part of the initial review phase. A cybersecurity audit of the company infrastructure and how the application will fit in it can help keep costs and effort down and provide more efficient use of the product. In addition, a cybersecurity audit of the product may discover that a subset of the application features that may have initially attracted users cannot be used or implemented because they present an unacceptable risk to the company’s cybersecurity stance. For example, while employees at a company may wish to use cloud-based services, the company’s cybersecurity stance and guidelines may include a list of approved cloud vendors and require employees to use only those vendors. Another part of the company’s stance may require employees to encrypt any files transmitted to clients and require that the encryption be done using a product that is FIPS 140-2 validated and appears on the NIST FIPS 140-2 Vendor List.

One of the lessons learned during the process was that a thorough cybersecurity audit prior to installing the product would have helped the teams and saved time and effort in bringing the product to acceptance and use. For example, the team could have saved time by a more thorough vetting of the vendor prior to purchasing the product. This would have found that the vendor, while aware of cybersecurity concerns, did not develop or maintain documentation that would be available to help the project team develop the required system security documentation. As another example, an audit of the software might have found that it was not configured to maintain certain log events, e.g., a password lifetime history, that help ensure security.

Based on experience, a cybersecurity audit would include the following activities:

• Determining which standards are in place at the company, including the US Federal Information Security Management Act (FISMA), US Health Insurance Portability and Accountability Act (HIPAA), US Health Information Technology for Economic and Clinical Health Act (HITECH), and NIST
• Determining how the company implements the standards, which may be based, in part, on the company’s product, business or service paradigm(s)
• Examining the network and system architecture (the wiring, software configuration and security mechanisms) and matching them to the required COTS system specifications and configuration requirements
• Determining what documentation is in place and available for use and repurposing

The ultimate goal was to ensure that the application, as installed, would be ready to meet certification and accreditation requirements, pass security assessment reviews (SARs) that federal clients conduct and receive an authority to operate (ATO) from the agencies.

Phase 2: Installing the COTS

The process for installing the COTS product in the organization included the proof of concept (POC) team development and testing.

The POC team was formed after the product was selected. The team consisted of individuals who had prior experience with installing software packages and tools in the company’s Moderate IT infrastructure and who understood which standards were followed and how they might be interpreted. Team members also had a good understanding of the IT capability of the infrastructure.

The initial phases of prepurchase exploration and selection were carried out. The team examined security concerns around the database, the movement of data and how these concerns applied to public-facing web servers.

Installation was carried out by corporate IT personnel and POC team members, with consultation from the vendor.

Proof of Concept Testing
The POC team developed test plans for COTS features that were required by prospective users. The test results were analyzed and divided into two categories: a bug list of items to remediate and a wish list of enhancements.

Testing, bug remediation and enhancements progressed incrementally with pilot tests in the different survey modes available on the COTS. Simultaneously, the POC team continued to fix, stabilize and enhance the COTS tool sets, while also increasing the number of production projects in each of the available modes as the team deemed fit. These projects and the tool itself were in a FIPS 199 moderate-impact security environment, which provides a different set of considerations in each facet of these activities. There are three FIPS 199 environments: low, moderate and high. The designations are based on the amount of harm that could be caused if the system’s confidentiality, integrity or availability were compromised by attackers or other means. Overall, the moderate-impact security environment adds a level of complexity to installing the COTS software system and to the documentation required.

Phase 3: Cybersecurity Audit of the COTS

After the extensive testing conducted in phase 2, senior management directed members of the POC team to begin a cybersecurity audit to make sure the data collected by the product would be protected from theft, loss and damage. The goal was to examine how the application protected data through its own internal controls and how the application fit into and was protected by the corporate infrastructure, including network access and physical security.

As part of gap analysis and audit, the following questions were asked:

• Is this control documented, implemented and effective?
• Is this control applicable to the software application, the network or both?
• Who is responsible for implementing the control?
• Do we know who is logging into the application?
• What audit records does the application have the capacity to record?^{4, 5}

To undertake the gap analysis and overall audit, an audit team was formed, which consisted of senior systems engineers and a research documentation specialist with experience as an information system security officer (ISSO).

For this effort, the team had buy-in throughout the project from management, corporate information technology services (ITS) personnel and research staff. The company also had the support of the vendor and scheduled weekly meetings with vendor representatives to help solve issues. The company had built-in controls, processes and documentation in place to build upon and reference. In addition, collaboration across multiple teams—including project teams already collecting data via other systems, corporate IT security personnel, IT teams with Moderate network experience and other corporate resources—was important and gave the POC team a wider knowledge base.

Preparing for the audit allowed the team to find areas of weakness in the system documentation and processes and work to remedy them before an external third-party audit. The internal auditors drilled deep into the processes of the COTS and the processes surrounding it, and the team developed a plan of action and milestones (POAM) to remedy the findings in a specific time period.

The internal auditors also provided validation that the work the COTS team did was effective and of proper scope.

NIST Documentation

To begin the process of evaluating the cybersecurity stance of the COTS product, the team determined the list of required documentation, including:

• System security plan (SSP)
• Contingency plan (CP)
• Incident response plan (IR)
• Access management plan
• Audit policy and procedures
• Configuration management plan
• Security training policy
• System maintenance policy
• Physical security policy and procedures

To help develop the document package, the team was able to make use of other in-house applications that had developed similar packages. These other teams were happy to share their documentation, and the audit team was able to use these documents as templates.

The most difficult of the documents was the SSP. At the application level, the team needed to address 18 of the NIST 800-53 control families and the enhancements required at the Moderate level—approximately 260 controls in all. While many of these were addressed by corporate policy and procedure, application-specific information had to be brought out through interviews of IT personnel and project team members. In addition, the team had to write application-specific policies and procedures. The COTS team used NIST SP 800-54 Revision 4 as the baseline.⁶ The team was assisted on this important document by the corporate IT governance, security and compliance (IT GSC) group, which had recently updated the corporate SSP to Revision 4. Corporate IT GSC also performed a very important review for the COTS team, annotating the template SSP and indicating which controls should be addressed at the application level and which are inherited from the corporate IT infrastructure.

The COTS audit team developed the COTS SSP. Any applicable baseline materials that had been used on other survey applications housed in the Moderate network were imported. The audit team then began developing original descriptions detailing how the COTS application worked and met the NIST controls. The process included reading and parsing out each NIST control and how it applied to the COTS, discussing how the COTS met the control requirements, and drafting a description that was reviewed by team members.

Determining the COTS Security Parameters

Security questions and concerns were also included in the weekly COTS project team call with project developers and the COTS vendor. The audit team gathered available documentation from the vendor and was able to elicit information on several points, including the software development life cycle the COTS vendor used to develop the application and to continue development and maintenance. However, the vendor explained that its documentation did not address the NIST controls, as it had not previously been an issue and other clients had not asked for it.

The audit team then determined that all the information about the application and how it met the NIST security controls would have to be developed by team members and be recorded in the SSP. As noted earlier, the team had determined the suite of documentation that the application needed to support the NIST controls. For example, while there is an overall corporate business continuity plan as well as a Moderate network contingency plan developed by the company ITS group, the application itself needed a CP that delineated the application’s project team roles and responsibilities and examined how the team would interact with the corporate and ITS plans. The application also needed an IR for the same reason.

Other documentation was application-specific as well. For example, the access management document described the process by which users were granted access to use the system itself when working on a data-gathering project. The application inherited the corporate and network access management plans.

The audit team worked through the NIST controls by family in weekly meetings and in emails, discussing how the system operated and how the NIST controls were or were not met or were inherited from the Moderate network.

For example, for the audit and accountability controls, the audit team discussed and recorded what the application itself was able to log and what the system relied on the Moderate network to log.

External Audit

After the internal audit team had finished the SSP and other documentation, management decided to have an external auditor prepare a security assessment review (SAR) to help ensure that the system and its documentation were FISMA compatible. An audit firm that had experience with the company’s Moderate network was chosen to perform the work.

The audit firm evaluated the application against the security and privacy control baselines as defined in federal guidelines and the company’s policies and procedures, then determined if there were any gaps or vulnerabilities. The test activities were performed in accordance with the NIST 800-53A Revision 1, Guide for Assessing the Security Controls in Federal Information Systems and Organizations: Building Effective Security Assessment Plans.⁷ The testing of each security and privacy control would be given a finding of “satisfied,” “other than satisfied” or “not applicable.” Gaps and vulnerabilities would lead to an “other than satisfied” finding; in such cases, recommendations would be provided by the auditors to help remediate the problem.

The SAR evaluated the security and privacy controls around the application based on an understanding of the company’s control environment for a FISMA moderate system based on the FIPS 199 standards. The scope of the assessment included the people, processes and technology used to receive, store and process, and analyze data collected.

The external auditors arranged to come on-site and meet with audit team members. The engagement was four working days, with space built into the afternoon of the fourth day to allow the audit team to gather information and develop responses for the external auditor.

Prior to their visit, the external auditors provided a secure SharePoint login to their corporate site and asked the audit team to upload documents that pertained to each NIST control family. The SharePoint site had folders for each individual control and a separate folder for the SSP.

Overall, the site visit went very well, and the audit team was able to provide nearly all additional artifacts requested by the external auditors and answer additional questions.

Lessons Learned

The COTS team took away several lessons from the experience:

• There were already built-in controls/processes in place to build upon and reference. As noted earlier, previous work done on similar systems was available from which to build. This indicates that documents should never be thrown away because they often offer a starting point. The team also had processes in place for the COTS that had been borrowed from either another system or adapted from the corporate processes.
• Collaboration across multiple teams and resources provided a wider knowledge base.The team was able to draw on many years of experience available in-house, working with members of the IT department, IT security group, and managers and administrators of support services. With their input, the team was able to understand and document the COTS and its relationship to the corporate network.
• The audit process provided tangible evidence and remediation requirements that allowed developing better controls. Preparing for the audit allowed the team to find areas of weakness in the system documentation and processes and work to remedy them before an audit. The audit itself then drilled deeper into the processes of the COTS and those surrounding it, and the team developed a manageable POAM to remedy the findings in a specific time period. The audit provided validation that the preparation work the COTS team did was effective and of proper scope, as the actual audit findings were not severe. The team had buy-in from management (and others) from the beginning of the effort. Senior management had initiated the process of developing the SSP and associated documentation, which is becoming more common and important.⁸ Senior management also allotted time in the schedule and person-hours to help accomplish the tasks. Management attention to cybersecurity auditing is become a standard both within business circles and beyond, for example, in public education.⁹

Documentation Specialist/ISSO Lessons Learned

The documentation specialist/ISSO on the COTS team learned some specific lessons from the project:

• Use a consistent description in email subject lines. For example, any information exchanged on the AC-1 control should have “AC-1” in the header. This sounds simple, but can be quickly forgotten. When forgotten, it can lead to lost time searching emails by other key words.
• Ask as many questions as needed. As the writer for the SSP and other documents, and not a user of the COTS, the documentation specialist needed to ask many questions about how the COTS worked and not make any assumptions based on experience with other applications.
• Use words and documentation developed for other projects when they can be revised and applied to the current work. Starting with text is much easier than starting with a blank page, even if the initial text needs to be completely rewritten.

Conclusion

Overall, the team learned that an audit by an independent body was a healthy exercise because it made the team look at the overall cybersecurity stance of the application within the corporate system. The items discovered by the audit were remedied and included writing and reviewing necessary security documentation, reviewing and updating existing policies and procedures, and ensuring that security training was updated to reflect new threats.

Author’s Note

The author would like to thank David Foster, David Schulz, Curry Spain and Charlotte Scheper.

Endnotes

¹ Federal Information Processing Standards, “FIPS 199 Standards for Security Categorization of Federal Information and Information Systems,” USA, February 2004, http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf
² Kepczyk, R. H.; “‘Top 20’ Cybersecurity Checklist,” American Institute of Certified Public Accountants, 7 July 2015, http://www.aicpa.org/interestareas/privatecompaniespracticesection/
qualityservicesdelivery/informationtechnology/pages/cybersecurity-checklist.aspx
³ Bramwell, J.; “Survey: Internal Auditors Making Strides on Addressing Cybersecurity Risks,” AccountingWEB, 10 March 2015, www.accountingweb.com/practice/practice-excellence/survey-internal-auditors-making-strides-on-addressing-cybersecurity
⁴ The British Standards Institution, “Performing Your Own Cyber-security Audit,” www.bsigroup.com/en-GB/Cyber-Security/Cyber-security-for-SMEs/Performing-your-own-IT-security-audit/
⁵ Galligan, M.; “For Audit Committees, a Growing Role in Cybersecurity,” Risk and Compliance Journal, 16 June 2014
⁶ National Institute of Standards and Technology, NIST Special Publications 800-53r4 and 800-53Ar4, USA, http://csrc.nist.gov/publications/PubsSPs.html
⁷ Ross, R. S.; Assessing Security and Privacy Controls in Federal Information Systems and Organizations: Building Effective Security Assessment Plans, National Institute of Standards and Technology, SP-80053A Revision 1, June 2010, USA
⁸ Op cit, Bramwell
⁹ Doran, L.; “State K-12 Cybersecurity Audit Finds Missouri District Unprepared,” Education Week, 27 April 2016, http://blogs.edweek.org/edweek/DigitalEducation/2016/04/state_k-12_cybersecurity_audit.html