Mac Endpoint Security: What Apple Admins Need to Know

Mac administration is always evolving. One example of that evolution: Many Mac admins these days are being asked to at least help manage the security of their Mac fleets. That, in turn, means they need to understand the four basic components of Mac security:

• Hardening devices;
• Patching software;
• Understanding threats; and
• Achieving compliance.

They also need to understand where and how the management tools they use every day—such as their MDM solution—can help implement or manage those four components. Here’s what you, as a Mac admin, need to know about Mac security and managing it with the help of MDM.

Hardening macOS

To use a music metaphor, the first step in becoming a rock star is to master your instrument. In this metaphor, the Mac, as a security endpoint, is your instrument. You have to understand the security foundations built into macOS that can harden the Mac against attack. Three examples of those foundational components: Passwords, the lock screen, and disc encryption.

Passwords

You know it's imperative to set a good password on any device. As an admin, you can ask users to set such codes to unlock their Mac computers. But with an MDM solution, you can actually enforce your password policies. 

With MDM, you can not only require passwords but also set minimum standards for their length and complexity—“Make sure the password is more than 10 characters,” or whatever length your security standards demand.

Lock Screen

OK, so you’ve set standards for user passwords. But when will those passwords be required? You need to be sure that a stranger can't get access to a Mac by just opening its lid and waking it from sleep (or by dismissing the screensaver). With the lock screen turned on, it will require the password when any of those things happen.

Again, you can ask users to configure their own lock screen settings. But using MDM, you can enforce things like:

• The grace period before which a password will not be required when the device is awakened or opened;
• The use of screen savers (with settable times);
• The number of attempts that will be allowed before the account is locked out; and
• Whether or not end users can change these settings.

Full Disc Encryption (FileVault)

A third tool for hardening the Mac as an endpoint: disc encryption. It prevents someone who's taken a physical device from reading its data. In the case of the Mac, this means FileVault.

Most admins know how to turn on FileVault and use it themselves. But their users may not. Again, you can use MDM to enforce policies to make sure that all of your endpoints are encrypted, so you can make sure they all benefit from FileVault’s protections.

With MDM, you can do more than ensure that FileVault is on: If you've just done so, you can force endpoints to reboot so they’re covered by its protections. You can define options for the FileVault recovery key—ideally choosing to escrow it somewhere safe where only you, as the admin and the actual owner of the device, can access it. 

That way, if a user turns in an old device to get a new one, but there’s something on that old computer that you need, you’ll have the keys to unlock it. 

Those are just some of the security tools built into macOS. Your job as an admin is to know as much as you can about as many of them as you can and learn what you can do to manage them via MDM.

Patching macOS 

One of the most useful things an MDM solution can do for you is to deploy software to endpoints. This includes all the vital productivity tools your users rely on every day: Microsoft Office, web browsers, communication tools, web conferencing, and on and on.

But it's also vital to understand how secure that software is and how one piece of software might interact with another and with the platform they’re all running on. To pursue our musical metaphor, it’s like learning how to play with other musicians. In security terms, we’re talking about understanding software vulnerabilities.

One way to learn about vulnerabilities in general and about the specific ones that might be in your organization's apps: Understanding common vulnerabilities and exposures (CVEs). The best-known database of such vulnerability reports is the NIST’s National Vulnerability Database. Let’s walk through one such report. 

At the top, you’ll see the Description section:

There you’ll find details about what the vulnerability is. In this case, it’s a vulnerability in Google Chrome (before version 112.0.5615.137) that allowed a bad actor (with the help of an unknowing user) to inject malicious code into “heap” memory. (“Heap” being memory space that had been freed up; malicious code there can surreptitiously slip into the computer’s processing stream.)

Next, look at the Severity section. 

Vulnerabilities are rated on a scale of 1 to 10 according to the Common Vulnerability Scoring System (CVSS). In this case, the vulnerability has scored a 7.5, indicating that it’s fairly serious. But that’s a base score. It can be modified by taking into account temporal and environmental factors. (The first considers the maturity of the exploit; severity generally diminishes over time. The second looks at the specific environment: If you don’t allow Chrome in your organization, a Chrome exploit isn’t a great threat.)

The Severity box also contains information—under the Vector subheading—about how that score was calculated. For this particular CVE, those factors included:

• AV: Attack vector; in this case, it’s N for network, meaning it spreads over the internet. 
• AC: Attack complexity, or how difficult it is to pull off. In this case, it's highly complex.
• PR: The account privileges the vulnerability requires. This one does not require any, which is especially concerning. 
• UI: User interaction is required. In this case, this vulnerability can take advantage just by getting someone to navigate to a webpage that uses this exploit.

