Goodbye CMMC 1.0, Hello CMMC 2.0

In November of 2021, the Department of Defense announced a major overhaul to the Cybersecurity Maturity Model Certification (CMMC) program. The nascent cybersecurity compliance program came under criticism from the defense industrial base (DIB) because of its extensive requirements and onerous penalties.

The program changes come as a result of an extensive internal review which was prompted by over 850 public comments regarding the CMMC during the public comment period in the Fall of 2020 in addition to concerns raised by Congress.

The CMMC Accreditation Body (AB) held a Townhall this week to discuss how the changes will impact the process of certifying assessors, training requirements, and more. This Townhall featured Deputy Assistant Secretary of Defense Jesse A. Salazar, Deputy DoD Chief Information Officer for Cybersecurity David McKeown, and Buddy Dees of the CMMC Program Management Office. They reinforced much of the new information that is available on the CMMC website.

A key driver for the change, they said, was to fully align the CMMC with National Institute of Standards and Technology (NIST) cybersecurity standards, to ease the process of expanding the program across the government. Though not an official announcement, it does portend the expansion of the program outside of DoD.

Read Our Full Summary of CMMC Program Changes >

AC.L1-3.1.1

(source: CMMC ML-1 Assessment Guide)

Overview of AC.L1-3.1.1

Despite having six Assessment Objectives, it is useful to think of this practice as having two overall requirements:

1. Organizations need to know of all user accounts, whether they are associated with a person [a], service [b], or a device [c], that can connect to in-scope systems/data.
2. Organizations need to limit access of those user accounts to authorized users [d, e, f].

Assessment Objectives [a], [b], and [c] only differ from each other in the type of account to which they refer.

• [a] refers to accounts that relate to people, i.e., employees and contractors of the entity.
• [b] refers to processes acting on behalf of authorized users. An example of this is a service account. For example, let’s say you have an application on your corporate network that can export Adobe Acrobat (PDF) files to a shared folder. It is likely that the application will require rights to the network to write those PDF files, and those rights will be granted via a user account. Other examples may include accounts that are used to process backup jobs, database operations, and network security functions.
• [c] is a catch-all for all other accounts not captured in [a] or [b], though its names printers in the Assessment Guide’s Further Discussion. In this context, multi-function scanners and printers frequently can email attachments or write files to networks. The accounts used by these devices to accomplish those tasks must also be known to the entity.

Assessment Objectives [d], [e], and [f] only differ from each other in the type of account to which they refer. Additionally, whereas [a], [b], and [c] describe organization requirements to know all of the authorized accounts, [d], [e], and [f] provide for the control requirements around those accounts.

When it comes to access authorization, organizations should have controls over four key areas:

1. New account access
2. Disabled account access
3. Access modifications
4. Periodic access reviews

New Account Access

Organizations should have a documented process to authorize new users prior to granting them access to networks and systems. This should apply to ALL new accounts, including human users [d], service accounts [e], and devices [f].

A new user access process should feature documented requests and approvals being provided to a system administrator, who then grants the access in accordance with the request. The documentation should clearly indicate the level of access (roles, permissions, etc.) that the user should be granted, and should be maintained so that it can be provided to a CMMC assessor. The most common example for most organizations will be new employee access, but the process should function for service accounts and devices as well. In these cases, the need for the account would be both generated and granted by IT. So, to avoid any single person from requesting, approving, and granting access, we recommend that accounts created by IT be approved by a senior IT official, a COO, or CEO, depending on the size of the organization.

Common Pitfall

Organizations going through compliance efforts for the first time frequently have multiple departments with individuals responsible for granting access to different systems. We often see organizations where IT departments are responsible for granting access to infrastructure systems like networks and email, and service delivery teams are responsible for granting access to the specialized software used to service clients. In our experience, organizations that can consolidate the compliance responsibilities for access controls to as few departments as possible have the most success.

Disabled Account Access

Organizations should have a documented process to ensure that employees who no longer need access have their access deactivated in a timely fashion. This is especially important when employees leave a company. Typically, an employee separation is communicated by the HR Department to the IT Department, and from there the IT department is responsible for disabling the employee’s access. If multiple company departments manage employee access to systems, then the HR Department will have to communicate the separation to every person or team that controls access for the employee. We recommend disabling employee access on or before the end of their last day. As an extra layer of precaution, for employees who are being terminated for cause, we recommend disabling all their access before they are notified that their employment is being terminated.

Access Modifications

Organizations should also have a process in place to increase and decrease account access as the employee’s job responsibilities change. If the employee transfers from one department to another, an official request and approval should be provided to the IT department and other system owners to ensure that access is adjusted as necessary.

Key to Success

IT auditors prefer to have system generated populations whenever they are available. Related to access control, organizations should be able to generate system generated lists that show new users, disabled users, and modified users. These populations should provide the timestamp that the change took place. With these populations, your assessor is likely to select a sample of the items on that list to ensure that access was granted/modified after it was approved, and that access was disabled for former employees on or before their last day.

Periodic Access Reviews

Each of the processes described so far are manual processes, and as such, they are susceptible to human error. Additionally, they are considered “preventative controls” designed to prevent people from obtaining or retaining unauthorized access. Preventative manual controls should be supplemented with “detective” controls to find instances where something slipped through the cracks. In the context of user access, if someone makes a mistake, e.g., a HR Team member forgets to communicate an employee separation to a system administrator, organizations should have processes in place to detect and correct those issues. Most organizations with detective user access controls implement a quarterly user access review. Although there is variability in exactly how such a review is structured, we generally see processes where system owners generate or are provided system generated lists of users and their corresponding access levels. The system owners then review the access to ensure that no terminated employees or terminated vendors appear on the list and the current access levels for users are appropriate. If access is inappropriate, the system owner would notate as such in the review and submit a request for change to the system administrator.

Because the CMMC specifically identifies service accounts and device accounts, this review should include those accounts as well.

Conclusion

“If it wasn’t documented, it didn’t happen.” This is the approach auditors of all stripes take to their work. If a user was granted access, but there is no evidence of approval, someone’s recollection that they called the IT team will not be sufficient. To comply with the CMMC’s requirements for AC.L1-3.1.1, organizations will need to quickly implement rigorous access approval, disabling, and review processes, document everything, and ensure they can create complete, system generated population reports.

For many organizations used to handling requests such as these over the phone, in person, or over email, there will likely be a bit of a culture shock. Employees are guaranteed to be frustrated when IT staff tell people to “fill out a form and get it approved” before they can grant access. Management must ensure they fully support IT and communicate the importance of compliance to the entire company.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide AC.L1-3.1.1

AC.L1-3.1.2

(source: CMMC ML-1 Assessment Guide)

Overview of AC.L1-3.1.2

This practice and the related Assessment Objectives set forth requirements that restrict user access based on the users’ needs. For most systems, this simply means that users are given access to systems via roles, and those roles are aligned to access rights.

Example of how a Defense contractor might implement practice AC.L1-3.1.2

A contractor provides security services to DoD facilities. The services are managed in a Security Services Management System (SSMS). Each contract that is awarded relates to an individual campus at which the services are provided. A single contractor Security Services Manager is in charge of each campus, and the security personnel at each campus do not rotate between campuses. Overseeing all of Security Services is the Director of Security Services. Given that structure, the SSMS has the following roles and structure:

Given the above example, it should be apparent how system permissions should be structured to comply with the practices. Ideally a system has roles for which the individual permissions are assigned and then individuals are assigned to a role based on their job responsibilities. In the above example, all the work could be performed if all service staff had the “Services Lead” role, but that would be excessive to what everyone needs, unnecessarily increasing the risk of unintended data loss.

Note: This is subtly different from AC.2.007 – an ML 3 requirement – that relates to the principle of least privilege.

Systems can be limited in a variety of ways other than role. For example, system access could be limited to certain times of day, days of the week, geographic location, etc.

Key to Success

Many organizations that have not had compliance requirements in the past enjoy loose data controls, with FCI and CUI stored in a semi-organized manner without many access restrictions within the company or department. Complying with the CMMC, however, will require changes. Organizations with data spread throughout a network will likely need to undertake a data cleanup effort. FCI and CUI should be consolidated into as few systems and locations as possible, and access should be restricted based on role. This effort will likely yield benefits because it will shrink the rest of your compliance efforts. For example, if you reduce the number of in-scope systems from five to three, and network folders from 25 to five, you have vastly decreased the ongoing compliance effort required to obtain and maintain your certification.

