이번 3주차에서는 프로젝트의 실무적인 기준이 될 분석 방향을 정립하였습니다. 이전까지는 Tetragon 정책 설계와 로그 분석 기법 두 가지 파트로 인원을 분담하여 운영하였으나, 본 프로젝트의 핵심 주제인 “네트워크 포렌식”에 더욱 집중하기 위해 로그 분석 기법 담당 인원들이 우선적으로 Hubble 로그 분석을 수행하는 것으로 변경 사항이 있었습니다.
Tetragon 정책은 MITRE ATT&CK Matrix에 맞춰 공격들을 분류한 후, 각 Technique별로 정책을 설정하도록 하였습니다. 이러한 방식은 OpenSearch 분석 과정에서 설정한 정책별로 탐지된 로그들을 개별적으로 분리하여 가시성을 확보할 수 있다는 이점이 있습니다.
반면 Cilium 및 Hubble은 L7 트래픽 가시성 확보를 위한 정책을 제외하고는 별도의 유의미한 정책 설정보다는, 오로지 트래픽의 이상 징후를 통해서만 분석이 가능하도록 설계하였습니다.
마지막으로 기존 인프라 환경은 각 파드가 독립적으로 배치되어 있었으나, 실제 환경에서 발생할 수 있는 트래픽 노이즈를 구현하기 위해 Web Service, API, DB 파드가 유기적으로 연결될 수 있도록 환경을 새롭게 구축하였습니다.
1. 분석 방향 정립
기존의 분석 방향은 Tetragon 로그와 Hubble 로그를 각각 OpenSearch에서 시각화한 뒤, 식별자들을 대조하여 수동으로 매핑하는 방식이었습니다.
하지만 이는 단순히 공격 과정을 복기하는 리플레이에 가깝다는 한계가 있었습니다.
따라서 저희 팀은 “이상 현상이 발생했고, 그 원인이 무엇이었는가”라는 포렌식 관점을 강화하기 위해, 네트워크 흐름의 이상 징후를 먼저 탐지하고 이를 기점으로 후속 로그 분석을 수행하는 단계적 로그 분석 파이프라인을 설계하였습니다.
설계한 파이프라인의 1차 트리거는 네트워크 관점의 Hubble입니다. 평상시 모든 로그를 분석하지 않고, 사전에 정의한 이상 네트워크 흐름 기준을 위반할 시 Alert가 발생하도록 하였습니다.
Alert에는 시간(Timestamp), 파드 이름(Pod Name), 네임스페이스(Namespace), 트래픽 방향 정보가 포함되어 있으며, 해당 정보는 Tetragon 로그와 연계할 수 있는 입력값으로 활용됩니다.
2차 분석에서는 위 정보를 바탕으로 Tetragon에서 프로세스 및 실행 명령어 로그를 쿼리하여 공격의 실체를 확인하는 구조를 확립하였습니다.
2. Tetragon 정책 현황
Tetragon 정책 수립은 공격 행위를 체계적으로 관리하기 위해 MITRE ATT&CK Matrix를 기준으로 기술들을 분류하는 작업을 선행하였습니다. 분석 시의 정밀도와 가시성을 확보하기 위해 전술(Tactic) 단위가 아닌, 구체적인 기법(Technique)별로 정책을 세분화하였습니다.
정책 설정은 총 3명의 인원이 담당하여 Matrix의 전체 영역을 분담하였습니다. 구체적으로는 다음과 같이 세 영역으로 나누어 정책을 구현하고 있습니다.
- Initial Access / Execution / Persistence
- Privilege Escalation / Defense Evasion / Credential Access
- Discovery / Lateral Movement / Impact
현재까지 주요 기법들에 대한 정책 수립이 완료되었으며, 향후 실제 서비스 통신 중에 발생하는 정상 로그를 정교하게 필터링하여 오탐을 줄이는 노이즈 최적화 과정을 지속할 예정입니다.
3. Hubble 로그 분석 현황
현재 재정립한 로그 분석 파이프라인에 따라 네트워크에서 이상 흐름이 탐지되면 Slack으로 Alert를 전송하기 위해, 이상 징후 탐지를 위한 쿼리 설정 단계에 있습니다.
초기 설계 방향은 개별 공격을 전제로 하지 않고 전체 네트워크 흐름을 하나의 관점에서 바라보며 이상 징후를 탐지하는 것이었습니다. 즉, 특정 공격을 미리 가정하고 로그를 찾는 것이 아니라 네트워크 레벨에서 평소와 다른 흐름이 발생했는지를 기준으로 이상을 감지하고, 그 시점과 대상 파드를 단서로 Tetragon 로그를 역추적하는 구조입니다.
이는 네트워크를 출발점으로 삼는다는 점에서 네트워크 포렌식의 본질적인 문제의식과 가장 부합하는 방향입니다.
하지만 쿼리 설정을 진행한 결과, 단순한 네트워크 이상 흐름 기준만으로는 모든 공격을 포착할 수 없다는 한계가 확인 되었습니다. 예를 들어 네트워크 통신이 거의 없거나 정상적인 트래픽 패턴 내에서 이루어지는 정찰 행위, 내부 정보 수집, 로컬 권한 상승과 같은 공격은 네트워크 레벨에서 뚜렷한 이상으로 나타나지 않을 수 있습니다.
따라서 공격별 네트워크 특징을 정의해 각각에 맞는 쿼리를 작성하는 방안도 검토 중에 있습니다. 이 방식은 탐지율을 높일 수 있으나, 탐지 단계에서 이미 특정 공격에 대한 가정이 들어가게 되어 순수한 네트워크 포렌식 접근과는 다소 거리가 생기게 됩니다.
현재 저희 팀은 이러한 두 가지 접근 방식 사이에서 네트워크 이상 탐지의 역할을 어디까지 정의할 것인지, 그리고 탐지 범위 확보와 포렌식 방법론의 순수성 사이의 트레이드오프를 어떻게 최적화할 것인지에 대해 심도 있게 논의하고 있습니다.
4. 인프라 환경 변경
Tetragon의 네트워크 탐지 정책을 구현하는 과정에서 기존 인프라 구조의 근본적인 한계를 인지하였습니다. 기존처럼 각 파드가 독립적으로만 존재하는 환경에서는 내부 네트워크 통신 탐지 정책을 적용하더라도 서비스 간의 상호작용이 전혀 없기 때문에, 실제 운영 환경에서 직면할 수 있는 오탐 문제가 표면적으로 드러나지 않았습니다.
하지만 파드 간 빈번한 통신이 발생하는 실제 환경이라면 저희가 설정한 정책들이 정상적인 통신까지 위협으로 탐지할 가능성이 높으며, 이를 검증하고 튜닝하기 위해서는 인프라의 재구성이 필수적이라는 결론에 도달하였습니다.
이러한 문제를 해결하고자 인프라 구성을 최대한 실제 환경과 유사하게 전면 수정하기로 결정하였습니다. user-api, order-api, DB, web-service로 구성된 마이크로서비스 환경을 구축하되, 각 서비스가 역할에 따라 서로 다른 트래픽 및 DB 접근 경로를 가지도록 재구성하는 것을 목표로 하였습니다.
React 기반의 SPA(Single Page Application) 취약 서비스 후보를 확정하고 웹 서비스 환경을 재정비하였으며, web → user-api → order-api → DB로 이어지는 서비스 체인의 정상 동작 확인을 완료하였습니다.
보안 설계 측면에서는 RBAC 과도 권한, 평문 시크릿, 평문 통신 등 보안이 취약한 상태를 의도적으로 유지하여 공격 및 탐지 실험이 가능한 기반 환경으로 수정 중에 있습니다.
향후에는 Hubble 및 Tetragon을 활용하여 해당 환경에서 발생하는 대량의 정상 트래픽과 공격 행위를 비교 분석할 예정입니다. 또한 한정된 디스크 용량 문제를 관리하기 위해 DB 데이터 수명 정책을 적용하여 주기적으로 데이터를 삭제하는 실험을 병행할 계획입니다.
결과적으로 이러한 인프라 고도화는 실제 환경에서 발생하는 정상적인 트래픽 노이즈를 구현하고, 그 속에서 공격자의 비정상적 행위를 정교하게 판별할 수 있는 실무적인 포렌식 분석 토대를 마련하였습니다.
