Background
I was tasked with creating a vulnerability management program from the ground up. Our current program was designed 15 years prior, for a different time, with a different objective. It centered around physical security and did not address core principles seen today such as risk ratings, risk priority, and patching. The security team had expanded from a two person team to 4 analysts and a director, while the organizations foot print went from 30 servers and a couple hundred workstations to hundreds of servers, a couple thousand endpoints, and multiple cloud services.
Purpose of this blog series
I wanted to share the culmination of my findings with the community. I found a lot of different resources along the way and by the end realized putting them together with a narrative may help someone on their vulnerability management journey. This blog is intended to help you address your own vulnerability and patch management program.
I am trying to help define a way to avoid the security theater of reactive patching or debating how an “APT” can chain these obscure vulnerabilities to “pwn” our environment. Executives don’t speak that language, they speak money and harm to the organization. That is communicated to them through risk and associated costs.
You can follow this blog to try and create a robust and extensive program. A word of caution, you need to do what your organization is ready for, not drop this entire document on your business. If you are just starting out, see a program like this as your goal if it fits your business. Start small and move outwards. Many organizations do not reach the level of this document and that is fine. Even the organization I am working on this with is still adopting this and working through the nuances that apply to us. That will never change as it is a marathon, not a sprint. As long as you are actively working towards risk management, try to keep from getting discouraged!
Every organization’s program is different and must be! Every business is different. The key piece to make this program successful is to understand the business! Take what you need and trim excess. There is a thing as too much security.
So lets jump right in!
Prerequisites
If you want to succeed there are a few things you need to have ahead of time. First and foremost you need to understand what exists in your environment. Asset management is not easy and is a continual journey without end. Your environment changes daily and keeping up is a huge challenge. Anyone that tells you it is “easy” is lying or has no clue what they are doing. I have yet to see anyone truely succeed at having 100% coverage over any amount of time. That being said the only way to succeed is to try. Start and keep at it, do not feel like you have to have this at 100% before you proceed.
The second requirement builds on asset and data management, which is an understanding of what is important to the business. The reason this relies on the other is if you dont know what you have, it will be hard to understand what requires what controls. If your company already has a Business Impact Analysis it is an easy starting point to understand what is important. If your organization does not have what is important documented, you will need to talk to the business to gather information to truely understand. This is not easy and is a continual journey as well. Businesses change and therefore values of data and systems change over time.
What is it?
A vulnerability and patch management program, VPMP, is a defined systematic way to discover and address weaknesses in cybersecurity defenses to reduce “surprises”. Addressing security issues methodically gives you a better assurance that gaps have been closed as quickly as possible. The goal is to reduce the chances of lost revenue and productivity that can result from intrusions or application failures.
The importance of defining a program is crucial to set expectations for scope as part of your document. This should be at the beginning, if not the first item addressed. Think of it as an “executive overview” or “TL DR” to help the reader understand what your program encompasses. This can change over time and is not set in “stone”. This should be a “living document” that changes and flows.