The Advisor’s Workbench

In my last blog, I talk about some of the changes and opinions I see in the market and started a discussion around a label and a definition of a role that while new, someone(s) is already performing within security organizations today.  The definition of the role could provide the official recognition and power necessary to provide additional security effectiveness, visibility and control.

Additional effectiveness, visibility and control is gained not through new alerts or detection technology.  Nor is it gained through adding yet another external news source or sharing group to pump even more information into systems to create more alerts to be parsed for false positives.

Additional effectiveness, visibility and control is gained through better internal focus, internal and external context and an understanding of security at a higher level.  The Advisor works between the teams, bridging the communication cracks that inevitably popup.

Figure 1: https://goo.gl/images/JwBik4

In the picture above the Advisor sees Bigfoot.  The Security Operations Center (SOC), or endpoint, or threat and vulnerability management usually aren’t high enough to see Bigfoot. They typically see a water buffalo, or a lion or a flower.

To get this level of visibility we have to be able to look externally and internally at the same time.  Along with being able to direct appropriate actions based on a library of internally sourced information and be able to hold people, processes and technology accountable to expected response times.

That’s a lot for a tool to do.   Let me show you the ThreatQ spin on this.  We call it ThreatQ Investigations.

We are going to hit on two use cases.  A standard SOC Sighting Use Case that utilizes data from both internal and external sources, and a non-indicator centric use case for those policy and procedural events that happen in Incident Response that can get wider than just re-imaging a box or deleting a user profile.

Up first some background information on ThreatQ Investigations.

Figure 2: ThreatQ Investigations

The screenshot above is from ThreatQ Investigations.  ThreatQ Investigations is a Cyber Situation Room that is designed to provide a collaborative platform for security awareness, threat assessments, and as a war room or situation visualization tool.

It is divided into three separate sections:

• An explicit timeline for tracking the investigation, a timeline for tasks that been created and assigned that are related to this investigation, and then a selected object time line at the bottom
• A sandboxed node graph-based workspace in the middle
• A context viewer for selected items on the right-hand side.

The explicit timeline is meant to help the management of the investigation.  When the notification was received, breach identified, vulnerability published, etc.  Then you would add additional timeline entries for the sections of the policy or plan.

The sandboxed workspace is the heart of the system.  While it may look like a node graph, and it is, it’s primary purpose it to allow the user(s) to quite literally connect the dots during a breach or an incident while collaborating and sharing the investigation with other teams or team members in real time.

The context viewer is effectively a view into the library of any context or information that has been gathered or collected.

While on the concept of the library it is important to note that we have also now empowered our customers to save and relate data however they see fit.  In older versions of ThreatQ our users had the following object model:

• Adversaries
• Signatures
• Files
• Events
• Indicators

Since we are single tenant, we have always given our users the flexibility to use this object model however they saw fit through our integrations, partnerships, or establishing their own context model or library framework.  We have now expanded this to allow our customers use provided STIX 2.0 or 1.2 object frameworks, or to work with us to create their own specific objects to match their analysis or library requirements.

In the investigation above an event was created in ThreatQ that contained indicators that were seen within the protected network.  It is important to point out that these indicators don’t have to be sourced from an external blacklist or feed.  ThreatQ’s bidirectional integrations allow our users to create their own searches or pattern matches that can be sent to a local Threat Library to be indexed, cataloged and related.  Also, the indicators could have been a recipient email address from a spear phishing attack or a series of phishes to multiple recipients that may all contain the same link, or file, or base domain, etc.

These indicators, or even recipients are continuously prioritized or scored based on localized criteria.  It is these prioritizations that may drive the creation of a shared investigation for a company-based triage of an event or incident, in effect what we see above.

So, for the SOC sighting Use Case we start from an internal SIEM sighting:

Figure 3: ThreatQ Investigations, SOC Sighting Use Case

With the timeline entry at the bottom we can track when this sighting was created in the network along with all the context or data provided.  In this case the other indicators that were seen in the network at that time or the indicators from the pattern matches.

Just a quick look over this information and as either the Intel specialist or as a coordinator I decide that we need to look into two indicators specifically.

I decide to start looking into the IP address, but the sadmountain indicator looks interesting so I task one of my team members, either in the SOC, or Incident Response (IR), or in Threat Intelligence (TI), or Threat and Vulnerability.  I do this from right clicking on the indicator in question, or on multiple objects and right clicking.  The task due date and the task creation is marked on the time and associate with the indicator.

Figure 4: ThreatQ Investigations, Add Task

Once the team member receives the task that’s where things change and open up.  We expect the new user to open the same investigation that the coordinator is working on and to have access to all the same data and enrichment tools.  They have the full range of right click options to gather more information, query internal systems, task others, etc.  But since it’s sandboxed only their view changes with their additions as they work through and complete their task or their team’s task or a new piece of information is determined to be valuable.  Then they can add those pieces to the larger investigation through another right click action.

Moving along the investigation, it has been mapped to additional sightings that occurred within the network through an internal spear phishing event linked to the IP address, and down through an adversary group from an external feed source and back to an internal ticketing system. Not only have we been able to collect and track indicators but we have also been able to track the particular vulnerability being utilized.  In this case, we are investigating an Identified CVE from a intelligence report from an outside feed source.

The critical path in this investigation is:

