How To Enhance Your Security Operations Program SLAs, MTTR & ROI

Within any organization’s security operations center (SOC), regardless of the level of role undertaken (security analyst, engineer or manager), when it comes to the security program at hand, the overall high level goal is to ensure that potential security risks from the alerts generated are dealt with in the most efficient and effective way possible, keeping the threat and potential incident under control, resulting in minimal impact to the day to day operations of the business.

As more and more security alerts are being triggered, potentially with increasing veracity as hackers get more sophisticated, the mean time to detection and mean time to resolution (MTTR) is vital. This is when it becomes critical to make sure your security operation center and incident response teams are fully utilizing the tools and resources they have available to them, to detect, orchestrate, automate and measure their security operations and incident response processes and tasks.

With security incidents becoming more costly, organizations must find new ways to further reduce the mean time to detection and the mean time to resolution. At the same time, they face pressure from being heavily monitored based on a number of security program KPIs to accurately measure (and improve) performance, which will inevitably be reported back to varying levels of stakeholders, including security management, c-level executives, and even board level. (For more information about KPIs for security operations and incident response, download our recent whitepaper here). While some members of the SOC team such as the analysts will solely be focused on the incidents at hand, KPIs and questions surrounding service level agreements (SLAs), mean time to resolution (MTTR) and the overall return on investment (ROI) of security tools and technologies are bound to be at the forefront of the agenda of perhaps the SOC manager, but in particularly the CISO.

In this blog we will briefly discuss how a SOC can enhance its security operations program SLAs, MTTR and ROI, by investing in a Security Orchestration, Automation and Response tool, such as the IncMan SOAR platform from DFLabs and we will run through a basic scenario of what happens when a security alert is detected and triggered using IncMan SOAR.

Many large organizations already use a number of third-party solutions, including security information and event management (SIEM) and endpoint detection and response (EDR) tools, but the question is…is all of the information being generated by these tools and technologies being utilized and fused together providing meaningful aggregated, correlated and analyzed security intelligence? The answer is most probably no and the likelihood is the SOC team is being overwhelmed with the number of alerts and information that it is receiving, therefore not easily being able to identify which is a high level vs. low level threat, or know exactly which process should initially be taken to start putting a playbook or runbook into action to contain the specific threat alert they are dealing with.

How IncMan Tackles an Alert with Security Orchestration and Automation

Example Scenario:

An incident was automatically triggered in IncMan SOAR when the organization’s vulnerability management systems found that one of the critical servers reported non-compliance due to missing patches. The security analyst on duty assessed that the problem needed an immediate remediation. An incident management record was created to assign the correction of the problem to the system administrator in charge of the server. Automated actions triggered email notifications to the system administrator and to the security architecture and governance team, who manage the organization’s compliance.

Earlier in the year, the CISO mandated that changes within the large organization were monitored end to end through the system development lifecycle (SDLC). This would try to ensure that there were no security gaps in the infrastructure, as non-compliance within servers can create a security gap that can easily be exploited and misused by a hacker.

This is just one example of an alert that an organization could receive and in this case, it is quite a simple one. Imagine hundreds of alerts coming in per day related to suspected phishing attempts, malware injections, ransomware attacks and data breaches etc. to name a few, that are more complex. Analysts often get overwhelmed with the number of alerts they receive but need to be able to respond quickly to all of them, while also prioritizing them at the same time. The key is to transform the resource intensive and manual tasks into an effective and efficient automated and orchestrated process, where dual actions (automated and manual) can occur side by side as needed. Automating the process with the use of tools such as the IncMan SOAR platform will cut down the time to gather the data manually and the number of resources needed to complete the several stages of the process.

IncMan SOAR provided this customer with a real-time alert that was responded to and remediated almost immediately. Automated processes were followed, reducing the amount of human manual interaction required, including data collection, enrichment, containment and remediation, all in a more efficient, standardized and timely manner. IncMan SOAR facilitated the enrichment of information via the integration tools that the security team was already using and this helped to provide additional intelligence to the investigation, that triggered the original security alert, helping to validate its severity.

