The physical layer encompasses the hardware components and direct physical interactions involved in the charging process. This layer includes EVs, EVCSs, and the Power Grid. EVs connect to EVCSs via standardized physical connectors. EVCSs manage the physical power transfer and perform essential real-time monitoring of operational parameters for control and safety.

The network layer provides the communication infrastructure enabling data transfer between physical devices and application layer systems, as well as internally within complex devices like the EVCS. Key protocols facilitating these interactions include:

ISO 15118: governs communication between the EV and the EVCS, enabling secure authentication, authorization, and charging parameter exchange.

The application layer comprises high-level software platforms and services managing overall system operations and user interactions. Key components shown at this layer are:

Mobile Application: provides end-user interfaces to locate stations, initiate charging sessions, and manage accounts through interaction with the CSMS.

This initial step identifies all relevant hardware and software elements within the investigation’s scope. Formally, we define the set of components as C={c1,c2,…,cn}, where each ciϵC represents a distinct system element. The process involves reviewing available technical documentation, analyzing network topology data, conducting controlled network discovery, and consulting system diagrams to enumerate components such as specific EVCS models cevcs CPO backend servers (ccsms), e-MSP platforms (cemsp), communication gateways (cgw), databases (cdb), and the associated EVs (cev). Each component (ci) can possess attributes like type, vendor, model, and version, contributing to the detailed system understanding.

The next step is to map the communication links and protocols that connect the identified components. The system’s interaction structure is formally modeled as a directed graph G=(C,I), where C is the set of vertices (components) and I is the set of edges representing the interfaces. An interface i∈I is defined as a tuple (csrc,cdst,p), where csrc,cdst∈C are the source and destination components, respectively, and p∈P is the communication protocol (from a set of relevant protocols P) utilized over that interface; thus, I⊆C×C×P. Identifying these interfaces involves analyzing protocol information from documentation (e.g., specific versions like OCPP 1.6J, ISO 15118-2), reviewing network configurations, and potentially analyzing network traffic samples. This helps in understanding how data, including potential digital evidence, are exchanged.

This step involves documenting the critical operational functions performed by the identified components and interfaces, particularly those relevant to potential security incidents. A set of critical functions F={f1,f2,…,fm} is defined. Each function fk∈F can be formally mapped to the set of components responsible for its execution MapF→C:F→2C and the set of interfaces utilized MapF→I:F→2I. For instance, an authentication function fauth might involve components {cev,cevcs,ccsms} and utilize interfaces associated with protocols piso15118 and pocpp. This mapping, derived from protocol specifications, user manuals, and system requirements, allows investigators to anticipate where digital evidence related to specific actions (e.g., authentication failures, unauthorized commands) might be generated within the formal model G.

The intended output of this system modeling phase is a formalized initial asset analysis. Based on the modeled graph G=(C,I) and the function mappings MapF→C,MapF→I, this analysis identifies critical system assets. A criticality score, Crit(x), can be assigned to each element x∈C∪I. This assignment considers factors such as its role in critical system functions (derived from F), its potential to store sensitive data or operational logs (information typically part of the System Knowledge Base, KBsys), and its direct relevance based on the preliminary incident information (Iinfo). Critical assets, Assetscrit, are then identified as those elements meeting or exceeding a certain criticality threshold, θ; formally, Assetscrit={x∈C∪I∣Critx≥θ}. It is important to note that while this describes a formalized approach, the practical assignment of criticality scores and determination of thresholds may be adapted based on the specific investigative context, available information, and experienced judgment, potentially incorporating qualitative assessments alongside or in place of strict quantitative scoring. Regardless of the specific evaluation method, the clearly identified set Assetscrit and the formal graph G are the key outputs of this phase passed to subsequent procedures.

This involves gathering specific documents describing the target system’s implementation, focusing on critical assets (Assetscrit). Sources include vendor manuals, system requirements, firmware notes, security advisories, and component datasheets, often found via OSINT (Sosint) or direct requests.