It is common for many companies to store FCI and CUI in shared drives on an Active Directory based network or cloud service, such as OneDrive or SharePoint. Companies with such requirements should leverage Active Directory Security Groups to limit access to FCI and CUI to only the employees who need access to the given data. For example, a consulting company provides Aircraft Survivability studies and Missile Defense analysis, and much of the analysis generated resides in shared network folders. The company should consider creating an Active Directory Security Group for the Aircraft Survivability Team and one for the Missile Defense Analysis Team. They should restrict access to their given work products to only the engineers on the given team.

It is also important to consider direct access to supporting databases. For example, if team members use data analysis tools to examine data in a database, those users might require user accounts to the database itself. Because they only need to read the data in the database, their database roles should be restricted to read only, rather than also having access to write, modify, or delete data.

Conclusion

System users should not all have rights to perform all types of transactions. All in-scope systems and networks will be required to have the ability to limit access to data and the functions of the system. Ideally, this will be accomplished with system roles that grant access to certain functions and data.
Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide AC.L1-3.1.2

AC.L1-3.1.20

(source: CMMC ML-1 Assessment Guide)

Overview of AC.L1-3.1.20

AC.L1-3.1.20 focuses on controls around external systems that you use and that connect to your in-scope systems. The Assessment Objectives clearly identify a distinction between “connections to” and “the use of” external systems.

External system refers to systems or a component of a system that an entity does not control.

Connections to external systems refers network connections between your organization and external systems, for example where industry partners, subcontractors, and others might need to connect to your logistics system.

The use of external systems refers to systems to which an organization allows it employees to connect. The Assessment Guide specifically mentions personally owned devices connecting to corporate resources.

Connections to and the use of each have three requirements:

• That they be identified
• That they be verified
• That they be controlled/limited

Identification and verification are subtly different, and in most cases, they will go hand in hand. Simply put, this will require the organization to have documented knowledge of (identified) and authorized (verified) the use of external systems, which employees may connect to or which may connect to the company’s network. For example, if an employee uses a VPN to connect to the company network, is that connection known to the technology team and has it been approved?

Key to Success
To demonstrate compliance with AC.L1-3.1.20 more readily, organizations should consider centralizing an inventory of external systems, the nature of the connection (inbound/outbound/port/protocol/etc.), the approval for the connection, and a description of any technical controls that may be implemented to limit/control the use of or the connection to the external system.

Controlling and limiting connections could be any of a large variety of manual and technical controls that limits connections. Some examples of controls that satisfy the practice requirements are:

• Employee owned laptops should not be able to connect to the corporate domain.
• Inbound connections to company owned systems should, if practical, be allowed only from whitelisted IP addresses.
• Third-party contractors who access the company’s network from the contractors’ devices/networks must do so from a virtual desktop infrastructure (VDI) solution.

AC.L1-3.1.20 Example

Prime Contractor A has a contract to organize a flight test and perform a survivability study on the telemetry data that is gathered during the flight test.  Contractor A has a robust analysis team but lacks the expertise to organize and execute the flight test itself.  Contractor A subcontracted the flight test to Contractor B, who specializes in flight tests.

To ingest flight test data, Contractor A has a web server with an API that is configured to receive data in a specified format. To grant Contractor B access to upload the data, an internal request from Contractor A’s Program Manager was submitted to the Chief Information Officer (CIO) who approved the request.  The CIO’s technology team communicated with Contractor B’s technology team and identified the IP address of Contractor B’s server that would be submitting the data.  Contractor B added the IP address to the allowed list on the firewall that protects the webserver and provided Contractor B an API key to authenticate their data transmissions.

Conclusion

This practice can be confusing because of how similar each of the Assessment Objectives appears and because the distinction between connections to and the use of is subtle. We do not recommend organizations be overly concerned in categorizing external systems as either systems that you use or connect to because the requirements are the same for each. Any external system, whether a connection is inbound or outbound, or it is a system that your employees use, are equally subject to the three requirements that you identify, verify, and control/limit.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide AC.L1-3.1.20

(source: CMMC ML-1 Assessment Guide)

Overview of AC.L1-3.1.22: Controls for Federal Contract Information and Controlled Unclassified Information

AC.L1-3.1.22 focuses on controls to keep Federal Contract Information (FCI) and Controlled Unclassified information (CUI) off publicly accessible systems, such as your company blog, press releases, and social media.

The internet is a key source for new teaming partners, employees, and customers. As a result, most companies share information on the internet to raise their profile. This could include information about major contract awards or even technical information and best practices related to work the company is doing. AC.L1-3.1.22 and the related Assessment Objectives are intended to control the publishing process.

The Assessment Objectives for this practice are fairly straightforward and should not present a huge technical challenge for most organizations.

To prevent unauthorized posting, organizations need to know who has access to publish information publicly and who is authorized to approve content [a]. Companies should think about access to publish and authorization to approve as two separate functions. For example, it will likely be someone on a web team who has the technical ability to publish content, but the web team is not likely going to be the individuals writing a press release announcing a new teaming partnership. As a result, the people on the web team need to know who is authorized to give them instructions to publish content. Given this, we recommend organizations maintain lists of individuals with the technical capabilities to publish and the authorization to approve publishing information on the company website and social media.  To achieve the Assessment Objectives, the authorization process should include someone with the capability to identify FCI and CUI in a publication, such as a government contracts team member or a compliance officer.

[b] Written procedures should be documented to govern the activities described in Assessment Objectives [c], [d], and [e].  Although CMMC Maturity Level 1 does not require policies, we recommend that organizations extensively document requirements relative to this practice because it is very likely to involve individuals from multiple departments including contracting, technology, marketing, and executives.

As described in [a], a company should know who is authorized to approve content prior to being published. These individuals should perform a documented review and approval of all content prior to being published [c]. An assessor may ask to see evidence that content posted publicly was approved by an authorized individual in accordance with the procedure.

This practice also requires some type of detective review process [d] to compliment the preventative approval procedure required by [c]. We recommend that organizations institute a monthly process where all content that was published during the preceding month is reviewed by an appropriate person to determine if FCI/CUI was inadvertently posted. This review should be documented and maintained as evidence for your assessors.

Key to Success

This practice truly demonstrates that CMMC compliance requires the entire organization to be invested in the associated controls, even some organizational departments that might not be accustomed to enforcing security compliance requirements, such as a Marketing. Great care should be taken to ensure all individuals in this process are appropriately trained to perform all elements of the Assessment Objectives.

Last, the practice requires procedures to remove FCI/CUI if it is discovered that it was inappropriately published [e]. For example, if the monthly review [d] identifies inappropriate disclosures, there should be a process in place to notify the appropriate individual or team with the ability to remove the information. This procedure should be documented [b] along with the other procedures described in this practice.

Conclusion

Relative to many of the other practices, this CMMC practice requirement is fairly straight forward. It simply aims to ensure FCI/CUI is not accidentally published to the internet. Although it should not pose significant technical challenges, compliance with this practice will likely require participation from departments and individuals not typically involved in cybersecurity. As a result, we recommend creating a well-crafted procedure and/or policy that describes the process and who is authorized to approve publishing content. Additionally, we recommend providing training for those involved to ensure they have the motivation and understanding required to consistently perform their responsibilities.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide AC.L1-3.1.22

IA.L1-3.5.1

(source: CMMC ML-1 Assessment Guide)

Overview of IA.L1-3.5.1: Identification and Authentication

This is the first of two Level 1 requirements related to Identification and Authentication. The Assessment Objectives are closely related to the objectives in AC.L1-3.1.1, which focuses on the procedures to authorize access. IA.L1-3.5.1, however, focuses on ensuring system functions are performed unique IDs.

Throughout the CMMC, we see access related practices repeatedly divided into objectives related to users (people), processes, and devices. This practice is no different, and as such, the only difference between the three assessment objectives here are that they apply separately to users (people), processes, and devices.

In that regard, this practice simply requires that when users, processes, and devices access a network or system, that they do so with a unique identifier. For most systems that a user logs into, this will typically be a userId that is specific to that user. This also means that users should not be assigned shared accounts. Shared accounts may be convenient, but they also impair non-repudiation and audit trails.

Key to Success

To meet this objective, organizations should verify their ability to generate lists of identifiers for all in-scope systems and networks. The obvious source of identifiers are the userId’s that employees use to login to the company network and in-scope applications. However, assessors may also examine service/system accounts used by processes and systems and device identifiers used by printers, switches, etc. So, organizations should consider these identifiers as well.

