Why is "applying all patches now" a "wrong"? : 6 reasons why patching is difficult [Part 2]

　Greek explained this mistake by citing "a scene where the hull was hit by a large shell while the sailors were blocking the hole in the hull through which the bullet had penetrated". "It's like closing a small hole one by one and not worrying about a large artillery shell punching a one-meter hole in the wall," he said. To avoid this situation, he recommends identifying high-risk vulnerabilities and establishing security policies that prioritize them.

　Steve Zaruski, who served as Chief Information Security Officer (CISO) at jeans manufacturer Levi Strauss, believes that unpatched IT products cause business risks, not technical problems. Zaruski recommends "risk-based patching" for security leaders. This is to "assess the degree of danger that vulnerabilities pose to business processes, sales generation, branding, etc., and narrow down the vulnerabilities that threaten the company's goals."

On the other hand, Mr. Zaruski added that "it is necessary to review the way we think about, define, and measure risks" in order to implement risk-based patching. Companies continue to use the traditional simple technical KPI (key performance indicator), patch adoption rate, to measure effectiveness. "The ultimate goal is to measure superficial effectiveness," he says.

Brian Lozada, Chief Information Security Officer (CISO) of the video distribution service HBO Max, also said that using the patch application rate as an effect indicator "is often an unachievable goal, and a strong security system is not necessarily It is meaningless without showing it.” For example, if you plug 9 bullet holes and leave 1 cannonball hole, technically you have a 90% patch rate, but the remaining hole could be a disaster. Don't "patch for the sake of patching". "It's more important to measure corrective outcomes than it is to measure the means by which those outcomes are achieved," Lozada said.

Mr. Cahill recommends that when evaluating the risk of unpatched IT products, consider the vulnerabilities that can be fixed with the patch from the following three aspects.

1. How severe is the vulnerability?
2. Is there an example of an attacker actually using a program to exploit the vulnerability?
3. The vulnerability

　Eric Nielsen, senior DevOps engineer at the Infosec Institute, a technical training company, has Support the approach of setting SLAs (Service Level Agreements) for vulnerability remediation based on severity. The SLA set here is

. If any vulnerabilities remain unfixed for longer than these, companies should review their security programs. The reason companies never patch their IT products is because of underlying problems, such as staff shortages.

In the third installment, we will look at the second and third reasons why patch application is delayed.

Predictive IT trends from TechTarget

From the wealth of articles from TechTarget in the United States, we have carefully selected and delivered the latest technology explanations, product comparisons in hot fields, and examples of IT product introduction by overseas companies. increase.