• Jan 11, 2023

  

• Certified CMMC Assessor: Spinning the Wheels of Trust in Much Bigger Systems

  Nov 28, 2022

  

  Certified CMMC Assessors click into place as just another cog in a much larger system that already exists.

  Every objective that a CCA examines must already be legally met by Organization Seeking Certification. CMMC introduced no new requirements on Federal contractors. When people often complain about the cost of CMMC they do not mean the actual assessment but refer more to meeting the requirements a CMMC assessment measures.

  After the continued exfiltration of data and failed self assessments A third party validation of the system security plan was added to increase the trustworthiness of systems designed to process, store, and transmit Controlled Unclassified Information.

  According to NIST a system is a series of elements or components that together have a shared identity working towards a goal within the constraints of a specific environment and the requirements of the outcome.

  Organization Seeking Certification engineer security in their systems through systems security engineering. Originally the Government placed trust in organizations seeking certification. However recent evidence calls into doubt the trustworthiness of self reporting. The lack of trust in System Security Plans in turns cast doubt on the trustworthiness of the overall security engineered into a system.

  So through CMMC a third party assessment was added to assess trustworthiness and increase trust in the supply chain.

  Trust and Trustworthiness

  A CCA serves as the verification and validation method to assure with confidence that federal contractors protect the confidentiality of Controlled Unclassified Information. A CCA verifies the trustworthiness of the evidence an organization seeking certification includes in their System Security Plan. You validate that their tests to ensure the trustworthiness of their systems proves the Organization Seeking Certification

  Trust is a belief that an entity meets certain expectations and can be relied upon. The terms belief and can imply that trust may be granted to an entity whether the entity is trustworthy or not. A trustworthy entity is one for which sufficient evidence exists to its claimed trustworthiness.

  Verification and Validation of the System Security Plan

  As a Certified CMMC Assessor you verify and validate that an Organization Seeking Certification meets the security requirements of NIST-SP-800-171. In order for a System Security Plan to be trustworthy the OSC must have a demonstrated ability to satisfy expectations of protecting Controlled Unclassified Information

  Since trustworthiness is something demonstrated, you verify and validate the evidence that supports a claim or judgment of the CMMC practices being met.

  As a Certified CMMC Assessor you also serve a dual role of trust. As a trained assessor the Government can put trust in your assessment. As a Certified assessor the Organization Seeking Certification can trust your credentials. Trust is value judgment based on authority and evidence.

  In terms of Cybersecurity Maturity Model Certification program this means you examine the SSP and validate each CMMC practice to ensure there is sufficient evidence of trustworthiness in the claims being made by the Organization Seeking Certification.

  A CCA validates the trustworthiness of each claim an Organization Seeking Certification makes about meeting the security requirements assessment of NIST-SP-800-171 to protect the confidentiality of Controlled Unclassified Information.

  This means the verification and validation of each assessment objective. As an assessor you have to make sure the evidence is sufficient and adequate enough to ensure that each of the 110 security requirements has enough depth and breadth that the claims made in the System Security Plan can be trusted.

  Your role in the system is to increase the assurance that the Nation’s controlled Unclassified Information gets protected. According to NIST,

  Assurance is a complex and multi-dimensional property of the system that builds over time. Assurance must be planned, established, and maintained in alignment with the system throughout the system life cycle.

  In your roles of dual trust as a CCA you help to build assurances in the overall supply chain system. You also verify the evidence an OSC includes in a System Security Plan and validate how an organization establishes the trustworthiness of these claims in the trustworthy context.

  Trustworthy Context

  The trustworthiness context involves decision making and evidence based demonstrations that a system security plan can be trusted to protect the confidentiality of Controlled Unclassified Information. The Organization documents how they develop and maintain their assurances of meeting the security requirements of NIST-SP-800-171 and how they demonstrate how the assurance is satisfied. A CMMC Certified Assessor verifies and validates the System Security Plan as a decision-making context.

  When the Organization Seeking Certification writes how they meet the security requirements of each NIST-SP-800-171 objective they create an assurance case. This demonstrates how they cover the objective with enough depth and breadth to ensure we can trust the assurance case.

  As a CCA you will verify and validate the evidence in System Security Plans with a variety of quality. An effective SSP acts as an assurance case playbook. First a claim is derived from from security objectives Then the OSC connects to and documents credible and relevant evidence that substantiates the claims. Often the evidence get validated through ongoing testing and good system development life cycle practices. Basically Say What you do, explain how you do it, and prove it gets done. Have an assurance case for every assessment objective.

  Organizations with strong cyber hygiene present a compelling assurance case for all 325 objectives in NIST-SP-800-171.The result provide a statement that adequate security has been achieved and driven by stakeholder needs and expectations. Strong Systems Security Engineering helps to strengthen security and reduce the effort on validating and verifying assurance cases.

• Sep 29, 2022

  Hanging at Converge Security and learning about Conway’s Law at the Keynote addresds

• Developing a Rubric to Assess Policies and Procedures for CMMC Compliance

  Jul 19, 2022

  People panic when it comes to policy and procedures and CMMC. Rightfully so. Compliance with NIST-SP-800-171 at a miminum requires fourteen different policies and fourteen different procedures. Probably More. In fact NIST recommends 39 different plans, policies, and procedures for 171 compliance.

  While policy and procedures are not explicitly assessed by CMMC practices a majority of assessment artifacts imply the need for policy and procedures through explicit mention of document based specifications.

  Yet few people write policy and procedures. Even less do it well.

  To help you in creating compliant policy I have developed a series of “self-assessment” checklists for each Domain of CMMC.

  Why Policy

  Policy defines the governance of the systems you engineer to protect the confidentiality of Controlled Unclassified Information. Let us examine configuration management.

  Overall configuration management policy communicate senior management’s expectations to the company. A good policy, regardless of domain must have specific, measurable, and confirmable objectives. Policies providea top-down approach to define what is required and what is not permitted with configuration management.

  While policy defines the objectives for what must get done, procedures describe how the policy objectives get met through specific actions and results. Configuration Management procedures describe the methodology and tasks for each activity that supports implementation of Configuration Management policy.

  As a company meeting CMMC requirements you should document your configuration management policy and procedures during your planning phase. In fact NIST-SP-800-171 requires you to regulary review all policies and procuedres.

  What makes a Good Congifuration Management Policy

  You can not check CMMC Assessment guides for help with writing configuration managment. You will not find your answers in NIST-SP-800-171, but 171 will tell you where to look,

  In the back of NIST-SP-800-171 you will find Appendix E. This lists all the security controls the government assumes you do or controls they assume only apply to the federal government. These controls came from NIST-SP-800-53.

  The very first base control of every family in NIST-SP-800-53 is policy and procedures. If you look at NIST-SP-800-53a you can find a list of requirements for compliant policy. This provides a wonderful tool for you to assess your current policy.

  As a tool however it is hard to read.

  Why A Configuration Management Policy Rubric

  Self-assessment works in improving technical writing skills. We know from decades of research that theese metacognitive, or thinking about thinking, guides help to improve outcomes.

  To design these rubrics I went through the objectives of each Policy and Procudure for each Family in NIST-SP-800-53. This information is required but not assessed for NIST-SP-800-171 nor assessed for CMMC but required evidence for a CMMC assessment.

  Organization Defined Parameters

  In order to be technology agnostic and provide a more holisitic approach NIST rarely defines rules around roles, events, and freqencies. Instead your policy and procedures must have clear organization defined parameters that get enforced in policy and procudures

  In NIST-SP-800-53a these ODPs get explicitly defined and displayed in a table with the requirements but off set with grey shading. These requirements are just NFOd in NIST-SP-800-171.

  The Requirements in NIST-SP-800-53a then spell out what should go into each policy

  

  I tried to take this information and turn it into a checklist a company can use to evaluate their configuration management policy.

  Check it out the checklist

