Integration of Cyber Threat Intelligence into Security Onion and Malcolm for the use case of industrial networks

1.1 Contribution and structure

The main contribution of this paper concerns the integration of CTI into Security Information and Event Management (SIEM) systems for the purpose of automatically configuring attack detection in industrial environments. Figure 1 illustrates the problem statement of this work. It includes multiple sources of CTI, like feeds, communities or an organization’s internally created CTI, that have to be manually integrated into the attack detection of SIEM tools. SIEM tools are represented by the two open-source implementations, Security Onion and Malcolm. Although both tools offer the automatic integration of detection rules internally, this functionality comes with several drawbacks. Rules can be fetched from public sources but cannot be filtered and it is often not transparent what rules are actually used, which can quickly result in a loss of track about the actual configuration of detection tools. Therefore, a more clear solution for the integration of all sorts of technical CTI is required. The general contribution can be broken down into two components, which are part of this paper:

1. An analysis of the current availability of open-source CTI that can be used in the context of industrial environments.

2. A model for the integration of CTI into detection systems with the purpose of enabling an automated detection process. This includes an investigation of applicable entry points for CTI in detection tools. The automated integration was implemented in the form of a proof-of-concept tool named CTIExchange. It was evaluated using both open-source SIEM tools, Security Onion and Malcolm, in a real-world manufacturing testbed.

Figure 1:

The initial situation of CTI integration into SIEM systems.

This paper is structured as follows: In Section 2, background information regarding the cyber security concepts CTI and SIEM is provided along with the Pyramid of Pain. Section 3 summarizes related work about CTI in ICS and CTI for attack detection. In Section 4, an analysis of the availability of CTI for ICS is provided. Section 5 introduces CTIExchange and its concepts for automating the configuration of attack detection tools using CTI. Finally, Section 6 describes the evaluation of CTIExchange and Section 7 concludes this paper.

2.1 Cyber Threat Intelligence (CTI)

In [5] Friedman and Bouchard defined CTI as “knowledge about adversaries and their motivations, intentions, and methods that is collected, analyzed, and disseminated in ways that help security and business staff at all levels protect the critical assets of the enterprise”. Generally, Cyber Threat Intelligence refers to the process of gathering information about cyber attacks, their context and their consequences [6]. The main objectives of using CTI include support for the detection and prevention of attacks as well as appropriate incident response [7]. CTI can be distinguished into three different categories:

Tactical CTI focuses on the short-term risks an organization faces based on vulnerabilities and threats targeting the organization. It includes tactics and tools that specific attackers use to implement attacks on their victims. On the tactical level, technical indicators in the network are collected and analyzed in order to gain an understanding of network-level threats [7].

Operational CTI is used to describe specific threats on a higher level and is focused on bringing information from the tactical level into more context. The focus here is more on adversary behavior and specific malware or campaigns than technical indicators [7].

Strategical CTI targets the security leadership level in an organization. The focus is on high-level threats and risks an organization faces [7]. Examples of strategic CTI include currently widespread threats (e.g., ransomware), industry-specific threats, or geopolitical events (e.g., the Ukraine crisis) [6].

The focus in this work is on tactical CTI, which can be distinguished into Tactics, Techniques and Procedures (TTPs) focusing on typical adversary actions and behaviors that indicate malicious presence in an environment [7]. Characteristic attack patterns are used to identify an ongoing attack or breach. On the other hand, Indicators of Compromise (IoCs) are technical patterns that can be used to detect suspicious activity or cyberattacks. IoCs are the most popular component of CTI; examples include IP addresses, file names/hashes, domain names and malware signatures [6].

To enable the full potential of CTI, the sharing and receiving of CTI data is desired, which requires defined data formats. Two common sharing formats are STIX2.x, the de facto standard [8], and the widely used MISP data format [8]. STIX2.x is a structured language used to exchange CTI information in a consistent and machine-readable format [9]. It defines multiple data types: STIX Domain Objects (SDOs) are used to describe threats in a general way, such as an indicator. STIX Cyber-observable Objects (SCOs) describe observable facts in a network or on a host that are mostly linked to an SDO. Finally, STIX Relationship Objects (SROs) can be used to define relationships between STIX Objects [9].

MISP’s data format is based on JSON objects that represent events [10]. Each event is associated with one or more attributes that can, for example, represent network or system indicators, known malicious credentials or bank account details [10]. Each attribute is associated with a category (e.g. Network activity, Payload delivery, …) to put it into a context. The data format is used for data exchange between different instances of the MISP Threat Intelligence Platform.

