Companies Are Failing at Incident Response: Here Are The Top Reasons Why

Discussions about security breaches often focus on the planning elements, but simply talking about planning is not enough. Comprehensive plans need to be drawn up, fully executed and regularly reviewed in order to be successful. This is the only way to potentially contain the breach and limit the impact it could have on the organization. Properly planning and implementing is the difference between success and failure for companies when it comes to security and incident response.

As the ever-evolving cyber security landscape poses new challenges, companies are pushed even more to fight back the growing number and even more sophisticated levels of cyber attacks. Organizations across all sectors and industries are potential targets and could become victims at any time. With attacks escalating in all areas, whether via phishing or malware, for example, security operations teams need to be prepared to respond to existing and new types and strains of threats, in order to fully defend and protect their company assets and networks.

Along with prevention becoming increasingly difficult for security teams, some organizations also tend to have a weakness when it comes to incident response. Below outlines some of the main reasons why this failure is happening today and if this a true representation of your organization, it is important for action to be taken in order to improve it.

Inadequate Resources

With the number of sophisticated cyber threats in the past several years growing at a phenomenal rate, the security industry has been facing an explosion of security tools available in the market. Many of these though have adversely resulted in creating more tasks for security teams and analysts in terms of monitoring, correlating, and responding to alerts. Analysts are pushed to work on multiple platforms and generate data from every single source manually, while afterwards then needing to enrich and correlate that data which can take many hours or even days.

Security budgets are often limited, and while it is often easier to gain support and approval for additional security apps and tools than it is for additional staff members, this means that many security teams often are forced to search innovative ways to perform many different tasks with extremely limited personnel resources.

Another important point to note is that with increased market competition for experienced and skilled analysts, companies are often forced to choose between hiring one highly skilled staff member versus a couple of less experienced, junior level ones.

Task Overload

Over the years, organizations have witnessed an increasing number of security tools to fight back the growing number of security threats. But even though these tools manage alerts and correlate through security information and management system, security teams are still overwhelmed by the volume of alerts being generated and in many instances are not physically able to respond to them all.

Every single alert must be verified manually and triaged by an analyst. Then, if the alert is determined to be valid, additional manual research and enrichment must take place before any other action to address the threat. While all of these processes take place, other potential alerts wait unresolved in a queue, while new alerts keep being added. The problem is, any one of these alerts may be an opportunity window for an attacker while they wait to be addressed.

Risk of Losing Skilled Analysts

Security processes are performed manually and are quite complex in nature, therefore training new staff members takes time. Organizations still rely on the most experienced analysts when it comes to decision making, based on their knowledge and work experience in the company, even with documented procedures in place. This is commonly referred to as tribal knowledge, and the more manual the processes are, the longer the knowledge transfer takes. Moreover, highly qualified analysts are considered a real treasure for the company, and every time a company loses such staff member, part of the tribal knowledge is also lost, and the entire incident response process suffers a tremendous loss. Even though companies make efforts to keep at least one skilled analyst who is able to teach other staff members the skills they have, they aren’t always successful in that.

Failure to Manage Phases

Security teams work with metrics that could be highly subjective and abstract, compared to other departments which often work with proven processes for measuring the effectiveness or ineffectiveness of a program. This is largely due to the fact that conservative approaches and methods for measuring ROI aren’t applicable, nor appropriate when it comes to security projects, and might give misleading results. Proper measurement techniques are of utmost importance when it comes to measuring the effectiveness and efficiency of a security program, therefore it is necessary to come up with a measurement process customized according to the needs of the company.

Another important issue that should be mentioned here is the one concerning the management of different steps of the incident response process. Security incidents are very dynamic processes that involve different phases, and the inability to manage these steps could result in great losses and damages to the company. For the best results, companies should focus on implementing documented and repeatable processes that have been tested and well understood.

In order to resolve these issues, organizations should consider the following best practices.

Orchestration

The coordination of security data sources and security tools in a single seamless process is referred to as orchestration. Technology integrations are most often used to support the orchestration process. APIs, software development kits, or direct database connections are just a few of the numerous methods that can be used to integrate technologies such as endpoint detection and response, threat intelligence, network detection, and infrastructure, IT service and account management.

Automation

Orchestration and automation might be related, but their end goals are completely different. Orchestration aims to improve efficiency by increased coordination and decreased context switch among tools for a faster and better-informed decision-making, while automation aims to reduce the time these processes take and make them repeatable by applying machine learning to respective tasks. Ideally, automation increases the efficiency of orchestrated processes.

