1. 들어가며 — 왜 「단일 장비의 로그」로는 충분하지 않은가 #

보안 로그 모니터링 현장에서는 「특정 IP 주소가 의심스럽다」는 판단을 대부분 개별 장비의 로그만으로 내립니다.

• 방화벽에서 다수의 포트를 스캔하고 있음 → 차단
• 웹 서버에서 취약점 스캔이 감지됨 → 경고
• VPN 인증에 여러 번 실패함 → 계정 잠금

각 장비가 개별적으로 판단합니다. 이것이 일반적인 운영입니다.

하지만, 실제 공격은 훨씬 조직적이며, 계층을 넘나드는 시나리오로 작동합니다.

예를 들어, 어떤 공격자가 다음 절차로 침입을 시도하고 있다고 가정합니다.

1. FW에서 정찰(포트 스캔) 수행          ← L1 네트워크 계층
2. 공개된 Web 포트에 취약점 스캔        ← L4 애플리케이션 계층
3. SSH나 VPN으로 무차별 대입 공격       ← L3 인증 계층
4. 침입 후 내부 네트워크로 측면 이동    ← L5 엔드포인트 계층

이를 개별 장비가 각각 탐지하더라도, 각각은 「약간 의심스러운 단독 행동」으로만 보입니다. 방화벽 담당자는 「평소의 스캔이군」, 웹 서버 담당자는 「평소의 스캐너군」, VPN 담당자는 「또 무차별 대입 시도군」이라고 판단하여 각각 별도로 대응합니다.

하지만 이 4가지는 같은 공격자의 연속된 행동입니다. 일련의 시나리오로 보면 대응 우선순위, 차단 범위, 경계 수준이 완전히 달라집니다.

BASTION의 다층 상관 캠페인 탐지는 「여러 장비의 개별 탐지를 동일 IP를 축으로 시간과 계층으로 중첩시키는」 구조입니다. 본 기사에서는 특허 출원 준비 중으로 비공개인 수식 부분을 제외하고 그 설계 사상과 구조를 해설합니다.

2. 「계층」이라는 개념 — 로그를 5가지 관점으로 정리한다 #

BASTION은 로그를 다음 5가지 「계층」으로 정리합니다.

이 계층 분류는 기계적인 장비 분류가 아니라 「공격의 진행 단계」에 대응하는 분류입니다. L1에서 정찰, L2에서 경로 탐색, L3에서 인증 돌파, L4에서 앱 취약점, L5에서 내부 활동, 이런 식으로 공격의 진행은 대체로 계층을 올라갑니다.

「특정 공격 IP가 여러 계층에서 관측된다」는 사실은 「공격이 다음 단계로 진행하고 있다」는 강력한 징후입니다.

3. trace-registry — IP별로 계층을 넘나드는 관측 상황을 집계한다 #

BASTION은 각 장비의 로그를 분석하는 과정에서 「이 IP가 언제, 어느 계층에서, 몇 번 관측되었는가」를 축적합니다. 이를 trace-registry라고 부릅니다.

개념적으로는 다음과 같은 구조입니다(실제 값은 샘플).

{
  "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
    }
  }
}

이 구조의 핵심은 「장비」가 아닌 「계층」으로 집계한다는 점입니다. 같은 방화벽 제품이 여러 대 있어도 모두 L1 네트워크 계층으로 처리됩니다. 반대로 1대의 서버가 Apache(L4)와 auditd(L5)의 로그를 모두 생성하면 2개 계층의 신호로 처리됩니다.

그리고 각 계층에 대한 관측이 시간축과 함께 기록됩니다. 공격의 진행을 읽을 수 있는 입도입니다.

4. 코히어런스 함수 — 「계층을 넘나드는 협조성」을 수치화한다 #

여기서부터가 BASTION의 핵심 부분입니다.

「특정 IP가 여러 계층에서 관측되고 있다」는 사실만으로는 아직 캠페인이라고 할 수 없습니다. 우연히 L1과 L4에서 관측되었지만 둘은 시간적으로 독립적이고 관련 없는 행동일 수 있습니다.

