4 Ways to Avoid Getting Too Comfortable with Your Cyber Security Program
If you work in cyber security, you know that an organization can have an incredibly mature or sophisticated security program and still experience a breach. There is no silver bullet to prevent this type of event at your company, but over the years I have found ways to continue to push our program forward and never get comfortable with where we are at.
I had the pleasure of sitting down with NetSPI’s Nabil Hannan to discuss some of those strategies as part of the Agent of Influence podcast. During our conversation, we discussed four strategies to stay focused on the highest priority actions and help keep a company safe.
1. Leverage and Listen to Your Red Team
You can learn a lot about your security program from red team engagements – namely, its areas of strength and weakness. Red teams can come up with some fantastic attacks against your company and open the door to new security considerations your blue team hadn’t thought of. You don’t necessarily need a large team to succeed at red teaming. At Code42, we have two people responsible for our red team engagements. And if you don’t have an internal red team, find a partner to collaborate with you on the engagement.
Many red teams today are leveraged for a standard monthly kill chain exercise. That’s a great practice, but try leveraging your red team for a larger, more complex engagement. An engagement that emulates the most likely attack against your organization will force them to think creatively about how to carry that attack out and how to prevent it from happening to your organization.
2. Perform Regular Threat Assessments
The second activity I encourage is to establish regular threat assessments. As security leaders, we can get stuck doing simple, straightforward compliance assessments. While compliance assessments can uncover a lot of risks, you start with a list of requirements rather than starting with what could go wrong at the company – and sometimes those don’t align.
In my current role as CIO and CISO at Code42, we do the traditional controls assessment, maturity assessment, and we use NIST, ISO, among other compliance frameworks. In addition, we take time every year to bring different leaders from various parts of the organization together, along with security experts from production and research and development (R&D), to complete a deep dive threat assessment. On this brainstorming day, we discuss all the terrible things that could happen to our company and assess what controls and processes we have in place – or do not have in place – for prevention and incident response. From there, we create a laundry list of actions to prioritize and ensure we improve our security posture.
3. Prioritize Existing Security Gaps, Then Do a Benchmarking Exercise
When building out a security program, chances are you have existing security gaps. My advice is to find and fix those first. For example, the volume and magnitude of risk from email phishing was prevalent when I first started as a CISO. So that’s where we started.
There are going to be security issues that are obvious. I think it’s important to tackle those right off the bat and earn some quick wins for your team. After that, pause and do a benchmarking assessment to figure out what activities to prioritize next. A benchmarking assessment is particularly important to do when things become less clear as to what to go after. Many leaders start with benchmarking – hear Nabil’s take on the timing of benchmarking during our podcast conversation – but I have the opposite advice. If you know what’s broken and you’re hearing about it, that’s where you should start.
4. Understand That The Importance of Application Security Has Never Been Greater
My team spends a majority of our time on application security. Why? Because that is where the majority of our risk lies today. There are a couple shifts in application security that are worth paying attention to.
First, is the rise of the serverless concept. This means that an application can be built where we don’t have to connect to the underlying OS and/or database aspects of it, which expands the attack surface at the application layer. It is more important than ever to focus on protecting the application layer knowing that the attack surface is expanding there today.
Another application security focus area that is incredibly important is to figure out where to plug in security resources and security scanning processes into your development lifecycle. At Code42, we built a standalone product application lifecycle security embedded within our R&D team. They’re part of the scrum teams, listening to the story mapping, embedding testing early on, and bringing up security concerns. I believe that the more security is seen as a partner and embedding themselves early on with development teams, the better. Security is still considered the outsider in many organizations, but we’re starting to be part of the larger development team at Code42. In a dream world, I would love for developers to be security developers – that’s utopia.
The speed at which applications are being built, updated, and deployed is always going to be a constant challenge for security. This ties back to the idea that comfort is the enemy. As security professionals, we need to continuously evolve and evaluate our security program to protect against adversaries. If you become too comfortable with your program, it’s likely that there’s something you’re missing.
Explore more blog posts
CTEM Defined: The Fundamentals of Continuous Threat Exposure Management
Learn how continuous threat exposure management (CTEM) boosts cybersecurity with proactive strategies to assess, manage, and reduce risks.
Balancing Security and Usability of Large Language Models: An LLM Benchmarking Framework
Explore the integration of Large Language Models (LLMs) in critical systems and the balance between security and usability with a new LLM benchmarking framework.
From Informational to Critical: Chaining & Elevating Web Vulnerabilities
Learn about administrative access and Remote Code Execution (RCE) exploitation from a recent Web Application Pentest.