It's paramount to craft and uphold a cybersecurity program, adequately tailored to meet your organization's distinct needs.
This encompasses the critical responsibility of protecting your business against cyber threats and building a fortified reputation that not only reassures your board members but also instills trust in prospective clients and insurers.
Join Victor Marchetto, Manager of Advisory Services, to refine your strategy:
- Streamline Security Questionnaire Responses: Accelerate your response time to security questionnaires through efficient, standardized processes.
- Cultivate Cross-Functional Collaboration: Enhance interdepartmental trust and establish definitive goals for your cybersecurity program to ensure unified effort and clarity.
- Optimize Cyber Insurance Renewals: Bolster your negotiating stance during cyber liability insurance policy renewals with a robust and demonstrable security posture
Transcript
Jack Ekolof:
Today we're presenting on the topic of the preventative security program review — protective measures to shield your business. Presenting is Victor Marchetto, our Manager of Advisory Services here at Evolve. Victor joined in 2022, and previously spent nine years on the CDW cybersecurity practice. He's published malware analysis on cryptojacking and a number of different variants. We're very excited to have him here today presenting on improving your security program and ways of communicating that within the business. With that, we'll hand things off to Victor.
Victor Marchetto:
Thanks, Jack. I'm super happy to be here with you all. If you feel inclined, leave some comments in the chat — for instance, if you find yourself inundated with annual insurance questionnaires or third-party vendor risk questionnaires from your clients, if you're wearing too many hats these days, or if you're generally losing sleep over how to address the ever-changing threats we see. It's a loaded question — I know that's what everyone's dealing with, and the frequency of some of these things has increased, which makes you wonder what's really happening out there.
There are three main points I'd highlight. First, the attacks are ever-increasing. We had a record 880,000 complaints to the FBI's IC3 (Internet Crime Complaint Center) — cybercrime complaints — but that's just the people who file one; I imagine the number of people affected is much higher, and that's just in the US. Within that, you see about an 18% increase in ransomware in particular. Second, our systems are becoming ever more complex and less transparent. The days of everything being on-prem, where you can put your arms around all of your infrastructure, are gone. Everyone's in some hybrid or cloud-centric state; everything is a SaaS-based solution provided from somewhere else, made up of multiple partner organizations. And third, there's just more information about what's happening in our environments — the data we deal with, the data our partners provide, the data our clients work with.
The threat landscape is vast. This information is from Mandiant's reports, which they put out every year — they're one of the best out there in threat research — and they're tracking at least 4,000-plus groups. Not that I'm suggesting anyone start a life of crime, but the risk of stealing information or assets of value in person is much higher than doing it over the internet, and the cost to engage in that activity is pretty low. So you see a huge number of financially motivated threat actors, and — obviously fewer, but way more funded — advanced persistent threats, some of which are attached to different state actors, if you were to guess. By and large, people commit these crimes for financial gain, and that makes sense: it's a lot less risky to steal at a distance than to do it in person.
The complexity of our environments is ever-increasing, and it's harder to keep a tight lid on all the different aspects of the systems we use. On tooling improvements — it seems like you can't go five minutes these days without talking about AI in some capacity, and it's having an interesting effect on this industry. The social-engineering improvements threat actors can use have been significant. Social engineering has always been one of the easier ways to get initial compromise, because every system has people in it, and people are susceptible to the same types of scams. But now threat actors can reliably create phishing campaigns in the language of their targets — so if they don't speak the target's language, LLMs weed out what used to be reliable tells like bad grammar or typos. There's also the ability to create audio and video deepfakes. It takes a bit more work and planning, but they're able to get pretty convincing results.
Our offensive security team here at Evolve Security uses these techniques for our phishing campaigns. You only need a handful of minutes with somebody — if you can get them on the phone and record their voice — to create a reasonably reliable simulation of your target's voice, which is useful for impersonating people. I don't know if anyone's seen the case where a "CEO" reached out to someone in the finance department and asked them to wire a bunch of money. The employee said, "This isn't typical for us — wiring money to an account I'm not aware of. Can we get on a Zoom call to talk about it?" So they do, and the employee invites a bunch of coworkers to validate the message — and everybody in that meeting was a deepfake, simulated to give the appearance this was sanctioned. And there goes however many millions of dollars.
On the other side, we're seeing interesting developments in the automation of these attacks. Researchers at the University of Illinois were able to use a GPT-4-based agent to run and exploit commonly known vulnerabilities it uncovers, at roughly an 87% success rate depending on the machines they sampled — and they estimated a cost of around $8 to $9 per exploit. As this technology improves, it may change the frequency of opportunistic attacks, because threat actors can automate and lower the interest threshold. If you don't have to attempt to exploit all these vulnerabilities yourself — you can just feed it to an LLM or AI agent to run — then organizations you wouldn't have gone after before become more attractive, because it's just cheaper to target them.
Let me pull out my crystal ball and give you a couple of insights into what I see ahead. Currently, when people think about cybersecurity, they think predominantly about protecting their environments, data, employees, and customers from ransomware and malware outbreaks. That's still going to be a main part of the mission. But beyond the prevention of threats, I think security is going to become more and more a part of the sales process — the way you acquire new customers. If data is the new oil, the new gold, your customers and partner organizations are going to want to know how you'll protect it, what you'll do with it, and how risky it is to do business with you. So your security program becomes part of demonstrating externally how resilient you are and that you have a plan for these threats.
Given the average cost of a data breach is somewhere around $10 million — and that fluctuates depending on which reports you read and how you consider impact — cybersecurity liability insurance is going to be an important part of your strategy. The ability to transfer some of those costs (maybe not all — some, like brand damage, fines, and fees, are hard to measure) to an insurance agency is very attractive. But the insurance agencies are getting smarter; they've had to, given the claims they've paid out relative to the policies they underwrote five years ago. They'll keep getting smarter about what risky organizations look like, ask more complicated questionnaires, and impose a more arduous application process, so they can narrow the threshold of what they will and won't cover.
In the future, I could see something like the telematics "safe driving" modules that auto insurers use today to give favorable rates to safe drivers. Insurers might build in similar monitors under the same guise — so if they see that 30% of your employees didn't complete their security awareness training this year and then you got breached, they might say, "You're not doing what you said you'd do, or what we recommended, so we're not going to pay out as much." I foresee them building the infrastructure to pull those levers.
Ultimately, we have to ask ourselves what we can do. The threats are going to increase and become more complex; our environments are as complex as they are and won't get any simpler; and our customers want more clarity on how we're solving these problems. If we want to transfer some of this risk, there's homework to do. What can we do? We can take a proactive approach. A reactive approach won't work — there'll never be enough time in the day to think through these problems; they're too big to not take a process and work through it.
We have to establish a baseline: figure out what we're currently doing and how our organization is currently protected. We can use lots of different frameworks for this — the NIST Cybersecurity Framework, ISO 27001/27002, SOC 2, or the CIS framework. Ultimately these frameworks are the blueprint for building a good house — a good cybersecurity program.
If we look at this circle, it identifies the six domains, or functions, of a well-designed cybersecurity program, from the NIST Cybersecurity Framework. Every program needs to do six things. It needs to identify the assets — hardware, software, and data — that matter to the organization. It needs to protect those things based on their sensitivity and criticality — things like antivirus, network protections, access control lists, and DLP (data loss prevention) — to prevent the majority of things that could occur. But you also have to detect when those preventions have failed, and you need a plan — and you need to practice that plan — to respond when that happens. You need to be able to recover from whatever incidents occur. And, new with this framework in particular, you need to govern the whole process, making sure all the functions work seamlessly together. Those are the building blocks of a good program. When establishing our baseline, we go through and understand how we're doing each function — and there's a whole series of sub-functions where we get into the details of whether a given practice is present or not.
After we figure out what we're doing today, we have to figure out what we should be doing — measuring against the threats out there. Is what we're doing enough to protect us against what's likely to happen? Your business gets to determine what's "too likely" for you all to collectively sleep at night, and ultimately the business has to decide what's too much and what it can spend. But that decision needs to be informed by security, and communicated to different business units in their respective languages, so the whole organization can figure out how stringent or expansive its security program needs to be.
So, on the whole, we figure out what we're doing, then make sure it's enough based on what we're at risk of. But practically, how do we do that? I'll give you a five-step process.
First and foremost, pick a framework. There are reasons to pick one over another: How big is your security team? What regulations are you held to? What do your customers care about? This framework is useful to proactively assess your position and look for improvements, but it's also a means of communicating internally and externally about the program you're building. If you have a smaller team, you might look to a simpler framework like CIS. If you have international business, a US civilian agency's framework like NIST may not hold the most weight internationally. Remember that the framework you choose helps you get to the next level of maturity — you can crosswalk and translate to other frameworks or adopt different ones as you go, so the progress is never really lost.
Jack Ekolof:
From your perspective, what's the most fun one to work on? Which do you enjoy working on, and which do clients like engaging on?
Victor Marchetto:
It depends. For a lot of my organizations that are just adopting one, I like the CIS framework, because it's fairly cut and dry — it's nice to be able to say yes or no to something. The NIST and ISO frameworks are a bit more vague, which is great if you already have an approach, because you can justify why you meet the spirit of the law. But for organizations just getting started, they can be too vague to wrap your hands around. So generally I like CIS for how it lets you go from talking about getting started to actually getting started — it's a quicker, smaller runway.
Once we've picked a framework, we perform an assessment against it. We could do that for you at Evolve Security, or you could self-administer it. In this process, you and your team go through the controls of the framework — each will say, for example, "You must have an inventory of all your hardware assets." Do we do that or not? Not every question has a definitive answer, but if you can't even speak to how a practice is being done — say, in application software security or DevOps, handled by an IT team you're part of or a separate department — you should pull those folks in to help get answers. Cybersecurity is ultimately a team sport; the more people who provide insight into what's actually happening today, the clearer your decisions become.
So we've picked a framework, performed an assessment, and figured out what we're doing and what we aren't. Now, step three: review those gaps against your risk appetite. Which domains hold the most gaps? Consider the type of data you work with and the services you provide — what are the most critical aspects of your organization, and are there intersections with the gaps we've identified? Consider the threat actors out there: what do they want, and what tactics do they use? Resources for finding those cross-sections include the MITRE ATT&CK framework, threat intelligence feeds you can buy, and information-sharing committees you can join in your industry or locality — those are super useful for hearing how other organizations solve these problems and what they're being hit with. So there are lots of ways to get a sense of what to worry about, and at step three we look at the gaps we've captured against the things we're most worried about, and where they meet, to make a short list.
Step four: build the roadmap. Now that we have a sense of what we could be doing better against the threats we're worried about, we build a list based on criteria like: How big is the team? How much can you digest right now? What's the team's expertise — is this something you can do in-house depending on the gaps, or something you have to contract for? How severe is it — do we have to deal with it right now, or can we push it out over the next couple of quarters? And what's the cost, and who will we work with?
Step five is, obviously, the easiest one — we just execute on the plan and track the progress. I'm not going to lie: that's probably the hardest part. The easiest part is finding out what we need to work on. So it's not a breeze, but with a systematic approach, you can chew on the important things first. It's easier to articulate to the organization why we're doing one thing over another, because it has context — the framework and process help explain why these things are more critical than others, based on the data they interact with or the services they support. It's much easier to continuously improve with a process like this than to just react to things coming in the door, contractual agreements, or vendor risk questionnaires.
All these frameworks have elements valuable to answering the problems we started with. The advisory practice at Evolve Security can help you through a significant portion of this process. We can help you select a framework, perform assessments and risk assessments, distill what the gaps are, recommend next steps, and build roadmaps. And if there's an audit you're seeking — like a SOC 2 audit or another cybersecurity audit — we can help prepare you. There's a broad range of ways we can help, because you don't have to do this alone. Everyone wears too many hats, and having outside assistance to distill and build out the roadmap with your insight can make the whole process a lot simpler.
When you externalize it to a third party like Evolve Security, we can help from an ad hoc perspective to support individual projects. We can build policies you may be lacking — a lot of organizations I talk to lack an incident response policy, plan, and playbooks, let alone testing them, and that's a very common thing insurance agencies and vendor risk questionnaires ask for: do you have a process for dealing with incidents? We can help plug those gaps. Depending on the framework you choose — I have my favorites, but we can address a wide number of them — we help identify the gaps, and we can take it further than just providing a report, building out the project plan to actualize the roadmap.
We use a portal that helps organize the documentation and complexity of your program in a way you can track and share internally, with task integrations into ticketing systems like Jira, and risk matrices. Should you be seeking a SOC 2 Type II or Type I, or an ISO certification, the work we do together to identify gaps, remediate them, and collect the evidence can then be shared with your auditors — lowering the cost of the audit and making things easier to manage. And if you really hate those vendor risk questionnaires, you can get on the front end and provide them to your own vendors, making sure they have fun answering them too.
In closing: taking an approach like this is a shift from how a lot of the clients I talk to currently do business. Most of the folks I work with have really capable teams, but there's a lot of responsibility spread over a generally small group of people who hold a lot of insight. Practices like this — assessing what the program needs, what it's doing, and the strategy — take a lot of focus. Externalizing not the decision-making, but the fact-finding and the guidance, has been very helpful in speeding up the rate of maturity for the organizations we work with.

.webp)