• Can you Engineer Culture in your Systems?

  Jul 11, 2022

  As we try to create online communities focused on open learning we have to recognize the troubled history open source has had with diversity, equity, and inclusion. Some bias is implicit due to systematic discrimination. You need to be well off to work for free.

  Often though we have seen countless explicit attacks such as Gamergate or even death threats against those doing Open Source Intelligence work to fight right wing extremism online.Before you can even begin to create an online community focused on open learning you need trust.

  For many we never engineered safety into the online communities we create and curate. Systems Security Engineering Approach to Culture

  Creating a Community as Your Curriculum (Cormier, 2008) takes a systems approach to engineering trustworthiness into the spaces you design. You can also think about your classroom culture, and the overall culture of your school as a system. in fact, our educational system is nested within this much larger system that many parents and students do not rightfully trust. By choosing a framework to develop an innovate and healthy online community you in turn reduce the threats to the members of your group that will do the learning work You also help build a better world.

  

  Once a framework is chosen systems engineering requires a set of iterative steps.

  Collect baseline data
  Identify goal you will engineer
  Acknowledge and identify blockers and variables of interest
  Develop a solution to address the goal without negatively impacting other systems
  Monitor the progress. Evaluate variable of interest.
  Iterate on the process
  

  When engineering for community we have to everyone recognize the cultural importance of safety. When trying to increase the overall hygiene of online communities you curate ,and thus engineer better trust in your system, you must first focus on the trust of potential and existing community members

  Dr. Kimberly Young-McLear, who won the 2017 Captain Niels P. Thomsen Innovation Award Winner for “Cultural Change for leveraging social media for large-scale disaster response.: has created the framework for a healthy and innovative workplace. Psychological Safety

  Psychological safety is paramount to good community culture. Dr, Young-McLear defines psychological safety as, “a service culture where all members have the confidence to serve as their authentic selves where self-knowledge, initiative, creativity, and self-empowerment are rewarded in an environment of interpersonal risk-taking.”

  The Internet has not always been a welcoming place as demonstrated in current news stories about harassment and stalking. Unrepresented populations need to feel safe in your community no matter their role. Online spaces improve when systematically marginalized groups of people share their perspectives and contribute to organizational solutions without fear of marginalization, retaliation, bullying, or discrimination. This can not happen without psychological safety.

  The model Dr. Young-McLear created integrates survivors of sexual assault, harassment, and racism. Marginalized groups are often ignored or for reporting incidents of abuse. The Web reflects our reality. The internet has never been a safe place for all. We must all work to create a places, online and in person where everyone feels safe and valued. This will increase the trustworthiness you engineer into your online community. Moral Courage

  Engineering an innovative and healthy environment also requires moral courage. This means all community members must feel compelled toward action to intervene against any culture or practice that inhibits the safety of any of our members. member of your organization must report violations of laws, policies, or your company’s mission, vision, and core values. Talk to potential members who have faced racism and discrimination in the past. Encourage a speak up culture. Cultural Competencies

  As you engineer an innovative and healthy workspace focus on growing key cultural competencies in your online communities

  Valuing diversity
  Having the capacity for cultural self-assessment
  Being conscious of the dynamics inherent when cultures interact
  Having institutionalized cultural knowledge
  Having developed adaptations to service delivery reflecting an understanding of cultural diversity
  

  Developing cultural competence systematically within a workforce requires subject-matter expertise and involvement by systemically marginalized groups. Over time as you grow your community may need to rely on experts in race, gender, gender identity, sexual orientation, religion, ethnicity, education, and ob position. In terms of addressing the systemically marginalized in online learning can look at the language used, the discourse patterns of leaders, and do recruitment outside of 24 hackathon events Inclusion

  According to Dr. Young-McLear inclusion is “individuals perceiving acceptance within the organization, as well as the ability to bring unique contributions to the workplace. Once your organizers have done the hard work of building psychological safety, moral courage, and cultural competencies feelings of inclusion will increase.

  We need more voices in for our online environments to thrive. We need communities explicitly inclusive to those who have faced trauma. Inclusion helps with both recruitment and retention. More importantly it makes your company safer. Research has shown diverse teams make better decisions. Diversity and Equity

  Diversity and equity share traits but have different impacts on the learning spaces you design. Diversity in the workplace means workers who are different from each other or come from different backgrounds. Diversity can involve constructs such as race, gender, age, etc. You need to think in terms of cultural, physical, and cognitive diversity.

  Only when your online spaces invest in diversity and equity can we hope to improve efforts to recruit, retain and members from systematically marginalized groups into technology. Diversity work often involves doing personal work more than outreach. Do not ask marginalized communities to put in extra effort to help you overcome their oppression. Mission Readiness and Innovation

  Once the foundation of psychological safety, moral courage, cultural competence, and diversity and equity get engineered into your systems the overall mission readiness of your online space may improve. Then innovation will follow. No matter the focus of your online community when people feel safe and there is a healthy exchange of free ideas innovation thrives.

