Discussions at Board level on Cyber Security are generally low on reality and high on rhetoric. This is due to the meeting of two very different worlds. Between a CISO who appears to be claiming Armageddon on a daily basis unless the Board fund all requirements, and a Board who don’t have enough knowledge to understand what is important and what is not, in the context of Cyber Risk.
Ransomware
A Topical subject that is bound to have triggered some questions from Board members to their CISO. So how can a Board be assured they are in good shape to protect themselves from Ransomware, and what reporting do they need on a regular basis?
Ransomware relies on one simple fact. Not many organisations have IT backups for all their devices.
IT departments don’t like doing backups, don’t like testing backups, don’t like recovering from backup. It is the least sexy IT Operations activity that exists. No-one wants to do it, let alone do it properly. So it is usually left as a mundane task for the juniors to carry out.
Testing that the backup actually saved something that was recoverable into a new system, is labour intensive, requires spare resources such as disk space and virtual machine space, and doesn’t have an amazing outcome. It either works or it doesn’t. No Nobel prize for IT to be had here.
The Board requirement
To protect yourself from Ransomware you need:
- IT backups for all of your devices, that can reliably be recovered.
- A plan for how that recovery would take place. Recovering hundreds or thousands of assets efficiently and effectively takes a little bit of thought, which is best pre-planned. Doing this ad-hoc in an emergency recovery situation is not good for anyone’s stress levels.
- The spare resources required to test that the backups are working properly and can be recovered correctly if required. The people, the disk space, virtual machines, etc.
Metrics and Reporting
What metrics do I need reported to the Board on a monthly basis, to show that the risk is covered.
- Percentage of IT assets with active backups in place. (i.e. Of all the IT assets in the company, how many are being backed up)
- Number of failed recovery events as a percentage of total (i.e. of the total number of recovery events attempted, how many were successful)
Not having the disk space required to do the backup recovery testing is not a minor risk. If you cannot test your backups are actually working, you will have no assurance that they will work when required.
Ransomware Recovery Plan
The Board requirement for the IT recovery plan for Ransomware, needs to state which resources need to be recovered, in which order.
This is very similar to your business continuity plan and may be seen as a specific instance of business continuity. The important thing to remember is that you are not necessarily recovering everything, as if it was a lost data centre. You may only need to recover your laptop/desktops, or your Windows estate, or some other fraction/subset of your total infrastructure.
Network Intrusion (aka Hacking)
Specifically someone from the outside (not an employee or someone with valid access permissions), gaining access to your organisations IT equipment.
This access generally occurs because the hacker makes use of a known vulnerability. Vulnerabilities are essentially errors in application coding that allow attackers to do things in an application that were not intended.
These are fixed all of the time through a patch update process. Microsoft has one every month. The idea here is that if you apply the fix (aka the patch), the vulnerability is closed and the attacker has to look elsewhere.
End Of Life IT software assets (EoL)
If you currently have software in use that is no longer supported by the vendor, you will not be getting these patches because the vendor no longer creates them. So you automatically have vulnerabilities that cannot be fixed. This is a bad thing. To fix this one, the Board need to be assured that all of the IT assets are running supportable software. You also need to be assured that anything that is coming close to the end of support, say in 6 months time, has a plan to be replaced before that date.
Metrics and Reporting
So the Board metrics for the monthly report would be:
- Percentage of IT assets that are not in support from the vendor.
- Number of IT assets that will be out of support within 6 months. If this number is non-zero, you want to make sure there is a viable plan to replace these software assets before they expire.
By setting a 6 month threshold, the Board is ensuring that IT will strive to remove these assets before this date such that the number of assets that will be out of support within 6 months is always zero. Better to remove or replace the asset earlier than to have to answer interesting questions from the Board as to why these assets still exist in the infrastructure.
Vulnerability Management
The second part of managing vulnerabilities (aka vulnerability management or Patch management), is to make sure that all the fixes are applied to your infrastructure, when a vendor provides a patch. This requires effort and is quite boring (but not as boring as backups). IT operations staff as a rule do not like to touch a working system. Touching working systems sometimes makes them non-working systems, and lots of important people get upset. IT don’t like this, so they try not to do it.
Applying a patch from an IT Operations point of view, means having to touch a working system. It’s a little bit like vampires and garlic. This is not without merit, as patches have been known to break systems when applied, not though any incorrect action by the IT team, but because the creators of the patch didn’t think things through enough when they created them.
The bottom line for the Board is, if you have an IT infrastructure where all the known patches have been applied, you are in a very good place indeed. How close you are to this goal is what you need to be measuring and being updated on.
Metrics and Reporting again
The Board metrics for the monthly report would be:
- Number of high-risk vulnerabilities outstanding (usually this is straight out of some vulnerability management reporting tool). Think of high risk in this context as there is a high risk that an attacker would use this vulnerability. It is a good one for them. They can do a lot of damage with it.
- Risk rating from the total vulnerabilities in your infrastructure (again usually straight out of a vulnerability management tool).
You also need to see a plan for how vulnerability management will work within your organisation and approve it.
Your goal here is to approach zero outstanding fixes/patches, and as a Board agree a risk level that you would be happy to live with.
Your vulnerability management tool will always show you some issues that your IT Operations team have simply not had time to fix.
The clever bit here is to agree a period of time for deploying and testing patches (usually a month) where the report doesn’t show vulnerabilities within that month that could not have been fixed yet. Then you will have a report that shows how many vulnerabilities still exist in your infrastructure, even though IT Operations have had a month to fix them.
The vulnerability management plan shows that this process is not ad-hoc, but follows a structured process. This is important for the Board, your Auditors, your clients and your lawyers if you get into any trouble in the future.
