Keywords

1 Introduction

In a time marked by continuous technological advancement, the introduction of automated minibuses has revolutionized urban transportation. These vehicles rely on a sophisticated interplay of systems, sensors, and data streams to navigate and assist passengers. However, this technological breakthrough also brings forth a pressing concern: cybersecurity. The safety and security of both passengers and the broader transportation environment demand our utmost attention. Within this chapter, a security analysis is presented regarding the pivotal role that security information and event management (SIEM) solution plays in fortifying the defences of automated minibuses. SIEM solutions are suitable for real-time monitoring and response, gathering and analysing data from a multitude of sources within the vehicles’ network. They provide a robust shield against threats such as data breaches, hacking attempts, and system vulnerabilities. Within the upcoming sections, an attempt is made to describe the indispensable necessity for SIEM in safeguarding an automated ecosystem which includes, among other, automated minibuses, enhancing their safety, and upholding the integrity of a continually evolving transportation domain.

2 Basics of a SIEM Software Solution

SIEM is a combination of two different security software: SIM and SEM. In 2005, Armit Williams described the SIEM term and presented the information gathered from network and security devices, the identity, and access management applications, from tools considering the vulnerability and policy of the monitored system, the operating system, the database, application logs, and, lastly, the external threat data (Williams & Nicolett, 2005). The mixture of the above assists the security administrators to utilize every possible source of information to detect and repel cyberattacks to their system. The importance of IT security grows exponentially every year, while the attacks and attackers are getting more sophisticated and less detectable. For this reason, security administrators should gather and analyse every possible source of information from each component of their system, as illustrated in Fig. 7.1.

Fig. 7.1
A chart presents the activities and resources. Security information and event management enhances security, optimizes network operations, and simplifies compliance. Log management secures information from networks, apps, databases, and storage.

Main activities and resources for SIEM

3 Most Popular SIEM Open-Source Software

Open-source SIEM are software which have made available to the public their cybersecurity infrastructure and the architecture of their components. This allows the IT experts to adjust the available software to their needs and remove or lessen any limitations. This list takes into consideration the most popular implementations and by no means has a promoting or advertising nature. The candidates can be different depending on search criteria and occasionally are subject to the subjective point of view of each researcher. An overview of the most popular SIEM is presented in Table 7.1 and described next.

Table 7.1 Different popular open source SIEM software solutions

Snort is a popular network intrusion detection system (NIDS), which scans all traffic to mainly sniff, log, and perform real-time analysis on the network flows. There is a visualization of the real-time stream of packets and dump packets with the option to perform analysis (Roesch, 2011).

MozDef is an open-source SIEM created by Mozilla with the main objective to automate the security incident handling process and facilitate the real-time activities of incident handlers. It uses Elasticsearch (Gormley & Tong, 2015) for storing data and runs as a cluster, making it scalable and redundant.

Wazuh is a platform used for all three main objectives in cybersecurity, threat prevention, detection, and response. It includes endpoint security agents, deployed to the monitored systems and data visualization of the gathered information (Wazuh, 2023a).

ELK Stack fulfils the need for log management and analytics. Mainly the ELK stack is a combination of three different open-source products: Elasticsearch (Gormley & Tong, 2015), Logstash (Logstash, 2023), and Kibana (Kibana, 2023). These different components are most used for monitoring, troubleshooting, and securing IT environments (Elastic, 2023).

AlienVault OSSIM is also an open-source software which combines log storing functions and correlation capabilities. A basic attribute of OSSIM is the utilization of different other open-source projects to create a holistic SIEM solution (AlienVault, 2017).

OSSEC is a scalable, multi-platform, open-source host-based intrusion detection system (IDS) (OSSEC Project Team, 2019). It is commonly used for log analysis, monitoring, and analysing firewalls, intrusion detection systems, web, servers, and authentication logs.

Security Onion uses a spectrum of open-source software with the main objective to ensure the proper intrusion detection, monitoring, and log management of the targeted system. The areas that Security Onion excels in are packet capture (PCAP) forensics, analyst virtual machine (VM), and as an external SIEM (S.O. Solutions, 2023).

Malware Information Sharing Program (MISP) collects, stores, and distributes security indicators and discovered threats. MISP is commonly used for fraud detection, information gathering, or threat hunting. Target users for this tool are security professionals (MISP, 2023).

4 SIEM Benefits for CAV Infrastructure

Not all the SIEM are created with the same design. As a result, there is not one that fits all needs. The main benefits of an average SIEM system can be sum up to log data management, compliance reporting, and threat intelligence.