• Guide to Microsoft's Security and Compliance Rebranding

  May 11, 2022

  

  Many people might stare with wide eye confusion at the naming conventions Microsoft has used in rebranding. Some of the services used in the government and by government contractors have a new moniker.

  Yet when you think about the changes the logic makes sense in terms of keeping compliance and security engines purring.

  Microsoft has a long established partnership with the Cybersecurity Maturity Model Certification community.

  In fact for the last five years, going back to when the System Security Plans (SSP) did not have their trustworthiness verified by a third party, the Seattle based company has retooled much of their information architecture to help the Government transition to the cloud and away from on-premises and boundary based protections.

  Microsoft has also created new tools to help with security and compliance. These efforts have lead to a rebranding of services companies will use for CMMC. Microsoft wanted to make a distinction between services for security and those for compliance.

  When you consider the Risk Management Framework (NIST-SP-800-37 and 39) that form the backbone of the 171 security requirements we think about a business at three levels:

  • Level One: Governance and Organization
  • Level Two: Business Processes
  • Level Three: Technical and Business Systems

  At each of the three level different assets, which include people, will have privileged and non-privileged roles. This means a user can access something at a specific tier other users can not access.

  In terms of the IA (information architecture) a company deploys they need to consider the Microsoft tools they choose for compliance and those they choose for security.

  Microsoft Azure and Microsoft 365

  The compliance and security services that Microsoft offers will cut across two different cloud platforms that people often confuse, Microsoft Azure and Microsoft 365. They each have different security and compliance needs and impact what controls a customer inherits from Microsoft or more like a Managed Service Provider. Microsoft 365 is a Service as a Software cloud (SaaS). This means all of your tools like Microsoft Office, Microsoft PowerPoint, and Visio. An organization seeking certification has limited responsibility with SaaS tools. You need to control access and training but Microsoft handles almost all the other security requirements.

  Microsoft Azure is more an Infrastructure as a Service (IaaS) or Platform as a Service (PaaS) depending on how an organization seeking certification deploys the service. Usually with IaaS a company does not control all their hardware or need to purchase the hardware. PaaS get used when you establish hybrid environments or create an enclave, for Controlled Unclassified Information, for example.

  Azure also gets used when Managed Service Providers, or security providers build apps in the cloud. For the end user the tool is a SaaS cloud model , outside of Microsoft, but for the company designing the tool they use Azure as a PaaS.

  As Microsoft focused on improving their services for CMMC they identified assets in both Microsoft 365 and Azure that an organization may use for security and those tools that will get used for compliance. These tools were rebranded and sorted into two different buckets.

  Security and Compliance

  When working on services that provide security to a Microsoft cloud deployment companies will work with the Microsoft 365 Defender portal. As part of a cloud first approach Microsoft has stopped the level of bifurcation between branding of their services. Azure Security Center is now Microsoft Defender for Cloud and Microsoft 365 Security Center is now Microsoft 365 Defender

  When working on services that provide governance, risk management, compliance (GRC)services, a cloud user will access the Microsoft Purview Compliance portal.

  Current name	New name
  Azure Purview	Microsoft Purview
  Azure Purview portal	Microsoft Purview governance portal
  Microsoft 365 compliance	Microsoft Purview
  Microsoft 365 compliance center	Microsoft Purview compliance portal
  Azure Purview Data Catalog	Microsoft Purview Data Catalog
  Azure Purview Data Insights	Microsoft Purview Data Estate Insights
  Azure Purview Data Map	Microsoft Purview Data Map
  Azure Purview Data Sharing	Microsoft Purview Data Sharing
  Azure Purview Data Use Management	Microsoft Purview Data Use Management
  Microsoft 365 Advanced Audit	Microsoft Purview Audit (Premium)
  Microsoft 365 Basic Audit	Microsoft Purview Audit (Standard)
  Office 365 Advanced eDiscovery	Microsoft Purview eDiscovery (Premium)
  Office 365 Core eDiscovery	Microsoft Purview eDiscovery (Standard)
  Microsoft 365 Communication Compliance	Microsoft Purview Communication Compliance
  Microsoft Compliance Manager	Microsoft Purview Compliance Manager
  Customer Key for Office 365	Microsoft Purview Customer Key
  Double Key Encryption for Office 365	Microsoft Purview Double Key Encryption
  Office 365 Customer Lockbox	Microsoft Purview Customer Lockbox
  Office 365 Data loss prevention	Microsoft Purview Data Loss Prevention
  Microsoft 365 Information Barriers	Microsoft Purview Information Barriers
  Microsoft Information Protection	Microsoft Purview Information Protection
  Microsoft Information Governance	Microsoft Purview Data Lifecycle Management
  Microsoft 365 Insider Risk Management	Microsoft Purview Insider Risk Management
  Privileged Access Management in Microsoft 365	Microsoft Purview Privileged Access Management
  Records Management in Microsoft 365	Microsoft Purview Records Management

  Do not let new naming conventions confuse you. The rebranded services from Microsoft provide the same catnip we have all come to love when dealing with Cybersecurity Maturity Model Certification.

  Img credit: Confused flickr photo by slava shared under a Creative Commons (BY) license

• May 9, 2022

  Matt Titcombe on the Compliance Trap from the Department of Defense.

• May 9, 2022

  Amira Armond on how inheritance and CMMC works.

• May 9, 2022

  Excited for Kyle Lai’s talk on ISO 2700. This is why I came.

• May 9, 2022

  Cole French a C3PAO on preparing for CMMC.

• May 9, 2022

  Victoria Pillitteri of NIST on future of 171

• May 9, 2022

  Leopold Wildenauer Datacentric approaches to Protecting CUI: CMMC and Zero Trust

• May 9, 2022

  Karen Evans, Why CMMC matters for SMBs.

• May 9, 2022

  Stacy Bostjanick, CMMC Director, at CMMC Day

• Apr 29, 2022

  

• CCMC: Asset Categorization and Systems Security Engineering

  Apr 24, 2022

  

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

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

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

  ASSETS AND RISK MANAGEMENT FRAMEWORK

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

  

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

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

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

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

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

  ASSET CATEGORIZATION AND CMMC

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

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

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

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

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

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

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

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

  This requires serious counting and then organizing what gets counted.

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

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

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

  “What operating systems are our laptops running?”

  “Which devices are vulnerable to the latest threat?”

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

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

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

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

  

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

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

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

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

  CONTROLLED UNCLASSIFIED INFORMATION

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

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

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

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

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

  SECURITY PROTECTION ASSETS

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

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

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

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

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

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

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

  CONTRACTOR RISK MANAGED ASSETS

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

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

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

  SPECIALIZED ASSETS

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

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

  OUT OF SCOPE ASSETS

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

  HELPING COMPANIES WITH ASSET CATEGORIZATION

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

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

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

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

  ---

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

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

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

  Second Post: CMMC and Systems Security Engineering

  Third Post: CMMC and Asset Inventory

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

  Fifth Post: https://flickr.com/photos/cowbite/820720997 shared under a Creative Commons (BY-SA) license by jgmac1106 shared under a Creative Commons (BY-SA) license