2.2 Pyramid of Pain

In 2013, Bianco published the “Pyramid of Pain” [11] after coming to the conclusion that indicators are not used effectively in threat reports. Figure 2 shows the pyramid that is intended to create a relationship between types of indicators and the “pain” of changing those in an attack [11]. At the bottom of the pyramid, there are atomic IoCs like file hashes, IP addresses and domain names, which are relatively easy to change from an attacker perspective. Network/host artifacts describe any sort of observables an adversary creates in a network or on a host, for example, the content of an HTTP request or a specific registry key [11]. The changing of these artifacts is much more difficult, as changes to the actual attack tool are required. By being able to detect many artifacts of an attack, it can be possible to defeat a whole attack tool, which means the attacker has to develop a new tool that implements the attack. Finally, TTPs are at the very top of the pyramid. If attacks can be detected just based on the TTPs used by an attacker, the attacker has to reinvent whole attacks, which causes the most “pain” [11]. From a CTI perspective, the “Pyramid of Pain” can be directly translated to the value of certain indicators. The more “pain” the change of an indicator creates for an attacker, the more valuable it is to own it as part of CTI data. It can thus be considered that generally detailed TTPs are much more valuable for detection than IoCs. This does not directly apply to automated detection, as automatic detection of TTPs is also significantly more challenging than detecting atomic IoCs.

Figure 2:

The Pyramid of Pain by Bianco [11].

2.3 Security Information and Event Management

A SIEM system is generally capable of collecting, aggregating, storing and correlating security-related information and events in a certain managed environment [12]. Additionally, real-time analysis and incident response are supported by most modern SIEM solutions. Usually, a SIEM is made up of multiple sub-components that perform specific tasks:

Log Management describes the collection and extraction of all types of log data and thus, events in a network and on its hosts [12]. Without proper log management, it is not possible to extract information on security-related events and SIEM functionality could thus not be implemented [12]. Additionally, mechanisms to search, filter, correlate or report log data are required for effective management [12].

Network visibility is an important element of any SIEM. It includes the gathering of logs about all network traffic, including meta data, as well as the functionality of Network-based Intrusion Detection Systems (NIDSs). In NIDSs, the data to be analyzed is captured at one or more defined spots in the network using a so-called sniffer interface to scan all network packets. The captured data is thereby analyzed either signature-based or anomaly-based.

Host visibility, also referred to as endpoint visibility, complements network visibility by gathering all logs on hosts in the network. This functionality can include Host-based Intrusion Detection Systems (HIDSs) that detect attacks on the host. A HIDS is usually software running on a host to monitor data and activities on that particular host. This data includes logs, system calls, file accesses or memory content.

There are several commercial and open-source implementations of SIEM systems available. In this paper, the two open-source implementations Security Onion^[1] and Malcolm^[2] are used, as they are installed in the used manufacturing testbed described in [13]. Both are based on the Elastic Stack to provide log management functionality. Their sub-tools for network- and host-visibility with a focus on those applicable for CTI integration are detailed in the following and depicted in Figure 3.

Figure 3:

The sub-tools of Security Onion and Malcolm.

Zeek: Zeek is an open-source tool for network traffic analysis that is frequently used as a Network Security Monitor and therefore provides network visibility. Zeek generates logs for a number of common network protocols and can be expanded with dissectors for ICS protocols.

Suricata: Suricata is a NIDS that is based on its predecessor, Snort. Although Suricata offers more features than Snort, it uses the same rule format. In general, Suricata uses signatures to detect malicious activities and can thus be classified as a signature-based NIDS.

Strelka/Yara: Yara offers a framework for malware pattern detection and defines a rule format for that purpose. Its rules are mainly based on detection strings and boolean expressions. In Malcolm, Yara rules are used for scanning files that have been extracted from network traffic. Security Onion uses Strelka for the scanning of extracted files based on the Yara rule format. Both therefore represent network visibility.

Playbook/Sigma: Playbook is a web application used by Security Onion for the purpose of detecting known indicators in log data. It thereby uses log queries that can be defined in the generic Sigma rule format. Sigma indirectly allows both network and host visibility by scanning both types of logs.

Wazuh: Wazuh is used as a HIDS in the form of endpoint agents in Security Onion and therefore represents host visibility. It forwards host logs of several types to the Security Onion manager. Additionally, Wazuh allows signature-based intrusion detection through an XML-based rule format.

