Top 5 misconceptions about building a CMMC Level 3 network

Who is this article for?

  • If you decided that your company needs to build a new information system to meet CMMC Level 3 requirements, this is for you.
  • If all of your users have admin rights on their workstations, this is for you.
  • If your network is complex and you have no idea how you will secure half of it to Level 3 requirements, this is for you.
  • If you haven’t been paying attention to 800-171 or DFARS cybersecurity requirements until now, this is for you.

I’ve been working with businesses for almost two years now to get them ready for the CMMC. In this time, I’ve spoken with over a hundred different defense contractors and several hundred cybersecurity professionals about their network and readiness.

During these discussions, I have seen clear trends and misunderstandings which sabotage efforts to reach a CMMC Level 3 compliant state.

Top misconceptions about building a CMMC Level 3 network

I’ve compiled a list of the top 5 logic problems that I see over and over again when contractors are designing their CMMC level 3 compliant network. In no particular order…

#1 – We don’t need email in our CUI enclave

This isn’t specifically about email, but I point it out because I hear this phrase repeatedly from companies that are starting to design a CUI enclave. It indicates that the decision maker 1) hasn’t spent time thinking about how their users actually work with CUI, or 2) doesn’t understand how scope works.

Your users need to be able to FUNCTION within the CUI network you design. In almost all cases, that means your in-scope systems need to provide capabilities for handling CUI in relation to..

  • Written communication with external people (also known as email).*
  • Screen sharing and video chat with internal and external people
  • Document editing
  • Web browsing
  • Saving work in progress, both to individual locations and to corporate shares
  • Long-term file storage
  • Sending or receiving large files with external people
  • Core programs used to perform on contracts

* Yes, CUI shouldn’t be sent through unencrypted email. And not all enclaves need email. But your users need to coordinate sharing CUI securely or talk about other project topics (FCI). Do you have a plan for how they will do that?

If you haven’t designed for each of these functionalities to work, you are begging for your users to access CUI using unauthorized systems. Or your new system will be unusable, wasting effort and money.

Don’t design a CUI enclave that is so limited that it is unusable for real work.

Sidebar: How to map out your data flows, sensitive data locations, and scope

#2 – I will use Virtual Desktop Infrastructure (VDI) as my core solution

In case you aren’t familiar with this technology, VDI is a terminal server-type solution where you can use a virtual computer as though you are sitting in front of it. The idea is that your users can utilize any workstation (even their home computer) to connect to the VDI. CUI can be viewed and manipulated on their computer screen, but since the user can’t copy-paste through the VDI, the endpoint never gets contaminated with CUI, so it isn’t in scope.

This one is going to get me some hate. Hear me out.

I have performed polls of cybersecurity professionals about this topic. Does a correctly-configured Virtual Desktop solution provide enough of an information barrier to keep user workstations out of scope? The reply is almost 50-50 yes and no.

When I talk to cybersecurity professionals with military background, most of them (80%+) do not feel that VDI can be used as a boundary to keep end user workstations out of scope.

I personally think VDI is a great solution, and should be acceptable for this purpose. But I don’t make the rules. The DoD does. To my knowledge, the DoD has never given an official opinion about whether VDI is acceptable for keeping end user workstations out of scope. The question has been asked repeatedly, but they haven’t answered.

At some point, the DoD WILL answer the question. What happens if they say no? Everyone’s VDI solution will immediately be invalid.

If you want to take this risk, now that you understand the full situation, go for it. If you want to play it safe, then don’t design for a VDI solution.

This goes for other fancy technology too. The DoD still largely uses an on-premises model with VPNs for access to internal resources, firewall protections at the corporate level, and perimeter physical security. If you want to be totally safe, follow their lead: design like it’s 2009.

#3 – Local admin rights for users is not a big deal

While it is technically possible to meet CMMC Level 3 requirements while allowing your users to modify their computers, it will be very very hard to pass your CMMC assessment.

Here is what goes wrong when your general user base has admin rights to their endpoint:

  • Password complexity requirements get turned off
  • Screen lock timer gets disabled or lengthened
  • You can’t keep an “authorized software list” that is even close to accurate
  • Browsers are configured to allow mobile code that is insecure, like Flash or older versions of Java
  • Restrictions to block portable storage are turned off and uncontrolled thumb drives are used
  • Antivirus gets disabled when it repeatedly blocks the malware your user wants to run
  • You can’t keep all computers patched because you are managing 7 different versions of PDF viewers and 26 different versions of meeting software
  • Firewall is modified or disabled
  • Audit logs can be viewed, modified, or deleted
  • CUI transmitted using unapproved methods or software versions that aren’t FIPS validated
  • Connections to external systems like home computers or personal cloud services can’t be blocked

There are so many practices in CMMC Level 3 that fail by default if your users have local admin rights. The burden on your IT department goes up like crazy if you expect them to uphold level 3 standards. Again, CMMC does not disallow this, it is just really hard to pull it off perfectly.

If you think you need to allow users to have admin rights, think again. Then again. Plan a lot of compensating security to make up for it.

#4 – Automation is the way

Modern IT departments design their solutions to be automated. Automated password reset. Automated account provisioning. Automated inventory management.

The default approach for most companies considering CMMC is to build out a full technical implementation, migrate their users to it, then build processes to perform CMMC compliance.

