One of the recent trends I’ve encountered for security operations teams is to design a more intelligence-driven SOC, where existing threat intelligence investments are leveraged to assume a more proactive security posture. More and more frequently, this trend is now a requirement.
This requirement may be expressed in any one of a number of use cases, but boils down to the same fundamental capability - that of being able to trigger a process as a result of the receipt of new intelligence, and take it through a number of stages so as to action it on the relevant security controls.
Some examples of these use cases might be:
As diverse as these use cases are, they can all be addressed by the combination of two relatively recent additions to Anomali ThreatStream’s functionality - the rules engine, and private tags.
The rules engine allows an analyst to specify a number of conditions, such as watching for a malware family’s name in incoming intelligence streams, new IOCs from phishing attachment detonations, a marker tag added by an analyst, or observables of a specific iType. For any observables that match the conditions, actions can be automatically triggered to open an investigation, create a bulletin, or add private tags to the observables.
Private tags are available in exactly the same way as public tags, but as the name suggests, only your organisation can see them. However, you can apply them to any observable or entity, private or public, shared or not. As such, an analyst can take observables from any source - OSINT, ISAC-shared, published by a commercial vendor - and apply private tags to them. Combined with rules, this opens up a useful capability.
A Finite State Machine (FSM) is one of the classes of automata in computational theory. In it, a machine sits stable in one of a number of possible states, until an input pushes it to transition into another state. From there, another input will cause it to transition again into another state, and so on, and so on. A generic example of an FSM is below.
If this looks familiar, it’s probably because you’ve seen graphical illustrations of SecOps ticketing system workflows or orchestration playbooks that use similar concepts for ticket stage and playbook stage respectively. In the context of a ThreatStream, a FSM would allow us to push new intelligence through a multi-stage process, with different triggers for the transition at each stage.
Private tags and rules allow us to create such FSMs in ThreatStream:
Private tags can be used to interact with external systems as well. In our example, all new IP addresses with the tag block_at_firewall set can be synchronised via Anomali Integrator to the perimeter firewall, in order to block any further communication with those IPs. Private tags can also be used in search filters within ThreatStream, in passing IOCs to SIEMs and EDRs, in providing responses to API queries, and in creating investigations.
In this example, we use our new FSM-building skills to manage the handoff between automated and manual stages of a process for addressing spear-phishing emails.
When a phishing email is received in the ThreatStream phishing inbox, ThreatStream handles the IOC scraping and sandbox detonation without any interaction from the analyst. It also handles the enrichment and scoring automatically. However, it also adds the private tag received_phish, meaning that we can define a specific process for indicators coming from this source.
After the IOC is imported, the for_NOC_blocklist_review tag is added, as we intend to block all IOCs that are identified from spear-phishing, but in this organisation, such blocks require NOC approval. A saved search using this filter tag quickly shows the new IOCs awaiting approval. and the NOC grants it by adding the NOC_blocklist_approved private tag.
From this point, a number of rules watching for this tag are triggered. Depending on each IOC’s iType, the rule will add a further tag of block_at_firewall, block_at_edr, or block_at_proxy. For each one of these tags, an integration will action the relevant IOCs by pushing them down to that security control to be blocked.
In this post, we have demonstrated how private tags and rules functionality within ThreatStream can be applied to implement a multi-stage process that is threat intelligence-driven, including interaction with other stakeholders and with various security controls. While a few simple use cases have been quoted to illustrate the concept behind this, more complex workflows are possible where required by using this approach.
Damian is a Principal Solution Architect for Anomali, building threat intelligence platforms and programmes for large enterprises in EMEA. Before Anomali, Damian was the SIEM regional architect and led the security digital transformation area programme for HPE in Asia-Pacific. He holds certifications including GIAC CTI, CISM, CISSP, CEH and CCSK.