Osquery Osquery is a tool to monitor and analyze OS X, Linux and Windows operating systems. It establishes a relational database model of the operating system and allows the use of SQL queries to gain visibility into the host operating system. A SQL table in Osquery can, for example, represent a running process, a kernel module or a network connection. SQL queries for Osquery can be defined in the Security Onion manager and executed by agents.

4.1 Challenges for industrial control systems

A major challenge for the usage of CTI in industrial environments is the large variety of different ICS networks originating from a large amount of industry-sector-specific (legacy) devices, protocols and architectures [18]. As the term ICS covers many sector-specific environments, these networks often have few similarities. This results in highly targeted attacks against specific environments that are not easily transferable to other ICS environments [18]. Therefore, CTI data used to detect or prevent a specific known attack is of limited value in another context. Knowledge about attacks on vulnerabilities or exploits of protocols or devices is thus critical but also much more challenging to obtain than in an IT environment. The knowledge base and thus the actual presence of IoCs for ICS environments, is very limited, as ICS or even vendor-specific protocols are not widely spread and thus not examined for possible weaknesses regularly, while the number of known attacks is low compared to IT environments [18]. Additionally, attacks frequently use valid protocol functions as part of an eventual attack [18]. Supporting the detection of attacks in industrial networks with CTI is not limited to ICS-specific CTI for stage 2 of the kill chain. It also involves attack detection in the first, more IT-related stage. Additionally, the proportion of IT systems in ICS environments is growing, which is also referred to as the “IT-fication” of ICS or IT-OT convergence. In [7] CTI is identified to be able to “bridge the IT-ICS divide”. As the amount of available CTI for this part of the environment is large and the detection of an attack in its initial phases can also be considered beneficial, the usage of CTI in industrial environments can be considered advantageous. The detection of attacks in the second phase requires much more effort and good data sources for CTI, and even then, it remains challenging. Furthermore, the inclusion of CTI contributes to the concept of defense in depth [19] by fostering proactive identification of potential threats.

4.2 Open-source

There are many sources of open-source CTI for traditional IT systems, including so-called feeds in common formats like STIX2.x or the MISP data format. A common source for TTPs is the MITRE ATT&CK framework including common attacker tactics, used techniques and concrete procedures used in an attack. With MITRE ATT&CK for ICS, Mitre offers a variant of its framework specifically for ICS, including ICS-specific attacker goals and techniques. It is provided in the form of a matrix built of attack tactics and techniques. The framework is a resource for gaining an understanding of attacker behavior and the concrete steps of an attack, but it cannot be directly used for attack detection. Instead, it should be used to bring detected IoCs into more context and enable an understanding of the stage of an attack and possible next steps of the attacker. Another common source for ICS-specific CTI are attack and vulnerability reports published by government agencies (e.g. CERT Bund), product vendors (e.g. SiemensCERT) or commercial organizations (e.g. Dragos Inc.). These reports usually contain information about discovered vulnerabilities in devices and protocols, as well as detailed breakdowns of known attacks. The focus of attack reports is on getting a general understanding of attacker behavior instead of specific, highly targeted attack steps that might not be applicable in other environments. The downside of using such reports is the manual effort required for the extraction of IoCs for attack detection. For the purpose of automating the configuration of attack detection tools, regularly updated indicator feeds are required. A thorough analysis of such open-source feeds mainly targeted at ICS yielded only one result. Automated Indicator Sharing (AIS),^[5] a sharing community platform provided by the CISA in the United States, is the only non-commercial feed that predominantly targets ICS. Although the actual AIS feed is free, registration requires the purchase of a PKI certificate from a Federal Bridge Certificate Authority and is thus limited to users in the United States. To the best of our knowledge, there are currently no open-source indicator feeds that are specific to ICS. Hence, the presence of data directly targeting ICS in available generic open-source feeds is of interest. For this purpose, an analysis of MISP’s default feeds (botvrij.eu^[6] and CIRCL OSINT^[7]), the Alienvault OTX^[8] default feed and Yara rule repositories (Florian Roth’s signature-base^[9] and Yara-rules repository^[10]) was performed. The feeds are listed in Table 2 and were chosen as they provide meta information instead of solely providing bare indicators (like i.e. an IP block list). The analysis was performed based on the following defined set of ICS-specific terms that were used to search in these feeds:

1. ICS protocols: bacnet, dnp-3, eip, ethercat, ethernet/ip, factory interface network, service, fins, fieldbus, ge-srtp, hart ip, iec-104, iec-60870-5-104, modbus, niagara fox, opc ua, pcworx, profinet, profibus, simatic, s7, tsap

