Let’s say you are the CISO or IT security lead of your organization, and your incident response program needs an uplift. After making a compelling business case to management for investment, your budget has been approved and expanded. With your newfound wealth, you focus on acquiring technology that will improve your monitoring, detection and analysis of data traffic.

Has the incident program really improved by the technology acquisition, or is the uplift merely cosmetic? If no other changes have been made to the program, a strong case can be made for the latter. Let’s take a look at why.

The technology: Don’t leave a supercar sitting in the driveway

Contrary to the title of this piece, let us start with technology to illustrate the downstream impacts of investment gaps. Firstly, powerful technology is an important pillar of any incident response program. But do not be fooled: technology alone is not an impenetrable shield, and it requires support.

Ask yourself this: are you using cybersecurity technologies as a tool or as a crutch? If it is the former, your program likely also has knowledgeable people and well-defined processes supporting it. But if the program lacks the people and processes, technology is likely acting as a crutch whether you recognize it or not.

People and processes are what eliminate technological blind spots or trouble points, such as the following:

  • Misconfigurations
  • Fragmented or disjointed coverage models
  • Duplication or conflict of services
  • Reduced optimization
  • No fine-tuning or activation of features
  • Poor and outdated maintenance.

Automation can take you a long way, but even that requires people and processes to run. What you want to avoid is having the equivalent of an exotic supercar sitting in the driveway. Sure, it may be mesmerizing to look at, but don’t you want to drive it as it was meant to be driven? If you do not know how to get the thing out of first gear, at best it is an expensive and high-maintenance compact car. At worst, it’s an expensive accident waiting to happen.

This is where people and processes come in.

The people: Your most critical asset

If the brain trust decides to invest in a race car, they better also invest in race car drivers, pit crews, engineers, analysts, researchers and those other roles required to win the race. And it’s not a stretch to suggest that incident response is a race — a kind of daily 24 Hours of Le Mans during peacetime meets F1 madhouse during an incident.

A recent IBM-commissioned study found that the first 72 hours of response is critical to taming the chaos of an incident. Pointing out the obvious: people are involved, and the human factor will always be the beginning, middle and end of every incident. You need people to:

  • Manage expectations of multiple stakeholders
  • Assess, report and advise on — if not make — important decisions
  • Think creatively about planning, responding and remediating
  • Take care of the aforementioned blind spots and pain points.

Technologies cannot do these things, which is what makes a day in the life of an incident responder so interesting. Like a race car, they can go from 0 to 100 mph in a heartbeat once the incident hits. But during peacetime, incident responders are boots on the ground that inform the requirements and adjustments to the program. Take the following questions, for example:

  • Are tools missing?
  • Are tools misconfigured or not optimized?
  • Are processes absent or misaligned?
  • Are preparations adequate?

You are probably starting to see the puzzle come together now. One end of the spectrum is the brains (people) and on the other are the tools (technology). So what makes them interact? It’s the process.

Watch the Webinar  

The process: Minimizing impact

Incident response processes — including associated policies, plans and playbooks — are both glue and lubricant for the incident response program. Even the best people have mishaps, which is why these processes need to be formalized.

As incidents continue to be stressful and increasingly impact the health of responders, the study above indicates that well-made processes are saviors (especially for ransomware cases). Formalized processes allow you to:

  • Build muscle memory
  • Document actions that — at least if done correctly — have been stress-tested against the environment and modified accordingly
  • Ensure maintenance and remediation activities
  • Drive consistency.

Most of all, well-developed processes keep the program honest throughout the incident response lifecycle, which is defined by the National Institute of Standards and Technology (NIST) Special Publication 800-61 Computer Security Incident Handling Guide as:

  • Preparation
  • Detection and Analysis
  • Containment, Eradication and Recovery
  • Post-Incident Activities.

Recent incidents have shown that severe data loss can happen by simple configuration errors, like leaving the door wide open on public-facing assets. Therefore, the “preparation” phase of the lifecycle is not just about incident responders, but rather about analysts, architects, engineers and decision-makers all working in tandem. If there are no processes to facilitate this, decisions are made in silos, adding blind spots.

Similarly, during a crisis, you need to have pre-existing processes in place for roles, responsibilities, interactions, escalations, activations and communications to work well.

The right fit trifecta

Time to bring this full circle. Now we have identified the three key pillars of an incident response program, the question likely on most minds is: where do I invest?

The answer is everywhere. It is the level of investment in each pillar that becomes trickier to determine. The answer to that question depends on your risk tolerance.

Nothing is stopping you if you want to throw all your eggs into the technology basket, but take a moment to appreciate the larger picture. Maybe the solution isn’t having a supercar, but instead having an everyday car that you know how to drive well and can maintain yourself to some degree. Otherwise, you may find yourself leaning on the mechanic (aka consultants and third parties) more than you want.

Finally, the lesson is that you need some level of balanced investment in all three pillars. Two short legs and one long one don’t make for an effective — or even usable — stool.

More from Incident Response

Alert fatigue: A 911 cyber call center that never sleeps

4 min read - Imagine running a 911 call center where the switchboard is constantly lit up with incoming calls. The initial question, “What’s your emergency, please?” aims to funnel the event to the right responder for triage and assessment. Over the course of your shift, requests could range from soft-spoken “I’m having a heart attack” pleas to “Where’s my pizza?” freak-outs eating up important resources. Now add into the mix a volume of calls that burnout kicks in and important threats are missed.…

SIEM and SOAR in 2023: Key trends and new changes

4 min read - Security information and event management (SIEM) systems remain a key component of security operations centers (SOCs). Security orchestration, automation, and response (SOAR) frameworks, meanwhile, have emerged to fill the gap in these capabilities left by many SIEM systems. But as many companies have begun reaching the limits of SIEM and SOAR systems over the last few years, they have started turning to other solutions such as extended detection and response (XDR). But does this shift spell the end of SIEM…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Unmasking hypnotized AI: The hidden risks of large language models

11 min read - The emergence of Large Language Models (LLMs) is redefining how cybersecurity teams and cybercriminals operate. As security teams leverage the capabilities of generative AI to bring more simplicity and speed into their operations, it's important we recognize that cybercriminals are seeking the same benefits. LLMs are a new type of attack surface poised to make certain types of attacks easier, more cost-effective, and even more persistent. In a bid to explore security risks posed by these innovations, we attempted to…