Strategic and Tactical Measurement

Information in favor of tactical decisions usually consists of incident data for analysts and managers, which might consist of indicators of compromise assets, process status, and threat intelligence. This information improves decision-making from incident triage and investigation, through containment and eradication.

On the other hand, strategic information is aimed at executives and managers, and it’s used for high-level decision making. This information might comprise statistics and incident trends, threat intelligence and incident correlation. Advanced security programs might also use strategic information to enable proactive threat hunting.

If these challenges sound familiar within your security operations team, find out how DFLabs’ Security Orchestration, Automation and Response solution can help to address these to improve your overall incident response.

Key Elements of Every Successful Incident Response Program

Nowadays, businesses face the fact that cyber attacks are part of the overall picture, and will happen at any given moment. Nobody is in doubt about this, and the question has shifted from ‘if they happen’, to ‘when they happen’. Along with this, cybercriminals have become much more sophisticated, raising the costs of fighting back on all industry levels.

Managing cyber security issues can pose a real challenge within a company. The new and complex networks, business requirements for innovation and new ways of delivery of services require new methods and approaches to the way security is handled. Traditional security management methods no longer work. Today, cyber security management should aim towards efficiency when it comes to possible future threats.

Serious data breaches can cost a company hundreds of millions of dollars. Often, what makes a breach serious is the effectiveness and speed of the incident response process.

This being said, creating an incident response program is of utmost importance. It has to excel in the following areas: visibility, incident management, workflows, threat intelligence, and collaboration/information-sharing. Below we’ll take a closer look at each of these areas and discover their importance from a systems level perspective.

Visibility

Having in mind the number of security products in an average company, visibility should be the core of any incident response system – this means aggregating data feeds from commercial and open-source products. When setting up an incident response system, specialists should consider platforms that offer support for security products out of the box. Although not all of them support everything by default, the one you choose should be flexible to add bi-directional integrations with security products not supported by default. But even though bi-directional integrations are important for the support of full automation and orchestration, these are not always necessary for each technology. For example, with simple detection and alerting technologies, unidirectional event forwarding integration will do the work. Just check that common methods of event forwarding and data transfer (such as syslog, database connections, APIs, email and online forms) are supported.

Incident Management

A well-structured incident response program should enable orchestration and automation of the security products that the organization uses. Above everything else, it should include the ability to manage the entire incident response process, starting from the basics, such as tracking cases, recording actions during the incident, as well as reporting on critical metrics and KPIs.

Furthermore, a more advanced incident response system should provide the following:

  • Phase and objective tracking
  • Detailed task tracking, including assignment, time spent and status
  • Asset management — tracking all physical and virtual assets involved in the incident
  • Evidence and chain of custody management
  • Indicator and sample tracking, correlation and sharing
  • Document and report management
  • Time and monetary effort tracking
Process Workflows

One of the key capabilities that should part of the incident response system is the automation and orchestration workflows. The result is more efficient processes and heavy reduction in repetitive tasks for analysts.

These are the core methods for a codification of process workflows: linear-style playbooks or flow-controlled workflows or runbooks.

Both methods have advantages and disadvantages, and as each is suitable for different use cases, they both should be supported by the incident response system. In both cases, workflows should be flexible and support almost any process, and should support the use of built-in and custom integrations, and creating manual tasks that should be completed by an analyst.

Threat Intelligence

The capability of incorporating threat intelligence feeds is one of the most basic requirements for an incident response system. Moreover, with the ability to correlate threat intelligence, it’s easier to discover attack patterns, vulnerabilities, and other current risks without manual analysis. Adding the automated correlation also helps identify whether an ongoing incident shares common factors with any previous incidents. But even though automated correlation is crucial for analysts to make decisions, visual correlation is also important. Visualizations of threat intelligence and correlated events are particularly useful for threat hunting and detecting attacks/patterns that could not have been detected using other methods.

Collaboration and Information-Sharing

Incident response is never a one-person show. Generally, it requires the participation of many people, and often of multiple teams. To be highly effective in such an environment, an incident response system should support seamless collaboration and information-sharing between all stakeholders and team members.

This means that authorized staff members should have access to the status of the incident and other generated information, including team members actions. Also, all staff members should communicate in a secure fashion, using out-of-band communications mechanism.

Furthermore, information-sharing and cooperation should be a regular practice with external entities, especially with law-enforcement agencies. Information-sharing, such as threat intelligence reports, is vital in the fight against cybercrime.

