The Advisor’s Workbench

Share and earn Cybytes
Facebook Twitter LinkedIn Email

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 to necessary 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 inevitable popup.

Figure 1:

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 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 222 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 a spear phishing event that was collected, and down through an adversary group and even back to a different ticketing system event that has also been correlated.  But the important part for this case study is that not only have we been able to collect and track indicators but also through external intelligence, or through our own sandboxing or forensics capability, that a particular vulnerability is being utilized.

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

This 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 a 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 virtual 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 and internal risk or exposure ranking through ThreatQ’s scoring and prioritization engine.

Figure 10: ThreatQ Scoring and Prioritization

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

Figure 11: ThreatQ, 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, 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, Event – Incident

Like a target spearphishing 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.

The post The Advisor’s Workbench appeared first on ThreatQuotient.

Share this post and earn Cybytes
Facebook Twitter LinkedIn Email
About ThreatQuotient
ThreatQuotient™ understands that the foundation of intelligence-driven security is people. The company’s open and extensible threat intelligence platform, ThreatQ, provides defenders with the context, customization and collaboration needed to ensure that intelligence is accurate, relevant and timely to their business. Leading global companies are using ThreatQ as the cornerstone of their threat operations and management system, increasing security effectiveness and efficiency. For more information, visit

Our Revolution

We believe Cyber Security training should be free, for everyone, FOREVER. Everyone, everywhere, deserves the OPPORTUNITY to learn, begin and grow a career in this fascinating field. Therefore, Cybrary is a free community where people, companies and training come together to give everyone the ability to collaborate in an open source way that is revolutionizing the cyber security educational experience.

Cybrary On The Go

Get the Cybrary app for Android for online and offline viewing of our lessons.

Get it on Google Play

Support Cybrary

Donate Here to Get This Month's Donor Badge

Skip to toolbar

We recommend always using caution when following any link

Are you sure you want to continue?