Author: Sean Slattery

Vendors are stepping up their game!

Up until now we have been focused on our own metrics, but what about vendor supplied or created ones? Some tools such as Trellix ePO (shown above) natively provide useful metrics covering the overall security posture, even providing recommendations on how to improve these. In other words, leverage vendor supplied metrics whenever possible.

Since we are dealing with endpoint protection, they will come a time where something suspicious or malicious sis detected. Understanding the detection type e.g. infostealer, ransomware, remote access trojan, and location e.g. laptop, server, department, or business unit provide valuable insights into what is happening in your organization. In fact, let's take it step further and also correlate threat detections with user and application e.g. browser, MS Office, Windows Explorer.

We once worked with a customer that had a staff member that was trying to download pirated movies. We tracked his behavior starting with his office desktop, then his office laptop, and eventually vis his remote access to the Citrix Presentation Server (aka Remote Desktop Services) farm. Simply accepting the threat detection events without understanding the context and being able to address the issue with the user, would have opened the company up to significant cyber and business risk and liability.

In our previous post about endpoint security, we discussed Operational Compliance, high-level metrics regarding coverage and timely communications. Now we're going to dive into the technical details of protection. Do note that depending upon the particulars of your endpoint protection, product-specific capabilities and functions will vary.

First let's consider your tools' configuration, settings, or tasks - collectively we'll just call policies. Ideally your management console can indicate that their policies are up to date and even a policy version. If your console does not have this ability, hopefully the local app's console can indicate this. Without some method to confirm that your apps are doing what they are being told, you have nothing more than assumption of what is in place.

• % of endpoints with up to date policies*

* Overall health is important but able to drill down into the details of any out of compliance systems so that they can be remediated.

If your chosen tool uses content updates e.g. signatures, .DAT files, engines, you will want to ensure that your endpoints are kept up to date. With most vendors releasing content on a daily basis, a good rule of thumb is ensuring that your systems are never more than four versions out of date. This threshold allows for reporting delays i.e. if a system is out of the office but online and also if systems are offline. For scanning engines or other content which are not updated as frequently, sticking with no less than a one version difference is good.

• % of endpoints with content within n-4 versions
• % of endpoints with engines within n-1 versions

These three aforementioned metrics are good, point-in-time snapshots. To really understand your environment, we recommend tracking these over time i.e. collect trends. Ideally your management consoles can be customized to display all of these in one screen, providing you with an at-a-glance view of the health of your organization.

• 30-day/90-day Trend % of endpoints with up to date policies
• 30-day/90-day Trend % of endpoints with content within n-4 versions
• 30-day/90-day Trend % of endpoints with engines within n-1 versions

Tracking trends is an effective way to spot operational anomalies in your environment and remediate them before they become institutional issues. For example, we worked with an organization that outsourced their Internet firewall management. When the supplier "cleaned up" some rules, they inadvertently disconnected their endpoints from the local management console, which also prevented propagation of the policies. Had the endpoint security team not been tracking these metrics, they would have only known about the changes upon encountering an operational issue, or worse a cyber incident.

Let's now tackle another pillar of cybersecurity, endpoint security.

We'll leave the debate of antivirus (AV), antimalware (AM), endpoint protection (EP), next gen antivirus (NGAV), or next gen endpoint protection (NGEP), or another day when we can play acronym bingo. We're going to lump all of these apps that serve, through signatures, behavioral rules, machine learning (ML), or even artificial intelligence (AI), to protection endpoints from malicious apps and activity into one basket.

Regardless of your organization's size, the first order of business is what I like to call Operational Compliance. Basically we are ensuring that all of your endpoints are protected by the correct apps, and reporting to central management in a timely manner.

In terms of coverage, you should strive for nothing less than 100% coverage, 95% or higher is a good pass in my books. Of course 95% of coverage in a 100-device organization can be easily remediated, but in a 1,000 device organization, 50 non-compliant systems starts to be more daunting to handle. As the saying goes, your mileage may vary - all depending upon your organizations risk appetite.

We've already established that knowing the number of assets in your organization is key, We're just building on the principle. That said, there are times where a system may need your AV/EP temporarily removed or disabled for troubleshooting purposes. Application vendors do tend to blame security for most issues don't they? So we should allow for those exceptions. Exceptions, though, should not linger and become the norm.

• % Endpoint Coverage (deployed / (total systems - exceptions))
• # of Exceptions or better yet # of Exceptions older than two weeks

