There are some math models for business that MBAs are taught. Just like assembling burgers for fast food or call wait queue management in a call center, vulnerability patching is a time based business opportunity. Leadership can be expected to use this math for capacity planning.
Suppose Microsoft produces 200 new vulnerabilities to patch each month. Further, suppose for capacity planning or compliance reasons, these patches need to be applied in 30 days. What would a patching process look like that is 95% likely to achieve this level every month? What if the patching team has a work load near 70% or higher? What are realistic patching process capabilities to sustain this?
Tr = Required number of days that a patch should not exceed waiting in line.
Pr = Probability that a patch has been applied in the required amount of time.
Tc = Average time a patch will wait in line from arrival to resolution.
U = Average work load of staff providing the patching process
Ra = Average rate of arriving patches per day
Re = Average rate of patches being resolved per day (the front of the line speed.)
How fast must patches clear on average in order to be 95% certain they resolve in 30 days?
Pr = 1 - exp(-Tr/Tc) => Tc = Tr/ln(1/(1-Pr))
Tc = 30 days / ln(1/(1-.95)) = 30 days/ln(20) = 10.0 days
If staff is 70% loaded, how fast must patches be resolved
U = Ra/Re = 0.7
Re = 1/(Tc*(1-U)) = 1/(10.0 * (1 - 0.7)) = 0.33 patches/day
Ra = Re * U = 0.33 * 0.7 = 0.23 patches/day
What is the maximum number of patches this process can sustain without getting overloaded?
Arriving Patches = Ra * Tr = 0.23 * 30 days = 7.0 patches/month
If patches arrive faster, then something must improve.
- The average rate of patching gets faster
- Parallel lines of patching are formed to keep up.
- Vendor selection must favor systems with lower needs for patches per month.
- A patch process quality improvement effort must be launched.
You must sign in to rate content.