• Apr 24, 2022

  In reply to us06web.zoom.us/meeting/r…

  I just RSVPd

• CMMC: Systems Security Engineering and the Cloud

  Apr 23, 2022

  

  In systems security engineering requirements and constraints drive the design choices we make. They will send signals in a CMMC assessment. The constraints and requirements of an environment determines the type of evidence an assessor needs to verify. Organizations Seeking Certification and Certified CMMC Assessors will more than likely have to deal with many environments that utilize cloud deployments.

  What is the Cloud?

  According to NIST cloud computing enables, “ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) ,“ and that these resources take minimal configuration by the users.

  The Federal Government, using this definition for their cloud migration efforts defined five key characteristics of cloud environments.

  • on-demand service-Employees can access from any device
  • broad network access-Employees can access anytime or anywhere
  • resource pooling,-Employers share servers and infrastructure
  • rapid elasticity-Can scale to almost unlimited users
  • measured service-A third party maintains the system

  Cloud computing provides a developer agnostic pathway to building controlled environments, meaning there are multiple solutions in a variety of forms of deployment. According to according to NIST this includes:

  • Private Cloud- Provisioned for a single organization.
  • Community Cloud-A cloud provisioned for specific groups of users withn a company
  • Public cloud-provisioned for general community use and not used in business setting often
  • Hybrid Cloud-A combination of any two above

  Cloud Security Requirements

  The shared services layer introduced into the system will impact the security engineered into the system and the assessment procedures used by a Certified CMMC Assessor. This service layer depends on the cloud service model used by the organization.

  According to CISA’s Cloud Security Technical Reference Architecture the service model will determine security requirements.

  

  NIST defines four services models as illustrated in the figure from CISA’s Cloud Security Technical Reference Architecture:

  • On-Premsises
  • Infrastructure-as-a-Service
  • Platform-as-a-Service
  • Software-as-a-Service

  Regardless of the service model all cloud environments must get engineered to meet the same basic security requirements as spelled out in Federal law and regulation.

  Shared Responsibility Matrix

  An assessor, in conversation with the OSC, must determine what and who is in scope. The majority of security requirements these assets introduce will all get documented in a shared responsibility matrix. An assessor will want to verify the FedRAMP equivalency seeing a document that outline who manages what security requirement if the cloud assets store, transmit or process unencrypted CUI. All cloud deployments, regardless of the service model, require a shared responsibility matrix for a CMMC assessment. Any FedRAMP authorized CSP must submit a responsibility matrix as part of their authorization package. Many organizations use that document to build their CMMC 171 SRM.

  NIST-SP-800-171

  These service models influence the security requirements engineered into a system and move the shared responsibility of meeting the requirements from the Organization managing them to the vendor managing the requirements. Regardless of the shared service layer engineered into the system the Organization Seeking Certification is always responsible for documenting and meeting the requirements.

  Export Control

  If an organization holds export-controlled data under ITAR or EAR new security requirements get introduced. This data requires data sovereignty for the cloud or must meet encryption requirements inside of a controlled environment and then remain encrypted the entire time in the cloud. Meaning never available in a readable format to anyone until downloaded and unencrypted back in the controlled environment. Only the organization and not the vendor should hold the keys to the data. Any vendor support must get restricted to US persons.

  FedRAMP-Moderate

  Cloud services, based on DFARS 252.204-7012(b)(2)(ii)(D), that store, process, or transmit Controlled Unclassified Information must meet the FedRAMP Moderate baseline or its equivalent. Thus if an organization uses a cloud service to support security such a s a SIEM, that tool does not need FedRAMP Moderate equivalency because it does not store, process, or transmit CUI.

  Incident Reporting

  In scope cloud service providers that store, process, or transmit CUI must also meet the incident reporting requirements of DFARS 252.204-7012(c-g). Any incident must get reported to the Department of Defense within 72 hours and images of the system must get preserved for 90 days. The DoD may want access to the equipment. This means a Cloud vendor must accept the contractual flow down of DFARS 252.204-7012

  A CMMC assessment only verifies the trustworthiness of 171 security requirements. It is not a DFARS or EAR compliant assessment. That being said an assessor may verify if your Incident Response Plan meets DFARS requirements. If your policy and plans state you are in compliance with other security requirements the assessor will verify the procedures and evidence to ensure “you say what you do and do what you say.”

  Cloud Environmental Constraints

  Migrations take time if an organization thinks they may hold CUI in the future. A Prime contractor may demands compliant environment regardless if they flow CUI down to an organization in a contract. In these situations an OSC should consider a compliant cloud environment given the time migration takes. Time is often the toughest constraint in systems security engineering.

  Regardless of deployment, cloud often refers to connecting to servers maintained by other organizations. How an organization utilizes the cloud depends on stakeholder needs and system constraints. A company inherits, or shares much of the security responsibility with a cloud vendor. This often gets represented in a shared responsibility matrix.

  Thus an Organization Seeking Certification and a Certified CMMC Assessor will need to understand how employees connect to the cloud based infrastructure. Security requirements around encryption are very specific in CMMC. The baseline policies must apply constraints on users in how they access the cloud. You must also determine if a managed service provider is in scope and if they have access to the CUI stored in the CSP.

  The world of IT, or Information Technology, has faced monumental shifts in the last three decades. We have moved from fixing a spool on a dot matrix printer to proving audit logs on endpoint detection.

  From a Systems Security Engineering perspective, this changing relationship between IT companies and members of the Defense Industrial Base introduces to requirements and constraints on security of your business.

  When creating a system for the way Controlled Unclassified Information flows through your networks an Organization Seeking Certification must understand the difference between key partners. Incorrect decisions could leave a third party and their systems in-scope of your assessment. This not only greatly increases costs but puts data at greater risk. The service models depend upon the people behind them.

  CSP, MSP, MSSP What is the difference?

  Utilizing NIST definition of cloud based computing we know that cloud solutions cut across five characteristics, three service models, and four deployments

  Characteristics	Service   Models	Deployments
  On-demand   self-service     Broad   network access     Resource   Pooling     Rapid   Elasticty     Measured   Service	Software as   a Service     Platform as   a Service     Infrastructure   as a Service	Private   Cloud     Community   Cloud     Public   Cloud     Hybrid   Cloud

  This defines the software, but what about the people? CMMC-AB and NIST go out of their way not to define the difference between Cloud Service Provider, Managed Service Provider, and a Managed Security Service Provider. The scoping guidance refers to all external service provider the same and the NIST page lists the definition of Clous Service Provider as none.

  

  NIST-SP-171-800 and CMMC scoping rely on a data centric model and the vendor delivering services does not change the security requirements. The people you choose to work with do change the evidence collection needs to meet the requirements and do introduce new constraints.

  As an Organization Seeking Certification you need to consider these requirements and constraints as you evaluate partners. An Assessor will need to evaluate the requirements and contraints of an environment when developing assessment procedures.

  What is a Cloud Service Provider?

  A cloud service provider gives you access to computing networks and servers that they own and maintain. Google Docs SaaS that Google provides as a cloud service provider. Microsoft is a cloud service provider with different levels of security.

  CSPS have their own requirements when it comes to establishing the trustworthiness in the system an Organization Seeking Certification throws. The evidence you must collect will change. Afterall Cloud Services Providers manage SaaS (Software as a Service), PaaS (platform as a service) or IaaS (infrastructure as a service) for users. This introduces new requirements and constraints to your system security engineering.

  A cloud service provider hosts all of your data and thefore must meet the requirement of protecting CUI while in transit and at rest. Some types of CUI must require the data get stored in the United States. There are even requirements for cloud computing spelled out in Defense Federal Acquisition Regulation Supplemental.

  What is a Managed Service Provider?

  The contrast between MSPs and cloud services providers revolves around access control. MSPs manage and maintain technology that you own or license, whereas CSPs offer access to technology that they own. MSPs may manage both on-premises and cloud-based infrastructure for their customers. The MSP, however, does not own or control the underlying cloud infrastructure that stores your data or Controlled Unclassified Information.

  MSPs also have their own requirements when it comes to developing evidence for compliance with CMMC Practices. They often act as IT Departments for companies that do not have them. An MSP acts as a partner and they may handle important tools such as Active Directory, data backup, anti-virus, and other IT functions. All of these fall in scope in a CMMC assessment.

  Whether an MSP falls in scope of your assessments will depend on the services they provide. Some my partition systems but through asymmetric key encryption never have access to any credentials or assets. Other MSPs may have physical access to networks and a company may treat these technicians as in scope employees. The service level agreements and shared responsibility matrices will drive your security requirements.

  What is a Managed Security Service Provider?

  A managed security services provider (MSSP) provides oversight of specific security tools. These tools may not store or access CUI but they protect assets that do fall in scope. An MSSP focuses security services, such as firewalls, virus protection, and intrusion detection, They may provide a SIEM, or Security information and event management. MSSPs often specialize in a particular area, such as managed firewall service providers.

  According to the CMMC Level Scoping Guide “Security Protection Assets are part of the assessment scope and are required to conform to applicable CMMC practices, regardless of their physical or logical placement.”

  The scoping guidance spells out that an MSSP falls in scope for all-applicable CMMC practices. Yet the same can be true of a CSP or MSP as well.

  As you apply systems security engineering to meet the requirements of a CMMC assessment you must evaluate your partners. Examine the service level agreements you have, consider the time of deployment and migrating between a cloud or service provider. You need to choose compliance partners when evaluating vendors.

  What is Hybrid?

  A hybrid deployment combines onprem servers with cloud-based servers. Some organization may want to keep control of servers that store credentials for cloud computing. Others may have out of scope on prem servers they maintain but provision a private cloud for employees authorized to handle Controlled Unclassified Information.

  A hybrid cloud infrastructure may connect to a public cloud platform from a trusted third-party provider. Hybrid deployments may also utilize a private cloud partitioned on premises. A company may utilize hosted private cloud provider and allow employees to connect to the servers. A CMMC Assessor will often find an in-scope managed service provider may maintain the hybrid environment.

  Hybrid Environmental Requirements

  Like all environments the hybrid cloud must meet the same security requirements. The use of the hybrid environment just changes the metrics and evidence used to ensure the security requirements of NIST-SP-800-171.

  The people who maintain the environment introduce evidentiary requirements. Any on-prem deployment of tools will need a focus on the privileged users who can access those tools. Hybrid deployments can either introduce the most complicated requirements to document or help an organization shrink their scope by utilizing a cloud-based service. They are difficult to maintain but can provide benefits to those who take advantage of increased on-prem solutions with the scalability of cloud services.

  For example, you will need to think about the access to both the logical and physical barriers that store servers. A company will need to make sure their inventory disposal polices align with the requirements set out in the Media Protection domain. Many smaller companies may try to utilize a hybrid approach managed by an MSP. Some organizations keep their access control logs and Identify Managament systems onprem and data in the cloud. This will impact the evidence collected to demonstrate security requirements get met.

  An MSP may or may not be in-scope or have access to your Controlled Unclassified Information in an unencrypted state. If they provide security to systems that protect CUI either on-prem or in the cloud you will need to show how the MSP handles the applicable security requirements they manage.

  Hybrid Environmental Constraints

  Hybrid environments can bring all the environmental constraints of on-prem or cloud deployments while leaving a managed service provider in scope. On the other end of the spectrum hybrid environments in a private cloud using asymmetric keys for authorization can shrink a company’s scope down to a few assets.

  The difficulty in maintaining hybrid environments introduce many constraints. First you need to make the relationship and boundaries visible in all your data flow and network diagrams. Cost and time always act as constraints in systems security engineering. In hybrid solutions you may have to support two disparate solution who do not “talk computer together.” This introduces bespoke coding and architecture that presents a new threat vector. If these systems have data interoperability constraints even more challenges get introduced.

  At the same time Hybrid solutions can often help small businesses who may have only limited exposure of CUI in their on-prem environment. So if a manufacturer only had two to three machines that process CUI they may utilize a hybrid environment to share controlled technical information with remote employees. The CUI gets encrypted before it goes to the remote employee. The remote employee only works on a local device not connected to their network. They rencrypt the file before sending back within the onprem physical boundary.

  Hybrid environments managed by high quality MSPs can provide flexibility, reduced cost, and the ability to scale.

  What is On-Prem?

  An on-premises environment, often on-prem for short, means all in scope software and systems exist withing the physical and logical boundaries of an organization. The organization seeking certification is responsible for managing, maintaining, and supporting all systems and the security of the assets who access those systems to process, store, or transmit Controlled Unclassified Information.

  On-Prem Environmental Requirements

  On-Premises environments can bring the same regulatory and security requirements of Cloud and Hybrid deployments but the organization is responsible for managing all the security requirements of the software and hardware. The vendor has no responsibility.

  The network diagrams and data flow diagrams will dictae what evidence a Certified CMMC Assessor must collect to assess on-prem environments. An IT department or External Service Provider must maintain layers security, encryption, and protection of key boundary points.

  On-Prem, however, is not a unified deployment. Companies may have multi-site environments that connect to these systems. Overall on-site staff or contracts must maintain all software, hardware, access control, and physical security. This introduces specific evidence requirements for a CMMC assessment.

  On-Prem Environmental Constraints

  A company maintains all the servers, firewalls, and routers. The necessary resources create a sever constraint on maintenance. The cost of deprecating equipment may have advantages to cloud environments. The over reliance on Managed Service Providers that maintain IT systems may increase the scope of security requirements.

  NIST-SP-800-171 approach to security relying on logical and physical boundaries meets the constraints of on-rem deployments for many companies. However recent security guidance and costs often drive businesses towards the cloud.

  Considering the ease of compliance for on-prem deployments may influence the design decisions and organization seeking certification makes. Other companies may choose on-prem solutions out of sheer size of their organization. A Certified CMMC Assessor will need to pay attention to the privileged access users have to key boundaries that protect physical access to servers. Organization who utilize on-prem solutions, will also need to detail who maintains the security updates to any of these assets. Most importantly they will have a reference architecture that explains the separation techniques that protect CUI.

  Right Fitting your Cloud Deployment

  Almost all organizations will have some element of cloud in their systems. From a Systems Security Engineering persepective each service model impacts the requirements and constraints a company must consider in their risk based awareness plan and daily operations.

  Systems Security Engineering broadcasts that an organization takes their security requirements serious regardless of the contrainsts they face.

  ---

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

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

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

  Second Post: CMMC and Systems Security Engineering

  Third Post: CMMC and Asset Inventory

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

  Img Credit: lost in transmission flickr photo by savoryexposure shared under a Creative Commons (BY-SA) license

