Remember 3 C’s Part 2
Welcome to part two of my three-part blog series on the 3C’s (Coverage, Context, and Cost) required for sustainable security monitoring infrastructure. In the last blog, I reviewed the importance of effective Coverage within a modern security operation. Today’s blog will focus on the second “C”—Context.
When it comes to triaging security alerts, CONTEXT IS KING! Context helps the analyst paint a picture of what is happening. Context makes a generic security alert relevant to your organization. Alerts that include internal, external and historical context makes the difference between a security alert which needs to be re-triaged and a security incident which is deemed malicious and actionable and can be acted on right away.
Step into the shoes of a security analyst. Let’s take for an example a single alert from a network intrusion detection system. The alert indicates that a permitted malware communication has occurred between two systems. Given the number of events in your queue, you probably can’t afford to spend more than a few minutes to decide if this alert represents a true threat to your organization.
A thorough analysis with context for this alert would include:
- Who is the attacker? Who is the target?
- What type of attack is this? How sophisticated is it?
- What is the attacker’s objective?
- Was the attack successful? Is the target vulnerable? Was it remediated by another control?
- What would be the impact to the business if it were successful?
- Is this happening anywhere else?
- How long has this been going on for?
Answers to the majority of these questions are not provided within an alert. Generally, an alert contains limited context and the only identifiable information in the alert is a set of IP addresses. To determine if an alert indicates a true threat or is just another false-positive, three contextual areas must be considered:
Internal Context: Contextual information about internal systems, like the system’s business function, importance, location, and vulnerability, reside in adjacent repositories which take time to retrieve information from as well as evaluate the data’s significance in the context of the attack. Context about internal systems helps an analyst understand if the observed attack is even relevant to the target system as well as help prioritize the incident -- is this attack against a production server or a visitor on the guest network?
External Context: Given that only an IP address is included in the event, external context can help attribute who owns the IP address and its geolocation. Reputable threat intelligence is helpful in understanding more about the attacker, the attacker’s intent, and if other organizations have been targeted.
Behavioral Analysis: Historical patterns of the behavior and associations of systems and account help corroborate if the observed activity is malicious or just normal behavior. Incidents unfold over time, involve multiple data sources, and adversaries attempt to ‘live off the land’ – meaning they will attempt to hide within authorized administrative tools.
In reality, security teams don’t have the capacity to collect and analyze the terabytes of data generated by security sensors or escalated by MSSPs (especially as organizations continue to increase their coverage and add new data sources). Effective decisions are made only when the event is considered with all the contextual elements combined, however gathering sufficient context takes time – something human analysts are short on. Machines, however, are 100% consistent, able to operate on large data streams and emulate human analysis and decision making through artificial intelligence approaches.
Do existing security monitoring technologies provide the “context” needed to identify and triage attacks, faster?
The short answer is no, at least not without a significant effort. SIEMs and SOAR (Orchestration) platforms can provide this context, but it comes at a cost. Both require you to build and maintain content within their platforms (correlation rules and playbooks, respectively), enabling you to apply boolean logic and if/then/else conditions. Additionally, these platforms were not meant to scale to modern data volumes, correlation rules and playbooks hit performance issues and can only operate on a pre-filtered set of alerts/inputs — which in turn has its downsides (a significant reduction in visibility/coverage).
However, let’s say that you are able to overcome the hurdles listed above and your security monitoring technology is effectively decorating events with relevant context. The challenge here is that a human analyst is still required to think deeply, judge the overall event in light of the context and make a manual decision if the event is malicious and actionable.
Bring Decision Automation into the security tech stack
Decision Automation software automates the collection of relevant context AND the interpretation of security alerts by emulating human reasoning and judgment. And the good news: you can (if you find the right tool) integrate this technology quickly. The most robust Decision Automation software is plug-and-play and immediately enhances the capability of existing SIEM and SOAR platforms. Decision Automation only presents the most valid security threats with the contextual evidence required within the alert so analysts can understand and respond quickly.
The importance of context when monitoring and triaging security data should not be underestimated. Context truly is King! The more context analysts have, the more confident and efficient they will be in resolving attacks. Armed with evidence to effectively respond to malicious attacks, morale rises and security teams become empowered. Contextual alerts save security teams valuable time, money, and resources.
This leads us to the 3rd “C” in our series—Cost. Stay tuned for next month’s final blog when I’ll examine the ROI that can be achieved with Decision Automation. Find out how understaffed security teams can identify more valid incidents and reprioritize resources to focus on higher priority projects—all while staying under budget!
If you would like to talk with one of our cybersecurity experts to discuss how to integrate Decision Automation into your security infrastructure, contact us: firstname.lastname@example.org
Tim Wenzlau is a Product Manager at Respond Software. He is focused on adding skills to the Respond Analyst--continuously improving the Respond Analyst’s intelligence, visibility, awareness, and user experience. Prior to Respond Software, Tim managed and launched a user behavior product and held various roles in corporate development, strategy, and business operations. Tim holds a degree in Operations Research and Financial Engineering from Princeton University.View all posts by Tim Wenzlau