The Data Source Inventory (DSI) should incorporate operational data (e.g., logs from CPOs/CSMSs, EVCSs, network devices, databases, particularly from Assetscrit) acquired through authorized procedures, and comparative datasets from public repositories or OSINT (Sosint) to provide analytical context and baseline behaviors.

Precise technical specifications for communication protocols (p∈P) identified in G (e.g., ISO 15118, OCPP) are essential for accurately interpreting communication-related digital evidence from the DSI. They define message structures, data fields, and forensically relevant information, forming a basis for analysis.

This initial step scrutinizes the communication pathways and data exchanges between system components (ci∈C) as delineated in the system model G. Applying the collected protocol specifications (part of DSI) corresponding to interfaces (ik∈I), the flow of critical data types across these defined interfaces is examined. This process can be visualized using data flow diagrams (DFDs) to identify potential junctures for data interception or manipulation, delineate attack vectors predicated on data flow characteristics, and anticipate the location of potential digital evidence generation within G. Fig. 4 provides an example of such a DFD for a representative EV charging infrastructure, illustrating how this technique can map out data movements between various entities and processes. Sosint can contribute by providing intelligence on known protocol implementation weaknesses or common misconfigurations affecting data flow security.

Threat modeling extends the insights from data flow analysis by applying established methodologies, such as STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service, and Elevation of privilege), to categorize and identify potential threats relevant to the EVCI, possibly drawing from a predefined threat taxonomy [22,31]. This approach links identified data flows and system elements to potential threat vectors. For example, spoofing threats might compromise EV-to-EVCS authentication processes (potentially related to interfaces using p_iso15118), while tampering could alter metering data transmitted via OCPP. This structured analysis helps reveal how adversaries might exploit system weaknesses and results in the identification of a set of relevant threats for the investigation, guiding the subsequent search for associated forensic evidence.

The attack surface analysis synthesizes the findings from data flow analysis and the identified threats to provide a comprehensive mapping of the system’s attack surface. This involves identifying all interfaces and components in G through which the system could potentially be accessed or influenced by the threats in Tid. Each identified element of the attack surface is correlated with specific threats and associated vulnerabilities. For instance, communication channels susceptible to interception or components prone to tampering are highlighted. Fig. 5 conceptually demonstrates how an attack surface can be identified within the EV charging infrastructure, focusing forensic efforts on the most significant vulnerabilities defined within AS. The Threat-Evidence Map is then generated by correlating these identified threats and attack surface elements with the list of potential digital evidence compiled during data collection.

To effectively utilize the MTE and guide the search for digital evidence, a structured taxonomy of potential incident types, categorized by the affected architectural layer, is a useful tool. This classification schema can be derived from the threats Tid identified during threat analysis (Section 3.3.2) and mapped onto the layered system architecture. Such a taxonomy facilitates a structured investigative approach by enabling investigators to associate observed anomalies or alerts with specific incident categories, thereby refining the focus within the MTE to pinpoint types of digital evidence most likely to be relevant.

Physical layer: physical layer incidents include hardware tampering, unauthorized physical access, or power grid disruptions. For instance, tampering with EVCS units (cevcs) might involve altering charging parameters or injecting malicious firmware.

This step details the process of identifying and acquiring specific digital evidence pertinent to the forensic investigation. Guided by the Layer-Specific Incident Taxonomy and the MTE, candidate digital evidence (Acandidate) is selected from the pool of potential digital evidence. Acquisition procedures are then employed to retrieve these Acandidate items from the sources cataloged in the DSI, often prioritizing sources associated with critical assets. The resulting set of collected digital evidence is denoted as Aacquired. The identification of specific relevant digital evidence within Apot involves a systematic analysis of collected data (DSI, including protocol specifications, datasets, documentation), categorized across the architectural layers. The following tables (Tables 3–10) present a comprehensive catalogue of digital evidence types identified as potentially valuable for forensic investigations within the EVCI. This catalogue is intended to guide investigators on what to look for and serves as a baseline for establishing forensic readiness.

