지식
Security

보안 모니터링과 SIEM: 공격을 탐지하는 관측 체계

SIEM의 수집·정규화·상관분석·대응 파이프라인, 로그 상관분석으로 공격 시퀀스를 탐지하는 원리, 탐지 룰과 UEBA, SOAR 자동화, 평균 탐지 시간(MTTD)을 줄이는 모니터링 전략을 다룹니다.

· 10 min read · PALDYN Team

지난 글에서 외부 연구자와 협력해 취약점을 사전에 발견하는 체계를 다뤘다. 하지만 모든 취약점을 사전에 막는 것은 불가능하다. 공격은 결국 일어나고, 중요한 질문은 “뚫렸는가”가 아니라 “뚫렸다는 사실을 얼마나 빨리 아는가”가 된다. IBM의 침해 비용 보고서에 따르면 침해를 식별하는 데 평균 200일 안팎이 걸린다. 이 시간을 줄이는 일, 즉 공격을 탐지하는 관측 체계가 이번 글의 주제다.

왜 로그만으로는 부족한가

모든 시스템은 로그를 남긴다. 웹 서버 액세스 로그, 인증 로그, WAF 로그, 클라우드 감사 로그. 문제는 이것들이 서로 다른 장소에, 서로 다른 형식으로, 거대한 양으로 흩어져 있다는 것이다. 침해의 흔적은 분명 그 안에 있지만, 사람이 수동으로 발견하기란 거의 불가능하다.

더 근본적인 문제가 있다. 개별 로그 한 줄은 거의 항상 무해해 보인다. 로그인 실패 한 번, 권한 변경 한 번, 대용량 다운로드 한 번 — 각각은 정상 운영에서도 매일 수천 번 일어난다. 공격은 이 평범한 이벤트들이 특정 순서와 맥락으로 연결될 때 비로소 드러난다.

상관분석이 잡아내는 공격 시퀀스

위 시퀀스를 보자. 로그인 100회 실패는 흔한 브루트포스 노이즈다. 그 직후의 로그인 성공도 정상으로 보인다. 권한 승격도 운영에서 일어나는 일이고, 대용량 전송도 백업일 수 있다. 그러나 같은 IP·계정으로 4분 안에 이 순서대로 일어났다면, 이것은 크리덴셜 스터핑 성공 → 권한 상승 → 데이터 유출이라는 명백한 침해 시나리오다. 흩어진 로그를 모아 시간 축으로 잇는 것 — 이것이 SIEM의 존재 이유다.

SIEM이란

SIEM(Security Information and Event Management)은 여러 소스의 보안 로그를 한곳에 모아 정규화하고, 상관분석으로 위협을 탐지하며, 경보와 대응을 연결하는 플랫폼이다. 파이프라인으로 보면 네 단계다.

SIEM 파이프라인

1) 수집(Collection). 애플리케이션·WAF·방화벽·인증·OS·클라우드 등 모든 소스의 로그를 중앙으로 모은다. 핵심 원칙은 로그를 발생 시스템과 분리된 곳에 보관하는 것이다. 공격자가 침투한 서버의 로컬 로그는 가장 먼저 삭제·변조되기 때문이다.

2) 정규화(Normalization)와 보강(Enrichment). 제각각인 로그 형식을 공통 스키마로 변환하고 타임스탬프를 정렬한다. 여기에 컨텍스트를 덧붙인다 — IP에 지리정보와 위협 인텔리전스(알려진 악성 IP인가)를 태깅하고, 사용자 ID에 부서·권한 정보를 연결한다. 보강이 잘 될수록 탐지 정확도가 올라간다.

3) 상관분석(Correlation)과 탐지(Detection). 모아진 데이터에 탐지 로직을 적용한다.

  • 시그니처/룰 기반: “5분 내 동일 IP 로그인 실패 50회 이상” 같은 명시적 규칙
  • 임계치/빈도 분석: 평소 대비 비정상적인 양과 속도
  • 행위 기반 이상탐지(UEBA): 사용자·엔티티의 평소 패턴을 학습하고 벗어남을 탐지. “이 계정이 새벽 3시에, 처음 보는 국가에서, 평소 안 쓰던 시스템에 접근”

4) 알림과 대응(Alert & Response). 탐지된 위협을 대시보드에 띄우고 담당자(SOC, 온콜)에게 알린다. 성숙한 조직은 SOAR(Security Orchestration, Automation and Response)로 일부 대응을 자동화한다 — 의심 IP 자동 차단, 계정 잠금, 세션 강제 종료 등.

탐지 룰의 예