Log collection not only enables real-time tracking of changes within the ecosystem but also allows for detailed monitoring of individual machines that may be compromised by attackers. This capability provides crucial insights into both the events that occurred and the subsequent analysis necessary to uncover vital evidence, such as the root cause of the exploitation. Normalization is an equally important tool for a security administrator which identifies and gathers complete information of the ecosystems’ security status. The extraction of the essential data from the noise of the system is a major attribute of the SIEM. These data can be cross checked with known databases for malicious signatures, potential malware, and machine learning algorithms to identify patterns and propagation trends and map unknown categories. Notification and alerts are an inseparable part of the security concept, since without it the resource cost of the permanent SIEM supervision would outweigh its benefits.

The efficiency in incident response lies within the proper configuration and maintenance of the SIEM software. If this challenge is accurately addressed, then the incident handling activities will result in numerous benefits to the security administrators, such as saving resources and time. All the required information is going through one single interface making it easier to be examined and further analysed. In addition, some SIEM software also has the ability to manually include user and entity behavioural analytic, to potentially detect threats from both people and software before they cause any disturbance. Moreover, the intelligence produced from the analysis can be distributed to other platforms, which is a very useful characteristic considering CAV infrastructure. This can be easier to appreciate with the use of an example. Let’s say that a CAV fleet has been targeted in a country from a group of attackers, with a zero-day attack. Regardless of the result from this kind of malicious action, all the gathered information and mechanisms will be distributed to the other cities which are also hosting CAVs’ fleet. Automatically, the possibility of causing the same crisis with some similar kind of attack is close to zero.

Security incident detection is just the tip of the security iceberg. It generally identifies activities such as unauthorized access and use of the system, changes to system’s firmware, and any other malicious actions. Threat response flow, which can be set and defined by the security administrators, is the key to properly deflect and minimize the hazard caused by an attack. A common observation is that companies, Internet of Things ecosystems, or even infrastructures like CAVs are better equipped with SIEM software than without it. Incident handling with the use of that kind of software is exponentially faster and with less human resources than having to examine all the logs to find the attacker’s footsteps. The SIEM identifies and correlates those events, from a bird’s eye view, while ensuring the efficiency of malicious tracking actions.

5 Limitations of SIEM

SIEM is a software solution that aggregates and analyses the activity of many different resources across the infrastructure under investigation. The automation of those activities conceals some complexities. One of them is the extensive configuration which must be done to the software to be tailored to the system’s needs. Misconfiguration can cause several problems, depending how major is the accident. Nevertheless, this applies to a lot of software, and it is easily answered by having experienced staff executing such tasks. The above limitation leads to another disadvantage of the SIEM software. The perfect setting up of this kind of software is costly and time-consuming, something which will be reversed in the long run. However, when the first installation takes place, and for a short period after it, the need for time and modifications will be immense. A key part of the SIEM software is the definition and creation of rules, whereas the lack of accurate configuration is possible to lead to false positives. For that reason, constant monitoring and examining of those rules are needed from the security administrators to have an excellent result. The combination of the above reveals the need to have trained and around-the-clock staff for a smooth cybersecurity operation. The information which will be stored through the log management is usually enormous, and since it is about ecosystems such as CAVs, it will need sufficient staff who will not get distracted by the noise captured from the software.

6 Characteristics of the SIEM Platform

SIEM aggregates and analyses the activity of many different resources across our infrastructure (Kotenko & Chechulin, 2012). Security data are collected, and the software stores, normalizes, aggregates, and apply analytics to that data to discover trends, detect threats, and investigate alerts as it is shown in Fig. 7.2. This system could perform the analysis on the platform but also on the CAN bus. For instance, MISP is a sharing platform which stores and distributes security indicators and discovered threats (Wagner et al., 2016). This platform is useful for those involved with security incidents and malware research. The users benefit from having a well-tested platform to structure the vast number of data points available when it comes to security threats. The tooling allows interaction with other software, like IDS. MISP is commonly used for fraud detection, information gathering, or threat hunting. In MISP, a user can describe an event with multiple attributes while providing as much information as possible, or one can only put a minimum of information for an event. The pull mechanism allows a MISP instance to discover available events on a connected instance and download any new or modified events. It automatically goes through each of the event IDs that are eligible, converting them to MISP’s JavaScript Object Notation (JSON) format and “POST request” them to the event creation API of the remote end. If the event already exists, it can be edited, while the remote side will match the event by universally unique identifier to a local event and return the URL that could be used to update the event. It shows an index, description, events, attributes, correlations found, proposals, active users, organizations, discussion threads, discussion posts, and number of instances to ease the usage of MISP. The Computer Incident Response Centre Luxembourg (CIRCL) provides a feed of events that can be easily shared, such as open-source intelligence (OSINT) events and attributes that are classified as unclassified information that can be distributed without any restriction.

