Half of tested sites exposed to at least one exploitable vulnerability throughout 2021

0
A computer screen is filled with code during a hackathon February 1, 2014 in Miami. (Photo by Joe Raedle/Getty Images)

Researchers found that 50% of all sites tested were vulnerable to at least one severe exploitable vulnerability throughout 2021, while only 27% of sites tested were vulnerable for less than 30 days.

In releasing its “AppSec Stats Flash: 2021 Year in Review,” NTT Application Security focused on changes in exposure window and resolution time data across industry verticals including healthcare , manufacturing, utilities and retail.

Here are some highlights by vertical market:

  • Utilities: Some 63% of utility websites were vulnerable to at least one exploitable vulnerability throughout 2021, up 8% from the previous year.
  • Education: The industry had the longest time to fix a critical vulnerability of any industry – 523.5 days – almost 335 days longer than public administration (188.6 days), which maintained the shortest time throughout 2021.
  • Finance and Insurance: At 43%, these industries had the lowest percentage of perpetually exposed sites.

Some of these stats are so high because organizations are grappling with growing web assets, downsizing/security expertise, and rapid application deployments via CI/CD to bring new features and functionality to market as quickly as possible, said Ray Kelly. , a member of NTT Application Security.

“It’s a constant game of catching up,” Kelly said. “If organizations don’t focus on patching critical vulnerabilities, sooner or later malicious actors will take advantage. The report’s most important finding concerns the exposure window, the fact that 50% of web applications were vulnerable to attacks throughout 2021 is quite alarming.

Mark Lambert, vice president of product at ArmorCode, said these vulnerabilities are generally known to teams, but security professionals face a lot of automation, generating lots of data, but no actionable insights.

“AppSec teams are outnumbered 100:1,” Lambert said. “Dev and security teams are siled and disconnected, leading to frustration and finger pointing. So builds come out fast and furiously with known vulnerabilities – and when new vulnerabilities are identified. , teams must scramble to respond.

Michael Isbitski, technical evangelist at Salt Security, explained that while the statistic that half of organizations are vulnerable throughout the year may seem alarming at first glance, the number reflects the realities of continuous security testing and the need publish applications in production. Isbitski said when organizations run application security testing (AST) tools, they often uncover similar sets of issues that they may not consider risky.

“It’s not uncommon for organizations to ignore or remove these security issues altogether, especially information disclosure issues,” Isbitski said. “Analytical tools frequently flag the mere presence of certain HTTP headers or server banners as information disclosure. This metadata offers details to an attacker about back-end systems and versions useful for finding other vulnerabilities. Information disclosure issues don’t always stem from the application code, and more often they stem from the configuration of the infrastructure.Other issues, such as injection faults and abusive business logic, often attract more attention.

David Stewart, CEO of Approov, said security vulnerabilities will always exist in software and while it is right to allocate time and resources to fix them, we will never reach a point where the industry will release software without vulnerabilities.

“What organizations should do, alongside their vulnerability patching efforts, is protect their applications and the APIs that serve them from scripts owned by bad actors seeking to exploit vulnerabilities,” Stewart said. “Effective shielding ensures that malicious scripts cannot reach intended backend services. Remember that the existence of vulnerabilities is not the main problem: it is the ability to exploit them. So block the exploit path first, then fix the vulnerabilities at your (relative) leisure.

Share.

About Author

Comments are closed.