• CMMC Assessment: In Systems Security Engineering the Environment Drives Evidence

  Apr 22, 2022

  

  From A Systems Security Engineering perspective, the environment will drive the evidence collected to ensure an organization seeking certification meets security requirements.

  For both the assessor and the contractor considering the impact of scope on how their systems gets deployed will be the largest driver in the cost of engineering a system and meeting security requirements. An Organization Seeking Certification must collect to meet the 320 objectives of a CMMC assessment. Assessors will need to consider the environment and the separation techniques used when deciding on what assessment procedures to use.

  Systems rely on the separation of physical and logical boundaries to ensure only those with a legal and authorized need access Controlled Unclassified Information. In fact, when designing controlled environments as part of our systems we must consider the environmental constraints of each possible deployment.

  The security requirements for storing, processing, or transmitting CUI for any deployment are the same. The requirements for export-controlled data are the same regardless of the environment. Incident reporting requirements are the same no matter the system an OSC engineers.

  You have a CMMC assessor come and verify the trustworthiness in your meeting the security requirements of NIST-SP-800-171. The environments used in the system will have an impact on the evidence used to justify a rating. The assessment procedures used by a certified CMMC assessor will change based on the environment.

  By analyzing constraints and requirements across the life cycle of a contract, thus utilizing systems security engineering, an organization identifies the type of evidence a Certified Assessor may collect to verify the trustworthiness of the System Security Plan based on their deployment

  Environmental Constraints and Separation Techniques

  When engineering a system an organization must consider how Controlled Unclassified Information does or does not move through logical and physical boundaries. Utilizing separation, or “system architecture design concept that can provide physical/logical isolation of assets that process, transmit, or store CUI from assets not involved with CUI” an organization can protect CUI from unauthorized disclosure.

  When an OSC accounts for different environments and their constraints they collect the unique evidence needed to demonstrate the security requirements get met.

  Where Do In Scope facilities Exist?

  Modern deployments range from on-premises where an organization maintains responsibility for all software, equipment, and physical to cloud based software-as-a-service platform where the organization maintains only limited control over domains such as access control and the vendor handles all other security requirements.

  Unless organizations utilize separation, techniques and keep all CUI in a system with security measures such as DMZ , layered boundary protections, and air gapped systems or an organization keeps an entire system in scope an assessor will be working with cloud environments.

  “Cloud Smart,” rather than “Cloud First” was initiated in 2017 as a result of the Report to the President on Federal IT Modernization. Cloud Smart emphasizes the three pillars of security, procurement, and workforce. These three principles work in systems security engineering while also introducing specific requirements and constraints to the environment.

  The biggest impact Cloud has on a CMMC assessment is introducing a shared services layer to the environment. As soon as an organization uses a cloud vendor for in-scope services or uses security tools in the cloud they share the security requirements and must document who and how they get met across the organization. The CSP is not assessed during a CMMC assessment, but the assessor will need to establish the trustworthiness of shared responsibility.

  These requirements and constraints have an impact when assessing organizations. As you engineer a system that meets the security requirements of NIST-SP-800-171 you need to determine your environment and consider the constraints and requirements across the lifecycle of your deployment.

  ---

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

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

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

  Second Post: CMMC and Systems Security Engineering

  Third Post: CMMC and Asset Inventory

  img credit: Drive flickr photo by astarothcy shared under a Creative Commons (BY-SA) license

