The Business Analyst in a Patch Management World

WannaCry. Petya. Meltdown. These are just some of the ominous monikers of recent cyber threats.

Today’s IT world is a new wild west, fraught with attacks from malicious individuals, groups, and even nation states. The impact of such attacks can be catastrophic to high profile corporations. Any organization with an information technology system is a potential target. Protection against cyber exploits is now a top priority. There’s now a growing demand for a specialized type of analyst with, if current job postings are any indication, titles like Patch Analyst, or Security Vulnerability Analyst.

So where does a traditional Business Analyst fit in this new Patch Management World? Does a BA have to upgrade skills to meet business demand for domain knowledge in such things as vulnerability assessment applications and patch deployment tools?

Not entirely.The traditional Business Analyst still has a critical role to play in the development and implementation of a functioning Patch Management program. Very few organizations started out with sophisticated patch programs. Typically, it was a set of duties shouldered by system administrators. That saw an evolution into a company’s Security division, which received and assessed vulnerability advisories being issued by vendors such as Microsoft and IBM. Now, the sheer volume and complexity of threats necessitates a comprehensive organization-wide program, with cross functional processes and procedures between Information Security, Operations Systems, Change Management, and other corporate divisions.

And that’s where the Business Analyst comes in. Moving from a rudimentary patch cycle to a comprehensive patch management program must start just like all other major initiatives; with solid requirements. What are the infrastructure assets that must be protected? Is it just servers and employee laptops? What about network appliances? What corporate divisions are stakeholders? Are there customer facing units that cannot bring systems down for patching outages? Who has the final say on if and when to patch? Is it the Security division, or does systems Architecture decide which threat has the most impact?

---

---

The answers to these questions can only be addressed through a focused business analysis. A detailed Business Requirements Document is not the only key deliverable needed here. Leveraging Enterprise Analysis skills, the BA can assess the scope of the patch program and where the capability gaps are in the present patch cycle. A thorough Stakeholder Analysis will reveal who ultimately has the final say on what and when to patch, as well as who else has skin in the game, not to mention the touch points between all the players and what their responsibilities are. Here the BA thinks RASCI (Responsible, Accountable, Support, Consulted, Informed). Consider as well the need for process flow charts, policy and governance documents, and procedures guides. These are all arguably Business Analyst products.

Then there are the technical aspects of the patch initiative that must be assessed and ‘solutionized’. A complicated IT landscape can be the bane of patch implementers if technical specifications and architectural design documents are sloppy. There’s the all-important ‘asset inventory’ of items in the organization’s technology infrastructure. Almost everything can be a vulnerability target, including laptops, servers, network switches and appliances, plus things you wouldn’t normally consider like smart devices such as phones, security cameras, and electronic door actuators. Consider just servers alone. Does your organization have an accurate and up- to-date server list? Whether you do or not, you can be sure a BA will make it a mandatory requirement listed in the BRD. You can also rest assured a BA will determine that the server list has more than just a server name and IP address. It will also contain critical details such as operating system version numbers, physical location, platform type, and more. And if your server list is hefty with scores of physical and virtual servers across different Windows or Unix platforms, the BA may draw on his solution assessment skills to propose a patch tool solution. He’ll be getting that Business Case template ready.

So what happens when all this up-front work is finished for patch management? Is the Business Analyst finished his duties? Not quite. There’s a big component of BA work called Validation. Part of that Validation is an activity that the Business Analysis Body of Knowledge (from the International Institute of Business Analysis) calls Solution Performance Assessment. Here’s where a BA is needed to apply critical thinking skills to design key performance indicators (KPIs), plus analytical and problem solving skills to implement methods to capture and analyze the data. In doing this, the BA plays an active part in driving improvements to the patch management processes, artifacts, and ultimately, the ongoing results of the patch management program. To ‘Kaizen’ purists, this is ‘continuous improvement’.

All in all, the Business Analyst definitely has a prominent role in today’s Patch Management World.