2. ICS vendors: beckhoff, codesys, ge industrial solution, honeywell, mitsubishi electric, omron, red lion, rockwell, schneider, siemens, sysmac, tridium

3. ICS device types: data historian, engineering workstation, field controller, hmi, human control interface, ied, input/output server, i/o server, plc, programmable logic controller, protection relay, remote terminal unit, rtu, safety instrumented system, sis

4. ICS attack software (AS): backdoor.oldrea, bad rabbit, blackenergy, conficker, crashoverride, discoder.d, downaup, duqu, ekans, flame, hatman, havex, incontroller, industroyer, kido, killdisk, lockergoga, medre.a, notpety, pipedream, plc-blaster, revil, ryuk, skyviper, snakehouse, sodin, stuxnet, trisis, triton, vpnfilter, wannacry

5. ICS attack groups (AG): allanite, apt33, dragonfly, energetic bear, hexane, lazarous group, leafminer, oilrig, sandwork, xenotime

6. ICS general terms: ics, industrial, scada, manufacturing, critical infrastructure

The observed percentage of ICS data in the previously mentioned feeds is shown in Table 2. It is relatively low, lying between 4 and 8 % for all investigated feeds. It can thus not be considered advisable to subscribe to such feeds in case only ICS-specific data is required. Table 1 shows the distribution of the match results with regard to the previously introduced categories. It shows that the large majority of the observed ICS data originates from known attack software or attack groups as well as general ICS terms. As indicators for known attacks are of limited value due to the low likelihood of the same attack being performed in a different network, the value of these feeds is further decreased. Only nine of a total of 377 filtered rules/events matched ICS protocols, devices or vendors, which are considered much more valuable information. The only match for protocols is a false positive of the eip protocol that matched the EIP register. All in all, the availability of open-source ICS-specific data that can be used for the automatic configuration of attack detection tools is very limited and not satisfactory.

Alternatively, there are commercial feeds that specifically target ICS environments, including Dragos WorldView, Kaspersky ICS-Cert, Microsoft Defender for IoT, Nozomi Networks and Trend Micro ICS/OT Security. All feeds and repositories, as well as their relation to ICS, are summarized in Table 2.

5.1 Configuration of detection tools

In SIEM systems, usually multiple sub-tools are used for the purpose of attack detection, including NIDSs and HIDSs. For Security Onion and Malcolm, the following tools have been identified as entry points for the use of CTI:

Zeek: The Zeek Intelligence Framework is part of every standard Zeek installation. It allows the definition of atomic indicators that are then matched on live traffic logs. As the intelligence framework is limited to atomic indicators, its detection capabilities are limited to the lower parts of the “Pyramid of Pain”.

Suricata: Suricata/Snort rules can be generated based on CTI indicators or fetched from various rule repositories. There are several open rule repositories that contain some rules for SCADA systems. Suricata rules allow the representation of complex network events, like, for example, whole HTTP requests. A Suricata rule thus has the potential to map whole network artifacts in the “Pyramid of Pain”.

Yara: Many Yara rules for the scanning of files are openly available and rules for the detection of common ICS malware exist. Yara rules can include complex representations of all sorts of files and are even capable of detecting variations of files. According to Bianco, Yara rules are thus part of the tool level in the “Pyramid of Pain” and have the potential to cause significant “pain” for attackers [11].

Sigma: Sigma rules allow the definition of complex queries and can thus detect complex indicators in log data. Open Sigma rule repositories exist, but rules intended for ICS are rare. A Sigma rule can potentially detect complex network- and host-artifacts or whole attack tools and is thus an indicator source located at the top parts of the “Pyramid of Pain”.

Wazuh: Wazuh’s XML-based rules can be defined to detect patterns in gathered host logs and can be based on IoCs. Although they are thus located relatively high in the “Pyramid of Pain”, the absence of publicly available rules, except for those directly provided by the Wazuh developers, is a major problem for the usage of such rules in the context of CTI.

Openly available rules exist for all of the identified tools and rules can additionally be created by converting IoCs in generic CTI formats to the specific rule formats.

5.2 Threat Intelligence Platforms