Physical layer digital evidence originates from hardware components (ci∈C) and their operational data. Based on the analysis of protocol specifications like ISO 15118 and examination of various datasets within DSI, critical physical layer digital evidence can be identified:

EV-related digital evidence: analysis of standards such as ISO 15118-2 reveals message types generating valuable digital evidence [49]. Message structures identified (e.g., from specific standard sections) yield digital evidence detailed in Table 3, representing critical evidence for physical layer incidents.

EVCS-related digital evidence: comparative analysis of multiple charging session datasets (examples referenced in Table 2 and detailed in Appendix A) enables the identification of common digital evidence generated across diverse charging systems (cevcs). Table 4 shows this digital evidence, providing essential evidence for incidents involving charging equipment.

Network layer digital evidence comprise data generated during communications between components over interfaces (Ik∈I). Critical forensic evidence is identified across primary communication segments:

EV-to-evcs communication digital evidence: analysis extends beyond the ISO 15118 message content (as referenced for physical digital evidence) to include network-level communication traces with significant forensic value, detailed in Table 5. These encompass physical connection signals, handshake parameters, security mechanism traces, and connection events.

Application layer digital evidence encompass data generated by management systems (ccsms), user applications, and related services. Systematic analysis identifies several categories of application-level digital evidence with significant forensic value:

Authentication digital evidence: the OCPP generates several authentication-related digital evidence for forensic investigation as detailed in Table 7.

The collection and categorization of these diverse digital evidence (Aacquired) across all layers, guided by MTA and the incident context, provide the foundation for the subsequent evidentiary value assessment (Section 3.4.3). Investigators can reconstruct complex incident scenarios, attribute malicious activities to specific actors, and document the effects of security events on charging operations by collecting and analyzing these digital evidence.

Following the acquisition of potentially relevant digital evidence (Aacquired), a critical phase involves the formalized assessment of their evidentiary value. This assessment provides a quantitative basis for prioritizing analytical efforts, focusing resources on digital evidence most likely to contribute significantly to the investigation. The evaluation is based on established forensic criteria—Relevance, Reliability, Temporal Fidelity, and Completeness—considered within the specific context of the EV charging infrastructure incident, and utilizes a structured quantitative model.

We define the Evidentiary Value E(A) for each Digital evidence A∈Aacquired using a multi-criteria decision analysis approach, specifically a weighted sum model as presented in Eq. (1). This model was chosen initially for its clarity, while acknowledging the potential for more complex models in future work. (1)LE(A)=wR⋅fR(A)+wL⋅fL(A)+wT⋅fT(A)+wC⋅fC(A)where fR,fL,fT,fC represent scoring functions that quantify the digital evidence’s Relevance, Reliability, Temporal Fidelity, and Completeness, respectively. A critical step for practical application, which is beyond the scope of the current definitions provided in this paper, is the development of specific, objective rubrics or mathematical formulas to operationalize each function fX(A), mapping diverse digital evidence attributes onto a normalized scale (e.g., [0, 1]). The weights wR,wL,wT,wC represent the relative importance of each criterion, determined contextually for the specific investigation, satisfying ∑wi=1.

Relevance (fR): this function must quantify the direct linkage between Digital evidence A and the incident hypothesis or investigative questions. Defining the scoring mechanism requires establishing rules based on factors like the evidence’s ability to confirm/refute specific questions (e.g., event timing, actor identity).

