I published a rather lengthy blog post about the importance of patch management to the success of a security program. Due to the length of the post I thought I’d add a tl;dr version of the primary points from the article.
- Bad security patching practices can and will undermine the budget spent on security tools
- Security patching needs to be a priority coming from the top of the organization
- CISO’s must ensure they partner with IT and business units and foster a “self-service” approach to vulnerability scanning and testing
- CISO’s and CIO’s must closely partner on configuration and patch management tools and administration
- CISO’s must present security patching data that focuses on practical risk to the company
- CISO’s must present security patching data that specifies the performance of each IT and business unit
- Leadership must hold IT and business leaders accountable for their group’s security patching performance
- CISO’s should not offer a risk-acceptance or security exception path for software vulnerabilities
3 Replies to “tl;dr – A Wonk’s Guide to Effective Vulnerability Management”
@djglass Having some experience in enterprise vulnerability management I somewhat agree and disagree with your points. Regarding #vulnerability #management in general it’s typically an area with low maturity beyond basic Microsoft services. Regarding the approach I would suggest to determining the right one, taking your business industry, the company’s risk profile into consideration. A manufacturing company’s have a very different profile compared to one in finance industry. Then it would be useful to understand how the #IT #OT function is perceived. In my experience it’s typically to think about these as #cost-centre, something to optimise. That would then be guiding policy for your program. What also is good to include risk management discussions, not only related to the vulnerability itself but what kind of risk the change potentially induces as well, particularly to OT side. As always the folks with the shoes on (if it breaks these are the guys that need to fix it) should be empowered to make the decision, however from risk monitoring perspective metrics and measurements should be established to see the development over time and keep it within #Risk tolerance.
I’m not sure where you are disagreeing with me though. Risk management is always part of the equation. However, if there is an unpatched vulnerability that is exposed, it should not be treated with risk acceptance – and if it is the system in question should not have made the report of “things that matter” that I mention. If the system does matter, other mitigating controls may be brought to bear to lower the risk (taking the device off the internet, putting it behind an NGFW, forwarding proxy, etc.) but one cannot simply wish the risk away. Very few senior executives of publicly trading companies I know of would knowingly be okay with leaving a risk on a “system that matters” exposed.