Conclusion

Most companies will experience data breach sooner or later, and how they respond will affect the future of the business. These essential components will help ensure that an organization’s incident response program can detect, contain and mitigate a breach before it can reach more serious status.

How to Perform Threat Hunting and Incident Response on Live Hosts

Performing threat hunting and incident response on live hosts, collectively referred to here as live analysis, can be a complicated task. When performed properly, they can detect and preserve volatile artifacts, such as network connections, running processes, hooks and open files, which may be the only evidence of today’s advanced attacks. Live analysis may also be the only option when taking a host offline for traditional disk forensics is not an option, such as with business-critical application servers or domain controllers. However, if performed improperly, they can alert attackers to your presence, destroy critical information or render any evidence gathered inadmissible in legal proceedings.

Live forensics and live threat hunting

Live forensics and live threat hunting begin as two different processes. When performing live forensics, we typically start with a pivot point; something has already been detected as anomalous which has prompted us to examine the host. During live threat hunting, we are seeking that anomaly, that indicator of potential malicious activity, to use as a pivot point for further investigation. Once that initial indicator has been discovered, the traditional incident response process, often involving further live forensics begins.

Unique challenges

Performing live analysis poses several unique challenges when compared to traditional offline disk forensics. Although any forensic process must be documented and repeatable, these attributes are especially important when performing live analysis. Unlike offline disk forensics, where the original evidence should theoretically remain static and unchanged, live evidence is constantly changing. In fact, we are changing the live evidence by performing live forensics. Although the live analysis process is repeatable, it cannot be repeated while achieving exactly the same results; processes start and end, network connections are terminated, and memory is re-allocated. This means that our live analysis processes must be able to stand up to increased scrutiny.

Because live analysis involves executing commands on a running host, it is crucial that the process is also performed in a secure manner. Only trusted tools should be executed. Each tool and the commands used to execute them should be tested prior to being executed during a live analysis to ensure that the results are known and only the intended actions occur. It is also important to ensure that the tools and commands you tested are the same ones being executed during each live analysis situation.

On Friday, September 7th, I will be speaking at the SANS Threat Hunting and IR Summit in New Orleans regarding some of the challenges and best practices when performing threat hunting and incident response on live hosts. I will also be demoing DFLabs free tool, the No-Script Automation Tool (NAT), which can be used to assist in the live data acquisition process. If you have not had a chance to see NAT, please check out our blog post hereand our demo video here.

Also, find out which top cyber security events DFLabs will attend this fall.

I hope to see you all at the SANS Threat Hunting and IR Summit soon. Safe travels and avoid the storm!

Streamline Incident Management and Issue Tracking Using DFLabs SOAR and Jira

Security incidents are complex and dynamic events, requiring the coordinated participation from multiple teams across the organization. For these teams to work with maximum efficiency, as a single body, it is critical that information flows seamlessly between all teams in real-time. Faced with a continued onslaught of security incidents, organizations must find ways to maximize the utilization of their limited resources to remain ahead of the attackers and ensure the integrity of the organization’s critical resources.

This blog will briefly discuss how your security operations team can manage security incidents in a whole new and efficient way by integrating DFLabs IncMan Security Orchestration, Automation and Response (SOAR) platform with your existing Jira solution, including a simple use case.

It is critical to bridge the gap between security teams orchestrating incidents with SOAR solutions such as IncMan and teams tracking other tasks with Jira, to ensure that all teams maintain a holistic view of the incident and function together as a single, unified body.

The Challenges

Today there are many challenges faced by security teams within their specific security programs. By integrating DFLabs IncMan SOAR with Jira you will be able to overcome the following key problems:

  • How can I ensure that all teams have the most up-to-date incident information?
  • How can I integrate the power of IncMan into my existing issues management process?
  • How can I enable all teams to work as a single unified body to increase the efficiency of the incident response process?
  • How can I quickly communicate critical information to those outside the security team?


Let’s discuss how in more detail.

How to Streamline Incident Management and Issue Tracking With The DFLabs SOAR and Jira Solution

Security operations teams struggle to gain visibility of threats and rapidly respond to cyber incidents due to the sheer number of different security technologies they must maintain and manage and the resulting flood of alerts. Aggregating these into a single pane of glass to prioritize what is critical and needs immediate attention requires a platform that can consolidate disparate technologies and alerts, and provides a cohesive and comprehensive capability set to orchestrate incident response efforts.