A critical consideration for the practical application of Eq. (1) is the necessary development of specific, objective rubrics or detailed mathematical formulas to operationalize each scoring function fX(A). Defining these functions rigorously is a complex task and is considered beyond the scope of the current paper’s primary contributions, representing an area for significant future research. Therefore, in the context of this paper and its case studies, the assessment of evidentiary value is primarily guided by these criteria in a qualitative or conceptual manner, rather than through strict quantitative calculation using Eq. (1). The aim is to filter Aacquired to yield Arelevant where E(A) is deemed sufficiently high based on these guiding criteria and a conceptually applied threshold. Subsequent analysis involves correlating Arelevant to reconstruct the incident timeline and determine findings.

Following the method outlined in Section 4.1 and the System Modeling procedure in Algorithm 1, we constructed a detailed system model relevant to the scenarios in Table 11. This involved identifying the key system components (C) and their communication interfaces (I), formally conceptualized as a graph G=(C,I). Table 12 provides an overview of the primary components and interfaces considered in this case study’s system model.

This model synthesizes the architectural representations in Figs. 1 and 2. Regarding the physical layer, relevant hardware components identified in Table 12 include the HMI display systems, power conversion modules, cooling management subsystems, and input contactors. The interface mapping identified critical communication pathways, such as the internal bus between the HMI display and the central controller (relevant to Scenarios 1–3) and interfaces controlling the power module and cooling system (relevant to Scenarios 4–7). The function identification process revealed that these components execute critical operations like power delivery control, thermal regulation, and safety monitoring, generating forensically significant data. The model also captures network layer interfaces like the EV-EVCS communication (using CCS/CHAdeMO) and the EVCS-CSMS communication (using OCPP), relevant to Scenarios 8–11.

This phase focused on gathering diverse data sources essential for the investigation. The collection was specifically targeted towards obtaining information related to the key system components and interfaces identified in the system model (Table 12). The primary goal was to compile a comprehensive Data Source Inventory (DSI) and subsequently identify a list of Potential Digital evidence (Apot) by analyzing the DSI based on predefined Digital evidence definitions (Adef). This involved gathering technical documentation, relevant datasets, and specific communication protocol standards governing the identified interfaces.

The technical documentation analysis focused on specifications like ISO 15118 and OCPP, which define the communication structure pertinent to the interfaces listed in Table 12. These specifications supply detailed message formats, data fields, and parameter definitions crucial for interpreting communication digital evidence potentially present in the collected data.

The dataset analysis incorporated multiple datasets identified during data collection (examples referenced in Table 2 and detailed in Appendix A), including the Multifaceted Analysis of EV charging data, DESL-EPFL data, and DOE EV charging data. These datasets provided baseline behavioral patterns for charging operations related to the modeled components (EV, EVCS), enabling the identification of anomalous activities characteristic of the security incidents described in Table 11.

The examination of the protocol specifications (part of the DSI) revealed substantive differences in security-relevant data fields between protocol versions, directly impacting the Apot derivable from communications over interfaces like the EVCS-CSMS link (Table 12). For example, OCPP 1.6 implementations often omit critical security event logging capabilities present in OCPP 2.0, whereas implementations of ISO 15118 vary significantly in certificate handling and authentication mechanisms. These variations substantially affect the forensic digital evidence available during investigations and require tailored analysis approaches for different deployment scenarios impacting the components and interfaces modeled in Table 12. Table 13 summarizes the key differences between protocol versions and their implications for forensic investigations.

The threat analysis procedure utilized the system model and the collected data sources and potential digital evidence from the previous phase as primary inputs, along with incident information (Iinfo) derived from Table 11 scenarios and a predefined threat taxonomy (Ttax). The objective was to systematically identify relevant threats (Tid), delineate the attack surface (AS) pertinent to the modeled system, and critically, generate the Threat-Digital Evidence Map (MTE) that links identified threats to Apot, guiding the subsequent digital evidence identification phase.

