24. SIEM 구축 전에 로그 소스와 아키텍처를 결정할 때 보는 기준

SIEM(Security Information and Event Management)은
결국 로그를 얼마나 잘 모으고, 정규화하고, 상관분석하느냐의 문제다.

실제 구축 프로젝트를 진행해 보면
솔루션 선택 이전에 로그 소스와 수집 구조를 어떻게 설계하느냐가
운영 난이도와 탐지 품질을 거의 다 좌우한다.

여기서는 SIEM 도입을 고민할 때
실무에서 자주 체크했던 기준들을 정리해 본다.

EPS보다 중요한 것, 어떤 이벤트를 언제까지 보관할 것인가

SIEM 제안서를 받아보면 항상 EPS(Events Per Second) 숫자가 먼저 나온다.
하지만 실제로는 EPS 총량보다
어떤 이벤트를 얼마나 오래 보관해야 하는지가 더 중요했다.

실무에서 먼저 정리했던 항목은 다음과 같다.

• 규제·감사 요구사항:
  인증 로그, 중요 시스템 접근 로그를 몇 개월 또는 몇 년 보관해야 하는지
• 사고 대응 관점:
  침해사고 발생 시 거슬러 올라가서 보고 싶은 기간이 어느 정도인지
• 스토리지와 예산:
  원본 로그와 정규화된 이벤트를 동일 기간 보관할지,
  롤업(집계) 정책을 적용할지

이 세 가지를 맞춰놓고 나면
EPS 계산도 훨씬 현실적으로 떨어진다.
단순히 “우리 회사는 10,000 EPS면 충분하다더라”가 아니라
“이 정도 소스를 이 기간만큼 보관하려면 어느 정도 스펙이 필요하다”로 바꿔야
나중에 증설이나 튜닝을 설명하기도 편했다.

에이전트 vs 에이전트리스, syslog와 API 수집의 조합

로그 수집 방식도 처음에 정리를 해 두는 편이 좋았다.

• 서버·보안장비:
  대부분 syslog 기반 수집이 기본이지만,
  파일 로그 tailing, Windows Event Forwarding,
  전용 에이전트 방식도 함께 검토한다.
• SaaS·클라우드 서비스:
  REST API, webhook 기반 수집이 늘고 있으며
  주기적 pull 방식과 실시간 push 방식을 혼합해서 설계한다.
• 애플리케이션 로그:
  로깅 프레임워크(Logback, Log4j 등)를 통해
  공통 포맷(JSON 등)으로 출력하도록 개발팀과 협의해 두면
  이후 파서(parser) 작성 비용이 크게 줄어든다.

에이전트 방식은 세밀한 제어와 보안 채널 구성이 장점이고,
에이전트리스 방식(syslog, WMI 등)은 도입 장벽이 낮다.
실제 구축에서는 중요 서버·코어 시스템에는 에이전트,
그 외 장비는 syslog 위주로 혼합해서 사용하는 패턴이 많았다.

정규화와 파서 설계: 필드 체계를 먼저 잡아야 상관분석이 산다

SIEM에서 상관분석(correlation rule), 대시보드, UEBA(User and Entity Behavior Analytics)를 제대로 쓰려면
이벤트 정규화(normalization)가 선행되어야 한다.

실무에서는 아래 정도의 공통 필드를 먼저 정의했다.

• 타임스탬프, 호스트명, IP, 사용자 ID, 프로세스명
• 이벤트 카테고리(auth, access, system, application, network 등)
• 결과(success/fail), 심각도(severity), 결과 코드

이 필드 체계를 정해 두고
각 로그 소스별로 파서를 설계하면
서로 다른 장비에서 온 이벤트라도
공통 축으로 분석이 가능해진다.

파서 품질이 떨어지면
같은 로그인 실패 이벤트가
장비마다 제각각으로 들어오고,
규칙을 장비별로 따로 만들어야 해서
운영 비용이 급격히 올라간다.

탐지 시나리오와 유즈케이스를 먼저 정리하기

SIEM 구축 프로젝트에서 가장 아쉬웠던 사례 중 하나는
“솔루션은 들어왔는데 정작 돌려볼 유즈케이스가 없었던 경우”였다.

그래서 가능하면 도입 초기 단계에
다음 항목을 리스트업했다.

• 계정 탈취 의심:
  짧은 시간 내 다수 로그인 실패,
  지리적으로 불가능한 위치에서의 연속 로그인 등
• 권한 오남용:
  관리자 계정의 심야 시간대 설정 변경,
  평소 사용하지 않던 리소스에 대한 대규모 접근 등
• 악성코드·C2 통신 징후:
  EDR, 프록시, DNS 로그를 결합한 상관 분석 룰
• 데이터 유출 의심:
  DLP, 프록시, 이메일 게이트웨이 로그 조합

이렇게 유즈케이스를 먼저 정의하면
필요한 로그 소스, 정규화 항목, 보관 기간이 역으로 도출된다.
또한 MTTD, MTTR 같은 관점에서
“탐지까지 걸리는 시간”을 줄이는 대상을 정리하는 데도 도움이 됐다.

운영 가능한 범위인지, SOC 인력과 프로세스까지 같이 보는 시각

마지막으로, 기술 설계와 별개로
“이 SIEM을 실제로 돌릴 사람과 프로세스가 준비되어 있는가”를
냉정하게 보는 것도 필요했다.

• 온콜/당직 체계
• 알람 티켓 발행 및 인시던트 대응 플로우
• 룰 튜닝 및 주기적 리포트 작성
• 운영 자동화(Playbook, SOAR 연계 여부)

SIEM은 도입 자체보다
운영 중 룰을 끊임없이 다듬고
노이즈를 줄이는 작업이 더 중요했다.
결국 SOC 인력과 대응 프로세스까지 맞춰야
솔루션이 “화면만 예쁜 제품”이 아니라
실제 탐지·대응 체계로 자리 잡는다고 느꼈다.