1. Introduction — Why “Single-Device Logs” Are Not Enough #

In security log monitoring operations, judgments about “a particular IP address being suspicious” are typically made independently from the logs of individual devices.

• FW scanning multiple ports → Block
• Web server receiving vulnerability scans → Alert
• VPN authentication failures repeated multiple times → Account lock

Each device makes decisions individually. This is standard operations.

However, actual attacks are far more organized and operate across layers in a coordinated scenario.

For example, suppose an attacker attempts intrusion using the following sequence.

1. Reconnaissance via FW (port scan)           ← L1 Network Layer
2. Vulnerability scan on public web port       ← L4 Application Layer
3. Brute force against SSH or VPN              ← L3 Authentication Layer
4. After intrusion, lateral movement in internal network  ← L5 Endpoint Layer

If individual devices detect this separately, each incident appears to be merely “slightly suspicious isolated behavior.” The FW team thinks “just another routine scan,” the web server team thinks “just another scanner,” and the VPN team thinks “another brute force attempt,” responding separately.

However, these four activities represent a single attacker’s consecutive actions. When viewed as a continuous scenario, the response priority, blocking scope, and alert level all change dramatically.

BASTION’s multi-layer correlation campaign detection is a mechanism that “overlays individual detections from multiple devices across time and layers, using a single IP as the axis”. In this article, I will explain its design philosophy and mechanism, excluding the mathematical formulas under patent application preparation.

2. The Concept of “Layers” — Organizing Logs from Five Perspectives #

BASTION organizes logs into the following five “layers”.

This layer classification is not a mechanical device classification but a classification that maps to “attack progression stages”. L1 involves reconnaissance, L2 path exploration, L3 authentication breach, L4 application vulnerabilities, and L5 internal activity. Generally, attack progression moves up through the layers.

The fact that “a particular attack IP is observed across multiple layers” is a strong indicator that “the attack is progressing to the next stage”.

3. trace-registry — Aggregating Cross-Layer Observation Status by IP #

During log analysis from each device, BASTION accumulates “when this IP was observed, at which layer, and how many times”. This is called trace-registry.

Conceptually, the structure looks like this (actual values are samples).

{
  "traces": {
    "203.0.113.42": {
      "layers": {
        "L1_network": {
          "first_seen": "2026-05-10T13:01:23+09:00",
          "last_seen":  "2026-05-10T13:42:11+09:00",
          "count": 47,
          "context": ["FW block: port_scan", "FW block: ssh_attempt"]
        },
        "L4_app": {
          "first_seen": "2026-05-10T13:35:08+09:00",
          "last_seen":  "2026-05-10T13:41:55+09:00",
          "count": 12,
          "context": ["webserver 404: vuln_scan", "webserver 403: forbidden_path"]
        }
      },
      "layer_count": 2,
      "total_count": 59
    }
  }
}

The key point of this structure is that it aggregates by “layer” rather than by “device”. If multiple FW units exist, they are all treated as L1 Network Layer. Conversely, if a single server outputs both Apache (L4) and auditd (L5) logs, this is treated as signals from two layers.

Furthermore, observations in each layer are recorded along a time axis at a granularity that makes attack progression readable.

4. Coherence Function — Quantifying “Cross-Layer Coordination” #

Here we reach the core of BASTION.

The mere fact that “an IP is observed across multiple layers” does not yet constitute a campaign. It might be observed in both L1 and L4, but the two could be temporally independent and unrelated behaviors.

Therefore, we define a function that evaluates “cross-layer coordination” numerically. This is called the coherence function C(i,t).

This function conceptually combines four elements.

1. Strength of cross-layer coupling — Which layers were observed simultaneously
2. Temporal proximity — How close the observation timing is
3. Amplitude of observations — The extent of observations in each layer (count)
4. Decoherence (temporal decay) — Older observations have diminished influence

The specific mathematical form (cross-layer coupling matrix K_ℓk, decay rate γ, amplitude term Φ, etc.) is non-public due to patent application preparation, but conceptually it takes the form:

C(i,t) = function of "cross-layer coupling × temporal proximity × observation amplitude × temporal decay"

C(i,t) takes a value between 0 and 1. The larger the value, the higher the likelihood that the IP’s behavior is “coordinated across layers”.

5. Campaign Determination — Automatic Action on Threshold Exceedance #

After calculating C(i,t) for each IP, those exceeding the threshold are judged as “attack campaign in progress”.

Important design decisions here:

1. Judgment is deterministic: Whether coherence value exceeds the threshold is judged mechanically. We do not rely on LLM inference
2. Thresholds are adjustable per environment: Default values are determined from internal proof-of-concept, but can be fine-tuned for customer environments
3. Judgment reasoning is explainable: All output shows “which layers were observed how many times, therefore the campaign was determined”

