SIEM·ESM·SOAR: 로그 상관분석과 대응 자동화의 연결

1장 개념과 보호 목표#

SIEM은 여러 시스템의 로그와 보안 이벤트를 모아 정규화·검색·상관분석하는 체계입니다. SOAR는 도구를 연결해 대응 절차를 자동화합니다. ESM은 기업 보안 관리에 사용되어 온 표현이며 실제 기능은 제품별로 비교해야 합니다.

2장 원리와 구분#

정확한 분석에는 시간 동기화, 사용자·자산 식별과 로그 누락 감시가 필요합니다. 이벤트가 많다고 탐지 품질이 자동으로 높아지지는 않습니다. 규칙은 위협 시나리오와 조사 가능한 증거로 연결해야 합니다. SOAR 플레이북은 권한, 입력 검증, 실패·재시도와 승인 조건을 갖춰야 합니다.

로그에는 분석에 필요한 정보를 남기되 비밀번호·접근 토큰·민감한 원문을 과도하게 수집하지 않아야 합니다. 공격자가 입력한 문자열이 로그 형식을 깨거나 잘못된 경보를 만들 수 있으므로 수집·정규화 단계도 신뢰 경계로 봅니다. 저장 실패와 수집 지연을 별도 경보로 감시해야 가시성의 공백을 확인할 수 있습니다.

3장 비교와 판단 기준#

구분	핵심 기능	운영 조건
SIEM	수집·정규화·상관분석	로그 품질·탐지 검증
SOAR	도구 연결·대응 절차 자동화	권한·승인·실패·복구
ESM	기업 보안 관리 기능군	제품별 범위 확인
성과 확인	탐지·조사·대응 개선	오탐·시간·재발 여부

4장 수집·분석·대응을 분리한다#

ESM·SIEM·SOAR는 제품마다 기능이 겹치지만 장비 통합 관리, 로그 분석과 대응 자동화라는 역할을 나누어 이해할 수 있습니다. 로그가 한 화면에 보이는 것과 위협을 탐지하고 대응하는 것은 다른 단계입니다.

5장 시간과 식별자가 상관분석을 좌우한다#

시간대, 시계 오차, 사용자·장비 식별자와 원본 이벤트 시간을 일관되게 처리합니다. NAT나 프록시 뒤의 IP 주소만으로 사용자와 행위를 확정하지 않습니다. 요청 식별자와 인증 정보를 연결할 수 있어야 합니다.

6장 이벤트의 발생 시간과 수집 시간#

늦게 들어온 이벤트를 수집 시각만으로 정렬하면 공격의 순서가 달라 보일 수 있습니다. 분석 창과 지연 허용 조건을 정하고 원본 시간을 보존합니다. 수집 실패와 이벤트 누락도 탐지 체계의 상태로 관리합니다.

7장 정상화와 원본 보존#

공통 필드로 변환하면 서로 다른 장비를 비교하기 쉽습니다. 하지만 변환 과정에서 의미가 빠질 수 있으므로 조사에 필요한 원본과 변환 규칙을 관리합니다. 로그 입력 자체가 신뢰된 명령·질의처럼 처리되지 않게 합니다.

8장 단일 경보보다 사건의 연결#

새로운 위치의 로그인, 권한 변경과 대량 데이터 조회가 이어지는 경우 각 이벤트를 연결해 가설을 검토합니다. 정상 출장·관리 작업과 구별할 문맥도 필요합니다. 경보 수가 많다는 사실만으로 탐지 품질이 높다고 판단하지 않습니다.

flowchart LR
 L[로그 수집] --> N[정규화·시간 정합]
 N --> C[상관분석]
 C --> T[분류·조사]
 T --> P[대응 절차]
 P --> V[결과 검증]

9장 탐지 규칙의 품질#

대상 위협, 필요한 로그, 정상 예외와 예상 결과를 정의합니다. 규칙의 탐지 범위와 오탐을 실제 사건·모의 상황으로 확인합니다. 장비나 인증 흐름이 바뀌면 규칙도 재검토합니다.

10장 SOAR의 입력과 권한#

경보에 들어 있는 IP·계정·파일 정보를 바로 실행 인자로 신뢰하지 않습니다. 입력 형식을 검증하고 대상 자산·계정의 범위를 제한합니다. 자동화 계정은 필요한 권한만 가져야 합니다.

11장 자동 차단의 영향#

공용 프록시 IP나 업무 필수 계정을 차단하면 피해가 커질 수 있습니다. 낮은 위험의 정보 수집과 업무 영향이 큰 차단을 구분하여 승인·복구 조건을 설계합니다. 자동화가 판단의 책임을 없애지는 않습니다.