SIEM 룰은 결국 “이런 조건이 맞으면 경보”라는 논리다. 대표적인 룰을 의사코드로 표현하면 이렇다.

-- 크리덴셜 스터핑 성공 의심: 다수 실패 직후 성공
SELECT src_ip, user_id, COUNT(*) AS failures
FROM auth_events
WHERE result = 'FAIL'
  AND timestamp > NOW() - INTERVAL '5 minutes'
GROUP BY src_ip, user_id
HAVING COUNT(*) >= 20
   AND EXISTS (
     SELECT 1 FROM auth_events s
     WHERE s.src_ip = auth_events.src_ip
       AND s.result = 'SUCCESS'
       AND s.timestamp > NOW() - INTERVAL '1 minute'
   );

실무에서는 이런 룰을 직접 짜기보다, 공개된 탐지 룰 라이브러리를 활용한다. Sigma는 SIEM 제품에 종속되지 않는 표준 탐지 룰 포맷으로, 한 번 작성하면 여러 SIEM으로 변환할 수 있다. MITRE ATT&CK 프레임워크는 실제 공격자의 전술·기법을 분류해 둔 지식 베이스로, “우리 탐지 룰이 어떤 공격 기법을 커버하는가”를 점검하는 지도로 쓰인다.

무엇을 로그로 남겨야 하는가

SIEM이 아무리 좋아도 입력 로그가 부실하면 소용없다. 탐지에 필요한 핵심 이벤트는 빠짐없이 남겨야 한다.

반드시 로깅          : 인증 성공/실패, 권한 변경, 접근 거부,
                      관리자 행위, 결제·주문 등 핵심 비즈니스 이벤트
함께 기록할 컨텍스트  : 타임스탬프(UTC), 사용자 ID, 소스 IP,
                      요청 경로, 결과 코드, 상관 추적 ID
절대 로깅 금지        : 비밀번호, 토큰, 카드번호, 주민번호 등
                      민감 정보 (로그 자체가 유출 자산이 된다)

마지막 항목이 중요하다. 보안을 위한 로그가 오히려 민감 정보 유출의 통로가 되어선 안 된다. 이 “무엇을 어떻게 안전하게 로깅하는가”는 별도 주제로 다룰 만큼 중요해서, 다음 글에서 보안 감사 로깅으로 자세히 살펴본다.

흔한 함정

  • 경보 피로(Alert Fatigue): SAST 오탐 문제와 똑같다. 경보가 너무 많으면 SOC는 곧 모든 경보를 무시한다. 룰 튜닝과 우선순위 분류가 탐지율만큼 중요하다.
  • 모으기만 하고 보지 않기: 비싼 SIEM을 도입해 로그를 다 모았는데, 탐지 룰도 없고 보는 사람도 없는 경우가 흔하다. SIEM은 도구일 뿐, 운영 프로세스(SOC, 온콜, 룰 관리)가 없으면 비싼 로그 저장소에 불과하다.
  • 시간 동기화 누락: 소스마다 시계가 어긋나면 상관분석이 무너진다. 모든 시스템의 NTP 동기화와 UTC 기준 타임스탬프가 전제 조건이다.
  • 로그 보관 기간 부족: 침해는 평균 수개월 뒤 발견된다. 그때 분석할 로그가 이미 삭제됐다면 사후 조사가 불가능하다.

작게 시작하기

대기업의 SOC를 처음부터 흉내 낼 필요는 없다. 오픈소스로도 충분히 시작할 수 있다.

  • 로그 수집·검색: ELK/OpenSearch 스택, Grafana Loki
  • 탐지·룰 엔진: Wazuh(엔드포인트+SIEM 통합), Sigma 룰셋
  • 클라우드 네이티브: AWS GuardDuty, GCP Security Command Center처럼 관리형 탐지부터

우선순위는 명확하다. 먼저 핵심 인증·권한 이벤트를 빠짐없이 안전하게 로깅하고, 그다음 가장 위험한 시나리오(계정 탈취, 권한 상승, 대량 데이터 접근) 몇 개에 대한 탐지 룰부터 만든다.

탐지는 사고 대응의 출발점이다. 경보가 울린 뒤 무엇을 어떤 순서로 해야 하는가 — 다음 글에서는 탐지 이후의 체계, 침해사고 대응(Incident Response)을 다룬다.

지난 글: 버그 바운티와 취약점 공개: 외부 연구자와 협력하는 법

다음 글: 침해사고 대응: 탐지부터 복구까지의 IR 프로세스


읽어주셔서 감사합니다. 😊