CMMC, Asset Inventory, and Systems Security Engineering

You cannot protect what you do not know you have.

Systems security engineering, as a method to meet the security requirements of CMMC requires an Organization Seeking Certification (OSC) to provide the means to locate, identify, and log the inventory of assets. Organizations must also engineer methods to verify the trustworthiness of data and provide it as evidence during a CMMC assessment. This closed feedback loop helps to strengthen the hygiene of an organization seeking certification.

Yet asset inventory, from a lens of systems security engineering means, more than just counting computers. It does not end at endpoints. Inventory refers to more than even physical or logical boundaries. Management involves more than logging. You also must assess the risk these assets face. Taken together, like any element in a system, asset management requires a security first philosophy.

Many, if not all, of the CMMC domains require you to do inventory. Any time you define, identify, or list items as part of an assessment objective under a practice, good inventory matters. Basically, don’t just think about counting the things that plug into the wall. You also need to count and manage all the assets that move data in between the walls, buildings, and networks.

Companies need to apply and understand the design principles behind asset management. If an organization takes an interdisciplinary approach to asset inventory, managing anything with value, as part of overall business success rather than seeing cybersecurity see it as an IT problem the company can begin to apply systems thinking.

By applying systems security engineering to asset inventory an organization will automate many of the elements that go into good inventory, create processes for Inventory and Asset Management (IATM), design IATM from a security first principle, and account for each stage of the asset lifecycle.

Systems Security Thinking

Inventory, emerges from a system. It requires technical and non-technical processes to come together.

System engineering thinking refers to interacting elements that achieve a business goal or stated purpose. Anyone who has owned or worked in a business knows how critical inventory systems are for overall success.

If an organization places security as central to their systems thinking, where they consider the implication of any asset or system across its lifecycle the company has focused on the principles of system security engineering.

No specific CMMC practice requires companies to adopt system security engineering but in reality collecting the real time records of all the assets a company has in scope would be difficult without relying on these principles. The amount of data needed to ensure the trustworthiness of an environment handling CUI is too much for any manual attempt. Further the data collected as part of IATM influences every aspect of security such as access control.

NIST-SP-800-160 SYSTEMS SECURITY ENGINEERING: A Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems lays out ways to apply security to all assets and processes throughout a business goal.

Systems security engineering puts a security baseline as a goal for stakeholders who own a system. A system consists of different elements or assets and the assets and elements that support the system. While you can count by hand good inventory requires system security engineering.

What Goes into Inventory?

• Unique Identifier-Each asset needs its own name
• Platform type-Windows, Mac, Server
• Asset Categorization-Type of CMMC asset per scoping guidance
• Owner of asset-who is the non-privileged or privileged user of asset
• Admin of asset-Privileged employee or a third party through shared responsibility
• The applications and processes that manage the inventory of this asset
• Network Connections-ways the asset connects
• Regulations-Laws that govern this asset
• Practices/Controls Met-CMMC practices that protect the asset
• Assets role in business
• Contractual Availability-Any rules that spell out access to asset
• Assigned Maintenance-Who maintains asset or third party relationship
• Link to Maintenance Plan

Asset inventory needs to be a living document fed by automation and cared for with good policy and procedures. An Organization needs a system to automate asset discovery. They need to collect up to date information on your assets, such as patching or log-ons. Some assets, like computer programs, may come with a software bill of materials that contain important information that gets automated.

In other words a successful CMMC assessment requires that organizations understand and utilize IT Asset Management from a systems security engineering mindset.

What is IT Asset Management (ITAM)?

IT Asset Management (ITAM) applies systems security engineering principles to manage the life cycle of inventory and the entities responsible for ownership. Key aspects of ITAM programs include:

· Asset inventory – Getting a comprehensive inventory of all hardware, software, and network assets

· License management – Ensuring all assets are running properly licensed software

· Lifecycle management – Deciding which assets should be decommissioned, managing the software licenses on these assets, and updating the inventory

· Patch management – Ensuring the latest security patches are in place on all systems that need them, and understanding which systems have existing vulnerabilities that must be mitigated if no patches exist

Properly conducted, IT Asset Management will help drive cybersecurity hygiene. You must understand an organization’s topography to understand the flow of Federal Contract Information and Controlled Unclassified Information. A Certified CMMC Assessor scoping an assessment will work with clients to answer the question: “Do you know where CUI resides and how the data flows through your organization?”

Manual inventory will fail when you consider that you must count your inventory, manage any license, track the lifecycle of equipment, make sure users keep equipment patched, and know who “owns” each asset. When companies attempt to track this manually the data gets stale.

Instead IATM requires a living document based on principles of security system engineering. This living document informs vulnerability scans and attempts to access by non-authorized users.

IATM and System Security Thinking

A living document takes engineering. A systems security thinking approach to IATM requires planning and designing to prevent the loss of an asset. You must understand how to handle and recover from an incident or loss. A CMMC Assessor will want to know if an organization approaches security from a system thinking approach. A CMMC Certified Professional providing consulting services need to embed security first thinking in the design of the systems they create with an OSC.