A requirement for the automated configuration of all tools using CTI is the automated fetching of CTI data from, potentially, multiple sources. For this purpose, Threat Intelligence Platforms (TIPs) can be used. The functionality of TIPs commonly includes the gathering, storing, visualization and sharing of CTI data. There are multiple implementations of TIPs, including both commercial and open-source projects. For the use case of transporting CTI data for the purpose of configuring detection tools, the main required features of a TIP are: data export functionality; automation of CTI gathering; integrability with other security tools; event streaming for notifications about new CTI data; API access to retrieve data and visualization and sharing functionality. Based on the evaluation of TIPs by de Melo e Silvain et al. in [20] the two open-source TIPs that best meet these requirements are MISP and OpenCTI. Both are still actively developed and belong to the most popular and case-applicable TIPs [20]. MISP originally started under the name CyDefSig in 2011 and was later renamed after being adopted by NATO. The main goal of MISP is to provide a platform to share knowledge about threats and IoCs in both public and private environments. In the ICS domain in Germany, MISP is used in the form of a closed community called Cyber Security Sharing & Analytics (CSSA). OpenCTI is an open-source TIP with the objective of enabling the storing, organizing and visualizing of all sorts of knowledge about cyberthreats and incidents. It was originally released in 2019 and is based on the STIX2.x data format specification.

5.3 CTIExchange design

CTIExchange provides a publish-subscribe channel for the purpose of connecting sources of CTI with tools for attack detection. As sources of CTI, both TIPs, MISP and OpenCTI are used as publishers, while the subscriber side is represented by Security Onion and Malcolm, more specifically by the identified sub-tools for the usage of CTI. Figure 5 shows the resulting architecture of CTIExchange.

Figure 5:

Architecture for CTIExchange.

Figure 6 details the publish-subscribe workflows in CTIExchange. Generally, indicators gathered in MISP or OpenCTI are published on CTIExchange in the form of STIX2.x indicator objects, associated with a topic indicating what kind of tool-specific rule is included. A Suricata rule would, for example, be published as a STIX2.x indicator with pattern type suricata associated with the topic suricata/indicator. Relevant rules can then be filtered by topic on the subscriber side. On the other hand, the sighting of a previously received indicator can be published as a STIX2.x sighting object associated with STIX2.x Cyber-observable objects and the topic stix2/sighting. This way, a subscribing TIP can collect sightings and provide an overview of the most relevant indicators. CTIExchange provides a publish-subscribe channel similar to Threat Bus, but there are conceptual differences between the two:

Figure 6:

CTIExchange publish-subscribe workflows.

Topics: In Threat Bus, all indicators are published with the topic stix2/indicator. As the main targets for CTIExchange’s subscriber side are detection tools, topics directly represent the tools’ specific rule types. Additionally, TIPs like MISP already provide conversion functionality for certain rule formats so that these rules can be published directly.

Sightings: In Threat Bus, sightings are reported in the form of STIX2.x Sighting objects. With Cyber-observable objects, STIX2.x provides a mechanism to provide more concrete information about a sighting (i.e., a log entry or packet capture that caused the rule to match). These SCOs can be included to a sighting with CTIExchange in the form of a custom observable.

Complexity: As CTIExchange is designed for (but not limited to) ICS, its complexity and setup effort were desired to be low. Compared to Threat Bus, there is no registration functionality, as CTIExchange is expected to run in a closed environment. Additionally, there is only basic messaging functionality, so there are no backbone plugins.

5.4 CTIExchange implementation

CTIExchange was implemented as a proof-of-concept in Python and provides a publish-subscribe channel as well as plugins for MISP, OpenCTI and the two SIEM tools, Security Onion and Malcolm. A main goal of CTIExchange is to be easily extensible through the integration of other security tools or CTI sources. Therefore, plugin implementations are only required to request available topics and can subsequently publish messages using these topics. In the following the implementation of the publish-subscribe messaging as well as all plugins are introduced:

Messaging: To implement CTIExchange, a basic implementation of the publish-subscribe pattern is required where different publish topics can be defined and subscribed to. The asynchronous exchange of CTI data requires no acknowledgments by subscribers, but messages should be queued for processing at the subscriber side. A connecting service should also be able to be both a publisher and a subscriber, as for example a TIP can publish CTI indicators and possibly subscribe for sightings of these indicators. Additional requirements for the message channel include scalability, low implementation complexity and a low setup effort in order to allow a simple integration into existing industrial networks. Three Python libraries for the implementation for the implementation of a publish subscribe channel were taken into consideration:

1. ZeroMQ:^[11] ZeroMQ is an open-source asynchronous messaging library with the goal of enabling message exchange between different applications. In ZeroMQ’s publish-subscribe model, a publisher can publish messages at a specified socket along with a topic to allow subscribers content-based filtering of messages. ZeroMQ can be deployed without a central broker instance.