With a vast amount of information being generated, having the ability to provide this information in an easy to use and understand format, then facilitated the communication among different IT team members and departments, allowing them to share the visualized information via dashboards and detailed reports that standardize the information sharing process.

Utilizing Playbooks and Runbooks

So how does a SOAR solution like IncMan know which actions to automate when a security alert is triggered? A security operations center can maximize its incident response process by utilizing a range of already predefined automation and orchestration processes via playbooks  and runbooks  that expedite activities based on the type of security alert. You could have specific ones for ransomware or a phishing attack for example that have been written, trialed and tested a number of times, over and over again to ensure the correct actions are taken.

IncMan’s SOAR powerful engine provides an assortment of automation and actions that within second of being triggered can enrich, contain, remediate and notify stakeholders faster than a human being can react, to gather diverse information from different data sources. The process is flexible and can be used fully automated or in hybrid mode with human interaction to approve certain actions, for example, to block an IP-address or quarantine a compromised asset.

How To Enhance Your Security SLAs, MTTR & ROI
Conclusion

In summary, the above example would have been a mundane and manual process without the use of orchestration and automation, that would depend on human resources collecting information from different data sources, actioning a number of activities and writing a manual report.

The power of the correlation engine in IncMan SOAR cuts down the time by facilitating the collection of the threat information via the integrated third-party vendors’ data sources. With the help of playbooks and automated runbooks meaningful threat intelligence can be easily gathered enriched and correlated to produce a visualization of the incidents, that can be displayed in an automated standard report. The information is quickly available, easily shared to make available to all teams as necessary, without having to wait for dependencies to obtain additional information about the incident from the project teams.

IncMan SOAR maximizes the SLAs for security availability and MTTR, by delivering key details expeditiously via digital computation from multiple data sources of information and delivering it in a visual or readable detailed report format to multiple stakeholders, leadership team or anyone that needs them. The data can subsequently be kept, helping to build and identify historical trending, analysis, patterns, type of attacks to name a few, facilitating the automation actions of future alerts, creating a better security defense system.

Overall the benefits of using a Security Orchestration, Automation and Response platform outweigh the negatives and such a solution can increases the efficiency of your security operations center, enabling it to become more effective, focused on incident response management, proactively threat hunting while minimizing cybersecurity vulnerabilities, as opposed to carrying out the multitude of mundane, repetitive and time consuming basic tasks.

Automation and orchestration reduces the MTTR, as well as aiding the organization’s management team with standard visualization and focused detailed written reports, that helps to contribute to better meeting compliance such as breach notification requirements, while meeting the organization mission to operate in a secure infrastructure in an efficient manner, by increasing cybersecurity governance SLAs and ROI, ultimately maximizing the company resources by doing more with less.

The Key to Furthering the Security Industry

Instead of a technical topic, this week I wanted to discuss an interaction I had with another Information Security professional recently because I believe it exemplifies how we as professionals can interact and share ideas in a way that furthers the security industry.

A couple of weeks ago, DFLabs released a whitepaper titled: Increasing the Effectiveness of Incident Management, which I authored discussing how the Incident Command System utilized for decades by emergency services in the US and across the world could be applied to streamline security incident management in the enterprise. Weeks later, Adam (whose last name I will not use since I did not ask his permission) reached out to me to express a problem with one of the premises of that whitepaper. What I want to highlight here is not that someone disagreed with me on a point (it happens often), or who is right (I don’t think there is any right or wrong in this case), but how the interaction itself occurred because I think it exemplifies how we can work together to further ideas in our industry.