12장 재시도와 부분 실패#

계정 비활성화는 성공했지만 세션 폐기는 실패할 수 있습니다. 단계별 결과를 기록하고 중복 실행 시 불필요한 변경이 생기지 않도록 멱등성을 고려합니다. 실패한 작업의 재시도와 사람에게 넘길 조건을 정합니다.

13장 운영 성과와 기록 보호#

수집 지연·누락, 조사 시간, 실제 탐지와 대응 성공을 함께 측정합니다. 로그의 인증 토큰·개인정보를 최소화하고 접근과 보유 범위를 정합니다. 탐지에 필요한 정보와 불필요한 원문을 구분해야 합니다.

14장 계정 차단 자동화의 부분 실패 사례#

경보가 발생하여 계정 비활성화와 기존 세션 폐기를 수행한다고 가정합니다. 첫 작업이 성공해도 세션 폐기 API가 실패하면 기존 토큰이 계속 사용될 수 있습니다. 워크플로 전체가 성공했다고 표시하면 대응자는 남은 위험을 놓칩니다.

각 작업의 대상·응답·실제 상태를 기록하고 실패한 단계만 안전하게 재시도합니다. 이미 비활성화한 계정을 다시 처리해도 불필요한 오류나 다른 계정 변경이 발생하지 않도록 설계합니다. 대상 식별자는 경보 문구의 이름만으로 결정하지 않습니다.

실행 완료 후 실제 로그인·세션 상태를 확인하는 검증 단계가 필요합니다. 자동화의 성공은 API 호출 횟수보다 의도한 상태가 되었는지로 판단합니다.

15장 적용 사례와 운영 방법#

비정상 로그인 뒤 권한 변경과 대량 다운로드가 발생하면 단일 이벤트보다 의미 있는 신호가 됩니다. 자동 계정 정지는 정상 업무를 중단할 수 있으므로 조건과 예외를 검증하고 필요하면 사람의 검토를 결합합니다. 대응 후 조치 효과와 복구 여부까지 기록합니다.

16장 로그의 연결 키가 상관분석의 품질을 결정한다#

시간만 가까운 이벤트를 묶으면 서로 다른 사용자나 자산의 행위가 섞일 수 있습니다. 사용자 ID·세션·자산·요청 ID를 정규화하고 시간대·수집 지연·중복을 처리합니다. 계정 이름이 재사용되거나 NAT 주소를 공유하는 경우도 구분해야 합니다.

탐지는 비정상 로그인→권한 변경→대량 다운로드처럼 조사할 수 있는 가설로 연결합니다. 정상 관리자 작업과 자동화가 비슷한 패턴을 만드는지도 시험하고, 경보가 울렸을 때 담당자가 어떤 로그를 열어 판단할지 설계합니다. 로그 수집 실패 자체도 중요한 가시성 경보입니다.

17장 SOAR 플레이북의 권한·승인·복구를 정의한다#

경보가 들어오면 자산·사용자 맥락을 조회하고 증거를 수집한 뒤 조치를 결정합니다. 악성 주소 차단과 관리자 계정 정지는 업무 영향이 다를 수 있어 자동화의 허용 범위를 나눕니다. 입력이 신뢰하지 않는 URL·파일·명령으로 바뀌지 않도록 스키마와 실행 경로도 검증합니다.

플레이북은 재시도·중복 실행·일부 실패·API 제한·사람의 승인 지연을 포함해야 합니다. 조치 ID와 결과를 남기고 되돌리기와 복구를 시험합니다. 성과는 처리 경보 수뿐 아니라 조사 시간·정확성·조치 실패·정상 업무 영향을 함께 측정합니다.

18장 적용 전 확인할 사항#

시간·필드·자산·보존기간의 기준을 정한다
탐지 규칙의 오탐과 조사 시간을 측정한다
플레이북의 권한·승인·실패·복구를 검증한다

19장 자주 묻는 질문#

SOAR로 모든 경보를 자동 차단해도 되나요?#

경보의 신뢰도와 업무 영향에 따라 달라집니다. 되돌리기 어려운 조치는 근거·권한과 검토 조건을 더 엄격하게 정해야 합니다.

로그를 많이 수집할수록 탐지는 무조건 좋아지나요?#

불필요한 데이터와 비밀 노출·비용이 늘 수 있습니다. 위협 시나리오에 필요한 필드와 보존·권한·무결성을 설계해야 합니다.

자동화 실패 후 재시도하면 언제나 괜찮나요?#

같은 조치가 반복되거나 일부만 반영될 수 있습니다. 멱등성·상태 확인·상한·복구 정책을 플레이북에 넣어야 합니다.