Microsoft.
When you hear this word, what goes through your mind? Is it joy? Perhaps frustration? Maybe it’s robust features like Azure. What about Azure Virtual Desktop (AVD); the very thing Totem’s ZCaaS secure enclave is built on? Of all the options the latest game of computer word association has generated, we would be surprised to hear “Vulnerability Management” in any of your responses. For those of us in the Defense Industrial Base (DIB) that handle Federal Contract Information (FCI) or Controlled Unclassified Information (CUI), and are pursuing a Cybersecurity Maturity Model Certification (CMMC), we have become (or will eventually become) all too familiar with vulnerability management. As we forge ahead in our implementation of NIST 800-171 and prepare to undergo a CMMC assessment, it is crucial that we understand both the expectations for vulnerability management under National Institute of Standards and Technology (NIST) 800-171, as well as the tools available to us for doing so. This post will attempt to dissect these requirements while looking at tools DIB members are using today for vulnerability management, including those offered by Microsoft.
There are many types of vulnerabilities in the cyber world. But what the heck is a vulnerability? today were going to look closely at software vulnerabilities. Particularly those in the applications we leverage on our daily-use computers.
What is a vulnerability?
A vulnerability is defined rather efficiently by NIST as:
A security flaw, glitch, or weakness found in software code that could be exploited by an attacker or threat source.
In short, if a piece of software has a vulnerability in it, that means a potential adversary can find that vulnerability and, depending on the severity of the vulnerability, take control of the compromised computer without any knowledge of the end user. A vulnerability can take many forms. A small typo in a piece of software can result in the software not operating as expected, and adversaries can take advantage of this, what we call “exploiting”. While most developers do an excellent job of testing and vetting programs, developers and programmers are human, so mistakes are made, or things are missed. Major organizations and development firms can be subject to vulnerabilities. Groups such as Google, Microsoft, Apple and Adobe send out frequent “patches” to their programs to help not only improve performance of their applications and add new features, but also to fix vulnerabilities that may be present in the software. Applying these patches is a crucial part of vulnerability management.
How can organizations prioritize vulnerability management?
Vulnerabilities aren’t only discovered by the developers; they can be found by other organizations, too. An entire industry has burgeoned around finding vulnerabilities in software and alerting the developers of those vulnerabilities. These groups do great work to help us, the end users, with vulnerability management and keep our data secure from the adversaries who would seek to exploit or exfiltrate it. Even home users or hobbyist coders can participate in what’s called a “bug bounty” program. These programs offer rewards to individuals or companies who find these vulnerabilities and report them in. For instance, Microsoft has their own bug bounty program.
When a vulnerability is discovered, a series of events take place not only internal to the organization who develops the software, but for the community of IT Professionals at large. These vulnerabilities, once announced, patched, or discovered in the wild (whichever comes first), inevitably will end in one or more databases that catalog vulnerabilities. These databases contain inforamation about the software vendor, product, a description of the vulnerability and, if available in some cases, instructions on how to “remediate”, or fix the vulnerability. NIST and a group called MITRE manage two of the larger databases of these vulnerabilities. The databases indicate each vulnerability’s severity as well as its exploitability, and its impact to an affected organization. These factors are combined to generate an overall Common Vulnerability Scoring System (CVSS) Score. In short, the higher the score the more severe the vulnerability.
The Cybersecurity & Infrastructure Security Agency (CISA) developed a very useful calculator to help cybersecurity professionals prioritize the response to vulnerabilities that are discovered by their organization. Factors such as if the vulnerability is being actively exploited and if that exploitation can be automated factor into prioritization of actions the organization will take as part of vulnerability management. Vulnerabilities that are not being exploited and cannot be automated (in this case meaning that users are not required to execute the bit of malicious activity or code) are set as much lower in the prioritization than those which are being actively exploited and require no user input to be leveraged. The chart below shows all the possible outcomes of the calculator, which CISA calls the Stakeholder-Specific Vulnerability Categorization (SSVC) calculator. Depending on the set of vulnerability attributes, the organization can respond by Tracking, Attending, or Acting.
The SVCC calculator takes a more subjective approach compared to the CVSS score. The assessment facilitated by the calculator factors in whether the exploit has any Technical Impact on the organization. Essentially, a vulnerability that checks the box on the first two criteria of Exploitation and Automation but that wouldn’t allow the attacker to take complete control of the system will have very low to no priority. And conversely, if the exploit would result in total control, remediating the vulnerability would be more of a priority. It’s always wise to keep a weathered eye on the horizon of vulnerabilities to ensure that your organization is being watchful of current tactics used by adversaries. A vulnerability in one software may be identical in another but has not yet been discovered.
After Technical Impact the calculator directs us to factor in Mission & Well Being. This speaks to how catastrophic (or not) this vulnerability would be. A piece of software used by one individual in an organization of 300 may have a much lower impact that one used by the other 299. All of these elements combine to recommend one of three vulnerability management responses: Track, Attend, or Act. Track simply means to keep an eye on the vulnerability and patch when reasonably possible. Attend is meant to bring attention to the situation as it may be somewhat new, unpatched, or an exploit is not yet found in the wild. Lastly, Act speaks for itself. It’s time for the organization to act, and quickly, to mitigate or remove the vulnerability as soon as possible.
Why should we care about vulnerability management?
Ok, so we have a good grasp on what a vulnerability is, and we have exposure to some tools for remediation prioritization. What is a small business DIB member actually to do? Well, because NIST has insight on how a vulnerability can impact CUI, the 800-171 standard has requirements, or “controls”, mandating vulnerability management. When it comes time for a CMMC assessment, the assessors will be looking at how our organization addresses these controls. So we are obliged by contract to adequately address vulnerabilities.
Here are the controls in the 800-171 standard that require vulnerability management:
Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.
Remediate vulnerabilities in accordance with risk assessments.
Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.
Identify, report, and correct information system flaws in a timely manner.
While NIST and the DoD provide some limited guidance on “how” to meet these controls, vulnerability management is still a heady task for many small businesses. (Especially in the CMMC regime which requires us to document how we do it.) The idea behind how to implement these controls is a sort of “seek-and-destroy”. Seek out (“scan for”) the vulnerabilities on a regular basis (monthly at least) and, if a patch or remediation is available, apply it. In this manner, we can Manage our Vulnerabilities. We discuss vulnerability management extensively in our quarterly CMMC Workshops. Additionally, our Totem™ Cybersecurity Compliance Management software has additional guidance on the hows and wheres of the NIST and CMMC controls related to vulnerability management. But in the rest of this post, we’ll describe some specific tools, techniques, and procedures that we use at Totem.
How can small businesses manage vulnerabilities?
A business of any size will have to put some technology in place to help with vulnerability management. The good news is there are multiple great platforms that can help. Enterprise platforms like Microsoft Intune can apply software, allow for centralized vulnerability tracking, execute automated reconfiguration and patching of endpoints, and report back on its results. Other more tactical (focused) tools like Tenable’s Nessus can facilitate automated vulnerability Assessments. This means that, a bit like a mall cop, they can find the issue, but not really do too much about it rather than let you know. These vulnerability scanning tools satisfy NIST 800-171 3.11.2, but leave out the crucial Remediate component of 3.11.3. Thus, when Nessus finds a vulnerability, its up to the administrator to apply a fix or push a patch via Intune. This 1-2 punch would most certainly satisfy the needs of these two controls for NIST 800-171 and CMMC so we’re off to the next control.
Tools like Nessus do a great job at finding these vulnerabilities, but like so many technologies, the configuration can be difficult to setup, administer, and maintain, especially for a small business with limited resources. What other solutions might there be to help close the gap? Totem has tested out quite a few of these combinations over the years, from small custom scanning solutions to some of the more powerful tools like Nessus. All these technologies have their pros and cons, but most lacked several key features that left us wondering what could be better. So here’s the approach that we’ve settled upon.
How Totem manages vulnerabilities
When we at Totem review a product and its capabilities, we often find ourselves thinking about small business implications first, and compliance second. This means that price is often top of mind in these scenarios. We weigh a technology’s effectiveness against its administrative upkeep, against its price, and against its ability to satisfy the control we’re working on. The results of these reviews allow us to deliver some great suggestions to our clients and avoid a cookie-cutter one-size-fits-all approach.
Our IT Director is an aquarium hobbyist. When we talk about stuff like IT maintenance and keeping IT platforms going, or any other topics in the cyber-realm, he repeats this line from his own experience in keeping aquariums: “Maintenance is maintenance; the easier it is to do, the more likely you are to do it.” We take that same approach with CMMC compliance and, as is the topic of this post, reviewing vulnerability management solutions. When we recently helped a client migrate to an all-cloud solution with Microsoft 365, we were faced with a curious discovery: Microsoft has their own Vulnerability Management?
Totem likes simplicity in all things (as best it can be achieved), and the concept of having a “single pane of glass” to show the security posture of this particular client was most intriguing. This client was already going to utilize Intune heavily, so a solution that encompassed the Microsoft ecosystem had us diving head first.
The solution was rather elegant. Intune already puts its agents on to the machine, and Microsoft makes integrating Intune with Microsoft 365 Defender very seamless. With just a few clicks…
…and a pre-configured policy from Microsoft…
…we were off to the races. Over the next 24 hours, Intune automatically enrolled all the Azure Active Directory devices into Defender, and we began to get great data on the security posture of the client’s endpoints:
Next we explored the vulnerability management suite of tools. Microsoft has many ways to accomplish this. It is available as a standalone service which can be added to any licensing bundle, or it can be included in an E5 suite. In this case, our client has G5 licensing, so under the endpoints tab popped the vulnerability management window:
Over the next 24 hours we discovered a multitude of applications that was otherwise overlooked from previous scanning solutions that had been tried in the environment. Programs long forgotten, Original Equipment Manufacturer (OEM) apps that no longer worked, and other software that seemed to magically appear. (By the way, understanding what software applications are in your environment is the crucial fist step to many other controls, especially vulnerability management. We have a whole blog on how to identify assets here: Know Your Assets.)
We learned that once per day Microsoft Defender does a complete software query of every application bundle suite (like .Net Frameworks). The results of these queries are placed into a software inventory list, and Defender checks the software versions against the CVSS databases we mentioned above. The result is a complete list of software that needs to be patched, organized by how many instances of a given vulnerabilty are present in the system, and on which devices:
In a few days we began to “squish bugs” and apply patches like the client had never seen before. Using the power of Intune to apply its own patches to Windows, Chrome, Office, and Adobe, we had the entire fleet running on current versions of the most critical software in a few weeks. Programs that fell outside of the scope of automation were placed into a list for manual patching; that list was very short indeed. And during months where we may be overwhelmed by the number of vulnerabilities that require manual patching, we rely on the SSVC calculator to assist us in prioritizing remediation.
As we explored the powers of the vulnerability manager, we came across the onboarding capabilities. In its engineering, Microsoft saw fit to make this solution cross-platform ready. AWS, Azure, Linux, Windows, and Mac are all available to be onboarded into the portal.
What’s that, you say? “What about non-Azure-joined devices?” The client we were working with had a server that couldn’t be shut down, and couldn’t be enrolled into Azure Active Directory management. The device was behind on patches, but otherwise well-managed by IT with manual application of security controls. Further, the device in question wasn’t even on a domain, it was a stand-alone appliance with its own independent suite of local logins. As to how to peform vulnerability management on this device, we were perplexed to say the least. Lo and behold: Microsoft Defender has the ability to onboard devices via a script! Defender documentation didn’t seem to indicate any issue so off we went in all fervor to test the hypothesis. The setup was simple enough, simply download the provided script to a USB device and follow the prompts. It required the manual application by an administrator, but seeing as this was a one-off situation it didn’t pose an issue. In around 10 minutes the server showed up in the Defender console, and the next day we had a slew of information about the server’s configuration, and more importantly for this post: we now had insight into the server’s vulnerabilities.
What would have taken hours for a single technician to compile and review manually or even to manually configure a solution like Nessus with independent credentials and scanners, all this was done in a matter of minutes with a single script. We do want to highlight that this server was not on Intune, so it wasn’t centrally-managed automatic patching was not available to the client. But the client elected to download the data inventory or to open the console at least monthly and check the current vulnerabilities on that server. It was a very elegant solution to a challenging problem.
It is important to note that in this scenario, the client’s server could connect to the Internet. We acknowledge this may not always be the case. Our suggestion in the case of a server with no normal Internet connection, is to connect it to the Internet at least one day a month, while closely monitoring activity on that server. Microsoft does provide robust documentation on what ports and services their solutions communicate over, so a few entries into a firewall to limit the outbound traffic, and the server can communicate regularly with Defender.
Bringing things to a close
Vulnerability Management doesn’t have to be a large-scale fiasco. We feel it’s an excellent way to help defend against an adversary, so much so that it is included in our Totem Top Ten™. NIST happens to think so too, and four of the NIST 800-171 controls are associated with managing vulnerabilities.
The objective here is to ensure that we’re looking at and patching all our software on a regular basis. For many organizations this can be done monthly. For some it’s easier to do it quarterly. It really depends on the needs of the organization. Join us at our next CMMC Workshop and if you’re working on this control, or any other controls, contact us and we would be happy to assist you in navigating these tumultuous waters. We’ve been there!
Go Fight Win!
-Ryan
