Objective

Security operations (SecOps) teams use pattern-matching rules in security event logs for detection. Integrating external threat intelligence, especially Indicators of Compromise (IoC) feeds containing malicious IPs, domains, file hashes, and URLs, significantly enhances these rules. Combining IoC data with behavioral events in SIEM and security analytics platforms allows for proactive threat identification and faster, more accurate responses, shifting from reactive to anticipatory security. Key considerations for leveraging IoC feeds include selecting reputable sources, normalizing and integrating data, and developing correlation logic with behavioral indicators. This approach empowers impactful Google Security Operations’ rules using threat intelligence.

The subsequent sections will delve deeper into these aspects, providing practical guidance on creating impactful SecOps rules that harness the power of threat intelligence.

IoC Feeds in the SecOps Environment

Google Security Operations rules follow YARA-L syntax and UDM fields to support leveraging feeds (ingested into Entity Graph). One such field is threat_feed_name under security metadata https://cloud.google.com/chronicle/docs/reference/udm-field-list#securityresult

An IoC feed should be available for YARA-L rule via ECG (Entity Context Graph). This requires an integration of the feed into ECG and the feed should be structured according to entity graph requirements. Adding feeds to Google Security Operations environment is briefly mentioned later but is not the focus of this document.

Writing Rules using IoC Feeds

Once the feeds are promoted to Google Security Operations environment, rules based on feeds will execute and generate security alerts based on the appropriate matches.

Simple is_present rule

A simple is_present rule can be the detection of an IoC that exists in a feed. For example, if a customer is receiving traffic from Tor Exit nodes and would like to be alerted, the following syntax for events, can be useful:

The above example is based on the feed from Google Threat Intelligence, Tor Exit Nodes. 

Note the metadata fields that are used in the rule. One way of pointing the rule to a feed is via using the field threat_feed_name. More about supported fields can be found at UDM_Fields

Complex Rules

In addition to leveraging curated threat intel in the form of IoC feeds, YL2 rules can include additional conditions, either to enrich the detections or elaborate the detection criteria. For example, one can detect multiple login failures from a Tor (or Remote Access Tool - Feed and  example attack) network to confirm that a malicious actor is trying to access the Google Workspace. Following is the sample complex rule involving multiple events - 

Tip: Above code constructs (outcome and condition) can further optimized with count syntax as follows -

Rule based on multiple feeds

There can be detections which would check multiple events and IoCs, which can be from various feeds. Rules can be written leveraging multiple feeds. Following is an example of 

• a sample which could be malicious and from remote access tools and 


• traffic is coming from Tor exit nodes. 

It would be a similar rule to the above complex rule, but matching IoCs should be joined. For example, IP match from Tor Exit Nodes feed and 

Current IoC Feeds in Google Security Operations Environment

Feeds for all Customers

Following feeds are available in Google Security Operations for all the customers to consume - 

• Tor Exit Nodes: Is a collection of IPs that act as Tor exit nodes.


• Remote Access Tools: Is a collection of malware hashes associated with Remote access tools.


• Benign Binaries: Collection of hashes from known benign binaries.

In addition, there are other types of feeds like -

• WHOIS: Public dataset of Domain name information.


• Safe Browsing: Hashes related Safe Browsing
  
  

Enterprise+ Customers

Enterprise+ customers have access to fusion feeds and can benefit from additional threat intel. Fusion feed consists of IoCs (IP, Domain, Hashes and URLs) associated with malicious activities. These feeds are curated from frontline insight from Google Threat Intelligence Group and Mandiant Consulting. 

Fusion feed events are matched as follows -

Additional context or metadata

For contextual metadata, fusion feed comes handy with most of the additional attributes that can be leveraged in conjunction with original rule logic. Following is an example of of YL2 rule which is using the additional metadata (like confidence score and active breach information) from the fusion feed -

Adding new Feeds

Customers can use Google Security Operations supported feeds or add their own feeds which need to be ingested into the environment during the rule execution. 

Following are a few high level references that can be used to get started on adding custom feeds -

• Entity Ingestion - https://cloud.google.com/chronicle/docs/ingestion/ingestion-entities


• Feed management  - https://cloud.google.com/chronicle/docs/administration/feed-management


• Writing custom parsers for your feeds - https://medium.com/@thatsiemguy/why-doesnt-chronicle-siem-have-a-default-misp-parser-d7b23ba87093


• Using Google SecOps Parser extensions (if existing parsers do not support your requirements) - https://cloud.google.com/chronicle/docs/event-processing/using-parser-extensions

Please note that customers can always reach out to Google Security Operations if they would like to onboard specific feeds into the chronicle environment.

Best Practices

As in most scenarios, there are some best practices that should be followed for composing effective detections in Google Security Operations environments.

Performance: 

Please note that, having the feed in the Google Security Operations rule execution environment and finding the appropriate IoC can be computationally expensive. This will be even more difficult when there are multiple feeds involved. To overcome this, composite rules can be used where the initial detections can be as basic as possible and apply rule-changing to combine initial detections.

Outcome section:

• It will be useful to emit the feed(s) names that were used in the rules to be able to track back as the reason for alerts. Sometimes, feeds may consist of false positives, and the alert can act as a feedback mechanism.


• Fields extractions from the feed entities are required to be aggregated in the outcomes section due to YL2 requirements.


• Limitation on the amount of  data that can be emitted in the outcome section should be considered.
  
  

Takeaways

• Google Security Operations detections are usually based on events and patterns.


• The detections can be expanded using threat feeds and this post highlights an overview and provides initial references and examples.


• Customers can use existing feeds, or request for new feeds or onboard their own custom feeds.