Hacker News new | past | comments | ask | show | jobs | submit login
Insurers balk at paying for some cyberattacks (thebulletin.org)
49 points by pseudolus on April 25, 2019 | hide | past | favorite | 29 comments



I can't fathom insurance companies seriously and sincerely wanting to offer insurance policies for infosec. I know they do. But it doesn't make sense to me.

1. The attack surface for any organization is so hard to defend that insurance companies would probably have to pay out a lot more than for other types of insurance policies.

2. In an age that is increasingly tech and data-driven, the value of data becomes larger and larger. Hence, the payout starts to get really expensive. I find it difficult to imagine what kind of insurance premiums could be charged to customers that are both affordable to the customer and also properly covers the risk the insurer is taking on.

3. Insurance companies are going to have to become infosec experts in order to properly assess the risk of their clients. Are they up for that? There's such a shortage of infosec workers already, or am I being fed a load of crap by HN? Where would they find capable infosec experts to do these assessments before quoting the client for an insurance policy? War for talent isn't easy.

I think this would all end up making insurance policies extremely expensive and unprofitable for the insurance firms. Yes, I hope that this makes organizations more serious about infosec, but I honestly don't see that happening so long as the average joe is not outraged whenever a service they use gets breached.


None of these details really matter for an insurance company. As long as they can accurately keep their total premiums above their total payouts, they'll make a profit.

1. Paying out more is not a problem as long as the premiums are covering it.

2. As payouts start to get expensive, insurers can either raise premiums, or, should the market not tolerate that, they can restrict policy coverage instead.

3. Properly assessing the risk of their _individual_ clients (as opposed to their entire portfolio) will allow them to offer more competitive policies against other insurers. They only need to be as good at that as their competitors, no more.


Three can be addressed by requiring security audits. Historically the Big 4 have done them for SOX compliance or other reasons, but its becoming much more routine for internal purposes. There is no reason it couldn't expand to external users (insurance companies). Many accounting firms are already doing them for hospital boards, etc.

Just like financial audits (or lack thereof) determine your loan rates in a SMB business, a security audit will do likewise.


The mistake you're making is in assuming insurance companies care about the overall risk. They don't. They only care about the risk they're insuring. Insurers very carefully word their policies to limit what they cover - anything outside of that and you won't get a dime. If a company has some holes in its security that's fine, so long as they're also outside of the policy coverage and the insurance company is capable to proving that.

I've never read any of these policies but I'd hazard a guess they all contain blanket statements like "providing reasonable security measures have been taken" without stating what is actually "reasonable". That pushes all the responsibility to the policy holder.


The question of what's covered and what "reasonable" security looks like is the problem for this industry.

If those definition's aren't clear, it'll mean that every major claim becomes a lawsuit, that's not going to help anyone apart from law firms.

Also if a lot of major claims are denied, companies will stop taking out these policies on the grounds that they're worthless.

FWIW my feeling is that Information security of a company is too complex and poorly understood to accurately model risk enough for decent insurance policy to be put in place.


From experience we over-estimate the actuarial competence of insurance companies. In most cases they will trial a new product with premium calculated from incredibly basic stats, see how it goes and then up/reduce the premium as they have more in house data on claims.


