undiscovered by the vendor even when they’re being exploited by miscreants, and non- disclosure creates a culture in which vendors turn a blind eye. A more balanced alternative is responsible disclosure as pioneered by CERT/CC in the US. CERT/CC notifies vendors to give them time to develop a patch before disclosing the vulnerability publicly. When the vulnerability is finally disclosed, no exploit code is provided. Empirical analysis comparing the patch-development times for vulnerabilities reported to Bugtraq and to CERT/CC revealed that CERT/CC’s policy of responsible disclosure led to faster patch-development times than Bugtraq’s full disclosure policy . This is because CERT/CC has developed a more constructive relationship with software vendors, working with them to fix vulnerabilities. The researchers also found that early disclosure, via CERT/CC or Bugtraq, does speed up patch-development time. Option 2: Vendor liability for unpatched software Another option is to assign liability for vulnerabilities to the software vendor until a patch is made available and consumer has reasonable chance to update. This could encourage faster patching. Cavusoˇ glu et al. compare liability and cost-sharing as mechanisms for incentivising vendors to work harder at patching their software . It turns out that liability helps where vendors release less often than optimally. Option 3: Fixed penalty for slow patchers Since liability has been fiercely (and so far successfully) resisted by software vendors, it is worth considering alternatives that could also speed up patch deployment. Vendors slow to issue patches could be charged a fixed penalty. Given that some operating system vendors are much slower to release patches than others (Figure 12), a fixed penalty may be quite effective at improving the overall speed of laggards. One drawback of fixed penalties based on a single time threshold, however, is that most vendors already prioritise their patch development to push out fixes to the most 63
severe vulnerabilities fastest. Introducing a time-based penalty may draw resources away from developing critical patches in favour of less-important ones near the deadline. Recommendation 6: We recommend that the EU adopt a combination of early responsible vulnerability disclosure and vendor liability for unpatched software to speed the patch-development cycle. 6.5.2 Challenge 2: Increasing patch uptake While quantitative measurements are difficult to obtain, the view among security profes- sionals is that patches are available for the majority of exploits used by attackers. Over half of the exploits in Table 6.5.1 appeared on Chinese websites after a patch was made available. Because these exploits are being advertised well after the patch was available, this provides evidence that attackers target unpatched machines. Judging from the me- dian values (22-day lag for patched vulnerabilities versus 2-day lag for zero-day exploits), whenever patches are published before exploits, attackers are less rushed to develop ex-
You've reached the end of your free preview.
Want to read all 114 pages?