The data flow analysis scrutinized communication pathways between the system components and across interfaces defined in Table 12. For Scenarios 1 to 3 involving HMI anomalies, we mapped the flow of display instructions from the EVCS Controller to the EVCS HMI, identifying potential interception points on the EVCS Internal Interface. For Scenarios 4 to 7 affecting power and thermal systems, we traced control signals between the EVCS Controller, Power Module, and Thermal Management system via internal interfaces, highlighting vulnerable points where malicious commands could be injected. For communication-related scenarios (8 to 11), we analyzed the bidirectional data flows over the EV-EVCS and EVCS-CSMS interfaces, identifying potential protocol vulnerabilities.

Threat modeling then classified each scenario according to its predominant threat category using the STRIDE framework (drawing from Ttax), explicitly linking threats to the components and interfaces in Table 12. This classification, summarized in Table 14, connects Tid to their likely manifestations in system data and guided the generation of the MTE.

The attack surface analysis integrated these findings to map the system’s overall AS comprehensively. As illustrated conceptually in Fig. 6, this involved correlating the identified vulnerable components and interfaces from Table 12 (e.g., EVCS Maintenance Interface, EV-EVCS and EVCS-CSMS communication link) with the Tid relevant to the scenarios. This analysis highlighted that maintenance interfaces, physical connectors (related to EV-EVCS interface), protocol implementations (affecting all communication interfaces), and administrative access mechanisms (potentially via EVCS-CSMS interface) represent the most significant elements of the AS for these scenarios.

The key output of this phase, the MTE, formally links the identified threats (Tid) and attack surface elements (AS) to the Apot listed in the previous step, providing a crucial input for the evidence analysis in the next section.

This procedure systematically processes potential evidence based on the findings from the preceding threat analysis phase. Key inputs for this procedure, as defined in Algorithm 1, include the MTE, Iinfo, G, Assetscrit, DSI, and Adef. The core of this analysis begins by selecting Candidate Digital evidence (Acandidate) pertinent to the scenario, guided by the MTE, followed by acquiring these candidates (Aacquired) from DSI. Subsequently, the Evidentiary Value (E(A)) of acquired digital evidence is conceptually evaluated using the criteria from Eq. (1), and only those meeting the required evidentiary threshold are filtered as Relevant Digital evidence (Arelevant). These relevant digital evidence are then correlated using temporal, spatial, and system-model-based analysis. This correlation enables the reconstruction of the incident timeline and the determination of findings based on the consolidated evidence. The relevant digital evidence (Arelevant) identified through this process for the case study scenarios are discussed below, organized by architectural layer.

For HMI-related incidents (Scenarios 1 to 3), the Evidence Analysis procedure, guided by the relevant part of M_TE, focused on identifying digital evidence from the EVCS Controller and HMI components (Table 12). Key Arelevant identified included controller-HMI communication logs (from EVCS Internal Interface), system status codes indicating component communication errors, external device connection records (via EVCS Maintenance Interface), and command history logs. HMI-controller communication logs were assessed (conceptually, via E(A)) as having high evidentiary value for distinguishing system malfunctions from malicious manipulations. For example, a simplified logical check applied during the correlation step to detect potential display tampering in these logs can be formulated. In the following expression in Eq. (2), cmd represents an individual command or log entry within the log: (2)IsTampered(LogHMI)=∃cmd∈LogHMI;s.t; (cmd.source∉TrustedSources)∨(¬VerifyChecksum(cmd))

For power and thermal management incidents (Scenarios 4 to 7), the analysis targeted digital evidence related to the EVCS Power Module, Thermal Management system, and Input Contactor. Relevant digital evidence identified through the process included power module control signals, real-time power/voltage measurements (potentially derived from ISO 15118 messages exchanged over the EV-EVCS interface, if logged), thermal management system logs documenting cooling system behavior, state transition records, and internal network traffic captures (EVCS Internal Interface). However, our analysis, stemming from the difficulty in acquiring sufficient Aacquired for evaluation, highlighted a critical digital evidence gap: detailed thermal management data such as cooling pump operation status, fan activation patterns, and precise cable temperature sensor readings are often not systematically recorded or available in the DSI of current implementations. This lack of granular data severely hampers the forensic analysis and conclusive determination (timeline reconstruction) of thermal incidents.