Example of judgment reasoning output (values are masked):

[COHERENCE_CAMPAIGN] ip=203.0.113.42  C=███
  L1_network: count=███ first=████ last=████
  L4_app:     count=███ first=████ last=████
  reason: layer_count=2 + coherence > threshold

Since the determination basis is explicitly shown, operators can confirm the observed facts themselves and approve automated defense based on understanding, rather than trusting AI’s black-box judgment.

6. Entanglement — Detecting “Coordination as a Group” #

So far, we have examined whether “a single IP is coordinated across multiple layers”. This alone is powerful, but real-world attacks are even more sophisticated.

For example, organized vulnerability scanning using multiple IPs on cloud providers. Each IP individually shows too low frequency to exceed campaign detection threshold, but when aggregated across an entire subnet or ASN, the activity clearly becomes organized.

Therefore, BASTION has a mechanism to “evaluate IPs in group units”.

• Grouping by subnet — IP groups in the same /24 are treated as one set
• Grouping by ASN — IP groups in the same ASN are treated as one set

For each group, we calculate group coherence (GC). GC is the aggregated coherence values of each member IP, multiplied by a boost coefficient based on group size.

The specific mathematical form is also non-public, but the concept is simple:

GC = Σ C(i,t) × boost(group_size)

A group composed of 10 IPs has higher probability of “organized attack” than one with 3 IPs, so the boost takes effect.

This mechanism is called entanglement detection. This too borrows a term from quantum physics, expressing the notion that “signals individually small can collectively carry strong significance when viewed as a group” in a mathematical model.

7. Real Operations Detection Example (Anonymized) #

Here is an example of a group captured by entanglement detection in our internal production environment (as of May 2026), with IPs and organization names masked.

[ENTANGLEMENT_CAMPAIGN] type=asn group=AS█████  size=17  GC=███
  Member IPs: ████.██.██.███,  ████.███.██.██,  ███.███.███.███, ... (17 items)
  Observed layers: L1_network (FW block), L4_app (vuln scan)
  Time window: 24 hours
  Action: All 17 IPs auto-blocked across boundary FW + DMZ Agents

This is a case where organized activity was observed across 2 layers (FW scanning and web vulnerability scanning) from 17 IPs of a major cloud provider within 24 hours. Each individual IP showed insufficient volume to trigger campaign detection with conventional SIEM, but as a group, the activity clearly indicated intentional activity.

After detection, all 17 IPs were simultaneously propagated and blocked across the boundary FW and public server-side DMZ Agent groups (cascade defense; detailed in a separate article to be published).

8. Why This Differs from SIEM/SOAR #

Conventional SIEM or SOAR can actually achieve “combined detection judgments from multiple devices” by writing correlation rules. So what is different?

The greatest difference is that “it can detect unknown scenarios”. SIEM misses attacks not written in its rules. Multi-layer correlation examines a universal characteristic of cross-layer coordination, so it adapts to new attack methods.

9. Design Tradeoffs #

To be candid, this mechanism has several tradeoffs.

1. Computational Cost: Computing C(i,t) for all IPs increases processing time as the number of observed IPs grows. BASTION mitigates this by limiting calculations to recent active IPs recorded in trace-registry.

2. Threshold Adjustment: Lowering the threshold increases false positives; raising it increases misses. This is environment-dependent, and the safe approach is to initially set it conservatively high and lower it gradually with observation.

3. False Negatives for Known IPs: IPs on whitelists (own servers, business partners, CDNs, etc.) must be excluded from judgment. This is managed through a separate mechanism.

4. Large Cloud ASN Characteristics: Large-scale ASNs like AWS or Microsoft include many legitimate users. Even if entanglement detection shows large group sizes, they should not be immediately blocked; they are safely constrained by CAP (maximum blocked IPs per group).

These were recognized at the design stage and appropriate countermeasures are in place. One of BASTION’s design principles is “safety envelope” — always incorporating mechanisms to physically limit damage if something runs out of control.

10. Future Development #

The multi-layer correlation engine itself has reached adequate operational maturity, but there remains room for improvement.

• Adaptive Thresholds: Automatically adjust thresholds by learning environment normal levels (Phase 4 vision)
• Time-of-Day Sensitivity Adjustment: Apply different sensitivity during nighttime versus business hours
• Health Coherence: Apply the model not only to attack detection but to detecting internal system malfunctions using biological models
• ASN Trust Score: Calculate trust levels for each cloud ASN based on past behavior

These will be implemented sequentially.