First, I would like to thank Adam for reaching out at all. As an author of papers such as this, it lets me know that people are actually reading the content and taking the time to give it some thought. Many of us in the security industry (and I am guilty of this as well) are great consumers of information, but often do not take the time to contribute our own thoughts. You don’t need to write blogs, whitepapers or speak at conferences to contribute. Providing meaningful feedback and collaboration is what turns good ideas into great ideas that can revolutionize the security industry.

It is common to receive positive feedback regarding a certain point or the content as a whole. While positive feedback is beneficial in letting you know you are on the right track, I would argue that constructive criticism is equally, if not more important. Perhaps it is a resistance to what we might perceive as confrontation, or just not taking the time to put our thoughts to words to share with others, but I would also argue that constructive criticism is often even more beneficial than positive feedback.

Notice that I said constructive criticism and not negative feedback. I think there is an important differentiation here. If you have a Twitter account, you know what I mean by negative feedback. Negative feedback is very seldom the spark for new ideas and creates more divides than bridges. What I really appreciated about Adam’s feedback was the way in which he provided it. Adam was not negative, he was not attempting to poke holes in my premise or tell me why I was wrong. Instead, Adam provided an alternate view in a professional and constructive manner. This lead to additional dialogue which broadened my understanding of the topic and allowed me to consider a viewpoint that I had not previously considered.

Based on my conversation with Adam, I now have a better understanding of a different viewpoint, and the topic as a whole, which will help me continue to evolve my ideas and apply them to a wider array of situations. We are all very busy, but taking 10 minutes from your day to share your thoughts and constructive criticism with someone else is a tremendous way to contribute to the community. Please, be like Adam!

If you are interested in reading the whitepaper Increasing the Effectiveness of Incident Management” is it still available to download.

Overcoming the Tower of Babel in Your Cybersecurity Program

Best practices for communicating cybersecurity risks and efficiency

One of the most difficult challenges encountered within risk management in today’s ever-changing cybersecurity environment is the ability to communicate the risks posed to an organization effectively. Security executives expect communication to be in their own language, focusing on the financial implications regarding gain, loss, and risk, and the difficulty of translating traditional security terms and nomenclature into risk statements expected by business executives poses a serious challenge. Therefore, it is the responsibility of a cybersecurity professional to ensure that security risks are communicated to all levels of the organization using language that can be easily understood.

The communication of security metrics plays a crucial role in ensuring the effectiveness of a cybersecurity program. When disseminating information on cyber risks, several aspects of communication should be considered. For example, a security professional should be cognizant of the credibility of the information’s source, the targeted audience and how to place the risk into perspective. We firmly believe that the success of a business today is directly related to the success of its cybersecurity program. This is largely due to the fact that all organizations depend on technology. Specifically, the interconnectedness of digital technologies translates to a significant potential for damage to an organization’s operational integrity and brand credibility, if its digital assets are not meticulously safeguarded. We only need to look at the recent Equifax breach for an illustrative example of this. Considering the potential impact of cyber attacks and data breaches, organizations must improve how they communicate cybersecurity risk.

The first step to ensuring effective communication of cyber risks involves a comprehensive business impact assessment. This must consider the organization’s business goals and objectives. Business impact assessments focus on how the loss of critical data and operational integrity of core services and infrastructure will impact a business. Furthermore, it acts as a basis for evaluating business continuity and disaster recovery strategies.

The second step is the identification of key stakeholders and their responsibilities. According to experts, this step plays a significant role in being prepared to mitigate the impact of cyber risks. Stakeholders are directly affected by a breach and have the most skin in the game. Identifying stakeholders should not be a one-off exercise but must be conducted regularly. An important consideration is that the more stakeholders there are, the greater the scope for miscommunication. Failure to identify the responsible stakeholders will increase the probability that risk is miscommunicated. In the case of a breach, it means that the response will be ineffective.

