Following internal penetration testing, Mojave has failed to pass security controls as they do not align with the CIS 10:14 Benchmark. This was no real surprise as we saw it coming. We are now tasked with some security remediation work and i wanted to hear from other who may be sitting in the same boat or who have had experience implementing these controls.
Previously with High Sierra we were able to meet compliance standards fairly easily using Jamf's CIS scrips hosted on Jamf GitHub found here https://github.com/jamf/CIS-for-macOS-High-Sierra-CP/tree/master/CIS%20Scripts which fully assign with https://www.jamf.com/resources/white-papers/macos-security-checklist
It would appear Jamf haven’t completed the benchmark for macOS Mojave yet, you could also argue its not Jamf's responsibility either - but have been helpful in the past in recognising CIS Benchmarks plays a big part in corporate I.T world and have been helpful enough to assist its customers to meet standard with such contributions.
What are people's views?
I know that a lot of emphasis is placed on the CIS benchmarks as they represent a consistent, respectable set of "standards" for organizations to follow. However, CIS is taking about a year after the release of each macOS to publish the document covering those settings (High Sierra v1.0.0 is dated August 31, 2018; macOS Mojave released on September 24th). So while I understand security teams wanting to "check the box" for compliance, there isn't a CIS document that exists yet for Mojave.
I've ended-up building my own "macOS security baseline" document for internal use that is based on the High Sierra CIS document (and will be updated whenever the official Mojave guide is published) and testing each feature against the updated OS, figuring out what is broken, and researching how to fix it. I also spend a lot of time pouring over security talks from various conferences, WWDC, Apple developer and administration documentation, etc. to make the most of securing the platform.
Get the full CIS docs, I think you can get the word doc version or the PDF version and it shows.
With both of those examples, it's usually sort of easy to appease "super smart" security groups.
FWIW, CIS isn't "ignoring" anything... the CIS group is a volunteer group who write the benchmarks in their spare time. (disclaimer, I helped write the 10.8, 10.12 and 10.13 benchmarks).
Due to a few factors, I haven't been involved in any of the CIS effort since 10.13, but if you want it done faster, help them! It was usually only 4-5 people working on it at a time, and just not enough resources to go around.
FWIW, for those who have access, DISA is also a very good option (DOD), but doesn't run any faster than CIS normally, and that one has "corporate" backing (aka, DOD sys admins assigned to work on it). One huge difference between the Mac and Windows CIS schedules is Microsoft's involvement, vs. no "official" support from Apple (although there are usually a few apple employees working on the CIS, but again, in their spare time as volunteers).
Don't think STIG released 10-14/10-15 either.
Once jamf | PROTECT is released (and allows us to control audit values) we will all be in a better place.
Another approach that should be valid if you have a reasonable ITSec. group - fix your documentation to simply say that your baseline is the "Current CIS benchmark" and stop listing version. Then for internal documentation, write up a reasonable approach stating core security controls you require to be in place, and allow new OS version on a provisional basis "until such time as CIS implements an updated benchmark". Most info sec departments are all about managing risk. Having things written well, with solid test plans, etc. give them what they need to help you. In past roles, we usually had a set of "core" controls that we required to be implemented for new OS's, and as long as we could guarantee those, we were allowed to run newer OS's. Depending on the size of your .org, if you're purchasing systems regularly you're more or less tied to Apple's OS release schedule, and can't handicap yourself by being dependent on a benchmark written for a specific OS release which may or may not be current.