Continuing from the above understanding, it's important to ensure that the proper tools and practices are pursued, for effectively protecting macOS, and avoid any misunderstandings (or worse disasters) that can arise by attempting to treat two very different computer operating systems as the same.

One thing that protecting both OSes (macOS and Windows) have in common, is that the best security is a layered approach, and with that in mind: Your first best layer of protection is user awareness and training (Security awareness and best-practices for users).

In terms of Security researchers who represent expertise most worthy of your attention, I recommend you devote some time and attention to Patrick Wardle (his website is https://objective-see.org/index.html) and Phil Stokes (his blog is here: https://sqwarq.wordpress.com). Which is not intended to imply any disregard for anyone else ! But please do your own research, and be a particularly careful consumer when it comes to bold statements or claims relating to the security of macOS.

An understanding of the native security capabilites of macOS and Apple hardware, should cover at least ASLR, SIP as well as Gatekeeper, Notarization, and XProtect.

I recommend further reading listed at the end of this post.

In the current day and age (and probably as far back as the last 5-7 years), another critical layer of a meaningful security posture is DNS-level protection/filtering.
Common choices here are Netskope, DNSFilter, Cisco Webroot (look for any history of compatibiility issues), and Zscaler amongst others. At a smaller scale, you might care to trial NextDNS.

If you're working with Jamf (or not, it's not a requirement), I recommend you look into Jamf Protect (for historical context, read about the past work of Patrick Wardle).

In terms of Security Software for macOS, opinions differ greatly here.
Some like to believe that nothing more is needed than the native features of the Apple software and hardware. Given the state of the current threat landscape (for technology and online communications), such a perspective is probably overly-confident and probably unduly biased in favor of Apple.

That said, in my opinion, many common "Anti-Virus" offerings don't actually offer anything that specifically protects against the current real-world threats that exist for - and are specific to- macOS. In other words, I'm not entirely convinced that many of them accomplish anything ...that is properly or thoroughly effective. Beware of products that appear to "check a box" (eg when it comes to compliance requirements), and please look carefully into whether the product does provide the intended goal of effectively protecting macOS.

That said, so-called "Next-Gen" security software can indeed provide real, worthwhile protections. Common choices here with cross-platform support are Crowdstrike Falcon https://www.crowdstrike.com/platform/endpoint-security/, and Sentinel One https://www.sentinelone.com

If you need to deal with regulatory compliance, I recommend you read Apple's article very nicely directing us to the macOS Security Compliance Project (mSCP)
Jamf also has information here: Enforcing CIS, STIG and More to Meet Auditor Standards

Additional considerations should of course include keeping your fleet up to date, which means MDM is a requirement. While I've mentioned Jamf, other popular choices (also not limited to the MDM exclusively) for macOS are Kandji, Mosyle, Addigy, and SimpleMDM. However, if you're specifically Sys/DevOps (GitOps, CF management) oriented in your practices, you could do well to look at FleetDM, Zentral, or even roll your own with MicroMDM and perhaps AutoPkg, Munki, Chef, Puppet, Salt or Ansible.

At this time, while I use Intune extensively with Windows, it would not yet be a first choice for macOS. It might be fine for your needs for iOS

Additionally, you should of course choose a trustworthy Identity Provider and configure it appropriately.

Additional information about iOS security is available from Apple.

Additional further reading from Apple:
https://support.apple.com/guide/security/welcome/web, https://www.apple.com/macos/security/ , https://support.apple.com/guide/security/protecting-against-malware-sec469d47bd8/web, as well as https://support.apple.com/guide/security/hardware-security-overview-secf020d1074/1/web/1

Get-AzResource

along with:

Get-AzSubscription

Originally published by me, March 15th, 2024

Commands for determining the active network interface and working with DNS server settings:

When we want to programmatically determine the existing primary network interface ID, name and existing DNS servers, there are a few different ways we can go about this:

serviceGUID="$(printf "open\nget State:/Network/Global/IPv4\nd.show" | /usr/sbin/scutil | /usr/bin/awk '/PrimaryService/{print $3}')"

serviceName="$(printf "open\nget Setup:/Network/Service/${serviceGUID}\nd.show" | /usr/sbin/scutil | /usr/bin/awk -F': ' '/UserDefinedName/{print $2}')"

!!! OR !!!

activeIF=$(route -n get 0.0.0.0 2>/dev/null | awk '/interface: / {print $2}')

serviceName=$(networksetup -listnetworkserviceorder | grep "$activeIF" | awk -v FS="(Hardware Port: |,)" '{print $2}')

The problem with cataloging existing DNS servers, when they are supplied via DHCP

When DNS servers are provisioned via DHCP, a common approach for determining the IP addresses for said servers will fail:

