12 steps to Cyber Insurance Eligibility

We all know the point of insurance; we are hedging against bets we cannot afford to lose. Current trends in cyber crime have resulted in a shift in the cyber insurance market, meaning not all organisations are insurable. Since the actuarial data for cyber is far less complete than more mature markets, insurers rely on root-cause analysis of incidents to build a picture of what a risky organisation looks like. The good news is that as a result, there are specific things you can evidence to show that your organisation has mitigated those risks. This article will look at twelve things insurers are looking for – that we should all be doing anyway. It will then suggest a straightforward way to present them to your insurance company or broker to maximise your chances of a successful renewal.?

1. Identity and Access Management (IAM)?

If you do not yet have multi-factor authentication (MFA) on all your external facing services, stop reading this and make that happen. If your list is long, focus on privileged accounts such as administrators, remote access, and email access to start with. Collaboration tools should be next as social engineering is a lot easier if you have access to an organisations internal instant messaging system or video conferencing tools.?

In case this is new to you, MFA means access to your critical systems will require at least two of these:?

1. Something you have, such as a passcode on an authenticator application?
2. Something you know, such as a password?
3. Something you are, for example using biometric reader??

If you use a commercial off the shelf Identity Provider (IdP), MFA will be available as a built-in option. Most decent Software-as-a-Service (SaaS) products will also have as standard process for integrating with you IdP of choice. It can be harder with internal tools, but competent developers should be able to pick up Security Association Markup Language (SAML) quickly.?

The challenge is convincing the people in your organisation to tolerate the extra hassle. Lack of Cyber Insurance will usually convince the board, which should result in a ratified policy to protect the system administrators making the change. Be prepared with an exception process for niche cases - 80% compliant is far better than 0%, you can mop up the tricky corner cases later.??

There is much more to IAM than MFA, but this is where you must start to be insurable in 2022. Frankly, it is the single best thing you can do to secure your organisation.??

2. End of Life (EoL) Systems?

Decommission these. Easy, right??

It is said that no enterprise has ever fully eliminated EoL systems. This is where our security policy exception process is key. If a system is critical to your business and cannot be removed quickly, your best option is to reduce the blast radius of any compromise. Isolate them from the main network, use a firewall to minimise any open ports and provide a single point of monitoring and control. A standard process by which EoL systems can be quickly assigned least-privilege will help. An inconvenient system that meets the business need is harder to argue against than removing that system. The lack of convenience is likely to drive the upgrade you need. Extended support can be expensive but buys you time. Truly EoL systems should not have internet connectivity. As Dr Seuss said, "Life is a balancing act".??

3. Network Segmentation?

Logical network zones with restricted access between them are a great idea. The obvious ones to start with are:?

1. Untrusted and Bring your Own Device (BYOD)?
2. Trusted (managed devices)?
3. Operational Technology (OT)?
4. Shared Services (DNS and other global services)?

A starting policy might be something like 1, 2 and 3 cannot communicate with each other but can access 4.?

You may wish to subdivide these, for instance Building Management Systems and Closed-Circuit Television could both sit in OT but would benefit from their own zones. You will then need an automated mechanism to determine which zone a device connecting to your network is put in. I would also suggest an external check that the zoning is working. For example, you could put a monitoring server in your Trusted Zone, configured to ping devices in your OT zone. Should a ping succeed, generate an alert that your zoning has failed.??

4. System Segmentation?

You do not want a single disaster to take down any critical systems. You can decide how far to take this but at the very least individual components should share power, cooling, or networking. Ideally, they will be in different geographic regions since extreme situations – such as severe weather – can cause all kinds of unexpected problems.??

Similarly, compromise of an internet-facing node should not result in access to a database or other internal systems. Pay special attention to systems holding personal data. Nobody wants to make headlines for a major data breach. You should encrypt those systems and their backups and have robust procedures around data access, including separation of duties where appropriate. A functional Record of Processing Activity (ROPA) with an assigned and accountable Data Owner can help, even if you may not require one in law in the UK for too much longer. Layers of defence people.??

5. Business Continuity Plan / Disaster Recovery Plan (BCP/DRP)??

You will need board or executive buy-in for this to make a difference. Many enthusiastic have written detailed business recovery plans only to have them stored safely away never to be looked at again. These need to be living documents and you will need to run through them annually – and be able to evidence to the insurers that you have done so.??

What does that look like? Disaster Recovery can be scoped to individual key systems and servers. Each of these should have a service owner and be recorded in a service catalogue. You can sometimes outsource DR for SaaS solutions, but verify your contract includes this. If you have an on-premises virtualisation platform, you might be able to produce a single Disaster Recovery Plan for all services hosted there. Watch out for databases though, they often need extra steps. The DR plan should include backup and restore procedures, failover procedures, any high-availability solutions included for disaster avoidance (DA) and a link to the DR testing log.?

Cyber incidents need to be part of this. We ran workshops thinking through the business impact of a major cyber incident. Questions like "who will talk to whom", "whose devices will we prioritise", "what are our roles and responsibilities" are better answered in advance. The NCSC (National Cyber Security Centre) has some great resources here: https://www.ncsc.gov.uk/information/exercise-in-a-box.??

BCP is a broader topic. Hopefully, your organisation already has this in place, and you can feed it with your DR plans. If not, start with what you would do if your data centre were a smoking hole in the ground, or if all your laptops were suddenly encrypted.??

6. Separate your Backups?