• CMMC, Asset Inventory, and Systems Security Engineering

  Apr 20, 2022

  

  You cannot protect what you do not know you have.

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

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

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

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

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

  Systems Security Thinking

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

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

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

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

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

  Problem	Solution	Trustworthiness	Analyze
  Identify and plan for enabling systems for IATM Define metrics of success Identify CMMC practices impacted by inventory Update SSP	Develop IATM Policy Create baseline for enabling systems Deploy enabling systems Create a lifecycle for any asset Identify stakeholder assets and asset categorization Apply security metadata tagging Develop a RACI model for any asset and enabling system or process Update SSP	Develop a scenario on how IATM system should work. Compare and identify assets from data collected during vulnerability scans Create traceability of inventory Update SSP and POAM	Analyze how enabling systems can further automate IATM Analyze impact on reference architecture if any systems got updated, removed, or added Update SSP and POAM
  Continuous Feedback Loop	Continuous Feedback Loop	Continuous Feedback Loop	Continuous Feedback Loop

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

  What Goes into Inventory?

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

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

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

  What is IT Asset Management (ITAM)?

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

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

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

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

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

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

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

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

  IATM and System Security Thinking

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

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

  ITAM and Asset Lifecycle

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

  • Enrollment
  • Operation
  • End-of-life

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

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

  Enrollment

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

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

  Operations

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

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

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

  End-of-Life

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

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

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

  Planning for the Future: Configuration as Code

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

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

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

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

  ---

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

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

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

  Second Post: CMMC and Systems Security Engineering

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

