Introducing “Inferred Context” or
How to Enjoy a Spring Day

Moving at a brisk pace across the campus of your company, laptop stowed under your arm, you hardly have a moment to admire the beauty of an early spring day. During the short trip and perhaps unbeknownst to you, your computer has changed IP addresses multiple times. This common practice helps IT organizations centrally and automatically manage IP addresses resulting in improved reliability and reduced network administration.

However, constant IP address changes can create havoc for Security Analysts because each address will appear as an independent system when a security alert occurs. For instance, an Analyst may start investigating an event based on an IP address and an attack name. The next step is to identify what has happened in association with that IP address, as well as what other systems may be involved in the attack. Depending on the information returned, the Analyst can make a completely inaccurate decision in terms of resolving the event.  If you cannot determine the location or owner of the target machine, you can’t fix the problem.

The decision-making process is further impacted by incomplete, outdated or inaccurate critical asset lists. This is an all too common occurrence that contributes to high numbers of false positives and even worse, false negatives.

Inferred Context – Advanced decision-making skills

Watch video on Inferred Context

The latest release of the Respond Analyst comes equipped with a new set of features called Inferred Context. Inferred Context improves the Respond Analyst’s ability to make informed, accurate decisions that lead to faster incident response times.

Two examples of how applying Inferred Context will result in better security decisions:

Dynamic Host Configuration (DHCP)

The first component of Inferred Context automatically and intelligently maintains an up to date mapping of an IP address to hostname through ingestion of Dynamic Host Configuration Protocol (DHCP) information. This enhances the accuracy of the Respond Analyst’s findings by attributing all relevant events to the infected/targeted asset (and only that asset!) and enabling reasoning across data sources where one source includes IP addresses (such as network IDS/IPS events). The result is fewer false positives, more accurate prioritization of events and faster time to resolution.

Critical Assets – Shades of Gray

Many customers are challenged in keeping up-to-date lists of systems and their level of criticality. To address this, the second component of Inferred Context collects vulnerability scan data in the Respond Analyst that includes information about the host such as operating system, as well as which ports are open. Because applications communicate over open ports, the Respond Analyst infers that an application is running there. For example, a Simple Mail Transfer Protocol (SMTP) server runs on port 25, so if that port is open, the Respond Analyst will infer that is a mail server, which is considered a critical asset.

Inferred Context is supported on all of the models listed on the Respond Software Integrations page.  Additionally, this release is expanding support to give security teams more visibility into their existing alerting telemetries for the following systems:

● Endpoint Protection Platforms: Trend Micro Deep Security, Trend Micro OfficeScan, Palo Alto TRAPs
● Web proxy/URL filtering: McAfee Secure Web Gateway
● Network IDS/IPS: Checkpoint

Inferred Context is helping the Respond Analyst quickly find the target of the attack, so security teams can resolve them quickly. Analysts will no longer have to investigate a multitude of false positives or try to manually search for the affected system, system owner and/or the system name. Instead of staring at a screen filled with endless events, let the Respond Analyst automate the process so you can get out there and enjoy a spring day.

For more on Inferred Context, please read our recent press release or better yet, check out our YouTube channel.

The Respond Analyst’s decision-making skills are continuously expanding. To learn more about what the Respond Analyst can do for your organization or to gain access to Future Early Access programs,

Is SOAR the Missing Link to the Success of the SIEM Market?

5 Key SOAR Considerations SIEM Vendors Need to Make

It’s time for SIEM vendors to up their game—but are they? And is SOAR the holy grail to solving the issues SIEMs have faced over the past few years?

A while back, we outlined the 8 fragments of SIEM that affect SecOps teams. Introducing its own set of challenges, SIEM was declared dead more than a decade ago, yet is still widely deployed in most security organizations today. One reason it’s still used broadly is that SIEM, once deployed, has processes and procedures woven around it making it burdensome to change; meaning ‘uninstalling’ SIEM isn’t as simple as flipping an on/off switch.