Fig. 7.2
A schematic of the S I E M architecture. Events from sources like authentication devices are sent to specialized connectors. Normalized events are then directed to security management platforms and a forensic analysis database. Terminals receive alerts from the security management platform.

A typical SIEM architecture. The SIEM system accepts input from various security devices and sensors

7 Investigation on Diverse Implementations within AVENUE

Considering the advantages of the SIEM along with the necessity of advanced security mechanisms, it is highly recommended to have it embedded within the CAV ecosystem. The SIEM can be deployed in several positions within the CAV environment. It can be installed in the cloud, or it can be installed inside the CAV. Both placements have their use in the overall architecture of the system. Since the speed and the robustness of the security system are critical in any automated minibus, the proposed position is considered as an isolated computer unit inside the vehicle with the objective of monitoring the whole network of the CAV. It provides an additional layer of security in case the vehicle gets compromised since it will allow the software to be part of detection, prevention, and response mechanisms. As is commonly found, many of the components inside the vehicle are defined by a characteristic network behaviour, in addition to their unique log files performance when they are operating under normal circumstances. The in-vehicle network system is comprised of vehicle electronic control units (ECUs) interconnecting with each other to create an Internet of Things ecosystem. The security administrators that will monitor the SIEM software will be able to recognize and detect in time possible attacks. This solution will provide real-time analysis of security alerts generated by the applications and network hardware which are implemented inside the vehicle. In this context, two different SIEM solutions are presented. The first one is the Security Onion and the second the Wazuh.

Security Onion

The installation of SecOnion for the simulated environment required approximately 15 GB of disk space, 2 GB of RAM, and 2 dedicated CPU cores of a 4.2-GHz processor. Each one of these is used for:

  • Central processing unit (CPU): Used to parse incoming events, index incoming events, search metadata, capture PCAP, analyse packets, and run the front-end components. As data and event consumption increases, a greater amount of CPU will be required.

  • Random-access memory (RAM): Used for Logstash, Elasticsearch, and disk cache for Lucene, Snort/Suricata, Zeek, Sguil, etc. The amount of available CPU will directly impact search speed and reliability, as well as ability to process and capture traffic.

  • Disk: Used for storage of indexed metadata. A larger amount of storage allows for a longer retention period.

In this set-up, and as presented in Fig. 7.3, the Security Onion was able to run properly and without any operational restrictions. The system under monitoring was another VM from where the captured data were analysed and visualized in Squert (Visscher, 2014). Additionally, Sguil was used as an intuitive GUI that provided access to real-time events, session data, and raw packet captures (Visscher, 2014). Finally, the Security Onion is a suitable tool to facilitate the practice of network security monitoring and event-driven analysis. The information shown in Sguil window, as presented in Fig. 7.4, includes the alert’s identification, date, and time the event took place, source and destination IP address, and the corresponding ports.

Fig. 7.3
A screenshot of the specifications of security onion. It presents the general, system, display, storage, audio, and network details of Security Onion along with the preview on the right.

Security Onion VM specifications

Fig. 7.4
A screenshot of the Squil window which is connected to the local host. File, query, reports, server name, user name, and user I D are at the menu tab. The data table below presents details such as S T, C N T, alert I D, sensor, and event message of real-time and escalated events.

Sguil’s window shows there are multiple events making available timestamps, destination and source, and event message information for analysis by the security administrators

Wazuh

An additional installation was performed to examine how user-friendly is the software, in addition to Security Onion where it was essential to have some experience in security domain. Wazuh provides a security solution capable of monitoring the infrastructure, detecting threats, intrusion attempts, system anomalies, poorly configured applications, and unauthorized user actions. It also provides a framework for incident response and regulatory compliance, as shown in Fig. 7.5.

Fig. 7.5
A flow diagram presents the program of the Wazuh Server. Wazuh agents are in Linux, windows, and Elastic servers are connected to Wazuh Manager. Filebeat and Wazuh A P I facilitate data collection from elastic search and the Wazuh Kibana plugin. Kibana serves as a user interface for Elasticsearch.

Wazuh server for monitoring, incident response, and regulatory compliance

In Fig. 7.6, the specifications for the Wazuh server are presented. In these settings Wazuh was able to run properly without any delays and restrictions. Wazuh server runs the manager and the API, where it collects and analyses data from the monitored agents. Additionally, there was an installation of two additional agents to examine the proper function of the SIEM software. In this case, the agents were two individual OS: Ubuntu 18.04, and Ubuntu 20.04. Wazuh agent runs on the monitored host, collecting system log and configuration data, allowing the detection of intrusions and anomalies. Communication with the server is mandatory, which forwards the collected data for further analysis. The compatibility between agent and manager/server is guaranteed when the manager version is greater or equal to the agent’s version. Additional information for the installation and the requirements can be found at Wazuh’s official site.