Jira’s industry-leading issue tracking solution has been battle-tested and becomes the core of an organization’s support, IT, incident response and project management processes worldwide. Jira allows teams from across the organization to collaborate and share information to plan, track and report projects and issues in real-time, maximizing efficiency and reducing impacts on the organization’s critical business processes.

By integrating with Jira, DFLabs IncMan extends these capabilities to Jira users, combining the orchestration, automation and response power of IncMan with the organization’s existing issue tracking process. IncMan’s R3 Rapid Response Runbooks can be used to automatically create issues within Jira and continue to update the issue as the incident progresses.

Allowing organizations to seamlessly share information between IncMan and Jira ensures that all involved in the incident response process are working with a unified set of information, enabling organizations to maximize security analyst efficiency, reduce incident resolution time, as well as reduce the number of incidents handled.

Use Case

An alert of a host communicating with a potentially malicious domain has automatically generated an Incident within IncMan.This alert is automatically categorized within IncMan based on the organizations’ policies, which initiates the organization’s Domain reputation runbook, shown below:

incident management DFLabs


Through this runbook, IncMan automatically gathers domain reputation information for the domain which generated the alert. If the resulting domain reputation information indicates that the domain may be malicious, IncMan will use a Notification action to automatically create a new Issue within Jira, allowing Jira users to immediately begin next steps. Next, using additional Enrichment actions, IncMan will automatically gather additional information regarding the suspicious domain, such as WHOIS and geolocation information. IncMan will then automatically update the Jira issue with this information. Finally, a screenshot of the page (if applicable), is taken and added to IncMan.

The automated workflow of IncMan’s R3 Runbooks means that an IncMan incident and Jira issue will have been automatically generated, and these enrichment actions through the Quick Integration Connector with Jira and other enrichment sources will have already been committed before an analyst is even aware that an incident has occurred. Both IncMan and Jira users are now able to perform their respective tasks, knowing that they are each working with the same information, and can continue to do so as the incident progresses.  

By harnessing the power of Jira’s industry-leading issue tracking solution, along with the orchestration, automation and response capabilities of DFLab’s IncMan SOAR platform, organizations can elevate their incident response process, leading to faster and more effective incident response and reduced risk across the entire organization.

If you would like to see IncMan and Jira in action together in more detail, get in touch to request a live demo of IncMan with one of the team.

Enabling Faster and More Efficient Cyber Security Incident Response with LogPoint SIEM and DFLabs SOAR

Cyber Security Incidents: The Problem and Challenges

Cyber security incidents are complex, potentially involving numerous assets being monitored by a myriad of different prevention and detection technologies. Investigating a cyber security incident requires the involvement of many different people, processes and technologies, all of which must work together seamlessly for an effective and efficient response. Failure to properly orchestrate these many moving parts can lead to increased risk, exposure and losses.

During a cyber security incident, context is key. Without proper context, analysts and managers are unable to make informed decisions regarding potential risk, containment, and recovery. Providing this necessary context can be a manual, time-consuming tasks, wasting valuable time as attackers continue to move throughout the network unobstructed.

Therefore, it is critical for security programs to implement an overall solution that aims to solve three key challenges:

  1. How can I use my existing resources more effectively?
  2. How can I reduce the mean time to detection (MTTD)?
  3. How can I reduce the mean time to response (MTTR)?

Combine the Power of LogPoint SIEM with DFLabs SOAR to Enable Faster and More Efficient Cyber Security Incident Response

The DFLabs and LogPoint Solution

DFLabs IncMan Security Orchestration, Automation, and Response (SOAR) platform automates, orchestrates and measures security operations and incident response tasks including threat validation, triage and escalation, context enrichment and threat containment. IncMan uses machine learning and Rapid Response Runbooks (R3 Runbooks) as a force multiplier that has enabled security teams to reduce average incident resolution times and increase incident handling.

LogPoint’s SIEM system is designed from the ground up to be simple, flexible, and scalable, providing a streamlined design, deployment, and integration tools to open the use of SIEM tooling up to all businesses. This means that the architecture can be continuously extended with additional functionality without the need for a full major release, to continue to support your business’s growing and changing needs.

Each as their standalone solution has their merits but also have their limitations. SIEMs are traditionally more commonly used within security operations infrastructure, ingesting large volumes of data, providing real-time analytics while generating alerts, but not all of these alerts can realistically be handled manually by security analysts. Orchestration and automation are critical components in responding effectively and efficiently to a cyber security incident. DFLabs IncMan SOAR platform is layered on top of the SIEM to manage the incident response process to each alert. Combing the aggregation, storage and analytics power of LogPoint with the orchestration, automation and response power of IncMan drastically multiplies the impact of the existing security program by removing the analyst from the repetitive, mundane tasks, allowing analysts to focus their time and energy where they can have the greatest impact.

