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.
Instead of a technical topic, this week I wanted to discuss an interaction I had with another Information Security professional recently because I believe it exemplifies how we as professionals can interact and share ideas in a way that furthers the security industry.
A couple of weeks ago, DFLabs released a whitepaper titled: “Increasing the Effectiveness of Incident Management“, which I authored discussing how the Incident Command System utilized for decades by emergency services in the US and across the world could be applied to streamline security incident management in the enterprise. Weeks later, Adam (whose last name I will not use since I did not ask his permission) reached out to me to express a problem with one of the premises of that whitepaper. What I want to highlight here is not that someone disagreed with me on a point (it happens often), or who is right (I don’t think there is any right or wrong in this case), but how the interaction itself occurred because I think it exemplifies how we can work together to further ideas in our industry.
First, I would like to thank Adam for reaching out at all. As an author of papers such as this, it lets me know that people are actually reading the content and taking the time to give it some thought. Many of us in the security industry (and I am guilty of this as well) are great consumers of information, but often do not take the time to contribute our own thoughts. You don’t need to write blogs, whitepapers or speak at conferences to contribute. Providing meaningful feedback and collaboration is what turns good ideas into great ideas that can revolutionize the security industry.
It is common to receive positive feedback regarding a certain point or the content as a whole. While positive feedback is beneficial in letting you know you are on the right track, I would argue that constructive criticism is equally, if not more important. Perhaps it is a resistance to what we might perceive as confrontation, or just not taking the time to put our thoughts to words to share with others, but I would also argue that constructive criticism is often even more beneficial than positive feedback.
Notice that I said constructive criticism and not negative feedback. I think there is an important differentiation here. If you have a Twitter account, you know what I mean by negative feedback. Negative feedback is very seldom the spark for new ideas and creates more divides than bridges. What I really appreciated about Adam’s feedback was the way in which he provided it. Adam was not negative, he was not attempting to poke holes in my premise or tell me why I was wrong. Instead, Adam provided an alternate view in a professional and constructive manner. This lead to additional dialogue which broadened my understanding of the topic and allowed me to consider a viewpoint that I had not previously considered.
Based on my conversation with Adam, I now have a better understanding of a different viewpoint, and the topic as a whole, which will help me continue to evolve my ideas and apply them to a wider array of situations. We are all very busy, but taking 10 minutes from your day to share your thoughts and constructive criticism with someone else is a tremendous way to contribute to the community. Please, be like Adam!
If you are interested in reading the whitepaper “Increasing the Effectiveness of Incident Management” is it still available to download.
Whether you call it Incident Management or Incident Handling, most will agree that there is a distinct difference between responding to an incident and managing an incident. Put simply, Incident Response can be defined as the “doing”, while Incident Management can be defined as the “orchestrating”. Proper Incident Management is the foundation and structure upon which a successful Incident Response program must be based. There are numerous blogs, articles and papers addressing various aspects of the differences between Incident Response and Incident Management dating back to at least a decade. Why add another to the top of the pile? Because while most organizations now see the value in putting people, tools, and basic processes in place to respond to the inevitable incident, many still do not take the time to develop a solid Incident Management process to orchestrate the response effort.
Security incidents create a unique environment, highly dynamic and often stressful, and outside the comfort zone of many of those who may be involved in the response process. This is especially true during complex incidents where ancillary team members, such as those from Human Resources, Legal, Compliance or Executive Management, may become involved. These ancillary team members are often accustomed to working in a more structured environment and have had very little previous exposure to the Incident Response process, making Incident Management an even more critical function. Although often overlooked, the lack of effective Incident Management will invariably result in a less efficient and effective process, leading to increased financial and reputational damage from an incident.
Many day-to-day management processes do not adapt well to these complex challenges. For example, as the size and complexity of a security incident increases, the number of people that a single manager can directly supervise effectively decreases. It is also not uncommon for some employees to report to more than one supervisor. During a security incident, this can lead to mixed directives and confusion. During a security incident, it is critical that information flows quickly and smoothly both vertically and horizontally. Many organization’s existing communication methods do not adapt well to this.
When an ad-hoc Incident Management system is used, the response process becomes much less consistent and effective. A common pitfall of this ad-hoc management style is that it can create a flat management structure, forcing the Incident Response Coordinator to directly oversee the functions of many groups with vastly different objectives. A flat structure such as this also tends to inhibit the flow of information between the individual groups.
Another common pitfall of this ad-hoc management style is that it often results in a fragmented and disorganized process. Without proper management to provide clear objectives and expectations, it is easy for individual groups to create their own objectives based on what they believe to be the priority. This seriously limits the effective communication between individual groups, forcing each to work with incomplete or incorrect information.
There are numerous ways in which the Incident Management process can be streamlined. On Wednesday, January 31st, DFLabs will be releasing a new whitepaper titled “Increasing the Effectiveness of Incident Management”, discussing the lessons that can be learned from decades of trial and error in another profession, the fire service, to improve the effectiveness of the Incident Management process. John Moran, Sr. Product Manager at DFLabs, will also be joining Paul and the Enterprise Security Weekly Team on their podcast at 1 PM EST on January 31st to discuss some of these lessons in more detail. Stay tuned to the DFLabs website, or listen in on the podcast on January 31st for more details!
Since Meltdown and Spectre were publicly disclosed earlier this month, there has been much confusion surrounding exactly how these attacks work, and what impact they may have on the enterprise. Though these vulnerabilities could pose a serious risk to the enterprise, I think we can probably hold short of a full-fledged panic, at least for now. Let’s take a look at what these two attacks really are, what solutions are available, and what they may ultimately mean for the enterprise.
Meltdown and Spectre exploit critical flaws in modern processors. Unlike most vulnerabilities, the vulnerabilities used by Meltdown and Spectre do not exist in software, but in the processors themselves. This is significant for many reasons. First, while it is possible to patch “around” these vulnerabilities, it is much more difficult to patch the vulnerabilities themselves. Second, although endpoint protection solutions may be able to detect methods used to deliver a payload which exploits the Meltdown or Spectre vulnerabilities, the execution of the exploits themselves are very hard to distinguish from normal processes and thus very difficult to detect heuristically. Finally, since these exploits are performed at the hardware level, the forensic artifacts often relied upon to investigate malware incidents are absent in these attacks.
While programs are typically not permitted to read data from memory sections outside their own address space, a malicious program can exploit Meltdown or Spectre to access regions of memory that the process should not otherwise have access to. This could include access to user credentials or hashes, private keys, sandbox escape, VM escape and access to other confidential information stored in memory.
So far, there are three specific vulnerabilities which are used in Meltdown or Spectre attacks:
• Variant 1: Bounds check bypass (CVE-2017-5753)
• Variant 2: Branch target injection (CVE-2017-5715)
• Variant 3: Rogue data cache load (CVE-2017-5754)
Spectre (Variants 1 and 2) has been shown to impact all modern chips manufactured by Intel, AMD and ARM. Meltdown (Variant 3) has been shown to impact most Intel chips since 2010, although researchers noted that with additional research and code optimization, exploitation against AMD and ARM chips may be possible.
A processor operates in two modes: kernel mode and user mode. Kernel mode is where the operating system executes, and processes running in kernel mode have access to hardware and all regions of memory. User mode is where most user processes execute. Each user mode process has a restricted view of memory, allowing access only to the process’s own virtual address space, and must use system calls to access hardware. Under normal conditions, if a user mode process attempts to directly access a memory section outside its own virtual address space, an exception will be generated which will cause the process’s thread to terminate.
While kernel memory cannot be read directly from user space without utilizing a system call, most modern operating systems still map kernel addresses into userspace processes to optimize performance. Although this sounds like a vulnerability on its own, a userspace process attempting to access kernel space outside of a normal system call will generate an exception and cause the process’s thread to terminate. This means that although kernel space is mapped into the user process address space, it is effectively inaccessible to the user space process outside of normal system calls.
Meltdown exploits the fact that kernel space memory is mapped into the user space process’s address space and the fact that, to optimize performance, most modern processors execute instructions out of order, to bypass the normal protection mechanisms and allow unprivileged user space processes to access kernel space memory. By executing specially crafted out of order instructions, kernel space memory address can be written to the process’s address space, which can then be retrieved via an address reference in the processor’s cache. Although this unprivileged memory access ultimately causes an exception which causes the rest of the out of order instructions to be discarded, the retrieved memory sections continue to reside in the user process’s unmapped memory space, and the reference still remains in the processors’ cache.
Although Address Space Layout Randomization (ASLR) means that an attacker will not know the location of kernel space memory beforehand, this presents more of a stumbling block than a barrier for this attack. The researchers who discovered Meltdown found that the location of kernel memory can be determined in about 128 guesses on a system containing 8GBs of memory, making ALSR trivial in preventing this attack.
Spectre exploits another set of processor features, branch prediction, and speculative execution, to access protected memory locations. Most processes contain a vast array of branch conditions, such as If/Then/Else statements. To optimize performance, as a process executes, the processor keeps track of which branches are executed most often. This allows the processor to “think ahead”, read memory sections and snapshot pre-execution of the branch which it believes is most likely to be taken. This is referred to as speculative execution.
Spectre causes the processor to access a memory location of the attacker’s choosing within the user process’s space during branch prediction and speculative execution which would not be accessed during normal process execution. Although these memory locations are never actually executed by the processor, they now exist in the processor’s cache and can then be read by the attacker.
Patches and Workarounds
There are patches currently available for the Linux kernel to prevent the Meltdown attack. Known as KAISER or Kernel Page Table Isolation (KPTI), these patches prevent most kernel memory from being mapped into userspace processes (although some kernel memory, such as the IDT, must still be mapped to user mode address space). Microsoft has also developed a similar patch for Windows to address Meltdown; however, due to compatibility issues (BSODs) with some endpoint protection solutions, Microsoft has cautioned users to check with their endpoint protection provider prior to deploying the patch. An unofficial list of support for the Windows patch by common endpoint protection solutions is available here. It is important to note that these patches do not fix the actual vulnerability itself, they simply limit the practical exploitation of the vulnerability. Some users have also been reporting issues with the Microsoft patch, causing systems with older AMD processors to fail to boot correctly.
For users still running legacy systems, such as Windows XP and Windows Server 2003, these systems will continue to remain vulnerable to Meltdown and Spectre along with the many other vulnerabilities still present on these systems. The best protection is to harden around these systems, or even better, replace them.
Patches to address these vulnerabilities do come with some performance implications, however. Estimates range from a 5% to a 30% decrease in performance depending on system usage. Systems utilized for more common tasks, such as email, Internet browsing, and word processing, are less likely to see a major performance impact from these patches. However, systems used for tasks which require more intensive hardware utilization are more likely to suffer a noticeable impact.
Apple, which bases its iOS A-series processors on ARM’s instruction set, has already deployed patches for some devices and plans to release patches for other devices soon. Apple has advised users are to check for new updates for their devices and check to ensure that they are running the most current operating system for their devices.
Google says that Android devices, which also most commonly run on ARM processors, should be protected if they have the latest security update installed. Currently, Android devices are protected by restricting access to the high precision timers needed to determine if a cache hit or miss has occurred; however future Android security updates will also include additional mitigations based on KPTI. Users of Google Android devices, such as the Nexus and Pixel, should have immediate access to the security updates. Users of other Android devices will likely have to wait a little longer for these patches as they are tested and pushed through each manufacturer’s update process.
Chromebook users running the latest version of Chrome OS (version 63 as of now) should already be protected against these vulnerabilities as well. To check if a Chromebook is updated to version 63, or if an update is available, users should check Google’s list of Chrome OS devices.
Qualcomm processors are affected by these vulnerabilities as well, although patches have not yet been released for all systems running on Qualcomm processors. Users are advised to check for operating system updates, particularly when running Android and Linux, on their Qualcomm-powered devices. IBM firmware updates should be available in the upcoming weeks for their Power CPUs to address Spectre-like issues in its design.
Cisco is also preparing to release patches to prevent exploitation of these vulnerabilities. Since most Cisco products are closed systems, which do not allow customers to run custom code on the device, practical exploitation of these vulnerabilities on Cisco devices is limited. However, certain processor and OS combinations in some Cisco products could leave them vulnerable, and it is recommended that users patch their Cisco devices as soon as a patch is available.
What does this mean for me?
While Meltdown and Spectre do pose some serious potential security risks, at the moment there is no need to panic. Users are still far more likely to be exploited via a phishing email than either of these vulnerabilities. So far, there has been no evidence that either of these attacks has been used in the wild, although it is certainly possible that others have known about these vulnerabilities for some time. It will likely take some additional time and effort to advance these attacks from a proof of concept to a reliable attack vector.
There has been enough attention given to these vulnerabilities that most major operating systems and applications already have patches available or will have patches available soon. Patching will be the best defense against these attacks. With proper patching, the risks from these vulnerabilities will be significantly reduced or eliminated. Users of less common or no longer maintained software which may be vulnerable to Spectre Variant 1 should check with their software vendors or deploy additional protections around these systems. Legacy and embedded devices, with limited or no ability to patch, will likely see the greatest long-term risk associated with these attacks.
The greatest potential impact from Meltdown could have been on cloud service providers, as they could have allowed both access to the hypervisor as well as data from other instances. However, most of the major cloud service providers were notified of the vulnerability prior to public disclosure and should have patches already deployed, or being deployed soon. Cloud service users should check with their individual providers to determine their potential existing exposure from these vulnerabilities.
The most significant lasting impact from Meltdown and Spectre may be these types of hardware vulnerabilities exist in the first place. Although these vulnerabilities have been present in hardware for many years, little attention has been paid to this class of vulnerabilities. Hardware vulnerabilities such as these present a very attractive vector for attackers due to the high level of access they provide and the potential for VM escape; even more so when they can be exploited remotely. We have seen this type of vulnerability “gold rush” in the past, where the discovery of a single vulnerability leads to increase in scrutiny of a certain application or system, disclosing dozens of additional vulnerabilities. Given the challenges in detecting, investigating and patching these types of hardware vulnerabilities, a gold rush here could have serious security implications.
Since I am a new face (or perhaps just a name to most of you) here at DFLabs, I wanted to take a moment to introduce myself before we jump into the topic for today. My name is John Moran and I recently joined the DFLabs team as Senior Product Manager. Prior to joining the DFLabs team, I worked in a variety of roles, including incident response consulting, security operations and law enforcement. While I have many responsibilities at DFLabs, one of my primary roles and the one that I am perhaps most passionate about is ensuring that DFLabs continues to bring you the industry leading security orchestration, automation and response feature that you have come to expect from IncMan. If you have feature requests, suggestions or other comments, good or bad, regarding IncMan, I’d love to hear from you. Please reach out to me at [email protected]. With that out of the way, let’s get to the good stuff…
While reports such as the Verizon DBIR indicate that the increased focus on creating holistic, detect and respond security programs has had a positive impact on reducing the time to detect security incidents, these same reports have also shown that attackers are continuing to evolve. There is still a continuing gap from compromise to detection. what I would like to discuss here instead though, might be described as the opposite problem; overreaction to a perceived security incident, or conducting a full-scale response to a security incident prior to validating that a security incident has indeed occurred.
Please do not misunderstand what I am saying, I will always advocate the “treat it as an incident until you know otherwise” approach to incident response. However, I would also encourage that the response to any security incident should always be a measured response. The incident response process must be rapid and decisive; but just as under-responding to an incident can present serious financial and reputational risks to an organization, so too can over-responding to a potential security incident. As with any other business process, incident response must provide value to an organization. Continued over-response to perceived security incidents will reduce the overall value that incident response provides to an organization, and over time will result in decreased support from management.
Few studies have truly been able to quantify the costs associated with failing to conduct a measured response. A 2015 study by the Ponemon Institute suggests that response to incidents detected based on erroneous or inaccurate malware alerts costs large organizations up to 395 hours-per-week, or almost $1.3 million a year. It is important to note that this study only took into consideration time spent investigating malware alerts. While malware detection technologies have undoubtedly improved in the two years since this study was conducted, most organizations have a variety of detection technologies, all generating alerts which must be investigated. It was assumed by Ponemon that the organizations surveyed were conducting an appropriate, measured response to each of these false positives. With the cost already so high, it is easy to conclude how costly over-responding to incidents can become at scale.
While conducting incident response consulting, I have personally seen organizations spend weeks to months conducting full-scale incident response activities before spending tens of thousands of dollars for incident response consulting, only to find out that the perceived incident was based on faulty information or conclusions. So how do you minimize the risk of over-responding while continuing to ensure that each potential incident is properly investigated? Here are five tips based on my experience:
- Have the right people in place – There is simply no substitute for having the right people in place. While proper training and experience are vital, the qualities of an effective analyst extend beyond these two attributes. It is crucial to have analysts who possess an analytical mindset and can remain level-headed amidst a stressful and dynamic environment. Training and be provided, the experience can be gained, however, some of these less tangible qualities are much harder to learn.
- Have the right toolsets in place – Attempting to substitute tools for skills will inevitably lead to failure. However, it is important to have the proper tools in place to give those highly skilled analysts the information they need to make fact-based conclusions. Even the most highly skilled analysts will inevitably arrive at the wrong conclusion when presented with incomplete or inaccurate information.
- Know the threat landscape – Threat intelligence, and I mean actual intelligence, not just a machine-readable threat feed, can provide much greater context surrounding a potential security incident. Analysts must also be provided the opportunity to remain up-to-date on the ever-changing threat landscape. This can allow decision makers a much more accurate perspective on which to base their initial level of response. Often, it is a lack of knowledge and conclusions based on assumptions that lead to a dramatic over-response.
- Know your limitations – Unless you are fortunate enough to work for a government agency or one of the world’s largest organization, chances are at some point your needs may exceed the scope of your internal capabilities. These limitations are not weaknesses in and of themselves. Instead, the risk here presents itself when an organization fails to realize its limitation and attempts to work outside of those bounds. It is important to know when to consider tapping into external resources such as consulting, incident response retainers and managed services.
- Replace the emotional response with processes and procedures – Even the most highly skilled analysts will approach some potential security incidents with certain biases or preconceived notions. It is essential to implement quality processes and procedures which maximize the analyst’s skills, take full advantage of the available tools, and guide the incident response process. Processes and procedures surrounding incident validation, incident classification and initial resource allocation can ensure that the process stays on track and avoid straying down the wrong, costly road.
The most important goal of any security program must always remain to never under-respond to an incident. However, integrating these five tips into your security program will undoubtedly provide a better, more efficient process to determine what the appropriate level of response to each potential security incident should be, greatly reducing the risk of over-responding.