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.
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.
The post People, Process and Technology: The Incident Response Trifecta appeared first on Security Intelligence.