Together they can provide security programs with the ability to:

  1. Automate repeatable, mundane tasks.
  2. Orchestrate actions across multiple security tools.
  3. Enrich raw data, allowing for more informed, effective decisions.
  4. Reduce the mean time to detection and mean time to response, minimizing potential risk.
Use Case in Action

A proxy has observed an internal host communicating with an IP address which is known to be a command and control server used by malicious actors.  The proxy generated an alert, which was forwarded to LogPoint. Using the IncMan app, Logpoint automatically forwarded the event to IncMan, which automatically generated an incident and began an automated response, including executing the R3 Runbook shown below.

The runbook begins by performing several basic Enrichment actions, such as performing a Whois query and an IP geolocation search. These Enrichment actions are followed by a Containment action, which is used to block the malicious IP address at the perimeter firewall.

Once the initial IP address is blocked, an additional Enrichment action is used query LogPoint for a list of all IP addresses the internal host has communicated within the past 30 minutes. Next, an Enrichment action is used to query each of these IP addresses against the organization’s threat reputation service of choice (for example, VirusTotal, Cisco Umbrella or McAfee ATD).

Any IP addresses which have a negative reputation will undergo a similar process to the initially identified malicious IP address; first utilizing several Enrichment actions to perform basic data enrichment, then being blocked at the perimeter firewall using a Containment action.

Once these IP addresses have been blocked to prevent any additional risk, LogPoint is again queried; this time for any other internal hosts which may have been communicating with these additional malicious IP addresses.

If any other internal hosts have been observed communicating with any of these additional malicious IP addresses, a final Enrichment action will be used to gather further information regarding each internal host from the IT asset inventory. This information will be automatically stored within the IncMan Incident and will be available for an analyst for review and follow up.

To ensure that each additionally potentially compromised internal host is further investigated by an analyst, a Notification action is used to immediately notify security team leaders about the identification of these additional potentially compromised hosts. If the organization were utilizing an IT ticketing system, an additional integration could be used to automatically generate an IT ticket to ensure additional accountability.

Minimizing the time from threat discovery to resolution from hours to seconds

The combination of a SIEM and a SOAR solution can provide real end-to-end visibility to neutralize potential cyber threats. By providing early detection and faster remediation of security incidents it can totally transform the security operations and incident response capability of any organization’s security program. Adopting this structure will inevitably minimize the time from threat discovery to resolution but can also have a positive impact on many other factors including improved operational performance, increased return on investment of existing security technologies, reduced risk resulting from security incidents while meeting legal and regulatory compliance.

The Top 5 Challenges Faced by Security Operations Centers

Not so long ago we used to hear about a cyber-attack or a new form of vulnerability in the news perhaps on a quarterly or monthly basis.  Today, they are becoming increasingly more frequent and I don’t think a day goes by that we don’t read in the headlines about the consequences an organization is having to face, due to another attack. McAfee recently reported a staggering eight new cyber threats a second in Q4 2017.  

With the sophistication of attacks also continuously evolving, the modern CISO is now facing up to the fact and preparing for a “when it will happen” scenario as opposed to “if it will happen”, as cyber incidents become more inevitable. Based on this, their cybersecurity strategy is being turned on its head and instead of focusing more on how to prevent an incident from occurring in the first place, they are now heavily investing in technologies and solutions to help identify, manage and contain an incident, in order to minimize the impact to the organization when it does occur.  

In larger enterprises today, it is common to have a Security Operations Center (SOC) and/or a Computer Security Incident Response Team (CSIRT) to monitor, manage and respond to incoming security alerts, but with this, there are numerous challenges that are continuously being faced.  Our recent blog “How to Implement Incident Response Automation the Right Way” specifically addressed the challenge of increasing volumes of alerts, resulting in an exponential volume of mundane tasks and discussed how utilizing automation should be implemented to overcome this. In reality, the number of challenges is probably many more than what we will cover in this blog, but here are our top five, which we believe are currently having the biggest effect on SOCs and CSIRTs today.

Top 5 Challenges Faced by Security Operations Centers

1.  Increasing Volumes of Security Alerts

