Building Intelligence-Driven Security Operations

Security teams are under pressure to move faster, but most workflows still rely on manual steps and disconnected tools.

An intelligence-driven SOC changes that by using threat intelligence to trigger actions, guide investigations, and automate response workflows.

This post walks through how security teams can use automation and structured workflows to operationalize threat intelligence in real-world environments.

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.

Common Use Cases for Intelligence-Driven Workflows

In practice, intelligence-driven security operations are built around triggering actions based on new threat data.

Examples include:

• Automatically analysing malware attached to a spear-phishing email, and sending the malware IPs, domains and URLs to firewalls, web proxies and mail security gateways in order to mitigate the risk of other recipients becoming compromised
• Receiving intelligence on targeted web application attacks from your MSSP, requesting approval from your networks team to block them, and then implementing the block.
• Receiving a bulletin on a new malware variant from your ISAC, triggering a scan of known file hashes on your own workstations, while raising a ticket for further investigation

These workflows reduce manual effort and improve response speed. 

Using Rules and Tags to Automate Workflows

ThreatStream enables automation through two key capabilities: rules and private tags.

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.

Together, rules and tags allow teams to automate processes like investigation creation, enrichment, and response actions.

Building a Finite State Machine in ThreatStream

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 allow us to track the state in the machine of an observable. For example, if we add the tag for_NOC_blocklist_review on a malware IP address, this might put the IOC into a state where it is pending review by the NOC.
• Rules facilitate transitions between states. For example, if the NOC has reviewed the IP address above, and have set a tag NOC_blocklist_approved on the malware IP address, then a rule can watch for new IP addresses being assigned this tag, and transition these to the next state, by adding another private tag automatically - block_at_firewall.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.

Example: Automating a Phishing Response Workflow 

A common use case is managing phishing threats from detection through response. 

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.

Conclusion

Intelligence-driven security operations help teams move from reactive alert handling to more structured, proactive workflows.

By combining threat intelligence feeds with automation, organizations can reduce manual effort, improve response times, and make more consistent decisions.

As environments grow more complex, this approach becomes essential for scaling security operations effectively.

‍