In a recent article in Information Age, Andy Kays, CTO of Redscan Managed Services, believes the onus lies on SIEM vendors to improve threat detection and response for their customers, by leveraging Security Orchestration, Automation and Response (SOAR).

While this may seem to be an obvious solution, integrating SOAR into SIEM is not so black and white and there are key considerations SIEM vendors and IT security teams need to make when it comes to leveraging SOAR.

1. SOAR: Buy vs build?

SIEM vendors will have to decide if they want to start building or buying SOAR capabilities, or just figure out how to best integrate.

The problem with both? SIEM vendors will be forced to integrate yet another platform into their software and there is a lot of setup, forethought, and man-hours required for integration into their own platforms, whether or not you build vs buy.

2. SOAR adoption is slow and it requires skilled people.

While SOAR is a beneficial tool, the number of installments in the cybersecurity industry is still limited. In addition, SOAR is resource-intensive and requires a trained professional to deploy the tools and develop appropriate playbook automation for specific and relevant actions and tasks.

3. SOAR can help ease SOC task burdens for security teams.

In which areas? Specifically workflow, case creation/updates, automated response actions. The more complex the task, however, the trickier it is to automate. Like SIEM, SOAR tools require you to tackle use case individually and requires security expertise and an engineering background. This is great for security teams who have skilled employees and the time to build it.

4. Platform-based approaches are still very reliant on people, whether SIEM or SOAR.

While efficiencies can be gained, they don’t address the core issue of skill shortage and resource/budget shortage. Yes, they ultimately address the people shortage by automating certain aspects of the SOC workflow, but the reliance on people to build and maintain playbooks is still a disadvantage.

5. Both SOAR and Decision-automation have a deliberate fit in the flow of SIEM operations.

While SOAR can and should be leveraged, SIEM vendors need to consider the true missing link: the high fidelity decision-making capabilities that neither SOAR nor SIEM can provide, but can be achieved with decision-automation solutions. Simply put, both SIEMs and SOAR platforms struggle in detecting malicious intrusions because they rely on rules and simple correlations —this is where decision-automation tools can help.

Decision-automation solutions that come pre-built with the ability to replicate human judgment are an alternative that automates security alert triage and analysis, covers a breadth of use cases and does not require a team of security experts.

That being said, SOAR and decision-automation are both needed; meaning there is an optimal way to plug SIEM, SOAR, and decision-automation in together. A happy “API-enabled” coexistence with all three would provide the best long-term outcome.

All-in-all, we agree that while SIEM vendors can leverage SOAR, the combination is still very reliant on people. But, by integrating with a decision-automation software like a Respond Analyst, SIEM vendors have a plug-and-play solution to help security organizations tackle high-volume, time-consuming event analysis of fundamental data feeds. This is especially beneficial for mid-sized enterprises who may not have a front line analyst, as the Respond Analyst is there to fill that role (24×7, I might add) for smaller security organizations.

PERCEPTION VS. REALITY: The Myth of 100 Security Data Sources

The realities of security monitoring and the promise of SIEM?

In enterprise IT, data is collected from any number of IT and security devices, and then used to monitor, protect, understand and manage our technology-enabled businesses. Due to the ever-expanding attack surface, the amount of data collected today is overwhelmingly unmanageable, and ironically, we only have a very general idea of what value it should provide. One of the most common objections I hear when talking about security operations is, “I have 100 or more data sources to monitor.” What makes this statement a myth, is not that we collect data from more than 100 data sources, but how we use that data in our security operations programs and how it gets reported to executive management.

What’s Your Monitoring Effectiveness?

With decades of direct experience managing many security operations teams that collect mountains of data, it’s evident to me they barely leverage any of it for security monitoring and detection purposes. If you have 100 data sources reporting into your Security Information and Event Management system (SIEM), but you only have rule logic applied to 5-10 of them (and then maybe only one or two rules for most) what is your actual monitoring effectiveness? To understand this more deeply, we’ll review here all the uses for data collected, in addition to what data applies to particular uses within our security programs.