/usr/sbin/networksetup -getdnsservers "$serviceName"

Returns with incorrect info: “There aren’t any DNS Servers set on <serviceName>”

Which is hardly useful ! So, we can proceed with the following:

For utility and extra tech-type fun, let’s use an array !

currDNS=($(/usr/sbin/networksetup -getdnsservers "$serviceName"))

if [[ ${currDNS[0]} == "There" ]]; then
  currDNS=($(ipconfig getsummary $activeIF | awk -v FS="({|, |})" '/domain_name_server/ {$1=""; print $0 }'))
fi

# check the array, via 
# declare -p currDNS
# For an example of working with the captured info:
# echo ${currDNS[0]}

# So now you can capture those existing DNS servers and append another

/usr/sbin/networksetup -setdnsservers "$serviceName" ${currDNS[0]} ${currDNS[1]} 8.8.8.8

# gcloud list all projects in root folder of organization in GCP:
gcloud alpha projects search --query="parent.id=<tenant_ID_Here"

gcloud projects list --filter 'parent.id=<id_here> AND parent.type=organization' | awk '{print $1 }' > projects.txt

And from there, reference the following with something like:

for Project in projects.txt; do gcloud projects get-iam-policy Project; done

Originally shared December 15, 2023

Start by listing all projects in the root folder of an organization in GCP:

gcloud alpha projects search --query="parent.id=<tenant_ID_Here"

AND

gcloud projects list --filter 'parent.id=<id_here> AND parent.type=organization' | awk '{print $1 }' > projects.txt

And from there, reference the following with something like

for Project in projects.txt; do gcloud projects get-iam-policy Project; done

For more information and reference, see https://stackoverflow.com/questions/44746358/how-do-i-list-all-iam-users-for-my-google-cloud-project

(This is actually a longstanding issue with macOS and the Finder).

–

An available workaround as remediation:

This is a long-standing issue with (shortcoming of the macOS Finder, in that it’s not very good at picking up changes or auto-refreshing in response to underlying changes in a network-based volume. It can happen with OS X Server-based AFP, and various vendors’ AFP or SMB server-based shares/network folders. One thing we can easily do is create an AppleScript to prompt/prod the Finder to refresh. Save it as an application, store it somewhere safe from accidential deletion (eg: /Library/CompanySupport) and then add it (drag and drop) to the top of a Finder window. Users can click on it to cause a Finder refresh. Optionally, you can add a dialog stating that a refresh is happening.

The AppleScript content is below:

try
 tell application "Finder" to update items of front window
end try

And with a dialog:

try
 tell application "Finder" to update items of front window
 display dialog "Refreshing the Finder" default button "OK" giving up after 1
end try

Investigating further

If you look at the running processes, you may see an existing softwareudpated process listed, which might have been active for some time.

Manually launching Software Update (in the GUI) or using the softwareudpate command, will simply sit without returning anything about available updates.

Remediation

To get past this, I have found the following helpful and the steps do not require a reboot:

Run the following via the Terminal (or remotely via ssh): sudo /bin/launchctl disable system/com.apple.softwareupdated

Then wait several seconds, and run: sudo /bin/launchctl enable system/com.apple.softwareupdated

Wait several more seconds. Note, the following should be (technically speaking) redundant and unnecessary, but think of it as one more “kick” to help get things working again:

sudo /bin/launchctl kickstart -k system/com.apple.softwareupdated

And - hopefully - you’ll find the problem resolved, as I have so far.

There are a number of options for managing updates for Dell servers, including direct access to an iDRAC card, which is configured with a specifed network configuration during initial setup of a/the server in question. Of course, please observe standard best-practices and never provide public accessibility to any such device, keep it behind your perimeter firewall where it (the iDRAC interface) can only be accessed via VPN. Once configured the iDRAC card is readily accessible at its assigned IP address, via a web-browser.

While there may be a tendency to “set it and forget it” with regards to something like this, there is an expectation to keep the iDRAC updated, and generally within a certain range (for reasons of compatibility if not official support) of associated system BIOS versions. If you are tasked with maintaining a Dell server that’s fallen behind in terms of updates, you can encounter an error when attempting to update an iDRAC when jumping up too many versions:

idrac RED007: Unable to verify Update Package signature

Remediation

This is most probably due to the existing iDRAC setup lacking required information about newer security (certificate) information for the much newer update installer.

A confirmed fix is to apply earlier updates to/for the iDRAC in a more step-wise manner: For example, if the card is listed at version 2.3x.(etc), apply the update to 2.40.40.40 then 2.5x, etc. up the latest update. It is often possible to skip one version, but as always, proceed with due care & caution.

Originally published by me, January 29, 2019