I’ve been asked lots recently about ransomware. Considering the recent news headlines this isn’t surprising. Infosec continues to be a reactive process for many firms; spending money preventing an incident that may or not happen, can be difficult to quantify, and competes for resources against aspects of the business with a more measurable ROI, is not going to sit well with everyone.
“Why don’t companies just patch?” I was asked in a blasé manner by someone who should know better. Because it’s really, really difficult; Comprehensive patch management isn’t simply Windows Update, it’s the entire estate. It’s your core switch firmware, it’s the version of JQuery you’re using on your corporate homepage, and it’s those database applications that are immediately out of support if moved off of the version of database they were originally installed on.
And this is the problem. Successful patching and update efforts don’t start with the end-user, they start with the designers/developers and purchasers. They start by accepting that the foundation for our systems and applications must be a fluid one over time.
So what do we need to do to make patch management work?
1. Asset management – You may have holographic smart water asset tags on your servers (very pretty btw), but do you REALLY know what you are running? When your web developer incorporates that trendy new JavaScript library into your latest CRM solution, is it recorded anywhere? Because in the coming months there will be a vulnerability in it, and so it would be nice if you knew you were running it.
2. Triage – How serious is the vulnerability? Is there a publicly available exploit? What’s your attack surface? CVSS scores are only one way of gauging the Severity of a vulnerability. They lose a lot of value if only the base score is used (a common situation).The base score is meant as a starting point for risk management, not an end. The vast majority of vulnerabilities will never have a publicly available functioning exploit. Some vulnerabilities (logjam) require such computational power, or such a huge amount of network traffic, that the feasibility of exploit is extremely limited. These are not the vulnerabilities you need to be making specific update cycles for. These can wait, the ones that often need immediate attention don’t come from your vendor patch notification list, no, they come via the Infosec community, and (if serious enough) get covered in the mainstream IT media pretty quickly.
3. Supplier buy in – If that new finance solution can only run on Oracle 10G, you may be in for a bumpy ride. Deal with this pre purchase order, it’s a slow, cultural change that has to happen, but locking unpatched software solutions into organisations is a practice that needs to stop. The irony of running mission critical systems on platforms with known vulnerabilities because you’re too afraid to update hasn’t gone unnoticed (Something I affectionally term “let’s scope the main business systems out of the penetration test scope” syndrome).
4. Don’t panic – The catchy names, logos and headlines you see these days don’t change the fact that the actual number of updates that are drop everything critical is a tiny percentage of those published.
If you would like to discuss the above or anything in relation to our penetration testing and assessment service, please, as always, drop us a line