Secure60 - Common Information Model (CIM):


The term Common Information Model (CIM) is used to describe what an Event should look like so that we can extract maximum value from the data.

When an Event is categorized properly inside the CIM, it means that we can extract deep context around the Event and construct Entity groupings based on this information.

An example of this context and the value might be: We capture Events that have multiple different type fields which could be email or app for example. Each of these Events could have a common operation value such as user-logon and a common field auth_username which contains the value john.doe.

Based on this information, we can then track and correlate the behavior of the user john.doe across all systems and have a much more powerful viewpoint into behavior. john.doe logging into multiple systems they have never logged into before or failed logon attempts across a range of systems are much stronger signals of malicious activity than individual events alone.

Secure60 - CIM Definition:

Fields in bold are compulsory. Filling in as many other fields as possible will ensure that the system can fully process context and perform effective correlations.

Fields that start with a type value indicate fields related to that entity type. For example, type = "http" would ideally have multiple fields such as http_status_code and http_uri submitted with the Event, otherwise, detections associated with the type = "http" will not be able to successfully match with full context.

type
operation
outcome
vendor
product
technology_group
environment
schema_version
timestamp
source_
http_
ip_
network_
dns_
host_
data_
event_
app_
auth_
user_
privilege_
security_
error_
agent_
file_
email
process_
alert_
message_
syslog_

Source, handler and destination

An administrator connects over a VPN to a server and logs in with SSH. The event that arrives carries the VPN address in ip_src_address, and that is correct: it is where the connection came from. The question the event has to answer next is which machine was logged into. Its name is in host_name; its address needs a field of its own, or a rule that resolves hosts by IP address can never see the login.

Every event involves up to three parties: the source that initiated the activity, the handler that recorded it, and the destination the activity was directed at. On most events they are the same machine. On the events that matter for detection they split, and the field a value lands in states which party it belongs to.

A value comes from one of two places. The payload is the line the program wrote. The envelope is what syslog, a relay or an agent wrapped around it on the way to the collector. An address read from the payload is the source. The machine’s own address is only ever known from the envelope.

Envelope — added by syslog, the relay or the agent HOSTNAME header app-server-02 origin ip (named by the relay) 198.51.100.24 TCP peer (the relay itself) 198.51.100.5 Payload — the line sshd wrote Accepted password for j.smith from 203.0.113.45 port 52114 ssh2

Payload values: user_name j.smith, ip_src_address 203.0.113.45. Envelope values: host_name app-server-02, syslog_origin_address 198.51.100.24, syslog_ip_src_address 198.51.100.5, and ip_dst_address 198.51.100.24, because the payload names a remote source and no destination, so the recording machine is the destination.

Party Field Holds When no other party is named
Source ip_src_address The address the activity came from, as the payload states it. The machine’s own address, from the envelope.
Source user_name The acting identity. For a login, the account that logged in. —
Handler host_name The machine that recorded the event. On an endpoint it is also the destination; on a firewall, domain controller or identity provider it is an observer. —
Handler syslog_ip_src_address, syslog_origin_address How the event travelled: the transport peer, and the origin a relay named. Provenance only. —
Destination ip_dst_address The address the activity was directed at. Firewalls, flow exporters and resolvers state it in the payload. When the payload names a remote source and no destination, the collector fills it with the recording machine’s own address from the envelope: that machine is the only other party. Empty. Nothing was directed anywhere.
Destination host_name Doubles as the destination name whenever the handler is the destination. —

Which party a value belongs to follows from the shape of the event. Every value is either read from the payload or taken from the envelope.

from the payload from the envelope from the envelope, filled by the collector empty All one box nothing remote is involved source ip_src_address = box handler host_name destination empty cron, process-create, file-write, console logon, sudo Remote → box someone reached this box source ip_src_address handler host_name destination ip_dst_address = box sshd, RDP (4624 type 3 and 10), WinRM inbound, web server access log Box in the middle an observer, not a party source ip_src_address handler host_name destination ip_dst_address firewall, NetFlow, DNS resolver, RADIUS, domain controller 4768 and 4769 Box → remote this box reached out source ip_src_address = box handler host_name destination ip_dst_address 4648 explicit credentials, Sysmon 3 outbound connection, curl from the host

Two fallbacks mirror each other. When the payload names no source, the recording machine is the source. When the payload names a remote source and no destination, the recording machine is the destination. Both take the address from the envelope, and a parser that states either value in the payload always wins. Events that arrive without an envelope, such as cloud audit feeds, get neither fallback.

isEntity() and isEntityGroup() match a host wherever it appears, as source, handler or destination: they resolve host_name, ip_src_address and ip_dst_address through the entity’s registered identifiers, so a host registered by IP address matches whichever column that address lands in. See Query Syntax for the functions and Entity Analytics for how identifiers are registered.

Reserved names

We reserve any field name starting with underscore _ as an internal Secure60 fieldname. Some usage of this includes:

These are the field names every integration maps onto. The guides below show the mapping in practice:

Back to top