Have You Read Your Cyber Insurance Policy?

Every organization should have a cyber insurance policy. It will help you recoup your losses and get back to business after a cyber attack. These policies are increasingly expensive and complex. In the last year or so, I’ve also talked to many technology decision makers who have never read their policy and were not part of the process of applying for insurance. I can’t blame them, a policy can be over 50 pages long. Yeah, this post is just going to be a PSA about your policy and some things you may be required to do.

The sudden move to an online world during the pandemic and the rise of crypto currency only accelerated the upward trend in cybercrime. We’ve shifted from a world where we ask “will I get attacked?” to one of “when will I be attacked?” Most large organizations are attacked daily in one form or another. Just like for other forms of crime, we’ve turned to our insurance companies to help carry the risk for us. As number of cyber claims went up, insurance companies started to do two things: raise rates and deny claims.

Is that unfair? In some cases, probably. But, on the balance, insurance companies have to compete with other insurance companies. They can only get away with so many unfair rate hikes and denied claims before customers flee for competitors. As such, insurance companies will tend to be careful about denials and hikes. Most insurance companies are going to strive to balance profitability with customer satisfaction, so if there is a sudden spike in rates and claim denials, it probably means there is an increase in claims that they need to be able to cover. That’s where insurance companies start looking to manage risk. How are they doing that in cyber insurance? By requiring you to do things to reduce your risk in turn. They add terms into the policy that require you to take responsible measures to protect yourself. They will also ask you during the process of applying for insurance what you are doing to protect yourself. If you aren’t compliant with those terms and aren’t doing the things you said you were doing when you applied, the claim will be denied.

The logical conclusion: if you are not going to comply with those terms, don’t buy a policy.

Does that make you feel uncomfortable? It should. The logical thing to do then is comply with the terms. Are those terms egregious? Unless you’ve got some weirdo policy, they won’t be. When a claim for a cyber attack is filed, the claims adjustor is going to ask the question of whether you did everything you reasonably could to prevent an attack from succeeding. If answer is no, then expect your claim to be denied. If the answer is yes, then you should be able to get your claim paid.

So breathe deeply. You can do this.

First, get your CFO and legal team to share the policy and application documents with the rest of leadership. While I’d probably not share all of the policy with the rest of the organization, I advocate for sharing the list of requirements the policy includes along with the procedures your organization told the insurer that you do when applying. Everyone touching technology in your organization will influence your security posture, so make sure they are looped in. This means your software developers need to be looped in just as much as your email administrators. Your sales team needs to be looped in along with your HR team. A little bit of that knowledge sharing goes a long way towards creating an organization that sees security as a shared responsibility and not just IT being a nuisance.

So what kinds of things will you be expected to do?

You need a written security policy.
You need to set password requirements. I’ve seen requirements that explicitly state things like minimum length and need for special characters in addition to letters and numbers.
You need to use multi-factor authentication. Yeah, it’s 2023 now folks.
Encryption is required for both live data and backups. It also applies to your end user devices.
While we’re on backups, yup, you need ‘em. And remember rule 14: if it isn’t tested, it’s broken. Test your recovery process!
You need an asset management program.
Data destruction policies need to be in place, including document shredding and hard drive destruction/wiping.
Accounts must be promptly deactivated when no longer needed(e.g., when an employee leaves).
Training for users in security awareness is usually a requirement.
Stipulation that you require your vendors to do all of the same and indemnify you if they don’t.
There usually is a statement about needing to follow good practices in general, even when not explicitly mentioned.

That’s just a sample list, but it’s not huge. Sure, if you have an organization that has been around for a while, it can be a pile of work to get it all instituted. However, there is nothing on the list that is a requirement unique to your insurance policy. It’s all good, solid practice and is good start on being more secure as an organization.

Because my focus is on the world of software development, you may ask what else can we be doing as software creators? OWASP, noted for their list of top ten web vulnerabilities, has published their Software Assurance Maturity Model:https://owaspsamm.org/model/. This is a good governance model for software development that covers the whole application lifecycle. Some things to look at:

Establish a governance model to manage risk.
Include security as part of your software development lifecycle, including the design phase.
Train your developers in secure coding practices. Refresh that training at least annually.
Nominate security champions to help raise awareness, help with training, and help with security reviews.
Require code reviews and require them to ask security questions. We all do something stupid from time to time and a second set of eyes can help catch those mistakes. It also helps share knowledge of what the code does.
Engage a third-party to perform regular penetration tests. This should be done at least annually, but the more frequent, the better.
Implement automated security testing and code scanning. There’s a bewildering array of tools out there. Start with infrastructure vulnerability scanners, Software Composition Analysis(SCA), Static Application Security Testing(SAST) and Dynamic Application Security Testing (DAST). Ideally, SCA, SAST, and DAST are part of your regular build process and the infrastructure scanner is always running. Don’t just run the tools, fix the problems they find!
Encrypt everything and make sure you’re using strong encryption algorithms.
1. Except password. Hash passwords, don’t encrypt them. Better yet, don’t store them at all. Use a service like Azure Active Directory, Duende IdentityServer, or Okta to handle authentication. Use a service like HashiVault or Azure Key Vault to store secrets your application needs internally and consider using service principals so that you don’t need passwords to begin with.
2. It’s tempting to use the secrets capabilities your build manager to store passwords and other secrets, but you need to think about where they go when you deploy them. If you put them in a plain text file when deployed, you need to rethink it. Vaults are usually a better option. Secrets in build managers should generally only be used for the things the build and release process needs, not the running application.
Automate your build and release process so that no one needs to manually do anything other than start the process. This includes things like database schema changes, infrastructure changes, and application changes. Reducing the need of adminstrators to manually sign in both reduces the chance of a mistake and reduces the chance of attackers sliding in.
Separation of duties: in sensitive applications, developers should not have production server access. Even admins should need to go through a Privileged Access Workstation(PAW) and/or Privileged Identity Management(PIM) to get to production servers and administration tools. This is a good practice for all applications, but especially for ones with sensitive data or that are mission critical.
Integrate development log with security logs. There’s lots of tools for this now.

That’s a lot and yet I’m just scratching the surface of what I could write down. Just remember that every thing you can point to as a security best practice is something that will help you get your claim paid if you have a cyber attack. It may also help you negotiate with your carrier when you discuss how much your premiums should be if you can find ways to go well beyond “reasonable” precautions. The best insurance policy is one you never have to use and no amount of money can make up for reputational harm and other, less tangible, damages of a cyber incident. Remember: every thing you do to protect yourself is just that: something you are doing to protect yourself. Be safe for you, don’t be safe for your insurance company.