Lets suppose you know that your firm must patch a set of critical vulnerabilities in 30 days. The patching team is 70% loaded building and deploying patches. But, it is time to make sure that the patching lifecycle reaches 95% of your systems in 30 days rather than a typical 62% success rate per 30 days.
Management needs to give the patching team the ability to patch an optimal patching throughput of 3 days. The average patching lifecycle needs to be 10 days. Management needs to make sure the arrival rate of new patching jobs says about 70% of the best execution rate of patching jobs. If leadership does not do this, then reaching 95% of systems with required patches in 30 days will never work. Worse yet, nearly every MBA in the USA has been trained on the math needed to know this is likely to be true.
It is possible to improve upon these numbers but for pilot math to adjust this plan to what your firm needs is good enough to make a credible suggestion. Another business analyst using Factory Physics based GMM Queue Theory techniques can dig deeper in to the problem. But, to start the discussion, lets use the same math an MBA get trained on to help with Call Center Queues or Fast Food lines.
Pr = Odds that a patching effort will not complete in the time frame required.
Tr = The time frame required, often by compliance such as PCI DSS.
Ct = Cycle Time, the average time it takes for a patch job to get scheduled run and then complete.
U = Utilization or Staff Loading of incoming work vs best possible speed in work.
Te = The best possible time it takes to run a patching job with no waiting.
Pr = exp(-Tr/Ct) => Ct = Tr / ln(1/Pr)
If a job must be 95% sure to complete on time then here is a 5% chance it will not complete on time.
The average time to complete a patching lifecycle = Ct = 30 days / ln(1/(0.05) = 30 / ln(20) = 10 days.
Now lets look at the best possible, no waiting, execution time.
Ct = Te/(1-U) => Te = Ct * (1-U)
Te = 10 days * (1 - 0.7) = 3 days
It takes a best execution time, no waiting, for 70% loaded patching staff to complete a patch lifecycle in 10 days on the average. Then, they get a few more cracks at patching every system to reach 95% effective in 30 days.
Laptops are traveling so they do not get the patch job. Patches get delayed due to adverse impacts on production or Vendors who have not released a good patch yet. Virtual machines only meant for load capacity, business recovery or load balancing are down from time to time. There are lots of reason nearly every firm is experiencing a level or process noise. C, near 1. Fixing why Sigma/Average process noise to signal are happening and fixing this is a very cost effective Lean/Six Sigma effort. But, until this improves. The math of queues or waiting in line works very well for NM1 queue math. Beyond this, a back of the envelope patching process is well estimated by a method your MBA leadership already recognizes as credible.
But, suppose you want more. A book called Factory Physics lays out GMM Queue theory estimates that work very well. These can allow you to look at what happens if the patching lifecycle could reduce process noise and even handle parallel line effects.
Best Wishes,
Don
Don Turnblade, MBA, MSc
"Protecting good people from being robbed with a computer."
PCI ISA, SSBB, CISM/CISA, C31000/AT31000, CISSP, PCIP
