Mac computers continue to grow in popularity; they’ve now moved well outside the purview of design firms, and can be found in-use across all industry sectors, including defense contractors. Many Mac users proudly boast about their enhanced security, while PC devotees maintain otherwise. The reality is that ALL compute platforms offer a level of risk, and all compute platforms in the scope of a CMMC assessment must achieve the required standards, including Mac users and environments.
Although the popularity of Macs continues to grow across a variety of industries, many CTO’s remain less familiar with their support, and have questions about the feasibility of compliance, especially with NIST 800-171 and CMMC. Compliance is possible – but it does take some effort.
The challenges with a Mac begin with the identity provider. NIST 800-171/CMMC L2 requires each user to have a unique identity and for all events to be traceable to a unique individual. To address this challenge, we typically join computers to an identity provider such as Azure AD or Active Directory so that when a user logs in to the endpoint they use the same identity on the computer as they do for e-mail, collaboration, and line of business apps. The logs from Azure AD and/or Active Directory are then imported to log aggregator or Security Incident Event Manager such as Microsoft Sentinel using native connectors. However, Mac does not support joining to Azure AD, and an Active Directory join is less than ideal from a support perspective. This means using a third-party service to provide identity services to the Mac so they will “join” an identity provider.
Keep in mind that introducing multiple identity providers means adding complexity to the environment. As this environmental complexity increases, day-to-day support can become more challenging, bringing with it higher labor costs and potentially longer resolution for support requests. Even simple tasks such as creating user accounts can become challenging. Furthermore, multiple logs for each identity provider must be stored, correlated, and reviewed. While most identity providers will support exporting logs via an API, this also adds increased cost and complexity.
After sourcing the original identity provider, one must enforce multi-factor authentication on the Mac. The Mac OS does not natively support multi-factor authentication, so another system (now potentially a third identity provider) must be added to enforce multi-factor authentication on the device. This system will also need to have logs stored, correlated, monitored and reviewed, which adds complexity and cost.
Once identity provider challenges are addressed, the next issue that Macs present is compliance with FIPS validated encryption. CMMC control SC.L2-3.13.11 requires that all Controlled Unclassified Information (CUI) is protected by FIPS validated encryption. Microsoft offers an “easy button” via an Endpoint Manager or group policy setting to disable non-FIPS 140-2 validated encryption. When using a Mac, administrators do not have the ability to block non-FIPS validated encryption on the endpoint. However, this does not necessarily mean a Mac will be non-compliant. Instead, administrators will need additional due diligence to carefully evaluate that all encryption protection CUI is FIPS 140-2 validated. This effort could be as simple as using the cryptographic module validation program search tool located here. However, be forewarned that tracking encryption modules is not fun.
When we talk with business leaders and technology professionals, the question typically comes up about using software virtualization on the Mac to run a Windows computer. The philosophy behind this is that the employee can have a single piece of hardware while using their virtualized Windows PC. I like this concept, but unfortunately it does not support the desired compliance. For example, the Mac will come into scope of an assessment because the network for the PC must traverse the Mac. If you have in-scope devices and out-of-scope devices concurrently on the same network, both devices would then be in-scope. In this case, the out-of-scope Mac would be the networking device for the Windows VM. If the Mac had malware or a bad actor (after all, Windows VM’s are just a file) CUI could be captured in transit at the local Mac, or other devices on the office network. So, despite all efforts to remove the Mac and the complexity it brings, we are back to square one.
So, what does all of this mean? Can you really achieve CMMC Level 2 compliance with a Mac?
The answer is yes, a Mac can be CMMC compliant, but it won’t be easy and it will come with both added complexity and costs. In the field, I am seeing more and more Mac users moving to a virtualized desktop hosted in Azure or Azure Government when working on systems in scope of CMMC. This provides a clean boundary and facilitates a more streamlined environment. At C3 Integrated Solutions, we have the knowledge and expertise in Azure infrastructure as well as CMMC compliance to tailor a solution that meets both your business and compliance requirements.
C3 Integrated Solutions has a proven track record of expertise with Microsoft solutions. We work with our customers to implement systems and solutions to support a range of compliance standards including ISO 27001 and CMMC Level 2. Our configurations are designed to create a balance between business requirements, security, and compliance. Most importantly, we prioritize working with you, our customer, to ensure they are tailored to fit your environment. If you have questions or are ready to take the next step in your compliance journey, contact us at email@example.com.