CIS, Apple and tools

New Contributor III

New Contributor III

I am currently implementing Jamf Protect to report on CIS Level 1 controls and likely later CIS Level 2 controls. I am using Jamf Compliance Editor to help generate the remediation measures.

Due to a significant misalignment between these two tools even though Jamf Pro via Jamf Compliance Editor is now reporting my test Mac is substantially compliant, Jamf Protect does not.

It is going to take a lot of tedious work to determine each cause since these two tools are not aligned but here are some examples.

  1. It is not possible to tell the exact method Jamf Protect uses to test compliance but based on what Jamf Compliance Editor does it is possible that Apple have goofed up. Apple do not allow using /usr/llibexec/ApplicationFirewall/socketfilterfw --getstealthmode to query and check whether stealth mode has been enabled if the Mac is being managed via an MDM. It is of course possible to enforce by a profile but not test this. As this command is not making any changes I do not see what it cannot be allowed. Clearly Apple have been too blunt.
  2. Both Jamf Compliance Editor and Jamf Protect think it is still possible to enforce the enablement of Location Services and so presumably do the CIS group. Apple blocked this ability for administrators several years ago. Only users themselves can enable this and it can only be done by the user via the GUI. As such reporting on this and expecting it to be enforced seems utterly pointless.
  3. Jamf Protect seems to report a failure regarding encrypted Time Machine backups even on Macs that do not have a Time Machine drive and never never used one. Jamf Pro and Jamf Compliance Editor do not.

As mentioned Jamf Compliance Editor and Jamf Protect control lists do not align properly. Ignoring the single test exemption I defined in Jamf Compliance Editor, it seems to now believe I have zero non-compliance CIS Level 1 controls on my test Mac whereas for the same Mac, Jamf Protect says 13 controls for are non-compliant.

Valued Contributor II

I think your point about reporting differences between Jamf Protect and JCE is very valid. We are going through a similar process right now, but our Security team uses Tanium for compliance scanning. Fortunately I have a good enough relationship with that Team that we can see the checks that Tanium is using for compliance. 

One thing i have noticed about JCE (and macOS Security Compliance Project, which is what JCE uses) and other tools is that mSCP sometimes uses a different solution for implmenting and validating the CIS standard  than is list in the official CIS documentation. I don't know for sure, but it may be a case where mSCP has mulitple standards that can be used for controls, the same control under one standard (CIS L1) may have a different implementation/audit than a different standard (NIST). I don't know enough about the difference between the standards to know for sure. 

In my case, I have gone back to my security team and explained how mSCP is implementing the control and getting their approval to use it. Fortunately, Tanium makes it easy to create custom compliance checks, so we can disable the CIS based compliance check and enable a custom check.  

Valued Contributor II

Hey @jel-gherson yes, cis is not exactly easy to implement manage but it is very possible. Requires many configuration profiles, smart computer groups, extension attributes & scrits but it is possible. Check out solutions provided by cis benchmarks, they provide a great pdf ~  & this git ~


Also, thank I believe Robert Hammen for this one (Location Services zshell) ~ been using it, works great, requires reboot but works. Haven't test on Sonoma yet.


# Enable location services script