Frequently, systems need to interact with each other, and when they do, they too should have a unique identifier to authenticate requests. This could also be a userId if a system needs to perform a function, such as an application using a MS Active Directory userId to write to a SQL Server database, run a PowerShell script on a network, or save a file to a network folder. It could also use an API key or other unique identifiers to authenticate requests.

The CMMC Assessment Guide also points out that for network devices, the identifier could be a MAC address, IP address, or some other device specific identifier. An example of a device accessing a system could be a multi-function printer that needs to be able to save files to a network location or email files to another user. It should have a unique userId from which it performs these tasks.  The CMMC Assessment Guide goes as far as to indicate that network switches should have unique identifiers, which is notable not because it is particularly difficult, but because it is a clear indication of how expansive the regulators consider the scope of CMMC to be.

Lastly, organizations should be able to demonstrate evidence that they comply with these objectives, such as user lists, device lists (with the device Id), or system/service account lists. We recommend companies maintain the ability to generate lists of these identifiers for all in-scope systems and supporting networks.

Conclusion

To look at this practice casually, one might be inclined to think it is a throwaway item that any organization would naturally comply with. “Of course our users have IDs!” But there is more to it than that. IA.L1-3.5.1 builds on the access control practices by requiring not only users but also, processes acting on behalf of users, and devices be assigned identifiers. With identifiers, interactions with systems and networks can be logged, creating an audit trail that is important for accountability as well as investigating security events

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide IA.L1-3.5.1

IA.L1-3.5.2

CMMC Maturity Level (ML) 1 Practices: Overview of IA.L1-3.5.2

This practice closely tied to IA.L1-3.5.1, which identifies requirements around having unique identifiers, such as userIds, for users, processes acting on behalf of users, and devices. By comparison, this practice requires authenticators to go along with those identifiers.

Authenticators can vary, though in most cases they will be passwords. Other examples can include key cards, API keys, multi-factor authentication (MFA).

Taken together, IA.L1-3.5.1 and IA.L1-3.5.2, in most circumstances, simply require that users have unique ids and passwords. With more complex systems and networks, the requirements can become equally complex.

To comply with this requirement, organizations should review the details of NIST SP 800-63-3, Digital Identity Guidelines, which provides best practices related to passwords and authenticators.  Organizations should be prepared to demonstrate that their systems require the use of hard to guess passwords, and we would recommend, wherever possible, MFA. Although MFA is not strictly a requirement of this practice, it is a requirement for IA.3.083, an ML-3 practice, and it can help reduce authentication risk of systems that you might only have limited ability to control passwords.

Conclusion

IA.L1-3.5.2 requires passwords (and other authenticators as appropriate) to go along with the userIds (and other identifiers) required in IA.L1-3.5.1. There is wide ranging guidance regarding passwords, however, we recommend organizations try to adhere to the recommendations in NIST SP 800-63-3, Digital Identity Guidelines, to help ensure you are complying with the same standards to be used by CMMC assessors. Additionally, many organizations may find themselves tied to systems with limited password configurability, and for that reason, we highly recommend MFA as a way to buttress your compliance.

Lastly, we recommend organizations define their corporate password requirements into a policy, even if you only need to meet Maturity Level 1 requirements. There is no one-size-fits-all password policy. Nuances in technology platforms, availability of MFA, and even the available keys on a device to enter a password, can impact an organizations password policy. The policy should outline password requirements around length, complexity, MFA, history, changes, invalid attempts, etc. If there are instances where your organization cannot comply with its own requirements, then it should be documented and justified. For example, if your organization requires upper, lower, numbers, and special characters, but a cloud product you use employs an algorithmic strength checker, such as the well-respected zxcvbn library, that does not fit neatly into common definitions of “complexity.” Without a password policy, your assessor will need to exercise judgement to determine if your password rules are sufficient in each system. By documenting a clear policy, your assessor will have a clear set of requirements against which to test your systems.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide IA.L1-3.5.2

MP.L1-3.8.3

source: CMMC ML-1 Assessment Guide

This practice is very straightforward and should be an easy win for most organizations.

The practice describes “media” and “sanitization.” These are both terms of art in the CMMC literature and related guidance, so let’s review each of them.

“Media” includes a wide array of items that can store information. These can include laptops, servers, hard drives (internal or external), thumb drives, CDs, DVDs, Blu-ray discs, USB drives, tape backup, mobile phones, paper documents, and more.

“Sanitization” is the process ensuring that the data that was written to the media cannot be recovered. There are many ways to accomplish the task, such as shredding, wiping, and physical destruction. Unfortunately, simply selecting the files and pressing the delete button is not enough. So, what is enough? The CMMC Assessment Guide does not dive into the details, but it does refer readers to an additional 64 pages of guidance, courtesy of the National Institute of Standards and Technology (NIST). Specifically, NIST Special Publication (SP) 800-88, Guidelines for Media Sanitization. The guidance provides recommendations for sanitizing different types of media, e.g., paper, external hard drives, iPhones, and even Blackberries. We recommend examining NIST SP 800-88 for guidance that relates to the type of media your organization uses.

An organization may have a number of reasons to sanitize information system media.

The MP.L1-3.8.3 practice features two assessment objectives separate the practice requirement into media that an organization intends to dispose of [a] and media that the organization intends to reuse [b]. The key distinction between the two is that some methods used to sanitize equipment when being disposed, such as physical destruction, are not practical when equipment is being reissued. After all, if a laptop hard drive is incinerated, it will be difficult to reuse.

Key to Success

Key to passing your assessment will be providing evidence to your assessors that proves you actually perform these functions. First, we recommend documenting a policy and procedure. The policy should clearly indicate the types of events within the organization require sanitization procedures to be applied, and it should identify the individuals responsible for carrying out the activities. The procedures should clearly describe what needs to be performed for each sanitization event and what logs would need to be retained to demonstrate that your organization consistently executes the related procedures. For example, a common event is an employee quitting and returning their computer. As part of the exit process, an organization could complete a checklist in which an IT staff member verifies the date and method used to sanitize the computer before it is put into storage to await reissue.

MP.L1-3.8.3: Media Sanitization and Service Providers

Many companies use a third-party provider to dispose or recycle media including papers and computing equipment. This does not displace the compliance requirement. Organizations should be able to point to their statement of work (or other document) that describes the standards to which the service provider sanitizes media. Additionally, organizations should retain records indicating which pieces of equipment were taken and disposed.

Conclusion

MP.L1-3.8.3 is the only Media Protection practice required in CMMC Level 1, and thankfully, the requirements are not terribly technical and should be an easy win for most organizations. The key to meeting the requirements is to ensure that an organization sanitizes every type of media and that evidence is retained to demonstrate the process is being followed.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide MP.L1-3.8.3

PE.L1-3.10.1

Overview of PE.L1-3.10.1

Practice PE.L1-3.10.1 is primarily concerned with ensuring that Organizations Seeking Certification (OSCs) protect Federal Contract Information (FCI) and Controlled Unclassified Information (CUI) through physical means [b, c, d], and that physical access to data is restricted to authorized individuals to include employees, vendors, and visitors who should have access to it [a].

Practice Scoping: Identification of Physical Spaces and Devices

To ensure your organization complies with this practice, your organization must identify the physical assets which are in scope. Only once the physical assets are identified will an organization be able to document how those assets are protected. The practice identifies three types of assets that require physical protections.

• Organizational systems are data repositories and programs which process data [b].
  • Examples include applications, databases, cloud platforms, and SaaS (software as a service).
• Equipment includes physical devices that process or store data [c].
  • Examples include servers, laptops, fax machines, and other IT devices.
• Operating environments are spaces where data are processed or stored [d].
  • Examples include server rooms, laboratories, networking closets, and production floors.

Although the CMMC standard identifies the three classes of physical assets, we do not recommend organizations ruminate too extensively trying to force an asset into a category. The categories are identified to show the types of assets that are in scope for the practice, rather than to create an administrative burden trying to classify every physical device into one of three categories.

Identify Authorized Individuals

Having determined where FCI/CUI is physically stored, your organization then needs to identify the employees, vendors, and visitors who are authorized to access in-scope organizational systems, equipment, and environments [a].

As with access to systems, the company should have policies and procedures for:

1. Requesting, approving, and granting access to authorized individuals requiring access.
2. Removing access to individuals that no longer require physical access, usually initiated by the end of employment or a contract.
3. Changing individuals access, usually associated with a promotion or transfer.