The third and most critical step is the identification of Key Risk Indicators (KRIs) tied to your program’s Key Performance Indicators (KPIs). Doing this correctly will mean communicating cyber risks to executives in a way that allows them to make informed decisions. As an example, the amount or the severity of vulnerabilities on a critical system is meaningless to non-technical executives. Stating that a critical system that processes credit card data is vulnerable to data loss is more meaningful. Once business impacts have been assessed, stakeholders have been identified, and meaningful security metrics have been determined, regular communication to various stakeholders can take place.

Different stakeholders have unique needs. This must be considered when communicating KRIs and KPIs. When delivering information, we must accommodate both the stakeholders that prefer summaries and those that prefer reviewing data to make their conclusions. DFLabs’ IncMan generates customizable KPI and incident reports designed to cater to both audiences. Cybersecurity program metrics1 must also focus on costs in time and money to fulfill business needs. The ability to track these metrics is a key differentiator for DFLabs IncMan.

DFLabs’ IncMan is designed to not only provide the best in class incident orchestration and response capabilities but also provides the ability to generate customizable KPI reports that accurately reflect up-to-the-minute metrics on the health of your cybersecurity infrastructure. If your organization needs to get a true, customizable view that incorporates all stakeholders please contact us at [email protected] for a free, no-obligation demonstration of how we can truly keep your cyber incidents under control.

R3 Rapid Response Runbook for Spear Phishing

According to Verizon’s Data Breach Investigations report 2017, social engineering was a factor in 43% of breaches, with Phishing accounting for 93% of social attacks.

DFlabs has worked closely with our customers to draft and deploy Phishing specific runbooks. In this article, we take a look at an example R3 Phishing runbook below.

The Premise
Our premise is that an incident appears to be a Spear Phishing attempt has been forwarded to the SOC. The SOC team must qualify the incident and determine what needs to be done to mitigate the attack.

We begin our investigation with an incident observable, a fully qualified domain name (FQDN).

We will correlate the FQDN with several external threat intelligence services to assess whether this is truly an ongoing Phishing attempt or a benign false positive. We have used VirusTotal and Cisco Umbrella in this example, but other threat intelligence and malware services could be used instead.

We have 3 different potential outcomes and associated decision paths:

R3 Rapid Response Runbook for Spear Phishing 7


The R3 Runbook

1. The FQDN is automatically extracted from the incident alert and then sent to Cisco Umbrella Investigate for a classification.

R3 Rapid Response Runbook for Spear Phishing 1

 

2. Depending on the outcome – whether Cisco Umbrella Investigate classifies the FQDN as benign or malicious – we can take one of two different paths.

R3 Rapid Response Runbook for Spear Phishing 2

 

3. The FQDN will be rechecked with VirusTotal to verify the result. We do this whether the first classification was malicious or benign. At this point we do not know whether one of the two services is returning a false positive or a false negative, so we do a double check.

R3 Rapid Response Runbook for Spear Phishing 3

 

4. IF both external 3rd party queries confirm that the FQDN is malicious, we have a high degree of certainty that this is a harmful Phishing attempt and can step through automatically to containment. In our example, we automatically block the domain on a web gateway.

R3 Rapid Response Runbook for Spear Phishing 4

 

5. Alternatively, if only one of the two queries returns a malicious classification, we need to hand the runbook off to a security analyst to conduct a manual investigation. At this point, we cannot determine in an automated manner where the misclassification resides. It could be that one of the services has stale data, or doesn’t include the FQDN in its database. With the ambiguous result, we lack the degree of confidence in the detection to trust executing fully automated containment.

R3 Rapid Response Runbook for Spear Phishing 5

 

6. If both VirusTotal and Cisco Umbrella Investigate return a non-malicious classification, no further action will be necessary at this point. We will notify the relevant users that the incident has been resolved as a false positive and can close the case for now.

R3 Rapid Response Runbook for Spear Phishing 6

 

This R3 Phishing Runbook demonstrates the flexibility and efficiency of automating incident response . Incident Qualification is automated as much as is feasible but keeps a human in the loop when cognitive skills are required. It only automates containment when the degree of confidence is sufficient. It eliminates false positives without requiring human intervention.