With the snowballing number of security alerts being received, valuable analyst time is being consumed sorting through a plethora of security alerts.  Most commonly, time is wasted performing a multitude of mundane tasks to triage and determine the veracity of the alerts, often resulting in alerts being missed or those of more damaging consequences slipping through the net as they are overlooked.  As you can probably imagine, analysts time would be better spent working on the more sophisticated alerts that need human intervention, as well as proactively threat hunting, in order to minimize the time from breach discovery to resolution.

 2. Management of Numerous Security Tools

As a wider range of security suites are being adopted by SOCs and CSIRTs, it is becoming ever more difficult to effectively monitor all of the data being generated from the multiplying number of data points and sources.  A typical security operations center may use a combination of 20 or more technologies, which understandably can be difficult to monitor and manage individually. It is therefore important to be able to have a central source and single platform to summarize all of the information as it is being generated and to be able to have a helicopter view of your overall security environment to manage, monitor, and measure security operations and incident response processes effectively.

3.  Competition for Skilled Analysts and Lack of Knowledge Transfer Between Analysts

With the global cybersecurity talent shortage to hit 1.2m by 2020 and to increase to 1.8m by 2022, the pool of suitable analysts will only continue to diminish over time, with the level of competition becoming more fierce for analysts that have the required skill set.  As with most companies and industries, workforce comes and goes, but knowledge transfer is particularly important within a security operations center and incident response teams, in order to ensure the correct response and process takes place within the minimal amount of time, reducing the time to incident detection and time to incident resolution. This lack of knowledge transfer can inevitably lead to increased response times and wasted resources.

4. Budget Constraints with Security Incidents Becoming More Costly

As within most organizations large or small alike, budgets are always restricted in some way, shape or form. In order to authorize spending, a clear positive ROI usually needs to be forecast and/or proven. Security operations and incident response are notoriously difficult to measure, monitor and manage, (why not read our recent whitepaper entitled “KPIs for Security Operations and Incident Response” to learn more), so justifying spend is always difficult.  With the increasing number of cyber-attacks, organizations are increasing the level of investment in cyber security tools, but what level of spending is necessary and what amount outweighs the benefits it will achieve? Can you put a price on the consequences of a potential incident such as a data breach, knowing you will likely face a hefty fine, as well as brand and reputation damage?

5. Legal and Regulatory Compliance

Meeting a growing number of legal and regulatory compliance such as NIST, PCI, GLBA, FISMA, HITECH (HIPPA) and GDPR to name a few, as well as industry best practices, will inherently have an impact on any organization, but can have a heavy bearing depending on the specific industry or geographical location.  Using the example of the upcoming Global Data Protection Regulation, taking effect on May 25, 2018, it is even more important for security operations centers to have mandatory processes and procedures clearly in place which are conducted in a legally and policy-compliant manner.  Providing sufficient incident reporting and breach notification within the required parameters (in the case of GDPR to notify the supervisory authority within 72 hrs of a breach) is going to be key, or the legal, financial and reputational impact and repercussions could be significant.      

Based on these five challenges alone, enterprise SOCs and CSIRTs are struggling to remain efficient and effective and are increasingly being forced to do more with less, while striving to keep up with the current threat landscape and a plethora of security alerts.  

With security incidents becoming more costly, enterprises need to find new ways to further reduce the mean time to detection and resolution.  As a result, security and risk management leaders will see the business need to invest in Security Orchestration, Automation and Response (SOAR) technology and tools, such as the IncMan SOAR platform from DFLabs, to help improve their security operations proficiency, efficacy, and quality, in order to keep their cyber incident under control.

If you are interested in reading more about how SOAR technology can help to address these challenges in more detail, look out for our future blog on the topic coming soon.

How to Implement Incident Response Automation the Right Way

One of the most pressing challenges facing cyber security professionals nowadays is probably the sheer number of security incident alerts, which is becoming too high to cope with even for the most expansive and well-equipped security teams. The increased number of alerts is a result of two factors at play, with the exponential boost in cyber attacks in recent years being the more obvious and straightforward one, the other is certainly much more complex and might also seem a bit ironic and surprising, as it arises from the growing use of different tools and devices within an organization, whose original function is to detect and mitigate incidents in the first place.

Security Operations Centers (SOCs) are now utilizing more devices designed to alert security analysts of cyber attacks than ever before, with the side-effect being too many alerts for the security teams to handle. Consequently, some of the most credible threats go by undetected or are simply not acted upon.

Addressing the Threat Noise Issue

