로그 분석으로 해킹 조사하기는 신화(Myth)?

By PLURA 2023-03-12

해킹 공격을 받으면 로그 분석을 해야 한다.
이 말은 맞습니다.

문제는 그 다음입니다.

많은 조직이 이렇게 믿고 있습니다.

“사고가 나면 로그를 보면 다 알 수 있겠지.”

하지만 현실은 다릅니다.
대부분의 경우, 사고가 발생한 뒤에는
정작 봐야 할 로그가 남아 있지 않습니다.

그래서 “로그 분석으로 해킹 조사를 할 수 있다”는 말은
준비 없는 조직에게는 종종 신화(Myth) 에 가깝습니다.

log_analysis_myth

1) 왜 이것이 신화가 되는가

로그는 저절로 생성되지 않습니다.

Windows에서는 감사정책(Audit Policy) 을 설정해야 하고
Linux에서는 auditd / syslog / 애플리케이션 로그 체계가 필요하며
웹 공격을 제대로 보려면 요청본문(Request Body)·응답본문(Response Body) 이 남아 있어야 합니다

즉,

로그 분석은 사고 이후에 시작되는 일이 아니라,
사고 이전에 무엇을 기록할지 정의하는 일입니다.

이 준비가 되어 있지 않으면,
사고가 난 뒤에 “로그 분석”을 하려고 해도
실제로는 분석할 로그가 없는 상태가 됩니다.

2) 실제로 어떤 로그가 비어 있나

많은 조직이 “로그는 있다”고 말하지만,
실무에서 자주 확인해 보면
다음과 같은 핵심 정보가 빠져 있습니다.

운영체제 로그에서 빠지는 것

프로세스 생성 기록
명령행(Command-line) 인자
권한 상승 흔적
계정 로그인 실패/성공 흐름
파일/레지스트리 접근 이력

웹 로그에서 빠지는 것

실제 요청 본문
공격 페이로드(SQLi, XSS, 웹셸 업로드 내용)
서버가 어떤 응답을 반환했는지
인증 우회나 API 오용의 실제 파라미터

즉,
URL·IP·상태코드만으로는
“접속이 있었다”는 사실만 보일 뿐,

무슨 공격이었는지,
무엇이 유출되었는지,
어떤 행위가 이어졌는지는 알 수 없는 경우가 많습니다.

3) access.log만으로는 왜 부족한가

많은 조직은 웹 로그라고 하면
여전히 access.log를 먼저 떠올립니다.

하지만 access.log는 보통 다음 정도만 보여줍니다.

시간
IP
URL
메서드
상태 코드

이 정보만으로는
공격의 핵심을 놓치기 쉽습니다.

예를 들어

/login 에 POST 요청이 있었다
→ 무슨 자격증명이 들어왔는지 모름
/upload 에 요청이 있었다
→ 악성 스크립트가 업로드됐는지 모름
상태코드 200이 반환됐다
→ 어떤 응답이 실제로 나갔는지 모름

즉, access.log는
누가 어디에 왔는지는 보여주지만,
무엇을 하려고 했는지는 거의 보여주지 못합니다.

4) 감사정책이 없으면 어떤 일이 생기나

운영체제 측에서도 마찬가지입니다.

감사정책이 부실하면
사고 후 조사에서 가장 중요한 질문에 답할 수 없습니다.

어떤 프로세스가 처음 실행됐는가?
누가 어떤 권한으로 로그인했는가?
정상 관리 행위와 공격 행위를 어떻게 구분할 것인가?
내부 정찰과 측면 이동은 언제 시작됐는가?

이 질문에 답하지 못하면
사고 조사 결과는 대개 이렇게 끝납니다.

“침해가 있었던 것은 맞지만,
정확한 최초 진입점과 확산 경로는 확인되지 않았다.”

즉, 로그 분석의 실패는
분석 기술이 부족해서가 아니라,
기록 자체가 준비되지 않았기 때문입니다.

5) 그래서 올바른 접근은 무엇인가

로그 분석을 신화가 아닌 현실로 만들려면
최소한 다음 세 가지가 선행되어야 합니다.

1. 운영체제 감사정책 설정

로그인/로그오프
프로세스 생성
권한 사용
객체 접근
정책 변경

2. 웹 요청·응답 본문 로깅

요청 페이로드
업로드 데이터
응답 결과
API 호출 맥락

3. 로그를 연결해서 볼 수 있는 분석 체계

웹 로그
운영체제 로그
계정/권한 로그
이벤트 상관분석

즉,
로그 분석은 단순히 “많이 저장하는 것”이 아니라,

공격을 설명할 수 있는 로그를
사전에 정의하고 연결하는 것입니다.

6) 전통 로그와 실제 조사 가능한 로그의 차이

구분	전통적인 로그 수집	조사 가능한 로그 수집
웹 로그	URL, 상태코드 중심	요청·응답 본문 포함
OS 로그	기본 이벤트 위주	감사정책 기반 상세 로그
공격 분석	접속 흔적 확인	행위 흐름 재구성
사고 대응	추정 중심	근거 중심
AI 분석 적합성	낮음	높음

즉,
로그의 양이 중요한 것이 아니라,
공격을 설명할 수 있는 깊이와 연결성이 중요합니다.

7) 이 신화를 극복하는 현실적인 방법

“사고가 나면 로그를 보면 된다”는 말은
기록 체계가 준비된 조직에서는 맞을 수 있습니다.

하지만 준비되지 않은 조직에게는
그 말은 신화에 불과합니다.

현실적인 방법은 단순합니다.

필요한 감사정책을 먼저 설정하고
웹 요청·응답 본문을 남기며
로그를 실시간으로 연결해 분석할 수 있어야 합니다

그리고 이 과정을
운영자가 매번 수작업으로 반복하기는 어렵습니다.

8) PLURA는 여기서 어떤 역할을 하나

PLURA는
이 신화를 극복하는 현실적인 방법 중 하나를 제공합니다.

감사정책 설정
웹 요청 및 응답 본문 로깅
운영체제·웹·계정 로그의 통합 분석
실시간 탐지와 대응

즉,
PLURA의 핵심은
“로그를 더 많이 쌓는 것”이 아니라,

실제로 해킹을 설명할 수 있는 로그를 남기고,
그 로그를 실시간으로 연결해 보는 것입니다.

로그 분석이 현실이 되려면
도구보다 먼저 철학이 필요하고,
그 철학을 실제 운영으로 옮길 수 있는 체계가 필요합니다.

PLURA는 바로 그 지점을 지원합니다.

결론

“로그 분석으로 해킹 조사를 할 수 있다”는 말은
절반만 맞습니다.

정확히 말하면,

필요한 로그가 사전에 준비되어 있을 때만
로그 분석은 현실이 됩니다.

그 준비가 없다면
로그 분석은 사고 이후에 기대하는 막연한 희망,
즉 신화에 가깝습니다.

로그는 저절로 생기지 않습니다.
조사를 가능하게 하는 로그는 더더욱 저절로 생기지 않습니다.

따라서 보안에서 먼저 해야 할 일은
사고 후 분석 방법을 고민하는 것이 아니라,

사고가 났을 때 반드시 설명할 수 있도록
무엇을 기록할지 지금 결정하는 것입니다.