In addition to these preventative processes, OSC’s should supplement them with detective review processes.

Accordingly, a critically important internal control process that just so happens to generate the exact documentation required for assessment objective [a] of this practice is a periodic physical access review.

Physical access reviews are a periodic (usually quarterly) review process wherein every individual’s physical access is internally reviewed by knowledgeable staff.

These processes can take different shapes and may depend on the integration of badging data into identity and access management systems, the number of physical locations, extent of the use of physical keys, and more.

However, the process typically starts with the generation of a consolidated list or lists of physical access that people have.

That list is stratified based on the person’s supervisor, and supervisors receive lists of individuals and their access to review. If the access is inappropriate, then a change process should be kicked off to modify the access, as appropriate.

When the process is complete, OSC’s should have generated a consolidated list of individuals who are authorized to access different physical areas that contain organizational systems, equipment, and operating environments.

Methods to Limit Physical Access

The second part of the practice is to actually limit access to organizational systems, equipment, and operating environments to the authorized individuals. Management should also understand and document the ways in which access to organization systems, equipment, and operational environments is restricted. There are many examples that can satisfy the requirement, including:

• Storing FCI/CUI documents in a separate wing of the building that is restricted by a badging system.
• Requiring employees to enter a PIN to gain access to the building.
• Using security guards or video cameras to monitor individuals that access the facility.
• Training employees to not allow tailgaters to follow authorized individuals into the building.

Subservice Providers

All CMMC practices, including PE.L1-3.10.1, are applicable wherever the FCI/CUI lives, whether it is in a system or facility that is controlled by the contractor/subcontractor or a subservice provider.

Accordingly, CMMC assessors will need to see how the practices your organization have inherited from your External Service Providers (ESP) have been implemented. To avoid needing to separately assess their ESPs, most organizations will opt to use ESPs that already have certifications, such as CMMC and FedRAMP, that grant reciprocity over the related practice.

Property Management Companies

Many businesses lease a portion of a building. In many of those situations, the lessor provides a property management function to maintain the physical space. In many cases, property management staff have access, either through physical keys or electronic key cards that grant them access to any location within the building. This creates a host of risks:

1. Risk the property management company did not deactivate the employee’s badge access prior to separation
2. Risk the property management company employee created a fictitious employee badge before separating
3. Risk the property management company employee made copies of physical keys
4. Risk that the property management company employee copied down OSC employee physical access pin codes before separating

All this adds up to the conclusion that the solution with the fewest risks is to work with the property management company to disable their ability to grant themselves access to in-scope physical spaces and treat them as visitors (see PE.L1-3-10.3 – Escort Visitors). If it is not possible to limit their access to the badging system, then organizations need to get creative. Once option is simply adding a secondary lock only the OSC’s team can open.

Conclusion

This practice is straight-forward conceptionally: Know who is authorized to physically access different assets and areas and prevent unauthorized physical access.

For some organizations, it will be straight forward practically as well. However, many OSCs will have to carefully navigate a cacophony of confounding conditions that will complicate their compliance.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide PE.L1-3.10.1

PE.L1-3.10.3

Overview of PE.L1-3.10.3

The main focus of this practice is the protection of Federal Contract Information (FCI) and Controlled Unclassified Information (CUI) through escorting and monitoring visitors.

A common cybersecurity adage states that each device that connects to your network is a possible attack surface. Organizations therefore implement security controls to ensure only authorized devices and users can access their systems. This concept also applies to physical access. Each guest that enters your building could be a threat actor seeking to gain access to sensitive spaces or data, so the CMMC has implemented standards that companies must follow to ensure all guests are known and their actions are monitored throughout their visit.

What Qualifies as a Visitor?

One significant distinction that is addressed by this practice is the difference between authorized, perpetual access and visitor access. For example, if your organization employs contractors that require persistent, regular access to your building, their access requirements would likely be reviewed, approved, and established during your organization’s onboarding procedures.

Practice PE.L1-3.10.3 is only concerned with the physical security controls that organizations implement for visitors such as clients, vendors, employee personal contacts, and other guests to the building – all encounters which do not occur on a regular basis.

Identifying Visitors

To best put practice PE.L1-3.10.3 in action, visitors should be easily identified by your staff [a, b].

Many vendors require their employees to wear company-branded clothes such as polos or t-shirts, but organizations should not rely on this marker alone. Terminated vendor employees, for example, could wear old company clothing and claim to be making a visit at their former employer’s behest. One way to mitigate this risk and show your staff that visitors have been vetted is to require that they check in, usually at a front desk, and receive a visitor badge to wear throughout their visit. Organizations could also consider requiring visitors to show photo IDs, such as professional badges or driver’s licenses, prior to signing a visitor log and receiving a badge. This is a more common step for organizations with elevated security concerns, such as schools or government facilities.

Escorting Visitors

Once visitors have been identified by your organization, they should be escorted by an employee throughout their visit [a].

To pass PE.L1-3.10.3, your organization should have a formal policy in place that establishes this requirement. Any evidence that demonstrates this occurs will be reviewed as part of the assessment of practice (PE.L1-3.10.4 -Physical Access Logs).

Monitoring Visitors

“If we escort visitors at all times [a], are we not also monitoring them[b]?”

– Everyone who reads this practice

Yes, I am reminded of my high school logic lectures on syllogisms. The classic example: All cows have spots. Betsie is a cow. Therefore, Betsie has spots. The CMMC equivalent seems to pop up here. Escorted people are monitored. Visitors are escorted. Therefore, visitors are monitored.

As easy as it is to quibble with this one, we recommend organizations consider their physical environments and try to identify measures, in addition to escorting, that support monitoring. These can include, but are not limited to:

• Visitor badges or stickers that clearly identify visitors
• Visitor logs, both in common areas and high-risk areas (such as server rooms)
• Security cameras installed at building entrances and exits

Visitor logs are required for PE.L1-3.10.4 – Physical Access Logs regardless, and a gross of brightly colored visitor stickers can be yours for less than a price of a movie ticket.

Conclusion

PE.L1-3.10.3 is among the easier practices to implement and pass. Thankfully, it appears to have fewer complicating edge cases than other Level 1 Physical Protection practices. We recommend verifying your policies and procedures contain requirements to:

• Have visitors sign-in,
• Escort visitors, and
• Any of the relatively easy ways to add additional “monitoring” to that which is naturally occurring during the “escorting.”

Last, we recommend communicating these requirements to those responsible for visitor intake and escort.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide PE.L1-3.10.3

PE.L1-3.10.4

Overview of PE.L1-3.10.4

The CMMC requirement to maintain logs of physical access is a perfect example of how a requirement that appears simple on its face (it has only one straightforward assessment objective) can be complex and expensive to implement.

In addition to the requirements to limit physical access, escort visitors, and to manage physical access devices (like physical keys and badges), CMMC Level 1 also requires that organizations keep a log of everyone who accesses physical areas where there is FCI/CUI.

Logs should be maintained for visitors and regular personnel. Additionally, they can be put in place for an entire facility or limited to areas within a facility that contain FCI/CUI.

Logs can be manual, part of an electronic badge system, or a combination of the two. For example, many organizations have a badging system for employees, but not visitors. In such cases, a badging system may create logs of employee access, but a manual log is retained to sign-in and sign-out visitors.

Badging System Logs

If your organization uses a badging system to control physical access, then you have a head start. Many badging systems automatically retain logs of who badges in and out of different areas.  However, there are a few considerations:

• Employees should be trained to not allow tailgating. In polite society, we often hold the door open for each other. In organizations that are required to follow the CMMC, staff should be trained to tap their badge to the badge reader, even if someone holds the door open. Likewise, if someone tries to tailgate without badging in, staff should also be encouraged to ask the person to badge in.
• Logs should be retained for a sufficient period. Logs are only good if they are there when you need them. Organizations should examine their badging system and determine if logs are retained and how long they are retained. Physical access records tend not to require a lot of storage space, so we recommend organizations play it safe retain these records for at least a year.

Manual Logs

For some organizations, a manual log whereby employees and visitors sign in and out may be the easy and cheap way to get started. This could be a good solution depending on a few factors:

• Smaller organizations or large organizations for whom the DoD work is confined to smaller work areas.
• If you’re under a time crunch and do not have time to implement an electronic system before you need to be CMMC compliant.

The downside of manual logs is that they’re, well, manual. Whereas badge readers hardly require staff to tap the brakes, a manual log requires a full stop, perhaps a wait in a line, a physical sign-in, and related annoyances among team members.