With so many systems monitoring potential security threats and incidents creating alerts, and also taking into consideration that in many cases SOCs are severely understaffed, it comes as no surprise that analysts have a hard time staying on top of every single alert and responding to them appropriately and in a timely fashion. Since they don’t have the time or sufficient human resources to handle all alerts, SOCs often choose to disregard some and try to focus on those they deem to be credible, which understandably can lead to real threats slipping through the cracks and inflicting serious and irreparable damage to organizations.

In an effort to address the issue of threat noise, some SOCs opt for either reducing the number of devices generating alerts or expanding their number of staff, but while seemingly simple and straightforward, these options can be both counterproductive and quite costly. However, these are not the only possible solutions to this challenge standing at the disposal of SOCs, as there is another alternative, which would neither allow alerts to go undetected, nor require hiring additional security analysts.

Automating the Most Time-Consuming Parts of the Process

While the number of alerts generated by monitoring devices in some cases doesn’t necessarily have to be a reason for concern for SOCs in itself, the fact that alerts take a significant amount of time to analyze and handle efficiently often makes them an insurmountable challenge for understaffed security teams. One potentially very promising tactics to tackle this challenge effectively, is by enabling an automated response to some specific types of alerts, in an approach that is thought to be able to yield a wide range of benefits to organizations.

The idea is to automate the routine tasks that are repetitive and that do not require a lot of human expertise, but do usually take a lot of time to respond to and handle. By automating the response to these types of alerts, SOC analysts get more time to handle the alerts that pose a greater risk to their organizations, which must be analyzed in a more focused and comprehensive manner.

As noted in a recent SANS Spotlight paper titled “SOC Automation – Disaster or Deliverance”, written by Eric Cole: “The rate at which organizations are attacked is increasing, as is the speed at which those attacks compromise a network – and it is not possible for a human to keep up with the speed of a computer. The only way to beat a computer is with a computer”.

However, it must be noted that the implementation of incident response automation itself brings a certain degree of risk to organizations, as it might produce false positives, with  analysts not being able to determine whether specific alerts are legitimate threats or not. This means that if automation is not properly implemented with predetermined processes and procedures in place, they may end up spending much of their time analyzing alerts that aren’t actual attacks and don’t pose any foreseeable danger. Having said that, organizations should not shy away from automation because of these potential drawbacks, but should instead implement it in a balanced and well thought out manner. The key is to manage and control false positives as oppose to simply eliminating them. It is therefore important to only automate the low-risk alerts that are not expected to have a major impact on an organization and leave the more serious threats to be handled by security professionals who can apply their expertise to resolve them.

When deciding whether to adopt automation or not, organizations need to be aware of its pros and cons, and if this assessment is carried out correctly, they will inevitably realize that the advantages of this approach clearly outweigh the disadvantages, that can also be easily controlled and managed to minimize any potential negative impact.

Looking at the pros and cons of automation, it’s easy to see that the most important benefit is the fact that it allows SOCs to monitor and analyze many more incidents than doing it manually, opening up the security team’s bandwidth to focus on the high-risk and high-impact alerts.  Other key benefits also include: a more consistent response to alerts and tickets, a higher volume of ticket closure and response to incidents, as well as coverage of a larger area and larger number of tickets. On the other hand, automation can yield false positives that for their part can lead to directing time and resources towards resolving alerts that are not legitimate attacks, consequently leading to organizations potentially shutting down operations, having an impact on their business and their bottom line.

All said and done, automated incident response has the potential to bring significant benefits to organizations, provided that it’s implemented properly and cautiously, with a well-thought out strategy.  Overall it should be a serious consideration for any SOC that has to handle large volumes of alerts on a daily basis.

100-Day Countdown to GDPR

For many of us around the world February 14th marks St. Valentine’s Day, but for those of us in Europe, this date also marks the beginning of the 100-day countdown to the upcoming enforcement of the General Data Protection Regulation (GDPR).

As most of us are already aware the EU GDPR was adopted in April 2016 and is due to be formally imposed on May 25th, 2018. In a nutshell for those who are not quite so GDPR savvy, the GDPR emphasizes transparency, security, and accountability by data controllers and introduced mandatory Data Protection Impact Assessments (DPIAs) for those organizations involved in high-risk processing. For example, where a new technology is being deployed, where a profiling operation is likely to significantly affect individuals or where there is large-scale monitoring of a publicly accessible area.

Breach Notification Requirements

