CMMC Weekly Series #1
Posted on March 27, 2020 by Ted Wernet, CISSP
Access Control
The Access Control domain is one the of the largest domains covered under the new CMMC framework. In its current release, V1.0, it has 26 Practices that span all 5 CMMC maturity levels. It is important to understand that Practices are separate requirements from maturity level Processes although they may support them. In this post we will be reviewing Practices only.
Some Practices are straight forward and will only be discussed briefly while others will be more in-depth. It is also important to note that the Access Control domain is broken down into four Capabilities (“Establish system access requirements”, “Control internal system access”, “Control remote system access” and “Limit data access to authorized users and processes”). For the purposes of this post we are going to organize them by CMMC Maturity levels instead of Capabilities.
Furthermore, even though CMMC V1.0 has been released, formal assessment training has not. The information in the post below is based off our (Blue Mantle Technology) prior experience in performing audits and assessments on other security-related frameworks. Hopefully by the end of this post you should have a better understanding of how you might implement some of these Practices.
Level 1
AC.1.001 Limit system access to authorized users, processes acting on behalf of authorized users, or devices (including other systems). Depending on the size of your organization, this practice will usually require some sort of Identity Management system like Microsoft Active Directory (on premise) or Amazon Web Services Identity and Access Management (cloud), etc. User accounts, processes acting on behalf of users, and devices can be easily managed, controlled and tracked through out your information system. You may also employ something like McAfee Rogue System Detection to notify you and restrict devices and device access when they are added to your network.
AC.1.002 Limit information system access to the types of transactions and functions that authorized users are permitted to execute. For this Practice, RBAC (Role Based Access Control) or Organization Units are a great solution. It allows administrators to easily assign permissions to groups containers and then place users in these buckets to ensure only proper access/restrictions are in place.
AC.1.003 Verify and control/limit connections to and use of external information systems. For most organizations this practice can be simple to implement by limiting devices and system access to company owned equipment and establish a policy that prohibits the use of external devices to manage and/or access FCI and CUI data.
AC.1.004 Control information posted or processed on publicly accessible information systems. This practice could very easily be addressed by policy. A documented policy that states “information released to the public must be reviewed by your FSO [or CISO, PR officer et al.] for content review” or something similar should suffice.
Level 2
AC.2.005 Provide privacy and security notices consistent with applicable CUI rules. For this practice, you want to configure a login consent message for any applicable systems. This message should be clear and concise. It may reference agreements the user has signed before gaining access to the system and may remind them of potential penalties for violations of those agreements.
AC.2.006 Limit use of portable storage devices on external systems. As much as we love to use technology to simplify our environments, this is not one of those times. The practice will require a policy that states how portable storage devices are managed and used with regards to CUI systems. It is also imperative to note that just because a system sits on the IT rack right next to a CUI system the non-CUI system would be considered an external system. The simplest solution would be to produce a policy that prohibits the use of CUI portable devices with any external system.
AC.2.007 Employ the principle of least privilege, including for specific security functions and privileged accounts. Least privileged, least privileged, least privileged!!! This has been the mantra for IT security for decades so it should be no surprise it is a part of the CMMC framework. Give your users and administrators the least amount of privilege to perform their job. There are some nuances in this practice that should be noted. For instance, if a standard user needs to have local system administrative capabilities that can be acceptable. But if that is the case you would want to take measures to ensure they cannot perform certain functions, like uninstalling Anti-Virus software or disabling a firewall. You should also think about your administrators. An Exchange administrator does not need to be a Domain admin. Only grant what is necessary.
AC.2.008 Use non-privileged accounts or roles when accessing nonsecurity functions. This Practice cascades directly from AC.2.007. If a user is not performing a privileged function, they should not be using a privileged account. All users should have a standard user account and administrators should have a second account (perhaps more) to perform privileged functions.
AC.2.009 Limit unsuccessful logon attempts. This practice is self-explanatory. Limit access attempts to help protect your environment!
AC.2.010 Use session lock with pattern-hiding displays to prevent access and viewing of data after period of inactivity. This practice is very straight forward. Set an idle time-out on your systems to enable a screen saver/blank screen to prevent viewing on the system.
AC.2.011 Authorize wireless access prior to allowing such connections. This practice is a bit cloudy. It definitely requires the creation of a wireless access policy that defines the scope of users and devices that can connect to the wireless network as well as a network usage policy; but it also has a bit of a technical requirement as well. I believe that AC.3.012 would cover any type of technical requirement solution one would need. It will be interesting to see how this practice needs to be implemented when such guidance is available.
AC.2.013 Monitor and control remote access sessions. As stated in the practice, a VPN is a great solution. Unfortunately, it does not stop there. You should provide a mechanism to monitor/review these sessions which could be accomplished through logging to a SIEM and IPS/IDS that have alerting capabilities to ensure that any remote access sessions are fully controlled and monitored.
AC.2.015 Route remote access via managed access control points. This practice is straightforward. If possible, set up one remote connection point. This reduces the amount of systems to maintain and monitor while providing employees the access they need.
AC.2.016 Control the flow of CUI in accordance with approved authorizations. This practice may seem overwhelming at first. The gist of it is: know where your CUI data lives and control access to it. This can be done in multiple ways. We have had customers who used completely isolated systems to manage their CUI data while others used firewalls to sandbox access. There a ton of scenarios one could use to implement this practice but the key is understanding where CUI lives and keeping it safe!
Level 3
AC.3.017 Separate the duties of individuals to reduce the risk of malevolent activity without collusion. “Separation of duties”…another infamous term in the realm of IT security. Although this practice is somewhat self-explanatory, it can be difficult to implement in smaller organizations. At a minimum, you would want to separate out your system administrator from your audit log reviewer/administrator. But the farther you can go the better.
AC.3.018 Prevent non-privileged users from executing privileged functions and capture the execution of such functions in audit logs. Logs, logs and more logs. Although logging will be covered in more detail in a future blog, the heart of this practice is that one must ensure the right kind of data is captured. For this practice, that is privileged functions! Most IT systems from your OS to your firewall have a way of capturing this data. Ensure your log/audit levels are setup correctly to include privileged functions. This way – if the need arises – you will have the records to determine what is going on!
AC.3.019 Terminate (automatically) a user session after a defined condition. This practice is self-explanatory. There are several solutions one can implement to achieve this based on organizational needs. If a session time-out condition is desired, this can be setup and managed through Group Policy. However, if you need something to restrict how many open connections, you can have to a database you are going to have to start writing triggers in SQL to address that.
AC.3.012 Protect wireless access using authentication and encryption. The practice probably doesn’t need much clarification. It is useful to know that there are several ways an organization might implement a solution. As noted in the practice, for smaller organizations a pre-shared key is acceptable, but in a large org this is simply impractical. In these situations, radius, EAP-FAST, EAP-TLS, etc. can provide solid solutions with minimal maintenance. There will be some configuration time required initially, but in my opinion, it is completely worth the effort.
AC.3.020 Control connection of mobile devices. Here is another practice that has two requirements: you must create a policy that defines if and what mobile devices are acceptable for connection and you must utilize an MDM (Mobile Device Management) solution. There are various MDM solution products that can help with this. I recommend finding one that offers the following features: a work profile\sandbox, force encryption, evaluate device compliance, and, of course, remote wipe. There a ton of other features MDM solutions can offer so review what best fits your organization.
AC.3.014 Employ cryptographic mechanisms to protect the confidentiality of remote access sessions. The requirements for this practice are straightforward. Employ encryption for remote access and make sure you use FIPS-valid crypto. Start by identifying all remote access. This could be a VPN connection, TLS access for OWA, etc. Once you have identified these access points, ensure you are using cryptography that meets FIPS compliance.
AC.3.021 Authorize remote execution of privileged commands and remote access to security-relevant information. This policy is straightforward. Document who can execute remote privilege commands and determine which commands they can execute remotely. The difficulty will be restricting users from certain commands. This could be accomplished in a myriad of ways. Try restricting RDP or system access to certain subnets, and/or create user accounts that can only reach certain devices or execute certain functions over remote access.
AC.3.022 Encrypt CUI on mobile devices and mobile computing platforms. Here is another practice that is best implemented with an MDM (Mobile Device Management) solution. An MDM will allow you enforce device encryption, create mobile device profiles that allow granular control and provide device wipe if the device is lost/stolen.
Level 4
AC.4.023 Control information flows between security domains on connected systems. This practice is similar to AC.2.016. The idea is to understand where your CUI data lives and keep access and flow separate from systems that do not contain CUI.
AC.4.025 Periodically review and update CUI program access permissions. This control is, once again, self-explanatory. Review your permission sets periodically to ensure they are accurate.
AC.4.032 Restrict remote network access based on organizationally defined risk factors such as time of day, location of access, physical location, network connection state, and measured properties of the current user and role. Conditional access is my favorite! Using programs like Microsoft Azure you can block/grant access to your company’s resources based on things such as location, device type, and even application type.
Level 5
AC.5.024 Identify and mitigate risk associated with unidentified wireless access points connected to the network. This practice could be a hardware/software solution or a handled by a review process. Obviously, a hardware solution to detect this type of activity is ideal but it is not required. You could develop a process to identify and catalog all system connectivity in your IS. You could then review these systems to determine something rogue has been placed on your network.