• System Security Engineering and CMMC

  Apr 18, 2022

  

  Every organization has a philosophy behind their system security plan.

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

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

  These leaders made a philosophical choice.

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

  Philosophy and Cybersecurity

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

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

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

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

  Systems Thinking

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

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

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

  System Security Engineering

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

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

  Lifecycle of System Security Engineering

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

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

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

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

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

  The System Security Plan

  

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

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

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

  System Security Engineering and Compliance

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

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

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

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

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

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

  Apr 13, 2022

  

  You do not jump out of a plane without first making sure a parachute works. Yet many Organization Seeking Certification (OSC) want to make a leap of bling faith about their compliance to the practices in the Cybersecurity Maturity Model Certification.

  When an Organization Seeking Certification (OSC) contacts a Certified Third Party Assessor Organization (C3PAO) they will not immediately accept ytheir business. Having someone pay for an assessment when a five minute phone interview can evaluate readiness, or lack there of, of an organization would lead to unethical profits. Assessments are a tandem jump between the C3PAO and and the OSC. Both parties have a vested interest in knowing the parachute opens and covers all in-scope assets.

  A C3PAO evaluates an organization as much as a OSC evaluates the assessment team they hire.

  Where should an OSC expect a C3PAO to begin?

  Scoping. The C3PAO needs to scope the assessment which means they need to understand how you scope your networks and systems and how CUI flows through the assets, people, technologies, and facilities, that make up your systems.

  For example a C3PAO needs to understand the difference between virtual and physical locations of your assets. Do you have servers, “on prem” or do employees connect to an enterprise cloud? Can employees share and hold CUI on mobile devices? Do employees at home store and transmit CUI?

  All of these questions impact the annual cost of your engineering and non-engineering costs each year. They determine the cost of a CMMC assessment. In fact no assessment should occur without knowing the difference between the logical and physical locations where in scope and out of scope assets exist.

  What documents should I have ready?

  As an OSC you must have a system security plan. You can not have an assessment without one. Yet your documentation needs stretch beyond the SSP. In fact to even begin a CMMC scoping conversation an Organization seeking certification should have the following document based specifications:

  • Network Diagrams
  • Data Flow Diagrams
  • Reference architecture
  • Asset Inventory
  • Access Control Policies

  These documents will not only explain the difference between your physical and logical techniques of separation used to protect CUI but also identify the owners and maintainers of the assets. As an OSC you can limit the numbers of assets in scope and reduce the cost of the assessment.

  NIST SP 800-171 Rev 2, which states:

  those organizations may limit the scope of the security requirements by isolating the designated system components in a separate CUI security domain. Isolation can be achieved by applying architectural and design concepts (e.g.,implementing subnetworks with firewalls or other boundary protection devices and using information flow control mechanisms). Security domains may employ physical separation, logical separation, or a combination of both. Basically when considering the logical and physical locations we always want to make sure the separation of assets legally authorized to process CUI. Logical boundaries, "set is physically (wired or tirelessly) connected to another asset or set of assets, but software configuration prevents data from flowing along he physical connection path." Your data flow diagram will demonstrate how Controlled Unclassified Information moves through your system. This will help you understand how to develop a more detailed network diagram. The network diagram would show all the firewalls that route traffic and only allow authorized assets to connect to the system. An access control policy identifies the authorized people with a matrix of role based access or other ways of user separation. We include an asset inventory to identify authorized devices. The asset inventory needs to track the software development life cycle of the device and includes information about the device owner and maintainer.

  Why do these documents matter?

  These documents prove a state of readiness for a CMMC assessment, but your really need to think of them as part of your life cycle approach to proving you implement the 110 security requirements of NIST-SP-800-171.

  Basically you need to develop a systems engineering approach. In fact the most subjective of almost all of the security practices in CMMC revolves around security engineering.

  SC.L2-3.13.2 – SECURITY ENGINEERING

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

  ASSESSMENT OBJECTIVES NIST SP 800-171A

  Determine if:

  • a architectural designs that promote effective information security are identified;
  • b software development techniques that promote effective information security are identified;
  • c systems engineering principles that promote effective information security are identified;
  • d identified architectural designs that promote effective information security are employed;
  • e identified software development techniques that promote effective information security are employed; and
  • f identified systems engineering principles that promote effective information security are employed.

  Adjectives and adverbs add a degree of scale to assessment objectives but also subjectivity. What does “effective” mean? How do we demonstrate to an assessor, as an organization seeking certification we identify and deploy “effective information” security, techniques, and principles?

  It begins with the document based artifacts that will have specifications proving you identify and deploy effective practices. “Effective information” architecture relies on technical information but also good project management. For example moving your security plan to a six month or annual cycle where you revisit the SSP and POAM while triaging not met practices during monthly meetings helps to support the technical understanding necessary.

  So many examples of effective information practices exist. So do many more ineffective examples. Of course you must establish security policies, you may develop layered protections so multiple boundaries protect key architecture. Some organizations place controls as the foundation for their design. Everyone must incorporate security requirements into the system development life cycle. In other words has a devices passed end of life for security patches. Reference architecture contains your network diagrams that delineate physical and logical security boundaries. It will list all the key security assets that protect key boundaries.

  You also need to consider in scope people when developing a systems engineering plan. For example anyone with privileged access, meaning they control security of assets or perform functions on systems others can not need different training on how to deploy secure software. Other employees may do risk awareness training and perform threat models to mitigate risk.

  To provide enough evidence for the depth and breadth for the assessment objectives of this practice you basically need to demonstrate that you have system architecture policy that can act like a guide and explains the architecture. You will include, for example, if you deploy different networks to logically separate in-scope and out of scope assets.

  SC.L1-3.13.5 – PUBLIC-ACCESS SYSTEM SEPARATION

  Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.

  ASSESSMENT OBJECTIVES [NIST SP 800-171A]

  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.

  Network diagrams will docmument to a CMMC Certified Assessor that an OSC should provide the necessary logical and physical separation of in-scope and out of scope assets.

  Controlled Unclassified Information takes an authorized legal need to access, store, or transmit. You can not just give access to the public to the CUI nor to the networks on where it gets transmitted and stored. In fact separating public accessible systems, like a company website or public wifi from the servers storing encrypted Federal Contract Information is a level one control. Remember the practices are cumulative . A CCA will assess all level one and level two practices for a Level 2 assessment.

  Often companies will use a cloud enclave for CUI to keep the data stored away from the public. Other companies will create a DMZ, a demilitarized zone, or subnetworks. An OSC may have one subnetwork for employees, one for the public, and one for in-scope employees to transmit and store CUI.

  By providing a C3PAO with a network diagram you provide readiness for your assessment. This also provides evidence that would speak to the breadth of your your security requirements. A CCA would add to the depth of the coverage by interviewing the people who protect the boundaries.

  CM.L2-3.4.5 – ACCESS RESTRICTIONS FOR CHANGE

  Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems. ASSESSMENT OBJECTIVES [NIST SP 800-171A]

  Determine if:

  • a
  physical access restrictions associated with changes to the system are defined;
  • b
  physical access restrictions associated with changes to the system are documented;
  • c
  physical access restrictions associated with changes to the system are approved;
  • d
  physical access restrictions associated with changes to the system are enforced;
  • e
  logical access restrictions associated with changes to the system are defined;
  • f
  logical access restrictions associated with changes to the system are documented;
  • g
  logical access restrictions associated with changes to the system are approved; and
  • h
  logical access restrictions associated with changes to the system are enforced.

  In fact a CCA will assess how an Organization Seeking Certification restricts access to people who can make critical changes to your system.

  Basically in order to have the system engineering in place for an assessment an organization should harden physical security at a uniformed layer. What must any employee or guest do to enter the building. You will need to monitor who comes in and control how they enter. If someone needs access to areas where systems changes can be made you need Follow them while they are there, and document why they are there. These steps must be spelled out in policy and procedures ahead of time. .

  So your access control policy, a key document in getting a conversation started with a C3PAO should, “Define, identify, and document qualified individuals authorized to make physical and logical changes.” This could include employees or managed service providers whp have access to the organization’s hardware, software, software libraries, or firmware

  Overall before you begin an assessment you need to demonstrate that you implement physical access control that prohibits unauthorized users from gaining physical access to an asset. You may use a key card or key pad entry to enter a server room. Your access controls should not allow regular users to log into security software. Some companies may use software that has automation with management workflow rules that define tasks such as seeking approval to change a server. A common technique is to use multiple boundaries such as only allowing patched from a specific IP management system but still requiring a manager to authorize execution.

  The network diagram, asset control policy, and asset inventory will all help a C3PAO understand the difference between the logical and physical controls of an OSC’s location. These documents will demonstrate how separation gets protected with access control.

  An Organization seeking certification not only must demonstrate their scope and network to a C3PAO but they should also explain how they perform system maintenance control on a system.

  MA.L2-3.7.2 – SYSTEM MAINTENANCE CONTROL

  Provide controls on the tools, techniques, mechanisms, and personnel used to conduct system maintenance.

  ASSESSMENT OBJECTIVES [NIST SP 800-171A]

  Determine if:

  • a tools used to conduct system maintenance are controlled;
  • b techniques used to conduct system maintenance are controlled;
  • c
  mechanisms used to conduct system maintenance are controlled; and
  • d personnel used to conduct system maintenance are controlled.

  These tools do not store or process CUI assets on a system but do “diagnostic and repair actions on those systems.” Viruses and malware get introduced all the time through bad patching or remote management maintenance tools.

  Companies have flexibility in implementing these requirements but this control illustrates how important asset inventory is when starting a conversation with a C3PAO. You can not approve maintenance tools without knowing what maintenance tools you need.

  Once you know the tools you need you should include the who is in charge of the maintenance and link to a document tracking the software development life cycle, basically when di you add the software, the version, operating system, controls it meets, business function it plays, when it gets updated, and when the software is no longer supported.

  Scoping Matters

  The four controls highlighted demonstrate how document based artifacts help to provide the breadth of evidence you utilize to demonstrate you meet the requirements of an objective. Yet these documents also provide a jumping off point for a C3PAO to evaluate an organization seeking certification.

  If a company has not documented the differences between the logical and physical locations of their assets than they can not get a CMMC assessment.

