Table of Contents:
Section 3.11.1
Section 3.11.2
Section 3.11.3
Section 3.12.1
Section 3.12.2
Section 3.12.3
Section 3.12.4
Does Your Business Need Help Achieving CMMC Compliance?
Don't want to read the article? Watch the full recording below.
Be sure to register here for the Cybersecurity for the Rest of Us webinar series!
3.11.1: Periodically assess the risk to the organizational operations (including missions, functions, image, or reputation), organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.
The important part of this section I'd like to point out is to understand and clearly define the system boundaries for your organization. This means you need to determine what is considered in-scope and out-of-scope for your risk management and assessment.
You'll also need to determine the types of risk you will assess, such as threats and vulnerabilities and the likelihood of them happening.
Don't forget to consider risk introduced by supply chain vendors, suppliers, and maintenance staff as well.
Consider also working with an unbiased 3rd party assessor, but if you do, make sure they come in from the very beginning or after you've completed your own security risk assessment and mitigated as much risk as possible.
Defining your scope isn't mean to be a way to game the system, it's meant to clearly put a fence around what you're looking at.
3.11.2: Scan for vulnerabilities in the organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
Most people come back to a simple question, "Is what I'm doing enough?" This is a hard term to define, but let's start with one basic fact: You need to ensure that everything that CAN be scanned for security threats IS scanned.
While NIST SP 800-171 r2 doesn't identify a recommended frequency, you need to consider a timeframe that allows reasonable allotment for identification, remediation, and QA. Don't overlook any local, state, federal, or contractual obligations that may supersede CMMC efforts by dictating a "no-less-than" frequency.
Consider implementing ad-hoc scanning periods when zero-day or critical vulnerabilities are discovered, and if you develop non-COTS software, consider static and dynamic code testing as part of your application security scanning program.
While there's nothing specifically called out, static and dynamic code testing is recommended, and should be part of the vulnerability management process. This makes discovery and remediation much easier and cheaper!
3.11.3: Remediate vulnerabilities in accordance with risk assessments.
This part is all about developing a business process for remediation of the risks you find during your assessment.
Note the difference between remediate and mitigate. Remediation means completely eliminating the issue and the risk associated with it. Mitigation may be a level of remediation.
Maybe you can't complete everything that's expected because it will break the information systems, but you can mitigate 80% of vulnerability and leave the system intact. Do so, and document why you can't fully remediate the entire risk.
This 80% mitigation will put your infrastructure at a much lower risk level during your next risk assessment.
Consider the level of effort, products, and labor costs required to remediate.
You have to start somewhere. Maybe you start with less-than-ideal timelines, such as "I'll remediate high-level priorities in no more than three months." While this isn't nearly fast enough, it at least gives you a baseline. If you keep this up, your team will continue to improve year over year as systems vulnerabilities are addressed.
Don't assume that just because you can't reach the ideal, you shouldn't try at all. You MUST create a "good, better, best" model and explain your position. As long as you can justify your position, you should be in good shape.
Also be sure to develop standardized timelines for remediating different security issues based on levels of severity. These need to be viewed as "reasonable" response times by your peers and/or auditors. These timelines must be followed once they're put in place, or you'll be viewed as contradicting your own information security policies.
3.12.1: Periodically assess the security controls in organizational systems to determine if the controls are effective in their application.
This is one of the most important components of CMMC certification. We see this everywhere, whether we're talking abut project management, patching, compliance, or change management.
This should be an iterative two-part process by which you first implement a solution to meet a control's requirement, and then second, periodically review and test the solution to ensure it provides the desired affect.
If you have applications or systems that can't be protected by a selected solution, make sure you implement it and document compensating controls to mitigate risk in the organization.
There are three reasons to have a process for documenting your security assessment.
Also, don't forget to consider privacy regulations such as GDPR and HIPAA where applicable.
3.12.2: Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
You never know when you'll need to provide documented SSPs and POA&M plans, so consider using templates.
Templated SSP and POA&M documents should be kept as a means of recording all deficiencies and non-compliant controls so you can build a plan for mitigation and/or remediation.
Don't forget to keep these documents up to date, so you can produce the exact state of your environment at any point in time.
3.12.3: Monitor security controls on an ongoing basis to ensure the continued effectiveness of the controls.
There is no "set it and forget it" option in cybersecurity.
Revisit controls on a recurring basis to ensure:
Always make sure you're meeting frequency requirements of local, state, federal or contractual obligations and look into automation whenever possible!
It's important to define effectiveness for your program early. This way you can determine how to best measure your results. If you can't measure your success, how do you know you're successful?
3.12.4: Develop, documents, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
Anytime a significant change occurs in your environment, SSPs must be updated. If no changes are recorded, you need to update at least annually.
Pay close attention to what is within your scope, particularly with company acquisitions or new products and services being offered.
Another important piece of this is to make sure that all documents are reviewed by executive leadership and are subsequently approved and distributed with a top-down approach. This makes them more effective within the organization, and takes care of the CMMC requirement showing that policies have been published and approved.
Be sure to catch up on our past CMMC blogs to find out all you need to know, and then reach out to our cybersecurity experts. We'll be happy to help!