Managing Vulnerability In The Age Of Cyber Everything

Is your organization performing penetration tests and/or vulnerability assessments? For those of you that may not fully grasp the difference, here is a simple way to look at it: A vulnerability scan enumerates potential risks associated with any given system.  Examples include missing patches, default credentials, and clear text protocols, such as telnet. A penetration test not only enumerates risk, as in a vulnerability scan, but it takes it one step further by proving a particular exploit is real. A pen tester very often will log onto a system with default credentials, and when the vulnerability is discovered, will take screenshots to prove the damage a malicious actor could cause.

Organizations often struggle with both type of exercises. Penetration testing is an art, as much as it is a science. Therefore, performing penetration tests requires a particular skill set that is at times difficult to find without contracting an external security partner.  By contrast, a vulnerability scan is something that most security professionals are able to handle, as most scanners are quite simple to use. The challenge, though, lies in the findings that result.

Are you seeing images of an avalanche?

Not knowing what problems exist is an issue in any profession, and especially so in IT security, but it’s also highly problematic to have volumes of vulnerability data that are not being addressed. No matter how jovial the relationship is between IT security and infrastructure, the strain of the remediation efforts can quickly erode any great partnership.

Penetration tests and vulnerability assessments are a key to understanding the security posture of the organization, at any given point in time. So how does a security team leverage this capability in such a way that doesn’t overwhelm the division?

• Prioritize: Don’t scan the entire environment at the same time and hand over a list of thousands of vulnerabilities to the network and infrastructure teams. Scan what matters most first. Leverage data from your business impact analysis (BIA) to scan the most critical hosts first. If a BIA has not been conducted, start with obvious critical assets such as domain controllers, firewalls, DNS, DHCP, Exchange, critical line of business servers, etc. Ultimately, scanning your IoT devices is the best way to understand the scope of the actual risk associated with those devices.
• Gradual Remediation: While critical vulnerabilities must be remediated as soon as possible, the reality is that when systems are in production, extra time may be required to deal with a high volume of findings. In addition, handing thousands of vulnerability findings to any team will overwhelm them and potentially prevent any progress from being made. Therefore, a reasonable strategy is to tackle critical and high vulnerabilities during the first pass/scan. During the second round, the amount of any critical or high vulnerabilities should be low enough to allow the team to focus on medium vulnerabilities. From then on, all vulnerabilities should be reviewed and addressed accordingly.
• Low hanging fruit: Vulnerability remediation can be quite time consuming and arduous. One effective way to minimize the time and effort is to scan and validate machine templates for servers and endpoint, at least quarterly, with an end goal to validate monthly. By ensuring your templates are hardened and vulnerability-free (according to the most recent scan), the team will be dealing with issues one time instead of replicating issues throughout the environment. As you would expect, these issues will then require individual resolution.
• Exceptions or Unresolved items: Every item that is discovered requires either remediation or documented explanation. Without this, the item will appear to have been ignored. The healthcare sector is plagued with third party applications that require very specific operating systems, patch levels and configurations. It’s very common to find a vendor that will proclaim, “If you patch the server(s) and something breaks, we won’t support that instance.”

Are we stuck? I say no.

What needs to be done in these cases — but rarely happens — is to ask the vendor for an explanation (on company letterhead) as to why you may not take the steps necessary to remediate the issue. A very common occurrence is the application vendor not certifying a particular operating system patch. Ensure you’re covered by obtaining the needed documentation from the vendor. If audited or a problem happens in the future, it’s imperative you have this information.

Penetration testing and vulnerability scanning is a necessary yet strenuous task that can be made more manageable and ultimately reap huge rewards, solidifying your security posture, by following the simple yet impactful suggestions above.