Systems security engineering, establishing security by considering the problem, solution, and trustworthiness of all key components in a business, begins with stakeholder interest and the business outcomes.

A business that cannot turn a profit cannot remain a business for long. This remains the greatest risk to the system and drives decision making. Business owners have assets, people, technology, and facilities with value that have costs, bring in revenue and that present risk. A risk-based approach must get applied to protect these assets.

We must consider security as a tangible asset, and not a cost constraint in a system we engineer. How we engineer security into the requirements of other assets depends on how we categorize the asset and the risk it faces.


Systems security engineering utilizing a risk management framework require us to consider assets at three levels.

three tier system of RMF

As an organization meets the security requirements of NIST-SP-800-171 they make continuous improvement in the organization’s risk-related activities across three different tiers. Tier one is the organizational level and sets the governance necessary to engineer secure systems. It includes the organization risks of profit and loss and decisions about investment in security as an asset.

In tier 2 the work gets done. It represents the mission/business processes a business relies on. This also includes how Controlled Unclassified Information, and all data moves through a system. Processes must be in place to meet security requirements. At this tier you deploy Inventory and Asset Management System and the reference architecture built to a baseline.

Tier three represents the information systems that enable the business processes to occur based on the governance and risk established. This includes many of the continuous systems that exist throughout their life cycle. Security requirements that align to the risk set in tier and utilizing the processes of tier two get met in order to protect assets that move through an information system.

Assets, anything with defined value, will exist at all three tiers. Security requirements, constraints, and in-scope assets of a CMMC assessment will exist across all three tiers.

By utilizing Systems Security Thinking from a risk management framework an organization seeking certification can engineer Inventory and Asset Management systems that help to increase the trustworthiness of asset categorization through automation and continuous monitoring.


Organizations who engineer security using proactive and reactive loss prevention will not only have better security, but they also control the cost and ease of a CMMC Assessment.

The goal of systems security thinking is to develop immutable architecture through baseline enforcement, moving access controls more from the boundary to the asset identity, and deploying continuous monitoring through automation and machine-based scanning.

Design based thinking requires establishing a baseline and we begin with inventory and asset categorization. Once security-based solutions for asset inventory get engineered a company should begin on asset categorization. In fact systems security engineering, and not just a NIST-SP-800-171 assessment, rely on asset categorization:

This means proactively planning and designing to prevent the loss of an asset that you are not willing to accept; to be able to minimize the consequences should such a loss occur; and to be in an informed position to reactively recover from the loss when it does happen.

For CMMC Level 1, only assets classified as FCI are considered in scope.

CMMC Level 2 assessments are conducted when an organization transmits, stores, or processes CUI. Often these organizations also have FCI. If an organization, for example, uses two different enclaves – one for FCI and one for CUI – then they will need two different assessments. If the FCI and CUI get comingled in the same system, an OSC should seek a single assessment from a C3PAO.

A Certified CMMC Professional, can help companies with complex systems and small budgets save money if they can categorize assets as either in-scope or out-of-scope. A CCA will want to understand how asset categorization fits within an organizations Inventory Asset Management policies and procedures. There are specific controls that require any authorized user to be tracked and for attempts at unauthorized access to get logged.

More importantly, in a CMMC assessment not all assets fall in scope. The scope of the people, technology, and facilities will change at the three different tiers of risk management. At each level you will have users with more privileges than others. You will have assets that require greater protections. Policies need to be accounted for in level one, reference architecture at level two and fine grain security requirements down to the last endpoint at level three. Any assets in the system must get categorized, the security requirements identified, and their life cycle documented.

This requires serious counting and then organizing what gets counted.

Sometimes an organization’s assets are such that it is more economical to grow the scope so that the entire company is a controlled environment rather than trying to limit the scope to one or more enclaves. This holds especially true for many small manufacturers who cannot add separation between CUI assets and normal business practices, such as by using an Enterprise Resource Planning (ERP) tool.

A CCP, will work with companies to develop their asset inventory to provide details of the assets the company owns. This can cover a range of asset types, from tangible fixed assets such as property and equipment, to intangible assets such as intellectual property. An assessment team member, CCP, CCA, or Leader assessor will use the asset inventory and categorizations to verify the scope of the environment and to scope the assessment.

But within the asset categorization you must think behind the wall. Physical asset management systems can tell you the location of a computer, but cannot answer questions like:

“What operating systems are our laptops running?”

“Which devices are vulnerable to the latest threat?”

Effective ITAM solutions, driven by asset categorization, tie physical and virtual assets together, and provide management with a complete picture of what, where, and how assets are used. ITAM enhances visibility for security analysts, which leads to better asset utilization and overall system security.

