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.
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.
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:
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.
Increasing Adoption of SOAR Solutions
Over the past several years, Security Orchestration, Automation and Response (SOAR) has gone from being viewed as a niche product to one gaining traction across almost all industry verticals. Today, more and more private organizations, MSSPs and governments are turning to SOAR Technology to address previously unsolved problems in their security programs. SOAR is about taking action: “Automate. Orchestrate. Measure”. Organizations are implementing a SOAR solution to improve their incident response efficiency and effectiveness by orchestrating and automating their security operations processes. Gartner estimates that by 2019, 30% of mid to large-sized enterprises will leverage a SOAR technology, up from an estimated 5% in 2015.
In this three-part blog, we will discuss the key drivers for SOAR adoption and what problems a SOAR solution can help solve. In the next blog, the second part of this three-part blog, we will discuss the three pillars of Security Orchestration, Automation and Response (SOAR). Finally, we will round out the series by discussing the critical components and functionality that a SOAR solution should contain.
Five Key Problems SOAR Technology Helps to Solve
Like many new product categories, Security Orchestration, Automation and Response (SOAR) technology was born from problems without solutions (or perhaps more accurately, problems which had grown beyond the point that they could be adequately solved with existing solutions). To define the product category more accurately, it is crucial to first understand what problems drove its creation. There are five key problems the SOAR market space has evolved to address.
- Increased workload combined with budget constraints and competition for skilled analysts means that organizations are being forced to do more with less
As the number and sophistication of threats has grown over the past decade, there has been an explosion in the number of security applications in the enterprise. Security analysts are being forced to work within multiple platforms, manually gathering desperate data from each source, then manually enriching and correlating that data. Although it may not be as difficult to find security analysts as it once was, a truly skilled security analyst is still somewhat of a rare breed. Intense competition for these skill analysts means that organizations must often choose between hiring one highly skilled analyst, or several more junior analysts.
- Valuable analyst time is being consumed sorting through a plethora of alerts and performing mundane tasks to triage and determine the veracity of the alerts
Even when alerts are centrally managed and correlated through a SIEM, the number of alerts is often overwhelming for security teams. Each one of these alerts must be manually verified and triaged by an analyst. Alerts which are determined to be valid then require additional manual research and enrichment before any real action can be taken to address the potential threat. While these manual processes are taking place, other alerts sit unresolved in the queue and additional alerts continue to roll in.
- Security incidents are becoming more costly, meaning that organizations must find new ways to further reduce the mean time to detection and the mean time to resolution
The cost of the average incident has increased steadily year on year. The immediate cost of an incident due to lost sales, employee time spent, consulting hours, legal fees and lawsuits is relatively easy to quantify. The financial loss due to reputational damage, however, can be much more difficult to accurately measure. Reducing the time to detect and resolve potential security incidents must be an absolute priority. Each hour that a security incident persists is effectively money out of the door.
- Tribal knowledge is inherently difficult to codify, and often leaves the organization with personnel changes
Employee retention is an issue faced by almost every security team. Highly skilled analysts are an extremely valuable resource for which competition is always high. Each time an organization loses a seasoned analyst, some tribal knowledge is lost with them and they are replaced with an analyst who, even if they possess the same technical skills, will lack this tribal knowledge for at least a period of time. Training new analysts takes time, especially when processes are manual and complex. Documenting security processes is a complex, but critical task for all security teams.
- Security operations are inherently difficult to measure and manage effectively
Unlike other business units which may have more concrete methods for measuring the success or failure of a program, security metrics are often much more abstract and subjective. Traditional approaches to measuring return on investment are often not appropriate for security projects and can lead to inaccurate or misleading results. Properly measuring the effectiveness and efficiency of a security product or program requires a measurement process specially designed to meet these unique requirements.
About DFLabs IncMan SOAR
DFLabs is an award-winning and recognized global leader in Security Orchestration, Automation and Response (SOAR) technology. Its pioneering purpose-built platform, IncMan SOAR, enables SOCs, CSIRTs, and MSSPs to automate, orchestrate and measure security operations and incident response processes and tasks. IncMan SOAR drives intelligence-driven command and control of security operations, by orchestrating the full incident response and investigation lifecycle and empowers security analysts, forensic investigators and incident responders to respond to, track, predict and visualize cyber security incidents. As its flagship product, IncMan SOAR has been adopted by Fortune 500 and Global 2000 organizations worldwide.
Schedule a live demo with one of our cyber security specialists here and see DFLabs IncMan SOAR platform in action.
Stay tuned for our next blog in this series, where we will discuss the three pillars of SOAR technology.
Threats are constantly evolving, and new threats emerge daily. Minimizing risk and the cost associated with security incidents means making rapid decisions based on the up-to-date and accurate information. Actionable threat intelligence can play a critical role in a proactive security program, as well as conducting efficient and effective incident response. Making incident response decisions based on incomplete or inaccurate intelligence can result in an incomplete or delayed response, residual risk and increased loss due to downtime, response cost, and fines.
Many security programs today experience challenges around gaining actionable and accurate threat intelligence and are looking for solutions to overcome these two key problems:
- How can I enrich incident indicators with actionable threat intelligence to make more informed decisions during the incident response process?
- How can I proactively gather threat intelligence data to ensure that my security team stays up to date on the latest threats and ongoing trends?
In this blog, we will briefly discuss how a security program can automate the collection of actionable threat intelligence from IBM experts utilizing IBM X-Force Exchange with its integration with DFLabs.
The DFLabs and IBM X-Force Exchange Solution
IBM X-Force Exchange is a cloud-based threat intelligence platform that allows security teams to consume, share and act on threat intelligence. It enables analysts to rapidly research the latest global security threats, aggregate actionable intelligence, consult with experts and collaborate with peers. IBM X-Force Exchange, supported by human- and machine-generated intelligence, leverages the scale of IBM X-Force to help users stay ahead of emerging threats.
DFLabs IncMan SOAR platform and IBM X-Force Exchange bring actionable threat intelligence sourced from the experts at IBM as well as industry peers, together with the automation and orchestration power of IncMan to deliver industry-leading incident response capabilities. Together, these solutions allow joint customers to make better, more informed automated and manual decisions, reducing the risk posed by security incidents.
Enriching incident indicators with actionable threat intelligence enable enterprises to reduce incident resolution times, maximize security analyst efficiency, as well as increase the number of handled incidents.
Use Case in Action
An alert based on an internal host communicating with a potentially malicious URL has automatically generated an Incident within IncMan. This alert is automatically categorized as a Malicious Communication incident within IncMan based on the organizations’ policies, which initiates the organization’s Malicious Communication runbook, shown below:
This runbook begins by utilizing several IBM X-Force Exchange integration actions to enrich the alert information, in this case, the potentially malicious domain. First, a WHOIS lookup of the domain is performed using IBM X-Force Exchange. Next, any threat intelligence regarding this URL is retrieved from IBM X-Force Exchange using the URL Reputation action.
After gathering intelligence on the initially reported URL, the runbook pivots outward and performs a DNS record search through IBM X-Force Exchange. For each DNS record returned, the runbook performs a WHOIS lookup on the IP address, followed by a threat intelligence search on the IP address through IBM X-Force Exchange.
Once all available threat intelligence has been retrieved from IBM X-Force Exchange, the runbook reaches an automated decision point. In this case, the runbook examines the threat intelligence for any threat score meeting a certain threshold. If this threshold is met, IncMan will automatically send a notification to the security team, then automatically update the incident type to that of a confirmed security incident. Following this notification and incident update, the security analyst will be prompted to determine whether or not automated containment actions are appropriate.
Actionable threat intelligence can play a critical role in a proactive security program, as well as conducting efficient and effective incident response.
By using DFLabs IncMan R3 Rapid Response Runbooks to automate the collection of actionable threat intelligence from the experts at IBM, as well as industry peers through the IBM X-Force Exchange, security teams can enrich indicators and gather additional intelligence to make faster, more informed decisions when the time is of the essence.
If you would like to see a more in-depth demo of this use case in action, or other use cases within IncMan, please get in touch.
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:
- How can I use my existing resources more effectively?
- How can I reduce the mean time to detection (MTTD)?
- 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:
- Automate repeatable, mundane tasks.
- Orchestrate actions across multiple security tools.
- Enrich raw data, allowing for more informed, effective decisions.
- 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.
As malware attacks continue, attackers are going to great lengths to obfuscate both the intent and capabilities of their malicious payloads to evade detection and analysis. In addition, the rate at which new malware is being developed has reached staggering new levels. Zero-day malware is increasingly common in all environments and signature analysis is becoming less effective.
As a result, malware has become increasingly difficult to detect using more traditional detection mechanisms. Once detection occurs, it is often difficult to successfully analyze the malicious file to determine the potential impact and extract indicators. To successfully respond to a potential malware incident and minimize the impact, early detection and analysis are critical.
In this blog, we will briefly discuss how a security operations team can detect, analyze and respond to advanced, evasive malware by utilizing McAfee Advanced Threat Defense (ATD) with DFLabs IncMan SOAR platform, and present a simple use case example.
Utilizing McAfee ATD with DFLabs IncMan SOAR Platform
Early detection, analysis, and extraction of indicators are critical in successfully responding to and remediating a security incident involving malware. McAfee ATD enables organizations to detect advanced, evasive malware and convert threat information into immediate action and protection. Unlike traditional sandboxes, it includes additional inspection capabilities that broaden detection and expose evasive threats. Tight integration between security solutions enables instant sharing of threat information across the environment, enhancing protection and investigation.
DFLabs IncMan and McAfee ATD together solve two specific challenges including; 1) How can I reliably detect malicious files? and 2) How can I determine capabilities and extract indicators from malicious files? Utilizing DFLabs IncMan’s integration with McAfee ATD and with the use of IncMan’s R3 Rapid Response Runbooks, organizations can automate and orchestrate the detection and analysis of suspected advanced and evasive malware, allowing faster and more effective response to malware incidents. In addition, ATD also provides users with critical insights into the capabilities of suspicious files, as well as indicators which may be further enriched through additional automated actions.
Use Case in Action
A potentially malicious file has been detected on a workstation, causing the security operations team to initiate the incident response process. The malicious file has been extracted from the workstation and included in the IncMan Incident as an Artifact. Next, the R3 Runbook predetermined for malware alerts and incidents will be used to scan the file, perform additional enrichment, then block the infected host, if necessary.
To begin, McAfee ATD is used to detonate the potentially malicious file. Once detonation has completed McAfee ATD will return information about the executable, including the determined severity level. Next, a condition is set to determine if the severity returned by McAfee ATD is greater than 0, indicating that the file is likely malicious.
If it is determined by McAfee ATD that the file is likely malicious, an additional enrichment action is utilized to gather additional information from McAfee ePolicy Orchestrator (ePO) regarding the host that the malicious file was detected on. Following this, McAfee ePO is also used to tag the host with the appropriate tags indicating that it may be infected with malware.
Following the additional enrichment actions, a user choice decision point is reached. This user choice decision will prompt the analyst to make a manual decision regarding whether or not the workstation which generated the malware alert should be temporarily blocked from communicating outside the network. All of the enrichment information from the previous actions, including the information from McAfee ATD and ePO will be available to the analyst to assist in the decision-making process.
If the analyst chooses to block this workstation at the perimeter, a containment action will utilize McAfee Web Gateway to block the IP of the workstation until further investigation and remediation can be conducted.
By harnessing the power of McAfee ATD, along with the additional orchestration, automation and response features of DFLabs’ IncMan SOAR platform, organizations can elevate their incident response process, leading to faster and more effective response and reduced risk across the entire organization. With malware continuing to be one of the top cyber attacks, it is critical that security operations have a streamlined process in place in order to be able to detect and respond to such security alerts.
If you would like to see a more in-depth demo of this use case in action, or other use cases within IncMan, please get in touch.
Attackers have long embraced the concept of automation. Although attackers were likely automating their attacks prior to the Morris worm, in 1988 the Morris worm brought attack automation to the attention of the security industry when it brought down a large portion of the Internet. Since then, the sophistication of attack automation has increased exponentially. Frameworks such as the Metasploit Framework allow attackers to script the entire attack process, from information gathering to exploitation, to post-exploitation and data exfiltration. This sort of automation has allowed the attackers to exploit systems with much greater efficiency.
According to the 2017 SANS Incident Response Survey, almost 50% of organizations who responded reported average detection to containment times of greater than 24 hours. Put another way, almost half of these organizations are allowing attackers to remain in their networks for more than a day after they have first been detected, and that does not even include the time that elapses from compromise to detection. Even an unskilled attacker can cause catastrophic damage to an organization with 24 hours of uninterrupted exploitation time. A skilled attacker automating network reconnaissance, establishing persistence on additional hosts and performing data exfiltration, can cause damage in 24 hours that it will take an organization months to fully discover and recover from.
Three decades later, why have we as a security industry been so slow to adopt the same methods of automation? Sure, we have long automated portions of the incident response process, such as automatically removing detected malicious files or automatically quarantining suspicious emails, but we have yet to achieve the sort of automation efficiency that has been being used by attackers for decades. Even for commodity attacks, this level of automation is often ineffective as attackers have adapted to include multiple mechanisms to maintain persistence when a single file or registry key is deleted. To a skilled and determined attacker, this level of automated prevention is trivial to bypass in most instances.
Attackers have learned that automating large portions of the steps along the Cyber Kill Chain allow them to more quickly infiltrate a single target, as well as more efficiently attack multiple targets. Why then has the security industry yet to follow suit and automate larger portions of the incident response lifecycle? The two most commonly encounter objections are that is it not possible or too risky to automate larger portions of the incident response lifecycle. The answer to the first objection is easy; it is certainly possible. The emergence of Security Orchestration, Automation and Response (SOAR) platforms, such as DFLabs IncMan, have made automation of a large part of the incident response lifecycle possible.
The answer to the second objection to automation is a little more complicated. There is certainly reason for a cautious approach to automating more of the incident response lifecycle, especially when we consider automating containment, eradication, and recovery. After all, there is little risk to the attackers when their automation fails; they may be detected or they may not successfully exploit the target. In either case, the attacker can simply try another method, or move on to the next target. The potential risk is much greater for organizations automating the incident response process. Automatically containing a business-critical system because of a malware detection or automatically blocking business-critical IP address because it was erroneously flagged as malicious, could cost an organization millions of dollars.
While these risks can never be completely eliminated, automation processes and technology have reached a level at which failing to embrace greater levels of automation carries with it significantly more risk than implementing automation in a well-planned, controlled manner. Appropriate automation pre-planning, identifying the repeatable processes which can most safely and easily be automated and carry the greatest risk/reward benefit, maximizes the benefit of increased automation. Proper use of both internal and external sources of enrichment information, such as threat intelligence and internal databases, to inform the automation containment decision process can greatly reduce the risk of containment actions which could negatively impact the organization. In addition, many SOAR platforms have incorporated the ability to include human input during critical decision points in the automation process. For example, IncMan’s Dual-Mode Orchestration allows users to switch between automated actions and human intervention at critical junctures in the response process, allowing the majority of the process to be automated while still permitting human input and reducing the risks posed by pure automation in some critical processes.
Although we are likely still decades away from the proverbial incident response “easy button”, or being able to say “Alexa, remediate that threat”, the current threat landscape is also demanding that we do more with less and respond faster, and that means automation. SOAR platforms are no longer just “nice to have” technologies, they are becoming a requirement for organizations to remain one step ahead of the onslaught of attacks. As an industry, we must continue to learn from our adversaries and continue to embrace increasing levels of automation.
For more information about using automation check out our resources created in conjunction with the SANS Institute, including the white paper entitled “SOC Automation – Deliverance or Disaster” and webinar “Myths and Best Practices Surrounding SOC Automation”.
DFLabs is excited to announce two new technology partnerships with recognized industry leaders: Recorded Future and Tufin. Both Recorded Future and Tufin recently launched formal technology partnership programs and DFLabs is honored to be among the first technology partners to join. Each of these integrations adds significant value to the security programs of our joint customers, allowing them to more efficiently and effectively respond to computer security incidents and reduce risk across the organization.
DFLabs’ new integration with Recorded Future allows joint customers to automate the retrieval of contextualized threat intelligence from Recorded Future, orchestrating these data enrichment actions into the overall incident response workflow. This enriched information can be used within the R3 Rapid Response Runbooks of IncMan SOAR to inform further automated decisions or can be reviewed by analysts as part of the response process.
DFLabs’ integration with Recorded Future includes five enrichment actions: Domain, File, IP and URL reputation queries, as well as a threat intelligence search action. Each of these enrichment actions will return all relevant intelligence on the queried entity, as well as a direct link to the Recorded Future Info Card.
DFLabs’ new integration with Tufin allows joint customers to automate the retrieval of actionable network intelligence from Tufin’s rich sources of network data, providing further context surrounding the organization’s network, allowing for more informed automated and manual decisions. This network intelligence can be used within the R3 Rapid Response Runbooks of IncMan SOAR to make decisions based on numerous factors, such as network device information, simulated path information or network policy rules, or can also be reviewed by analysts as part of the response process.
DFLabs’ integration with Tufin includes five enrichment actions: Get Devices (get network device information based on the supplied parameters), Get Path and Get Path Image (simulate the path which would be taken based on source and destination IP and port information), Get Policies by Device (get network policies for the given device ID), Get Rule Count (get the number of rules which match the specified parameters), and Get Rules by Device (get network rules for the given device ID).
See the DFLabs IncMan SOAR Platform Integrations in Action
Each of these new partnerships extends DFLabs automation and orchestration capabilities into new product spaces with some of the best solutions in their respective classes.
If you are attending the RSA Conference at the Moscone Center in San Francisco and would like to see DFLabs’ new integration with Tufin in action, I will be at the Tufin booth (#929) in the South Expo Hall on Wednesday, April 18th from 3:00 to 4:00 PM PST to provide a live demo and answer any questions.
Otherwise, for more information regarding our new Recorded Future and Tufin partnerships, please contact us to schedule a demo to see IncMan SOAR Platform in action here.
DFLabs is excited to announce the latest release of its industry-leading Security Orchestration, Automation and Response platform, IncMan version 4.3. Solving customer’s problems and adding value to our customer’s security programs is one of our core goals here at DFLabs and this is reflected in our 4.3 release with over 100 enhancements, additions, and fixes; many suggested by customers, all designed to make the complex task of responding to potential security incidents faster, easier and more efficient.
IncMan 4.3 includes many new bidirectional integrations from a variety of product categories including threat intelligence, malware analysis, ticket management and endpoint protection, chosen to broaden the orchestration and automation capabilities of our customers. These new bidirectional integrations include:
- Atlassian Jira
- BMC Remedy
- Carbon Black Defense
- Cuckoo Sandbox
- McAfee Advanced Threat Defense
- McAfee Threat Intelligence Exchange
- Recorded Future
With IncMan 4.3, we have also greatly enhanced the flexibility of our R3 Rapid Response Runbooks with the addition of two new decision nodes; Filter and User Choice. Filter nodes allow users to further filter and refine information returned by previously executed integrations; for example, filtering IT asset information to include only servers, focusing on key assets first. Unlike automated Enrichment actions, automated Containment actions could have serious unintended impacts on the organization. User Choice nodes allow users to minimize this risk by allowing them to define critical junctions in the workflow at which a human must intervene and make a decision. For example, human verification may be required before banning a hash value across the enterprise or quarantining a host pending further analysis.
Improvements to our patent-pending Automated Responder Knowledge (DF-ARK) module allow IncMan to make even more intelligent decisions when suggesting response actions, and enhancements to IncMan’s correlation engine allow users a more advanced view of the threat landscape over time and across the organization. IncMan’s report engine has been significantly bolstered, allowing users to create more flexible reports for a variety of purposes than ever before. Finally, numerous changes have been made to IncMan’s Dashboard and KPI features, allowing users to create more actionable KPIs and gather a complete picture of the organization’s current state of security at a moment’s glance.
These are just some of the highlights of our latest IncMan release; IncMan 4.3 includes many other enhancements designed to streamline your orchestration, automation and response process. If you would like a demo of our latest release, please go to our demo request site. Stay tuned to our website for additional updates, feature highlights, and demos of our latest release.
We have all heard about Key Performance Indicators (KPIs) and how critical they can be for your security program, but confusion remains surrounding what KPIs are important to track and how they can be used to measure and improve the organization’s security program. Tracking KPIs is great, but if those KPIs are not relevant and actionable; if you are tracking KPI’s just for the sake of tracking KPIs and they are not being used to inform your security program, your KPIs will become more of a detriment than an enabler for your security program.
At its core, a KPI is a way of measuring the success or failure of a business goal, function or objective, and a means of providing actionable information on which decisions can be based. Quality KPIs serve as a security program enabler and driver for continuous improvement. This is true of both the tactical functions of security operations – looking for attack patterns and trends of malicious activity, as well as the strategic functions of security operations – identifying program gaps and making long-term program decisions.
KPIs should focus on assessing a goal or function and providing actionable information on which decisions can be made. The most effective way to develop meaningful KPIs is to start by identifying which security operations goals or functions are the most critical to the security operations program, then developing KPIs to measure those critical goals or functions. KPIs which will not inform the decision-making process in some way are unnecessary and should be avoided, they will serve only to muddy the waters.
When choosing KPIs to measure, quality should be valued above quantity. Each KPI should have a meaning to the organization and add value to the security program. There are many different methods for evaluating the effectiveness of a KPI; here we will use the acronym SMART. Each KPI should be:
- Simple– KPIs should not be overly complicated to measure. It should be clear what the purpose of each KPI is and how it impacts the security program.
- Measurable– A KPI must be able to be measured in some way, quantitatively or qualitatively. The method by which each KPI is measured should be clearly defined and consistent.
- Actionable– KPIs should be used as a driver for decisions. The purpose of a KPI is to measure performance, and if necessary, take some action based on the results. A KPI which is not actionable serves little to no purpose.
- Relevant– Each KPI should be a measurement of the function being assessed; in this case, the security program. KPIs which are simple, measurable and actionable, but are not relevant to the function being assessed will be of little value.
- Time-Based– KPIs can and should be used to show changes over time. An effective KPI should be able to be collected and grouped by various time intervals to show variations and patterns.
There will never be a set of “correct” KPIs to measure; the goals and objectives for each organization will always be different, and the organization’s KPIs should reflect the individual priorities. The key to choosing KPIs which will have a real, actionable impact on the organization’s security program is to ensure that the KPIs are SMART, focus on the six most common components of a successful security operations program, and are used to further the security program.
For more detailed information on how your organization can use KPIs to enhance your security program, check out our whitepaper “ Key Performance Indicators (KPI’s) for Security Operations and Incident Response” here
Following on from my recent blog post entitled “Meltdown and Spectre – What They Mean to the Enterprise” published in January, I wanted to take a closer look at how these types of hardware vulnerabilities could (and should) easily be detected, managed and mitigated using Security Orchestration, Automation and Response (SOAR) technology, for example with a platform such as IncMan from DFLabs.
Using Meltdown and Spectre as a use case, I wanted to enlighten you about the automated processes an organization can undertake. There are many pros and cons for using automation, but if used in the correct way it can significantly improve Security Operations Center (SOC) efficiencies, saving security analyst many man hours of mundane tasks. Alerts can also potentially be responded to and contained before an analyst has even been notified. Using IncMan’s integrations and R3 Rapid Response Runbooks, SOCs can quickly respond to such an alert when a vulnerability is detected. The overall goals would be as follows, in order to reduce the risk these vulnerabilities present to the organization.
1) Automatically receive alerts for the host which have been identified as being vulnerable to Meltdown or Spectre.
2) Create an Incident and perform automated Notification, Enrichment and Containment tasks.
Let’s move on to the implementation stages. Where should you start? For ease I will break it down into 3 simple sections, creating a runbook, utilizing the rebook and seeing the runbook in action. So, let’s begin…
Creating an R3 Rapid Response Runbook
The first step in reducing the risk from the Meltdown and Spectre vulnerabilities is to create a runbook to handle alerts for newly detected vulnerable hosts. In this use case, we will use integrations with Jira, McAfee ePO, McAfee Web Gateway, MSSQL Server and QRadar to perform Notification, Enrichment and Containment actions; however, this can easily be adapted to include any other technology integrations as well.
Using a Jira Notification action, a new Jira issue is created. This Notification action should notify the IT or Infrastructure teams and initiate the organizations’ normal vulnerability management process.
Next, an MSSQL Server Enrichment action is used to query an IT asset inventory for the host name of the vulnerable host, which is passed to the runbook automatically when the incident is created. This asset information is then available to the analyst for further review.
Once the IT asset information is retrieved, a decision point is reached. If the IT asset information indicates that the host is a server, one path (the top path) is taken. If the IT asset information indicates that the host is not a server, another path (the bottom path) is taken.
If the asset is determined to be a server the Jira Enrichment action is used to update the Jira issue, informing the appropriate parties that the host has been determined to be a server and should be treated as a higher priority. Next, two McAfee ePO Enrichment actions are performed. The first Enrichment action queries McAfee ePO for the system information of the given host name, providing the analyst with additional information. The second Enrichment action uses McAfee ePO to tag the host with the appropriate tag. Finally, a Task is added to IncMan reminding the analyst to follow up with the appropriate teams to ensure that the vulnerability has been appropriately mitigated.
If the asset is determined not to be a server, the two previously mentioned McAfee ePO Enrichment actions are immediately be run (System Info and TAG). Following these two Enrichment actions, a McAfee Web Gateway Containment action is used to block the host from communicating outside of the network. This Containment step is completely optional but is performed here on non-servers only to minimize the Containment action’s potential impact on critical systems.
Once the new runbook is created, IncMan must be told how and when to automate the use of this runbook. This is achieved by creating an Incident Template, which will be used any time an incident is generated for a Meltdown or Spectre vulnerability. Through this incident template, critical pieces of information such as Type, Summary, Category can be automatically applied to the newly created incident.
From the Runbook tab of the Incident Template wizard, the previously created Meltdown and Spectre runbook is selected and set to autorun. Each time this template is used to generate an incident, the appropriate information such as host name and host IP address will be used as inputs to the runbook and the runbook will be automatically executed.
In this use case, alerts from QRadar are utilized to initiate automatic incident creation within IncMan. However, another SIEM integration, syslog or email could also be utilized to achieve the same outcome. A new QRadar Incoming Event Automation rule is added and the defined action is to generate a new incident from the previously created Meltdown and Spectre Incident Template.
Solution in Action
When a QRadar Alert is generated matching the criteria defined for a Meltdown or Spectre vulnerability detection, IncMan will automatically generate a new incident based on the Meltdown and Spectre Incident Template.
Without requiring any action on the part of an analyst, the Meltdown and Spectre runbook is automatically initiated, performing the defined Notification, Enrichment and Containment actions.(In the example shown here, the ‘server’ path is taken).
How easy was that? The entire process has taken place in a matter of minutes, likely before anyone has even had time to acknowledge the alert. As an analyst begins to manually examine the alert, many of the mundane tasks have already been completed, allowing the analyst to focus on the tasks which require human intervention and reducing the time required to remediate this issue, ultimately reducing risk to the organization.