Now let's consider the versions. Just like any application, your AV/EP will require periodic updating, patching, or upgrading. And just like any other application, you should be running recent (the latest n, or n-1) versions excluding any compatibility issues. A pie cart is a good way to visually and quickly understand the state of your environment. If your AV/EP tools utilise several modules, you'll need to duplicate these efforts for each of these, as well if your systems require a separate management agent. For larger organizations, segmenting this data by business unit or asset type can be helpful in order to direct resources to investigation.

• # Deployed versions of AV/EP
• # Deployed version of AV/EP by business unit or asset type (servers, workstations, laptops)

Last is where the proverbial rubber meets the road. It does us no good to deploy software if we can't ensure that it is operating normally, have the latest policies and settings, or have reported back to the management console. Generally speaking I like to ensure that all endpoints have checked in at least once a week. Exceptions such as being out of the office can be easily managed simply by bringing these systems online. You would anyways be doing this as part of your patch management process right?

• % of assets with successful communication within n-days

Your AV/EP architecture and management console will largely dictate how easy all of this information is gathered or reported. While automatic/scheduled export/delivery is ideal, at the very least be able to easily extract the information if manual efforts are required. As the expression goes, your mileage may vary.

Let's bring this topic home and cover what we want to do about them, because we are going to do something right? We patch, remediate, and mitigate in order to reduce the exploitability of the asset in question.

Ideally your business and or asset owner should be indicating how long they are willing tolerate being exposed. Turning cybersecurity into a business decision is a bigger discussion for another day so let's seed this discussion with a 30-day window. Why 30-days? Simply because we are all very used the cadence of Patch Tuesday - Microsoft, Adobe, Oracle and few others' regularly scheduled release of updates. If we can patch our systems within 30-days, we don't have to deal with complications of overlapping updates. Don't forget that there are many vendors that may have their own update cadence and that many vendors may release out-of-band updates to address more critical issues.

The typical small to mid-sized enterprise (SME) that operates 9x5 should be able to adhere to the 30-day target. For all others, you may have to have different targets depending up the type of asset. For example, you may choose to allow non-critical assets to be patched within 45-days. See previous posts regarding asset categories.

For now let's stick with 30-days for all assets.

• Average # of days to patch Critical assets
• Average # of days to patch non-Critical assets
• % of Critical assets patched within 30-days
• % of non-Critical assets patched within 30-days
• # of assets with exceptions
• # of assets with exceptions over 90-days

Yes, that is a strong password, but the sticky note needs to be hidden under the computer!

In our previous post, we determined that we need to organize our assets based upon their context. With that in mind, let's consider what vulnerabilities matter to us.

The oblivious place to start is the Common Vulnerability Scoring System (CVSS). Taking into account factors such as attack vector, complexity, privileges and user interaction, CVSS provides standardized way to assess the severity of security weaknesses. Sounds great right? Before you answer, consider the real-world context. Does a Critical vulnerability on a trivial asset, let's say an intern's laptop, matter as much as a Medium vulnerability on your mission-critical communications server? Ceteris paribus, eventually yes that laptop is concerning, but probably not in the immediate future.

Obsolete, end-of-life, of end-of-support, software is its own class of vulnerabilities. In most cases, the vendors no longer offer support or updates for these, so your only recourse is to upgrade, seek an alterative, or uninstall.

Another significant class of vulnerabilities are those that are known to be exploited. These are worth tracking anywhere in your organization. The U.S. Cybersecurity Infrastructure Security Agency (CISA) is one of several organizations that maintains a list of Known Exploited Vulnerabilities (KEV).

The last class of vulnerabilities to consider at this time are those with no remediation. Note that I did not specify patch. Remember that some vulnerabilities are simply misconfigurations such as a default password left in operation. The lack of remedy could simply be because a fix has not yet been developed. Or worse, a remediation might be incompatible with the system or might create other problems such as creating performance issues. In either case we're dealing with vulnerabilities with no solution in sight.

In summary, so far we're working with:

• Severity
• End-of-life/end-of-support software
• Known exploited
• Vulnerabilities with no remediation or mitigation

Let's now include some context and we have the following to get started:

• Known Exploited Vulnerabilities for any asset or group
• High-severity for Critical systems
• Rated vulnerabilities for all non-Critical systems
• Any severity above Informational (rated) for Internet-facing systems
• End-of-life/end-of-support software by business unit

Next week, we bring this topic home when we also consider remediation/mitigation efforts.

There are two critical vulnerabilities in the image, can you spot them?

Stated simply, vulnerabilities are weaknesses that attackers can exploit to gain unauthorized access or cause harm. Mitigating a vulnerability usually entails patching, updating, reconfiguring, or applying a compensating control. Sometimes though mitigation may not be possible due to a lack of a patch or because the patch might be incompatible with other parts of the system.

