This paper provides a comprehensive discussion on patch schedules. This discussion occurs over two parts. The first analyses existing implementations of patch schedules with a focus on Microsoft’s monthly patch schedule. The arguments for patch schedules, namely increased patch quality and better planning within organisations are analysed and the impact of the type of disclosure investigated. It is concluded that in the case of delayed disclosure, where the vulnerability researcher privately discloses the vulnerability to the vendor allowing a patch to accompany the public disclosure, patch schedules provide significant benefits. However, in the case of instantaneous disclosure, where a vulnerability is disclosed directly to the public, as in the case of 0days, implementing a patch schedule significantly increases the risk to organisations waiting for a vendor patch. Some vendors already allow for ’out of band’ patches to be released, however the criteria for choosing when to release a patch ’out of band’ in unclear and often subjective. Additionally, involving the community in rapidly prototyping and testing patches will provide intrinsic benefits. The second part then builds on these findings to provide advice to vendors implementing patch schedules. First the type of disclosure is recommended as an objective and pertinent criteria for differentiating when a patch should be released per a schedule or as soon as possible. Next, effective mechanisms for implementing both types of patch release are discussed. The paper concludes that while patch schedules can provide significant benefits, vendors can still make many improvements based on recent examples to significantly improve their patch release methodology. Some of this work was undertaken in the Distributed Multimedia Centre of Excellence at Rhodes University, with financial support from Telkom SA, Business Connexion, Comverse, Verso Technologies, THRIP, and the National Research Foundation with additional financial assistance from the DAAD foundation hereby acknowledged. Some work was undertaken while in the employ of Deloitte and their contribution is acknowledged and appreciated.
[1]
Eric Rescorla,et al.
Is finding security holes a good idea?
,
2005,
IEEE Security & Privacy.
[2]
Eric Rescorla.
Security Holes . . . Who Cares?
,
2003,
USENIX Security Symposium.
[3]
Ramayya Krishnan,et al.
An Empirical Analysis of Vendor Response to Disclosure Policy
,
2005,
WEIS.
[4]
William A. Arbaugh,et al.
IEEE 52 Computer
,
1985
.
[5]
H. Summerton.
Who cares?
,
2000,
Nursing times.
[6]
A. Arora,et al.
Impact of Vulnerability Disclosure and Patch Availability - An Empirical Analysis
,
2004
.
[7]
EschelbeckGerhard.
The Laws of Vulnerabilities
,
2005
.
[8]
J. Röning,et al.
Introducing constructive vulnerability disclosures
,
2001
.
[9]
Hao Xu,et al.
Optimal Policy for Software Vulnerability Disclosure
,
2008,
Manag. Sci..