Source-linked AI summary
Real Time Lateral Movement Detection based on Evidence Reasoning Network for Edge Computing Environment
Zhihong Tian, Wei Shi, Yuhang Wang, Chunsheng Zhu, Xiaojiang Du, Shen Su, Yanbin Sun, Nadra Guizani
TL;DR
Edge-cloud environments complicate lateral movement detection because attacks span distributed, dynamic systems with uncertain data persistence. CloudSEC constructs an Evidence Reasoning Network from vulnerabilities and environmental information, and experiments report complete, credible evidence chains with real-time reasoning capability.
Problem
Edge-cloud complexity, dynamic architectures, and uncertain data persistence make lateral movement detection and forensic reconstruction difficult.
Source: §I · p. 1Method
CloudSEC builds an Evidence Reasoning Network from vulnerability knowledge and network-environment information to correlate evidence and reason about attack chains.
Source: §I · p. 2, §III · p. 2Results
Experiments report complete and credible evidence chains, real-time lateral movement reasoning, and processing of around 100 evidence chains per second.
Source: §I · p. 2, D. Performance Analysis · p. 7, §V · p. 8Takeaways & Limitations
CloudSEC supports rapid evidence investigation and real-time attack detection in complex edge-cloud environments.
Source: §V · p. 8
Abstract
from arXiv · showhide
Edge computing is providing higher class intelligent service and computing capabilities at the edge of the network. The aim is to ease the backhaul impacts and offer an improved user experience, however, the edge artificial intelligence exacerbates the security of the cloud computing environment due to the dissociation of data, access control and service stages. In order to prevent users from using the edge-cloud computing environment to carry out lateral movement attacks, we proposed a method named CloudSEC meaning real time lateral movement detection based on evidence reasoning network for the edge-cloud environment. The concept of vulnerability correlation is introduced. Based on the vulnerability knowledge and environmental information of the network system, the evidence reasoning network is constructed, and the lateral movement reasoning ability provided by the evidence reasoning network is used. CloudSEC realizes the reconfiguration of the efficient real-time attack process. The experiment shows that the results are complete and credible.
I. INTRODUCTION
The edge-cloud model improves service proximity and latency but increases security complexity, making lateral movement detection difficult. CloudSEC addresses this need by constructing evidence chains for real-time reasoning and forensic investigation.
Motivation
- Edge computing shares cloud-center load at the network edge, providing low latency, proximity, and high bandwidth for services.The combined edge-cloud environment supports applications including e-Health, augmented reality, smart cameras, gaming, and industrial automation.Source: §I · p. 1
- Greater authority transfer, additional service stages, and increased data interactions make complete intrusion prevention impractical in edge-cloud systems.The paper therefore emphasizes monitoring system operation, estimating system state, detecting intrusions, and driving responses.Source: §I · p. 1
Challenges
- Lateral movement detection faces uncertain data persistence on constrained edge nodes, limiting traditional methods that require manual effort and business knowledge.The paper identifies uncertainty about data origin, persistence, and storage as part of this challenge.Source: §I · p. 1
- Dynamic edge architectures can prevent detection methods based on identifying changes in node behavior from applying successfully.Vehicular fog computing over vehicle ad hoc networks is given as an example of such dynamism.Source: §I · p. 1
CloudSEC
- CloudSEC constructs an Evidence Reasoning Network from network vulnerabilities and environmental information to reason about lateral movement in real time.The method is intended to produce concrete evidence, clarify attack consequences, and support response decisions.Source: §I · p. 2
II. RELATED WORKS
Prior work includes host-based forensics, packet capture, evidence correlation, and distributed logging, but these approaches have limitations in dynamic and poorly persistent edge-cloud environments. CloudSEC combines event monitoring with alert correlation to support this setting.
Existing approaches
- Existing forensic approaches include host media analysis, packet capture, evidence graph presentation, intrusion forensics, and distributed logging.These approaches differ in whether they collect, present, analyze, or correlate forensic evidence.Source: §II · p. 2
- Several prior methods rely on long-term logs or statistical analysis, which the paper states are unsuitable for poor data-persistence environments.This limitation is presented in the context of edge-cloud forensic requirements.Source: §II · p. 2
Limitations
- Host-based methods operate in the same fault domain as the kernel, making them susceptible after privilege acquisition and vulnerable to crashes or kernel compromise.The paper identifies user-level operation and shared fault domains as the relevant weaknesses.Source: §II · p. 2
CloudSEC architecture
- CloudSEC uses EventTracker inside each virtual machine or container and AlertCorrelator at the edge to monitor activities and correlate distributed intrusion alerts.EventTracker audits logs, commands, and system calls, while AlertCorrelator analyzes alerts from multiple network intrusion detection sensors.Source: §III · p. 2
A. Vulnerability and Vulnerability Correlation
CloudSEC models multi-stage attacks through vulnerability correlation, linking vulnerabilities when they can support a multi-stage attack. Correlations are represented with AND or OR structures and used to connect discrete attack evidence.
Definitions
- A vulnerability is a defect in software whose exploitation can violate security policies and harm system confidentiality, identifiability, or usability.The paper denotes a vulnerability as v.Source: A. Vulnerability and Vulnerability… · p. 3
- Vulnerabilities are correlated when an attacker can use a selected set of them to launch a multi-stage attack against a software system.The definition applies to vulnerabilities within the system’s vulnerability set.Source: A. Vulnerability and Vulnerability… · p. 3
Correlation structures
- An AND correlation requires all specified vulnerabilities, whereas an OR correlation requires any one of them to enable the attack premise.These structures encode alternative requirements for exploiting a target vulnerability.Source: A. Vulnerability and Vulnerability… · p. 3
- CloudSEC maps attack features into vulnerability space so attack correlations can be represented as vulnerability correlations.This mapping supports construction of credible evidence chains from discrete attack evidence.Source: A. Vulnerability and Vulnerability… · p. 3
B. Evidence Reasoning Network Model
The Evidence Reasoning Network is a directed graph that connects network nodes and correlated vulnerabilities with logical relationships, risk weights, and evidence data structures. CloudSEC constructs this graph from network topology and vulnerability information, then reasons over it to reconstruct attack processes.
ERN model
- An Evidence Reasoning Network represents information-system connectivity and vulnerability correlations as a directed graph.The graph is used to correlate evidence and reason about attack chains.Source: B. Evidence Reasoning Network Model · p. 3
- ERN vertices contain network-node and vulnerability information, while directed links connect parent and child nodes with correlated vulnerabilities.The link direction represents the connectivity relationship used in reasoning.Source: B. Evidence Reasoning Network Model · p. 3
- Logical expressions use AND and OR operators to represent relationships among incoming or outgoing directed links at each node.These expressions determine how linked evidence satisfies a node’s reasoning conditions.Source: B. Evidence Reasoning Network Model · p. 3
- Each vertex receives a risk weight wi = (fi+pi+ri)/3 combining functional value, exploitation probability, and security impact.The weight provides a standard for evaluating generated evidence.Source: B. Evidence Reasoning Network Model · p. 3
Evidence storage
- ERN data structures store evidence timestamps, child pointers, node states, and risk weights for reconstructing attack flows.Circular queues support evidence storage, while pointers preserve process relationships.Source: B. Evidence Reasoning Network Model · pp. 3–4
ERN construction
- CloudSEC constructs the network by reporting topology, scanning vulnerabilities, creating vertices, and recursively generating directed links and logical expressions.The resulting example network contains 10 nodes and 11 directed links.Source: B. Evidence Reasoning Network Model · p. 4
C. Evidence Chain Reasoning
The evidence chain reasoning process maps extracted evidence to vertices in an Evidence Reasoning Network and links evidence when directed relationships and logical conditions are satisfied. It then reconstructs attack flows by traversing the resulting network.
- The resulting evidence chain is represented as a subgraph of the ERN, with data-structure elements changing as evidence arrives.Source: C. Evidence Chain Reasoning · pp. 4–5
- Evidence preprocessing maps extracted attack-flow evidence to corresponding ERN vertices through map().Source: C. Evidence Chain Reasoning · p. 4
- For each time-sequenced evidence item, the algorithm searches earlier evidence for directed ERN links from map(εh) to map(εi).Source: C. Evidence Chain Reasoning · p. 4
- The procedure initializes evidence timestamps, performs association analysis based on a vertex’s in-degree, and generates chains through breadth-first traversal.Source: C. Evidence Chain Reasoning · pp. 4–5
- Vertices with no incoming links become start nodes, while linked parent evidence satisfying the logical expression identifies an intermediate node and records parent pointers.Source: C. Evidence Chain Reasoning · p. 4
D. Timing Independent Evidence Chain Reasoning
The timing-independent algorithm addresses inconsistent evidence timestamps by checking vertex states and applying association analysis across start, intermediate, and virtual-node cases. It then generates the evidence chain from the reconstructed pointers.
- The timing-independent algorithm is proposed because correct conclusions depend on accurate evidence timestamps, which can be inconsistent.Source: D. Timing Independent Evidence Chain… · p. 5
- Each incoming evidence is mapped to an ERN vertex and initialized with its timestamp before vertex-state checking and association analysis.Source: D. Timing Independent Evidence Chain… · p. 5
- When a vertex has no incoming links, the evidence is a start point; when its logical expression is true, it becomes an intermediate node linked to qualifying parents.Source: D. Timing Independent Evidence Chain… · p. 5
- When the logical expression is false, the algorithm searches parent nodes and inserts a virtual record when needed; virtual records represent evidence not acquired by EventTracker and exclude its risk weight.Source: D. Timing Independent Evidence Chain… · p. 5
- The reconstructed chain is generated by breadth-first search from an ERN vertex with in-degree zero.Source: D. Timing Independent Evidence Chain… · p. 5
E. Time Complexity Analysis
The evidence chain reasoning algorithms are analyzed in terms of ERN vertices and links. Both the standard and timing-independent procedures have overall linear complexity in the network size.
- O(N + E) is the overall time complexity of the evidence chain reasoning algorithm, where N and E denote vertices and links.Source: E. Time Complexity Analysis · p. 5
- O(N + E) is also the overall time complexity of the timing-independent algorithm, including virtual-node handling and breadth-first search.Source: E. Time Complexity Analysis · p. 5
F. Power of the evidence chain
The evidence-chain power is evaluated from the risk weights of observed evidence and virtual records. EventTracker supplies the operational basis by monitoring system calls and mapping their dependencies into an ERN.
- The power of an electronic evidence chain is evaluated by summing the risk weights of evidences on that chain.Source: F. Power of the evidence chain · p. 5
- Virtual records indicate evidence not acquired by EventTracker, so their risk weights are excluded from the overall evidence weight used in the confidence calculation.Source: F. Power of the evidence chain · p. 5, Figure 6 · p. 6
- EventTracker monitors system calls because their changes reveal characteristics of program operations and support dynamic security analysis.Source: G. The application of an ERN in… · p. 5
- EventTracker maps system calls and their parameter dependencies into ERN nodes and links to identify complex lateral movement attacks.Source: G. The application of an ERN in… · p. 6
H. Design and implementation of AlertCorrelator
AlertCorrelator preprocesses and correlates distributed NIDS alerts before inserting chronological evidence into the ERN. Its design supports iterative expansion as new NIDS are added, while experiments evaluate implementation and risk weighting.
Alert processing
- AlertCorrelator standardizes, enriches, merges, and chronologically inserts alerts from multiple NIDS as ERN evidence.Timestamps and attacker source addresses are added, and alerts related to one attack are merged into a single alarm.Source: H. Design and implementation of… · p. 6
Scalability
- New NIDS can be incorporated into an existing ERN iteratively, demonstrating AlertCorrelator’s scalability and flexibility.Source: H. Design and implementation of… · p. 6
Implementation
- The prototype EventTracker system uses C on Linux RedHat 7.3, Snort 2.4.3 for attack detection, and Graphviz for evidence-chain visualization.Experiments were conducted on Shuguang servers with a 2.4G CPU and 8G memory.Source: §IV · p. 6
Experimental setup
- Risk weights are evaluated under an assumption of equal exploitation probabilities and equal functional attributes across network nodes.Vulnerability impacts are classified into nine categories for the experiments.Source: A. Parameter Setup · p. 6
B. Reasoning Result of the Lincoln Dataset
EventTracker reconstructs attack evidence chains from the LLDOS and Treasure Hunt datasets. The chains capture multi-stage attack sequences, with the LLDOS1.0 result matching documented attack behavior and Treasure Hunt confidence varying by sub-network.
LLDOS datasets
- The LLDOS experiments use datasets containing external, internal, and DMZ hosts across Windows, Linux RedHat, SunOS, and Solaris systems.Each dataset produced an intranet data set of 179 MB.Source: B. Reasoning Result of the Lincoln… · p. 6
- The LLDOS1.0 evidence chain identifies five attack phases, from network scanning through exploitation, privilege gain, backdoor installation, and DDoS launch.Source: B. Reasoning Result of the Lincoln… · pp. 6–7
- The LLDOS1.0 chain matches MIT Lincoln documentation and reaches 100% confidence because there are no virtual records.Source: B. Reasoning Result of the Lincoln… · p. 7
- The LLDOS2.0.2 chain contains a complete, more complex and latent springboard attack sequence involving Sadmind exploitation and root-privilege acquisition.Source: B. Reasoning Result of the Lincoln… · p. 7
D. Performance Analysis
CloudSEC is evaluated for processing capacity and deployment suitability in edge-cloud environments. It handles about 100 evidence chains per second, exceeding reported detection-point event requirements, while the conclusion reports linear-time reasoning algorithms.
Processing performance
- Around 100 evidence chains per second can be handled by CloudSEC, greatly exceeding reported current detection-point processing requirements.The cited comparison is approximately 10–20,000 security events per day per detection point.Source: D. Performance Analysis · p. 7
Deployment suitability
- Under real-time lateral-movement reasoning conditions, the reported processing performance is suitable for edge-cloud deployment.Source: D. Performance Analysis · p. 8
Computational analysis
- Both CloudSEC chain-reasoning algorithms achieve linear time complexity according to the paper’s theoretical analysis.Source: §V · p. 8