시스템 보안 · 취약점 › B. 계정 · 인증 보안 강화 · 47/50편 (전체 097/450)
학습 단계: 5단계 · SOC 관제 연계
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.
선행 학습
1. 개념
룰을 하나씩 만드는 것을 넘어, 탐지를 유스케이스(use case) 단위로 설계하면 빠짐·중복 없이 체계적으로 운영할 수 있습니다. 각 유스케이스는 하나의 위협을 탐지→대응까지 다룹니다.
탐지 유스케이스 템플릿
목표 : 어떤 위협을 탐지하는가 (예: SSH brute-force 돌파)
데이터 : 필요한 로그원·필드 (secure, audit; user·srcip·result)
로직 : 탐지 조건·룰 (101220 등) + 임계값
정탐조건 : 무엇이 정탐인가
오탐조건 : 흔한 오탐과 예외
대응 : 탐지 시 조치 절차
검증 : 테스트 방법(샘플 로그·주기 점검)이 틀로 정리하면 룰·대시보드·대응·검증이 하나로 묶입니다.
2. 왜 중요한가
- 룰만 쌓으면 "이 룰이 왜 있는지, 울리면 뭘 해야 하는지"가 흩어집니다. 유스케이스는 이를 한 문서로 묶습니다.
- 임계값·오탐 조건을 명시해 두면 운영 중 튜닝과 인수인계가 쉽습니다.
- 검증 방법이 포함돼 있어, 룰이 여전히 동작하는지 주기적으로 확인할 수 있습니다(047편 0건 룰 문제).
3. 핵심 명령어 / 설정
| 유스케이스 | 핵심 룰 | 임계값(예) |
|---|---|---|
| SSH brute-force 돌파 | 101220 + 5720 | 실패 N회 후 성공 |
| password spraying | 101210 | 출발지당 계정 ≥ 15/5분 |
| 계정 열거 | 101190 | invalid user ≥ 10/2분 |
| 이상 로그인(다축) | 101171/101240 | 비관리망+업무외 |
| 서비스 계정 로그인 | 101011/101320 | 1건 |
| 권한 확대 | 101280 | 부여 후 사용 |
| 계정 탈취 결합 | 101370 | 다범주 ≥ 3 |
4. 실습 (실습 예시)
# 유스케이스 설계 문서 예시 (텍스트 템플릿)
UC-AUTH-01 SSH brute-force 돌파
목표 : 무차별 대입으로 계정이 뚫린 순간 탐지
데이터 : secure/auth.log(5716,5715), audit(USER_LOGIN)
로직 : 같은 srcip+user에서 5720(다수실패) 후 5715 성공 → 101220(level 13)
정탐 : 실패 수십~수백 후 성공, 비관리망·새벽
오탐 : 사용자 오타 후 로그인(실패 1~2, 관리망) → 제외
대응 : 세션 종료·계정 잠금·비밀번호 교체·IP 차단(074편)
검증 : 샘플 로그 wazuh-logtest, 월 1회 재주입5. 정상 상태
설계가 잘 된 유스케이스는 탐지부터 대응·검증까지 공백이 없습니다.
UC-AUTH-01 상태: 룰 101220 활성, 대시보드 '돌파' 패널 연동,
대응 절차 문서화, 최근 검증 2026-09-15 통과
→ 운영 가능 상태6. 이상 상태
설계에 공백이 있으면 운영 중 문제가 됩니다.
UC-AUTH-03 계정 열거
룰 101190 활성이나:
- 임계값(10회/2분)이 느린 열거를 놓침 → 조정 필요
- 대응 절차 미작성 → 울려도 뭘 할지 불명확
- 최근 검증 없음 → 동작 여부 불확실(0건이 정상인지 고장인지 모름)- 임계값·대응·검증 중 하나라도 비면 유스케이스가 "반쪽"이 됩니다.
- 설계 문서가 이 공백을 드러내 보완하게 합니다.
7. 로그 분석 (분석 방법)
유스케이스 묶음으로 본 커버리지 점검 예시입니다(가상의 예시).
위협(MITRE) 유스케이스 룰 대시보드 대응 검증
T1110 Brute Force UC-AUTH-01/02 101220/210 O O O
T1078 Valid Accounts UC-AUTH-04 101171/240 O O △
T1136 Create Account UC-AUTH-05 101260 O O O
T1098 Account Manip UC-AUTH-06 101030/270 O △ △| 점검 | 의미 |
|---|---|
| 빈 칸 | 탐지·대응·검증 공백 → 보완 대상 |
| MITRE 매핑 | 위협 커버리지 확인 |
유스케이스 표로 "어떤 위협을 못 보고 있는지"를 한눈에 점검합니다.
8. SOC 관제 포인트
- 탐지는 유스케이스 단위(목표·데이터·로직·정탐/오탐·대응·검증)로 설계·관리합니다.
- MITRE ATT&CK에 매핑해 위협 커버리지의 빈 곳을 찾습니다.
- 각 유스케이스에 검증 주기를 두어 룰이 계속 동작하는지 확인합니다.
9. 탐지 규칙
유스케이스는 룰·대시보드·대응을 연결하는 문서이며, 룰 자체는 045편 것을 재사용합니다.
# 유스케이스 ↔ 자산 연결 (개념)
UC-AUTH-01(돌파) → 룰 101220 → 대시보드 '돌파' 패널 → 대응 절차 074편 → 검증 샘플 로그Wazuh/Kibana에 유스케이스별 태그(예: rule.description에 UC 번호)를 넣으면, 대시보드·보고서에서 유스케이스 단위로 집계할 수 있습니다. ATT&CK Navigator로 커버리지를 시각화하는 것도 유용합니다.
10. 대응 방법
- 초기 확인 — 탐지 대상 위협을 유스케이스로 정의하고 템플릿 항목을 채웁니다.
- 범위 확인 — MITRE 매핑으로 커버리지 공백(탐지·대응·검증)을 찾습니다.
- 증거 확보 — 유스케이스 문서와 연결된 룰·대시보드·대응 절차를 보존·관리합니다.
- 차단/조치 — 공백(임계값·대응·검증)을 보완하고 주기 검증을 수행합니다.
- 재발 방지 — 유스케이스 카탈로그를 운영 기준으로 유지합니다.
11. 핵심 정리
| 항목 | 내용 |
|---|---|
| 구성 | 목표·데이터·로직·정탐/오탐·대응·검증 |
| 단위 | 위협 하나 = 유스케이스 하나 |
| 매핑 | MITRE ATT&CK로 커버리지 점검 |
| 가치 | 룰·대시보드·대응·검증을 한 문서로 연결 |
| 면접 포인트 | "룰을 쌓지 말고 유스케이스로 설계 — 탐지부터 대응·검증까지" |
12. 다음 편 예고
다음 편 098. 계정 · 인증 보안 — 인증 Alert 정탐·오탐 판단 에서는 룰이 울린 뒤의 판단인 인증 Alert 정탐·오탐 판단을 다룹니다.
이전 편: 096. 계정 · 인증 보안 — ELK 인증 대시보드 구성
📚 시리즈 전체 보기: 시스템 보안 · 취약점