Finding a Balance Between Rapid and Measured Incident Response

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:

  1.  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.
  2.  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.
  3.  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.
  4.  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.
  5.  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.

GDPR & Breach Notification – Finally We Will Get Some European Breach Data

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.

GDPR and Data Breach Notification

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.

Integrating Lessons Learned into Incident Response

Let me start by saying that total prevention is not attainable with today’s technology. Whether through negligence or ignorance, any data stored on a network is subject to unauthorized access by 3rd parties. Instead, we must combine Prevention with Detect and Respond. We know we are going to get breached, so we must focus on the how we deal with that.

One significant activity that can improve cyber incident response and enable the timely mitigation of threats is the transfer of knowledge after an incident as part of a formalized “Lessons Learned” phase of the incident response life cycle. Integrating successful processes and procedures from previously successful incident response activities can play a critical role in determining whether a business will suffer in terms of operational integrity, reputation and legal liability. A publicized security breach will lower customer confidence in the services offered by an organization as well as call into question the safety of their sensitive 3rd party information. This impacts a business credibility and translates directly into lost revenue.

In regulated industries, increased regulatory scrutiny is an additional consequence of a breach. This involves evaluating if the tools and procedures used in responding to security threats were sufficient. Integrating lessons learned into existing and future incident response playbooks ensures that the proper technologies and processes are deployed, and avoids accusations of gross negligence, expensive and time-consuming investigations and regulatory demands.

Procedural improvements can be incorporated into incident workflows via incident playbooks and ensure that all stages of the incident response process have been acknowledged and addressed. It also ensures that required security measures and procedures are documented and relevant stakeholders informed of their roles in case of an incident.

This process can be augmented through machine learning. Applying machine learning to this problem requires that all relevant data associated with incidents are analyzed and automatically applied to future incidents. DFLabs recently released DF-ARK machine learning capability to do precisely this. Our patent-pending Automated Responder Knowledge (DF-ARK) module applies machine learning to historical responses to threats and recommends relevant runbooks and paths of action to manage and mitigate them. DF-ARK requires sufficient training data – it begins with no knowledge, but learns from the experience and actions of your security team, becoming more effective over time. DF-ARK implements supervised case-based reasoning machine learning.

Figure 1DFLabs IncMan Automated Responder Knowledge

It also involves combining automated workflows and manual procedures to keep a human in the loop. This can be constantly improved by applying new observations and data, to fine tune existing methods and procedures identified in the lessons learned phase.

IncMan offers the R3 Rapid Response Runbook engine and Dual Mode playbooks to facilitate this. R3 Runbooks are created using a visual editor and support granular, stateful and conditional workflows to orchestrate and automate incident response activities such as incident triage, stakeholder notification, data and context enrichment and threat containment. Dual Mode Playbooks support manual, semi-automated and automated actions, meaning that users can automate the action without automating the decision.

Adding all of this together, here are 5 best practices for increasing the effectiveness of incident response via lessons learned:

  1. Encourage feedback from responders at every level. First, second and third line SOC operators and incident handlers each have a unique perspective that must be incorporated into future response playbooks.
  2. Review all relevant documentation to ensure compliance. This includes organizational policies or regulatory mandates to ensure any disparities are addressed in future playbooks.
  3. Chronicle any unanticipated or unusual events to extend procedures to mitigate similar occurrences in the future
  4. Annotate enhancements to existing processes that were identified during the incident response cycle.
  5. Designate a business unit or individual to be responsible for making necessary changes to existing playbooks, processes or procedures and to distribute these to stakeholders.

