Introduction
All I wanted for Christmas was a change request that included everything it was supposed to. This year, to save me from tears, I’m giving you something special. Ok, ok. That might have been the cheesiest opening to a blog article I’ve ever written, but hey, I’m just trying to get into the holiday spirit. With that in mind, I thought to myself, what better way to spread the cheer than with a deep dive into a very common NIST 800-171 question/concern I get: physical and logical access restrictions related to change management.
This has been a topic that I’ve wanted to do for a long time. It’s one of those requirements that people might easily glaze over when setting up their CMMC change management process. I would also argue, from my experience, that this is one requirement that is not scrutinized as significantly as it ought to be, carrying a five-point value in SPRS according the 32 CFR section on scoring. My goal in this article is to explain the risk that this requirement aims to mitigate (remember, all things cybersecurity is about addressing risk; these 110 requirements are no different), explain the requirement itself down to the particular objectives, exemplify how this requirement could be implemented into a system adequately and practically, and, finally, the impact of this requirement on different parties and stakeholders using and managing the system. So quit the chatter, Steve, and let’s dive in!
Let the Kid Wonder, Live a Little!
I want you to imagine with me for a moment: your organization has been leasing half of a floor in an office building for a couple of years now, and you’ve been able to operate your business out of a single network closet with a few racks for your servers and network stack – nothing big, and it gets the job done. However, over the last few years, your company’s been growing, and you’ve decided that you’re going to need more office space. After researching your options, you determine that extending the leased space to the rest of the floor in the office building makes the most sense. The only downside is that the rest of the office isn’t currently equipped with the network infrastructure necessary to support the other offices, as it’s really only been used so far to provide telecommuting space for individuals or small groups with Wi-Fi access only. This is not going to work for you, but the office will let you make the adjustments you need to suit your business (as long as you pay for it, of course). Conversations with your IT department determine that they want to wire the rest of the floor with Ethernet, and they want to use one of the current small closets on the other side of the office as an additional network closet to support the new physical infrastructure that will ultimately act as an extension of your current data center. This will also give the IT guys more space to add some special machines they’ve wanted but didn’t have room for in the main network closet.
In the spirit of doing your due diligence to follow your processes for change management, you formally initiate the change management procedure by submitting a request for this change to your system and infrastructure. The ticket gets created; a shoot-from-the-hip security impact analysis is performed by one of the security guys before being finally approved by the Change Advisory Board (CAB). The change is implemented successfully upon approval, and your company has a sick new network closet and, functionally, things are working great….until, one day, on bring-your-kids-to-work day (does that even still happen?), someone’s kid, let’s call him “Ralphie” (you know, from ‘A Christmas Story’), gets away from the group, wonders around the office, discovers the door to Narnia, walks right in, and starts pressing buttons and playing with some imaginary blue snakes (your Ethernet cables) thinking he’s Indiana Jones. Then, the new accountant is wondering why her Sage Accounting session just crashed. Thank goodness it wasn’t a bad guy who snuck into the office and started fiddling with things!
Though it covers several similar scenarios or worse, CM.L2-3.4.5 exists to help mitigate such possibilities. It exists to ensure that access control (i.e., only the people who should have access are given such access and that their access is performed in an authorized way) is maintained as a fundamental part of the Change Management Process. It ensures that, whether the change is the replacement of old technologies with new components, adjustments to logical configurations, or even the addition of a network closet to house an extension of the server room, little Ralphie, the scammer posing as Microsoft Support, or the uneducated/not-so-tech-savvy sales guy, isn’t able to access critical systems or data during or after the change is completed. In short, CM.L2-3.4.5 would have increased the likelihood that a lock on the door of the new network closet would’ve been something thought about before important stuff was put in there.
Gimme’ the Scoop
This requirement has eight objectives, which are essentially the same four objectives repeated twice with separate focuses. These objectives focus on determining whether the organization has defined, documented, approved, and enforced Physical or Logical access restrictions that are relevant to changes going through the change management process (hence why this requirement comes right after 3.4.3 and 3.4.4, which are precedent processes). So, let’s break up the four principles:
- Physical and Logical Access Restrictions are Defined (objectives [a] & [e]) – These objectives refer to the administrative standards and policies for the system and are more static across the organization. Generally, you want a policy that specifies the basic universal/global physical and logical access restrictions that should be in place for system changes.
- Physical and Logical Access Restrictions are Documented (objectives [b] & [f]) – These objectives focus on the actual restrictions that are associated with a live change. It’s one thing to have a defined policy that says “X, Y, and Z restrictions must be in place for all changes; it’s another thing entirely to address those principles or any other unique circumstances related to a unique change request. It should be explicitly clear as part of the documentation for the change request (e.g., ticket, form, email thread, etc.) what exact restrictions are necessary for the change at hand.
- Physical and Logical Access Restrictions are Approved (objectives [c] & [g]) – These objectives exist to ensure that the people who are responsible for changes to the system (i.e., could get in big, big trouble if something goes really bad), are informed of the suggested access restrictions necessary for changes to the system and determine whether they are sufficient enough to address the risks the change would incur. At the end of the day, leadership needs to be informed of the risk and be provided with relevant recommendations and information so they can ultimately make a decision.
- Physical and Logical Access Restrictions are Enforced (objectives [d] & [h]) – Finally, these objectives emphasize the importance of avoiding deviation from the plan. If certain access restrictions have been defined and documented for the change at hand and approved by the individual or group responsible, it is essential that those restrictions are actually put in place when the change is performed and as an outcome of a completed change. It is never ok to just go “wild-west” and ignore what has been approved for implementation by those in charge because it’s THEIR RISK, not yours. This doesn’t mean that issues don’t arise during the implementation of an approved change that puts a wrench in the plan; it happens all the time! Even in those situations, it is crucial to communicate with those responsible and gain their blessing and approval before deviating from previously blessed and approved plans. Any deviations should also be documented in the change management documentation or ticket.
Beware! The red flags are probably already going off in your head about the breadth this requirement might entail. This can cause a huge impact on the “Who” and “How” change management is performed. One prime example of this is the involvement of a Managed Service Provider (MSP) and how they do things in your system. Many MSPs follow a standard approach to making changes to customer systems. I’ll briefly mention a strategy for addressing that concern shortly.
If You Really Wanna Know….
As promised, I wanted to leave you with some perspective and suggestions on how you can knock this one out of the park for your company. When we teach Organizations Seeking Certification (OSCs) and MSPs how to implement this requirement and what Plans of Action & Milestones (POA&Ms) they should develop for themselves, we generally are giving them a pretty consistent approach that I think works well in most situations.
Pointer #1: Update your policy to include the basic, across-the-board physical and logical access restrictions that should be enforced as the standard. Things like “Only members of the IT Department shall be granted logical access to the operating systems or other logical interfaces where the changes are being performed,” or (referring to our example from earlier) “Physical locks must be in place at ingress/egress points to rooms where technical infrastructure is to reside. Only members of the IT department, Information Security Department, and Executive Leadership shall be given physical access to such rooms.”
Pointer #2: Implement a dedicated portion of your ticketing system or change tracking capability where these access restrictions can be specified. A text box in a Change request that leaders and members of the security team can call out specific restrictions, in addition to the standards policy-defined restrictions, will only add additional assurance to this workflow and will reduce the risk that something gets missed.
Pointer #3: Train the people involved. There might be an opportunity to improve upon your role-based training for individuals in security-relevant roles (AU.L2-3.2.2). You could communicate via training to individuals responsible for reviewing and approving changes that they really need to consider the system’s access restrictions before granting approval, and make sure there are clear restrictions in place that must be implemented for this change as a condition of your approval. You could also communicate to those responsible for implementing approved changes that they are required to implement the change exactly in accordance with your company’s policies and with what has been approved for the change request including, the logical and physical access restrictions.
Pointer #4: Sync up with your MSP. Though it’s expected that MSPs have their own unique workflow, it is extremely important that the way the MSP does things doesn’t violate your policies and procedures related to change management. This should be a conversation with the MSP, and if necessary, you need to account for how they do things in your policies and procedures. If the MSP doesn’t do change management in a way that is suitable for your requirements, then you really only have three options: 1.) Confer with them and see if they’d be willing to adjust to their procedures at least for their activities involving your system, 2.) Adjust your policies, procedures, and internal requirements to align with their approach to change management, or 3.) Consider switching the MSP. Some of these options are more feasible than others, but CM.L2-3.4.5 should be emphasized when considering your MSP.
A Fleeting Remark and Season’s Farewell
All is calm; all is bright for the organization that takes change management seriously. Of course, there’s probably much more that could be said, and I’ll be the first to admit that maybe certain elements above won’t apply to everyone equally. However, I do hope that this was helpful and gave you a jolly dose of clarity when it comes to another, sometimes tricky requirement to get right. IntelliGRC is all about spreading the cheer and helping people in their journey with CMMC and several other GRC efforts for that matter, so please don’t hesitate to reach out! You can find out more about us at https://IntelliGRC.com/. Also, feel free to connect with me, Steven Molter, your resident Chronic Yapper, anytime.
As always, Happy Implementing, Happy Holidays, and please don’t let Ralphie shoot his eye out!
