# V-SOC4 AS: A Vehicle-SOC for Improving Automotive Security
## 4 V-SOC4 AS: Vehicle-SOC for Improving Automotive Security
### IBM QRadar SIEM  
Starting from the proposed architecture, IBM QRadar SIEM was used in order to identify attacks in an automotive environment [37]. This choice was based on the following reasons:  
* Good position, \"Leader\", in Gartner Magic Quadrant 2022 [38] in comparison to other SIEMs. * Possibility to create a custom Log Source different from the IT context. IBM QRadar, using the Syslog protocol, allows information to be received from systems that are different from each other, for example, a vehicle and a computer. * Possibility to use a set of default rules to be customized for the automotive environment. * Risk priority modelling that determines the priority level of each offense based on local and enriched threat context, tactics and techniques observed and learned offense disposition patterns within the automotive environment. QRadar consists of a modular three-layer architecture that provides, in real-time, the security status of the IT infrastructure. These three-layer are [39]:  
* Data Collection: Collects data such as events or flows from a specific asset. IBM QRadar SIEM accepts data from IDS/IPS, firewall, Syslog, and other sources. The data are parsed and normalized before they are passed to the processing layer. Raw data are parsed and then normalized to present them in a structured and usable format. In Figure 1, this task is carried out by the \"Data Collection\", \"Event aggregation parsing & normalization\", and \"Rule-based Analysis\" modules. * Data processing: In this layer, the data are run through the custom rule engine (CRE), which generates offenses and alerts, and then are written to the storage. In Figure 1 this task is carried out by the \"rule-based\" module. * Data searches: Data collected and processed by QRadar are available to users for searches, analysis, reporting, and alerts or offense investigations. In Figure 1, this task is carried out in the SOC console. IBM QRadar uses the Syslog protocol [40] to receive generic events. For this reason, in the proposed architecture, the CAN messages are sent using this protocol in JSON format. When IBM QRadar obtains data from a generic log source (would be the TCU or other vehicle components in the context of automotive) using the Syslog protocol, it manipulates them using the three-tier architecture described above. In this work, IBM QRadar SIEM Community Edition v7.3.3 was used. Specifically, V-SOC4 AS combines the tools found in QRadar to obtain messages from a vehicle, parse them, and check using rule-based mechanism whether these messages are attacks. An important consideration is that we send messages to IBM QRadar using a local network and not through the cloud environment. Figure 2 shows the Log Source created to receive the messages. It contains various parameters: _ID_ that is automatically generated; _Name_ is a generic name that can be defined by the user; _Description_ can be empty; _Enabled_ whether it is to be activated or not; _Log Source Type_ identifies the type of the event; _Protocol Type_ to set the appropriate format for different contexts. In this example, Syslog was chosen. To properly analyze the data from the vehicle, a plug-in file called device support module (DSM) supported by QRadar was used. This plug-in collects the raw data and transforms them into a specific format defined by the SOC analyst so that it can be shown on log activity. The DSM extracts the value contained in the JSON with a specific key and creates six properties. An example of a property created by DSM is shown in Figure 3.  
The other properties created are:  
* Vehicle ID: unique identifier of the vehicle (expressed in the payload with a Universally Unique Identifier (UUID). It can be used in the response phase when an attack is detected. * Event ID and Event Category: are used to map an event with Qradar Identifier (QID). QID is a numeric representation of a specific event and includes name, description, severity, and low-level category. Figure 4 shows the QID, ECU data transfer created with these properties.