Fig. 7.6
A screenshot of the specifications of Wazuh. It presents the general, system, display, storage, audio, and network details of v m wazuh along with the preview on the right.

Wazuh server VM specifications

To test the Wazuh implementation in real scenario, the installation of Kali Linux was required. Kali can be installed using 128–512 MB of RAM and 2 GB of disk space. If 128 MB is available, it will be able to run only a basic SSH server with no desktop, and if it has 512 MB of RAM, it will run the default GNOME desktop with the full meta package. The recommended specifications are 2048 MB of RAM and 20 GB of disk space and at least one CPU supported by at least one of the amd64, i386, armel, armhf, or arm64 architectures.

The finalized test bench was implemented with four RAMs, two agents, one manager, and the attacker, as illustrated in Fig. 7.7. The attacker performed a brute force attack on the agents, which are the victims in this case, and the response of the system will be further analysed in the following figures.

Fig. 7.7
A screenshot of the installation setup of Wazuh. It has 4 windows labeled Agent 1 192 168 1 6, Agent 2 192 168 1 7, Attacker 192 168 1 3, and S I E M 192 168 1 15.

Testbench for Wazuh implementation

The Wazuh databases store information related to agent keys and file integrity monitoring (FIM)/Root check event data. This information is highly optimized to be handled by the core. To provide well-structured data that can be accessed by the user or the Wazuh API, new SQLite-based databases have been introduced in the Wazuh manager (Wazuh, 2023b). The database synchronization module is a user-transparent component that collects the following information from the core:

  • Agent information: name, address, encryption key, last connection time, operating system, version, and shared configuration hash

  • FIM data: creation, modification, and deletion of regular files and Windows registry entries

  • Root check-detected defects: issue message, first detection date, and last alert time

  • Static core settings: maximum permitted agents or SSL being enabled for Authd

The above description is provided by the official Wazuh documentation as precise description of the dashboard, which is shown in Fig. 7.8.

Fig. 7.8
A screenshot of the Wazuh user interface. It has the number of total, active, disconnected, and never-connected agents at the top. It displays data under security information management, threat detection and management, auditing and policy monitoring, and regulatory compliance.

Wazuh user interface modules

Figure 7.9 presents a screenshot from the security event module. The information visualized here includes the count of the alert levels, the corresponding timestamps, and a pie chart with the most attacked agents, among other important information for the security administrator. Additionally, there is a second tab, called “Events,” where a more detailed explanation is available.

Fig. 7.9
A screenshot of the security event dashboard in Wazuh. It has data for critical severity alerts, high severity alerts, medium severity alerts, and low severity alerts. It has graphs for most affected agents, most common C V Es, alerts severity, and TOP affected packages alerts evolution.

Security event dashboard

MITRE attack (The MITRE Corporation, 2020) is a knowledge base of adversary tactics and techniques based on real-world cases of cybersecurity threats. It is globally accessible and documents the procedure of the attacks. Essentially is a database which answers to the question of “How” an adversary achieves a tactical objective by performing an attack. This feature allows the user to additionally customize and enhance the database, as there is an option to include specific information related to cyberattack techniques, as presented in Fig. 7.10.

Fig. 7.10
A screenshot of the MITRE attack dashboard in Wazuh. It has graphs for alerts evolution over time, attacks by technique, top tactics by agent, top tactics, and MITRE techniques by agent.

MITRE attack database analysis dashboard

8 Conclusion

In the advancing landscape of smart city infrastructure, the appearance of automated minibuses has revolutionized urban transportation, offering innovation and efficiency. However, since automated minibuses must be continuously connected to their surroundings, a critical matter has to be highlighted: cybersecurity. The discussed solution, SIEM, stands as a cornerstone of real-time monitoring and response, collecting and analysing data from a plethora of sources within the vehicles’ system. Examining some of the most popular open-source SIEM platforms has revealed their diverse features and benefits. While SIEM offers numerous advantages, it is crucial to recognize its limitations, such as the need for extensive configuration, potential misconfigurations, and the resource-intensive nature of initial set-up. Considering the possible implementations makes it clear that SIEM should be a core part of the automated minibuses’ infrastructure. An isolated deployment within each vehicle is suggested, as deployed in Copenhagen and Geneva pilot sites of the AVENUE project, since this solution allows comprehensive network monitoring while providing an additional layer of security and real-time analysis to detect and respond to potential malicious actions. In conclusion, the incorporation of SIEM as a defence mechanism is not just a necessity but a vital step towards ensuring the safety and security of passengers and the long-term sustainability of transportation systems.