“I have seen the largest most sophisticated companies on the planet report the fact they collect 100+ data sources but fail to explain that only 3-5 of them have any form of rule logic or other use that can support the cost of collecting them all.”

How Enterprise Data is Used in the Security Environment

The diversity of users needing access to this information presents a key friction point for data aggregation and collection, this is very often seen in shared Splunk instances. Previously, business intelligence strategies were implemented to architect a data warehouse to collect everything and then create various datamarts specific to each user’s information requirements. Today, big data and data-bus solutions have solved this issue, however, they are not fully adopted and deployed with all users in mind. IT operations and IT security present the highest conflict situation because they are the most likely to be on a shared infrastructure with very different business requirements. The team responsible for managing the SIEM (or big data solution) and collecting data has the mission to collect everything, since more is better, right? Often the operations team does not have sufficient authority to get engineering to focus narrowly on what matters to them for detection and response. This is the tail wagging the dog!

Monitoring & Analysis

Looking at data in a time sequence from the first time it’s collected until it is discarded at the end of its information lifecycle; we generally start with analytical monitoring in as close to real-time as possible. Within monitoring, we pay attention to performance, health status, availability, configuration, and security. Each of these requires different fields from the logs produced. They are analyzed entirely differently and are all high volume, low signal monitoring problems.

Typically, the security signal comes from malicious signatures, traffic patterns or behaviors. However, another theory exists which is that anomalies are more likely to be malicious than signatures. I do not agree with this theory, but merely add them to the mix along with signatures and all other potential indicators of malicious activity. These have historically proven extremely difficult for humans to monitor at scale effectively, which is why automation is the more important requirement. 

Reporting & Metrics

One of the next uses in the lifecycle for the data we collect is reporting and metrics. These are designed to answer questions of governance, risk, compliance (GRC), operations analysis and overall effectiveness and efficiency of the business infrastructure. They rarely do, the common top 10 report is an example of “data” without “information.”

There is a ubiquitous statement attributed to Edward Deming — “You get what you measure.” A key challenge in operational security is the inability to secure sufficient budget to support security operations adequately. In these cases, many of the metrics reported are used for budget justification rather than measuring effectiveness and efficiency. It is tough to prove a “cost avoidance ROI.”

The lack of nuance and the naked agendas that are so common in reporting and metrics result in the “Myth of 100 Data Sources.” I have seen the largest most sophisticated companies on the planet report the fact they cover 100+ data sources but fail to explain that only 3-5 of them have any form of logic or use that can support the cost of collecting them all. The reasoning that “we might use it someday, forensically,” is a feeble and expensive justification.


Hunting, a relatively new security discipline, and in position to overtake monitoring rapidly. Hunting requires a more extended and more in-depth set of data.  This includes tasks such as identifying hyper-current attack methods, locating the appropriate data sources, doing pivot-and-search from suspicious sources, looking at specific slices of time where enterprise activity was deemed to be suspicious and visualizing large amounts of data.  In the security operation centers I have been involved in building, we always dedicated a four-hour block of time on Friday to conduct a retrospective hunt over the last week.  In that hunt we discovered that, for the most part, more incidents were missed than detected during 24×7 operational monitoring. The highest quality incidents were found during that retrospective hunt.

Forensic Analysis

Once we’ve identified a security situation exists, then some data becomes useful for forensic analysis. This includes determining the extent of an intrusion, performing root cause analysis supporting or confirming the conclusions of incident response teams and supporting investigations as requested by the corporate legal department. Where data is likely to be presented for forensic purposes in a court of law, you must be able to establish that it was either collected as a business record or has been maintained in a forensically approved data store to verify that it could not have been maliciously modified.


One of the most critical applications of IT data, especially as data volumes scale beyond human management, is process automation. The types of automation that are appropriate include things like the application of logic and algorithms to identify specific issues within the data, the addition of context, business process intelligence for operational improvement and the automation/orchestration of appropriate response action based on security situations detected.