Challenges

Electronic systems break. Even if you have an electronic system in place, they do occasionally fail. Consider a paper backup plan in the event it breaks to limit the effect of gaps in your electronic logs.

Property management staff control the badging system and can access everything. Many organizations have a full-time building property management company. When an organization is one of many tenants in a building, the property management company often has full access to the badging system, can access any part of the building at any time, can change audit log retention periods, and have direct access to audit log data. In such cases, OSCs should identify compensating measures to secure physical access and protect audit logs, such as creating separate backups of physical access log data and having a written agreement that property management staff are not to access protected areas without approval and escort from the organization.

Scoping. Logs must be kept for each area where there is FCI/CUI. For organizations that primarily service the DoD, it is likely the entire physical space would require logs. In those instances, badging in or signing into a physical building or office space may be enough. However, for organizations where FCI/CUI is isolated to specific areas within a larger office, an organization may be able limit the logging to those specific areas.

Depending on the distribution of FCI/CUI within a physical space, an organization may save costs by consolidating the location of FCI/CUI and staff who interact with it to specific locations within a building.

Server rooms and network closets. The rule applies not only to where people physically sit and do work; it also applies to areas where data is processed. Don’t forget to log access to these areas as well.

Cost of adding badge readers. Adding a new badging system, or even adding a new badge reader to an existing system can be time consuming and expensive. Ultimately, it is a business decision as to whether it is worth the expense to have an automated system that retains logs.

Changing badging systems and log retention. If you switch badging systems, don’t dispose of your old logs. If the logs are stored in a service provider’s cloud, be sure to get a copy of the logs in a readable format and retain them in accordance with your policy.

Janitorial staff. It’s common for organizations to have contracted janitorial staff. These individuals require access to all areas of a facility, including where FCI and CUI are processed. Their access is also subject to audit logs, whether they are escorted visitors or approved (and presumably subject to other related staff requirements, like background checks).

Conclusion

“Maintain audit logs of physical access.” It sounds simple on its face. In actuality, it is loaded with confounding variables from whether FCI/CUI is physically diffuse or consolidated, related staff training requirements, costs of an electronic system vs a paper system, property management company access, the impact of the other three CMMC Level 1 physical access requirements, and more.

With careful analysis and planning, however, organizations can minimize the cost and complexity of implementing physical access controls including physical access logging.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide PE.L1-3.1.2

PE.L1-3.10.5

Overview of PE.L1-3.10.5

Unlike, PE.L1-3.10.1 – Limit Physical Access, which focuses on people, PE.L1-3.10.5 focuses on the devices used by people to access physical areas.

Organizations implement some type of physical device that, when presented, either allows or prevents access to an entire building, a suite, a room, etc. The devices can be key fobs, badges, key codes, cypher locks, spin dial locks, etc. Access to these physical access devices (or their codes) must be controlled.

The CMMC enumerates three elements of control: identifying devices, controlling devices, and managing devices.

[a] Physical Devices are Identified

The application of this control depends largely on the type of device.

Physical Keys

Physical keys are present in just about every organization. Even if advanced badge readers are used in most circumstances, there are often physical keys that can unlock the door in the event the power is out or the badging system breaks.

To the extent that physical keys are present in your environment they should be uniquely identified, such as with a punched number, and their current disposition noted. For example, if there are three keys to the front door and three keys to the “Engineering Room,” where FCI/CUI is present, an organization might keep a record like this:

Fobs or other Digital Devices

Electronic access systems commonly have a list of devices including those that have been issued and unissued. However, they may lack the functionality to associate the devices with people. If they do lack such functions, the organization should maintain its own list, similar to the example for physical keys.

Organizations that have systems that associate the devices with people often have unassigned guest badges. These should still be tracked.

Cypher Locks or Spin Locks

These devices are more common on interior doors rather than exterior doors. They are used to control access to a specific area by giving specific people knowledge of the code to open the door. In these instances, organizations should maintain a list of who has been provided the codes and when the codes were last changed.

[b] Physical Devices are Controlled

We interpret “controlling physical devices” to refer to two broad areas:

Giving/activating physical devices to authorized people

Physical access devices are often maintained by staff who are not responsible for authorizing new access. For example, the Facilities team is responsible for issuing badges to new employees. However, they are only allowed to issue badges when a completed request from Human Resources appears in the badging system.

Regardless of the mechanism used, organizations should indicate a record of the badge being issued, the date, the request, and the approval.

Protecting unissued devices

Certain devices, especially physical keys, can be used by the bearer without a secondary activation. Accordingly, organizations should implement security measures to protect unused devices and document those mechanisms in appropriate policies and procedures.

[c] Physical Devices are Managed

It is helpful to think of “management” as relating to two types of devices: those issued to people (like keys, fobs, badges), and those attached to structures (key locks, cypher locks, combination locks).

Devices Issued to People

Organizations should have documented processes in place to recover/deactivate keys, badges, fobs, and other physical access devices from employees when they separate from the company. These processes are most consistently executed if they start with Human Resources and notify the appropriate staff of the employee’s departure.

The foregoing also applies to vendors. Organizations frequently provide vendors facility access to perform various tasks. Janitorial services, building maintenance, consultants, and auditors are just some examples of visitors that might be issued badges. However, Human Resources is likely not the starting point for deactivating badges issued to vendors. To manage vendor badges, one strategy is to consider them in two groups: Daily Visitor Badges and Permanent Vendor Badges.

• Daily Visitor Badges are appropriate for visitors, including vendors, who do not have a long-lived presence. These badges should be deactivated automatically or manually at the end of the day.
• Permanent Vendor Badges are for vendors who do have a long-lived presence. Contracts with vendors should require the vendor to notify you if their employees separate from the vendor so that you can deactivate their badge. Additionally, if the badging system is capable, it is a best practice to automatically expire the badge at the contract’s end or on a set, periodic basis, e.g., quarterly, unless reapproved by the line-of-business manager overseeing the vendor’s work.

Additionally, an organization should have a procedure to address the inevitable lost device. Employees and vendors should be educated to notify designated individuals if they lose a key, badge, or fob. Likewise, the organization should have documented procedures to respond to such events, such as deactivating the badge or fob and, depending on the scenario, changing the lock.

Regardless if caused by a separation, internal transfer, lost device, or other business reason, the organization should retain records to show that devices were recovered or disabled timely to the related event.

Devices Attached to Structures

Cypher locks and combination locks must be changed every time a person with access no longer requires access. This could be from separation or an internal transfer. If a company uses these types of locks, the separation/transfer process should contain a step to evaluate if the person had access to door codes, and if so, the combinations should be changed and the date of the change documented and maintained.

Physical keys are more difficult and expensive to change. So, an organization may elect to apply criteria to see if an event requires a key change. For example, if someone was terminated for cause and the organization was unable to recover the key at the time of the termination, the organization may elect to change the locks on the door and issue new keys to current employees. If there was a break-in, and you are unsure if the lock was picked or if a key was used, the lock should be changed.

If no event driven lock and code changes occur, organizations should change locks and codes on a minimum periodic basis. Changing physical locks is likely to be very infrequent. Changing cypher and combination codes should be more frequent. Importantly, organizations should document the established frequencies in policies and procedures and document the events as they are performed.

Conclusion

How organizations control and manage physical access devices is highly variable to the type of physical devices used. Regardless of the mechanism, organizations should have policies and procedures to maintain a record of the current disposition of physical access devices and to control how they are issued and recovered. Additionally, when physical access devices are issued and recovered, organizations should maintain a record of the event including who authorized the event and when it was performed.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide PE.L1-3.10.5

SC.L1-3.13.1

Overview of SC.L1-3.13.1

This is the first practice in the System and Communications Protection domain, and if you were to identify which of the CMMC practices requires a firewall, this is the one. With eight assessment objectives and the many methods to defend a system boundary, it’s no surprise then that there is far more to this practice than simply having a firewall.

In summary, SC.L1-3.13.1 requires that you define your external network boundary and key internal network boundaries. Those boundaries must also be monitored, controlled, and protected. If we were talking about physically protecting a house, these practices could be summarized as:

• Identify all your doors and windows [a, b]
• Implement a security system (monitor) [c, d]
• Only open the door for allowed people (control) [e, f]
• Keep the doors and windows locked (protect) [g, h]

The house metaphor, however, starts to break down when we talk about internal boundaries. Although motion detectors and internal cameras are not uncommon with home security systems, most people do not put a lock on their pantry (though that could curb the midnight snacking). Sadly, in the world of cybersecurity, we can’t rely exclusively on protections at the network perimeter.