People, technology, and facilities can be in scope as any of the five asset categories at the three tiers of the system. At tier one policies inform the configuration management. The authorized holder of the CUI will have a privileged role. People with incident response and disaster recovery will also have privileged roles. Elevated assets often fall in scope.

At tier two you need to categories any configuration management procedures of in scope assets. Baselines, reference architecture, and threat monitoring procedures exist at this level. Privileged users will collect data about risk to assets and pass that up to in scope people in tier one.

At tier three all the people, facilities, and technology that make up your system need to meet the security requirements. Most of the assets categorized for a CMMC assessment will exist at this level. This includes every endpoint, training records, key physical and logical boundaries. You may have systems to separate out of scope assets from CUI.

asset categorization across three tiers

In security systems engineering the in scope assets exist at mainly at level one, the procedures to secure those assets exist at level two. The data about the current state of the asset and its lifecycle get pushed back up to threat monitoring at level two. If an adverse risk is noted the policies and regulations categorized in tier one kick in.

As an organization engineers asset categorization into their Inventory and Asset Management systems they need to consider if the labeling will happen manually, automatically, or at provenance of the asset. Manual means someone physically has to enroll and de-enroll an asset from the system. Even with automation good security practices require manual authorization for an asset to first connect to a system. Your key boundaries will also exist and need protection at the third tier. People who maintain the security and all in scope users will need specific training. None of this can happen without categorizing assets based on risk.

In terms of determining the scope of a CMMC assessment we must think about five types of assets.

  • Control Unclassified Information Assets-Assets that process, store, or transmit CUI.
  • Security Protection Assets-Assets that provide security functions or capabilities to the contractor’s CMMC assessment scope even if these assets do not store or transmit CUI.
  • Contractor Risk Managed Assets-Assets that can, but are not intended to, process, store, or transmit CUI because of security policy, procedures and practices in place.
  • Specialized Assets-Assets that may or may not process, store, or transmit but are out of scope of CMMC beyond documenting risk mitigation in the SSP through security policy, procedures and practices.
  • Out of Scope Assets-Assets that cannot process, store, or transmit CUI.


Controlled Unclassified Information assets make up the heart of a CMMC assessment. Any asset categorization system should attempt to identify CUI to ensure it meets the security requirements spelled out in DFARS.

NARA has identified many categories of CUI but a contractor in the Defense space will mainly handle controlled technical information, critical infrastructure security information, naval nuclear propulsion, and unclassified controlled nuclear information.

If the contractor sells a commercial off the shelf product it is not Controlled Unclassified Information. COTS can still come with export controls and be considered ITAR and need to meet security requirements from the State Departmnt but this would be out of scope of a CMMC assessment. Next an organization seeking certification needs to determine if the data gets created, processed, transmitted, or stored is the result of a contract with the DFARS 252.204-7012 clause. Without this clause you do not handle CUI on behalf on a Defense contract. If you receive CUI as a result of a contract without this clause you have no security or incident reporting requirements.

Most CUI will not get labeled. The data labeled or unlabeled, by being controlled unclassified information, is controlled by some federal law or regulation. Your next step is to examine any assets with limited distribution statements of that is considered ITAR. Any ITAR or data marked for limited access because of a contract with the 7012 clause is almost always CUI.

Asset categorization must pay particular attention to CUI assets if an organization is trying to use enclaves or to keep out of scope assets separated from CUI. You will want to categorize the people who have authorized access to the CUI. You also need to count the things that protect CUI


We must also consider the Security Protection Assets (SPA). These are all of the cybersecurity hardware and software a company uses and pays for to protect their systems. A CCA may fail an Organization Seeking Certification if SPAs go unaccounted and thus unpatched. Your cybersecurity, or SPA inventory should:

  • Gather data from any source that provides detailed information about assets
  • Correlate that data to generate a view of every asset and what is on it
  • Continually validate every asset’s adherence to the overall security policy
  • Create automatic, triggered actions whenever an asset deviates from that security policy

Automated asset management has significant advantages over manual asset inventory. Mainly, all your data lives in one place rather than in a variety of spreadsheets, clipboards, or bar code systems. Warranties, receipts, user manuals, STIGS, and baseline configurations get stored in one place. As a CCP, you should help a company inventory all of the important documentation required for all five types of CMMC asset categories.

An Assessment Team member, whether a CCP or a CCA , will assess if an organization uses asset inventory software, or build procedures into their existing systems. They will check on the ability to schedule maintenance automatically. A CCA will make sure Patching gets included in the lifecycle of a SPA.

