The DNA sequence for each human is 99.5% similar to any other human. Yet when it comes to incident response and the manner in which individual analysts may interpret the details of a given scenario, our near-total similarity seems to all but vanish. Where one analyst might characterize an incident as the result of a successful social engineering attack, another may instead identify it as a generic malware infection. Similarly, a service outage may be labeled as a denial of service by some, while others will choose to attribute the root cause to an improper procedure carried out by a systems administrator. Root cause and impact, or incident outcome, are just a couple of the many considerations that, unless properly accounted for in a case management process, will otherwise play havoc on a security team’s reporting metrics.
Poor Key Performance Indicators can blind decision makers
What is the impact of poor KPI’s? All too often the end result leads to equally poor strategic decisions. Money and effort may be assigned to the wrong measures, for example into more ineffective prevention controls instead of improved response capability. In a worst case scenario, poor KPI’s can blind decision makers to the most pertinent security issues of their enterprise, and the necessary funding for additional security may be withheld altogether.
Three best practices are required to address this all too common problem of attaining accurate reporting:
- A coherent incident management process is necessary in order to properly categorize incident activity. Its definitions must be clear, taking into account outliers, clarifying how root causes and impacts are to be tracked, and providing a workflow to assist analysts in accurately and consistently determining incident categorization.
- The process must be enforced to guarantee uniform results in support of coherent KPI’s. Training, quality assurance, and reinforcement are all necessary to ensure total stakeholder buy-in.
- Security teams must have the technologies to support effective incident response and proper categorization of incidents.
There are several ways that the IncMan platform supports the three best practices:
First, IncMan provides a platform to act as the foundation for an incident management program. It provides customizable incident forms allowing for complete tailoring to an organization and the details it must collect in support of its unique reporting requirements. Custom fields specific to distinct incident types allow for detailed data collection and categorization. These custom fields can be coupled with common attributes to track specific data, thereby providing a high level of flexibility for security teams in maintaining absolute reporting consistency across the team’s individual members.
Next, playbooks can be associated with specific incident types, providing step-by-step instructions for specialized incident response activities. Playbooks enforce consistency and can further reinforce reporting requirements. However, playbooks are not completely static, and while they certainly provide structure, IncMan’s playbooks also offer the ability to improvise, add, remove or substitute actions on the fly.
The platform’s Knowledge Base offers a repository for reference material to further supplement playbook instructions. Information collection requirements defined within playbook steps can be linked to Knowledge Base references, arming analysts with added information, for example with standard operating procedures pertaining to individual enterprise security tools, or checklists for applicable industry reporting requirements.
IncMan also includes Automated Responder Knowledge (ARK), a machine learning driven approach that learns from past incidents and the response to them, to suggest suitable playbooks for new or related incident types. This is not only useful for helping to identify specific campaigns and otherwise connected incident activity but can also highlight historical cases that can serve as examples for new or novice analysts.
Finally, the platform’s API and KPI export capabilities enable the extraction of raw incident data, allowing for data mining of valuable reporting information using external analytics tools. This information can then be used to paint a much clearer picture of an enterprise’s security posture and allow for fully-informed strategic decision-making.
Collectively, the IncMan features detailed above empower an organization with the means to support consistency in incident categorization, response, and reporting. For more information, please visit us at https://www.dflabs.com
What’s wonderful about all our security industry and specifically the products, is that we constantly see similar fancy dashboard reporting. These views focus on an abundance of information being displayed to aid users trying to correlate and make historical data relevant. It’s vital data but I don’t think this information is best placed in this scenario. I am going to focus on the perspective that is most relevant to myself, and that’s incident response. For incident response, historical data is relevant when you have a purpose to use it. Our main focus, within incident response, is to respond to incidents that are relevant right now.
We often focus on thinking outside the box and use examples from other business models in order to facilitate our own growth. I think this concept is common and serves its purpose for planning, but we must understand the purpose for which we’re trying to use this concept. I always laugh when I see a show of the morning which displays stock/indices information. I ask myself, who is next to implement that view in their security product? Considering this, I think it’s something we need to seriously think about. Is this information relevant for this purpose at this point of a cyber investigators journey?
Over-complicating and over-stimulating users with too much data can have the opposite effect of the desired consequence. You’ll lose value and purpose for this information and ultimately it can become another piece of background clutter that is easily ignored. Time is essential when dealing with any cyber security event, not only from a response standpoint but also an evidentiary gathering perspective. Orchestrating information at the correct time is just as important as responding to the incident itself. Evasion techniques, obfuscation, and piggybacking are just some of the thought processes cyber intruders will use. It’s extremely difficult to know when the right time will be for each individual case, however having an incident response platform to gather and display incident information is essential and following this information in a visual manner will prove effective to the war rooms.
An incident responder’s dashboard should be clear and concise. The investigator, analyst or stake holder should see information that can drive them to an action on a granular level. While this information may be different from organization to organization, the concept should remain the same. I do enjoy a good list, so here are some of the thoughts I have when planning a dashboard view:
– Active Cyber Incidents per business units and their priority, some people mention this as a health status. Either way the concept is the same. Which business units have incidents registered against them? What’s the priority of the incident? This should simply generate a % number and a color coding. Use RED, if major, Green is low priority and non-invasive tasks identified. The number should represent the inverse of incidents * by the priority raised
– Events identified by source, knowing which products are producing the most events is quite key in identifying if this source is doing its job or if the source could be configured differently
– Playbook stage number, time to close organized by priority.
Incident data is critical, and the general rule of thumb is more is preferable to not enough. However, given that the purpose is to understand the relevant data as it relates to current and future incidents, this simple technique ensures that your incident data feeds not only remain timely, but provide maximum value as well.