2. RabbitMQ:^[12] RabbitMQ is an open-source message broker that enables different types of messaging including the publish-subscribe model. For messaging, three components are defined by RabbitMQ: a producer that sends messages, a queue that buffers messages and a consumer that receives messages. To make use of all the provided features, a RabbitMQ server that acts as a message broker has to be installed and configured.

3. Apache Kafka:^[13] Apache Kafka is an event streaming platform that combines three key capabilities: the publication and subscription to event streams, along with the storing and processing of such event streams. The use of Kafka requires the installation of a Kafka server that acts as a central broker.

Generally, all three options provide the features needed to implement the message exchange for CTIExchange. Additionally, all systems provide the necessary scalability to be used for CTIExchange: In [21], it was shown that both ZeroMQ and RabbitMQ have high performance and can process thousands of messages per second, which exceeds the needs for the exchange of CTI data. Kafka is highly scalable as it also allows a distributed deployment with multiple brokers. The biggest differences show in the setup effort required to start the message exchange. With ZeroMQ, it is possible to run in a mode without a central broker instance, thus there is no setup required. Both RabbitMQ and Kafka require the installation and maintenance of servers that act as brokers and in the case of Kafka, require complex configurations. Furthermore, additional features that Kafka offers, like persistent storing of messages, are not required as all CTI data is expected to be stored in Threat Intelligence Platforms. Due to ZeroMQ being the simplest and easiest to setup solution that provides all required features, it was chosen for the proof-of-concept implementation of CTIExchange.

MISP connector: The MISP connector currently is the main CTIExchange plugin as it provides the most features. The connector itself is also designed in a plugin-based way, so that formats in which data originating from MISP is exported, can be integrated seamlessly. In the context of the MISP connector, these plugins are called MISP export plugins. A plugin can thereby be based on the conversion of sole MISP attributes or complete events, which is indicated by its observer type. The MISP platform uses ZeroMQ to stream the creation of events and attributes inside a MISP instance. In the case that an event or attribute is created, it is handed over to each MISP export plugin and either directly published to the CTIExchange channel or converted into the respective plugin rule format. MISP directly supports export in both the Suricata and Yara rule format. These rules can therefore be published directly and the respective export plugins are thus straightforward. While MISP is also able to export data in the text-based Zeek Intelligence format, this functionality is not accessible via the REST client. Zeek rules are thus created by an own converter as part of the Zeek export plugin. The conversion is based on a mapping from MISP attribute types to Zeek’s intelligence format. There is a mapping to each Zeek intelligence type but some MISP attributes, like ip-src and ip-dst lose accuracy as Zeek does not distinguish source and destination IP addresses. For Sigma rules, MISP does not provide any conversion or export functionality. Sigma rules are also created by an own converter as part of the Sigma export plugin that maps MISP events and attributes to the Sigma rule format. As Sigma rules are more complex, the mapping of whole MISP events to Sigma rules is partly possible. Therefore, all attributes of an event that concern the network are gathered and converted to a network-based Sigma rule. Similarly, all host attributes are gathered for a host-based Sigma rule. A mapping of MISP attributes and MISP objects to Sigma log fields was created based on the Security Onion Sigma field mapping. Although there are many possible mappings, several log fields and MISP attributes could not be mapped reasonably. The conversion to the Sigma language is thus limited and it is recommended to directly import/use Sigma rules instead of creating them by conversion. The addition of Wazuh is currently only possible by directly adding a MISP attribute of type text, including the actual rule.

The complete workflow of the MISP connector is as follows: Initially, all available topics and thus rule formats are requested from CTIExchange. Afterwards, existing CTI data is requested from the specified MISP instance. This data is then converted into different rule formats by existing export plugins. Currently, export plugin implementations for Suricata, Yara, Zeek and Sigma exist. Finally, the MISP connector subscribes to updates from the MISP instance in order to forward these to CTIExchange. Received messages are queued until there are no further messages for 5 s. Subsequently all queued rules are handed over to the implemented export plugins to generate all desired rules. Each rule is then published along with its respective topic. This overall workflow can be used as a basis for other CTIExchange plugins.

OpenCTI connector: The OpenCTI connector is much more lightweight than MISP’s. As OpenCTI is based on the STIX2.x data format, direct forwarding of some indicators is possible. Therefore, no conversion functionality is provided but instead STIX2.x indicators with pattern types Snort, Suricata, Sigma and Yara are directly forwarded to CTIExchange. The connector is implemented based on OpenCTI’s plugin template as a connector of type Stream. It thereby uses OpenCTI’s live streaming functionality to be notified of new or updated indicators. The connector can be run manually or as part of an OpenCTI docker compose setup.