Define External [a] and Internal [b] Boundaries

This practice focuses on “system boundaries.” A system boundary is the logical (rather than physical) perimeter of the system. It includes all barriers (devices, services, and software) through which traffic flows before a connection is made to another system or device on the other side of the boundary. The practice speaks to both internal and external boundaries.

External System Boundaries

The external boundary is the system boundary that surrounds your enclave. For most organizations, this is likely to include your corporate firewall that connects your corporate network users to the Internet. All inbound and outbound requests to and from your network pass through your firewall.

Although the firewall is the most obvious external system boundary, it is usually not the only one. Your users’ computers (or other devices) might also be part of the boundary. If your users are:

• able to access the internet directly from their computers without the traffic passing through your corporate firewall, and
• their computers also process, store, or transmit Federal Contractor Information (FCI) or Controlled Unclassified Information (CUI)

This commonly occurs with companies that allow remote work. For example, your remote team members access a cloud document sharing platform. A software agent on the user’s computer syncs the cloud files with FCI or CUI back to the user’s computer. In that case, the user computer “stores, processes, or transmits” covered information and are part of your external boundary.

Internal System Boundaries

Internal system boundaries follow the same basic principle and are expected in zero-trust environments.  Internal system boundaries are common if a company has internally hosted systems that store, process, or transmit FCI or CUI. For example, a company uses an internally hosted web-based contracting system that contains FCI. It has an application server and a database server. The company determines that those servers should reside within their own boundary and implement a firewall through which all traffic must pass before reaching the application server and the database server.

Defining the Boundaries

Okay, now we know some of the common things to look for with respect to system boundaries, but assessment objectives [a] and [b] require that they are defined. Ultimately, this means that the boundaries need to be documented. The CMMC assessment guide is not opinionated as to the form of the documentation. So, although you could document your internal and external system boundaries in iambic pentameter or in a diorama, we recommend a network diagram or topology. The illustration below shows a basic illustration of a network that has:

• internally hosted applications
• separate vLANs for administrators and normal users
• remote users
• defined network boundaries for the above

Monitor External [c] and Internal [d] Boundaries and Protect External [g] and Internal [h] Boundaries

Monitoring and protecting system boundaries are usually so closely related to each other that they should be discussed together. Most commonly, monitoring is an automated process where a device is listening to some type of network traffic coming into a boundary, and if that monitoring identifies a threat, it automatically blocks the threat, protecting the system(s) internal to the boundary.

For example, corporate firewalls are typically configured to automatically detect malicious traffic patterns and drop data packets if malicious traffic is detected. Detected threats that meet a specific threshold may result in automated blocking of the IP address.

If a boundary monitoring mechanism is not capable of automatic actions to protect in response to detected threats, it is likely capable of automatically notifying your administrator or writing security events to a log that can be manually reviewed on a periodic basis (e.g., daily or weekly).

Monitoring can also occur on outbound traffic. For example, automated ransomware payloads may attempt to access the internet on obscure ports to download the public key being used to encrypt data. If a user attempts to access the internet on a blocked port, that may trigger an alert as well. Additionally, data loss protection (DLP) systems may inspect outbound packets for sensitive information leaving the network.

What about remote users who might have CUI or FCI on their computers? To meet this requirement their computers could be fitted with:

• Endpoint detection and response software
• Web filter software
• Host-based firewalls

Control External [e] and Internal [f] Boundaries

Controlling is part management process and part technology implementation.

In the previous sections, we’ve discussed various tools that an organization may use to help protect and monitor a network boundary. Those tools, however, should be configured based on the needs of the organization for the given boundary device. Firewalls should be configured to deny all traffic and allow traffic by exception[1], i.e., control which data is allowed to pass through them to their destination and which data is blocked. The process to identify the types of data (ports and protocols) to allow at each boundary is a management process. The technology implementation is the deployment of the rules borne out of the management process.

Consider the above diagram. It has three firewalls: one internal firewall, an external firewall, and host-based firewalls installed on the endpoints. They might be configured as follows[2]:

• Internal Firewall
  • Inbound requests for the application on TCP port 443 (HTTPS) are allowed from the user vLAN and the admin vLAN
  • Inbound requests for the database on TCP port 443 (HTTPS) are only allowed from the admin vLAN, because users have no need for their computers to communicate directly with the database
  • Outbound – Block all
• External Firewall
  • Inbound – VPN requests on ports UDP port 500 and UDP port 4500
  • Outbound – TCP port 443 (HTTPS) and UDP port 53 (DNS)
• Endpoint Host-based Firewall
  • Inbound – Block all

Allowing only required ports and protocols is only one very small piece of the puzzle. Some of other considerations based on the technologies discussed in this article are:

Network Firewalls

• Geo-IP blocking – Block all inbound and outbound communications to countries you do not do business with
• Aggressiveness level of detection and blocking – More aggressive settings block more but are more prone to false positives
• Whitelist inbound IPs – If you have exposed services, only allow connections from specific IP addresses (if possible)
• Modern ciphers for VPNs – Avoid ciphers with known weaknesses
• Configure to notify IT administrators of specific circumstances (e.g., login attempts to the firewall or high threat level attack is detected)

Web Filters

• Block foreign domain extensions and foreign hosted sites
• Block categories as deemed necessary (e.g., adult, gambling, etc.)
• Configure HTTPS traffic inspection – requires an agent-based filter rather than a DNS-based filter
• Block downloads of executable files
• Block downloads of malicious files
• Block unapproved file sharing sites
• Configure to notify IT administrators of specific circumstances (e.g., a user attempts to download a malicious file)

Host-Based Firewalls

• Configure to block all inbound and outbound connections with the exception of necessary network services from authorized IP addresses. This can impair a threat actor’s ability to move laterally through the network. This is especially helpful for remote workers when little Timmy’s unpatched Minecraft server gets hacked

Endpoint Detection and Response (EDR) Software[3]

• Configure to deactivate the computer’s network interface and notify IT administrators of specific circumstances (e.g., ransomware detected)
• Aggressiveness level of detection and blocking – More aggressive settings block more but are more prone to false positives

Conclusion

SC.L1-3.13.1 – Boundary Protection is one of the more technologically complex CMMC Level 1 requirements. It may require expertise in networking and multiple commercial solutions. Conceptually, however, it is fairly straightforward. Put plainly, organizations should know where their internal and external boundaries are and implement technologies to prevent bad guys from getting in and stopping them if they do.

The other good news is that the technological complexity usually scales with complexity of the IT environment. And the more complex your environment, the more likely you are to have team members that understand the requirements in SC.L1-3.13.1 and possess the skills to implement them in your environment.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide SC.L1-3.13.1

[1] Deny all, allow by exception is a CMMC Level 2 requirement (SC.L2-3.13.6 – Network Communication by Exception); however, we strongly recommend all organizations adopt this posture where possible. It is a potent cyber defense posture.

[2] This is an extremely simplistic example. An actual configuration would need more rules. For example, the internal firewall and host-based firewalls would need to allow other ports to facilitate system administration, domain controller communications, and offsite backups.

[3] It may be more appropriate to document your EDR configuration and solution in your System Security Plan (SSP) documentation for SI.L1-3.14.2 – Malicious Code Protection. If so, we recommend referencing that documentation in your SSP documentation of SC.L1-3.13.1 – Boundary Protection.

SC.L1-3.13.5

Practice
Practice Title: Public-Access System Separation
Practice Number: SC.L1-3.13.5
Practice: Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.

Assessment Objectives
Determine if:
[a] publicly accessible system components are identified; and
[b] subnetworks for publicly accessible system components are physically or logically separated from internal networks.

Preface: Throughout this article we reference different types of cloud services. Please note that cloud services that meet the definition of CUI Assets or Security Protection Assets must have the requisite FedRAMP Moderate/High Approval or Equivalency. Whether FedRAMP Moderate or FedRAMP High is required depends on your circumstances considering such factors as the presence International Traffic in Arms Regulations (ITAR) data, the use of end-to-end encryption, or other situation specific facts.

Company networks usually have an internal network and a firewall at boundary that separates and protects the internal network from the public Internet. The firewall should be configured, for example, to block inbound traffic to devices on the internal network.

However, some organizations have a need to allow inbound traffic. For example, a company hosts a web application server on their network to interact with customers. In such circumstances, the firewall would be configured to allow inbound traffic on TCP ports 80 (HTTP) and 443 (HTTPS) and direct all inbound traffic on those ports to the web application server.

