Today, organizations are overwhelmed with the volume, variety and complexity of cyber attacks. They are equally overwhelmed with the variety and complexity of cyber security solutions, particularly the overlapping capabilities offered by vendors with a “me too” attitude. This is flagrantly evident with “incident response tools;” every vendor wants to be their customer’s incident response solution.
The cybersecurity incident response cannot be a simple extension or an after-thought. It’s a discipline that organizations have tried to hone in on since the first malware was discovered, and it requires a thoughtful, evolutionary and comprehensive approach commensurate with the changing cyber threat landscape. Any tool that purports to be an incident response tool must seamlessly integrate with an organization’s incident response strategy, the core of which includes an incident response policy, plan, procedures and service levels. Collectively, this is called the incident response program.
Regardless of the size of an enterprise or its industry, organizations must create and implement an incident response program to effectively and confidently respond to the current and emerging cyber threats. More often than not, companies make simple mistakes in developing and implementing these programs largely because they are focused on the day-to-day, versus a comprehensive strategy to combat persistent cyber threats. Ken Silva, president of cyber strategy at ManTech Cyber Solutions, offers seven key elements required to establish a robust, evolutionary and durable incident response program that delivers results.
Click through for seven key components organizations need to create an effective incident response plan, as identified by Ken Silva, president, ManTech Cyber Solutions International.
Incident response essential practices
There are two parts to establishing essential security practices for incident response: (1) adherence to compliance and laws and (2) definition of standard operating procedures that clearly document the steps for each incident type. Compliance requirements drive policy and privacy, and the controls that must be implemented. Any gaps in controls could well lead to incidents.
Organizations must proactively understand these vulnerabilities and create response procedures that are documented and implemented, hopefully using tools that help codify these processes for consistency across all teams. These essential practices should be reviewed periodically, and updated based on experience from responding to incidents, availability of new controls (tools), or changes in the regulatory or legal landscape. Note that the essential practices must include containment, remediation and prevention strategies, as well as contingencies like escalation and brand repair.
Know your data
Know all of the types of data that reside on the network and where it lives, and prioritize it based on value. Next, investigate all of the avenues through which this data can be accessed — both internally and externally. Think of it as a map, detailing all of the ins and outs of the network. Create the protection plan for this data based on the map, keeping in mind data can be at rest, in motion and in execution.
Create plans for all possible situations
Not every incident will be the same, nor will every incident consist of a one-off hack. In fact, that is seldom the case, as is evident from kill-chain analysis. Organizations should plan for external attacks, as well as incidents that occur pursuant to assets being lost or stolen (i.e., laptops, mobile devices and removable media). Also remember that insiders can be a threat – including when an outsider compromises an insider’s access. Create a separate plan for each scenario so no matter what the incident is, a response plan can immediately be put in place. If you have tools that can codify and automate some of these processes, you will be that much better off in compressing time by meeting service levels while also increasing capacity.
Keep an eye on threats
There is good reason there has been an explosion in data feeds and services that provide or share threat information. Such threat information includes a variety of indicators, malware binaries, tools and techniques, and actor data. While it may seem like searching for a needle in a haystack, and it often is, there are many compelling reasons to aggregate threat data — for example, to follow known sources or actors, to scan internal logs to recognize the presence of a threat before any of your security tools can, to implement protection strategies with prior threat knowledge, to corroborate internal discoveries with the work of the community in confirming threats, and much more. Today, we are caught up in buzzwords like “security analytics” and “sandboxing.” Focus first on proven methods to collect and correlate feeds in order to maintain a pulse on the threats out there.
Establish a command center
Create a base for incident response operations — like a command center. This can simply be a conference room or the largest office space in the building. Having one room identified as the “command center” makes it easier for those involved in incident response to know where they need to be physically to put a plan in place. This way, stakeholders don’t have to chase down a status update. Instead, have a go-to place (or portal) for comprehensive or role-based access for real-time situational awareness. Along with the command center, organizations also need to identify a leader that truly understands their organization’s incident response program. Nominate one point of contact and make sure this person can reach everyone working on the incident, as well as those who need to be updated on the situation. Also, consider connecting the leader with the PR team if needed. If PR is necessary, the leader should be the only voice speaking to the general public and media. The legal team can deal with compliance issues on a case-by-case basis.
Implement a system of record
Today, much of the enterprise is run by software. There is no reason for a comprehensive cybersecurity incident response to be largely a pen, paper and spreadsheet operation. Technology is an integral part of security, and what the industry needs is more integrated, automated yet evolutionary technology for incident response as an effective complement to the incident response program — and the key to the success of the command center. Until organizations demand such a tool, and the security software industry responds, the incident response program will remain somewhat ineffective. A strong program needs a strong execution engine. This is not a defeatist view. In fact, the incident response program is a MUST, and vendors will seek out the opportunity to fill in any void that exists.
In the end, the effectiveness of an incident response program is only as good as its implementation and performance by the team responsible for it. There are many reasons why things take too long — for example, if processes are onerous, teams and roles are not trained, organizations do not have the right tools, collaboration is idiosyncratic, or access to incident data entails red tape. As the saying goes, “you can’t control what you don’t measure.” Granular measurements will identify flaws in the processes, while aggregate SLAs will identify (or justify) staffing, training and technology investments. Finally, SLAs will also provide insights into the incident response essential practices, closing the loop on a well-rounded, responsive and current incident response program.