In recent posts on this blog, I’ve talked about which bad guys are likely coming after your assets—that’s the who. We also discussed a few reasons why—an employee with a grudge, for example, or a jealous competitor, or a greedy stranger. Having assessed all that, the next item to consider is how the attacks might take place. We started talking about the how in my last post, but it’s time to roll up our sleeves and really get technical.
That’s right, this post is about vulnerabilities.
The Cybersecurity and Infrastructure Security Agency has a program called CVE, whose mission it is to seek out and expose cybersecurity vulnerabilities. (If you’re interested, you can find out more about the context of CVE’s work at their site.) CVE defines a vulnerability as: “A weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability.”
The ugly truth about vulnerabilities is that every system has them! Every single one.
And we’re not just talking about a couple of vulnerability issues here and there. Think thousands upon thousands, with more being discovered every day.
The good news is that the vulnerabilities you need to be concerned about are limited to your world and your world only. In other words, we only care only about your information system, system security procedures, internal controls, or implementations—not the universe of vulnerabilities out there. You have enough headaches as it is!
Of course, your world is a rather expansive term, one whose boundaries you’ll need to decide ahead of time. Think about the now-famous hacking of Target in late 2013—it was the largest hack of a retail company to date. Something you may not realize unless you were following the situation closely: it wasn’t the actual Target systems that were hacked! Instead, a Target vendor was compromised—a so-called trusted partner. Target didn’t control the vendor’s cybersecurity system, but boy did Target get the blame when that system failed. The question therefore is: what constitutes Target’s cybersecurity world? If you answered, “Their own systems plus all the vendor partner systems,” you get a cookie! You are correct! The same goes for your organization: Your world in cybersecurity terms is not limited to your own internal network.
The problem is, performing a vulnerability assessment on such an expansive definition of your world becomes unwieldy, not to mention legally tricky. For example: Do you, as a procuring organization, have the right to test the seller’s systems? It depends on (a) what you are buying and (b) how good your lawyers are. What if you are buying something-as-a-service? What kind of vulnerability testing can you reasonably demand? Again, those are very tricky conversations.
What most organizations have settled on, and my recommended approach, is for the buyer to do the following: first, request that the seller complies with a reasonable cybersecurity operational standard (e.g., “Have you implemented <insert your favorite standard here> in your organization?”) and second, demand the right to audit the vendor.
Whether or not you have the right to audit can be a matter of dispute. For example, what if the vendor serves multiple clients, some of which may be your competitors? If you have the right to audit, the other clients may object on the grounds of data confidentiality. You could descend into a legal rabbit hole defining exactly what system you’ll audit, how you’ll audit, and so on, but you get the picture.
Audit is a five-letter word that is best used sparingly and with profound respect. Fortunately, there are workarounds. For example, you may be able to request the results of an independent audit, as opposed to performing one yourself.
Next question: how do you decide which vulnerabilities apply to your world? You start by matching your systems to known vulnerabilities. You know your systems. Now, you need to find the list of applicable known vulnerabilities.
What about the unknown ones, you ask? Those are the dreaded “zero-day exploits!”
Obviously, you can’t test against an unknown vulnerability anymore that you can vaccinate against an unknown virus. But, just like in medicine, you can monitor your systems closely for any signs of abnormal behavior and respond accordingly. Most importantly? You are not alone in this! Thousands of dedicated cybersecurity professionals and cybersecurity companies make it their mission in life to scan for as-yet-unknown vulnerabilities, publish them, and recommend patches or mitigating controls.
Referencing back to our cybersecurity primer, you’ll remember that zero day refers to nasty little bugs that exploit vulnerabilities in existing systems that are known only to the hacker. In dealing with zero day exploits, your plan is simple: Stay alert, stay informed, and have in place a defense-in-depth strategy that protects your organization as much as is practical.
The word practical here is key. It is not about protecting your organization to the outer limit of what technology allows—that’s unlikely to be appropriate to your risk appetite. It is always about deploying protection in a pragmatic way.
The first step is to determine which type of vulnerabilities may apply. At a top level, you should be able to place your assets into the following buckets.
- Operating Systems
This is the software that controls your hardware. Operating systems can be manufacturer-specific, such as Apple’s and Microsoft’s, or they can be open-source based such as LINUX. Operating system choices can be extremely polarizing, and I advise you to avoid those conversations like the plague. All you need to know is which systems are deployed in your organization. Leave the question of which one is better to be debated by the corresponding high priests of each tech religion. If you are interested in the market share of operating systems, browsers, search engines, platforms, and so on, I recommend you visit the Global Stats site—a free website chock full of statistics happiness.
Servers are essentially applications that host (or enable) other applications. For example, database servers or web servers. You will need to know how many you have, what kind, the manufacturer, version, and so forth.
These run either directly off the operating system (like a word processor), or in combination of operating system and some server (like a website.) For example, your accounting system is running both on an operating system, using a database server, and is itself an application for which you need to know all the fun stuff we’ve been cataloging (manufacturer, version, etc.).
When will the fun stop? It stops with services! Those are any information technology services that your company consumes from a third party. It could be storage. It could be infrastructure. It could be anything-as-a-service (infrastructure-as-a-service, firewall-as-a-service, software-as-a-service, etc.). And, yes, you need to know about it in as much detail as possible. In the case of as-a-service you will need to consult the agreements you have with the vendors, as well as contact their cybersecurity personnel to determine what their baseline posture is. Assuming you’re dealing with a reputable vendor, they will be able to provide you with all the documentation you need.
Mapping and Remediation
Next, you’ll need to research and develop a current known vulnerability list for each of the four buckets. To do this, you will need to consult with the following amazing, free, and hard-to-imagine-anything-more-useful services:
According to their website:
The MITRE Corporation is a not-for-profit company that operates multiple federally funded research and development centers (FFRDCs). We provide innovative, practical solutions for some of our nation’s most critical challenges in defense and intelligence, aviation, civil systems, homeland security, the judiciary, health care, and cybersecurity.
I am here to testify that yes, they do, and I am one of their biggest fans! One of their many projects is the Common Vulnerabilities and Exposures Details. This is an amazing tool, where you can search by vulnerability, product, vendor, or anything else you can imagine and get meaningful, up-to-the-minute, actionable information. For example, searching for Microsoft SQL Server will return a table by year, number of vulnerabilities, type, and so forth, all of which link to more specific information. If you click on year 2015 “Code Execution” vulnerabilities, you will get two of them: CVE-2015-1763 and CVE-2015-1762. Clicking the second one, you’ll get all the details about a remote code execution vulnerability for the specific product and what to do to mitigate it. What’s not to love?
The National Vulnerability Database (NVD)
If you thought MITRE was hot, you haven’t seen NVD yet! Originally the brainchild of the National Institute of Standards and Technology’s (NIST) Computer Security Division, these days the NVD is brought to you by your friends at the Department of Homeland Security’s National Cybersecurity Division. According to them,
The National Vulnerability Database (NVD) is the U.S. government repository of standards-based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. The NVD includes security checklists, security-related software flaws, misconfigurations, product names, and impact metrics.
When you visit their website and click on the Vulnerability Search Engine link, you’ll have a very powerful research tool at your disposal. For example, entering the CVE-2015-1762 vulnerability from our previous example, you will get a detailed report including description, impact, and references to advisories, solutions, and tools, to say nothing about all the technical details you can eat. Personally? You had me at “References to Advisories, Solutions, and Tools.”
Last but not least, we have the Open Web Application Security Project. OWASP is an international open community “dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security.” Their claim to fame is the periodic publication of the OWASP Top Ten 10 most critical web application security risks.
It is not only an incredibly useful and actionable tool, but it has also significantly contributed to cybersecurity awareness among developers and computer professionals as a whole. You will find this and many other tools and guidance at their website.
Is that it? Are these three sources all there is? Not even close. There are many more sources and resources out there for vulnerability research. Many are free; some are subscription-based. The three listed above here are simply a good start: They are all free, and they will suffice for most organizations’ vulnerability identification needs. The trick to all this is vigilance. Like all things in cybersecurity, you do the task once and re-check on at regular intervals. How regular? It depends on your systems and assets: No two companies are the same.
Having identified and mapped the known vulnerabilities to your systems, the next step is remediation. Known vulnerabilities have, thankfully, known remediation steps. If you can, follow them to the letter!
Wait, why did I say, “If you can”? Crazy as it may sound, not every known vulnerability can be plugged. In fact, not every one should be!
I’ll leave you with that cliffhanger for now. In my next post, we’ll talk about the necessity of—but also the limits of—vulnerability remediation.
One more thing: if the prospect of all this research makes your stomach churn, consider giving us a call at TMG. With our fully customizable cyberCTRL subscription, you don’t have to manage your vulnerabilities alone.