Covid-19 and Cybersecurity 7: The change freeze and Covid-19
2 years ago - Blog Posts
Over the past few weeks we’ve spoken to a lot of companies and organisations who have implemented a change freeze in some form with the core focus on system stability at a time when the risk of a significant proportion of their IT team could be unavailable is high.
They are certainly not alone with the likes of Microsoft and other organisations reigning in known breaking changes and even extending support for some version of Windows. However with my security hat on and keeping in mind the new wave of Threat Actors looking to exploit the situation it’s important to balance the risks of changing a system against the risks of it being exploited.
It’s all about risk management
Let’s envision a hypothetical company; they are going through the motions to migrate a web application that’s published to the internet from on premise to a cloud service provider. They know it’s running an out of date version of the Apache web server and that their new service provider will be managing their updates for them. Along comes COVID-19 and the project is put on hold and the web server sits vulnerable awaiting compromise.
In this situation our next step needs to be a risk assessment of leaving the service as is which is also mapped to the data stored the web server along with its configuration and connectivity to other services. Perhaps the web server doesn’t host sensitive data and is hosted in a dedicated DMZ – our biggest risk might now be remote compromise resulting in the server being used in a DDoS attack or to mine cryptocurrency. Alternatively if the server hosts special category data while also having broad internal network access our biggest risk shifts to data theft and potentially complete compromise.
By reviewing these risks alternatives to the original plan can be devised; perhaps based upon logging data the service can be restricted to be only accessible from a limited set of source addresses, features like inbound decryption and IPS could be enabled or simply patch the existing web server.
Each alternative carries its own risk, but by at least reviewing them and presenting them to management the residual risk can be understood and at least acknowledged if not fully remediated.
Today we ask
• Do you have a risk register, does it include how risks are remediated or mitigated?
• Does patching appear in the list of mitigations? If yes, are you continuing with patching?
• Are you evaluating the risk of not making a change against the risk of making it?
• Who in the organisation approves any residual risk, are they within the IT team or a non-technical executive?
As a business we are committed to providing help, guidance and support to our customers, particularly those on the front line and in critical industries. We want to do our part to help, so if you have questions, want to chat some things through, you know where we are.