You are here

7 common security bug management mistakes and how to avoid them

public://pictures/ericka_c_0.jpg
Ericka Chickowski, Freelance writer

As the volume of software in the enterprise has exploded, so have the number of security holes in the code base. Last year, the number of vulnerabilities detected in commercial software totaled over 15,435 in 3,870 products, according to security vendor Secunia—and that doesn't include the security flaws in all the custom and legacy code running in production systems in the enterprise.

Unfortunately, many vulnerabilities remain open for weeks, months, or even years as organizations struggle with bug management. But it doesn't have to be this way. Here are the seven most common mistakes people make when managing security-related bugs and how you can avoid them.

[ Get up to speed fast on today's tools with TechBeacon's Application Security Buyer's Guide 2019 ]

1. Developing policies in a vacuum

All too often, organizations develop their vulnerability management programs in a vacuum, failing to account for unique business processes when setting vulnerability and assessment policies. This often happens because many of these programs are compliance-driven and don't grow organically from internal business processes, says Montez Fitzpatrick, director of information security and compliance at Keystone IT, an IT consultancy serving healthcare providers.

"The business processes have preceded the vulnerability management program, so it is the duty of the custodians of the program to weave it into the business processes, not weave the business processes around the program," he says.

2. Considering vulnerability management a fire drill

When most organizations perform bug management, they typically view it as a reactive exercise to deal with the latest headline vulnerability. Think of the Heartbleed and Shellshock bugs, for example. As it is with vulnerability management, any type of security is a process.

This way of thinking puts organizations on their heels, waiting to respond to the next big vulnerability headline, rather than proactively mitigating threats on an ongoing basis. "A non-continuous, reactive security policy isn't going to protect anyone from the threats that exist," says Joshua Cannell, malware intelligence analyst for Malwarebytes. "Vulnerability management cannot be something that's only performed annually; it's a constant endeavor that involves continuous security reviews of potentially vulnerable software, penetration testing, network filtering, and much, much more."

[ Application layer attacks are on the rise. Get key takeaways from the 2019 Application Security Risk Report in this free Sept. 25 webinar ]

3. Having too many dependencies on insecure applications and components

Some of the worst offenses in vulnerability management and poor patch hygiene are associated with custom applications that are tied to old, vulnerable versions of software and third-party components.

"Custom applications often cause delays in patching," says Casey Pence, cyber analyst with information security analytics tool vendor IKANOW. "These custom applications often depend on specific versions of software, for instance Java, which if upgraded will break the in-house application. This in turn results in many critical servers not being patched for long periods of time, due to the effort involved in updating the custom in-house applications and testing the patches on the servers."

Many times, organizations don't even have good visibility into these dependencies. To lay the foundation for the type of improvements necessary to fix this problem, enterprises first must find better ways to track and catalog these dependencies to make it easier for security teams to understand the scope of risk when vulnerabilities come to light.

4. Failure to prioritize by risk

The sheer number of vulnerabilities that need to be addressed in a typical enterprise can overwhelm even the most experienced IT shops. Even if an organization is committed to proactive bug management, it can still fail to address the worst vulnerabilities before they're exploited if it doesn't properly prioritize remediation based on risk. This means a formalized ranking system based on variables like the severity of the vulnerability, the software's importance, the sensitivity of data it holds, and the sensitivity of the systems running the software.

"While vulnerabilities are ranked in isolation by metrics like the standard CVSS [Common Vulnerability Scoring System] scoring, it's obvious that a low-CVSS score vulnerability in a DMZ is of greater concern than a higher-CVSS score vulnerability on a host isolated in an internal lab," says Stephen Hultquist, chief evangelist for security analytics tool vendor RedSeal, Inc. "Access over the network and from outside threat sources are primary metrics, invisible without automated network access analysis, that measure access to network-attackable vulnerabilities. They are critical for deciding which patches to prepare first and which hosts most need patching."

Prioritization should also take into account network connections and configurations, warns Pence.

"It's not always the critical assets such as database servers that require prioritization," he says. "Lower-level assets like workstations, combined with a poor security configuration, can result in massive breaches."

5. Over-reliance on WAFs and other blocking technology

It's a common misconception that blocking technology, such as web application firewalls (WAFs), can replace a solid bug management process, particularly in the area of in-house development. Not only does this approach contribute a ton of technical debt within your code base, but if you don't manage the technology well, it can introduce more vulnerabilities into your infrastructure.

"An incorrectly configured WAF or load balancer is easily the most exploitable piece of critical network equipment in an environment," says Marc Punzirudu, senior security consultant for ControlScan. "Often those devices provide SSL decryption so that the data can be analyzed, which leaves sensitive information in the clear if not managed effectively."

6. Poorly placed scanners

Many times the people in the trenches who are performing vulnerability assessments don't have a big-picture view of network topology, so they might not be aware of where internal firewalls, IDS/IPS sensors, and WAN connections sit. This can cause big problems.

"These teams try to perform scans from a central location and get erroneous results because other security tools and network bandwidth block an assessment. Even if they get whitelisting rules in place, NAT environments and connection limitations can also wreak havoc on a scan," explains Morey Haber, vice president of technology for BeyondTrust. "Properly architecting a vulnerability management solution is key to providing meaningful and accurate results."

7. Lack of resources

Finally, although there are a lot of tools out there to help automate the most arduous parts of vulnerability assessment, a vulnerability management program will need well-organized human brainpower to get anywhere.

"There needs to be a firm process for assessments, remediation, and verification," says Haber. Unfortunately, most organizations loosely govern these processes and don't properly assign ownership, he adds.

Having a good process doesn't mean dumping that ownership onto some overworked IT security professional's desk. Whoever is responsible actually needs to be given the time and resources to do the job.

"In nearly all cases, vulnerability management is not a job duty that can be just tacked on as an additional responsibility," says Fitzpatrick. "If their workload is near capacity, the security team will not be successful in implementing a successful vulnerability management program."

While these mistakes certainly aren't the only things getting in the way of enterprises effectively managing vulnerabilities, avoiding them will go a long way toward improving flaw management.

There are no easy fixes for these mistakes, but establishing a formalized, ongoing, and adequately funded vulnerability management program is a good first step. Beyond that, security, developers, QA professionals, and operations all need to recognize that the spirit of cooperation that has fueled the DevOps movement stands to benefit organizations greatly when it comes to fixing vulnerabilities.

[ Get Report: Gartner Magic Quadrant for Application Security Testing 2019 ]