[SEC-011][실무] 보안 로그로 이상 징후 찾고 대응하기 > IT 기술 공유

• 목록

[이번 수업]
보안 사고는 기억만으로 조사하기 어렵습니다. 구조화 로그를 남기고 반복 실패를 탐지해 확인·억제·복구·회고로 잇는 방어 절차를 연습합니다.

[선수지식]
SEC-001~010의 위협 모델, 인증·인가, 비밀정보 보호와 취약점 관리 개념과 JSON·Python 실행법을 알아야 합니다.

[학습목표]
1. 조사에 필요한 보안 로그 필드를 고른다.
2. 임계값과 시간 범위가 있는 탐지 규칙을 설명한다.
3. 경보를 검증하고 증거를 보존하며 대응 절차로 연결한다.

[핵심개념]
보안 로그는 ‘언제, 어디서, 누가, 무엇을, 어떤 대상에, 어떤 결과로 수행했는가’를 다시 확인할 기록입니다. UTC 시각, 이벤트 종류, 결과, 가명화한 계정 식별자, 출처, 대상, 요청 상관관계 ID를 일관된 이름과 형식으로 남깁니다. 인증 성공·실패, 인가 거부, 관리자 변경, 데이터 내보내기처럼 위험 판단에 필요한 사건을 우선 기록합니다.

탐지는 로그에서 조사할 신호를 만드는 일입니다. 규칙에는 데이터 원천, 조건, 시간 범위, 임계값, 예외, 심각도, 담당자와 대응 안내를 붙입니다. 예를 들어 ‘5분 동안 같은 출처에서 로그인 실패 3회 이상’을 경보로 만들 수 있습니다. 정상 사용도 걸릴 수 있으므로 경보는 사고 확정이 아니라 확인이 필요한 출발점입니다.

사고 대응은 준비와 탐지에서 시작해 사실 확인, 영향 범위 파악, 억제, 제거·복구, 사후 개선으로 이어집니다. 최초 로그를 보존하고 시간순 기록을 남기며, 사용자 영향과 자산 중요도에 따라 우선순위를 정합니다. 급해도 근거 없이 계정을 삭제하거나 로그를 지우지 않습니다.

[따라하기]
events.jsonl을 만드세요. 한 줄이 하나의 JSON인 가짜 로그인 기록입니다. 이 파일 전체가 한 번의 5분 수집 묶음이라고 가정합니다.
```json
{"time":"2026-09-05T10:00:00Z","event":"login_failed","account":"demo","source":"127.0.0.1"}
{"time":"2026-09-05T10:01:00Z","event":"login_failed","account":"demo","source":"127.0.0.1"}
{"time":"2026-09-05T10:02:00Z","event":"login_failed","account":"demo","source":"127.0.0.1"}
{"time":"2026-09-05T10:03:00Z","event":"login_success","account":"demo","source":"127.0.0.1"}
```
detect.py를 만듭니다.
```python
import json
from collections import Counter

with open("events.jsonl", encoding="utf-8") as file:
    events = [json.loads(line) for line in file if line.strip()]

failures = Counter(
    event["source"]
    for event in events
    if event.get("event") == "login_failed"
)
for source, count in failures.items():
    if count >= 3:
        print(json.dumps({
            "alert": "repeated_login_failure",
            "source": source,
            "count": count,
        }))
```
macOS·Linux는 `python3 detect.py`, Windows는 `py detect.py`로 실행합니다. 예상 결과는 alert가 repeated_login_failure, source가 127.0.0.1, count가 3인 JSON 한 줄입니다. 실패 기록 하나를 지우면 출력이 없어야 합니다.

[흔한 실수]
모든 요청 본문을 무조건 저장하거나, 성공 사건만 남기거나, 서버마다 시각과 필드 이름을 다르게 쓰지 마세요. 경보 수만 늘리고 담당자·우선순위·대응 안내를 정하지 않으면 중요한 신호가 묻힙니다. 로그 수집 중단 자체도 탐지해야 합니다.

[보안 주의]
비밀번호, 세션 ID, 접근 토큰, 암호화 키, 결제정보와 불필요한 개인정보를 로그에 남기지 마세요. 로그에는 엄격한 읽기 권한, 전송·저장 암호화, 위변조 방지, 보존·폐기 기준을 적용합니다. 사고가 의심되면 원본과 시각 정보를 보존하고 승인된 담당자에게 알립니다. 타인 시스템에 시험 요청을 보내지 말고 로컬·격리 환경만 사용합니다.

[직접 해볼 과제]
다른 출처의 실패 2개를 추가해 경보가 생기지 않는지 확인하세요. 이어 탐지 규칙 문서에 목적, 5분 범위, 3회 임계값, 예상 오탐, 심각도, 담당자, 확인할 로그, 억제와 복구 절차를 적고 모의 경보를 한 번 처리합니다.

[확인문제]
1. 보안 경보가 곧 사고 확정을 뜻하지 않는 이유는 무엇인가요?
2. 탐지 규칙에 시간 범위와 예외 조건이 필요한 이유는 무엇인가요?
3. 사고 대응 중 원본 로그와 시각 정보를 보존해야 하는 이유는 무엇인가요?

[다음 학습]
SEC-012에서 격리된 실습 서비스를 대상으로 설정, 권한, 의존성, 로그와 복구 절차를 묶어 안전하게 점검합니다.

[공식 참고 자료]
https://csrc.nist.gov/pubs/sp/800/92/final
https://csrc.nist.gov/pubs/sp/800/61/r3/final
https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
https://docs.python.org/3/library/json.html
https://docs.python.org/3/library/collections.html#collections.Counter