Getting started with Google Security Operations SOAR
To begin working in the Google Security Operations SOAR platform, the first thing to understand is the very basic concepts which are mentioned frequently in our documentation, and are important to know.
Be sure to read it in the given order, since each explanation relies on the prior one.
Connectors
Connectors are the ingestion point for alerts into Google Security Operations SOAR. Their goal is to translate raw input data, coming from various sources, into Google Security Operations SOAR data. The connector gets alerts (or equivalent data) from 3rd party tools, and forwards normalized data into the Data Processing layer. Google Security Operations SOAR provides out-of-the-box connectors for today's most popular security systems and also a Python SDK to develop new ones easily, if needed.
Cases, Alerts and Events:
Case consists of alerts which were ingested from a variety of sources by the connectors. Each Alert contains one or more security events. Once ingested into the platform these events are then analyzed and their indicators, destinations, artifacts, etc are extracted into objects in Google Security Operations SOAR called entities.
Entities:
Entities are objects that represent points of interest extracted from alerts (IOCs, artifacts etc.).
Entities allow you to automatically track their history, group alerts without human intervention and hunt for malicious activity based on the relationship between the different entities.
In order to visually present the entities and their connection in the platform, there is a configuration process of the ontology that involves mapping and modelling. During this process, you select the visual representation of alerts and the Entities that should be extracted from it.
Google Security Operations SOAR provides basic Ontology rules for most popular SIEM products out-of-the-box.
How to create Entities in Google Security Operations SOAR:
The process of mapping and modeling allows you to create the entities
related to a specific model family and to visualize the connections between
them in a case.
By mapping and modelling we can define the entity properties such as what defines if an entity is internal or external is the configuration in the settings and if its malicious or not by the product we run in the playbook. The mapping and modeling is more for what is source, what is time, types etc.
The mapping and modeling occurs once during the first time it is ingested and from then on the rules will run on each case inserted that is relevant to it.
Playbooks
A Playbook is an automation process that can be triggered by a predefined trigger. For example, you can trigger a playbook for each alert that contains the product name "Mail": This means that the playbook will attach to each Alert ingested into Google Security Operations SOAR from this product.
Each playbook consists of actions that can be configured to run manually or automatically on the scope defined for the alert entities. For example, we can configure VirusTotal - Scan URL action to run automatically only on a specific entity type such as URL entities.
The actions take place by their defined order according to conditions- (flows) forming a tree of actions. When the final action is done, the playbook gets to a resolution for the triggering alert.
Environments
You can define different environments to create data segregation and assign platform users to one or more environments. This means that the users see cases and related information about these cases from those environments only. Some user roles have access to all environments, which grants the users full access to data from all environments in their platform including any new environments added later.