# Find the device UUID
uuid=$( /usr/sbin/ioreg -d2 -c IOPlatformExpertDevice | /usr/bin/awk -F\" '/IOPlatformUUID/{print $(NF-1)}' )

# Enable macOS Location Services
/usr/bin/defaults write /var/db/locationd/Library/Preferences/ByHost/ LocationServicesEnabled -int 1
/usr/bin/defaults write /var/db/locationd/Library/Preferences/ByHost/$uuid LocationServicesEnabled -int 1

# Set date and time automatically
/usr/bin/defaults write /Library/Preferences/ Active -bool YES
/usr/bin/defaults write /private/var/db/timed/Library/Preferences/ TMAutomaticTimeOnlyEnabled -bool YES
/usr/bin/defaults write /private/var/db/timed/Library/Preferences/ TMAutomaticTimeZoneEnabled -bool YES

# Force time zone and time sync
/usr/sbin/systemsetup -setusingnetworktime on
/usr/sbin/systemsetup -gettimezone
/usr/sbin/systemsetup -getnetworktimeserver

# Restart location services daemon
/usr/bin/killall locationd

exit 0


Looking for a Jamf Managed Service Provider? Look no further than Rocketman

Virtual MacAdmins Monthly Meetup - First Friday, Every Month

Legendary Contributor III

If you enable Firewall Stealth mode via Config Profile, you can check for the existence of a "" file in /Library/Managed\ Preferences and look for the "EnableStealthMode" key in the plist, which should be set to "1" or true/enabled. I do this with an Extension Attribute. It's true you can't use the socketfilterfw command to actually check its status when it's enabled this way, but if you have the profile deployed to the Mac with that setting in place, it should be on. That said, whether it can be checked in this way using the tools you mentioned, I can't say, since I don't have either one in place here.

And, I do also find a few odd discrepancies between what CIS says is possible and what actually IS possible based on Apple's controls. I think the team that works to create the CIS guidelines could do a better job at confirming what they recommend. I find sometimes they don't always take MDM management into consideration, and how that differs from manually setting up a device. An example is the one you already provided above, in that they recommend testing Firewall Stealth mode using socketfilterfw, but this doesn't work if it's enabled via a profile.

It looks like @Hugonaut has posted a possible solution for point #2. For #3, I can't say I've seen that, but then, I'm not using Jamf Protect as I stated before (though I wish we were)

Valued Contributor II

Agree with @mm2270.

Saw discrepancies between what was set with MDM and what the CIS-Scan from Security reported. Had to pivot on some.

@jel-gherson Do you have an InfoSec team that can scan one of your CIS Hardened Macs? Maybe you can compare, adjust from there.


New Contributor III

Thanks @obi-k @mm2270 and @Hugonaut 

 @Hugonaut A few years ago I had used a script to enable location services which Apple later blocked, I will try this newer one.

 @mm2270 yes I had myself thought of that approach, it can be made able to cover MDM and none MDM approaches by adding an if/then/else to cover both, the problem is that whilst tweaks like this can be done via Jamf Compliance Editor for its checks, they cannot for Jamf Protect. The definitions in Jamf Protect are controlled by Jamf. Here is a suggested alternative.

if [[ -e "/Library/Managed Preferences/" ]]; then
        stealthSTATUS=$(/usr/bin/defaults read "/Library/Managed Preferences/" EnableStealthMode)
        stealthSTATUS=$(/usr/libexec/ApplicationFirewall/socketfilterfw --getstealthmode | /usr/bin/grep -c "Stealth mode enabled")

In my last job we did have a dedicated security team (it was a bigger org) but in my current role it is a smaller org and I have to do everything myself. I am currently going through the results from both Jamf Compliance Editor and Jamf Protect and trying to get both happy.

Note: I regard the reporting in Jamf Protect to be more external security auditor friendly despite its various flaws so would like to get that sorted as well even if Jamf Compliance Editor is already happy.

New Contributor III

Another two Jamf Protect controls with issues.

Jamf Protect is checking the Security Audit log retention settings. Its control is described as per the attached screen capture. This to me suggests the requirement is for it to be set to 60 days or more, and 1GB or more. Jamf Compliance Editor remediation enforces 60 days and 5GB which again to me should be regarded as compliant. Jamf Compliance Editor checks of course agree. However Jamf Protect regards this as non-compliant.

Screenshot 2023-07-17 at 11.31.22.png


By manually editing the setting in /etc/security/audit_control to 60 days and 1GB and updating the Jamf Protect inventory for the test Mac by doing sudo protectctl checking --insights I can see this does result in a pass.

It therefore seems the logic in Jamf Protect is

If number of days = 60 AND size = 1GB then result = pass

whereas arguably the logic should be

If number of days >= 60 AND size >= 1GB then result = pass

The second issue is that for a number of Macs Jamf Protect is reporting a non-compliance regarding encrypted Time Machine backups. However none of these Macs are doing or have Time Machine backup drives. I had thought this might be being (incorrectly) triggered by local Time Machine snapshots which are stored on the boot drive in /.MobileBackups but this folder does not exist either.

Since there is no Time Machine drive setup it is not possible to configure it to be encrypted! It is not however down to a default incorrect assumption since a significant number of Macs also with no Time Machine drive are not triggering this.