Cyber Insurance Incident Response: Market tends towards commoditization | Hacker News Reader

Cyber Insurance Incident Response: Market tends towards commoditization

cyber-economics.com

36 pointsEwanToo30 comments

Very interesting article. It mainly focuses on what happens after an attack, but I was left wondering - before selling the insurance, does the insurance company require the insured to perform any kind of basic cyber security audit? Are they required to take regular backups, and to test those backups on a regular basis?

I know I can't insure my home if it doesn't meet basic fire-proofing standards. Does cyber security insurance work the same way?

No.

However there will be written requirements into the policy on security expectations.

When the incident happens, there will be a post mortem review of whether the security best practices were implemented and how they contributed or hindered to the incident

The insurer will use that to either deny some coverage, increase premiums or worst case, advice that the policy will not be renewed.

The way requirements are handled is true for small or medium clients. I dont have experience with large firms but i would not expect those clients to be different.

(One does not go about winning business by asking new clients to submit to an audit prior to switching)

That being said, there may be audit requirements at renewals.

As with most things in computer security this is mostly performed as a self-assessment. The insurer will provide a set of questions about things like backup policies, access control, and encryption which you’re expected to answer. Unless it’s a ridiculously valuable policy they’re not going to get pentesters in to verify your answers, in the same way your home insurer doesn’t send someone round to check you really do have smoke detectors and locks on your front door.

It's a "self-assessment" until it comes time to pay the insurance. Then the insurance co pulls out that old file and checks it :)

Depends on the company. Mine (Coalition) does do scanning and ensuring basic metrics and protection are in place. For example, RDP ports must be closed, which is an auto-decline.

The client is given an output of our findings and what would be necessary for us to underwrite the policy.

Any cyber insurance company that does not do this is exposing themselves to outsized risk because they're writing policies based on incomplete data on their exposure.

Naive and perhaps pedantic question from me, does using scanning for monitoring not create an aggregated/correlated re-insurance risk?

It could seem like the PCI/NIST and others are akin to a building's electrical or fire code, which raises all boats, but it also concentrates overall portfolio risk in high-value assets with catastrophic failures. Like saying, "we only insure unsinkable ships certified by Titanic & Co., it's free money." Where instead of Titanic, with cyber the risk is only diversified over configurations of MSFT, AMZN, GOOG products and some linux kernels. Not a criticism, but as a security architect, it's the most interesting set of questions of all.

The insurance incentive to close ports is great, and super positive, perhaps how that risk gets managed on the back end is secret sauce.

There are multiple parts to the underwriting process (full disclosure I run the team that does data collection and security at Coalition where the op you're replying to works). Part of the data we collect is used for risk selection (do we want you on our book?) and then other piece is used for pricing and thats where technologies, providers and a lot of other things come in! Lmk if u have any questions!

Super cool of you to respond. You're solving one of the most interesting problems in security. I worked on a concept for modelling an SPV for an event driven ILS for cyber policies many years ago, and the barrier was the bond modelling people wanted a standardized risk model signed off by a university, which to me seemed like /dev/null for risk, and seemed to miss the point. I'm just excitable about that topic, it's probably not a useful public discussion, I'll certainly keep an eye to what you're doing for my institutional clients. Rooting for you.

I work for a large insurer underwriting cyber.

For large companies the answer is a clear yes. At least we do this. It is not very complicated process, but depending on the IT/OT complexity it might take 1-2 weeks to gather the data since it usually requires the input from many stakeholders within the company.

What I'm always amazed by: companies think protection only when thinking about cyber. But that's not how an insurance thinks about. You have got to take into account what is at stake, too.

I work within this space in terms of performing the actual assessments / audits. It varies based on underwriting insurance provider. Some require compliance with certain standards (e.g., NIST CSF, PCI/DSS, etc.) and evidence of said implementation of security controls (e.g., via an independent third-party assessment).

I've even begun seeing a trend towards tying coverage to use of continuous monitoring platforms, which I see becoming the norm within the next couple of years.

Basically, not only will they want to see where you are at before the policy is underwritten, they also will expect you maintain compliance and they can verify that compliance via CM.

In my opinion, use of CM would actually benefit the customer more than anything, as these policies are written in such a way I am skeptical they'll ever pay out (e.g., 100% compliance with something like NIST CSF is a pipe dream; you will always have some level of implementation snafus and oversights/negligence).

Do any of the audits ever include a risk assessment of the company's domain names and how they're being used? And how they're set up?

It COULD, depending on the standard used and level of risk. If you have a product that is publicly available/accessible and the domain is not using DNSSEC or you're not using TLS/SSL to protect data in transit, you're probably going to get hit.

Or another thing I would look like is the controls that are implemented with the domain registrar itself (e.g., is two factor authentication enabled, principle of least privilege implemented, etc.).

Scoping your information system is one of the most important and difficult parts of cybersecurity. Many would not think that implementation of controls with their domain registrar would be in scope. But if you think of the reality, something like weak authentication in use by a domain registrar or lack of protection of data at rest/in transit is potentially just as risky any other service provider/your internal boundary. This is especially true if your product is quite literally dependent on the domain name resolving properly.

Just a quick reminder that signing zones with DNSSEC is not in fact a security best practice; while there's little practical overlap between DNSSEC and TLS (you need TLS regardless of whether you use DNSSEC), I think it's fair to draw an "or" line between the two, since in fact that's the decision industry has made: near universal adoption of TLS, which eliminates almost the entire problem DNSSEC attempts to address. As a result, almost none of the zones managed by serious security teams are signed.

Hah, that is a great point and unfortunately, there are and will likely always be security control requirements that are no longer considered best practices.

For example, it was fairly recent that NIST updated its guidance on requiring changing of passwords at a defined frequency.

In the case of DNSSEC, it is potentially a relevant and required control under, for example, NIST 800-53, revision 5.1, SC-21 [1]. That's why I mentioned that depending on the standard, it COULD be a requirement.

[1] https://csrc.nist.gov/Projects/risk-management/sp800-53-cont...

Edit: It is also still offered as a potential (arguably secure) practice under NIST SP 800-81-2.

Just for additional context: until around 2016, there was a FedRAMP requirement that services be run on DNSSEC-signed zones. They rescinded that requirement --- they tried mandating DNSSEC and decided, you know what? nah.

Two other big industry-wide things that happened vis a vis DNSSEC:

1. All the mail providers banded together and came up with an alternate SMTP transport security standard, MTA-STS, that says explicitly that it exists because nobody wants to deploy DNSSEC.

2. The DNSSEC people and the browser/TLS people got together and proposed a DNSSEC stapling mechanism as a TLS extension. That stapling --- which Geoff Huston once wrote was an existentially important feature for DNSSEC, since DNSSEC queries routinely fail when made behind random CPE equipment that won't forward weird-looking DNS messages --- failed and was withdrawn.

There are basically no positive signals with respect to DNSSEC deployment. We're belaboring it; your comment isn't really about DNSSEC. I'm just saying: even if you're very, very diligent about security, it's unlikely that DNSSEC would be a high priority item. :)

Hah, you are definitely right and I agree with you there =). Thanks for the comment and have a great deal of respect for you!