따라서 「계층 간 협조성」을 수치로 평가하는 함수를 정의합니다. 이를 코히어런스 함수 C(i,t)라고 부릅니다.

이 함수는 개념적으로 다음 4가지 요소를 결합합니다.

1. 계층 간 결합 강도 — 어느 계층과 어느 계층이 동시에 관측되었는가
2. 시간적 근접성 — 관측 타이밍이 얼마나 가까운가
3. 관측의 진폭 — 각 계층에서의 관측량(count)이 어느 정도인가
4. 디코히어런스(시간 감쇠) — 오래된 관측은 영향을 약화시킨다

구체적인 수식 형태(층간 결합 행렬 K_ℓk, 감쇠율 γ, 진폭항 Φ 등)는 특허 출원 준비 중이므로 비공개이지만, 개념적으로는:

C(i,t) = "층간 결합 × 시간적 근접성 × 관측 진폭 × 시간 감쇠"의 함수

라는 형태를 가지고 있습니다.

C(i,t)는 0에서 1 범위의 값을 가집니다. 값이 클수록 해당 IP의 행동이 “층을 넘나들며 협조하고 있을” 가능성이 높다고 판단할 수 있습니다.

5. 캠페인 판정 — 임계값 초과로 자동 행동 #

각 IP에 대해 C(i,t)를 계산한 결과, 임계값을 초과한 것을 “공격 캠페인 진행 중”으로 판정합니다.

여기서 중요한 설계 판단:

1. 판정은 결정론적: 코히어런스 값이 임계값을 초과했는지 여부로 기계적으로 판정한다. LLM의 추론에 의존하지 않는다
2. 임계값은 환경별로 조정 가능: 기본값은 사내 실증으로 정한 값이지만, 고객 환경에 맞춰 미세 조정할 수 있다
3. 판정 이유가 설명 가능: “어느 층에서 얼마나 관측되었기 때문에 캠페인으로 판정했는지”를 모두 출력한다

판정 이유 출력 예시(값은 마스킹):

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

판정 근거가 명시되어 있으므로, 운영자는 AI의 블랙박스 판단을 신뢰하는 것이 아니라, 관측 사실 그 자체를 확인하고 납득한 후자동 방어를 허가할 수 있습니다.

6. 엔탱글먼트 — “그룹으로서의 협조”를 검지하는 #

여기까지는 “1개의 IP가, 복수 층에서협조하고 있는가”를 살펴봤습니다. 이것만으로도 강력하지만, 실제 공격은 더 교묘합니다.

예를 들어 클라우드 프로바이더 상의 복수 IP를 사용한 조직적인 취약점 스캔. 각 IP 단독으로는 빈도가 너무 낮아 캠페인 판정의 임계값을 초과하지 않지만, 서브넷 전체나 ASN 전체로 집계하면 명확히 조직적인 활동이 되는 케이스입니다.

따라서 BASTION은 “IP를 그룹 단위로 평가하는”기구를 가지고 있습니다.

• 서브넷 단위 그룹화 — 동일 /24에 속하는 IP 그룹을 하나의 집합으로 취급
• ASN 단위 그룹화 — 동일 ASN에 속하는 IP 그룹을 하나의 집합으로 취급

각 그룹에 대해 그룹 코히어런스(GC)를 계산합니다. GC는 각 멤버 IP의 코히어런스 값을 집약한 것에 그룹 크기에 의한 부스트 계수를 곱한 값입니다.

이것도 수식의 구체적 형태는 비공개이지만, 개념은 단순합니다:

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

3개 IP로 구성된 그룹보다 10개 IP로 구성된 그룹이 “조직적 공격”의 개연성이 높으므로, boost가 효과를 발휘합니다.

이 기구를 엔탱글먼트(얽힘) 검지라고 부르고 있습니다. 이것도 양자 물리학 용어에서 차용한 것으로, “개별로는 작은 신호라도, 그룹으로 보면 강한 의미를 갖는” 현상을 수학적으로 모델화한 것입니다.

