What is CMMC?
The theft of Intellectual Property (IP) and Personally Identifiable Information (PII) from all commercial industry sectors is a threat to the global economy and national security. Cyber attacks cost the US economy alone between $50 billion and $100 billion per year. Global estimates are $600 billion USD.
The US DoD & Military Defense Industry Base (DIB) is a prime target for much of this malicious cyber activity. The Cybersecurity Maturity Model Certification (CMMC) framework was developed by Carnegie Melon and John Hopkins universities under US Government Federal Contract and released in March 2020. CMMC will impact 200K+ DIB companies who must now all complete independent third-party audits of the strength and maturity of their Cyber Security program.
Lack of effort in complying with NIST SP 800-171 Assessing Security Requirements for CUI (issued 2018) prompted introduction of the CMMC Compliance audit program requiring Defense Contractors to perform independent 3rd party audits for compliance with the required compliance level to bid on, or participate in, any particular DoD contract as a prime or sub-contractor. NIST SP 800-171 also references other NIST Standards such as NIST SP 800-53 (Security & Privacy Controls).
The objective of the CMMC certification program is to improve US DoD & Military Defense Industry Base (DIB) Cybersecurity Best Practices and reduce the risk. This includes reducing the negative economic impact and any threat to national security resulting from unauthorized access to Controlled Unclassified Information (CUI) or Personally Identifiable Information (PII) or malicious cyber activity from internal or external bad actors.
The most fundamental requirement of NIST SP 800-171 and CMMC is maintaining the Confidentiality of sensitive data and implementing adequate and reliable access control over this data with full accountability for all access or use of the data. All of the 17 different domains from Personnel Security (PS) and Awareness Training (AT) to Media Protection (MP) and Risk Management (RM) are essentially additional layers in a layered approach to security further supporting control over any access, authorized or unauthorized, to sensitive information assets (IP, CUI, PII).
NIST SP 800-171 Requirements
National Institute of Standard and Technology (NIST) is responsible for developing information security standards and guidelines under the Federal Information Security Modernization Act (FISMA). First published in 2018, all DIB companies were required to adhere to this standard in developing and operating their cybersecurity program. It was soon discovered this requirement was largely being ignored. CMMC was then implemented to correct the lack of attention to the standard.
This core access control, confidentiality and accountability requirement is laid out in the following sections of NIST SP 800-171. Any of SecuPi’s Global SI implementation partners can assist in cost-effectively meeting these requirements leveraging SecuPi’s solution for providing the required centrally managed, consistently applied, fine-grained access controls, accountability, audit trail, advanced User Behavior Analytics (UBA) and Data Activity Monitoring. This solution completely replaces functionality provided by other data security tools like Database Activity Monitoring (DAM), Data Loss Prevention (DLP), Data Obfuscation and other tools.
What also becomes immediately evident is how almost impossible it will be to satisfy the fine-grained access control requirements using only Role Based Access Controls (RBAC) applied either at the Application Layer (used to access the data) or within the Data Layer using Semantic or View Layer security controls hard coded into Database Views. Next generation Purpose or Attribute Based Access Control (PBAC/ABAC) become essential to full compliance. These must also be centrally managed, consistently applied and follow the data enabling greater data mobility and hosting flexibility.
The Blue Text below highlights some of the core requirements fully met by SecuPi’s comprehensive solution features and functionality.
3.1 ACCESS CONTROL
Basic Security Requirements
3.1.1 Limit system access to authorized users, processes acting on behalf of authorized users, and devices
Access control policies control access between active entities or subjects (i.e., users or processes acting on behalf of users) and passive entities or objects (e.g., devices, files, records, and domains) in systems.
Access enforcement mechanisms can be employed at the application and service level to provide increased information security.
3.1.2 Limit system access to the types of transactions and functions that authorized users are permitted to execute.
Organizations may choose to define access privileges or other attributes by account, by type of account, or a combination of both. System account types include individual, shared, group, system, anonymous, guest, emergency, developer, manufacturer, vendor, and temporary. Other attributes required for authorizing access include restrictions on time-of-day, day-of-week, and point-of-origin. In defining other account attributes, organizations consider system-related requirements (e.g., system upgrades scheduled maintenance,) and mission or business requirements, (e.g., time zone differences, customer requirements, remote access to support travel requirements).
3.1.3 Control the flow of CUI in accordance with approved authorizations.
Enforcement occurs in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, firewalls) that employ rule sets or establish configuration settings that restrict system services, provide a packet-filtering capability based on header information, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics).
Information flow control regulates where information can travel within a system and between systems.
Flow control restrictions include the following: keeping export-controlled information from being transmitted in the clear to the Internet; blocking outside traffic that claims to be from within the organization; restricting requests to the Internet that are not from the internal web proxy server; and limiting information transfers between organizations based on data structures and content.
Transferring information between systems representing different security domains with different security policies introduces risk that such transfers violate one or more domain security policies.
In such situations, information owners or stewards provide guidance at designated policy enforcement points between interconnected systems.
Organizations consider mandating specific architectural solutions when required to enforce specific security policies.
Enforcement includes: prohibiting information transfers between interconnected systems (i.e., allowing access only);
3.1.4 Separate the duties of individuals to reduce the risk of malevolent activity without collusion.
Because separation of duty violations can span systems and application domains, organizations consider the entirety of organizational systems and system components when developing policy on separation of duties.
3.1.5 Employ the principle of least privilege, including for specific security functions and privileged accounts.
Organizations employ the principle of least privilege for specific duties and authorized accesses for users and processes. The principle of least privilege is applied with the goal of authorized privileges no higher than necessary to accomplish required organizational missions or business functions.
Organizations consider the creation of additional processes, . . . and apply least privilege to the development, implementation, and operation of organizational systems.
Security functions include setting events to be logged, setting intrusion detection parameters, and configuring access authorizations (i.e., permissions, privileges).
3.1.7 Prevent non-privileged users from executing privileged functions and capture the execution in audit logs.
This requirement represents a condition to be achieved by the definition of authorized privileges in 3.1.2.
Misuse of privileged functions, either intentionally or unintentionally by authorized users, or by unauthorized external entities that have compromised system accounts, is a serious and ongoing concern and can have significant adverse impacts on organizations.
Logging the use of privileged functions is one way to detect such misuse, and in doing so, help mitigate the risk from insider threats and the advanced persistent threat. Enhanced by User Behavior Analytics (UBA), Alerting & Blocking of anomalous data access activity.
CMMC (Access Control Related) Audit Requirements
CMMC covers 17 Cybersecurity Domains with 5 different levels of increasing requirements with each higher level adding compliance requirements, while cumulatively including all lower level requirements. At the core of all of the 17 different Domains in the model, is controlling and limiting access to the sensitive data to authorized personnel for authorized business purposes with the full knowledge and consent of the Data Owner. The model is broken down into 17 Domains that each include Processes and Capabilities (that include one or more Practices).
Figure 1: Simplified View of CMMC Model Framework
SecuPi enables companies to easily comply with many of the most challenging requirements in 9 of the 17 domains (AC, AM, AU, CM, MP, RM, SA, SC, SI) while also providing some capabilities in several other Domains.
The following diagram highlights the functional capabilities of the SecuPi solution and the corresponding relevant CMMC Domains. Domains such as Physical Security of the actual data center facility also contribute to fundamental access control over sensitive information assets by protecting against someone walking out of the data center with a disk drive containing the data.
Figure 2: Mapping SecuPi Capabilities to CMMC Model Domains
The following diagram provides descriptions of each of the 5 levels from Basic Cyber Hygiene to Good Cyber Hygiene (required for hosting or processing CUI) to fully optimized, progressive controls capabilities.
Figure 3: CMMC Levels and Descriptions
Level 3 or above is required for any DIB company handling Controlled Unclassified Information (CUI),
Personally Identifiable Information (PII) or Private Health Information (PHI).
Note that PII and PHI are also considered CUI.
Specific Access Control related CMMC requirements for each level are listed below. Each of these are fully supported out of the box by SecuPi’s solution (Blue Text).
Level 1 Compliance
AC.1.001 Limit information system access to authorized users, processes acting on behalf of authorized users, or devices
AC.1.002 Limit information system access to the types of transactions and functions that authorized users are permitted to execute
AC.1.004 Control information posted or processed on publicly accessible information systems
Level 2 Compliance
AC.2.007 Employ the principle of least privilege, including for specific security functions and privileged accounts
AC.2.013 Monitor and control remote access sessions
AC.2.016 Control the flow of CUI in accordance with approved authorizations
Level 3 Compliance
AC.3.017 Separate the duties of individuals to reduce the risk of malevolent activity without collusion
AC.3.018 Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs
AC.3.019 Terminate (automatically) user sessions after a defined condition
AC.3.020 Control connection of mobile devices
AC.3.021 Authorize remote execution of privileged commands and remote access to security-relevant information
Level 4 Compliance
AC.4.023 Control information flows between security domains on connected system
AC.4.025 Periodically review and update CUI program access permissions
AC.4.032 Restrict remote network access based on organizationally defined risk factors such as time of day, location of access, physical location, network connection state, and measured properties of the current user and role.
CMMC requires strict enforcement of both Column and Row or Record Level Security (CLS/RLS) controls. Access to data may need to be limited based on a wide range or User attributes including physical location, nationality, security clearance level, job function, time of day or even the application used to access the CUI.
Common Misunderstandings
A common misunderstanding is that NIST SP 800-171, CMMC or other data privacy regulations like GDPR, CCPA, HIPAA, PIPEDA and many others require encryption of data at rest. Virtually no Data Privacy Regulations require Column Level Encryption of CUI, PII or PHI.
Fine-Grained Purpose Based Access Control (PBAC) is essential for CMMC. Any Column-level encryption or tokenization solution is simply trading RBAC for a Column with RBAC for a Key used to encrypt the Column. The same applies for tokenization of the same Columns.
Encryption and Tokenization should be used very selectively as an added layer of security for particularly sensitive data elements like SSN or credit card Primary Account Number (PAN) where only a few business processes (or users) rarely require access to the clear text values. In most cases SSN for example can function as a unique primary index key or unique secondary identifier with the values remaining encrypted or tokenized.
Fields that may require “Like” or “Range” comparisons, calculations (sum, average, min, max), alpha or numeric sorting are poor candidates for encryption or tokenization at rest.
Implementation timeframes, complexity and costs associated with any broad use of Column-Level Encryption or Tokenization of CUI will be unacceptable. Any project attempting to even encrypt or tokenize 3 to 5 PII Columns can take (24 to 36 months) just for a single large Enterprise Data Warehouse due to all the physical and logical data model changes to the underlying Database platform and all the required Application layer code changes, API calls and more that must be designed, developed, tested and implemented.
Operational and Performance impact of Column Level Encryption or Tokenization to protect CUI will be unacceptable to the business (major impact on Response time SLA’s).
Any solution must still meet all relevant CMMC Access Control (AC), Audit & Accountability (AU), and Risk Management (RM) requirements for Level 3 (CUI).
SecuPi provides a full suite of Column Level Encryption or Tokenization along with Dynamic Masking, Obfuscation and Anonymization with no changes to the data repository, no physical or logical data model changes, no View layer security controls (Where predicates, joins to security Tables), hard-coded Stored Procedures, Macros or User Defined Functions (UDF), and no agents to install on the Databases for Database Activity Monitoring (DAM) or Data Access Monitoring.
Summary
SecuPi or any one of our global implementation partners guide customers through the process of complying with NIST SP 800-171 and CMMC compliance audits by implementing the most advanced and most comprehensive Authentication, Authorization, Purpose or Attribute Based Access Control (PBAC/ABAC) and Accountability solution available.
What is required for compliance with CMMC and data privacy regulations like GDPR, CCPA and HIPAA is fine-grained PBAC or ABAC to ALL PII with full Accountability and Audit Trail regardless of where the data is physically stored or consumed. Physical location of the PII and the data consumer are just one Data attribute and one User attribute respectively that must be considered in controlling access to any regulated data.
Other data protection methods must also be leveraged to reinforce this access control and accountability. These include anonymization, obfuscation, encryption, tokenization, static and dynamic masking which when used appropriately enhance control and privacy compliance.
Any comprehensive solution needs to be centrally managed and incorporate a wide range of access control and data protection methods to independently, transparently, consistently and uniformly apply and enforce data privacy rules. These include but are not limited to Restriction of Use, Least-Privilege, RTBF, Geo-Fencing, Consent & Preference Management and more. The solution must be data layer and application platform agnostic and cannot require massive development efforts, code changes or modifications to core platforms without the risk of never being fully implemented or compliant.
The solution must support complex over-lapping hierarchies & matrixed access control requirements while being flexible and nimble enough to keep pace with constantly growing and changing data privacy compliance requirements.
Another critical component whenever CUI is hosted remotely by a DIB or by a Cloud Service provider is support for Hold Your Own Key (HYOK). When encryption or tokenization are used to provide customer or patient record anonymization, or an added layer of data protection for the most sensitive or identifiable PII fields, HYOK ensures that the keys remain On-Prem and only encrypted/anonymized records are hosted in the Cloud. Records can only be re-identified back On-Prem by authorized Users.
Cloud hosting of CUI by DIB companies may also involve compliance with FedRAMP requirements.
SecuPi’s implementation partners help customers leverage SecuPi’s fully configurable solution for satisfying multiple different interpretations of each applicable data privacy regulation, corporate risk tolerance, level of sensitivity of the regulated data and the geographic distribution of the data, users and business processes. SecuPi was the original inventor of Dynamic Data Masking over 10 years ago and has full support for HYOK encryption or tokenization along with advanced User Behavior Analytics, Anomaly Detection, Alerting and Blocking of anomalous or inappropriate access to CUI.
All this combines to deliver an easy to implement enterprise wide solution providing a single pane of glass control and compliance platform. Implementations that are measured in weeks, not months or years because no changes are required to existing data repositories or applications to comply with core CMMC requirements.
Virtually ALL Data Privacy and Data Protection Regulations DO require fine-grained access controls (incorporating least-privilege, need-to-know, basis, dynamic masking, record filtering, accountability, audit trail, detection & blocking of unauthorized access).
