[HN Gopher] Cyber Insurance Incident Response: Market tends towa...
___________________________________________________________________
Cyber Insurance Incident Response: Market tends towards
commoditization
Author : EwanToo
Score : 31 points
Date : 2021-07-26 10:34 UTC (12 hours ago)
(HTM) web link (www.cyber-economics.com)
(TXT) w3m dump (www.cyber-economics.com)
| logshipper wrote:
| 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?
| hereforphone wrote:
| 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.
| aenario wrote:
| 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.
| ls612 wrote:
| 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.
| wil421 wrote:
| 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.
| mox1 wrote:
| 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.
| wil421 wrote:
| 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.
| hereforphone wrote:
| I'd argue that a janitor with a TS/SCI + polygraph was
| working in a sensitive position.
| wil421 wrote:
| Tons of stuff isn't TS or even Secret. There are a lot of
| public trust checks with varying degrees of questions.
| ethanbond wrote:
| Pretty sure being able to get through the front gate at many
| government facilities counts as sensitive.
| GartzenDeHaes wrote:
| > 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.
| IG_Semmelweiss wrote:
| 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?
| impostervt wrote:
| 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?
| IG_Semmelweiss wrote:
| 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.
| bladegash wrote:
| 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).
| Arrath wrote:
| 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?
| bhartzer wrote:
| 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?
| bladegash wrote:
| 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.
| tptacek wrote:
| 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.
| bladegash wrote:
| 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.
| tptacek wrote:
| 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. :)
| jon-wood wrote:
| 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.
| mox1 wrote:
| 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 :)
| baxtr wrote:
| 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.
| dd82 wrote:
| 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.
| motohagiography wrote:
| 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.
___________________________________________________________________
(page generated 2021-07-26 23:03 UTC)