VPN 로그인 실패, 원격접속 성공, 내부 파일 접근이 각각 기록됐다고 가정해 보자. 로그인 실패만 보면 비밀번호 입력 실수일 수 있고, 파일 접근만 보면 정상 업무일 수 있다. 그러나 같은 계정이 짧은 시간 안에 이 행동을 순서대로 수행했다면 함께 조사할 이유가 생긴다.
보안 이벤트 상관분석은 이렇게 흩어진 기록을 식별자, 시간 범위, 발생 순서 등의 조건으로 연결해 의미 있는 활동을 찾는 과정이다. 핵심은 로그를 많이 모으는 데 있지 않다. 어떤 기록을 같은 활동으로 볼 것인지, 그 연결이 얼마나 믿을 만한지 설명할 수 있어야 한다.
1. 단일 이벤트에서 활동의 흐름으로
NIST SP 800-92는 이벤트 상관분석을 두 개 이상 로그 기록 사이의 관계를 찾는 것으로 설명한다. 하나의 시스템 안에서도 가능하며, 여러 보안 장비의 로그를 결합하는 경우에만 해당하는 개념은 아니다.
SIEM(Security Information and Event Management)은 여러 시스템의 보안 로그를 수집·분석하는 플랫폼이다. 여기서 단일 이벤트 탐지는 한 기록이 특정 조건에 맞는지 확인하고, 상관분석은 여러 기록이 함께 만족하는 관계를 확인한다. 예를 들어 로그인 실패 한 건을 찾는 것과, 같은 계정의 실패가 반복된 뒤 성공 로그인이 발생했는지 찾는 것은 다른 분석이다.
여러 경고를 한 조사 묶음으로 정리하는 기능도 구분해야 한다. Microsoft Sentinel 공식 문서는 이벤트를 경고로 묶는 설정과 경고를 인시던트로 묶는 설정을 별도로 설명한다. 묶음이 만들어졌다는 사실만으로 사건 사이의 인과관계가 증명되거나 침해가 확정되지는 않는다.
2. 연결의 기준은 식별자·시간·조건
상관분석을 설계할 때는 먼저 ‘누구 또는 무엇의 활동을 연결할 것인지’를 정한다. 사용자 계정, 단말 식별자, 세션 ID처럼 기록 사이를 이어 주는 값을 연결 키라고 부른다. 계정명은 조직이나 도메인까지 함께 구분해야 이름이 같은 계정을 잘못 합치는 일을 줄일 수 있다.
다음은 연결할 시간 범위다. 같은 계정의 이벤트라도 수개월 떨어진 기록을 무조건 한 활동으로 묶으면 관련성이 약해진다. 반대로 범위를 너무 좁히면 느리게 진행되는 활동을 놓칠 수 있다. 시간 범위는 탐지하려는 행동과 조직의 정상 업무 흐름에 맞춰 정해야 한다.
마지막은 관계 조건이다. 발생 횟수만 필요한지, 서로 다른 행위가 함께 있어야 하는지, 순서까지 필요한지를 구분한다. Sigma 공식 문서는 이벤트 수, 서로 다른 값의 수, 시간 내 조건 충족, 순서가 있는 시간 관계를 별도 유형으로 설명한다.
| 연결 방식 | 확인할 관계 | 주의할 부분 |
|---|---|---|
| 횟수 집계 | 같은 계정의 로그인 실패가 일정 시간에 반복됨 | 중복 수집된 기록이 횟수를 부풀릴 수 있음 |
| 서로 다른 값 집계 | 같은 출발지에서 여러 대상에 접근함 | 접근 횟수와 대상 개수는 다름 |
| 시간 내 조건 결합 | 같은 대상에서 서로 다른 의심 행위가 함께 발생함 | 가까운 시각에 발생한 것만으로 같은 활동은 아님 |
| 순서 분석 | 로그인 실패 이후 성공과 후속 접근이 이어짐 | 발생 순서와 수집 순서를 혼동하면 안 됨 |
Elastic EQL 문서의 sequence by는 동일한 연결 키로 이벤트를 연결하고, with maxspan은 첫 이벤트부터 전체 순서가 완료될 때까지의 최대 시간 범위를 제한한다. 이는 관계를 표현하는 구현 예이며 모든 SIEM이 같은 문법이나 처리 방식을 쓰는 것은 아니다.
3. 가상 사례로 보는 계정·세션·후속 접근 연결
다음은 설명용 가상 사례다. 시각은 같은 날의 KST로 통일했으며 계정과 주소도 예시다. 실제 침해사고 기록이나 권장 임계값이 아니다.
| 발생 시각 | 로그 출처 | 기록된 사실 | 다음 기록과 연결할 정보 |
|---|---|---|---|
| 09:00~09:02 | VPN 인증 로그 | corp/user-a의 인증 실패가 여러 번 발생 | 계정과 접속 출발지 |
| 09:03 | VPN 세션 로그 | 같은 계정의 인증 성공, 세션 vpn-s1에 내부 IP 10.20.5.14 할당 | 계정·세션·할당 IP·세션 유효 시간 |
| 09:06 | 파일 서버 감사 로그 | 출발지 10.20.5.14, 계정 corp/user-a로 보호 대상 파일 읽기 성공 | 계정·주소·파일·처리 결과 |
이 사례의 분석 조건을 ‘실패 묶음의 첫 기록부터 10분 안에 같은 계정의 로그인 성공과 후속 파일 접근이 이어짐’으로 설정했다고 가정하자. 인증 실패와 성공은 계정으로 연결하고, 성공과 파일 접근은 해당 시각에 유효한 VPN 세션의 주소 할당 정보와 서버에 기록된 계정을 함께 확인한다.
여기서 10분은 설명을 위한 설정이다. 실제 규칙에서는 실패 횟수 기준, 동일 출발지를 요구할지 여부, 파일 접근 범위까지 명시해야 한다. 파일 서버가 필요한 감사 기록을 남기지 않는다면 마지막 단계를 확인할 수 없으므로 수집 설정부터 점검해야 한다.
세 기록이 연결돼도 계정 탈취가 입증되지는 않는다. 사용자가 비밀번호를 잘못 입력한 뒤 정상 접속했을 수 있다. 담당자는 사용자 확인, MFA 결과, 접속 단말, 파일 접근의 업무 필요성을 추가 조사한다. 파일 읽기 성공은 해당 접근의 결과이며, 외부 유출까지 증명하는 기록은 아니다.
4. IP가 같아도 동일 단말이 아님
기업 네트워크에서 외부로 나가는 여러 단말은 NAT(Network Address Translation)를 통해 하나의 공인 IP를 공유할 수 있다. 따라서 같은 공인 IP의 이벤트를 전부 한 사용자에게 붙이면 서로 다른 사람의 활동을 섞을 수 있다.
운영 관점에서는 필요한 시각의 내부 주소, 포트, 통신 방향, NAT 변환 내역을 대조하고, 가능하면 계정과 세션 기록으로 연결을 보강해야 한다. VPN이나 DHCP가 내부 IP를 재할당하는 환경에서도 현재 주소의 사용자와 과거 시점의 사용자가 같다고 가정하면 안 된다.
필드 이름을 통일하는 정규화도 값의 의미까지 보장하지는 않는다. 어떤 로그의 출발지 IP는 실제 단말 주소이고, 다른 로그에서는 프록시 주소일 수 있다. 연결하기 전에 각 장비의 관찰 위치와 필드 의미를 확인해야 한다. 이 확인이 없으면 정교한 규칙도 잘못된 관계를 빠르게 만드는 도구가 된다.
5. 발생 시간과 수집 지연을 함께 다뤄야 함
이벤트가 발생한 시간과 SIEM에 도착한 시간은 다르다. 파일 접근 로그가 먼저 도착하고 로그인 성공 로그가 나중에 도착했다고 해서 파일 접근이 먼저 발생한 것은 아니다. 시간대 통일과 장비 시계 동기화가 필요한 이유다. NIST 로그 관리 지침도 공통 시간원을 통한 시계 동기화와 로그 원본 보존을 다룬다.
자동 분석에서는 행위 사이의 시간 범위 외에 규칙 실행 간격과 조회 범위도 고려해야 한다. 행위가 10분 안에 이어졌는지 확인하는 조건과, 이번 실행에서 과거 얼마만큼의 데이터를 읽을지는 별개다.
Microsoft의 수집 지연 대응 문서는 늦게 들어온 이벤트가 조회 범위를 벗어나 탐지에서 빠질 수 있으며, 조회 범위를 넓히면 중복 경고가 생길 수 있다고 설명한다. 여러 로그를 연결할 때는 출처별 지연을 측정하고, 늦게 도착한 기록의 재평가와 같은 활동에 대한 경고 중복 방지를 함께 설계해야 한다.
이벤트가 없다는 조건도 신중하게 해석해야 한다. 후속 기록이 보이지 않는 이유는 실제 행위가 없어서일 수도 있지만, 감사 설정 누락이나 수집 장애 때문일 수도 있다. 로그 미수집을 정상 상태로 해석하지 않도록 수집 상태 자체를 확인하는 절차가 필요하다.
6. 운영 전에 연결 근거를 설명할 수 있어야 한다
실무자 관점에서 첫 점검 대상은 규칙 개수보다 연결에 필요한 데이터다. 다음 항목을 실제 기록으로 확인하면 상관분석의 작동 범위와 한계를 파악하기 쉽다.
- 필요한 계정·세션·단말 필드가 채워져 있고, 원본 로그로 연결을 추적할 수 있는가.
- 정상 업무, 의심 활동, 수집 지연, IP 재할당 사례에서 예상한 관계만 만들어지는가.
- 결과에 연결 키, 적용한 시간 범위, 구성 이벤트와 처리 결과가 남는가.
- 담당자가 예외 승인 내역과 자산 정보를 확인하고 다음 조사로 이어 갈 수 있는가.
긴 조회 범위와 여러 데이터의 결합은 검색 자원과 운영 부담을 늘릴 수 있다. 소규모 조직이라면 중요한 계정과 시스템의 분석부터 시작하고, 확보하지 못한 로그 때문에 확인할 수 없는 단계도 문서화하는 편이 현실적이다. 정상 업무 예외에는 적용 범위와 재검토 시점을 두어 오래된 예외가 탐지 공백으로 남지 않도록 관리한다.
상관분석 결과에는 ‘어떤 기록을 왜 연결했는지’가 남아야 한다. 이 근거를 설명할 수 있고 연결 실패도 찾아낼 수 있을 때, 관제 담당자는 경고를 검증하고 대응 우선순위를 정할 수 있다.