CSAF format description

There are no mandatory fields, properties in CSAF format. However, basic device identification is expected (ip, hostname) and time and name of an alert at minimum.

The below table tries to represent exhaustive example of the CSAF alert. In first column you can see name of each field/property. In second column there are alternative names of fields/properties from column 1. This might be helpful to identify respective fields that should be mapped to the schema because every vendor and security device is using different naming convention and taxonomy. Other columns represent short description with type of a property and possible example. This example is not intended to be exhaustive nor minimal.

The shading of the cells are based on "object" presence. First object (Device )is without shading, second object (priority) is grayed out and so on. Don't be confused, some objects are nested like artifacts within alert and associated events. 

Name	Alternative name	Description	Examples
Device	origin, producer	Object – all properties related to device identification. There are no mandatory fields, however device name and IP is highly recommended to be present all the time. There might be more fields describing the device or the element responsible for generating the alert.	"Device": {      "vendor": "Cisco",      "product": "ASA",      "version": "5525-X",      "OS": "IOS 14",      "module": "Firepower",      "feature": "WEB protection",      "device_name": "badassfw",      "device_IP": "10.20.255.1",      "policy": "block_porn",      "rule": "24",      "action": "blocked",},
vendor	manufacturer, producer	device vendor identification	"vendor": "Cisco",
product	model, type	product identification	"product": "ASA"
version		version of a product if applicable	"version": "5525-X"
OS	operating_system	details about operating system, could be with version number	"OS": "IOS 14"
module	blade	if multiple modules are present within one device	"module": "Firepower"
feature	function	if multiple features are present it could be distinguished by this property	"feature": "WEB protection"
device_name	hostname	name of the device, usually hostname or DNS record	"device_name": "badassfw"
device_ip	device_address	local ip address of the device, if multiple ip addresses are assigned, primary IP or IP that is registered in DNS should be assigned	"device_IP": "10.20.255.1"
policy	group	policy, group or sometimes rule that triggered alert	"policy": "block_porn",
rule	use_case, monitoring_scenario	in more complex scenarios one policy can have multiple rules	"rule": "24"
action	output	the rule or policy action (blocked, allowed, alerted…)	"action": "blocked"
Priority	severity, criticality, magnitude	Object – usualy it will be only one property. In this case it can be a simple string and not an object. All variables that can help to describe the priority/severity of an alert.	"Priority": {"severity": "High", "credibility": "Med", "relevance": "10"} -   or simplified - "Priority": "Low" -   or alternative - "Magnitude": 5
severity		Could be numerical or text value	"severity": "High"
credibility		Could be numerical or text value	"credibility": "Med"
relevance		Could be numerical or text value	"relevance": "10"
…..	confidentiality, availability, integrity	Other fields describing the overall criticality/priority/severity of an alert	"Priority": {"confidentiality": "5", "availability": "10", "integrity": "1"}
Alert	Offense, Incident	Object
time	date	time or date and time it is recommended to use UTC standard and format defined in RFC5424 for example 2003-10-11T22:14:15.003Z	"time": "2019/06/05 13:02:14.171",
category	type	array; often, event can be part of multiple categories or high-level and low-level category is assigned to one event	"category": ["WEB","Traffic blocked","web access blocked"],
name	description	name of the generated alert	"name": "Porn site access",
id	alert_id, alert_nr	this field could be either string or number. It refers to alert id from originating device	"id": "a5dc612a03-b84daef88"
link	url, reference	link or reference to the originating device, where alert could be seen and investigated	"link": "http://10.20.255.1/alerts?id=100237"
domain	tenant, customer	in case of multi-tenant or multi-domain setup distinction of customer/tenant	"domain": "Tenant1",
region	country, location	region, country location of the attacker or attacked object, if applicable	"region": "CZ",
target	attacked_object, victim, destination	array; this could be list of most important artifacts or specification of target/attacked object	"target": ["freevideo.cz","adm_user","10.101.24.23"]
artifacts	attributes	List of all artifacts/attributes associated with alert. Values from the target field could be repeated.	"artifacts": {       "username": "adm_user",       "src_IP": "10.101.24.23",       "src_port": "50435",       "dst_IP": "80.188.244.72",       "dst_port": "443",       "domain": "freevideo.cz",       "url": "https://freevideo.cz/big_gang_bang_theory",     },
username	user	if applicable user performing the activities that led to generation of the alert	"username": "adm_user",
src_IP	src, source_IP, sIP, IPv4, IPv6	network identifier, it could be IPv4 or IPv6 or both	"src_IP": "10.101.24.23",
…..		list of other artifacts, no limitations there, but it should be reasonable amount or within transferring protocol limits
status	outcome	status of an alert from the device. In most cases it will be active and there is no need to include this in the list, but it can provide more detailed information like blocking, quarantined, inspecting, evaluating etc.	"status": "active",
tactics	domains, categories	array; Expected Mitre ATT&CK mapping, but could include any framework (NIST, killchain..) mapping	"tactics": ["defense evasion","execution"],
techniques	activities	Usually Mitre ATT&CK mapping, but could include any framework mapping that the originating device is able to provide	"techniques": "Web service"
rawData	raw, details	original form of the data, alert. Worst case scenario, all the details be stated in this field only.	"rawData": "null",
associated_events	contributing_events	Array of objects; when multiple events belongs to an alert (multiple login failed can generate)
time	date	time or date and time it is recommended to use UTC standard and format defined in RFC5424 for example 2003-10-11T22:14:15.003Z	"time": "2019/06/05 13:02:14.171",
name	description	name of the associated event	name":"blocked web traffic",
target	attacked_object, victim, destination	destination, attacked object or victim of the associated event	"target": "freevideo.cz "
artifacts	attributes	Object - List of all artifacts/attributes associated with event	"artifacts": {    "username": "adm_user",    "src_IP": "10.101.24.23",    "src_port": "50435",   "dst_IP": "80.188.244.72",    "dst_port": "443",    "domain": "freevideo.cz",    "url": "https://freevideo.cz/", },
sender		In case of email related alerts, sender is expected	"sender": "vocas@dlouhy.cz"
…..		list of other artifacts, no limitations there, but it should be reasonable amount or within transferring protocol limits
count	number_of_events, number_of_elements, aggregation	number of associated events, useful in case where multiple events with same properties must appear to generate an alert (multiple authentication failures, large number of fw denies)	"count": 1,
rawData	raw, original_data	original form of the data related to associate event.	"rawData": "empty"