7. 실제 운용에서의 검출 예(익명화) #

사내 프로덕션 환경에서 엔탱글먼트 검지가 포착한 그룹의 예(2026년 5월 시점)를 IP/조직명을 숨기고 소개합니다.

[ENTANGLEMENT_CAMPAIGN] type=asn group=AS█████  size=17  GC=███
  Member IPs: ████.██.██.███,  ████.███.██.██,  ███.███.███.███, ... (17건)
  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

이것은 대형 클라우드 프로바이더의 17개 IP에서 24시간 이내에 2개 층(FW 스캔과 Web 취약점 스캔)에서 조직적인 활동이 관측된 케이스입니다. 1개 IP 단독으로는 대단한 양이 아니며, 기존 SIEM으로는 검지할 수 없는 수준이지만, 그룹으로 보면 명확한 의도를 가진 활동이었습니다.

검지 후 17개 IP 전부를 경계 FW와 공개 서버 측 DMZ Agent 그룹에 동시에 전파하여 차단했습니다(캐스케이드 방어. 이는 별도 기사에서 자세히 설명 예정).

8. 왜 이것이 SIEM/SOAR와 다른가 #

기존 SIEM이나 SOAR에서도 상관 규칙을 작성하면 “복수 기기의 검지를 조합한 판정” 자체는 실현할 수 있습니다. 그렇다면 무엇이 다를까요?

가장 큰 차이는 “미지의 시나리오도 검출할 수 있다”는 점입니다. SIEM은 규칙에 작성되지 않은 공격은 놓칩니다. 다층 상관은 층간 협조성이라는 보편적인 특성을 보기 때문에 새로운 공격 수법에도 대응할 수 있습니다.

9. 설계상의 트레이드오프 #

솔직하게 말하면, 이 구조에는 몇 가지 트레이드오프가 있습니다.

1. 계산 비용: 모든 IP에 대해 C(i,t)를 계산하므로 관측 IP 수가 많으면 처리 시간이 증가합니다. BASTION은 trace-registry에 기록된 최근 활동 IP로 한정하여 계산함으로써 이 문제를 완화합니다.

2. 임계값 조정: 임계값을 낮추면 오탐이 증가하고, 높이면 미탐이 증가합니다. 이는 환경에 따라 다르며, 초기에는 보수적으로 높게 설정하고 관찰하면서 낮추는 것이 안전합니다.

3. 알려진 IP의 위음성: 화이트리스트에 등록된 IP(자사 서버, 거래처, CDN 등)는 판정 대상에서 제외해야 합니다. 이는 별도의 메커니즘으로 관리합니다.

4. 클라우드 ASN의 특성: AWS나 Microsoft와 같은 대규모 ASN은 정상 사용자도 다수 포함합니다. 엔탱글먼트 탐지에서 큰 그룹 크기가 나타나더라도 즉시 차단하지 않고, CAP(그룹당 최대 차단 IP 수)로 안전하게 제약합니다.

이러한 사항들은 설계 초기 단계부터 인식하고 있었으며, 각각에 대한 대책을 마련했습니다. BASTION의 설계 원칙 중 하나인 “안전 포락선”이 있으며, 무언가 폭주했을 때 물리적으로 피해를 제한하는 메커니즘을 항상 내장합니다.

10. 향후 발전 #

다층 상관 엔진 자체는 충분히 실용 수준에 도달했지만, 더 개선할 여지가 있습니다.

• 적응형 임계값: 환경의 정상 수준을 학습하여 임계값을 자동 조정(Phase 4 구상)
• 시간대별 감도 조정: 심야와 업무 시간에 서로 다른 감도 적용
• 건전성 코히어런스: 공격 탐지뿐만 아니라 내부 시스템의 이상을 생물학적 모델로 탐지하는 응용
• ASN 신용 점수: 클라우드 ASN별로 과거 행동으로부터 신뢰도 산출

이러한 기능들은 순차적으로 구현할 예정입니다.