Help

Compliance in Small Bites

bethjohnson
New Contributor III
4 weeks ago

If you're like me, you wear many hats at your organization, and if your organization is like mine (higher education) your staffing is lean. You may think, as I once did, that you don't have time to start enforcing macOS security compliance, or even see why you should. But in today's climate of evolving threats, increasing regulation, and high-profile settlements, it's likely that you'll need to get started sooner than you think. 

First of all, if you're new to security compliance, you might want to check out my presentation from PSU MacAdmins 2024, where I went into detail about how the macOS Security Compliance Project (mSCP) works together with Jamf Compliance Editor (JCE) to help you build a framework you can use to: set a compliance baseline, check your fleet to see what's compliant and what's not, report on those findings, and fix non-compliant devices. There are plenty of great resources on how to use mSCP and JCE, so what I'll concentrate on is the planning and staging. 

If you don't have a particular benchmark that you're required to follow, then choose an easy one: use the Center for Internet Security [CIS] Level 1. Even when fully implemented, it's not particularly intrusive for end users. It's even likely that you won't implement this benchmark completely; most organizations "tailor" it to their own needs, adding additional requirements or even omitting rules. For instance, you might have kiosks that need to use the Guest account, so you'll exempt those from those rules, and if you're using JamfPro you don't want to disable remote management, so you'll leave that rule out! 

You also don't need to implement all your security in one step. For me, it was more manageable to break it up into three stages: 

  1. Stage One - audit and logging 
  1. Stage Two - important OS and system settings 
  1. Stage Three - browser and user settings, anything with high risk of user impact 

A core tenant of security response is investigation, yet macOS, shipping as a consumer product, has some audit and logging functions turned off. So a valid Stage One is to deploy a baseline with audit and logging rules, and only those rules. These rules are highly unlikely to cause any problems for your users and none of them are fixed with profiles, but you still get a feel for the baseline process: uploading the script, running it in audit and fix policies, using extension attributes to report on the compliance. 

Stage Two adds more rules that can have a user impact but that are easily outweighed by the importance, such as enforcing the firewall and updating Gatekeeper. You'll need configuration profiles to add to the script fixes to make everything compliant. mSCP builds profiles for you, but test them with your existing profiles to make sure you don't have conflicts. When building this next stage out, it's easiest to keep the name of your baseline the same and simply upload the new version of the script. If you have different names for each stage, then reporting gets complicated, so keep it simple. 

For Stage Three, you can tackle complex and/or highly user-facing changes, such as password policy, browser settings, screen lock, etc. By this time, you should have let your users know some changes are in the works, identified a pool of test users if you didn't already have one available, and provided an easy method for your users to report on any issues. Again, keeping the same baseline name means you add rules (via a new script version and profiles) as you are comfortable with the results of your testing.  

Beyond these stages, you might need to create exemptions for certain groups of computers, change values for some rules, or upload new script versions as mSCP publishes updates. But even if you can only manage Stage One right now, you're still better off than if you don't start at all. 

Additional Resources: 

  • MacAdmins Slack: #jamf-compliance-editor  #macos_security_compliance 
  • Jamf Compliance Editor built-in Help 
2 Comments