There are many data collection automation opportunities. However, one thing is still valid — there is still a ton of useless data that needs sifting through when automating from raw telemetry. This fact is one of the guiding principles of what I call the “small data” movement as opposed to the big data movement; where you find an actual use for the data before you collect and store a ton of it.


The data sources we collect provide visibility across many different technical perspectives. There is network telemetry, security telemetry, application telemetry, host-based telemetry, cloud telemetry, and contextual telemetry, to start. Within each of these categories, we have infrastructure devices that produce logs and sensors that monitor, whether for operations or security. 

Even within a category each vendor or specific implementation contains radically different information in its log files or alert stream. While there are common logging formats and methods, there is very little agreement or commonality in the information contained used for specific purposes. Logs are highly inconsistent and hard to leverage for any purpose effectively.

Let’s walk through a high-level list of the type of sources were talking about:


Network sources include routers, switches, load balancers, and other LAN/WAN network infrastructure equipment. These sources provide visibility on what is transiting your network. Inbound, lateral and outbound are all interesting viewpoints, but these devices mostly provide performance and availability information and are highly repetitive in their log messages. These sources would also include network specific sensors like deep packet inspection and network flow collection these being used for anomaly detection, performance monitoring, and forensic review.


With security devices, there are some blended network infrastructure technologies like firewalls and proxies, and also dedicated security infrastructure like Identity and Access Management systems or Intrusion Prevention sensors. Security focuses on sensors that detect potential attack signatures and behaviors at various chokepoints and critical nodes. These sensors are looking for signatures or anomalies that might indicate suspicious activity in the form of malicious hackers or code. These also have a high noise to signal ratio and are hard to analyze.


Application telemetry is the least mature and has the highest attack rate. This runs the gamut from web server logs to user-experience application monitoring for custom e-commerce applications. Application telemetry is highly focused on performance and availability, and almost wholly ignores all but very basic security uses. This makes them almost useless for detection monitoring. The main exception is the authentication of users but that is a shallow set of use cases.


Host-based also has multiple categories.  The native operating system has defensive and logging facilities that can be monitored, though the volume is extremely high with only a tiny number of events indicating maliciousness. There are also host-based agents; from NexGen Antivirus (NGAV), Endpoint Protection Platforms (EPP), Endpoint Detection and Response (EDR) or simply IT operations instrumentation.


With cloud as the newest critical component in our business IT strategy, it also has most of its focus on performance and availability rather than security controls.  There are still minimal use cases detected through monitoring in cloud tools. The primary argument is that much of the traditional security is handled by the cloud provider and invisible to the user. This situation led to the development of the Cloud Access Security Broker (CASB), so the cloud user could demonstrate compliance and security requirements without resorting to the provider’s controls. Native cloud telemetry is very shallow at the moment with CASBs filling the gap.


Context is a category that many people fail to think about thoroughly. Maintaining a historical record of context is essential to identifying assets impacted but which are transient on the network. For example, what IP address did an offending host have at any given point in time?  Can I map back to the hostname of that asset and how far back in time can I go to locate a malicious incident on a highly mobile endpoint? We commonly refer to this use as event alignment. This same problem applies to users, and all of that contextual information is very critical to making informed decisions. Criticality of every entity in the enterprise is also key to business prioritized risk decisions.


Not surprisingly, data sources are all narcissistic. They only talk about themselves and often repeat things that are not valuable. Routers are notorious for talking about route flapping; route-up, route-down, route-flap, If no one cares, why do we collect it? Unfortunately, an agreed upon set of informational fields across data categories, vendors and applications does not exist.  If it did, this would allow us to derive much higher value from all this data. 

Moral of the story — don’t get sucked into the myth that collecting 100 data sources into a single data platform, is providing real value for operational security or any of the other applications. The reality is, these efforts are not providing much value at all and most likely increasing your cost and volume without reducing your risk significantly. Collect only what matters and focus on deriving deeper value from it via automation. And remember, humans should not monitor consoles for high noise, low signal use cases. 

Join our growing community! Subscribe to our newsletter, the "First Responder Notebook," delivered straight to your inbox.