Because it is intended to be publicly accessible, the web application server is exposed to the public internet, which is home to honest users as well as threat actors who can, and almost certainly will, attempt to compromise it. If the server is compromised, the threat actor would have a foothold on a server on the company’s internal network that can be used as a staging area to attempt further attacks.

This CMMC practice sets forth networking requirements intended to impede the lateral movement of a threat actor that has already successfully compromised a publicly accessible system or service.

To implement this practice, you must [a] identify your publicly accessible systems and [b] separate them logically or physically from the rest of your internal network.

Identifying Your Publicly Accessible System Components

Most companies will have at least some publicly accessible systems, and we think it’s helpful to put these systems into one of three groups. The nature and complexity of the compliance obligations vary based on the group.

Fully managed, cloud-hosted, services or systems

These are your typical software-as-a-service (SaaS) products and are typically purchased services where the application is developed, hosted, protected, and otherwise managed by the provider on their servers within their datacenters. Typically, users have little or no control over security at the network level.

Examples include:

• Microsoft One Drive
• Dropbox
• Google G-Suite
• Citrix ShareFile

Partially managed, cloud-hosted, services or systems

These are your typical infrastructure-as-a-service (IaaS) products and include cloud systems where you have a great deal more control over the networking and the server operating system itself where you can install software, open and close ports, and implement a firewall and/or a virtual network.

A web application in this model might entail configuring a cloud-based virtual private cloud (VPC) that contains a server to host the web application software, a database server, a backup server, and a virtual firewall in front of the VPC through which all public traffic must travel. You would have a massively increased amount of control and related responsibilities for the server, the software, and the networking.

Examples include:

• Web-based accounting system software you host in Microsoft’s Azure Cloud
• API service you host in the Amazon Web Services (AWS) cloud
• AI models you host in Google Cloud

Self-hosted, on-premises, services or systems

These include any publicly accessible services or systems that are hosted within the same network as non-public services or systems.

Like the previous example, a website in this model might have an application server, a database server, and a database backup server. However, they would be located on the interior of a company’s corporate network where end users, the domain controller, internal file shares, and other non-public systems are located.

Examples include:

• Remote time entry systems hosted on your own network
• Remote collaboration tools hosted on your own network
• Company website hosted on your own network

Separating Your Publicly Accessible System Components from Internal Networks

Once you’ve identified your publicly accessible systems [a], you need to ensure they are logically or physically separated from non-public systems [b] and document your implementation details to support your CMMC Assessment and/or Self-Certification.

In the subsections below, we’ll revisit each of the three broad categories we discussed above and describe methods to logically and physically separate public systems from internal systems.

Fully managed, cloud-hosted, services or systems

Fully managed SaaS products are completely separate from internal corporate networks, and as a result they have the least complex technical and compliance requirements for organizations.  For these types of systems, we simply recommend documenting that the service is fully managed by the cloud provider and is therefore separated from your internal network.

Partially managed, cloud-hosted, services or systems

Evidence

Once implemented, we recommend organizations retain diagrams like the ones in this article that depict the desired separation for each publicly accessible system or component. For Level 1 organizations performing a Self-Assessment, we also recommend obtaining and retaining evidence (e.g., configurations, screenshots, etc.) that demonstrate the implementation conforms with the diagram.

Conclusion

It’s a bad day when you discover a breach in an external system. That alone is a nightmare scenario for an organization. However, a single server compromise is a far preferable outcome to an entire corporate network compromise.

SC.L1-3.13.5 – Public-Access System Separation – is intended to help prevent a breach event from going bad to worse. Its requirement to identify publicly accessible systems and separate them from internal systems, usually with some form of DMZ, can prevent an external system breach from turning into a full network breach. Additionally, it’s an uncontroversial long-standing network security best practice.

Not all CMMC requirements are created equally. If MA.L2-3.7.6 – which requires supervising maintenance staff, including custodial staff, plumbers, and others – went the way of the dodo, I wouldn’t expect the candlelight vigil to last long into the night.

In contrast, SC.L1-3.13.5 – Public-Access System Separation, ranks near the top in terms of actual security benefits and we recommend organizations implement this one with rigor.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide SC.L1-3.13.5

SI.L1-3.14.1

(source: CMMC ML-1 Assessment Guide)

Note: CMMC practice RA.L2-3.11.1 – Vulnerability Scanning and RA.L2-3.11.2 – Vulnerability Remediation are CMMC Level 2 requirements. For organizations that are targeting CMMC Level 2, there will almost certainly be some overlap/redundancy with the subject of this article SI.L1-3.14.1 – Flaw Remediation.

Overview of SI.L1-3.14.1

According to IBM’s Cost of a Data Breach Report 2023, roughly 6% of data breaches start with an attacker leveraging known vulnerabilities in software or firmware. The infamous Equifax data breach, in which hackers stole the personally identifiable information of 147 million Americans, was perpetrated by exploiting an unpatched vulnerability in the Apache Struts framework on an Equifax webserver.

These attacks also target end users. Such attacks start with a victim user being prompted to open a malicious file with a vulnerable application. When the application tries to open the malicious file, the application is usually forced into an error state, such as a buffer overflow, from which the malicious file can now run its own arbitrary code.

This happens more than you might think. The Common Vulnerability and Exposure (CVE) database, for example, reports 22 new vulnerabilities for Adobe Acrobat Reader in the first four months of 2024; 82 in 2023, and a staggering 2,115 vulnerabilities dating back to 1999. Nearly every recent Acrobat Reader vulnerability is exploited when victim users “open a malicious file.”

The good news, however, is that software manufacturers are generally pretty good about releasing patches to fix the vulnerabilities. Organizations that want to shore up those vulnerabilities have to apply those patches when they are available.

SI.L1-3.14.1 is the CMMC requirement that requires patching security vulnerabilities. Although simple in concept, organizations with complex infrastructure or immature endpoint security will have some work to do.

Flaw Remediation has six assessment objectives, which relate to three main areas:

1. Identifying flaws [a, b]
2. Reporting flaws [c, d]
3. Correcting flaws [e, f]

Half of the objectives require formalizing timelines to identify [a], report [c], and correct [e] flaws; the other half [b, d, and f] require implementation of those timelines.

Software Inventory – A Helpful Prerequisite

To patch vulnerable software or firmware, you must first know a flaw exists to patch. And to know if a flaw exists to patch, you must first know what software and firmware is installed on your systems and network. A well-designed patching program is therefore predicated on the ability to maintain an inventory of software and firmware.

When creating an inventory, we recommend considering software that runs on:

• Network devices – Firewalls, managed switches, wireless access points, and other network devices all have a type of software called firmware that needs patching.
• Servers – Including the operating system and any other software necessary for the server to perform its function.
• End-user computers – Operating systems, office productivity software, web browsers, PDF readers, and more.
• IoT Devices – Multi-function printers, cameras, etc.

The most challenging of the above are end-user computers, and that challenge is most acute in organizations that allow end-users unrestricted rights to install software, usually through local admin privileges.

Maintaining a software inventory and a functioning patching program is practically impossible if end users can install whatever they want.

Organizations should disable local admin rights for end users wherever possible. If local admin privileges are necessary, as may be the case when certain end-user software requires it, other mitigations should be implemented to prevent unauthorized software from running (such as AppLocker).

Organizations may also find it helpful to use automated tools to generate inventory reports, monitor the software installed on end-user computers, and even patch them.

Conclusion

SI.L1-3.14.1 – Flaw Remediation – requires organizations to identify, report, and correct flaws in a timely manner. For most, this is a simple matter of layering some additional governance and documentation onto existing system patching processes. However, organizations that have provided end users with the ability to download and install any software will have some additional work.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide SI.L1-3.14.1

SI.L1-3.14.2

Overview of SI.L1-3.14.2

Flashback to 1987 – I was 8 years old, the Giants beat the Broncos in Super Bowl XXI, IBM launched its second-generation personal computer (the PS/2), and John McAfee released VirusScan, the first commercial antivirus software.

As computers became more common in the workplace and at home, the necessity of antivirus became obvious to nearly all users.

Today, antivirus software can range from traditional file and system scanning solutions to full endpoint detection and response (EDR) services. For this article, however, we will simply use the term endpoint protection.

This is the first of three CMMC Level 1 requirements related to endpoint protection. Simply put, it requires organizations to deploy endpoint protection where necessary.

Designated Locations