A DPIA is the process of systematically considering the potential impact allowing organizations to identify potential privacy issues before they arise and come up with a way to mitigate them. In addition, and a highly important aspect for Security Operation Centers (SOCs) and Computer Security Incident Response Teams (CSIRTs) to be fully aware of and responsive to, data processors must implement an internal breach notification process and inform the supervisory authority of a breach within 72 hours. They must also communicate the breach to affected data subjects without due delay or consequently face a penalty of up to EUR 20,000.00 or 4% of worldwide annual turnover for the preceding financial year, whichever is greater.

Incident Response Processes and Best Practices

As the number of breaches has risen and cyber attacks have become more sophisticated, authorities have recognized a need for increased data protection regulation. The number of simultaneous processes required in a typical forensic or Incident Response Scenario has also grown. Processes need to cover a broad spectrum of technologies and use cases must be standardized, and must perform clearly defined, fully documented actions based upon regulatory requirements, international standards and established best practices.

Additionally, context enrichment and threat analysis capabilities must be integrated to facilitate and automate data breach reporting and notification within the timeframe specified by GDPR. Lastly, customized playbooks must be created to permit rapid response to specific incident types, aid in prioritizing tasks, assignment to individual stakeholders, and to formalize, enforce and measure specific workflows.

Incident Response Management with DFLabs IncMan

Having a platform in place to formalize and support these requirements is crucial. DFLabs IncMan provides all the necessary capabilities to facilitate this. Not only do organizations need an Incident Response plan, they must also have a repeatable and scalable process, as this is one of the steps towards compliance with the GDPR’s accountability principle, requiring that organizations demonstrate the ways in which they comply with data protection principles when transacting business. They must also be able to ensure that they will meet the 72-hour breach notification requirement or face a stiff penalty.

Find out how IncMan can help you become GDPR compliant

Organizations must establish a framework for accountability, as well as a culture of monitoring, reviewing and assessing their data processing procedures to detect, report and investigate any personal data breach. IncMan implements granular and use-case specific incident response procedures with data segregation and critical security control requirements. To enable Incident Response and breach notification in complex organizations and working across different regions, IncMan can be deployed as a multi-tenant solution with granular role-based access.

Cutting Response Time and Accelerating Incident Containment

Automated responses can be executed to save invaluable time and resources and reduce the window from discovery to containment for an incident. Organizations can easily prepare advanced reports from an automatically collected incident and forensic data, and distribute notifications based on granular rules to report a breach and notify affected customers when required to comply with GDPR and avoid a financial penalty.

Finally, the ability to gather and share intelligence from various sources by anonymizing the data to share safely with 3rd party protect the data without inhibiting the investigation. IncMan contains a Knowledge Base module to document playbooks, threat assessment, situational awareness and best practices which could be shared and transferred across the organization.

IncMan and Fulfilling GDPR Requirements

In summary, DFLabs IncMan Security Automation and Orchestration platform fulfills the requirements of GDPR by providing capabilities to automate and prioritize Incident Response through a range of advanced playbooks and runbooks, with related enrichment, containment, and threat analysis tasks. It distributes appropriate notifications and implements an Incident Response plan (IRP) in case of a potential data breach, with formalized, repeatable and enforceable incident response workflows.

IncMan handles different stages of the Incident Response and Breach Notification Process, providing advanced intelligence reporting with appropriate metrics, with the ability to gather or share intelligence with 3rd parties as required.

So, this Valentine’s Day, we hope that you are enjoying a romantic dinner for two, knowing that your SOC and CSIRT, as well as the wider organization, has the necessary incident response and incident management best practices implemented to sufficiently meet the upcoming GDPR requirements in 100 days’ time. If not, speak to one of our representatives to find out more.

Find out how IncMan can help you become GDPR compliant

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.

3 Ways to Create Cyber Incidents in DFLabs IncMan

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:

  1. Alerts from cyber security detection technologies such as Endpoint Detection & Response or User Entity Behavior Analytics tools
  2. Alerts from Security Information & Event Management Systems (SIEM)
  3. Emails from ITSM or case management systems
  4. Website submissions from internal stakeholders and whistle-blowers
  5. 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:

 

cyber incidets incman

 

You will see that under the external sources option there are 3 options available to use as sources to automate incident creation:

  1. Incoming events automation, for CEF/Syslog
  2. Incoming Mail automation, for a monitored email account
  3. 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

 

cyber incidets incman 1

 

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:

 

cyber incidets incman 2

 

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):

 

cyber incidets incman 3

 

In this screen, you can then convert this source item to an incident, or link the source to an existing incident.