At the heart of incident response, and by extension of Security Automation and Orchestration technologies, resides the Cyber Incident. A typical definition of a cyber security incident is “Any malicious act or suspicious event that compromises or attempts to compromise, or disrupts or tries to disrupt, a critical cyber asset”. Almost everything we do in a SOC or a CSIRT is based on incidents, and there are a variety of potential incident sources, for example:
- Alerts from cyber security detection technologies such as Endpoint Detection & Response or User Entity Behavior Analytics tools
- Alerts from Security Information & Event Management Systems (SIEM)
- Emails from ITSM or case management systems
- Website submissions from internal stakeholders and whistle-blowers
- Phone calls from internal users and external 3rd parties
This diversity of incident sources means that a solid SAO solution must offer a variety of different methods to create incidents. Regulatory frameworks also frequently mandate being able to originate incidents from different sources. DFLabs IncMan offers a rich set of incident creation options.
There are three primary ways to create incidents in IncMan, offering flexibility to accommodate a variety of incident response process requirements and approaches.
Option 1: Automated Incident Creation
We will feature automated incident creation in a more detail in a future post. In the meantime, I will show you the location of this feature.
Select settings menu, then head to the external sources:
You will see that under the external sources option there are 3 options available to use as sources to automate incident creation:
- Incoming events automation, for CEF/Syslog
- Incoming Mail automation, for a monitored email account
- Integrations, for all QIC integration components.
Automating incident creation supports a variety of filters to support a rules-based approach. In addition, it is also possible to create incidents using our SOAP API. Certified 3rd party applications use this mechanism to create incidents within IncMan, for example, Splunk.
Option 2: Manual Incident Creation
Click the incidents menu option, then click the + symbol selecting the incidents screen
Fill out all mandatory fields (these can be defined in the custom fields screen) then step through and complete the incident wizard to create the incident:
Once all relevant fields have been completed, click save and this incident will then appear in the incident view and apart of the queue you assigned in the details screen.
Option 3: Incident creation from source
Select an incident source for the incident you want to create, for example, a Syslog or CEF message, an Email, or a Threat intelligence source (STIX/TAXI, ThreatConnect):
In this screen, you can then convert this source item to an incident, or link the source to an existing incident.
Since I am a new face (or perhaps just a name to most of you) here at DFLabs, I wanted to take a moment to introduce myself before we jump into the topic for today. My name is John Moran and I recently joined the DFLabs team as Senior Product Manager. Prior to joining the DFLabs team, I worked in a variety of roles, including incident response consulting, security operations and law enforcement. While I have many responsibilities at DFLabs, one of my primary roles and the one that I am perhaps most passionate about is ensuring that DFLabs continues to bring you the industry leading security orchestration, automation and response feature that you have come to expect from IncMan. If you have feature requests, suggestions or other comments, good or bad, regarding IncMan, I’d love to hear from you. Please reach out to me at [email protected]. With that out of the way, let’s get to the good stuff…
While reports such as the Verizon DBIR indicate that the increased focus on creating holistic, detect and respond security programs has had a positive impact on reducing the time to detect security incidents, these same reports have also shown that attackers are continuing to evolve. There is still a continuing gap from compromise to detection. what I would like to discuss here instead though, might be described as the opposite problem; overreaction to a perceived security incident, or conducting a full-scale response to a security incident prior to validating that a security incident has indeed occurred.
Please do not misunderstand what I am saying, I will always advocate the “treat it as an incident until you know otherwise” approach to incident response. However, I would also encourage that the response to any security incident should always be a measured response. The incident response process must be rapid and decisive; but just as under-responding to an incident can present serious financial and reputational risks to an organization, so too can over-responding to a potential security incident. As with any other business process, incident response must provide value to an organization. Continued over-response to perceived security incidents will reduce the overall value that incident response provides to an organization, and over time will result in decreased support from management.
Few studies have truly been able to quantify the costs associated with failing to conduct a measured response. A 2015 study by the Ponemon Institute suggests that response to incidents detected based on erroneous or inaccurate malware alerts costs large organizations up to 395 hours-per-week, or almost $1.3 million a year. It is important to note that this study only took into consideration time spent investigating malware alerts. While malware detection technologies have undoubtedly improved in the two years since this study was conducted, most organizations have a variety of detection technologies, all generating alerts which must be investigated. It was assumed by Ponemon that the organizations surveyed were conducting an appropriate, measured response to each of these false positives. With the cost already so high, it is easy to conclude how costly over-responding to incidents can become at scale.
While conducting incident response consulting, I have personally seen organizations spend weeks to months conducting full-scale incident response activities before spending tens of thousands of dollars for incident response consulting, only to find out that the perceived incident was based on faulty information or conclusions. So how do you minimize the risk of over-responding while continuing to ensure that each potential incident is properly investigated? Here are five tips based on my experience:
- Have the right people in place – There is simply no substitute for having the right people in place. While proper training and experience are vital, the qualities of an effective analyst extend beyond these two attributes. It is crucial to have analysts who possess an analytical mindset and can remain level-headed amidst a stressful and dynamic environment. Training and be provided, the experience can be gained, however, some of these less tangible qualities are much harder to learn.
- Have the right toolsets in place – Attempting to substitute tools for skills will inevitably lead to failure. However, it is important to have the proper tools in place to give those highly skilled analysts the information they need to make fact-based conclusions. Even the most highly skilled analysts will inevitably arrive at the wrong conclusion when presented with incomplete or inaccurate information.
- Know the threat landscape – Threat intelligence, and I mean actual intelligence, not just a machine-readable threat feed, can provide much greater context surrounding a potential security incident. Analysts must also be provided the opportunity to remain up-to-date on the ever-changing threat landscape. This can allow decision makers a much more accurate perspective on which to base their initial level of response. Often, it is a lack of knowledge and conclusions based on assumptions that lead to a dramatic over-response.
- Know your limitations – Unless you are fortunate enough to work for a government agency or one of the world’s largest organization, chances are at some point your needs may exceed the scope of your internal capabilities. These limitations are not weaknesses in and of themselves. Instead, the risk here presents itself when an organization fails to realize its limitation and attempts to work outside of those bounds. It is important to know when to consider tapping into external resources such as consulting, incident response retainers and managed services.
- Replace the emotional response with processes and procedures – Even the most highly skilled analysts will approach some potential security incidents with certain biases or preconceived notions. It is essential to implement quality processes and procedures which maximize the analyst’s skills, take full advantage of the available tools, and guide the incident response process. Processes and procedures surrounding incident validation, incident classification and initial resource allocation can ensure that the process stays on track and avoid straying down the wrong, costly road.
The most important goal of any security program must always remain to never under-respond to an incident. However, integrating these five tips into your security program will undoubtedly provide a better, more efficient process to determine what the appropriate level of response to each potential security incident should be, greatly reducing the risk of over-responding.
Today, we will talk about our dashboards in IncMan. We will see how to add, delete and generally organize the dashboard widgets. IncMan widgets can display charts, graphs and tables to display and track Key Performance Indicators. IncMan supports role-based dashboards. This is a key requirement for any SOC, facilitating that the right information is available to the right person based on their role, duties, and needs. Which information is required for any individual or team will differ from organization to organization, so we support customization to create unique and dedicated dashboards for every persona.
How to use IncMan Dashboards and Widgets
This default screen displays a number of out of the box charts to get you started. But you will want to customize the dashboard with the widgets you need for your role.
1. To begin creating your unique dashboard, select “Customize” to open the menu.
2. The dashboard screen is split into 4 distinct parts: top, left, right and bottom. By selecting the “+” symbol, you can add an additional widget from a number of pre-defined templates. For this example, let’s add the “Incident Overview” widget:
3. You can change the name of the widget in the configuration screen, for example, “GDPR” or “Urgent Incidents”. You can also specify the applicable timeframe for the widget, and the refresh rate, to determine how often the widget will be updated.
4. Next, we will configure the widget filters to determine the data that the widget displays.
We can apply search filters to narrow down the displayed incidents. You can filter by a variety of attributes, including tags, incident priority, the Incident Response process stage, and any custom fields you have defined. Every filter that is selected will also need a corresponding value assigned to it in the values tab.
5. Once you’ve selected the values you want to add into the table, the final step allows you to define which columns will be displayed in the widget.
The EU GDPR will be enforced from May 25th next year. GDPR mandates a wide variety of requirements on how data processors must manage customer and 3rd party data. Although it is not primarily focused on cybersecurity, it does contain vague requirements on security monitoring. This includes that data processors must establish a breach notification procedure, that include incident identification systems, and must be able to demonstrate that they have established an incident response plan.
Further, there is a requirement to be able to notify the supervisory authority of a data breach within 72 hours of becoming aware of a data breach or face a stiff financial penalty. This last requirement is of special interest beyond the impact on data processors. Because it means that for the first time, we will begin having reliable data on European breaches.
Historically, European companies have had no external requirement to be transparent about being affected by a breach. This has had the consequence that we have not had good data or an awareness of how well or badly European organizations are doing when it comes to preventing or responding to security breaches.
I am sure that if like myself, you have worked in forensics and incident response in Europe over the years, you are aware of far more breaches that are publicly disclosed. The only information available is when a breach is disclosed due to the press and law enforcement, or the impact is so great that it can’t be ignored. We also have some anonymized reports from some vendors and MSSP’s, but these are really no more than samples. While not without benefit, these also do not provide a reliable indicator, as the samples are not necessarily statistically representative This provides a false sense of how European organizations are faring compared to other regions and presents a skewed image of European security in general.
The true state of European security is an unknown and has been difficult to quantify. I have seen German articles for example that have claimed that German Security is better than the rest of the world because there are less known breaches. The absence of evidence is of course not evidence of absence. Something that has not been quantified cannot be said to be good or bad. More importantly, if you do not measure something, it cannot be improved.
It will be interesting to see whether GDPR will force European organizations to place more focus on Incident Detection and Response, and give us insight into the true state of European security.