But before we can discuss measuring vulnerabilities, we need to really understand where we are measuring them. Is uniformly measuring all assets (devices, systems, operating systems, applications, etc) appropriate? If our organization only consisted of five laptops, all running the same software for users to perform the same work, maybe. But for any reasonably sized organization, a server has greater business value than a single user's desktop. The CEO's laptop is going to have greater business value (operationally) than a receptionist's desktop. And for a final example, a public-facing system will be of greater value than a test system. In other words we must establish levels of criticality or importance to business functions.

Here are some examples of asset categories that will help to define our vulnerability metrics, keeping in mind that an asset might belong to several categories simultaneously.

• Critical vs non-critical
• Tier 1 (production) vs Tier-2 (supporting) vs Tier-3 (test/development)
• Internet-facing
• Contains sensitive data e.g. customer or financial
• VIP users : CEO, CFO, HR managers i.e. high value targets
• Business unit

Thinking ahead, once you apply your policies and processes to the asset groups, your work is simplified to managing these groups as assets or commissioned or decommissioned.

In reference to this post's image, the first vulnerability should be obvious, the zip tie. The second is the Master lock. While wildly popular and mainstream, they are some of the easiest to defeat.

Administrative or privileged accounts are the holy grail for threat actors because they are the proverbial and literal keys to the kingdom.

Since Windows Active Directory is the most popular network operating system, we'll focus our efforts on domain environments.

For IT administrators of a certain age, there are certain hard-to-break habits that persist. These include granting end users local administrator rights, making certain users e.g. managers Domain Admins, and the most egregious in my opinion, making their own user accounts a Domain Admins.

This can be quite an expansive topic so we're going to focus on certain fundamentals to get the proverbial party started:

• Set aside the default Domain Administrator account with a strong password kept under lock and key
• Minimize privileged account sprawl
• Enforce separate user and admin accounts for IT staff
• Require multifactor authentication (MFA) for all privileged accounts
• Monitor for and alert on undesirable privileged account activity
• Monitor for and alert on privileged user group changes

Minimize the following key metrics for best results:

• # of accounts with administrative permissions
• # of privileged accounts without MFA enabled
• # of privileged accounts with passwords older than 1-year (your mileage may vary)
• # of inactive privileged accounts i.e. with no logon in last 30-days
• Frequency that the default Administrator account has been used
• Frequency that privileged user groups have been changed
• Frequency of privileged account failed logins, lockouts, unlocks, and password resets

We could go on and on with regards to auditing. Seriously we could go on and on, and will do so at a later time. For now, this should get you started on the straight and narrow.

_{Image Source: Adobe Firefly Generative AI}

Now that we can measure what's connected to our organization, let's see what's running (installed). As with the previous posts, we're going to initially focus on our local systems.

Consider what is running in your environment. The obvious things are productivity applications such as MS Office, collaboration software, and web browsers. Speaking of web browsers, what about plug-ins and extensions? Also consider any hardware enabling drivers, their supporting apps, and of course all of your security software. You're probably thinking that this list is getting big.

But wait, there's more! The two most important bits of software have yet to be mentioned: the computers' operating systems (OS) and firmware (BIOS). The OS probably just slipped your mind but you probably didn't consider the BIOS. Without a working BIOS, your computer is just a mess of metal and electronic circuits. It is the firmware which turns that pile of stuff into a computer, and enables the OS to load and run. And yes, you really need to manage the firmware along with everything else. Don't worry though, there is an app for that!

Let's recap the various bits of software that we should be measuring:

• BIOS/firmware
• Operating Systems
• Drivers and hardware enablers
• Applications
• Application add-ons e.g. Browser Helper Objects

The more versions and variations of these, the greater the risk from misconfigurations, vulnerabilities and exploitation, and the greater the effort and time required to manage. Therefore we want to have a few of these as possible in order for the business to function i.e. establish a common operating environment (COE).

A common operating environment's benefits include but are not limited to:

• Increased efficiency and productivity
• Reduced costs
• Improved collaboration and communication
• Enhanced security and compliance

In terms of metrics, here are some to get you started. For simplicity with this list, we'll refer to all items in the previous list as apps. Minimize these for best results and there are bonus points for having these broken down by business unit.

• # of different app versions
• # of end-of-life/end-of-support apps
• # of unauthorized / non-COE apps
• # of authorized / COE apps not used in the last n-months
• # system deviations from COE standard
• # of systems with COE exceptions or extensions

_{Image Source: Adobe Firefly Generative AI}