Do not put your backup eggs in the same basket as your production system eggs. Keeping backups in a separate geographic region is prudent. Also, do you allow the same domain admin accounts to access your production systems and their backups? If so, why? You do have MFA on those backup admin accounts right? Encrypted backup systems designed with immutable file systems are good. Tape has its place too.?

7. System Backups?

This is related to 5. We all need to take regular backups and regularly test the restore procedure. Other things to consider include whether stakeholders understand what Recovery Point and Recovery Time Objectives (RPO/RTO) are and how they apply to their system. Have you tested that for an arbitrary system, you can get the right data back within the RTO? Shorter RTOs and RPOs are expensive, have your right-sized these for your business needs??

8. Firewall and Network Perimeter Defences??

Does a firewall make sense in 2022, when most traffic is encrypted anyway? The reality is, I lock my door when I go out – even though a determined criminal would be able to break into my house. I might as well check my locks are in good working order and conform to the standards expected by my insurance company. How do you do that with a firewall???

Beyond the obvious hiring of good people to admin your firewalls, I would suggest an annual rule audit and unused rule clean up. Automate monitoring so that firewall changes are communicated to relevant personnel - in addition to standard change control procedures. Have a highly conservative firewall policy and clear exceptions procedure. This should have appropriate sign-off and an assigned risk owner for each exception. Firewalls can be a wealth of information but the signal to noise ratio is often poor. Projects to improve this and fold relevant firewall information in with other daily checks are beneficial.??

Putting a firewall between security zones is sensible as it provides a single point of visibility and control.??

9. Patch your systems?

Boring but important.??

1. Start with Policy, again to defend the administrators pushing out patches.??
2. Have an exception and quarantine process as previously mentioned.??
3. Communicate to your business. If automated regular patching is not already happening, warn them it is coming. PCs which have not been patched for a while can be out of action for a while and this could damage your reputation and negatively affect your ability to get this done.??
4. Use a vulnerability scanner.?
5. You need visibility. If possible, combine dashboards showing the state of your estate into one place. We have a lot of Scientific Operational Technology and hooked our network patch database up to our Windows, Mac and Linux management platforms, and the output of our vulnerability scanner. We now have a single view showing OS (Operating System) version, location, and wall socket, whether the device is IT-managed and other useful metadata.??
6. Push patch management as close to the user as possible. Our managed devices automatically update, with an option to snooze for up to 24 hours. Our IT (Information Technology) Helpdesk assist owners of devices over which we have no direct control. If they cannot be patched, we quarantine.??
7. Use Key Performance and Risk Indicators (KPI/KRI). PCI/DSS and other standards are explicit about how quickly devices must be patched. By setting your KPI to match the standards against which you are measured and making the KRI shorter than this, you can alert and act early. Your insurer may expect KPIs as tight as 7 days. This may not be possible – we test all patches before deploying them to production and some bugs take longer than this to show. 30 days is usually achievable as a KPI, 21 days is a good place to start for a KRI.?

10. Endpoint Protection?

The Cloud and machine-learning have transformed the antivirus market. Your business needs will drive what you deploy. The following points are worth considering:?

1. Are your devices configured securely? Is anyone on your network sharing their C:\ drive for example? Are you domain policies robust? How are your monitoring this? Annual pen tests help but look for something continuous.??
2. What is the footprint of the endpoint protection? We have faced resistance to agents which affect the performance of our scientific equipment. A lightweight tool which provides good enough coverage is better than a power tool which has been disabled.??
3. What resources are available to you to monitor alerts? Will your in-house team do this, or will you outsource it? Does the tool do auto-remediation? Do you want this? An expensive alerting tool that nobody looks at is useless.?

11. Employee Awareness and Ownership?

People have mixed views on phishing tests. Insurers expect to see them run at least annually. We invested in a decent awareness tool. I like to validate the utility of our programmes, so we conduct phishing and spear-phishing tests. For the latter, we combined the results with our data on staff training and noted a strong correlation between recent training and correct response to spear-phishing emails.??

A culture where staff take ownership of security is what I aim for, but this is not the work of a moment or ever really finished. It is one presentation, conversation, campaign, report, policy, procedure, and blog at a time. I have found that giving people agency and responsibility has yielded reliable results. I aim to always be a facilitator and to provide guidance as required.??

12. Annual Penetration Testing?

These are worthwhile if you have the authority and capacity to act on the results. We started with annual external penetration tests and have systematically operationalised each element. It is the difference between driving with occasional massive steering corrections as you crash into the barrier, and constant minor tweaks to the steering. We now use our pen testers to help us prioritise and to provide external validation of the work we have done.??

We also ask to receive our results in .csv format up-front. Often by default you will get a lengthy pdf which can be painful export data from to track vulnerabilities. A summary report for the Board or even for external consumption by insurance companies can also be useful.?

Concluding thoughts?

Insurers need to understand your business to provide cost-effective cover. Are you a FTSE 100 finance company, a small non-profit or major education institution? This may not be immediately obvious to the insurers, so it is worth taking the time to educate them about your business and the risks it faces.??

A fantastic way to validate your work across these 12 areas is through external audit. You may need to do this for compliance reasons anyway. By framing your audits around headings like these and working with your auditors to provide a sanitised report suitable for your insurance brokers, you put yourself in a much stronger position at insurance renewal time. Good luck!??

Acknowledgements

The idea for this post came from Risky Business #659 -- Okta and Microsoft meet LAPSUS$ - Risky Business. Around 1:01:00 in Paul Lanzi gives his top 8. These 12 came from further conversations I've had.