SIEM plugin: The connection of Security Onion and Malcolm to CTIExchange is realized with a single SIEM plugin. The plugin is configured with the location of rule files/directories for all supported rule formats. To avoid an overload on the subscriber side, received messages are queued and added through a background job. Some of the integrated rules have to be enabled manually or require a restart of the respective tools. In Security Onion, added rules for Suricata, Zeek, Yara and Wazuh are automatically integrated into detection processes within 15 min using Salt. Sigma rules for Playbook have to be activated manually through the web interface. For Malcolm, a restart of the services is required for all integrated rules to be activated.

6.1 Testing

For testing purposes, exemplary rules in the introduced formats Suricata, Zeek, Sigma and Yara have been added to MISP and OpenCTI and were then transferred to Security Onion and Malcolm using CTIExchange. Rules were either directly provided or converted from regular MISP attribute types. The following test cases were executed:

1. Test case 01 – MISP IP-addresses: For this test case, the MISP attribute types ip-src, ip-dst, ip-src/port, ip-dst/port were used. They result in rules for Zeek, Suricata, Yara and Sigma. Yara rules are ignored for this test case, as they can only be used to find the IP address as part of a file’s content. All other rules generate alerts, while Zeek is not able to distinguish between source and destination IP. With the generated Sigma rules, duplicate alerts are created as they are used to query all existing logs. These logs include the actual traffic that contains the IP addresses but also the alert logs generated by Suricata and Zeek. The Sigma rule thus also matches on previously generated alerts for the same IP addresses. It is therefore considered reasonable to only use Zeek or Suricata rules for simple IP address detections.

2. Test case 02 MISP Domains: MISP’s attribute types domain and domain/ip result in rules for Zeek, Suricata, Sigma and Yara, where a Yara rule scans for the domain in extracted files. The other rules match DNS traffic, but Zeek cannot match the combination of a domain name and an IP. It can therefore result in false positive matches in the case that only the actual combination is considered malicious.

3. Test case 03 – MISP Files in network: To detect files sent over the network file names, hashes and file contents can be used. Therefore, MISP attribute types filename, pattern-in-file, sha1 and md5 are converted to Zeek and Yara rules. Zeek is able to detect both file names and hashes in HTTP traffic. The detection of file contents in files sent over HTTP is enabled by Yara rules generated by MISP’s export functionality. The detection with both rule types was successful.

4. Test case 04 – MISP Zeek rule: For this test case, a MISP attribute of type zeek was added. As the attribute is already provided in the Zeek rule format, there is no conversion involved. It includes an SSH public key as Zeek INTEL::PUBKEY indicator. A match is generated on all subsequent SSH connections involving the provided key.

5. Test case 05 MISP/OpenCTI – Suricata/Snort rule: This test case involved MISP’s attribute types suricata and snort as well as STIX indicators with pattern types suricata and snort in OpenCTI. An exemplary rule was used to detect HTTP payload delivery and file extraction. HTTP Post requests to download a fictive payload or to extract files from a target machine were successfully detected by these rules.

6. Test case 06 MISP/OpenCTI – Sigma rule: Sigma rules can be directly added as MISP attributes with type sigma or as STIX indicators with pattern type sigma in OpenCTI. The used Sigma rule was used to detect the same HTTP traffic as the Suricata rule in test case 05.

7. Test case 07 MISP/OpenCTI – Yara rule: Yara rules can be added through MISP and OpenCTI similar to Sigma and Suricata rules. The added rule was used to detect Caldera payloads by file content.

In order to test the scalability of CTIExchange, MISP’s two largest feeds, CIRCL OSINT and botvrij.eu, were used. The results are shown in Table 3. The fetching of these feeds resulted in 521,535 and 34,842 rules, respectively. For the CIRCL OSINT feed, the sending of all rules took around 180 s, while the addition of Suricata, Zeek and Yara rules on the SIEM side took around 62 s. For the botvrij feed, the sending was finished after around 31 s, and all Suricata, Zeek and Yara rules were inserted after another 61 s. The rule insertion time is thereby mostly made up of a 60 s delay to wait for further messages. Only the addition of Sigma rules into Security Onion’s Playbook application took much longer, at around 56 min and around 13 min, respectively, due to the slow insertion functionality through the so-playbook-import command of Security Onion.

6.2 Attack emulation with Caldera