For example, in environments that use a commercial cloud organization may use configuration management tools. These cloud services allow you to write, manage, and compile to create a Desired State Configuration (DSC). The inventory features built into built into these tools allows for tracking of virtual machines hosted in commercial clouds, on-premises, and other cloud environments. As part of Inventory and Asset Management lifecycles assets get tracked using these scripts. This asset therefore provides security protection to CUI assets and gets categorized as in scope. If you mess with the scripts that count and categorize assets a threat can hide their tracks.

Many inventory software systems, especially mobile device management tools, allow privileged users to perform remote updates and inspections of IT assets. You can inventory devices such as laptops or tablets. This saves the IT staff valuable time and resources. Most manual inventory processes end up hurting the company’s bottom line because the IT staff could be better using their time in support of the IT infrastructure. Other organizations may have no IT staff at all.

Inventory software helps to reduce loss through theft of valuable assets via physical verification and tagging of fixed assets. This, in turn, helps to protect the confidentiality of CUI – the goal of the CMMC program. Asset inventory software can produce the most accurate inventory. Discrepancies get identified and resolved quicker and cheaper than by manual methods. CCPs may want to consider doing assessments and contracts especially around the automation of ITAM.


Contractor Risk Managed Assets can process, store, or transmit CUI but an organization plans to keep CUI out of these assets. This requires an inventory of the security policy, procedures, and practices in place to protect these assets NIST-SP-800-171 is neither a framework or a security plan. A CMMC assessment only verifies that you meet the security requirements of NIST-SP-800-171 to protect the confidentiality of CUI. You will need a risk based security plan to categorize CRMA. Contractor Risk Managed Assets are not required to be physically or logically separated from CUI Assets.

They are part of the CMMC Assessment Scope. These assets just get managed using the contractor’s risk-based information security policy, procedures, and practices that sit above CMMC in the tier one of the system. If properly categorized CRMA and are not assessed against CMMC practices.

Facilities may often fall under contractor risk managed access as ab organization may not own the building or utilities coming inside. A conference room, for example, may hold meetings that process CUI. This CUI then gets locked away and protected by one physical barrier. The lockbox is inscope but the conference room is a risk managed asset.


Specialized assets may or may not process, store, or transmit Controlled Unclassified Information. If they do handle CUI the asset must provide a very specialized function. It should configured to do just that one function and if possible be physically or logically separated from in scope systems. Internet of Things, Operational Technology, Restricted Information systems, Government property, and test equipment get excluded.

An asset categorization system must account for specialized assets. The security plan must detail how an organization accounts and controls the risk to the asset. In essence specialized assets require tailoring from a Risk Management Framework from NIST-SP-800-37 and 39 using Systems Security Engineering in NIST-SP-800-160. When you have a highly specialized asset you tailor a set of controls if the asset can not not meet the required security baseline.


Out of scope assets do not handle CUI. They are not in scope of a CMMC assessment. Your asset categorization however should account for any asset. Remember an asset is defined as anything with value. If something has worth and organization should count it. Adversaries want to steal your IP and PII as much, if not more, than Controlled Unclassified Information


A CCP or CCA need to work with your clients on identifying data flow within their companies and understanding how this data flow impacts the five asset categories of a CMMC assessment. This will be essential when scoping the assessment.

An implentor will want to work with clients to leverage their existing expertise and systems for inventory to help them automate IT Asset Management. A Certified CMMC Assessor will want to work with organization that have effective asset categorization.

On Microsoft Systems a CCA will often analyze evidence collected using Azure Automation. Asset categorization and Inventory Asset Management may occur Microsoft Defender. In Apple environments people may use a third party vendor such as JAMF to only install approved apps. Other organizations may drive their inventory through a SIEM and vulnerability scanning.

Long term, once the risk based analysis is completed, the assets inventoried and categorizes Systems Security Engineering will drive us to a baseline and reference architecture. Categorizing assets across the lifecycle of deployment enables this goal. At the same time good reference architecture will help to automate asset categorization.

This is the sixth post on a series on using NIST-SP-800-160 Systems Security Engineering to meet the requirements of SC.L2-3.13.2 – SECURITY ENGINEERING

Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.

First post: Evaluating Organizations Seeking Certifcation: Document Based Requirements to Start a Conversation

Second Post: CMMC and Systems Security Engineering

Third Post: CMMC and Asset Inventory

Fourth Post: CMMC Assessment: In Systems Security Engineering the Environment Drives Evidence

Fifth Post: shared under a Creative Commons (BY-SA) license by jgmac1106 shared under a Creative Commons (BY-SA) license