An alert, or threat log, is the primary type of data ingested and analysed by SOC.OS. Alerts are generated by security protection and detection tools such as IPS, EDR and SIEM tools, to name a few. To see the full list of compatible tools SOC.OS ingests alerts from, please visit Integrating your Tools.
An alert/threat log is a single record indicative of activity pointing to a potential security threat. It often represents a grouping of event logs.
For example, a single alert might warn of 100 failed logins to a system in 30 seconds, which would be indicative of a brute force attack - alone, it represents actionable intelligence that would be an immediate cause of concern for an analyst. This is likely to lead to further investigation and therefore should be ingested by SOC.OS. We use this alert data to correlate and form clusters for your analysis.
An event log can be generated by any number of systems in the network. A group or pattern of event logs might trigger security tooling to produce an alert, but the majority of the time it just represents everything happening in the network.
An event log is a single record representing a happening/event taking place within an IT system.
For example, a single event log might show a single failed login to a system, which could be part of a brute-force attack, or it could be an authorised user mistyping their password - it represents a single piece of point-in-time intelligence that on its own is not an immediate cause of concern for an analyst. This is not likely to lead to further investigation, and therefore should not be ingested by SOC.OS. One hundred of these event logs occurring in 30 seconds might trigger the brute force alert described above - but only the single alert, not the 100 event logs, should be ingested by SOC.OS.
A cluster is a group of security alerts which SOC.OS has deemed to be related and grouped together. This ensures that, for example, alerts targeting the same part of your network with similar threat types would appear in the same cluster. Each cluster consists of anywhere between 1 to 5,000 alerts.
A cluster represents a group of alerts that have been correlated together because they share a common set of features that would suggest they are part of the same incident.
A cluster is dynamic and can grow as and when new and relevant information is generated. Say that on a particular day, 15 alerts were generated and on day two, 10 alerts were generated. Provided that they share common features (e.g. threat type, IP addresses, timelines, etc.) these 25 alerts will correlate into one cluster.
Clusters are then graphically visualised in the tool to easily show who is involved (internal and external entities), what threat(s) the cluster represents (aligned to the MITRE ATT&CK® Enterprise Framework) and when it started and stopped correlating (this timeline can span days, weeks or months).
A key benefit of clustering alerts together based on similar threat types and entities is an enhanced “full-picture” visibility. Consider the following example:
A cluster is a grouping of security alerts which are related to a unique or similar activity taking place on an IT estate. SOC.OS analyses the timeline, entities and threat types (aligned to MITRE ATT&CK®) within an alert to determine whether 2 or more alerts should be combined into a cluster.
To see this live in action based on a real anonymised customer data, please watch our demo video.
An entity is a representation of an object involved in a cybersecurity incident, including (but not limited to); IPv4 Addresses, Domains, URLs and SHA256 Hashes. It's possible that two entities could represent the same object; for example, an ipv4 address entity and a hostname entity could both represent the same physical server. Equally, a sha256hash entity and and md5hash entity could both represent the same file.
SOC.OS uses entities as part of the correlation process which groups alerts into clusters.
Entities can also have attributes. This adds extra contextual information about the entity; for example, a domain might be attributed to a country, or a sha256hash entity might contain a file size.
All entities have a category attribute, which can either be internal or external. An internal entity is owned, managed, or under the responsibility of the organisation using SOC.OS. This often includes private IP addresses, but might also include public IP addresses or domain names that they own. An external entity is anything that isn't an internal entity, such as unknown URLs or IP addresses.
Additional attributes are added to entities through third-party enrichment or custom enrichment. This allows analysts to quickly understand the entities involved in a cluster.