Caldera [22] is an open-source attack emulation tool by Mitre that is based on the MITRE ATT&CK framework. A Caldera server thereby acts as a command-and-control server that controls agents on “infected” hosts. To test CTIExchange, the following attack techniques were performed and rules were created based on observable log data in order to detect the specific attack technique:

T0846/T1046 – Remote System Discovery: ICS Port Scan: An ICS port scan was performed using nmap to scan common ICS protocol ports. It is a common early step in stage one of the ICS kill chain to find an entry point into the “ICS world” or to identify specific target devices. Initially, the scan was not detected. After inserting a Sigma rule by SOCPrime^[14] through CTIExchange, the scan was detected regularly. Remote system discovery is part of many known ICS attacks, including Industroyer, INCONTROLLER, Trition and PLC-Blaster,^[15] where target machines were identified using similar techniques.

T1548.002 – Bypass User Account Control: With this attack technique, Windows User Account Control was disabled using the registry. The detection of such registry changes was possible using either a Sigma or a Wazuh rule. Registry changes are also used by ICS attack groups like Dragonfly. An example of an ICS attack group using registry changes during an attack is Dragonfly. They reached the goal of persistence by adding the registry value ntdll to the Registry Run key.^[16]

T1027 – Execution from compressed file: Adversaries try to make the detection of executables used in the course of an attack difficult. The obfuscation of file execution is a common attacker goal to hide attack payload on a target host or in a target network. In Caldera, execution from a compressed file is emulated by executing an executable payload in a ZIP folder using Windows PowerShell. The detection of this execution was enabled using either a Sigma or a Wazuh rule, based on the presence of the “.zip” file ending in an executed process. The obfuscation of payload files is a common technique that can also be used in the “Delivery” and “Install/Modify” phases of the first stage of an ICS attack.

T1048.003 – Exfiltration over alternative protocol – ICMP: After successfully gaining access to a network, attackers frequently steal data from that network. Data can thereby be exfiltrated using common unencrypted protocols like ICMP in order to avoid detection. The size of ICMP packets that carry data for exfiltration is unusually large, though. This allows the detection of such packets using a Suricata rule. The detection of data exfiltration can also be considered relevant for ICS. The APT33 threat group that mainly targets industrial facilities, for example, used FTP for a similar unencrypted file exfiltration channel.^[17]

By emulating real-world attack tactics and techniques with the help of Caldera, it was shown that the integration of IoCs into detection tools can result in the detection of attacks that could previously remain undetected. This shows the value and the practical applicability of CTI-supported detection processes and, thus, of CTIExchange. Although the emulated attack scenarios mainly target IT systems, they are still relevant for ICS environments, more specifically for the first stage of ICS attacks.

6.3 Results

CTIExchange underwent a comprehensive evaluation encompassing two distinct phases, both of which yielded positive outcomes: (1) The first phase involved conducting functional testing to ensure the accurate forwarding and integration of rules into detection tools. While the overall test results were successful, the evaluation highlighted new challenges. Specifically, in the initial two test cases, it was observed that Zeek was incapable of matching domain names with IP addresses. Furthermore, Test Case 01 revealed difficulties in differentiating between source and destination IP addresses. Additionally, the utilization of Sigma rules generated duplicated alerts, as Sigma triggered alarms based on logs that already represented alarms from Suricata and Zeek. This discovery raises the question of whether integrating tactical CTI into all detection tools is the right approach. Further evaluation and consideration are required in this regard. Additionally, CTIExchange was tested to handle the integration of whole threat feeds with up to half a million messages. (2) The second part of the evaluation involved the emulation of real-world attack techniques, utilizing the open-source tool Caldera. CTIExchange demonstrated its capability to effectively handle and respond to these attack scenarios.

7.1 Future work

The risk for cyber attacks against industrial networks is considered high, which means expanding security capabilities in this area is important. As CTI can benefit automated attack detection processes, it is also valuable to integrate intelligence into ICS detection processes. In the absence of ICS-specific open-source CTI, the sharing of such information between organizations in the ICS field can be considered an option. The establishment of open sharing communities is an option to improve ICS-specific CTI sharing. The usage of CTIExchange as an endpoint for received CTI data in such a scenario could be of interest. Regarding CTIExchange, its functionality can be extended by integrating more detection tools or commercial SIEM solutions. Finally, the potential scenarios for the usage of CTI are not limited to the integration of technical indicators into automated detection processes. The use of CTI for risk management in industrial environments could be another possible research direction.