CMMC Weekly Series #13
Posted on July 24, 2020 by Brigham Slocum, MS
A Layman’s Guide to Security Assessment
Some Background
For those of us familiar with the world of Department of Defense (DoD) cybersecurity and its associated requirements frameworks, such as the Federal Information Security Management Act (FISMA) and its Risk Management Framework (RMF), the concept of security assessments is nothing new. We are all too familiar with Federal Information Processing Standards (FIPS) 199 and 200, the National Institute of Standards and Technology (NIST) Special Publication (SP) documents, e.g. NIST SP 800-37, NIST SP 800-53, NIST SP 800-60 (to name a few), and even the Committee on National Security Systems Instruction (CNSSI) 1253. However, there are many DoD contractors who, reading this now, are quickly turning to Google to inquire what on earth I am referencing. That said, it is outside the scope of this post to provide a detailed history of the E-Government Act of 2002, specifically Title III (FISMA), and the implications on DoD agencies, programs, systems, and system owners. Suffice it to say, FISMA requires the designation of certain officials, the implementation of an information security program, and the employment of security controls, among other things. NIST was saddled with the responsibility of developing the “standards” that would include those controls and the associated RMF framework.
One of the “control families” from NIST SP 800-53 is Security Assessment and Authorization (CA) which includes numerous controls associated with the necessary assessment and authorization processes and procedures required for a system or program to gain accreditation. In its infinite wisdom, in order to attempt to limit the mass damage that is being perpetrated by our enemies in the form of critical information exfiltration, the DoD has developed the Cybersecurity Maturity Model Certification (CMMC) framework. In the development of this framework, DoD utilized numerous existing standards to create an aggregate; seeking to take the best of each, while also considering the associated burden placed on the Defense Industrial Base (DIB). Inherently, NIST 800-53 was a primary draw of many of the controls, or as CMMC refers to them, “practices.” As such, CMMC includes practices associated with the Security Assessment (CA) domain. CMMC breaks down each domain into “capabilities” which then include certain practices associated with the various CMMC levels, i.e., 1-5. For the CA domain, CMMC contains 3 capabilities, each containing their own associated practices, which we will examine here.
Security Assessment Capabilities and Practices
CO34 – Develop and manage a security system plan
This capability includes two practices, one at level 2 and another at level 4. Let’s start with level 2. This practice requires that the contractor “Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.” Alright, it is all well and good to require a system security plan (SSP), but what on earth is an SSP? Again, for those familiar with RMF this is nothing new, but we have already established that there is a large percentage of DoD contractors who have no familiarity with these concepts. An SSP, simply put, is a single document that addresses the entirety of the security controls that are applicable to your system, program, or organization.
When speaking of RMF, the SSP would be broken down according to control family and would then proceed to address each and every control that is applicable to the system. For each control the SSP details the control requirements, the current implementation status of the control (i.e., whether it is implemented and how), and planned implementation, as applicable. In addition to the control details, the SSP should provide specifics about the system itself, such as a system description, system owner or responsible party, system environment, system boundaries and interconnections, and system status. As applied to CMMC, it is recommended that the SSP follow the domains, providing detailed status of the implementation of each capability and associated practices. If a particular practice is not implemented or not implemented fully, the SSP should address the planned implementation, which can be further addressed in a Plan of Action and Milestones (POA&M) document (we will tackle POA&Ms in the next capability associated with the CA domain).
The second practice related to this capability is required for level 4 of the CMMC and necessitates that the contractor “Create, maintain, and leverage a security strategy and roadmap for organizational cybersecurity improvement.” This practice presents itself as fairly straightforward: the organization ought to develop and use a strategy (concrete plan) to constantly improve its cybersecurity posture. Although this practice finds itself at the higher levels of CMMC, it ought to be considered a best practice that, frankly, every organization should be striving to implement.
C035 – Define and manage controls
This next capability for the CA domain presents the most practices. CO35 defines two separate practices at CMMC level 2, one at level 3, and two at level 4. Here again, let’s start at level 2 and work towards the more rigorous. Practice CA.2.158 requires that the contractor “Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.” Once an organization determines the applicable controls, develops, and actualizes processes for implementation, and develops the necessary SSP they cannot simply stop. An organization and its associated information systems can be likened to a developing child; they grow and change, even at physical maturity, we understand that we all continue to change according to our life experiences and outside environmental factors.
The same is true for our organizations, including our employees and our information systems. They grow, develop, require updates, new additions, changes to address new “outside environmental factors” (developing threats). In order for any organization to ensure the continued security of their systems and information they need to, first, understand this concept, second, regularly assess the status of their systems and security controls, and third, provide the necessary updates, changes, and mitigations. These periodic assessments ought to include the means to assess technical controls (such as compliance and vulnerability scanning, penetration testing, and threat hunting) as well as methods to address management and operational controls, such as documentation review, personnel interviews, site checks, etc. Periodic assessments are commendable, but they only provide the information. How do we fix the “issues” that an assessment may present?
This brings us to the second practice associated with this capability at CMMC level 2. Practice CA.2.159 presents the contractor with the responsibility to “Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.” This practice provides the means to address the updates and growth necessary for any organization and system. It requires the contractor to address the flaws that inevitably present themselves during the periodic assessments. This practice refers to what I mentioned earlier and what is used in RMF, the POA&M. In layman’s terms, this requires that for each vulnerability found during an assessment, the organization develop and implement a concrete plan to mitigate or remediate that vulnerability. This plan (POA&M) ought to include the requirement, the non-compliant or vulnerability finding, the remediation plan, the responsible party, and the proposed completion date. The POA&M can act as the central repository of necessary mitigation actions, while an organization might develop separate action plans that can be delegated to appropriate parties and/or departments. However, it is recommended that there be a single manager for the POA&M and the status of all items – this way there is a single point of contact, who is tracking status and can follow-up with responsible parties to ensure findings are properly addressed.
Please note that the CMMC framework does not allow for POA&Ms when attempting to achieve a certain level of certification; in other words, if you are attempting to obtain level 3 certification and some of the required practices are not met, an organization cannot choose to POA&M these controls and still gain certification. In order to achieve any particular CMMC level, ALL practices must be implemented. Above I am recommending the use of a POA&M for internal cybersecurity maturity, where it is used to track items that an organization hopes to correct or milestones it hopes to achieve. It also might be used when an organization is working toward a higher level of CMMC, where the POA&M is an internal tracking tool to monitor those practices that are planned but not yet fully implemented.
At level 3, capability CO35 includes a single practice that requires the contractor to “Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.” At first glance this might seem to be the same as periodic assessment, however it is not. This practice refers to what RMF calls “continuous monitoring.” This requirement could mean something as detailed as a Security Operations Center (SOC) which is manned 24×7 providing continuous monitoring, auditing, logging, correlation, alerting, etc. of an information system(s). However, in the vast majority of circumstances this will not be the case and the use of a SOC will far outweigh any security requirement (although there are CMMC practices requiring SOCs and there are organizations who maintain such sensitive information or necessary systems that a SOC is required).
It is much more likely that the organization will be able to meet this practice and ensure the security of its systems and information through the use of logging software and operating system related utilities or even the use of a Security Event and Information Management (SEIM) tool. For many organizations even a SEIM might be more than is necessary; but at the least, all organizations ought to configure the native operating systems to provide the most robust auditing and logging possible, while also allowing for daily operations. In addition to auditing and logging, this practice should encompass recurring system scanning and manual review. There are numerous tools available to accomplish this task, such as Nessus, Nexpose, Retina, and Nikto2 and most (if not all) can be configured to scan for vulnerabilities as well as compliance (i.e. scanning a system against a baseline configuration to ensure compliance with said configuration). In addition to automated scanning, it is recommended that periodic manual review of system samples be completed to provide another layer of assurance.
Now we proceed to level 4 of capability CO35, which contains 2 practices; the first requires the contractor to “Conduct penetration testing periodically, leveraging automated scanning tools and ad hoc tests using human experts.” Although this practice rests at level 4 of the CMMC, a level that most contractors will not require or attempt to maintain, it is a recommended practice to conduct, at least occasionally, penetration testing activities at your organization. Penetration testing helps reveal an organization’s security shortcomings by using advanced tools, techniques, and procedures to exploit vulnerable services and bypass security misconfigurations. A penetration test can help find security deficiencies often missed by traditional security reviews as well as show the real-life impact of vulnerabilities. In addition, penetration tests can be tailored towards an organization’s needs and security maturity.
These tests, even for an organization not seeking CMMC level 4, might be done annually during one of the periodic assessments performed on a system. Since many DIB contractors will require third party support to conduct assessment procedures (i.e., scanning, doc review, manual assessment, interviews), the addition of a penetration test might prove to be less cost prohibitive than initially thought, if added to a service already being provided. Additionally, a well conducted penetration test can provide invaluable insight and even help avoid future expenditures since it might prevent compromise down the road, which will surely present a greater cost to any organization, both monetarily and reputationally.
The final practice associated with this capability goes a step further than the one we just discussed. Practice CA.4.227 necessitates that the contractor “Periodically perform red teaming against organizational assets in order to validate defensive capabilities.” Although it was recommended that every organization, whether required to or not, perform occasional penetration testing activities, red team engagements are likely beyond the security requirements of most organizations. That said, for an organization seeking CMMC levels 4 or 5, or for any organization that considers its systems and/or information meriting this level of security, a red team engagement can provide unique and valuable insight into security vulnerabilities and strengths, and help develop a roadmap to an highly improved posture.
Precisely due to the fact that red teaming is a full-scope, multi-layered attack simulation designed to measure how well an organization’s people and networks, applications and physical security controls can withstand an attack from a real-life adversary, it will result in an untold wealth of knowledge. Although most firms will not require this level of testing, a penetration test could be utilized in a similar manner but on a more limited scale; an example of this might be a phishing campaign, where the tester would simulate a malicious actor and present an advanced phishing operation against unaware organizational personnel.
CO36 – Perform Code Review
The last capability in the CA domain is comprised of a single practice at level 3 and, likely, will not apply to the vast majority of DIB contractors. This is the case because this capability deals with software code review and the practice requires that contractors “Employ a security assessment of enterprise software that has been developed internally, for internal use, and that has been organizationally defined as an area of risk.” Upon reading the practice one will likely understand why it will not be applicable to many, since most of us utilize commercial off the shelf (COTS) utilities, both software and hardware. However, for any organization developing its own software, in this case for internal use, this practice presents not only a requirement but a best practice as well. Just as information security ought to be built into our COTS system configurations and every aspect of our organizational infrastructure, so too it needs to be incorporated into any software development lifecycle.
Although this practice simply requires the assessment of internally developed software (for internal use) that has been defined as an area of risk, it is not only prudent but necessary that the contractor go a step further and develop a security program applicable to the software development lifecycle. This ought to include a security expert involved at every step, from design to deployment, with recurring testing throughout the process to ensure that, at deployment, the software will function according to the control criteria initially intended. As part of this process, the organization should implement recurring security testing post deployment to ensure continued secure functionality and operation.
In Conclusion
As mentioned at the start of this post, anyone familiar with DoD cybersecurity and the associated security and compliance frameworks will be no stranger to the Security Assessment domain. However, it is my hope that for those less familiar with these concepts this post might provide some small insight into industry best practices and even some guidance for the implementation of the associated capabilities and practices. There is a great deal more that could be said about the intricacies of developing an SSP, or the implementation of continuous monitoring tools and techniques, not to mention the ins and outs of penetration testing and red team engagements. However, a deep dive into each of these topics could be a blog post in and of itself. The above information is intended to flesh out some of the overarching concepts and guiding principles associated with the requirements of the CA domain.
Finally, we would all do well to remember that although these practices might be required by the CMMC framework in order to obtain certification and for an organization to maintain the ability to bid on DoD work, in fact, these controls apply to a far greater population than just the DIB. It is not only DoD contractors who retain sensitive information or maintain vital systems. Numerous industries such as health, finance, and the academic world must ensure the security of their information and the systems on which this information resides. Here again, as mentioned several times above, due diligence necessitates that all organizations, whether within the DIB or not, who retain any sort of sensitive information or maintain an information system that requires continued availability, seek to implement these practices (or some other similar information security framework) in order to provide some assurance of confidentiality, integrity, and availability, whether required to or not.
