By: Slade Griffin, Director of Security Assessments
Contextual Security Solutions | September 22, 2017 @ 11:03
I’ve been watching some of the excuses flying for recent breaches coming from different people while at the same time, accusations of ineptitude come from others. Let’s take a minute and talk about what should be a foundational aspect of your information security program. Patch management, configuration management, or change and configuration management is the process of trying to keep your systems up to date with software fixes and altering their configurations as needed to protect your data and keep them running.
You’ll need a few things to get started but none of this is overly difficult although it is a bit of work but that’s what they pay us for. First, you’ll need to have a system inventory. To create this, I’d suggest running nmap and/or Nessus against your entire organization, exporting the results into a spreadsheet and keep track of IP address, DNS name, OS platform, mission critical packages installed (Apache, SQL), and any other information relevant to its function at a minimum. I threw together a quick example below.
Notice the system owner is an individual and not a department. As always do whatever best serves your organization however knowing it’s Bob vs. 9 people in your web development group, or 25 in your helpdesk group, can provide additional accountability and clarification during an incident. Once you have an inventory, look at some industry-accepted hardening guides that are free for the taking over at the Center for Internet Security (https://www.cisecurity.org/cis-benchmarks/). Chances are no matter what you’re running, this group has some guidance on how to disable unnecessary services or insecure services that you might not know were running. Implementing these can take some time and you don’t want to overwhelm Bob, so plan implementation, test it, then schedule it.
At the same time, develop a way to identify vulnerabilities on your systems. I am most comfortable with the vulnerability scanner Nessus by Tenable. Their security center product may be better suited for bigger organizations but I like the scanner. For effective vulnerability management, you’ll need to regularly check your systems using the most updated plugins. For our customers who have us perform regular scans we provide something like the following images. The first shot display basic metrics with how many hosts were targeted, how many returned results (live hosts), the number of vulnerabilities categorized by severity, then the highest CVSS score noted. We use CVSS because it is recognized as a standard. Anyone using any severity rating system should always keep in mind that just because it doesn’t say HIGH doesn’t mean that vulnerability isn’t critical for you.
The second graphic shows the top 5 vulnerabilities by CVSS rating, full detail of all vulnerabilities is provided in another document. I’ll pause here to point out that if you were using a domain administrator credential across the unencrypted Telnet server; this would be a high-severity vulnerability. No scanner will detect nuances like this and this is where I hope you have invested in your people and that you are listening to them.
The final graphic will show your trends over time. This can help provide some visibility into whether or not you are improving, remaining static, or getting worse.
Now that you have decided to regularly check your environment for vulnerabilities, what do you plan to do about them. My suggestion would be to mitigate and/or remediate them. Sometimes this involves changing a configuration, like when we had to replace all SSL with TLS, and sometimes it involves installing a software fix/security/upgrade. Before we chase that, let’s talk about criticality and severity ratings again. The Nessus scanner has its idea, CVSS has theirs, and here below is one from Microsoft that I like to use when developing a policy like this. Pick what works best for you.
The last thing you’ll need in your policy is when to apply patches. You can develop a matrix that says when patches will be applied based on their severity rating. This same scheduling matrix should also include which systems require additional testing, which systems require vendor interaction, and which systems cannot be patched. Here’s another quick sample I put together. I added some flexibility for any severity rating below critical and used different ratings from the MS example above however it is all interchangeable if your verbiage is consistent throughout your organization.
So, what’s the point here? Something as simple as we’ve outlined above could give someone like Equifax visibility into their current vulnerabilities and a plan to deal with them as they are discovered. This is work but it isn’t splitting the atom. The entire process requires more detail but can be accomplished by most organizations quickly. If you have any questions or need assistance with this, please let us know.