A high percentage of discovered bugs remain unremediated for a long time, a new study shows.
Chances are high that almost every single application an organisation uses has at least one security vulnerability in it.
Contrast Security recently analysed telemetry gathered between June 2019 and May 2020 from applications in development, testing, and operations at customer locations. The exercise found 96% of applications contained at least one security bug — more than one-quarter of them serious. Eleven percent of the applications analysed had six or more serious vulnerabilities.
As usual, cross-site scripting errors, broken access control, and SQL injection errors topped the list of serious vulnerabilities that Contrast’s researchers encountered. More than seven in 10 (72%) had insecure configuration vulnerabilities and 64% were vulnerable to sensitive data exposure.
Contrast’s research shows attackers are relentlessly probing for these vulnerabilities to try and break into applications. The company counted over 13,000 attacks per month on average against individual applications — 98% of which were just probes that did not hit an existing vulnerability. Contrast counted a sharp increase — 179% over the previous year — in attacks targeting command injection vulnerabilities in particular. Though such flaws are rare, they are easy to scan for and allow attackers to take complete control of a web application server, says Jeff Williams, co-founder and CTO at Contrast Security.
“Enterprises need to recognise that their applications are both vulnerable and [under] attack,” Williams says. “The data shows that attackers are persistent and use smart strategy by targeting the most prevalent vulnerabilities, with a special focus on vulnerabilities with the most critical impact.”
Much of the attack traffic is generated by automated tools and, fortunately, never connects with the corresponding vulnerability.
“[They are] like rocks thrown at a building that don’t hit a window,” he says.
Contrast found many organisations are continuing to struggle with vulnerability remediation. The mean time to remediate a flaw was 67 days for all vulnerabilities and 36 days for the serious ones. The company found 50% of vulnerabilities are remediated in seven days and 62% of the serious ones in just three days.
But the time organisations are taking to address the remaining flaws tended to be much longer. In fact, Contrast found that if an organisation did not remediate a discovered vulnerability within the first 30 days, the vulnerability tended to remain unresolved even after 90 days. In fact, even 65% of the serious flaws that were not remediated expeditiously tended to remain unremediated after 90 days heightening risk for organisations.
“Once a vulnerability survives that first 30 days, it’s more likely to get put into a backlog,” Williams says.
Someone might choose not to immediately remediate a flaw because they have another mitigating control in place. “But sometimes vulnerabilities are simply ignored by development teams and remain unfixed for long periods of time,” Williams notes.
How to Prioritise Remediation
Joseph Feiman, chief strategy officer at WhiteHat Security, cites other reasons, as well, for organisations to drag their feet on vulnerability remediation.
“If the application security testing tool is not accurate and produces too many false positives, it will take too much time for developers to figure out which ones to prioritise,” he says.
Feiman says the way organisations should prioritise their remediation efforts is to consider the severity of a disclosed flaw, determine how critical the vulnerable application is to the business, and determine how hard it is for a hacker to detect and exploit the issue.
Several organisations have severity-based vulnerability management policies and procedures in place that dictate the speed at which issues are remediated, says David Faraone, director and virtual CISO at the Crypsis Group.
“For example, a policy statement may state that for any vulnerability with a CVSS score of 9.0 or higher, organisations have an emergency procedure in place to patch 100% of these identified matters within 24 hours,” he says.
Others might have higher risk thresholds based on the type of asset or system that is impacted.
“For example, an organisation’s vulnerability management goal may have a target of patching 90% of all servers within two weeks of identifying the vulnerability impacting that system category, Faraone adds.
Ultimately, it is the maturity of the security team that determines how well, or not, an organisation is at vulnerability remediation, Faraone says.
“An often overlooked precursor to managing critical risks is having a formal cyber-risk management program in a place that is supported by senior leadership,” he says.
Full article attribution is made to its original source and author.