Two of the most meaningful ways to manage risk and make your company more secure is patch and backup. Ransomware has taught the value of backups. And patching is the result of a need for product function, or security.
Patching, like backups, is done by non-security teams and falls into the realm of IT Systems Management, or ITSM.
Patching has exemplified the two forces at play in cybersecurity: function vs security. Function has always been the ‘strong’ force, to use a physics analogy. Without the business, there is nothing to secure.
Cybersecurity has adapted somewhat and is more aligned to recognizing this and working with business to function but with security. It’s the core of DevOps security to recognize that security must be built into the business, not just bolted on.
The gap for patching – between the gravity of security and the needs of the business – is wide: between the security imperative to patch immediately to close vulnerabilities and the business need to patch in a way that is the least disruptive to the business.
It’s not just the task of applying the patch but ensuring that the patching doesn’t break anything is a more important concern. This balancing act has been managed by the Ops teams using ITSM products.
Enough philosophy. You may have been advised to ‘unplug’ your ITSM product this week. This is an unusual event as most vulnerabilities are handled by putting in place a pre-patch shield (IPS signatures) that buys time until the patch is available and can be tested and installed with the least disruption to the business.
Being advised to unplug a product is highly unusual and indicates that running the product brings with it very very high risk. But after you unplug, there is a smaller, yet not insignificant, risk associated with not having an ITSM.
The advice from SolarWinds this week includes unplugging, taking security actions to examine for compromise, rebuilding the hosts, then bringing the known-good ITSM online. This likely won’t happen quickly.
We are not suggesting that companies ignore the recommendation to unplug, but that the risks associated with this action are known and dealt with:
- The biggest issue is, ironically, patching. Your ITSM may be your patch management solution. Identify if there are any critical patches not related to your ITSM product that need to be deployed and decide whether that should proceed. If nothing else, ensure IPS signatures for those vulnerable products are in-line.
- System and network performance monitoring will likely be unavailable. If your SOC has any ITSM views for threat-hunting, they’ll have to look for other sources (switch vendor provided monitoring) or use less preferred or indirect monitoring views.
- Not all outages will be performance related. Resist the assumption that performance changes are caused by a functional outage due to the ITSM being removed. It could be an attack or malware taking the opportunity to infiltrate the environment while the ITSM is not present.
Thinking through these items can mitigate some additional risk while the ITSM is disconnected, and while we wait for more information on this incident to arm threat hunters in victim organizations. The next steps will be far more difficult as companies remove all traces of these attackers from their networks.
In the meantime, the best advice overall is for those ‘frenemies’ of security and ops to talk more during this period. Leave the blame hats at the door, and work to keep the IT infrastructure up and secure when the ITSM, that dashboard of the IT car, isn’t working for a while.
For more information on all the ways Trend Micro is supporting and protecting customers impacted by the SolarWinds situation, please visit: https://success.trendmicro.com/solution/000283368.