The first assessment objective requires that organizations identify where endpoint protection software is needed [a]. It does not need to be installed on every device, but organizations should start with a risk-based analysis to determine where it is needed.

Identifying the impact and likelihood of malware on a device will help provide a clearer picture of the risk. Risk factors to consider might include:

Likelihood

• Device connectivity to the Internet (likelihood)
• Other protection tools upstream or downstream from the device (likelihood)
• Ubiquity of malware on the platform (likelihood)
• Extent of user device interaction (likelihood)

Impact

• Device connectivity to other devices (impact)
• Mission criticality (impact)
• Data sensitivity (impact)

Given the above, it would be difficult to reasonably conclude that end user computers with Internet access and local network connectivity do not need endpoint protection. In contrast, a Linux server that serves an internal-facing web application, with CLI access limited to local admins (who do have endpoint protection software on their machines) via SSH might reasonably not have dedicated endpoint protection software.

Organizations will also consider the cost, performance impact, and availability of compatible endpoint protection software.

For example, if an organization serves a web application with a cluster of servers behind a load balancer it may be more performant and easier to use a firewall performing deep packet inspection on inbound traffic rather than endpoint protection software installed on every server in the cluster.

There is a lot of judgment when determining where endpoint protection software needs to be deployed. If your judgements are documented and reasonable, this assessment objective should not trouble most organizations.

Implementation

Once you decide where you need to implement endpoint protection, now you have to install it and hit the “On” button. That is all there is to it, sort of. CMMC Level 1 has two more related practices that address two related areas.

• L1-3.14.4 – Update Malicious Code Protection
• L1-3.14.5 – System & File Scanning

Conclusion

Computing without endpoint protection is a bit like skydiving without a parachute; both are destined to end poorly. Thankfully, “antivirus” has had over 30 years to embed itself in our collective consciousness as an essential cyber defense, and most organizations have already adopted a solution. So, aside from documenting where it should be deployed and why, most organizations will not have much additional work to satisfy CMMC’s Malicious Code Protection requirements.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide SI.L1-3.14.2

SI.L1-3.14.4

(source: CMMC ML-1 Assessment Guide)

Overview of SI.L1-3.14.4

CMMC Level 1 contains three highly related practices that collectively set forth requirements for endpoint protection, i.e., antivirus. This is the second such practice.

If Malicious Code Protection (SI.L1-3.14.2) is the parent requirement, then Update Malicious Code Protection (SI.L1-3.14.4) and System & File Scanning (SI.L1-3.14.5) are fraternal twins.

Update Malicious Code Protection

Endpoint protection software, like any software, requires updates. Endpoint protection software updates usually come in a few flavors:

• Malware signature and/or behavioral definition updates
• Software patches
• New major versions

Endpoint protection tools use a variety of mechanisms to detect malware, such as malware signature and behavioral analysis. Because malware is constantly evolving, endpoint protection software providers issue regular definition updates to keep pace with the threats. These updates are issued at least daily. Microsoft releases updates for Defender around six times per day!

This CMMC Level 1 practice has a single assessment objective, and that is to ensure that that definition updates are applied when they are available.

To comply with this practice, organizations should use a centrally managed endpoint protection, rather than one off installations on user devices. If not centrally managed, users likely have the ability to disable the automatic updates or even disable the software entirely.

Centrally managed endpoint protection tools also commonly provide reporting capabilities that will show the definition version and when it was last updated for each protected endpoint. Without such reporting, your assessor may need to manually inspect devices to determine whether this practice is implemented.

Monitoring

Most endpoint protection software can keep itself up to date without any issues. Occasionally, however, something goes wrong. The endpoint protection software may never be installed, be accidentally removed, or lose the ability to phone home to the centralized management server.

CMMC Level 2 contains practice requirements for Security Control Assessments (CA.L2-3.12.1) and Security Control Monitoring (CA.L2-3.12.3). Adding a layer of monitoring and periodic assessments to your endpoint protection controls will help identify noncompliant endpoints and support Level 2 requirements. Monitoring and assessment activities to consider include:

• Periodic reconciliation of devices reported in the endpoint protection administration console to asset inventories will identify unprotected devices. (Supports SI.L1-3.14.2 – Malicious Code Protection)
• Periodic inspection of devices in the endpoint protection administration console to identify misconfigured and out of date software. (SI.L1-3.14.4 – Update Malicious Code Protection and SI.L1-3.14.5 – System & File Scanning)

Conclusion

Teenagers have always had their own dialect. Aided by technology, however, today’s slang changes as often as the weather and spreads faster than glitter in a kindergarten class. Parents, however, also benefit from the technology; they have various online dictionaries they can use to keep up with their teen’s latest vernacular. No cap! Amirite fam?

Like teen dialect, malware is in a constant state of evolution and change. Endpoint protection tools, likewise, need to be updated so they can keep up with the latest malware. Thankfully, updating malware protection takes less effort than yeeting those cheugy jeans.

Endpoint protection software is almost always configured by default to automatically update protection definitions. So, organizations that have implemented Malicious Code Protection (SI.L1-3.14.2) will probably also have implemented Update Malicious Code Protection (SI.L1-3.14.4) without doing anything extra, which is totally lit.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide SI.L1-3.14.4

SI.L1-3.14.5

(source: CMMC ML-1 Assessment Guide)

Overview of SI.L1-3.14.5

CMMC Level 1 has three practices related to endpoint protection (i.e., antivirus).

The first (SI.L1-3.14.2 – Malicious Code Protection) sets out requirements to implement endpoint protection software where necessary.

The second (SI.L1-3.14.4 – Update Malicious Code Protection) requires enabling automatic updates of the “protection mechanism,” commonly known as virus definitions or signatures.

Finally, this practice brings up the rear by establishing specific requirements for periodic and real-time scans.

Periodic Scans

The first two assessment objectives require that organizations define, such as in a policy, the frequency with which scans should be run [a] and to run the scans according to that requirement.

The CMMC guidance does not provide any indication as to a minimum cadence. So, organizations have latitude to determine what makes sense. Some key factors informing that decision are:

• Performance – Full system scans can take several hours and can significantly degrade performance during the scan.
• System Risk – End user computers and network file shares are at higher risk of malware because they constantly have new files saved to them. Servers to which users cannot write files are at lower risk.

Additionally, scheduled scans supplement real-time scans [c] that are performed when files are downloaded and opened. So, assessment objectives [a] and [b] are addressing the risk that downloaded malware is not detected at the time of the download, but updated definitions/signatures identify it later as malware. It is a real, albeit narrow, risk.

Given the above, we think full system scans should be configured to run no less frequently than monthly. Higher risk systems may warrant weekly scans.

Real-time Scans

Without real-time scans, endpoint protection software is doing basically nothing. Verify that your endpoint protection is configured to scan files as they are downloaded and opened [c].

As with the other two endpoint protection related CMMC Level 1 requirements, organizations should use a solution that can be centrally managed by administrators so that users cannot disable periodic scans or real-time protection. Additionally, it will be easier for your assessor to verify the settings with a centrally managed solution rather than manually inspecting individual endpoints.

Monitoring

Most endpoint protection software can keep itself up to date without any issues. Occasionally, however, something goes wrong. The endpoint protection software may never be installed, be accidentally removed, or lose the ability to phone home to the centralized management server.

CMMC Level 2 contains practice requirements for Security Control Assessments (CA.L2-3.12.1) and Security Control Monitoring (CA.L2-3.12.3). Adding a layer of monitoring and periodic assessments to your endpoint protection controls will help identify noncompliant endpoints and support Level 2 requirements. Monitoring and assessment activities to consider include:

• Periodic reconciliation of devices reported in the endpoint protection administration console to asset inventories will identify unprotected devices. (Supports SI.L1-3.14.2 – Malicious Code Protection)
• Periodic inspection of devices in the endpoint protection administration console to identify misconfigured and out of date software. (SI.L1-3.14.4 – Update Malicious Code Protection and SI.L1-3.14.5 – System & File Scanning)

Conclusion

Having endpoint protection software but not enabling real-time scans is a bit like having a gym membership but only using the smoothie bar. It is not doing you any good.

Periodic scans are also required, but organizations have the flexibility to determine how often they need to occur. Consider the performance degradation the scheduled scans cause and the system related risk to identify an appropriate cadence for scheduled malware scans. Most organizations will identify a cadence between weekly and monthly.

Read the Full Article: DoD Contractor Considerations for CMMC Practice Guide SI.L1-3.14.5