로그인 실패 경고가 반복될 때 임계값부터 올리면 화면은 조용해질 수 있습니다. 하지만 천천히 진행되는 공격까지 놓칠 수 있습니다. SIEM 탐지 규칙을 개선하려면 어떤 행위를 찾는지, 무엇을 기준으로 묶는지, 정상 업무를 어디까지 구분할 수 있는지부터 확인해야 합니다.
SIEM(Security Information and Event Management)은 보안 로그를 모아 분석하는 시스템입니다. 탐지 규칙은 그 안에서 조사할 가치가 있는 행위를 골라 경고로 만드는 기준입니다. 오탐을 줄이는 핵심은 데이터와 조건을 정확하게 맞추고, 예외를 좁게 관리하며, 변경 뒤에도 필요한 행위가 탐지되는지 검증하는 데 있습니다.
1. 탐지 규칙은 조건식과 운영 설정으로 구성
탐지 규칙의 출발점은 탐지 가설입니다. 예를 들어 “한 계정에 인증 실패가 짧은 시간 동안 집중되면 비밀번호 추측 시도일 수 있다”처럼 관찰할 행위와 의심하는 이유를 연결합니다. “로그인이 이상하다” 정도의 설명으로는 조건도 조사 절차도 정하기 어렵습니다.
아래는 규칙을 설계할 때 확인할 공통 항목입니다. 제품마다 이 항목을 표현하는 문법과 설정 위치는 다릅니다.
| 구성 요소 | 정해야 할 내용 | 놓치기 쉬운 부분 |
|---|---|---|
| 데이터 범위 | 로그 종류, 대상 시스템, 필수 필드 | 필요한 감사 로그가 실제로 생성되는지 |
| 탐지 조건 | 행위, 결과, 횟수, 서로 다른 값의 수 | 단순 문자열과 실제 행위의 의미가 같은지 |
| 묶음 기준 | 계정, 단말, 출발지, 대상 서비스 | 여러 사용자의 활동이 섞이지 않는지 |
| 시간 설정 | 행위 관찰 구간, 조회 범위, 실행 주기 | 수집 지연과 겹치는 조회 구간 |
| 예외·출력 | 제외 조건, 심각도, 조사에 필요한 근거 | 예외 범위와 경고에 남길 정보 |
| 관리 정보 | 담당자, 버전, 변경 이유, 검증 결과 | 업무 환경이 바뀐 뒤의 재검토 |
Sigma 공식 문서는 로그 범위를 나타내는 logsource, 조건을 정의하는 detection, 설명과 심각도 등의 메타데이터를 구분합니다. 특히 falsepositives 항목은 예상 오탐을 기록하는 설명이며, 변환기가 자동으로 제외 조건으로 처리하지 않습니다. 오탐 가능성을 문서에 적는 일과 실제 필터를 구현하는 일은 구분해야 합니다.
2. 로그인 실패 규칙에서 드러나는 설계 차이
설명용 가상 규칙으로 “같은 인증 영역의 같은 계정·대상 서비스에서 최근 10분 동안 비밀번호 불일치로 인한 실패가 10회 이상이면 경고”를 생각해 보겠습니다. 여기의 시간과 횟수는 구조를 설명하기 위한 값이며 권장 임계값이 아닙니다.
먼저 실패 사유를 확인해야 합니다. 비밀번호 불일치, 만료된 자격증명, 접근 정책에 따른 거부를 모두 같은 실패로 집계하면 서로 다른 문제를 한 경고에 섞게 됩니다. 계정 이름도 인증 영역을 포함한 식별자로 묶어야 동명이 계정의 활동이 합쳐지는 일을 줄일 수 있습니다.
집계 기준은 탐지 범위까지 바꿉니다. 계정별 실패 횟수는 한 계정에 집중되는 시도를 찾는 데 적합합니다. 여러 계정에 조금씩 시도하는 패스워드 스프레이를 찾으려면 출발지별 대상 계정 수처럼 다른 관점이 필요합니다. 두 패턴을 한 규칙의 임계값 조정만으로 모두 해결하기는 어렵습니다.
같은 출발지 IP에서 발생했다는 이유만으로 한 사람의 시도라고 판단해서도 안 됩니다. 공용 접속 환경에서는 여러 사용자가 같은 외부 주소를 사용할 수 있습니다. IP는 관찰 단서로 사용하고 계정·단말·세션 등의 근거를 함께 확인해야 합니다.
시간 설정도 별도로 살펴야 합니다. Microsoft Sentinel의 예약 분석 규칙 문서는 실행 간격과 과거 데이터를 조회하는 범위를 구분합니다. 예를 들어 5분마다 최근 10분을 조회하면 구간이 겹칩니다. 이때 같은 행위가 다시 경고되는지 확인해야 합니다. 쿼리 안에서 집계한 원본 이벤트 수와, 쿼리 결과 행 수에 적용되는 경고 임계값도 구분해야 합니다.
또한 “최근 10분”과 “시각을 기준으로 나눈 고정 10분 구간”은 다릅니다. 고정 구간의 경계 양쪽에 실패가 나뉘면 각 구간에서는 임계값에 못 미칠 수 있습니다. 원하는 관찰 방식이 구현된 쿼리와 일치하는지 검증해야 합니다.
3. 오탐 원인에 따라 수정 방법을 선택
규칙이 예상대로 동작했더라도 승인된 점검이나 관리 작업이면 보안 사고 조사가 필요하지 않을 수 있습니다. 운영에서는 이런 경고도 오탐으로 묶어 부르지만, 조건 오류인지 정상 업무와의 중첩인지 구분해서 기록하면 수정 방향이 명확해집니다.
Elastic의 규칙 튜닝 지침은 규칙 자체가 지나치게 넓은 경우의 튜닝과, 해당 조직에서 안전하다고 확인된 활동에 대한 예외를 구분합니다. 이를 적용하면 다음 순서로 원인을 좁힐 수 있습니다.
- 데이터 오류: 결과 코드가 잘못 해석됐거나 같은 이벤트가 중복 수집됐다면 수집·변환·중복 제거 단계부터 바로잡습니다.
- 조건 범위 오류: 다른 서비스의 실패가 합쳐졌다면 묶음 기준과 대상 범위를 수정합니다.
- 정상 업무와 중첩: 승인된 점검이 원인이면 대상·계정·시간을 확인해 제한적인 예외를 검토합니다.
- 반복 경고: 같은 활동의 경고가 쌓이면 중복 처리나 경고 묶기 설정을 검토합니다.
임계값 상향은 정상 활동 분포와 놓칠 수 있는 공격을 비교한 뒤 선택해야 합니다. 야간 배치와 주간 사용자 활동을 구분할 수 있는데도 전체 임계값을 올리면 다른 시간대의 탐지 민감도까지 낮아집니다. 반대로 조건을 계속 추가하면 필요한 필드가 없는 행위가 빠질 수 있으므로 조건별 누락 영향도 확인해야 합니다.
4. 예외와 경고 억제는 영향 범위 다름
예외는 특정 조건의 이벤트가 경고를 만들지 않게 하는 방식입니다. 따라서 “점검 서버에서 발생한 모든 활동 제외”처럼 넓게 설정하면 그 서버가 침해됐을 때의 활동까지 빠질 수 있습니다. 승인된 출발지·대상·계정·작업 시간처럼 확인 가능한 조건을 조합하고, 등록 이유·책임자·만료일을 관리하는 것이 실무적으로 유용합니다.
예외의 만료 기능을 지원하지 않는 제품이라면 별도 관리대장과 정기 검토 절차가 필요합니다. 담당자가 바뀌거나 점검 도구가 폐기된 뒤에도 예외가 남아 있으면 탐지 범위가 줄어든 이유를 추적하기 어려워집니다.
경고 억제는 제품별 동작을 직접 확인해야 합니다. Elastic의 alert suppression 문서는 일치하는 이벤트를 지정 필드로 묶어 경고 수를 줄이고 원래 이벤트를 조사할 수 있다고 설명합니다. 반면 앞서 인용한 Sentinel 예약 규칙의 억제 설정에는 경고 발생 후 일정 시간 쿼리 실행을 멈추는 방식이 있습니다.
따라서 설정 이름만 보고 같은 기능이라고 가정할 수 없습니다. 같은 IP 기준으로 너무 넓게 묶으면 서로 다른 계정의 공격이 한 경고 안에 섞일 수 있고, 규칙 전체가 멈추면 그동안 다른 대상에서 일어나는 행위의 탐지에 영향을 줄 수 있습니다. 묶음 기준, 유지되는 근거, 실행 중단 여부를 함께 확인해야 합니다.
5. 변경 효과는 경고 감소와 탐지 유지로 검증
운영 규칙을 수정하기 전에는 이전 버전과 변경 이유를 남기고 과거 데이터에서 결과를 비교합니다. 정상 업무 표본뿐 아니라 탐지돼야 할 행위, 임계값 부근의 행위, 예외와 일부 조건만 같은 행위를 함께 확인해야 합니다. 가능한 경우 별도의 시험 환경에서 안전하게 만든 모의 이벤트로 검증합니다.
예를 들어 승인된 점검에는 예외가 적용되더라도 같은 계정의 다른 대상 접근이나 승인 시간 밖 활동에는 적용되지 않는지 확인합니다. 필수 필드가 비어 있거나 이벤트 도착이 늦은 경우도 포함해야 합니다.
Microsoft의 수집 지연 대응 문서는 늦게 도착한 이벤트가 시간 필터에서 빠질 수 있고, 조회 범위를 넓히면 중복이 생길 수 있다고 설명합니다. 경고 감소가 규칙 개선의 결과인지, 수집 지연이나 로그 누락의 결과인지 구분해야 하는 이유입니다.
운영에서는 규칙별 경고 수, 검토 완료 경고 중 확인된 위협의 비중, 미분류 건수, 조사 시간, 시험 시나리오의 탐지 여부를 함께 살펴볼 수 있습니다. 확인된 위협의 비중은 검토 표본에 대한 정밀도에 가까운 값이며, 정상 활동 전체를 분모로 하는 오탐률과는 다릅니다. 놓친 공격의 전체 수를 모르면 실제 환경의 미탐률도 단정할 수 없습니다.
실무자 관점에서 경고에는 계정·대상·실패 사유·관찰 구간·집계값·원본 이벤트 확인 경로를 남기는 편이 좋습니다. 조사 근거가 부족하면 규칙이 정확해져도 담당자가 다시 로그를 찾는 시간이 길어집니다. 변경 후에는 실행 오류와 데이터 수집 상태를 확인하고, 예상치 못한 누락이 생기면 이전 버전으로 되돌릴 수 있어야 합니다.
6. 규칙 검토는 탐지 범위가 남아 있는지 확인하는 일
오탐이 잦은 규칙 하나를 골라 탐지하려는 행위, 필요한 데이터, 경고가 반복되는 이유를 한 장에 정리해 보세요. 그다음 원인에 맞는 항목을 변경하고 정상 업무와 탐지 대상 행위에서 결과를 비교하면 됩니다.
최종 판단 기준은 경고가 얼마나 줄었는지와 함께, 어떤 행위를 계속 관찰하고 어떤 행위를 제외했는지 설명할 수 있는가입니다. 인력이 적은 조직일수록 핵심 규칙의 담당자와 검토 시점을 정해 두어야 예외 누적과 데이터 변경으로 생기는 탐지 공백을 관리하기 쉽습니다.
참고자료
제품별 동작은 2026년 10월 16일 확인한 공식 문서를 기준으로 설명했습니다.