In essence you cannot have system security thinking without applying design principles to IATM. At any given time, an Organization Seeking Certification needs to know the users connected to a system and the processes connected on behalf of those users. Patch management logs must be up to date. An OSC needs to track assets from purchase to disposal.

ITAM and Asset Lifecycle

Applying system security thinking to IATM requires you to consider security starting at blocking drip campaigns from vendors, to product evaluation, through acquisition, lifecycle management, knowledge management and more. Each in scope asset for a CMMC assessment includes business processes around agreements and acquisitions, project specific processes, technical requirements, and technical processes. In a typical lifecycle, an asset lifecycle includes the following phases:

• Enrollment
• Operation
• End-of-life

NIST-SP-800-160 lays out concepts, development, staging, production, deployment, code review, and support. For a developer contractor asset lifecycle can include code or repos. This requires a different approach to asset lifecycle than an an industrial environment where Operational Technology gets run by specialized assets with an out of date operating sytem. Other in scope organizations may provide services or support staff to the Government. The requirements and constraints of the environments will impact asset lifecycle.

The asset lifecycle while going through the three stages will focus much more heavily on the people assets. In industrial environments asset lifecycles must also include all of the out of scope operational technology and include how a company secures those assets.

Enrollment

No matter the constraints of different environments constraints enrollment may involve manual activities performed by IT staff such as assigning and tagging the asset with a serial number and barcode, loading a baseline IT image, assigning the asset to an owner, and, finally, recording the serial number as well as other attributes into a database.

An admin should manually authorize assigning an asset to an owner. Many Mobile Device Management (MDM) devices or corporate buying programs, such as those through Apple, help to automate the enrollment process and might also include primary location, hardware model, baseline IT image, and owner. This could also mean giving employees access to a code repo or a Kanban board by a project manager. As Certified CMMA Assessor you will collect evidence that makes the relationship between, IATM, asset life cycles, and access control quite evident.

Operations

As the asset goes through the operations phase, changes can occur. Such changes could include introduction of new or unauthorized software, the removal of certain critical software, or the removal of the physical asset itself from the enterprise.

When applying system security thinking to IATM we know the changes to an asset must get tracked and recorded. Therefore, asset monitoring, anomaly detection, reporting, and policy enforcement must occur in services, developer, or industrial environments. Tracking change logs is in fact a requirement for Level Two Certification. Systems thinking and asset lifecycles is critical to security and IATM.

A CMMC Certified Assessor will often rely on systems that monitor change logs and lifecycle data using installed agents that reside on the asset, as well as network-based monitoring systems that scan and capture network traffic. These monitoring systems collect data from and about the assets and send periodic reports to an analytics engine. Each monitoring system sends reports with a slightly differing emphases on aspects of these enterprise assets. Reports get collected regarding installed and licensed software, vulnerabilities, anomalous traffic (e.g., traffic to new sites or drastic changes in the volume of traffic), and policy enforcement status. Once again we have specific CMMC practices that require the collection and reduction of this dats.

End-of-Life

As an asset reaches the end of its operational life, it goes through activities within the end-of-life phase. These will differ based on the constraints of the in-scope environment. For devices across most organization this includes returning the asset to IT support for data removal. As a CCA you need to know who is responsible for overseeing the decommission of a device. Often organizations may not have an IT department, and this gets conducted by Human Resources or the CEO.

The unique identifier such as a serial number then gets removed from registration database and other associated databases such as your asset inventory. Finally, the asset is prepared for physical removal from the enterprise facility.

A CCP or CCA must know the CMMC practices associated with the end of life stage of the asset lifecycle. Especially for CUI assets. The Media Protection domain spells out specific requirements for the destruction of CUI in order to comply with CFR 32 Part 2002, the federal regulation defining CUI.

Planning for the Future: Configuration as Code

As a company engineers their IT Asset Management system they will want to automate this process as much as possible. For example, this may mean writing a Powershell script to inventory software and checking the current state of patches. Another script may get written to limit roles allowed to specific Teams meetings. Other companies may automate inventory utilizing their vulnerability scanner to count authorized devices.

Evidence collected through IATM also gets created through the system. A major goal of engineering for automated inventory is to create evidence of trustworthiness of the people and processes with authorized access to CUI. By understanding the practices that secure each asset IATM automates the collection of evidence needed to verify the procedures in a System Security Plan.

Both the automation of inventory and the collection of data benefit from system security engineering and make up an important process in the overall risk plan of an organization. Overall organizations should move to configuring IATM processes through baseline configurations. configuration as code allows those assets assigned DevOps roles to monitor and control configuration discrepancies. These efforts all come together in a reference architecture an organization builds to meet the requirements of NIST-SP-800-171 and constraints of the business environment.

The more we move to a zero trust model that authorizes at the asset level and not the boundary level through configuration as code the more secure we will all be. You still need to count what you protect. Just automate the process as much as possible.

This is the third post 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

image credit: Logistics Specialist Seaman William Swan, from Virginia Beach, Virginia, assigned to the aircraft carrier USS Gerald R. Ford (CVN 78), inventories repairable parts. flickr photo by Official U.S. Navy Imagery shared under a Creative Commons (BY) license