Verizon Business recently posted an excellent article on their blog about security patching . As someone who just read The New School of Information Security (an important book that all information security professionals should read), I thought it was refreshing to see someone take an evidence-based approach to information security controls. Verizon begins by asking the following two questions:
How much better is it to have a world-class patching process compared to an average one? Could it ever be detrimental to patch too fast?
The idea that “patching too fast” could be “detrimental” is clearly related to this column’s focus on the concept of “agile security,” so this immediately caught my attention. Verizon sums up the answers to their own questions nicely:
The recently published “Verizon Business 2008 Data Breach Investigations Report” describes characteristics of more than 500 computer crime investigations performed over the past four years. Our data shows that in only 18% of cases in the hacking category (see Figure 11) did the attack have anything to do with a “patchable” vulnerability. Further analysis in the study (Figure 12) showed that 90% of those attacks would have been prevented had patches been applied that were six months in age or older! Significantly, patching more frequently than monthly would have mitigated no additional cases.
Patching more frequently than monthly was not only unnecessary to prevent the vast majority of compromises included in their research, but there is evidence that in at least some cases the focus on frequent patching caused more harm than good.
In summary, the Sasser worm study analysis found that companies who had succeeded at “patching fast” were significantly worse off than “average” companies in the same study. This seemed to be because, as a group, these companies tended toward less use of broad, generic countermeasures. They also thought they had patched everyone, when in reality they hadn’t. You might say they spent more of their energy and money on patching and less on routing, ACLs, standard configurations, user response training, and similar “broad and fundamental” controls.
And the above quotation only considers the impact of “patching fast” from a security effectiveness perspective. It says nothing about the potential for other negative impacts of “patching fast” on an organization’s agility.
Compare the results of Verizon’s research with an industry benchmark, the very well-intentioned Payment Card Industry (PCI) Data Security Standard (DSS). The DSS addresses the issue of remediating security vulnerabilities. The first is DSS requirement 6.1, which is focused on security patches.
6.1 Ensure that all system components and software have the latest vendor-supplied security patches installed. Install relevant security patches within one month of release.
The second relevant DSS requirement is 11.2, which is focused on vulnerability scans.
11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).
Turning to the audit procedures for 11.2, we find the following statement.
Verify that the scan process includes rescans until “clean” results are obtained.
Finally, requirement 11.3 discusses penetration testing.
11.3 Perform penetration testing at least once a year and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment). These penetration tests must include the following:
11.3.1 Network-layer penetration tests,
11.3.2 Application-layer penetration tests.
Finally, the audit procedures for 11.3 do not explicitly state a timeline for corrected vulnerabilities discovering during a penetration test, but instead merely require that the auditor “Verify that any noted vulnerabilities were corrected.” Since 11.3 refers to penetration tests occurring at least annually and whenever there are significant changes in the environment, one could assume that any noted vulnerabilities (not requiring a patch) must be corrected either within a year or before the test scheduled after a major upgrade.
(I suppose I could have also included the recent PCI guidance in the supplement on requirement 6.6, but I think you get the point.)
Thus, PCI’s position on “fast patching” may reasonably be interpreted as follows. If a security vulnerability can be addressed by a patch, the patch must be applied within 30 days. If a security vulnerability is discovered by a network vulnerability scanner but the vulnerability cannot be addressed by a patch, the vulnerability must be fixed before the next quarterly scan. If a vulnerability is only discovered during a penetration test (and cannot be fixed by a patch), then it must be remediated within a year and maybe sooner (if a penetration test is required because of a major upgrade).
Aside from the fact that these well-intentioned requirements don’t really seem to be in synch with one another, what is obvious is that these requirements have differing levels of impact on agility. Additionally, if the conclusions of Verizon’s research are correct, it would appear that PCI DSS requirement 6.1’s focus on 30 days is not justified by the evidence.