Purely from the outside looking in so this may be a naive question: what are the chances for a mandated continuous monitoring system to actually provide more attack surface ala Solarwinds?

Hi, person responsible for the teams that do this at Coalition! Anytime you get a quote from us, we scan all your domains, subdomains and ip addresses. We hit the main ports that might have services running we know are dangerous and your quote might come back contingent on certain actions, for example: if you have Admin panels exposed to the internet we will require that you put them behind a VPN. We give you a PDF that describes all our findings and how we did the association with your org. If you become a policyholder we offer perimeter scanning and notify you when we find weird stuff and make security experts available at no cost to help you fix things! You can read more about it here https://www.coalitioninc.com/blog/analyzing-policyholders-te... though what we do at underwriting time has substantially evolved since. Ask me anything here or on twitter @balgan

Great article. One takeaway from this is pretty straightforward: as a startup, this is strong evidence to invest in cyber coverage specifically with those top carriers.

One of the shortcomings of the article though, is that they don't address the price effect:

has the grouping of IR led to cheaper premiums with top carriers?

Are top carrier cyber policies effectively a "better deal" as a result of this gating?

Or is the margin even justified given the commoditization that is taking place at the top firms?

As has been said on here many times, the problem is with a lack of accountability. My information was stolen as part of the OPM hack. No one has taken my identity yet, but various nations no doubt know that I used to work in sensitive positions, and pretty much all my private information.

You know what the government did about this? They gave me free credit monitoring for a certain number of years. Enough critical information / infrastructure is online that heads should roll with each major breach.

There is apathy toward security on a large scale. There is apathy toward identity thievery. I grew out of the "death to capitalism" stage of my life decades ago but in this case it is obvious that money is protecting the big players.

Would they really know if you were truly in a sensitive positions? I’m sure janitors, food service workers, and front desk people went through the OPM process. There are probably a lot of people working in government buildings that don’t even use a computer.

The SF-86 is an incredibly detailed document. I would agree they aren't after low level people in sensitive positions.

But that document lists family members, past residences, perhaps previous crimes, etc.

Its the same document from high level people down to the janitor.

Its extremely useful from an intelligence perspective. Allows you to connect A LOT of dots.

Yea unfortunately I know how detailed the SF-85 is. Luckily it was a public trust specifically for IT stuff not the full blown one but I think the only difference was it looked at 7 year history vs lifetime.

I'd argue that a janitor with a TS/SCI + polygraph was working in a sensitive position.

Tons of stuff isn’t TS or even Secret. There are a lot of public trust checks with varying degrees of questions.

Pretty sure being able to get through the front gate at many government facilities counts as sensitive.

The very notion of identity thievery is "BigMoney" (banks and credit rating) putting on their customer the responsiblity of what we used to call fraud.

But the customer is basically never actually responsible for fake debts and accounts opened in their name. By law and practice the banks end up eating almost all of that cost. So this whole idea seems somewhat questionable to me despite being a popular meme on HN.

> that heads should roll with each major breach

It's not uncommon for government agencies to put their security manager in an at-will position for precisely this purpose. In other words, they have hired people for the purpose of having heads available to be cut so the people with authority are not at risk.

Quite an interesting article!

I am curious as to how this "limited collection" of IR firms adds to or drains from the overall security ecosystem.

On one hand, having a limited number of firms allows for seamless knowledge transfer, and upholds a somewhat high standard of service - kind of like a licensing regime.

On the other hand, I wonder if this cartel limits innovation and keeps new entrants with new ideas and better service from entering the fray.

Maybe its a bit of both?

Reply on news.ycombinator.com