System Security Engineering and CMMC

Every organization has a philosophy behind their system security plan.

These may range from an idea that, “Compliance is not security,” to “DFARS is an unfunded mandate, “ or ” “CMMC did this to me.”

Other organizations may have their SSP reviewed on a quarterly timeline, and they have biweekly security meetings to analyze any changing threats or to address open items in a plan of action. Even with no full time IT staff the CEO may have made security a central system principle. Another organization may be moving their technology to designs based zero-trust architecture.

These leaders made a philosophical choice.

The organizations they lead have designed a security program explicitly or implicitly utilizing the principles laid out “NIST-AP-800-160 Systems Security Engineering Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems” published by NIST.

Philosophy and Cybersecurity

Choosing a design such as zero trust and then applying systems thinking is a philosophical choice. Apathy, or willful ignorance, is also a philosophical choice. Both will impact the assets and opportunities for an organization.

When evaluating whether to adopt or change a computing environment to meet the requirements of NIST-SP-800-171 a company needs to consider the impact to business outcomes at every stage of the system lifecycle and the processes that lead to profits.

A large company with contracts across many different federal agency may choose a hybrid deployment where users access assets in the cloud, servers and software somewhere else, but any software handling authorization runs “onprem,” a server located at the business and maintained by IT.

Another company may sell software and they connect to a cloud through VDI. No matter the deployment each company must meet the same security requirements. Everyone must demonstrate compliance with NIST-SP-800-171 through a CMMC assessment. Applying systems thinking ensures that when a system or asset gets authorized, we can trust the security.

Systems Thinking

Systems thinking is a lifecycle approach to examine each stage as contributing to an overall goal. Usually this goal is a business output that should result in a profit after margins get considered. Systems thinking leads to the development of a common mindset for any system.

Systems thinking drives outcome-oriented results and utilizes an iterative engineering process to deal with the complexity of business. Systems engineering, driven by this thinking, is data- and analytics-driven to create metrics to inform decision making. When comparing cloud, on-prem, or hybrid environments, for example, a company needs to consider the impact on all other systems within the organization.

In turn, regardless of choice in environment, we must consider how any asset impacts security while also embedding requirements at each stage of the asset or system’s lifecycle.

System Security Engineering

Systems Security Engineering, when layered on top of engineering systems, creates a “system of systems” that helps to increase the “trustworthiness” that an organization meets the 320 security requirements in the 110 practices of NIST-SP-800-171.

Basically the security concerns of any system and the assets that make up those system get integrated into the technical and nontechnical processes. Security becomes part of the philosophy built into all systems. This in turn leads institutionalizing of security and the use of security as a proactive contributor, and not just a cost, to the business outcomes.

Lifecycle of System Security Engineering

Regardless of the chosen computing environment a design philosophy requires an organization to establish a lifecycle for their System Security Plan. Like any system the SSP, which lays out how you meet the security requirements of NIST-SP-800-171.

Through engineering thinking we move the security of a system to an asset from a problem to a solution state while increasing the trustworthiness through deployment. At each stage an organization analyzes the security impacts to understand the security requirements, collect relevant data, align to business outcomes, and ensure fidelity for deployment.

A company’s risk-based security plan, acts as a system of systems on systems that integrate with all other systems in a business. Within that system the trustworthiness of evidence that the security requirements of NIST-SP800-171 get tracked in the SSP, or system security plan.

The SSP needs to be seen as a living document that reflects the security design philosophy while producing evidence of trustworthiness. An organization should consider the SSP and Plan of Action and Milestone on an organizationally defined timeframe such as six months.

When the time period elapses the system gets evaluated against the security requirements of NIST-SP-800-171 and a POAM gets published and triaged. Once the CMMC rule goes live in DFARS the allowable time on the POAM will not exceed 180 days and can only apply to a limited number of practices.

The System Security Plan

The SSP must act as a tool in the feedback loop of systems security engineering. You begin by first collecting all the security requirements of different assets. What laws and regulations govern these requirements? You then map, in the instance of complying with 171, how CUI data flows your system and create separation between in scope and out of scope assets. This is the problem context.

Once organizations have an understanding of assets they can then build out a reference architecture and complete an SSP and POAM. You implement technical solutions through policy and procedure that align to your design philosophy. This is the solution context

Following an initial publishing, or an update of the SSP and POAM if a new system is introduced the closed feedback loop kicks in. Having a C3PAO come in to complete a third party assessment adds the trustworthiness component to systems security engineering.

System Security Engineering and Compliance

No CMMC practice or assessment objective from NIST-SP-800-171a requires you to utilize system security engineering in efforts to comply with DFARS requirement. Yet companies who apply a security first principle from acquisition security tools to verification of customer receipt will have an easier time working with a C3PAO on a CMMC assessment.

System security engineering by its nature creates evidence of persistent and habitual application of CMMC practices. Having a plethora of evidence to choose from will help a C3PAO evaluate an OSC on any number of practices.

System Security Engineering requires organizations to consider their outcomes and constraints. Organizations then create policy to ensure regulation while planning and allocating resources for deployment. The baseline architecture, risks, and mitigation plans get communicated to in-scope people trained as part of the system.

We can not assess for best practice in cybersecurity. Cloud, on-prem, or hybrid. No one solution rules them all. Instead, we need to engineer for better practices given the local environments and contracting restraints.

When security becomes a first principle in this cycle everyone wins.