• 222.X.X.X IP address to a spear phish email based on enrichment of the IP address to a domain registration.
• The sender Email address seen in the spear phish event is from the same domain.
• The email had either a malicious link embedded to a malicious file attached.
• Analysis of the link or the file lead to the associated Adversary (Pulled from an external source)
• A vulnerability typically used by that Adversary, and potential linked to a specific file or hash was identified.

Figure 5: ThreatQ Investigations, View details

I can use the workbench to reach out to my vulnerability tools to see what hosts we have that match.  Once I have that information I can task the server and the vulnerability group.

Figure 6: ThreatQ, Operations

Figure 7: ThreatQ Investigation, Task Details

In the screen above, I created the task and added not only the hosts that need to be looked at, but also the vulnerability details, and if I wanted I could include the link to get the patch either from the library or from an outside source in real time.   The task is added as node in the workspace and also as a tasked timeline entry.

Figure 8: ThreatQ Investigations, Timeline

I think you get the general idea.

A single user or team can drive the focus and the steps of an investigation, the handling an internal event, or verify the impact of an external notification.  All while keeping track of who was going to handle the next step.

There is also the ability to improve security effectiveness and efficacy by tracking how and why an action was taken or decision was made, along with most importantly, the when it was assigned and when it was completed

Next the Non-Indicator Centric Case Study:

In this case study let’s talk about an investigation that has nothing to do with indicators but has everything to do with breaches and public data exposures.  A lost laptop.

In this case it is as simple as creating a new event and calling it “Lost Laptop” and then creating some tasks around the issue to help us coordinate and resolve.

Simple questions to answer:

• Who lost the laptop?
• Where were they?
• What information was on it?
  • Is a recent backup available?
  • Was the drive encrypted?
  • What type of security is enable to log into the laptop?
• Can we remote wipe?
• What would the impact be if the information on the laptop was accessed?

The key for the investigation here, is not that the advisor would know all these things, but that they should know WHO to contact or task to answer these questions.  Also, it is up to the advisor to determine the severity of the issue.

In this case she or he may be tasking the IT group, pulling internal systems and backups, contacting Access Control, etc.

However, when it comes to assessing the severity of the issue, the advisor can contact Risk or Compliance, but he or she could also use some tricks from ThreatQ itself to help determine severity and provide evidence on why one issue should be elevated above another.

Figure 9: ThreatQ Investigations, Lost Laptop Investigation

In the investigation above we have lost laptop timelines and a task assigned to IT to pull the latest backup.  We have also expanded some of the attributes of the user that had the laptop.

With ThreatQ’s API capabilities we can communicate and pull information from virtually any source.  Here we pulled some basic attributes but also created some new ones around victim exposure, corporate risk levels and if the person travels or not.  These attributes and values in association with other information pulled from internal sources allow us to create an internal risk or exposure ranking through ThreatQ’s scoring and prioritization engine.

Figure 10: ThreatQ Threat Intelligence Platform Scoring and Prioritization

We increased or decreased a victim or a victims’ identifier (email address in this case) based on whether or not they travel, their department, their exposure, and do they have access to sensitive or classified information.  If we do this for all the employees we end up with a list.

Figure 11: ThreatQ Threat Intelligence Platform, Indicators

Once the list is sorted we can then apply a tag or attribute and value to the users as an identifier of high corporate risk.

Figure 12: ThreatQ Threat Intelligence Platform, Attributes

In this case, the CEO Anna Hogan is listed as a ‘yes’ to the custom attribute of a Top Three Corporate Risk Target, and visually we can see the relationships between her and other events that have occurred.

Figure 13: ThreatQ Threat Intelligence Platform, Event – Incident

Like a target spear phishing event or, in this case the CMO losing his laptop while at a bar during RSA.

Figure 14: ThreatQ Investigations, User Interface

The goal of this case study is different from the SOC sighting.  In this one we have personalized information that guides the investigation more so than a standard process.  Here the user was a top 3 corporate risk user so the question of the severity of the investigations was answered for us almost immediately.  The advisor receives the responsibility and influence she or he needs to start asking the questions to guide the investigation to a timely end, or to prepare the company for fallout of the lost data.  Since they not only have the visualization and the ranking of the level of corporate risk but also the evidence and can “show their work” on why the user and the loss of the laptop signifies a major issue more can get done.

It’s not a gut decision that’s being made, it’s an evidence-based decision that is accurately communicated and can be defended.  That is the key to the advisor’s workbench.  It allows the collection of disparate pieces of information into the library and to show how those disparate pieces relate to each other.

While it depends on your definition of threat intelligence and your company’s internal toolset there is always a place for a system to provide feedback on what is and isn’t working well.  Normally in security this occurs at the team level through Quarterly Business Meetings and reviews of reports from the different tools.  This tool can be focused on processes, timelines and expectations.  Advisors can utilize the workbench to ask a question, get the answer and launch a shared investigation or exercise that the whole security stack can participate in.  They can judge and provide evidence of the effectiveness of not only indicators or detection pieces like rules or signatures, or specific blacklists, but also on how teams and processes perform on their assigned tasks.

This ultimately is the job of the Advisor.  To work at the people and process level of security by gathering evidence of what is important, what is working, and what isn’t.  ThreatQ investigations provides a unique capability to gather, structure, and present this evidence in a collaborative way that increases security effectiveness.