Capitalizing on lessons learned during incident response provides immediate and long-term benefits that contribute crucial time savings necessary to successfully mitigate future threats. Deploying a platform designed to facilitate the rapid inclusion of identified improvements to the incident workflow, such as DFLabs’ IncMan, can not only reduce the time it takes to fully investigate an incident but also reduces the overheads required to do so. If you want more information please contact us at DFLabs for a no obligation demonstration of exactly how we can improve your response time, workflows and remediation activities.

Demolishing the Ivory Tower – Collaboration and Communication in Incident Response

A collaborative environment between IT and security groups is critical. The number of cyber security incidents currently impacting networks and customers is increasing exponentially and mitigating security incidents and risks is more complex than ever before. Timely and effective communication are keys to improved collaboration between all parties involved in the cyber incident response process. One of the simplest and most effective methods to improve communication between all relevant IT and security groups is to deploy a common, shared platform where stakeholders can review and analyze incidents across the entire cyber landscape. A cross-departmental platform enables them to focus on correlating cyber incidents and risks with contextual information relevant to their role and responsibilities plays a significant part in organizational success in this regard.

Incorporating knowledge transfer between disparate business entities often separated both geographically and functionally is essential to facilitate a better understanding of the current IT and security challenges. The preferred method to provide this collaborative environment is via electronic based communication mediums and devices. To tie all of these channels together, an organization should consider deploying a cyber incident response platform, and the platform must be able to integrate these technologies, be it SMS, email or other messaging medium, to cover the broadest range of communication channels to transmit critical information to stake holders.

Another successful strategy that focuses on effectively communicating timely, critical information to relevant stakeholders is via the creation of an incident notification group. IncMan supports the creation of groups of Watchers that are appraised of incidents and activities automatically via SMS, email or an integrated communications system. A Watcher group can ensure that information is properly communicated to the appropriate stakeholder(s). This provides differing stakeholders with the capability of monitoring incidents that may impact business continuity. Additionally, IncMan has integrated communications capabilities comply with industry best practices which recommend having a separate, secure and hardened communications channel if email or other internal communication channels are compromised. This independent messaging capability also provides additional benefits such as asymmetric encryption capabilities.

Leveraging a dedicated solution that can orchestrate the communications to stakeholders standardizes the process of cyber incident response and mitigation and is the key to ensuring a more effective response. If you would like more information or a free no obligation demonstration of how IncMan from DFLabs can more effectively automate and orchestrate your incidents please contact us at [email protected]

 

3 Best Practices for Incident Categorization to Support Key Performance Indicators

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:

  1. 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.
  2. 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.
  3.  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

Slaying the Hydra – Incident Response and Advanced Targeted Attacks

In incident response, protecting against a targeted attack is like slaying the hydra. For those not familiar with what a hydra is, it is a multi-headed serpent from Greek mythology, that grows two new heads for every head you chop off. A determined attacker will try again and again until they succeed, targeting different attack vectors and using a variety of tactics, techniques, and procedures.

The Snowden and Shadowbroker leaks really drove this home, giving partial insight into the toolkit of nation state actors. What really stuck out to me was the sheer variety of utilities, frameworks, and techniques to infiltrate and gain persistence in a target. Without the leak, would it be possible to reliably determine that all of those hacking tools belonged to a single entity? Would a large organization with thousands of alerts and hundreds of incidents every day be able to identify that these different attacks belonged to a single, concerted effort to breach their defenses, or would they come to the conclusion that these were all separate, unrelated attempts?

Our colleagues in the Threat Intelligence and Forensic analysis industries have a much better chance to correlate these tools and their footprint in the wild – they may discover that some of these tools share a command and control infrastructure for example. A few did have at least an outline of the threat actor, but judging by the spate of advisories and reports that were released after the leaks, not very many actually appear to have achieved this to a great degree. The majority were only able to piece the puzzle together once equipped with a concise list of Indicators of Compromise (IoC) and TTP’s to begin hunting with.

“How does this affect me? We are not important enough to attract the attention of a nation state actor”

Some readers may now be thinking, “How does this affect me? We are not important enough to attract the attention of a nation state actor”. I would urge caution in placing too much faith in that belief.

