Microsoft Selects SentinelOne to Power Mac & Linux Coverage for Windows Defender ATP. We’re excited and humbled to announce that Microsoft has selected SentinelOne to power Mac and Linux endpoint protection in the Windows Defender Advanced Threat Protection (ATP) service. The fact that SentinelOne. SentinelOne delivers cutting-edge security with this platform by offering protection against malware, exploits, and scripts. SentinelOne cloud-based platform has been perfected to be innovative compliant with security industry standards, and high-performance whether the work environment is Windows, Mac or Linux. Sentinel LDK Runtime v7.9 available for download December 18, 2018 SuperPro Updated CodeCover Engine – Windows 10 (build 1803) October 9, 2018 64-bit Branded runtime (v7.80 and above).
In our recent post, How Malware Persists on macOS, we discussed the ways that threat actors can ensure that, once they’ve breached a macOS device, their malicious code will survive a logout or device restart. But persistence is only one element of the kill chain, and some threat actors are known to shun persistence in favor of either one-time infections or a reusable vulnerability to remain stealthy. Then there’s the possibility of malware achieving its objectives and cleaning up after itself, effectively aiming to leave without a trace. Clearly, just looking for persistence items isn’t sufficient for threat hunting, so in this post we’ll take a deeper dive into how you can hunt for threats on a macOS device.
Gathering Information about the Mac
How you go about hunting down malware on a macOS endpoint depends a great deal on what access you have to the device and what kind of software is currently running on it. Of course, if you have a SentinelOne-protected Mac, for example, you can do a lot of your hunting right there in the management console or by using the remote shell capability, but for the purposes of this post, we’re going to take an unprotected device and see how we can detect any hidden malware on it. The principles remain the same if you have a protected device, and understanding what and where to look will help you use any threat hunting software you may already have more effectively.
The other thing to consider is whether you have access to the device directly, or only via a command line, or only via logs. For the purposes of this exercise, we’re going to assume that you have access to the command line and to any logs that can be pulled from it.
Step 1: Get a List of Users
The first thing you need to know is what user accounts exist on the Mac. There’s a couple of different ways of doing that, but the most effective is look at the output from dscl, which can show up user accounts that might be hidden from display in the System Preferences app and the login screen.
A command like
$ dscl . list /Users UniqueID
will show you a lot more than just listing the contents of the /Users folder with something like ls, which won’t show you hidden users or those whose home folder is located elsewhere, so be sure to use dscl to get a complete picture.
A downside of the dscl list command is that it will flood you with perhaps a 100 or more accounts, most of which are used by the system rather than used by console (i.e., login) users. We can narrow the list down by filtering out all the system accounts by ignoring those that begin with an underscore:
$ dscl . list /Users UniqueID | grep -v ^_
However, there’s nothing to stop a malicious actor from creating an account name that begins with an underscore, too:
So you should both check through the full list and supplement the user search with other info about user activity. A great command to use here is w, which tells you every user that is logged in and what they are currently doing.
Here we see that user _mrmalicious, which wouldn’t have appeared if we filtered the dscl list by grepping out underscores, is using bash.
While the w utility is a great way to check out who is currently active, it won’t show up a user that has been and gone, so let’s supplement our hunt for users with the last command, which indicates previous logins.
$ last
Here’s a partial output, which suggests our user briefly logged in and then shutdown the system.
Step 2: Check for Persistence
We’ve already covered this in a previous post, so please head there first and check out some of the obvious and not-so obvious ways we describe that bad actors can use to persist across sessions on a Mac.
Remember also that when looking for LaunchAgents and other processes, you have to consider all users on the Mac, including the root user, which if present should be found at /var/root.
Here’s one piece of Mac malware that likes to run from there. A system-level LaunchDaemon that runs on every boot for all users calls a python script hidden inside an invisible folder in the root user’s Library folder.
We also need to consider persistence methods that take advantage of open ports and an internet connection, so we’ll start looking into those next.
Step 3: Check Open Ports and Connections
Malware authors interested in backdoors will often try to set up a server on an unused port to listen out for connections. A good example of this is the recent Zoom vulnerability, which forced the company to push out an emergency patch in an attempt to address a zero-day vulnerability for Mac users. Zoom have been running a hidden server on port 19421 that could potentially expose a live webcam feed to an attacker and allow remote code execution. This is a good example of just how easy it is for one privileged process to set up a persistent server that could act as a backdoor to easily evade detection by ordinary users, as well as macOS’s built-in security mechanisms.
To detect this kind of issue, we can use netstat and lsof to help check for this.
First, we use
$ netstat -na | egrep 'LISTEN|ESTABLISH'
to list services that are either listening for connections or already connected.
We can see that there are servers listening in on ports 22, 88, and 445. These indicate that the Mac’s Sharing preferences are enabled for remote login and remote file sharing. A full list of ports used by Apple’s services can be found here.
Next, let’s use
$ lsof -i
Mac microsoft word double space same paragraph. If you don’t like those options, click Custom Paragraph Spacing and change the numbers under Paragraph Spacing. Don’t want to change the spacing in the whole document?
to list all files with an open IPv4, IPv6 or HP-UX X25 connection.
This output gives us quite a bit of useful information, including the IP address, command and PID. We can query the ps utility for more information on each process.
$ ps -p <pid>
Step 4: Investigate Running Processes
The ps command has a lot of useful options and is one of a number of tools you can use to see what’s running on a Mac at the time of collection.
One of the first things I’ll do is get a full list of all processes by running this as the superuser
$ ps -axo user,pid,ppid,%cpu,%mem,start,time,command
I will normally dump that out to a text file and pay particular interest to commands where the PPID, the parent process identifier, is something other than 1, indicating a user process that’s also spawning child processes.
I also like to dump the output from
$ lsappinfo list
as that gives a lot of useful information about applications including the executable path, pid, bundle identifier (useful for detection purposes) and launch time.
You should also examine running daemons, agents and XPC services through the launchctl utility. I find the older, deprecated (but still functional) syntax somewhat easier to parse than the newer syntax, but that may be just my preference from habit, so experiment with either.
In the old syntax, you can simply run
$ launchtl list
to get a lot of useful information on what’s running in that particular user’s domain. The same command prepended with sudo will produce a list of services running in the system-wide domain.
For the newer syntax, use something like
$ launchctl print user/501
Replacing ‘501’ for the UID of any user you’re interested in. Use
$ launchctl print system
Sentinel One Client For Mac Os
to target the system-wide domain.
The output between the old and the new syntax is quite different, and which you find more useful may depend on what kind of information you want. I often use the old syntax and grep out anything with a com.apple label so that I can focus on (mostly) non-system processes. However, some macOS malware does deliberately use the name “apple” in their labels precisely in an attempt to hide in the weeds, so if you do follow that suggestion be sure that you’re parsing items with “apple” labels somewhere else, too (e.g., such as from the data you received from examining the Launch folders or from using the ps utility).
Step 5: Investigate Open Files
Earlier we used lsof with the -i option to list open ports, but we can also list all open files by just running lsof without any flags at all. That produces quite a mountain of information and you’ll want to quickly narrow it down to make it manageable.
If the system is running with System Integrity Protection turned on (tip: you can determine that with the command csrutil status), I will normally parse the output of lsof in something like BBEdit and remove all lines that contain references to the System folder. Bear in mind that doing so could cause you to miss something – not all System folders are protected by SIP, but in the early stages of an investigation I will leave that kind of possibility for later in the event that I don’t find any other IOCs (Indicators of Compromise).
For similar reasons, I’ll tend to focus first on open files that don’t belong to regular apps. Again, keep in mind the caveat that malware authors can sometimes use regular apps to live off the land, exploit browser zero days or sneak in via supply chain attacks, so be judicious in what you filter out and remember to go back over anything you skimmed or ignored later on if necessary.
Step 6: Examine the File System
If I haven’t found any suspicious processes at this point, that could well be because the malware has already finished its execution, so next it’s time to start making an initial investigation into the file system. At this point, we’re just trying to establish that a threat exists, rather than do a deep forensic dive on the entire system (we’ll cover that in a future post), so let’s look at some of the resources you can quickly access and parse to look for evidence of malicious behaviour.
A word of warning, though, before we start. If you’re dealing with a macOS system from 10.14 Mojave onwards, you may find command line investigations hampered by macOS’s recent user protections. In order to avoid those, ensure that Terminal has been added to the Full Disk Access panel in the Privacy pane.
I tend to start by making an initial audit of files in certain locations that are often populated by malware. These include hidden files and folders in the User’s home folder, unusual folders added to the /Library and ~/Library folders, and the Application Support folders within all of those (remember there’s a separate Library folder for every user as well as the one at the computer domain level).
You can get those for the current user and the computer domain with a one-liner:
$ ls -al ~/.* ~/Library /Library ~/Library/Application Support /Library/Application Support/
Senitel One Client For Mac
You’ll need to drop down to sudo and iterate over users with a bash script if there’s more than one user account on the Mac.
Next, check the /Users/Shared folder, and the temp directories at /private/tmp and the user’s Temporary Directory (these are not the same), which you can get to using the $TMPDIR environment variable.
$ ls -al /Users/Shared$ ls -al /private/tmp$ ls -al $TMPDIR
Also, don’t forget that you should already have a list of items present in the Launch folders and any Cron jobs from your investigation into persistence mechanisms. More often than not the program arguments of these will have already led you to other locations of interest.
In the majority of cases, if a Mac has been infected the above steps will have turned up something and directed my searches further, but if not, there’s still a few other things to look for. If the time since the suspected infection is still relatively recent (within a few days or less), you may try a find search to look for any files created since or between a certain time or date. For example, this will find any files modified in the current working directory in the last 30 minutes. You can substitute the m for h to specify hours, or leave off a specifier and it will default to days.
$ find . -mtime +0m -a -mtime -30m -print
Depending on how much regular activity there has been on the device since then, and how long the timespan you search for, that could result in an overwhelming amount of data or just enough to be manageable, so adjust your search parameters to suit.
We can also query the LSQuarantine database to see what items have been downloaded by email clients and browsers.
$ sqlite3 ~/Library/Preferences/com.apple.LaunchServices.QuarantineEventsV* 'select LSQuarantineEventIdentifier, LSQuarantineAgentName, LSQuarantineAgentBundleIdentifier, LSQuarantineDataURLString, LSQuarantineSenderName, LSQuarantineSenderAddress, LSQuarantineOriginURLString, LSQuarantineTypeNumber, date(LSQuarantineTimeStamp + 978307200, 'unixepoch') as downloadedDate from LSQuarantineEvent order by LSQuarantineTimeStamp' | sort | grep '|' --color
Again, you could get a lot of data to sift through here, but filter on the dates to find recent items. The good side of LSQuarantine is it will give you the exact URL from where the file was downloaded, and you can use this to check against reputation on VT or other sources. The downside of LSQuarantine is that the database is easily purged by normal actions the user (or malicious actor) can take in the UI, so not finding something there doesn’t rule out that a file didn’t actually come through the quarantine process.
Another useful trick here is to see what turns up just by doing an mdfind query on the quarantine bit:
$ mdfind com.apple.quarantine
That should find documents – which are also tagged with the quarantine bit – that have been downloaded, including malicious pdf, Word .docx and others. Again, there’ll be a lot of innocent stuff in the results, so careful filtering will be required.
Step 7: Examine the Mac’s Network Configuration
Malware authors on macOS have in some cases manipulated the DNS and AutoProxy network configurations, so it’s always worth checking on these settings. You can get all these from the command line, so first let’s get the details of the network interface configuration with this command:
$ ifconfig
That will output information regarding the wireless, ethernet, bluetooth and other interfaces. You’ll also want to gather the SystemConfiguration property list to look out for malware that tries to hijack the Mac’s DNS server settings, as OSX.MaMi was seen to do in 2018.
$ plutil -p /Library/Preferences/SystemConfiguration/preferences.plist
Use this command
$ scutil --proxy
to inspect the Mac’s auto proxy settings. Spyware like OnionSpy has been seen to configure these settings to redirect user traffic to a server of the attacker’s choosing.
Dive Into macOS’s Hidden Databases
Depending on what access and authorization you have, it’s also possible to dive a lot deeper and recover very fine-detailed information about file system events, user’s browsing and email history, application usage, connected devices and more. In a future post on macOS Digital Forensics and Incident Response, we’ll cover things like Apple’s built-in system_profiler and sysdiagnose utilities, unified logging, fsevents and a plethora of sqlite caches that hold almost every detail you could ever wish to know. In the majority of cases, the steps outlined above will be sufficient to find evidence of even the most stealthy of macOS malware, but digging down into the hidden depths of macOS may provide you with more evidence that can help in detection, remediation, and attribution.
Conclusion
If you are interested in learning how to hunt malware infections on macOS, whether it’s cryptominers, adware, backdoors or nation state actors, the steps outlined above should give you a good start on where to look and what to look for. Don’t forget also to review our post on macOS persistence mechanisms as these are often the easiest indicators to detect, and if you’re interested in reversing macOS malware, check out our series on how to do that safely, too. And before you go, don’t forget to follow the blog and we’ll let you know when our next post is out.
Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.
Read more about Cyber Security
A little later in June than usual, Apple’s WorldWide Developer Conference (WWDC) 2020 kicked off this week in, of course, more than unusual circumstances. With COVID-19 still very much an issue as we hit the mid-year mark, Apple’s signature event has turned entirely virtual, allowing us all a front-row seat to take in the news, announcements and forthcoming developments across Apple’s platforms. Among those, the beta release of the next version of macOS is of major interest to enterprises and security teams. In this post, we round up the most significant changes we’ve seen announced so far affecting macOS security. Let’s take a look!
1. Will Your Hardware Support macOS 11.0 Big Sur?
In order to take advantage of the changes brought to macOS in Big Sur, you will of course need compatible Apple hardware. There are seven supported product lines for macOS Big Sur, with the earliest supported models going back to 2013:
- iMac Pro, 2017 and later
What does this mean for enterprise?
Ageing hardware in your Mac fleet is probably already feeling the heat from the resource-intensive Mojave and Catalina. The only real question is how much of your macOS hardware you want to update now before the ARM chip hardware becomes available at the end of 2020 and through 2021.
2. Big Sur Version Number: Is it macOS 10.16 or 11.0?
There were a couple of big shocks with the first release of the macOS Big Sur beta, neither of which were explicitly called out in Apple’s Keynote on Monday. The first of these, spotted by some eagle-eyed watchers, was that macOS 10.15 isn’t being superseded by macOS 10.16! Instead, Apple have finally put the nail in the coffin of the 20-years of Mac OS X, now not just in name but in version number, too: Big Sur is to be the first macOS 11.0!
What does this mean for enterprise?
Such a small change, but it will have consequences for many enterprises, as Apple themselves are finding out. So many enterprise workflows rely on scripts that check for version numbers in the 10.x range that many of these are going to be instantly broken.
Even Apple’s own software update check is probably counting in 10s, and the first beta was delivered as 10.16 (and possibly the rest, too; indeed, there’s plenty of internal documentation referencing “10.16”).
3. Kexts Get a Temporary Stay of Execution
Another big surprise turned out to be that the much-anticipated demise of kernel extensions did not occur, although Apple have certainly put in enough roadblocks to make developers and users want to transition away from kexts as fast as possible and migrate to using System Extensions and DriverKit instead.
Nonetheless, kexts remain an open possibility for organizations that have critical dependencies, and there’s a new tool kmutil to manage loading, unloading and diagnosing kexts and “kext collections” on Big Sur.
What does this mean for enterprise?
Organizations will be able to upgrade to macOS Big Sur without fear of losing functionality from software that depends on kernel extensions. However, it should be noted that kextutil and kextload have now been replaced by kmutil and there are changes and restrictions on how these work (see the man page for details).
Apple have made it clear that there’s no let up in the drive to move developers away from kexts, advising that:
SentinelOne customers can be assured that our forthcoming macOS 4.4 Agent does not use kexts and will be compatible with macOS 10.15 Catalina and macOS Big Sur.
4. Compatibility with Rosetta 2, Apple silicon and Universal Binaries
Of course, one huge change that was mentioned at the end of the Keynote was the one that has been widely anticipated in the media: Apple’s move to an ARM-based chipset for macOS, dubbed “Apple silicon” at WWDC 2020. Although there is no ARM-based hardware available at the moment, a Developer Transition Kit is being made available, and Apple have said they expect to start shipping ARM Macs in late 2020.
To facilitate this transition, Apple have resurrected an old friend familiar to those that remember the PowerPC-to-Intel transition: Rosetta. Psa xs evolution driver. Reinvented as Rosetta 2, this software-layer technology will allow certain classes of software compiled on Intel architecture to run on ARM-powered devices.
However, there’s a couple of gotchas with Rosetta 2. First, the translation inevitably takes time, and no amount of clever optimization will alter the fact that some applications relying on Rosetta 2 will launch or run slower than they would if run natively on the Intel architecture they were compiled for. To help avoid this problem, Apple have also introduced a new multi-architecture, Universal (aka ‘Fat’) binary format. This allows developers to port existing macOS apps to run natively on Apple silicon. With Xcode 12 or later, developers can build a “fat” binary that contains architectures for both machines: an ARM-based Mac isn’t required to compile these universal binaries.
The second problem with Rosetta 2 is that it won’t translate all software compiled on Intel architecture into something that will run on Apple silicon. In particular, Windows virtualization software and kernel exensions are not supported. Those hoping Rosetta 2 might give them a ‘get out of jail free’ card for their kernel extensions will have to think again. It remains unclear what future there is for Windows Virtual machines on macOS, though VMWare at least seem to still be holding out some hope that all is not lost.
What does this mean for enterprise?
The widely-anticipated transition to ARM, which Apple expect to happen over 2 years, will not have any immediate effects on enterprise, but in the mid-to-long term IT teams will need to inventory which apps can run natively with universal binary, which are labouring under Rosetta 2 translation, and which are just incompatible.
Perhaps the biggest choice affecting organizations here, as mentioned earlier in this post, is deciding on when to upgrade hardware, and whether it’s in your businesses’ best interest to await ARM-powered Macs before further purchases.
5. Keep Out! A Cryptographically Signed System Volume
Aside from the big changes we’ve already covered, there are some important changes that have received less attention. Among these is that macOS 11 brings cryptographic signing to the System volume. In Catalina, Apple already made an architectural change to split the root volume into two: a read-only System volume and a Data volume for everything else.
Now, the System volume receives extra protection by being cryptographically validated to prevent offline attacks and malicious tampering.
What does this mean for enterprise?
As messing with the System has been a “no-no” since Apple introduced System Integrity Protection way back in macOS El Capitan 10.11, this hardening of the System volume shouldn’t present too many challenges to IT and security teams.
There are a couple of upshots, however. One is that FileVault no longer needs to encrypt the System volume at rest on macOS 11. The Data volume will still be protected by FileVault encryption, if it is turned on.
Secondly, attempting to boot a “live” version of the OS (i.e., a writable filesystem) by turning off System Integrity Protection will no longer work. It is possible to disable the protections and make modifications while it is not booted, but “live” modifications are now off the table in macOS 11.
6. Networking Ins and Outs
There’s a number of small changes to networking and internet use that could affect your security or workflows that we will lump together here.
The first, publicly reported by macrumors, is that the long-standing Network Utility app has been “deprecated”, although from what we can tell it’s actually now entirely non-functional.
The Network Utility contains a bunch of useful tools like Netstat, Ping, Traceroute and Port Scanning among others.
Apple have also added a useful Privacy Tracker and blocker to Safari that allows users to see what tracking cookies a site is using and that Safari has blocked. Publicly reported here, the Privacy toolbar button provides detailed insight through a popup with a number of further pop-outs accessed from within.
Given the extensive malicious use of extensions in all popular browsers, security teams will want to take note of the new Web Extensions feature in macOS Big Sur. This allows existing Chrome and Firefox extensions to be easily converted to use with Safari 14 with the xcrun tool. Apple hope to ameliorate security concerns around this by continuing to insist browser extensions must be distributed through its App Store. There are also new user controls for managing extensions in the browser.
Safari 14 will also reportedly have HTTP/3 enabled by default. According to Apple’s release notes, Big Sur enables experimental HTTP/3 support in Safari via Experimental Features in the Developer menu. It can be enabled system-wide using the following Terminal command:
Sentinel One Client For Mac High Sierra
And since we’re discussing the command line, another networking change in macOS 11 pertains to the networksetup utility, /usr/sbin/networksetup. As of Big Sur, this tool will no longer allow standard users to change network settings. Standard users will be able to toggle Wifi on and off and read the network settings, but modifications will require an administrator user name and password.
What does this mean for enterprise?
Overall, these changes should help to enhance network security. The change to the networksetup command line tool is in line with permissions that standard users have in the System Preferences.app, and it’s nice to see Apple get consistent across tools.
We also don’t envisage a significantly greater attack surface arising from an increase in browser extensions so long as Apple’s App Store does the work of monitoring and removing these for malicious or abusive behaviour in a timely and effective manner. The onus there, of course, is on Apple, and enterprise security teams may well feel that locking down the installation of browser extensions through MDM or similar configuration tools is something worth considering given both the history of malicious extensions and how much of our private and sensitive data goes through browser applications. On that, the new privacy reporting tool is a welcome addition to Safari 14 in Big Sur.
Finally, on networking, the removal of the Network Utility app shouldn’t cause much consternation among IT teams. You probably are already using the command line equivalents of the tools it provided a GUI wrapper for, so we don’t expect this to be missed by too many.
7. Certificate Trust: Root Is Not Enough
With macOS Catalina and earlier, the command line security tool can be used to change certificate trust settings if the effective user is running as root via the add-trusted-cert flag, as shown in the tool’s man page on a Catalina install:
In macOS Big Sur, simply running with UID 0 will no longer be sufficient to make this change: confirmation will be required with an administrator password.
In a fortunate nod to managed enterprise environments, Apple will allow the change to take place without confirmation if the certificate payload is deployed with the root certificate using a configuration profile.
What does this mean for enterprise?
This welcome hardening to certificate trust settings may affect your workflow if you use the security command-line tool to change trust settings or a privileged process calling the SecTrustSettingsSetTrustSettings function.
8. Configuration Profiles Get Preferential Treatment
Configuration profiles, managed through the command-line profiles tool or the Profiles System Preferences pane, have been abused by macOS malware for some time now. Chief among the perpertrators are adware infections seeking to manipulate browser home page and search settings, although others have been seen that configure things like malicious DNS settings, too. Profiles started to become a preferred target by adware after Apple took steps to lock down Safari browser preferences in previous OS releases.
In macOS Big Sur, Apple have acknowledged this abusive use of profiles and now raised the bar for their installation. Unless the device is enrolled in an MDM program, installing a profile will now require the user to manually finish the profile installation in the System Preferences app, where a window will also describe the profile’s actual behaviour.
Somewhat oddly, there is an 8 minute timeout on this action: if the user does not complete the installation within that timeframe, macOS Big Sur will remove it from System Preferences.
What does this mean for enterprise?
Your enterprise is likely only using profiles through an MDM solution, and so this change shouldn’t affect most. If for some reason you are manually scripting the installation of profiles, you will need to engage in user education to teach them how to complete the steps (in less than 8 minutes!).
While malicious use of profiles through social engineering will undoubtedly be tried by adware and other macOS malware vendors, this change should have a welcome impact on reducing some of the worst offenders.
9. Surprisingly, No Surprises in App Security
Although WWDC 2020 is far from over, we haven’t seen any announcements or suggestions that Apple will change their approach to App security with macOS 11. With so many under-the-hood changes focused on security, enterprise security teams might have been hoping for some major developments, but as yet that remains to be seen.
In macOS 11, it seems that Apple will continue to rely on the model that’s been slowly evolving through the macOS 10.x years but which is still somewhat behind the rest of the industry in relying on static signatures for blocking and detection. The app security model continues to look something like this:
- Protect: codesigning, notarization, and system policy checks via Gatekeeper
- Detect: malware blocking via static Yara rules in XProtect
- Remove: removal of known malware via static detection signatures in MRT.app
What does this mean for enterprise?
While Apple admirably places lots of focus on security – and some of the changes in Big Sur are more than welcome – it does seem oddly out-of-touch in some respects. Even Windows now has some rudimentary behavioral detection, and Apple’s reliance on its triumvirate of Gatekeeper, XProtect and MRT.app is starting to look and feel dated.
Gatekeeper and Notarization are weakened by simple social engineering ploys that attackers began using with 10.14 and have only got better at. XProtect’s static YARA rules rely on malware already being known to Apple (i.e., some user or organization has to first get infected before Apple can update the signatures), and MRT.app only runs when it is updated, the user logs in or reboots the Mac – meaning it is impotent for most of the time the Mac is actually in use.
Moreover, for enterprise security teams, there’s no visibility as to what any of these tools are doing or have done. Even with Apple’s latest iteration of macOS, with its new name, new version number and many new features, there’s still every need to keep your Macs protected by a behavioral security platform that can detect, protect and report on known and unknown malicious activity.
Conclusion
WWDC 2020 still has a few days to run, and we’ll update this post in light of any new announcements in the rest of the week. From what we’ve seen so far, we like the look of macOS 11 and welcome the changes that have been reported. Most of these should help your security team to improve the security posture of your macOS fleet with only a few changes needed to most workflows.
Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.
Read more about Cyber Security