Each threat is also classified according to the known weakness it exploits. In this case, that weakness is known as CWE-416; there’s a separate database that keeps track of those.

There’s plenty more information in this CVE, but those are the facts most admins will care about. The gist of this one: This is a vulnerability in Chrome whereby a remote attacker could steer a user, via custom HTML pages, to gain access to the computer’s memory; from there, it might be able to extract information that could be used to continue an attack. 

As an admin, a score of 7.5 is something you’d want to pay attention to. But you’d also want to dig a little bit deeper to understand the components of the score and how it might affect you. For example, if you’ve already patched Google Chrome to a later version, you can move on. But if you do have an earlier version of Chrome, you’d want to prioritize that patch.

The point is that there will always be vulnerabilities. Chances are that some of the software running right now on your organization's devices has some. You'll always have some on your systems. It’s up to you to be aware of them and then figure out how to manage them. 

The best response: Patch your software. Developers are constantly monitoring for vulnerabilities and issuing updates to address them. With an automated patch management system (such as Kandji's Auto Apps) in place, you can be sure that your users have the latest, least vulnerable versions of their apps and operating systems.  

macOS Security Threats 

The next step is from vulnerabilities to actual threats. You know and accept that there are vulnerabilities in the software on the devices you manage. But sometimes, those vulnerabilities are exploited. When someone or something exploits such a flaw, it can become a threat. 

In our music metaphor, this is when things get real: You're not just practicing with the others, but you're actually going out there and performing for a live crowd.

Threats are malicious. They purposefully try to do something on the devices you manage that you don't want to happen. Threats can represent a continuum of impact, from the innocuous (adding an album you don’t want to your music library, say) to the severe (gaining access to access to the databases where you store your company’s customer information).

Threats come in many forms and are known by many names: adware, keyloggers, ransomware, spyware, trojans, viruses, and worms. But for simplicity’s sake, it helps to think in terms of two categories:

Malware is software that’s designed to be malicious in some way. Again, there's a continuum from annoyances to existential threats.

Then there are potentially unwanted programs (or PUPs), which is software that might be knowingly installed but which has consequences you didn’t count on. It’s malware in that it produces side effects with malicious intent. It could be something as seemingly innocuous as a web browser that you’d prefer users didn’t install or when people install World of Warcraft on their work devices.

Or take the example of MacKeeper. (We are purposefully not linking to it.) It’s a utility that promises to “clean” the user’s Mac; it claims to offer antivirus protection, as well. But it would be classified as a PUP in the sense that you don't want it on your organization’s computers. It has some elements of malware. For one thing, if users install it, they’ll be inundated with adware, which is annoying and can degrade performance. More seriously, at one point, studies showed that 50 percent of the malware on macOS was introduced with MacKeeper. It’s a classic PUP.

When thinking about threats, it can help to look at three behaviors:

Infection

Before it can do anything, a threat needs to find a way to be installed on a host. There are a couple of common techniques:

User interaction: This means trying to trick the user into downloading and installing some software. Perhaps a user sees a web pop-up that says, "We found 37 critical items on your device. Click here to download software to clean it up!" Or an email that seems to be from HR: “Log in here to complete your annual payroll withholding review.”

Exploited vulnerability: As we explained above, sometimes legitimate software has a vulnerability that bad actors can exploit. One infamous example: Many years ago, the Internet Explorer browser contained a component called ActiveX. It turned out that Active X contained multiple vulnerabilities that allowed software to be downloaded and installed automatically without user intervention. That’s all been cleaned up, of course, but it remains the classic example of how legitimate software can be a gateway for malware. 

Supply chain: This one’s becoming more prevalent. An attacker is able to inject its malware into systems before they’re distributed to customers and can therefore attack those customers en masse. The most recent example: A telephony app from 3CX. 

Persistence

Once a piece of malicious software gets installed, it wants to stick around. Otherwise, it could be wiped out by a simple reboot. On Mac, there are two common modalities for achieving persistence:

• Launch agents, which run in user space and don’t require admin privileges; and.
• Launch daemons, which run system-wide as soon as the computer starts up but do require elevated privileges to install.

The one piece of good news here: the locations and methods for installing or activating launch agents and daemons are well-known and understood. At one point, we came up with a list of 17 different locations on a Mac where these kinds of files could be created. So you can always look for agents and daemons being installed. 

There are other, less common ways of achieving persistence, including login items (which now require more user interaction before they’re enabled), cron jobs, and kexts.

Going back to our MacKeeper example, it installs a launch daemon that allows it to run at OS startup. And it installs a kext that keeps the code on the device even if you run the uninstaller. 

Impact

This is when the malware executes its core mission, which could be lifting data; holding data for ransom (ransomware); extreme marketing or entrapment (aka adware); or espionage (spyware). 

For organizations, the impacts run the gamut from lost productivity to lost money or proprietary information. At this stage, you’re losing something, and now you also have to lose time fixing the problem.

That’s why it’s worth investing in tools that will prevent malware and PUPs from installing in the first place, that will remove it if it does get installed, and that will prevent it from running again. Your MDM solution can be an important part of that strategy.

Tools

The history of malware on Apple devices has been a leapfrog pattern of threat followed by counter-measure followed by new threat followed by new counter-measure, and so on. 

The first piece of Apple-specific malware was Elk Cloner in 1981, which ran on Apple 2 computers. In 1987 we got antivirus software, which scanned volumes for known viral objects and removed them. But AV software was never ideal: It missed unknown harmful objects and relied on definitions that had to be constantly updated; that update cycle might not be tight enough for it to catch new threats.

Then came the internet, which offered new ways for threats to appear on devices and created the need for new tools that could scan for threats that didn’t come on floppy disks. Apple responded with new, smarter countermeasures.

The first of these came in 2007: file quarantining. If you downloaded software from the internet, it wasn’t automatically trusted. A dialog was presented to the user, checking to be sure they meant to install the software. Among other things, this thwarted drive-by downloads, where you'd visit a website, and it would silently download and install something. Placing that quarantine flag on a downloaded file prevented that from happening.

Then in 2009, we got the Malware Removal Tool, XProtect, and Gatekeeper, all of which can block known malware from running; Apple itself maintains the list of things to block. Those tools are still hard at work today.

In 2013, we got the first endpoint detection and response tools for Mac. These went beyond traditional AV, adding behavioral analysis to file-based detection. EDR can look for malware at the infection stage. It can keep an eye on which files are being created, for example, and if it sees behavior that’s consistent with known malware, respond appropriately.

With the introduction of macOS Catalina in 2019, Apple introduced its Endpoint Security framework (ESF), an improved solution for detecting threats. ESF is an API for monitoring system events for malicious activity, authorizing pending events, and receiving event notifications. It’s relatively lightweight in terms of system resources, and it enables security solutions to see what's happening on a device in real time. 

With ESF, security vendors can create logic to perform actions triggered by events. (For example: If you detect a file download, check its metadata for signs of malware; if you see such signs, kill the download.)

Achieving Compliance

Recalling our music analogy, we’ve talked about a progression: 

• Learn your instrument—in this analogy, the Mac and the details of what you can configure and install and protect on the endpoint.
• Learn to play with others—how to make the different components on your devices work together.
• Learn to play live—threats and how they actually behave on your platform.

Now we’ve come to the fourth step: Compliance is where you, as an admin, can become a rockstar, where you put together all the other things you learned and not just respond to threats but prove to the world you know how. Compliance events—such as an audit—are like recording your band for posterity. Before you do that, you need to make sure that everything is dialed in, that you've got all the components in place, and that everything’s working the way you want it to. Compliance audits are showcases for your device management and security chops. 

Compliance might be required by your organization because of contracts with customers or suppliers. But most of it is really just good common sense. Compliance frameworks are useful to anyone in evaluating their security stance and how well they're doing in achieving the kind of security that they want for their organization. 

There are a bunch of compliance standards, including:

• Center for Internet Security (CIS);
• National Institute of Standards and Technology (NIST);
• Cyber Essentials;
• General Data Protection Regulation (GDPR);
• Health Insurance Portability Accountability Act (HIPAA).

There are also a variety of auditing standards and reports, including: 

• SOC 2;
• ISO27001;
• PCI.

Some of these standards are local—more prevalent in the U.S., Europe, or other markets. But they share a lot of controls in common. 

Audits can be painful and might feel like busy work. But it's way better to discover your security issues in an audit than in an actual breach. At the end of the day, the goal is to have other organizations confide in and transact with yours. In many cases, that starts with being able to trust your work as an admin.

As an admin, you now have the tools—MDM and others—to be a major player in your organization’s security and compliance efforts. Whether you’re leading those efforts or just following along, your understanding of these four pillars of Mac security will go a long way toward keeping your organization’s fleet safe.

Editor's note: This post is based on a presentation "Security for Mac Admins" delivered at this year's Mac SysAdmin & Developer Conference (MacAD.UK 2023).

About Kandji

Kandji is the Apple device management and security platform that empowers secure and productive global work. With Kandji, Apple devices transform themselves into enterprise-ready endpoints with all the right apps, settings, and security systems in place. Through advanced automation and thoughtful experiences, we’re bringing much-needed harmony to the way IT, InfoSec, and Apple device users work today and tomorrow.