Generally these insurance policies have requirements or cluases for things like training staff on good security practices, documenting that this training happened. Helps to lower exposure to lawsuit (ie we weren't negligent). I know of one insurer that requires companies to place a hardware device that blackholes dns in front of the customers network. Things like this really help to lower exposure to attackers. I'm surprised black hole dns isn't more common.


> to properly assess the risk of their clients

I've sat through a lot of these insurance company cyber risks assessments. It's absurd. You get asked a question like "did you pay for a firewall?". Then you say yes. Then you get asked to prove it by showing them an invoice. Repeat the question for antivirus. Throw in password expiry question and boom, you're low risk.


Insurance also creates a moral hazard regarding proper cybersecurity. A risk/reward analysis may arrive to the conclusion that upgrading infrastructure and hiring/training staff will be more expensive than simply paying more for insurance.


That doesn't seem to make sense from the insurer's point of view. If your infrastructure is in a state so bad, then the risk is much higher and they would charge more. There would have to be either some kind of review before signing the paperwork, or the rules would exclude negligence in basic ops.

Similar to how house insurance will ask if all entries have locks and the structure is sound/secure. If they prove it was left open - you're not getting your payout.


I think the insurance company would not accept any claim under these circumstances, for the same reason they do not cover burglary when your house is not properly secured.


I was tasked a couple of years ago with obtaining cyber insurance cover for my previous employer. Their business was an in-house B2B web application, used by hundreds of their staff, thousands of their customers, and hundreds of thousands of their customers' clients.

I looked in to 5 different insurers — these were all major, internationally-recognised financial juggernauts — before abandoning the project entirely.

Every single insurer based their quotation and assessed our risk on some variant of the following: https://i.imgur.com/3pB2LSa.png

I had to go back to each one and ask them:

— How do they define a "record"?

— How do they define "transmitting" a record?

— How do they define "processing" a record?

— Which forms of "encryption-at-rest" do you consider acceptable?

— Which forms of "encryption-in-transit" do you consider acceptable?

— None of our data is "stored" on mobile devices, but it is "accessed" through them — so what does this mean for mobile device encryption?

— None of our data is "stored" on portal storage media as standard, but nothing would stop a user saving a screenshot to their USB stick — so what does this mean for portal storage media encryption?

Not a single insurer had any clue what I was talking about.


You might be interested in https://en.wikipedia.org/wiki/Contra_proferentem

If they drafted the contract and they are ambiguous, legal questions raised later that fall into the ambiguity will generally be resolved in your favor. As long as, for example, you use a generally accepted standard for "encryption-at-rest", you should be fine, legally speaking.

(I am not a lawyer)


From the Wikipedia link you posted:

"The doctrine is not, however, directly applicable to situations where the language at issue is mandated by law, as is often the case with insurance contracts and bills of lading."


To be fair to them, the questions you had are mainly about the minute legal definitions of the text they had written. Our industry is too young to have them defined that well.

On the other hand I think the questions are generally quite concrete and tangent to each other so there’s some clarity to their line of thought.

What makes it a bit funny is the fact that “most probably”, your business loosing your data today has got nothing to do with the fact whether you encrypted it or not at all.


The meta-question they were asking was, "in the event of certain common attacks, will you actually pay out? Or are these definitions constructed deliberately to exclude that?"


Also if the data is always encrypted on user devices like mobiles, then what's the point of having it there at all. At some point the data needs to be decrypted to be used.


The title is an interesting question, and I would recommend "How Everything Became War and the Military Became Everything: Tales from the Pentagon" by Rosa Brooks to dig into this question more.

The basic premise is that our simple "war vs. peacetime" framework no longer works.

Is cyberwarfare war? Maybe, maybe not.

What about one-off drone killings? The US definitely doesn't consider that war. But when you're at peace, killing someone like that is totally not OK.

What about US military involvement in building infrastructure in developing nations? Probably depends on which country it is, and what "infrastructure" means.

I just never really thought about this question much before, and I thought it was a thought-provoking read (spoiler: no answers provided) if you haven't thought about it either.


The framework works just fine. But it is in the warmongers' interest to blur the lines - writing off acts of aggression as not war (yet somehow still not crime) hinders democratic oversight. Meanwhile propagandizing that we're in some continual low level war (just as in 1984) increases their status, lines their pockets, implies a need for wider society to sacrifice, and justifies the use of a massive standing army for mercenary operations.

Framing remote bit twiddling itself as war is frankly ridiculous. Attempted exploits are the Internet's background radiation - its sine qua non is to cross jurisdictions!

If a hacking incident deliberately causes missiles to launch, or disables communication/defenses as a prelude to a physical attack, I'd call that an act of war. Anything short of this overt nature is simply negligence by someone not securing their systems before blithely hooking them up to the Internet, and then looking for an ominous scapegoat after they can't simply bust up some 12 year old's bedroom to soothe their own ego.

I do look forward to seeing if the snake oil industry starts backpeddling on all that state actor saber rattling, now that they will be getting hired to write reports justifying insurance coverage.


Like other aspects of war I think this also depends on variables.

Was it war when German Uboote sank our supply ships enroute to the UK? Not for a while. Was of war when Iran captured US navy seamen in the Arabian gulf?

Is it war when NoKo does the Sony hack? If they start shelling SoKo and they also pull some “cyber” to use military lingo, then it’ll probably be war. In the meantime it’s more like spying/sabotage (which can be part of war, but by themselves aren’t)


>Was of war when Iran captured US navy seamen in the Arabian gulf?

On January 12, 2016, two United States Navy riverine command boats were seized by Iran's Islamic Revolutionary Guard Corps (IRGC) Navy after they entered Iranian territorial waters near Iran's Farsi Island in the Persian Gulf.


The policies in question are not paying were due to NotPetya. The Ukraine and Russia were in an open shooting war, and Russia loaded infected the Ukrainian tax commission's computer. When companies logged in to the Ukrainian computer, they became infected.

Was collateral damage done by this virus to say Maersk (who got the virus from their Ukraine subsidiary) or others an act of war?


A naive, and imo correct, response to this would be, "Has Congress declared war on the nation from which the attackers originated?" This assumes that the attackers were state sponsored.

If the answer to that is no, then if I were in the position to make a decision, i.e. a judge, I would say, "Sorry insurance company, this wasn't an act of war, it happened a year ago and Congress didn't declare war because of this attack; pay up."

That doesn't answer the questions you raised, e.g. is the the peacetime killing of non-combatants illegal, but it answers the question in the article.


So any attacks, including pearl harbor would fall outside the jurisdiction of 'war'. It would also mean that the U.S would likely never truly declare war via Congress since it would annul millions of insurances and would lead to insurance premiums going up to levels never seen before.

Based on this really small sample, would you still follow that rationale?


>It would also mean that the U.S would likely never truly declare war via Congress since it would annul millions of insurances and would lead to insurance premiums going up to levels never seen before.

How does this follow? If Congress declared war against Russia, that would mean that insurance companies could now refuse to pay out for any Russian "cyber attacks", that seems counter to what you just said?

Maybe I'm misreading.


GP already considered something like Pearl Harbor with a 1-year lag for war to be declared, later, in connection with the event.


No. But it can be an "act of war". There is a difference war and an act of war.

An "act of war" or any casus belli doesn't necessarily lead to war. Economic sanctions are "acts of war" but most do no lead to an actual war.


The articles going around about insurers not paying cyber claims that cite Mondelez are disingenuous. The Mondelez policy was a property & casualty (P&C) policy with an extension for some data property, not a separate cyber insurance policy. It's quite possible that insurers would balk at the claim considering it an act of war, but they haven't done it yet. In my opinion, this case is more about the wrong type of coverage. Mondelez should have purchased a stand alone policy.


Surprised it took this long.

Funnily enough it might be what gets the bigger players to wake up and do some basic security.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: