When discussing cybersecurity topics, you have probably heard a lot of discussion on zero-days, phishing, vulnerabilities, and even the latest trends for cybercrime groups. What may have been discussed less often is patch management. However, while it isn’t the sexiest security topic, it is one of the most vital.
A patch management program is a formalized approach to ensuring solutions are maintained, with the appropriate persons aware of their roles and responsibilities, and ensuring the solution fits within the organization’s capabilities. Maintaining patch levels helps reduce the likelihood of incidents and can even reduce the impact of some incidents.
How can organizations ensure they have an effective program? Ideally, the following would be considered and formalized from the start and formally documented as soon as possible.
However, most organizations will not be able to start over. Where can they begin to align with the below? It’s the same idea but retroactively applied. Start with business critical, highest risk and most exposed solutions for priority – then work backwards to ensure each solution has the appropriate information formally defined. This list isn’t exhaustive, but it is a great place to start.
1. Risk Appetite, Frequency and Regulatory Requirements
First and foremost, the organization needs to define what it’s comfortable with. What is the definition of up-to-date internally? It may be the latest patches only, but it can also vary by type of solution, i.e. mobile phone OS may need to be prioritized. Additionally, organizations need to work out what frequency is required, i.e. critical patches must be within x number of days, whereas regular non-security patches may be able to take a longer deployment. This can also vary by the type of solution and system, e.g. a business-critical server vs colleagues’ laptops.
Further questions to ask when creating these definitions are does your organization need to align with any certifications and/or regulations? If yes, they may have their own frequency to align with, for example, Cyber Essentials.
For applying this to existing environments, it may make sense to create a more lenient requirement, and once the business is aligned, further restrict the requirements until they meet the organization’s risk appetite.
2. Responsibility Matrix and Nurturing Awareness
Unfortunately, it is common for new solutions to be deployed without fully defining who’s responsible for what aspect. There may even be a shared responsibility model, where another internal team or third party hosts something. Who’s responsible for testing patches, what type of patches are they deploying (e.g. OS-level only or application level) and who’s accountable for ensuring they are deployed successfully?
For new solutions, there should be a matrix that defines the maintenance of a solution, including patching. Don’t forget, when someone leaves an organization, who takes over the responsibility? Especially if there is a gap between the leaver and new joiner.
For existing environments, you can again start with the most critical and work backwards. Identify what team(s)/person(s) are currently handling different activities and what gaps exist.
At some point, there may be an impact on end users and/or consumers. Patch management should be relatively frequent, and out-of-schedule patching for critical patches can further disrupt persons. This is why colleagues must be made aware of the importance of collaboration with the program to prevent unnecessary delays and frustration.
3. Level of Criticality and Available Capabilities
Knowing the type of data and business criticality of a system or solution is key to helping you know the priority. It will also ensure you know how much testing is required and what teams to notify when a potential outage might take place. For colleagues’ laptops, this might mean deploying patches at the end of the day on a planned date. Whereas externally exposed licensing servers of custom-built software may require notification to consumers of possible outages while maintenance takes place.
One challenge I have seen in various organizations throughout my consulting years was tooling or skills gap for solutions already in place. I even saw one environment where they hoped a system didn’t go down as there was no one skilled internally to rebuild the server if it did go offline. In that situation, a question would be, is this solution worth the cost if something happens, or would it be smarter to invest in a replacement?
4. Quality Control and Proactively Identifying Gaps
Consider how your organization stays aware of what solutions are in place and the patch level deployed. A slightly manual approach, such as an Excel document, may suffice in a small organization. However, new tooling will likely be required once you get to medium and large organizations.
We’ve seen time and again with vulnerable software or library announcements that many organizations don’t know what is in place or what’s required in their environment. Restricting who can deploy solutions, creating an authorized list, and controls to track what’s installed can significantly enhance your program. Patches might not always deploy in a timely fashion; failures happen or due to timing delays may be required – tooling can also assist in ensuring compliance.
Some patches require reboots, others may cause conflicts, and the annoying ones may change default configurations. Testing environments or selecting sample groups from production may be worthwhile to validate a patch before fully deploying.
Many organizations will have solutions that simply cannot be updated. However, they are still required to be retained either temporarily or long term – in that case, they are still in the scope of the patch management program, responsibilities still exist and need to be documented, but a risk waiver may be applied with compensating controls defined and reviewed on an appropriate frequency.
5. Automation
While it may not be possible to automate every aspect of patch management, there are some things you can configure – such as configuring auto updates of solutions that are not business critical or a short outage will not cause serious harm. Deploying tooling to measure patch levels, easily deploy patches en masse, restrict unapproved solutions and/or identify vulnerabilities detected in solutions deployed. The last one is beneficial for environments where a large group of persons have access to install new solutions.
Conclusion
While the above does not provide an exhaustive list of patch management, it does start to identify considerations often forgotten regarding effective patch management programs. At the end of the day, an organization is only as secure as its awareness of what’s in its environment, who is responsible for what tasks, and the controls that are in place to proactively identify gaps before issues arise.