• CMMC and Asset Inventory

  Apr 11, 2022

  

  Asset Inventory will drive your compliance. Whether you rely on the shared responsibility of zero trust models or protect information at your boundaries, asset inventory drives your security. When determining the cost of both compliance and security asset inventory drives your scoping.

  Asset Inventory Matters.

  You can not protect what you do not count.

  What should good asset inventory be an inventory of?

  Before we get there consider your process. How will you count the stuff you want to protect? Once a company gets over 5-10 employees mandatory inventory hurts. A lot. Not only is it time consuming but the data quickly falls out of date.

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

  Before you count stuff you must figure out how you will count it but you need to be strategic. For example a company may use their vulnerability scanner to identify assets connected to a system or they may use a spreadsheet and inventory scanners. Just develop a plan that helps to automate as much as possible while considering the many different practices of CMMC.

  What Goes into Inventory?

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

  As Jill Lawson notes you will want to expand the CUI assets to a greater extent and include links to a CUI Management plan:

  that identifies what CUI or CTI is being protected, who has access to it, where is resides at rest, how to dispose it, and the process of notifying the KO if a risk of aggregation of the CUI arises

  .

  A CUI policy is one of the delta twenty practices that got cut from CMMC 2.0 and is listed as an NFO, an Appendix E of NIST-SP-800-171. As in the government assumes this is something you do. As an NFO control that means, while not assessed it is an expectation that you meet this for compliance with DFARS-7012.

  Source: NIST SP 800-40r4 Guide to Enterprise Patch Management Planning:Preventive Maintenance for Technology

  img: Counting flickr photo by anno.malie shared under a Creative Commons (BY) license

• Apr 7, 2022

  

• Apr 7, 2022

  Any great conference should close with Amira Armond.

subscribe via RSS