For communication protocol incidents (Scenarios 8 to 11), the focus was on digital evidence generated during communications over the EV-EVCS and EVCS-CSMS interfaces. Significant Arelevant identified included Controller Area Network (CAN) bus communication packets documenting protocol-level interactions, control pilot signal data detailing pulse-width modulation signals and duty-cycle patterns, charging session timing information, battery SoC reporting data, and network traffic patterns potentially revealing attacks like Man-in-the-Middle or replay on either interface. The Evidence Analysis process again revealed significant gaps: CAN bus communication packets and detailed pilot wire signal logs were identified as potentially high-value digital evidence (high potential E(A)) but are not consistently captured or available in the DSI from existing systems. This represents a significant limitation in current forensic capabilities for investigating attacks targeting these communication layers.

The analysis revealed substantive patterns in digital evidence availability and utility across these scenarios. Physical layer digital evidence provided the most direct evidence of system manipulation but were often inadequately logged in existing implementations. Network layer digital evidence offer the most consistent forensic value, particularly when protocol-level traffic is comprehensively captured. Application layer digital evidence vary significantly in forensic utility depending on implementation-specific logging practices, with substantial inconsistencies across charging networks. These patterns strongly highlight the need for improved standardization of forensic logging practices across the EV charging ecosystem to ensure sufficient high-value digital evidence (Arelevant) can be reliably identified, acquired, and analyzed using this method, thereby enhancing overall investigative capabilities.

This first virtual scenario involves a fire incident at an EVCS. The potential causes are varied, including EVCS malfunction, EV battery faults, user actions, or external environmental factors. Applying the structured forensic method proposed herein, the goal of the investigation is to determine the root cause. The process involves identifying and acquiring critical digital evidence, such as battery SoC information from the EV, EVCS data, and corresponding user authentication/payment data from the CSMS. The subsequent analysis phase examines these identified digital evidence for anomalies and correlations indicative of the fire’s origin. For example, scrutinizing power logs (LogPower) for overcurrent conditions preceding the incident could involve the illustrative check shown in Eq. (3). In this equation, Twindow represents the specific time window being analyzed within the power log, and Imaxlimit denotes the predefined maximum current threshold considered safe for the EVCS operation: (3)DetectOvercurrent(LogPower,Twindow)=∃t∈Twindow;s.t.;Current(LogPower,t)>Imax_limit

Further analysis would involve examining EVCS status codes and EV SoC data for electrical faults (overvoltage, overcurrent, overcharging), analyzing power logs for other abnormal requests or delivery patterns, reviewing available environmental sensor data (temperature, water ingress), and correlating CSMS data with the incident timeline to assess user actions. Finally, synthesizing the findings from the correlated evidence allows inferring the most probable cause.

This scenario considers a coordinated attack leveraging the EV charging infrastructure to disrupt the electrical grid. Guided by the proposed systematic method, the investigation aims to identify the attack vector, method, and involved entities. Critical digital evidence identified during the evidence analysis phase include EV SoC data, EVCS power logs, charger status codes, EVCS-CSMS communication logs (OCPP), session timing data, and CSMS logs (user authentication, network traffic, OS access).

The analysis phase focuses on detecting anomalies indicative of such a coordinated attack across multiple chargers. As an example of specific logic that could be applied, detecting potentially coordinated high charging demands might involve a check like the one defined in Eq. (4). In this equation, Csubset represents the subset of chargers under scrutiny within a specific time window twindow, IsHighDemand(Logc,twindow) is a function evaluating if an individual charger c’s log indicates high demand during that window, and Demandthreshold is a predefined threshold representing the minimum ratio of chargers in the subset that need to show high demand simultaneously to trigger suspicion: (4)DetectCoordinatedDemand(Logs,Csubset,twindow)L=(1|Csubset|∑c∈CsubsetIsHighDemand(Logc,twindow))>Demandthreshold

