In the realm of cybersecurity, there is also a 'Suri,' which is the abbreviation for Suricata.
Suricata stands as an open-source, next-generation Intrusion Detection System/Intrusion Prevention System (IDS/IPS) engine developed by the Open Information Security Foundation (OISF) https://oisf.net/ a consortium of industry organizations funded by the US Department of Homeland Security (DHS).
Typically, IDS/IPS engines inspect traffic entering and exiting networks at various network boundaries and chokepoints, whether they are external or internal. The functionality of IDS/IPS is often integrated into most Next-Generation Firewalls (NGFWs).
Analyzing a Suricata Signature
Let's examine an example signature to understand how Suricata constructs its signatures. This signature comprises three primary sections:
Action
Header
Options
The Suricata 'Actions' are:
pass
drop
reject
rejectsrc
rejectdst
rejectboth
alert
The 'Header' section of the signature specifies how the signature inspection applies to network traffic. It allows the rule to be applied to different network constructs such as source protocols, IP addresses, and ports, as well as destination IP addresses and ports. It also takes into account the direction of the traffic, denoted by the 'Directionality Markers' (-> and <->). You can find more information about Suricata rule directionality here: https://docs.suricata.io/en/suricata-6.0.4/rules/intro.html#direction
Additionally, this section allows for the representation of IP address ranges through variables like $HOME_NET and $HTTP_SERVERS. This feature is particularly valuable for safeguarding internal systems. Given that IDS/IPS systems often generate false positives, these variables help organizations fine-tune their alerts by considering which system is communicating with which, in addition to the rule signature itself, rather than relying solely on the signature.
The 'Options' section is enclosed in parentheses, with each option separated by a semi-colon. The first 'Options' field we'll discuss is the 'msg' field, which provides human-readable text for the signature alert.
The 'flow' keyword enables rule/alert matching based on several factors:
The direction of the flow (e.g., to/from client or to/from server).
Whether the flow is established or not.
Specifying a match on a stream (only_stream) only or a packet only (no_stream).
Some protocols may have additional content modifiers. In this example, the HTTP content modifier 'http.request_line' is specified. These content modifiers offer protocol-specific capabilities at the application layer. In the case of 'http.request_line,' it requires the inspection of the entire HTTP request line.
Next is the 'content' section, which specifies the values the system scans for within the full stream or packet. In this example, 'Apache APISIX' is a dynamic, real-time, high-performance API Gateway designed for creating Cloud-Native Microservices API gateways. The listed API key is the default API-Key value.
Two other important Suricata rule values are 'nocase,' which determines whether case sensitivity is applied to the string lookup, and 'fast_pattern.' This latter feature prioritizes content matches with the highest 'priority' when used in the signature.
Another field occasionally present in signatures is the 'target' option, with 'src_ip' and 'dest_ip,' which assists in accurately identifying the source and target IP addresses in Suricata logs.
The signature includes additional metadata, and one of the most crucial metadata fields is the 'reference' field. This field offers users or systems working with the signature more information related to it.
'Classtype' provides information about the classification of the rule/alert.
The 'Signature ID' (sid) is a unique value that identifies the signature rule.
Additional valuable information in the rule includes:
'deployment <value>' - This indicates the recommended location to apply the rule to traffic. In this example, it is specified as 'network Perimeter.'
'performance_impact <value>' - This provides an estimate of the system performance impact caused by the rule."
Example ICS Signature
NSA/CISA has recently unveiled a project called EliteWolf, a repository that houses a collection of signatures tailored for industrial control systems (ICS), OT, and SCADA. The primary aim of this initiative is to assist Critical Infrastructure Defenders, Intrusion Analysts, and other stakeholders in enhancing their ICS, OT, and SCADA system monitoring. You can access the project here: https://github.com/nsacyber/ELITEWOLF
The initial project rules were authored as Snort signatures, but many have been converted over to Suricata rules. Below is an example of a signature that pertains to potential suspicious activities on Allen Bradley (Rockwell Collins) systems. This example underscores the importance of accurately identifying systems that routinely communicate with ICS/OT/SCADA systems, implementing network segmentation, and ensuring adequate traffic visibility. This is crucial as systems can often generate alerts for regular traffic to and from servers.
Commenti