How Trading Platforms Are not the Same as Incident Response Platforms?

Posted bySteven Ditmore - 03rd Apr 2017
How Trading Platforms Are not the Same as Incident Response Platforms?

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.