Beyond such specific checks, the broader analysis involves scrutinizing power logs and status codes for abnormal grid feedback or simultaneous faults. Communication logs and session timing data are analyzed for patterns suggesting orchestrated commands or communication jamming. CSMS logs are assessed for evidence of unauthorized access or command injection targeting grid interaction parameters. Correlating suspicious network activity with authentication data helps identify compromised accounts or actors involved. Consolidating the evidence then confirms the nature and source of the attack.

This scenario involves tracking a stolen EV using charging station data. Following the defined forensic process, the investigation focuses on reconstructing the vehicle’s location and movement patterns. Essential digital evidence identified during the investigation include the stolen vehicle’s unique identifier (EVstolen), its battery SoC data recorded during charging sessions, charger IDs and their physical location data, requested power logs, session timestamps, and relevant CSMS data (like user authentication and network logs).

The core of the analysis involves querying CSMS and EVCS logs using the (EVstolen) to retrieve all associated charging events. The locations from these events are then mapped chronologically to reconstruct the vehicle’s path. The logic for this path reconstruction can be represented by Eq. (5). In this equation, QueryLogsByEV_ID(EVstolen) retrieves the relevant session records for the EVstolen, the Map function extracts the timestamp (session.timestamp) and location (session.location) from each session record (session), and Sorttime orders these timestamp-location pairs by time to produce the final path sequence (Path): (5)Path=Sorttime(Map(QueryLogsByEV_ID(EVstolen),λsession:(session.timestamp,session.location)))

In addition to path reconstruction, the SoC data recorded at the start and end of the identified sessions can help estimate the travel range and predict potential subsequent locations. Analysis of the requested power data might also help distinguish the stolen vehicle’s unique charging signature. Furthermore, user authentication information and network logs associated with these sessions can provide clues regarding the perpetrator’s methods or location. Integrating these digital findings with physical evidence (e.g., CCTV footage from charging sites) completes the investigation picture.

This scenario addresses a compromise of the charging network or CSMS for data exfiltration or manipulation. Following the proposed structured approach, the investigation aims to determine the intrusion vector, breach scope, data manipulation, and trace attacker activities. Relevant digital evidence identified during the analysis include potentially compromised data (EV IDs, SoC logs), charger/location info, OCPP logs, session times, and critical CSMS logs (authentication, network traffic, OS access, database audit, firewall).

The analysis phase focuses on identifying the breach point and potential data exfiltration pathways. For instance, network traffic logs (LogNet) are examined for suspicious outbound connections. An example rule applied during this analysis to flag potentially suspicious network flows (flow) is given in Eq. (6). Here, flow.dest is the flow’s destination address, TrustedDestinations is a predefined set of legitimate destinations, flow.protocol is the protocol used, Pexfil represents protocol(s) potentially used for exfiltration (e.g., FTP, specific TCP ports), flow.volume is the data volume transferred, and Vexfilthreshold is a volume threshold indicating potential large data transfer to an untrusted destination: (6)IsSuspiciousFlow(flow)=(flow.dest∉TrustedDestinations)∧(flow.protocol=Pexfil)∧(flow.volume>Vexfil_threshold)

In addition to network traffic analysis, CSMS access logs are examined for unauthorized access attempts or privilege escalation. OCPP communication logs are reviewed for signs of data tampering or unauthorized command injections directed at charging stations. Database audit logs are crucial for identifying any unauthorized record modification or deletion. Comparing potentially exfiltrated data with original system records helps determine the scope of the breach and any data manipulation. Correlating various logs allows reconstruction of the attacker’s actions, identifying compromised accounts or systems, and potentially tracing the attack origin. The final phase involves synthesizing the findings into a comprehensive report on the breach.