On the one hand, for businesses in some countries the risk of economic espionage by-nation state hacking has decreased. As I wrote on Securityweek in July, China has signed agreements with the USA, Canada, Australia, Germany and the UK limiting hacking for the purpose of stealing trade secrets and economic espionage. However, this does not affect hacking for national security purposes, and it will have little impact on privately conducted hacking. These are also bilateral agreements, and none exist in other nations, for example, Russia or North Korea. For militarily and economically weaker nation states, offensive cyber security is a cheap, asymmetric method of gaining a competitive or strategic advantage. As we have seen, offensive cyber activity can target civilian entities for political rather than economic reasons, and hackers are increasingly targeting the weakest link in the supply chain. This means that the potential probability of being targeted is today based more on your customer, partner, and supply chain network, and not just on what your organization does in detail. Security through obscurity has never been a true replacement for actual security, but it has lost its effectiveness as targeted attacks have moved beyond only focusing on the most prominent and obvious victims. It has become much easier to suffer from collateral damage.

Cyber criminals are becoming more organized and professional

On the other hand, cyber criminals are becoming more organized and professional, with individual threat actors selling their services to a wide customer base. A single small group of hackers like LulzSec may have a limited toolbox and selection of TTP’s, but professional cybercrime groups have access to numerous hackers, supporting services and purpose-built solutions. If they are targeting an organization directly and are persistent and not opportunistic, it will be as difficult to discern that a single concerted attack by one determined threat actor is taking place.

What this means in practical reality for any organization that may become the target of a sophisticated threat actor, is that you have to be on constant alert. Identifying, responding to and containing a threat is not a process to be stepped through with a final resolution step – instead, cyber security incident response is an ongoing, continuous and cyclical process. Advanced and persistent attacks unfold in stages and waves, and like a war consist of a series of skirmishes and battles that continue until one side loses the will to carry on the conflict or succeeds in their objectives. Like trying to slay the hydra, each incident that you resolve means that the attacker will change their approach and that the next attempt may be more difficult to spot. Two new heads have grown instead of one.

To tackle this requires that we cultivate a perpetual state of alertness in our SOC and CSIRT

To tackle this requires that we cultivate a perpetual state of alertness in our SOC and CSIRT – but we must do this without creating a perpetual state of alarm. The former means that your team of analysts is always aware and alert, looking at individual incidents as potentially just one hostile act of many that together could constitute a concerted effort to exfiltrate your most valuable data, disrupt your operational capacity, or abuse your organization to do this to your partners or customers. In the latter case, your analysts will suffer from alert fatigue, a lack of true visibility of threats, and a lack of energy and time to be able to see the bigger picture.
The hydra will have too many heads to defeat.

In the Greek legend of Heracles, the titular hero eventually defeats the Hydra by cauterizing each decapitated stump with fire to prevent any new heads from forming. Treating an incident in isolation is the Security Incident Response equivalent of chopping off the head of the hydra without burning the stump. Applied to our problem, burning the stump means that we have to conduct the response to each incident thoroughly and effectively, and continue the process well beyond containment.

We must invest more time in hunting and investigating, and we have to correlate and analyze the relationship between disparate incidents. We must use threat intelligence more strategically to derive situational awareness, and not just tactically as a machine-readable list of IoC’s. This also requires gathering sufficient forensic evidence and context data about an incident and related assets and entities during the incident response process, so that we can conduct post event analysis and continuous threat assessment after containment and mitigation have been carried out. This way we can better anticipate the level of threat that we are exposed to, and make more informed decisions about where to focus our resources, add mitigating controls and improve our defenses. In Incident Response “burning the stump” means making it more difficult for threat actors to succeed in the future by presenting them with a hardened attack surface, reducing their reside time in our infrastructure, and reducing the time we need to discover and contain them. To do this we need to learn from every incident we manage.