Recently, Apple released the next major version of OS X, now 14 and a half years, nearly to the day, since OS X was first released. The platform has come a long way, not just in features, usability and performance, but also with respect to security.
With El Capitan, Apple continues its growth and acceptance in the enterprise market. As a provider of enterprise software, Bit9 + Carbon Black has known for years that supporting OS X as an endpoint platform is a necessity. As malware and APTs against OS X have increased, the fact that no platform is 100 percent secure has been embraced by OS X engineers.
As early as OS X 10.6, Apple added Xprotect, also known as File Quarantine, a technology where the system tracks the originating source of files. Files downloaded via the Internet receive a protection bit that identify them as something the user should be warned about. 10.6 included the addition of known malware signatures. In 10.7.5, Apple introduced Gatekeeper, a very coarse-grain trust mechanism that enables the user to trust signed applications (whether from the Apple store or third-party developers). And this is where Apple begins to approach security in a similar way to the Bit9 Security Platform.
It is infeasible to blacklist all known malware—there is just too much of it—but tracking the known-good software and applying trust is a much more manageable and secure solution. Apple first acknowledged the need for a trust mechanism with Gatekeeper. Gatekeeper has been around for nearly four years and only recently have researchers started finding clever (and limited) ways to bypass it. These techniques are not vulnerabilities in the mechanism, but a limitation, which Apple has said it will close. After Gatekeeper came more advanced trust mechanisms.
In 10.9 came the soft requirement of signing kernel extensions (aka kexts or drivers) and the kextcache. 10.9 kext signing is considered soft because you could still install an unsigned kext in a legacy location and have it load. Apple wanted to give the relatively small number of kernel developers a chance to apply for and use the new signatures before making it a hard requirement in 10.10.
As a kernel developer, I will say that the process of obtaining a certificate for kext signing is not trivial. Apple wants to know why you need one and what you plan to do with it. They also reserve the right to revoke said signing certificate at any time. Signing kexts and verifying the intent of developers is a strong layer of protection against rootkits on the system.
In 10.10, a kernel extension must be signed with an Apple-generated certificate to be loaded. As with all signing mechanisms, if the binary hash doesn’t match the one contained in the signature, the system knows it has been compromised and will not load it nor include it in the kextcache.
In 10.10, the kextcache also is signed and if the kext cache is modified after signing and before boot, the boot mechanism will rebuild it using only validly signed kexts. For a rootkit to be installed on 10.10 and later, gaining root privilege is not the only, or even the highest, hurdle. Apple’s recognition that root can be compromised is well received.
Still, there were mechanisms to bypass kext signature checking, even on 10.10. Namely, the nvram could be set with a boot parameter to disable kext signing checks. This was intended for developers to test their kexts without the need for using their signing certificate. This is important since most developers do not want to sign every build they use for testing.
However, the issue with the nvram setting is that it does not require physical access, so an attacker with remote access that gains root privilege can disable the kext signing requirement. With El Capitan, Apple limits trust of the root user even further with System Integrity Protection (SIP). Apple also removes the nvram boot args that disable kext signing checks. Now for developers to test unsigned kexts, they must have physical access in order to boot the device into Recovery, disable SIP and reboot.
What does SIP actually do? The details are all here:
https://developer.apple.com/videos/wwdc/2015/?id=706 in a publicly available WWDC session from June. Fast forward to 4:50 to get to the SIP discussion. In short, SIP is a file integrity control mechanism that protects the system from unauthorized modification. Specifically, it protects the following locations on the system:
Additionally, SIP protects system processes from dynamic attachment and code injection. With SIP, OS X becomes one of the most secure endpoint platforms available.
For the last three years, the Bit9 Security Platform for Mac OS X has provided the same capabilities as SIP via its file integrity monitoring and control technology. Bit9 provides the ability to protect any set of directories and files from unauthorized modification, including modifications made by the root user. Policies that describe these protections are very easy to create and can be flexible in what aspects of the modification (path, process, user, etc.) are trusted to make modifications.
Additionally, Bit9 for Mac provides execution control, and since 7.2.0, Bit9 for Mac has protected itself against tampering in similar ways that SIP protects itself from attachment and code injection attacks.
Is SIP enough? No. Despite the fact that we can be assured that the system is being modified only by trusted sources, no single mechanism is sufficient. Even with SIP, threats both internal and external exist that can still compromise a system without violating the restrictions placed by SIP. Bit9 is compatible with SIP and will extend protection to areas not covered by SIP.
Additionally with Bit9 + Carbon Black you gain continuous visibility and monitoring of threats that go beyond the built-in protections of OS X. As a user of and a developer for OS X, Apple deserves recognition for the security measures present in El Capitan.