I urge you to start from the other direction. Focus on processes first. Perform the required compliance tasks manually on a small scale then decide whether you should automate them.

Build a prototype enclave which includes all the “big rocks” for CMMC compliance. Assign 2 system administrators from your department to perform all the required processes starting now.

What processes should you start performing now, while your enclave is still a baby?

  • Audit log and alerts generation and review
  • Change management
  • Software approvals and inventory
  • Hardware inventory
  • Tracking processes and cryptographic keys
  • Account management (onboarding AND offboarding)
  • Training, user agreements, and screening (including the staff building the system)
  • Incident response and reporting
  • Patching
  • Vulnerability scanning
  • Helpdesk procedures
  • Granular permissions and data ownership
  • Capturing configurations and standard build procedures
  • Risk assessment and situational awareness
  • System Security Plan & Plan of Action creation and updates
  • Physical protections for enclave (if server room is shared or if entire company not authorized for CUI)
  • Following policy for passwords, default and shared accounts
  • Different accounts for admin rights and user rights

If you start doing the manual processes now, you will be building evidence of Maturity (the first M in CMMC). You want as much evidence of process maturity as possible for your assessment.

#5 – Only my [insert server here] is in scope

This also applies to contractors that buy an end-to-end file or email solution and think that only the encrypted transit is in scope.

Hate to break it to you, but I’m pretty sure that the Department of Defense disagrees.

While we don’t have official scope guidance for CMMC yet, we do have scope guidance for DFARS 252.204-7012 which is the predecessor for CMMC. DFARS 7012 says that “The Contractor shall provide adequate security on all covered contractor information systems. To provide adequate security, the Contractor shall implement, at a minimum, the following information security protections…

Let’s look at the definitions that DFARS uses for scope.

Sidebar: Full review and commentary on Covered Defense Information / Covered Contractor Information System (video).

“Covered contractor information system” means an unclassified information system that is owned, or operated by or for, a contractor and that processes, stores, or transmits covered defense information.

“Information system” means a discrete set of information resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of information.

I think it is safe to say that “information system” does not refer just to the server that has CUI in it. The DoD wants these security protections to apply end-to-end through your environment if that environment processes Covered Defense Information. This is why logical and physical boundaries are so important – they define where the ends of your environment are.

At the very very minimum, you need to include endpoints (whatever device renders the view of CUI to the user) in addition to your CUI database or file server. It is pretty safe to say that the DoD expects you to include firewalls, switches, identity (domain), backups, patching, antivirus, and possibly logging systems in this design too. Reference NIST SP 800-171 scoping guidance (page 2).

Wrapping up

Almost every contractor I’ve talked to over the last two years is operating from one or more of these misconceptions. So I expect most of you did not enjoy this article and at least 30% are ready to fight me over it.

What is your take? Please comment or share this article if you found value from it (or want to say it is terrible).


Please sign up for our newsletter for timely updates about CMMC and DFARS 252.204-7012 . You can unsubscribe at any time.


V. Amira Armond (CISSP, CISA, PMP, MBA) is a computer systems architect, cyber-security consultant, and owner of Kieri Solutions LLC. She specializes in CMMC preparation and DFARS 252.204-7012 compliance, and designing secure and resilient enterprise systems for private sector and the DoD. She is the chief editor for cmmcaudit.org, a public resource for news and informational articles about the Cybersecurity Maturity Model Certification.

3 thoughts on “Top 5 misconceptions about building a CMMC Level 3 network

  1. mitch tanenbaum says:

    regarding misconception #2, I agree we don’t know how the DoD is going to rule on this. But think about this. The DoD has been using VDI in its classified world for years – to make it more secure. Granted their VDI world is not public cloud based, but they keep reiterating that this is not classified, either. I guess we have to stay tuned.

  2. Randy A Renk says:

    Some additional support for your premise about the scope of an “information system”. Please note that in December 2016, NIST purposefully substituted the term “System” for “Information System”. They explained why in subsequent version of NIST 800-171r1. Their intent was to embrace a wider scope of the attack surface to include IOT, factory equipment, infrastructure and test equipment.
    NIST 800-171r2 did not carry over that explanation since (I suspect) it was almost five years old. But Rev 2 still uses “system” and not “information system.”
    (Note: The CMMC authors regressed back to “information system” in their interpretation of the NIST requirements)

  3. Thomas Nohs says:

    I think you hit the nail on the head and it’s been very helpful. The DoD contractors and manufacturers that I have been working with are not technical people and rely on me to guide them through it. The points you make above, prove my point in that it’s going to be a long haul no matter how good the infrastructure is. The processes are what take the most understanding. Small contractors or manufacturers normally do not have the skilled personnel to perform these tasks. It is really is a new beginning for them.

    Looking at it from a cybersecurity standpoint, this will make for a better and more secure environment in long term.

    I find it extremely important to step through the 800-171 and put the processes in place as you go. This way the process can be digested within the company. They also get to understand the importance of the process.

    I believe the most important piece in all of this is the buy-in of the ownership. Without that, it is going to be a struggle.

    I started walking through a first-time-ever administrative group and account review with a contractor. The ownership was getting upset that there were so many administrator accounts on the system and that there were so many users who were no longer with the company. My response was first to calm them down and explain that this is why there is a review process and that almost every company goes through the same thing. Now they had an understanding of this process and saw it with their own eyes.

    They are believers 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *