Looking for a temperature/gut check and maybe life advice

[Al3x Lee]

Perfect, thanks! It'll be here Thurs.

Personally, that's not far from my original idea, especially if he tells them they'll need things like a formal annual employee training program, ongoing vulnerability scanning, audit logging, 24/7/365 monitoring and alerting, an IDS/SIEM solution, a written Incident Response Plan, a Patch Management program, etc, etc, etc.

I think the "Insurance Consultant" license (whatever that means) sounds closest to my original intention, which was to walk the business owner through that process without getting in trouble for giving unlicensed (and/or terrible) insurance advice.

It seems that I mostly want to be a MSP/MSSP and probably not sell insurance on the side. I've been working for startups just as they start to scale, spend a year or two there, then they sell or merge with someone else. I've been through I think seven M&A deals since 2017 (another niche I'm pursuing) and it'd be cool to do all of the architecture analysis stuff without the layoffs part.

Who on the insurance side does <technical stuff>, like deciding what's acceptable and what's not? Is it basically a predefined list of major vendors, or does there exist a long process of reviewing network topologies, software versions, firewall rules, password policies, logging configurations, etc., like with other regulatory environments? (Becoming GDPR compliant, for example, was easily a 5-figure process and large companies spent millions.)

At the risk of making another bad analogy, perhaps I'm thinking along a boat surveyor or home inspection kind of line.

The book is a pretty dry read, but it's certainly insightful and will give you a good idea of what you're diving into.

I think going to larger businesses and helping them get in compliance and set up proper controls for their insurance broker is more in your wheelhouse from what you've described. Maybe you can partner with an agent who is pursuing the companies you want to consult for. It would be a win/win, he sets up the insurance, and you help them get all of the proper controls in place. - There's probably more money on the consulting side anyhow.

In terms of who does the technical stuff on the insurance side, it can vary greatly. There's the technical of insurance - actuaries, claims adjusters, product and claims counsel (attorneys), underwriting, policy language, etc etc. Then there's the cybersecurity technical side, which many cyber insurers are bringing in-house. The insurance companies will hire dedicated cybersecurity experts to handle the technicalities associated with that side of their business. Go poke around on LinkedIn and you'll have a pretty good idea of their employee structure.

Some examples:
https://www.coalitioninc.com/coalition-security-services
https://www.at-bay.com/security/

The insurers are not going to take great leaps to get a company's cyber risk management up to snuff or be compliant with regulations like GDPR, so there is definitely the opportunity to step into that gap and help those companies out.

 

[Al3x Lee]

I am a successful commercial broker by pretty much any measure, and I have no idea what DevSecOps is. At first I thought it was some sort of covert military division.

It's like a IndInsAge, except you have to work and compete less for the piles of money thrown at you. Downside - You sit at a computer all day and get fat... wait... that last part sounds a lot like insurance

 

[cwm5]

I am a successful commercial broker by pretty much any measure, and I have no idea what DevSecOps is. At first I thought it was some sort of covert military division.

The best answer is probably that nobody really knows what Dev[Sec]Ops is (it's a buzzword); another makes use of covert military references ad nauseam. Personally, I just recycle a complaint from another department: "DevOps is taking a week to automate what I could have just done myself in an afternoon!"

In the criminal justice system, there are the police who investigate crimes, and the district attorneys who prosecute the offenders. In software, there are Developers who write the code and system administrators (Operations) who "operate" (configure, deploy, monitor, etc) it.

Originally, DevOps was a methodology/framework/philosophy/whatever (similar to Six Sigma/Agile/etc) that declared the left hand (Dev) should know what the right hand (Ops) was doing, and that Ops people should know how to write code so they can automate the Operations.

Minds were blown. Numbers went up. Other numbers went down. Suddenly, everyone needed to "hire a devops".

After automating our own jobs for a bit, we now call it DevSecOps (Continuously integrating Security at all stages of the lifecycle!™, you see) or Platform Engineering or whatever.

In practice, at startups, it means I'm the senior generalist who handles most things that aren't the app developers' job, the CTO/Engineering Manager's job, or involving the printers/employee laptops. Sometimes, they let me out of the basement to meet with other departments for things like researching cyber insurance or going back and forth with Legal and Product about how to word RFP responses.

 

[cwm5]

I think going to larger businesses and helping them get in compliance and set up proper controls for their insurance broker is more in your wheelhouse from what you've described. Maybe you can partner with an agent who is pursuing the companies you want to consult for. It would be a win/win, he sets up the insurance, and you help them get all of the proper controls in place. - There's probably more money on the consulting side anyhow.

This was the original motivation, plus understanding "proper controls" as their insurance defines them. Ideally, it'd be a package/repeatable process, or an automated set of tools.

> [From the NAIC report] Changes regarding risk factors are occurring in the underwriting process. Underwriters are starting to use tools to evaluate prospective insureds' computer networks to decide whether they will write the cyber business.

Which is not indifferent from what I'm developing, except I'm reporting concrete findings ("Port X is open on Server A") to IT/business decision-makers, vs (presumably) applying actuarial data to those findings to calculate some kind of risk score. I wonder if anyone's doing a DriveWise-esque thing, since many of the scanners require an agent on the system anyway.

ETA: Ha, Coalition and At Bay seem to be basically what I had in mind (on one level, anyway)

 

[Al3x Lee]

This was the original motivation, plus understanding "proper controls" as their insurance defines them. Ideally, it'd be a package/repeatable process, or an automated set of tools.

> [From the NAIC report] Changes regarding risk factors are occurring in the underwriting process. Underwriters are starting to use tools to evaluate prospective insureds' computer networks to decide whether they will write the cyber business.

Which is not indifferent from what I'm developing, except I'm reporting concrete findings ("Port X is open on Server A") to IT/business decision-makers, vs (presumably) applying actuarial data to those findings to calculate some kind of risk score. I wonder if anyone's doing a DriveWise-esque thing, since many of the scanners require an agent on the system anyway.

ETA: Ha, Coalition and At Bay seem to be basically what I had in mind (on one level, anyway)

I believe that forming a partnership with an independent insurance agent or broker who's knowledgeable in cyber could be a good move for you. One significant aspect of this opportunity is a challenge that I've noticed insurance carriers haven't adequately addressed. While these carriers can advise insured individuals and agents on the necessary risk controls, they often fall short in providing clear guidance on how to implement them effectively.

To illustrate, let's take the examples of Coalition and At Bay. They call themselves "Active Cyber Insurance", which means if they identify a vulnerability they're concerned about, they promptly inform both the agent and the insured party. However, the notification most often comes from their cyber security department, usually a cyber analyst, so their explanations can be somewhat vague, and this notification may occur during the middle of the policy term. There seems to be a disconnect between the insurance and "active security" side of their business. I imagine the insurance people know the insurance side very well, and the cybersecurity people know that side very well, but there seems to be a silo between those two sides.

Here's an example from my office: Another agent had a client who used a managed IT service provider for email services. At some point during the policy term, an At Bay cybersecurity analyst discovered that the client's email system was running on an older version of Microsoft Exchange, which had known security weaknesses. Unfortunately, the analyst's guidance on how to address this issue was quite unclear, essentially stating, "You need a newer version of Microsoft Exchange." with a vague set of technical instructions. Neither the agent nor the insured was familiar with Microsoft Exchange. Luckily, I was, so I was able to send the notification to his third-party service provider. Had I not done that, or if the service provider had not implemented the update, the policy would have non-renewed.

 

[cwm5]

I believe that forming a partnership with an independent insurance agent or broker who's knowledgeable in cyber could be a good move for you. One significant aspect of this opportunity is a challenge that I've noticed insurance carriers haven't adequately addressed. While these carriers can advise insured individuals and agents on the necessary risk controls, they often fall short in providing clear guidance on how to implement them effectively.

To illustrate, let's take the examples of Coalition and At Bay. They call themselves "Active Cyber Insurance", which means if they identify a vulnerability they're concerned about, they promptly inform both the agent and the insured party. However, the notification most often comes from their cyber security department, usually a cyber analyst, so their explanations can be somewhat vague, and this notification may occur during the middle of the policy term. There seems to be a disconnect between the insurance and "active security" side of their business. I imagine the insurance people know the insurance side very well, and the cybersecurity people know that side very well, but there seems to be a silo between those two sides.

Here's an example from my office: Another agent had a client who used a managed IT service provider for email services. At some point during the policy term, an At Bay cybersecurity analyst discovered that the client's email system was running on an older version of Microsoft Exchange, which had known security weaknesses. Unfortunately, the analyst's guidance on how to address this issue was quite unclear, essentially stating, "You need a newer version of Microsoft Exchange." Neither the agent nor the insured was familiar with Microsoft Exchange, so it likely would have just gone to non-renewal had I not intervened. Scenarios play out like this every single day.

This is what I've observed from the IT side as well, mostly because we use slightly different language. I might suggest another "silo" between the NOC/SOC analyst who escalates the alert and the people who implement the fix.

The update thing is a good example. Many of these automated scanners are based on public datasets (e.g., CVEs) or industry benchmarks, and the results are pretty noisy and generic.

Some of those updates won't be "fixed in package" for a while (days/weeks/months/years even). Sometimes a fix is available in a "nightly" or "pre-release" or "alpha" channel, but that is not without risk - and frequently, the risk of updating to bleeding-edge software introduces more problems than the perhaps-hypothetical vulnerability anyway.

Complaining about having public access enabled on a public-facing website is silly, but the tool sees that it's public (and public S3 buckets are bad). Solution: deal with it or silence the alarm. No mechanism for adding a note that this website *should* be accessible to the public.

Sometimes the security issue is only hypothetical, or not really applicable to the environment, like websites being open to the public or cars in Arizona falling into the ocean. Practically, it's just a non-issue. ("But that car *could* fit into the ocean!")

> There seems to be a disconnect between the insurance and "active security" side of their business.

This seems like some kind of Hegelian dialectic whereby one half of their business says "you need to keep your systems updated" while the other half says "your systems are not entirely up-to-date" to almost force them to move to SaaS/PaaS or hire a security team.

As I see insurance pushing adoption of these kinds of tools, the emergence of CyberScores, and so on, I do worry about more of these Exchange-type scenarios popping up. It has the potential to be a really frustrating experience, perhaps even distracting staff from actual risk management to checking boxes and silencing alarms. The "CyberScore" concept could be a plus here, if there's no issue as long as the needle stays in the green.

When you say it might have gone into non-renewal without intervention, what was that like? Is there any kind of grace period, timeline, or consideration of the overall setup? Or is it more "red light is on and we cannot insure anyone when the light is red"?

 

[Al3x Lee]

Sometimes the security issue is only hypothetical, or not really applicable to the environment, like websites being open to the public or cars in Arizona falling into the ocean. Practically, it's just a non-issue. ("But that car *could* fit into the ocean!")

As I see insurance pushing adoption of these kinds of tools, the emergence of CyberScores, and so on, I do worry about more of these Exchange-type scenarios popping up. It has the potential to be a really frustrating experience, perhaps even distracting staff from actual risk management to checking boxes and silencing alarms. The "CyberScore" concept could be a plus here, if there's no issue as long as the needle stays in the green.

Yep, you make some solid points. There's a quote I like : "The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts. "

Yet we all walk around with cell phones and have smart cars, smart homes etc. There's a level of risk that people are willing to endure. Unfortunately for businesses, a breach creates a much higher cost, which hurts the insurer's loss ratios greatly. It only takes so many large ransomware events before an insurer decides to just walk away from that line of business entirely.

When you say it might have gone into non-renewal without intervention, what was that like? Is there any kind of grace period, timeline, or consideration of the overall setup? Or is it more "red light is on and we cannot insure anyone when the light is red"?

There is no grace period, the notification was sent 90 days prior to renewal. The insured and agent were advised that the policy would be non-renewed if the issue wasn't fixed prior to the renewal date. In this scenario, yes, the red light is on, no renewal policy.

Here is what the notice and guide looked like in that scenario




Guide that was provided to customer: [EXTERNAL LINK] - Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server | MSRC Blog | Microsoft Security Response Center

We'll survey the forums @Markthebroker @marindependent @adjusterjack , does the info in the link above make any sense to you fellas?

 

[cwm5]

> Unfortunately for businesses, a breach creates a much higher cost, which hurts the insurer's loss ratios greatly.

I noticed when I was looking at online estimators that the limits for the policy were like "250,000 / 250,000", "1,000,000/1,000,000", whereas I'm used to seeing "n / 2n" or something, so it looks like you really only get one screw-up?

> There is no grace period, the notification was sent 90 days prior to renewal. The insured and agent were advised that the policy would be non-renewed if the issue wasn't fixed prior to the renewal date. In this scenario, yes, the red light is on, no renewal policy.

Looking at the CVE in question, it was reported Sept 8 (which scanners should have picked up that day), but no solid fix introduced until Nov 22. Since scanners usually just check version strings, they likely wouldn't detect the temporary mitigations and the light would stay red until after Nov 22 release, even if you took the Microsoft-recommended steps on Sept 8 or 9.

Suppose I do the two fixes outlined there on Sept 8, but I still have a vulnerable version of Exchange running, and the org has an incident in mid-September where someone clicked on a link in their email (would have happened even with a post-November version of the email server). Do they risk the contract becoming void, or a claim getting denied or something, because their system "wasn't up to date"?

Was this a 90d warning, or did the Sept 8/Nov 22 date happen to occur just before their policy renewed? Put another way: if it happened a week into their policy, would they still have a whole year to fix it, or does this come with a "you have 90 days to get back in compliance with the terms or we're not covering you"?

Any idea how a traditional company (who's not actively monitoring their customers systems) might respond to running yesterday's version of Exchange, or is that policy/carrier-specific?

 

[Al3x Lee]

> Unfortunately for businesses, a breach creates a much higher cost, which hurts the insurer's loss ratios greatly.

I noticed when I was looking at online estimators that the limits for the policy were like "250,000 / 250,000", "1,000,000/1,000,000", whereas I'm used to seeing "n / 2n" or something, so it looks like you really only get one screw-up?

It depends, but if your company is cyber risk heavy and don't take the risk management seriously, then on a big claim, yes, they probably only get one.

Looking at the CVE in question, it was reported Sept 8 (which scanners should have picked up that day), but no solid fix introduced until Nov 22. Since scanners usually just check version strings, they likely wouldn't detect the temporary mitigations and the light would stay red until after Nov 22 release, even if you took the Microsoft-recommended steps on Sept 8 or 9.

Suppose I do the two fixes outlined there on Sept 8, but I still have a vulnerable version of Exchange running, and the org has an incident in mid-September where someone clicked on a link in their email (would have happened even with a post-November version of the email server). Do they risk the contract becoming void, or a claim getting denied or something, because their system "wasn't up to date"?

I looked at the notes in this scenario, they received notice on 10/6 and the provider was able to patch it on 11/4. I don't know the specifics beyond that though, I wasn't directly involved, not my account.

In terms of the contract being void, they would probably be fine in that scenario, since the policy was still in force, had their original application been accurate. The accuracy of cyber applications at the time of signature and submission to the insurance carrier is paramount. If you check that you have MFA on all systems, and you're only running it on email, then one of your non-email systems gets breached, you're not going to have coverage. In that example, saying all systems have MFA is a risk mitigation warranty to the insurance carrier, much like saying you have sprinklers in your building.

Since you mentioned Travelers, there was a court case on this exact scenario recently:
[EXTERNAL LINK] - Travelers, Policyholder Agree to Void Current Cyber Policy
[EXTERNAL LINK] - The Impact of Travelers v. ICS for Cyber Insurance Brokers.

Was this a 90d warning, or did the Sept 8/Nov 22 date happen to occur just before their policy renewed? Put another way: if it happened a week into their policy, would they still have a whole year to fix it, or does this come with a "you have 90 days to get back in compliance with the terms or we're not covering you"?

It probably depends on the vulnerability and the policy conditions. I don't know if I could give you a blanket answer for every scenario. In this case, it was close enough to renewal that the insurer gave them a window to get it done prior to renewal.

Any idea how a traditional company (who's not actively monitoring their customers systems) might respond to running yesterday's version of Exchange, or is that policy/carrier-specific?

Insurance carriers vary widely in how they handle cyber coverage. Some could care less and offer cyber as a sublimit endorsement on a commercial package policy or BOP. Other carriers might require a long application and warranty process and extend limits up to $10M and beyond, with no further monitoring throughout the year. It really does vary by carrier.

For example, AdjusterJack mentioned The Hartford in his list of big cyber insurers. As far as I know, most of Hartford's cyber premium comes from their package and BOP policies, they're not out there slinging monoline cyber policies, yet they have a large portion of market share due to the many small cyber endorsements they carry on their book of business.

 

[cwm5]

I looked at the notes in this scenario, they received notice on 10/6 and the provider was able to patch it on 11/4. I don't know the specifics beyond that though, I wasn't directly involved, not my account. ... In this case, it was close enough to renewal that the insurer gave them a window to get it done prior to renewal.

Word. That seems like a pretty reasonable timeline from my experience, though I know some orgs wouldn't be happy waiting a month between CVE disclosure and notification.

Assuming a traditional insurer (wasn't their fault notification was delayed), if the insured had an incident on 10/1, would it likely have been covered, rejected because they exploited a month-old vulnerability, or require a judge or something to figure out?

I guess I'm used to many of these factors being fairly obvious from police reports. Had right-of-way per the cop? Covered. Left on red while drunk? Not covered.

An IBM report talks about the cost impact of involving law enforcement in ransomware, and I've read that cyber can cover costs related to forensics - but is there any routine "we need a copy of the police report" kind of requirement for filing a claim?

The accuracy of cyber applications at the time of signature and submission to the insurance carrier is paramount. ... saying all systems have MFA is a risk mitigation warranty to the insurance carrier, much like saying you have sprinklers in your building.

I guess that's what I'm getting at - things could be 100% at the time it was signed, but someone in Marketing signs up for a new email marketing tool, and it's no longer true.

I guess I'm thinking back to various situations at non-tech companies where people did something innocent like move a piece of equipment or prop a door open and got scolded with something like "I know it's BS, but our insurance said so".

Or a months-long back-and-forth between a few guys in a volunteer org (who were all insurance/financial advisors at their real jobs) about whether we had to hire a professional snow removal company or if the volunteer with a landscaping company could swing by in the morning on his usual route (as he offered to do). He's not covered under WC in his own truck! He is if he signs in briefly! Doesn't he have his own WC? But then he's a different class of employee if this is outside his volunteer duties! Let's just pay him then! He can't volunteer AND work here! Is it his truck, or his company's? etc, etc, etc.

Maybe that's why I overthink this stuff haha

Since you mentioned Travelers, there was a court case on this exact scenario recently:
[EXTERNAL LINK] - Travelers, Policyholder Agree to Void Current Cyber Policy
[EXTERNAL LINK] - The Impact of Travelers v. ICS for Cyber Insurance Brokers.

Interesting. It seems this might be a major contributor to any "insurance companies are suddenly asking more questions" trend?

Insurance carriers vary widely in how they handle cyber coverage. Some could care less and offer cyber as a sublimit endorsement on a commercial package policy or BOP. Other carriers might require a long application and warranty process and extend limits up to $10M and beyond, with no further monitoring throughout the year. It really does vary by carrier.

Is there any public information on the application/warranty process, or insight on how they arrive at the requirements/questions they do? I assume some high-level guidance comes from govt/[tech]industry, but would it be NAIC or maybe some underwriters' association who has better insurance industry research/reports/guidelines? (Found this linked in the NAIC report)