[Cloud & CERT] 조사 3. CERT 인프라 설계(김태형)

🎯 목표 설정

이전 과정들을 통해 서비스와 네트워크 구축이 끝났다. 그럼 이제 그냥 서비스를 운영하면 될까?

우리는 보안 관점에서 안전한 서버 사이드 설계를 마쳤고, 네트워크 배치까지 완성 했지만 그렇다고 시스템이 안전하다고 볼 수는 없다.

내부 시스템에 존재하는 보안 취약점이 있을 수도 있고, 내부자의 실수로 데이터가 유출될 수도 있으며, 악의적인 공격자가 시스템을 지속적으로 공격할 수도 있다. 하지만, 관리자가 내부 시스템에서 어떤 일들이 일어났는지 확인할 수 있는 방법이 없다면 이를 알아챌 수도, 방어할 수도, 대응할 수도 없다.

이번 과정에서는 정보보호 침해사고로부터 우리의 서비스와 네트워크를 보호하고 관리하기 위해 무엇이 필요한지 또, 어떻게 구현해야 하는지에 대해 배워볼 것이다.

🛡️ AWS CERT 인프라 설계

1️⃣ 서버에서 무슨 일이 일어났는지 알아내자

Endpoint Telemetry - 서버의 행위를 관찰하는 데이터

새벽에 WAS 서버에서 알 수 없는 프로세스가 실행됐다는 경보가 발생해, 아침에 서버에 접속해 확인해 보았다고 상황을 가정해보자. 이미 프로세스는 종료되어 ps 명령에서 보이지 않고 history 기록도 비워져 있다.

즉, 이상 징후는 확인했지만 그 원인과 발생한 피해를 알아낼 수 있는 행위 기록이 없는 것이다.

따라서 사고를 분석하려면 현재 상태뿐 아니라 누가 어떤 행위가 언제 발생했는지에 대한 과거 행위를 지속적으로 기록해야 한다.

Endpoint Telemetry는 서버나 사용자 PC와 같은 단말기에서 관찰하고 수집한 행위 및 상태 데이터를 의미한다.

그리고 우리가 이번 설계에서 수집해야하는 Endpoint Telemetry는 다음과 같다.

구분	수집할 이벤트	주요 기록 항목
누가 실행했는가?	로그인, 인증, 권한 변경	계정, 세션 식별자, 실행 권한
무슨 명령을 실행했는가?	프로세스 실행 기록	실행 파일 경로, 명령행 인수, PID/PPID
어떤 파일을 만들거나 변경했는가?	파일 생성・수정・삭제・권한 변경	파일 경로, 작업 종류, 수행 프로세스와 계정
어떤 IP에서 통신했는가?	네트워크 연결 시도와 결과	출발지・목적지 IP와 포트, 프로토콜

행위 기록은 어떻게 생성되는가?

Linux 서버를 기준으로 보았을 때, 인증 로그와 감사 기능 등을 기본적으로 제공하지만, 우리가 필요한 프로세스 실행・파일 변경・네트워크 연결 정보를 기록하려면 수집 범위를 미리 설정해주어야 한다.

예를 들어 Linux의 감사 서비스인 auditd를 활용해 특정 프로그램 실행이나 파일 작업을 기록할 수 있다. 필요한 항목에 따라 별도 수집 Agent를 사용할 수도 있다. Agent는 서버와 같은 단말기에 설치되어 데이터를 수집・전송하거나 조사 작업을 수행하는 프로그램이다.

서버 안에만 기록하면 충분할까?

각 서버에 Endpoint Telemetry를 기록한다고 해도 서버가 여러 대라면 사고 발생 시 각 서버에 접속해 기록을 확인해야 하고, 공격자가 충분한 서버 권한을 가졌으면 내부 기록을 삭제하거나 수집 기능을 중지할 수도 있다.

따라서, 필요한 이벤트를 서버 밖의 중앙 시스템으로 지속 전송하고 보관하는 구조가 필요하다.

중앙 로그 관리

각 서버에서 수집한 기록을 중앙 시스템으로 전송하면, 관리자는 여러 서버에서 발생한 행위를 한곳에서 검색하고 시간순으로 확인할 수 있다.

그런데 기록을 한곳에 모았다고 해서 의심스러운 행위를 자동으로 알아낼 수 있는 것은 아니며, 서버에서 발생하는 수많은 이벤트를 관리자가 매번 직접 확인하는 것은 어렵다. 따라서 수집한 기록을 분석해 위협이 의심되는 행위를 찾아내고, 조사와 대응으로 연결하는 기능이 필요하다.

이를 도와주는 것이 바로, EDR이다.

EDR - 행위 기록을 위협 탐지와 대응으로 연결

EDR은 Endpoint에서 발생하는 행위를 관찰하고 위협을 탐지・조사・대응하는 것을 지원하는 보안 솔루션으로 Endpoint Telemetry 데이터를 활용해 어떤 행위가 의심스러운지, 어떻게 조사하고 대응할지를 판단하도록 돕는 역할을 한다.

앞서 가정했던 상황을 다시 생각해 보자. Endpoint Telemetry를 수집하고 있다면, 관리자는 EDR을 통해 해당 프로세스를 실행한 계정과 상위 프로세스, 관련 파일 및 네트워크 연결을 확인하며 원인과 영향을 조사할 수 있다.

그리고 조사 결과 위협으로 판단되면, EDR 솔루션과 운영체제가 지원하는 범위에서 프로세스를 종료하거나 서버의 네트워크 통신을 제한하는 등의 대응 수행이 가능하다.

대표적인 EDR 오픈소스 도구로는 OpenEDR이 있다. 팀 근두운 인프라에서는 Wazuh SIEM을 사용하고 있기 때문에, Wazuh Agent로 일부 EDR 역할을 하도록 설계한다.

DFIR - 사고 원인과 피해조사

EDR을 통해 의심스러운 행위를 발견하고 해당 프로세스를 종료했다고 해서 사고 대응이 끝난 것은 아니다.

공격자가 어떻게 서버에 접근했는지, 다른 서버에도 침입했는지, 데이터가 외부로 유출됐는지를 확인하고, 서비스를 안전하게 복구하는 과정이 필요한데, 이러한 일련의 과정을 DFIR(Digital Forensics and Incident Response)라고 정의한다.

DFIR은 용어의 의미대로 디지털 포렌식과 침해사고 대응의 합성어이다.

디지털 포렌식을 통해 로그・파일・메모리 등에 남아 있는 디지털 증거를 수집・보존・분석하여 어떤 일이 일어났는지 확인하고, 침해사고 대응을 통해 사고를 판단하고, 피해 확산을 억제하며, 공격 원인을 제거 후 서비스를 복구하는 과정을 거치게 된다.

대표적인 DFIR 오픈소스 도구로는 Velociraptor가 있다.

CERT 인프라 설계의 첫 번째 단계는 각 서버의 Endpoint Telemetry를 수집하고 중앙에서 보관・분석하여, 위협 탐지부터 사고 조사와 대응까지 이어지는 기반을 마련하는 것이다.

2️⃣ 서버 여러 대의 로그를 한 곳에서 보자

앞 단계에서 각 서버의 Endpoint Telemetry를 기록하고 EDR과 DFIR을 활용하여 수집, 탐지, 조사, 분석이 가능한 구조를 만들었다. 각 Agent를 통해 수집한 로그를 하나의 서버에서 확인할 수 있다.

현재는 Agent가 설치되어 있는 Endpoint에 대한 로그만을 수집하여 보고 있는데, 이는 시스템 전체의 보안 이벤트나 로그를 확인하기에는 역부족이다.

우리는 AWS 시스템에서 발생하는 침해사고를 탐지・조사・분석하려면, 계정 내 API 호출을 기록하는 CloudTrail, 보안그룹에 의해 ACCEPT/REJECT된 네트워크 트래픽 등과 같은 AWS 관리형 서비스 로그도 기록・수집 하여야 한다.

그럼 이제 EDR 솔루션(여기선 Wazuh Agent)의 탐지 결과와 DFIR Agent(Velociraptor)가 수집한 이벤트, AWS 관리형 서비스 로그를 각각의 서버 또는 서비스에 접근하여 확인할 수 있다.

하지만, 이를 확인해 보면, 로그 형식과 시간대가 제각각인 것을 볼 수 있다. 이로인해 관리자는 인프라에서 발생한 공격을 추적하려면 각각의 서버 또는 서비스에 접근하여 서로 다른 포맷의 로그, 타임라인 분석을 위해 시간대도 맞춰가면서 일일이 확인해야하는 번거로움을 겪는다.

이는 빠른 대응을 요구하는 보안 침해사고에 있어서 매우 큰 리스크가 된다. 그렇기 때문에, CERT 인프라를 설계할 때, 서로 다른 출처의 로그를 같은 기준으로 비교하고 연결하며, 분석할 수 있는 환경을 만들 필요가 있다.

Centralized Logging - 중앙 로그 관리

앞서 Agent를 통해 여러 서버의 Telemetry를 하나의 서버에서 관리하는 환경을 만들었다. 이러한 개념도 Centralized Logging이라고 볼 수 있지만, 우리는 인프라 전체에 대한 보안 감사를 위해 Agent가 탐지한 결과 뿐만 아니라, AWS 관리형 서비스 로그도 하나의 서버에서 확인할 수 있어야 비로소 중앙 로그 관리를 달성 했다고 말할 수 있다.

Log Normalization - 로그 정규화

그러면 로그들을 하나의 서버로 모으기만 하면 될까? 그렇지 않다.

앞서 언급한 것처럼 보안 솔루션이 생성하는 결과와 AWS 관리형 서비스 로그의 형식은 모두 다르다. 가장먼저, 우리는 중앙 로그 관리 달성을 위해 공통된 기준으로 로그 포맷을 통일 시켜줘야 한다.

이러한 과정을 Log Normalization이라고 부르며, 정적분석 도구가 AST 구조로 파싱하는 것과 비슷한 개념이라고 생각하면 된다.

NTP - 시간 동기화

두 번째로는 로그를 발생시키는 각각의 서버 및 서비스의 시간과 시간 표현(UTC, KST)을 맞춰 중앙 로그 관리 화면에서 같은 시간축으로 로그를 확인할 수 있게 해야 한다.

AWS에서는 별도 NTP 서버 없이, Amazon Time Sync Service로 시간 동기화가 가능하다.

로그 정규화와 시간 동기화까지 완료하고 나면, 비로소 중앙 로그 관리 환경이 완성된다.

그런데, 중앙 로그 관리 서버에서 로그를 확인하는데, 하루 수백만 줄이 쌓여 관리자가 읽을 수 없고, 어떠한 이벤트가 발생했는지 알려주지 않아 관리자의 피로도가 여전히 크다.

효율적으로 침해사고를 탐지・조사・분석하기 위해서는 로그들을 중앙으로 모으고 난 후에 해당 로그를 보고, 의심되는 행위에 대한 보안 이벤트를 탐지하여 알려주는 시스템이 필요하다.

이 역할을 하는 보안 도구가 바로 SIEM(Security Information and Event Management)이다.

SIEM - 여러 출처의 로그와 이벤트 데이터를 종합하여 탐지・분석

SIEM은 다양한 보안 장비에서 찍히는 개별 Security Event(보안 이벤트)를 Detection Rule(탐지 룰)에 따라 분석한 뒤 알람을 발생해주고, 대시보드에 실시간으로 시각화 해준다.

Detection Rule은 SIEM 장비 자체에서 기본적으로 제공하는 규칙도 있지만, 대부분의 SIEM 솔루션은 관리자가 커스텀 탐지룰을 설계하여 운영할 수 있다.

그리고, SIEM은 개별 이벤트를 탐지하는 것뿐 아니라, 여러 이벤트의 관계를 분석하는 Correlation(상관분석)도 지원한다.

예를 들어 WEB 서버에서 로그인 실패가 반복되고, 이후 같은 계정으로 로그인이 성공했다고 가정해 보자. 각각의 기록만 보면 비밀번호를 잘못 입력한 사용자가 정상적으로 로그인한 상황일 수도 있다. 하지만 로그인 성공 직후 해당 계정이 평소 사용하지 않던 관리자 기능에 접근했다면, 계정 탈취 가능성을 의심해 볼 수 있다.

이처럼 여러 기록을 공통된 정보와 시간 흐름에 따라 연결하면, 개별 이벤트만으로는 파악하기 어려웠던 의심스러운 행위의 흐름을 발견할 수 있다.

관리자는 이러한 관계를 탐지 조건으로 정의하여 “같은 IP와 계정으로 5분 동안 로그인 실패가 5회 이상 발생하고, 이후 5분 안에 로그인이 성공하면 경보를 생성한다”라는 상관 규칙을 구성할 수 있는 것이다.

따라서 SIEM의 상관분석은 로그 정규화와 시간 동기화라는 기반 위에서 여러 시스템의 기록을 연결하여, 관리자가 공격의 흐름과 영향을 조사하도록 도와주는 핵심 역할을 한다.

이로써 두 번째 CERT 인프라는 SIEM 솔루션을 통해 여러 출처의 보안 이벤트를 정규화하여 상관분석하는 환경을 만드는 것이다.

SIEM 오픈소스 도구는 Wazuh, ELK 스택 등이 있다. 현재 팀 근두운 인프라에서는 Wazuh SIEM을 활용할 계획이다.

3️⃣ 탐지된 IP가 공격자인지 어떻게 판단할 수 있을까

SIEM 장비에서 평소 통신하지 않던 Source IP 185.X.X.X가 반복적으로 탐지 되었다면, 공격자라고 단정할 수 있을까? 해당 IP가 비정상적인 활동을 했다는 연결 되는 보안 이벤트가 있다면 의심할 수는 있겠지만 단순 IP만으로는 공격자의 접근 시도라고 판단하기 매우 어렵다.

그래서 여러 기업/기관에서는 위협 정보를 서로 공유하는데, 이를 Threat Intelligence(위협 인텔리전스)라고 한다.

Threat Intelligence

위협 인텔리전스(TI)는 공격 대상・수법・인프라 등에 관한 정보를 수집하고 분석하여 보안 판단에 활용하는 행위이다. 그중 IP Reputation은 해당 IP가 스캔, 로그인 공격, 악성코드 통신 등에 연관되어 관찰・신고됐는지를 나타내는 정보로 이를 통해 탐지된 Source IP가 공격자 IP인지 판단할 수 있게 도와준다.

그리고 이뿐만 아니라, 악성 도메인(Malicious Domain), 파일 해시 정보도 받아올 수 있는데 이러한 정보들이 바로 TI에서 받아오는 핵심 IoC(Indicator of Compromise, 침해 지표)이다.

IoC 유형	의미
IP 주소	공격 시도나 악성 통신에 사용된 것으로 알려진 주소
악성 도메인	피싱이나 악성코드 통신 등에 사용한 도메인
파일 해시	파일 내용으로 계산한 식별값

외부 위협 정보와 내부 로그를 대조하는 기준

IoC는 악성 활동과 관련된 흔적을 찾기 위한 단서이며, 우리 시스템에서 해당 값이 관찰되었는지 확인하는 기준이 된다. 이러한 지표는 제공 기관의 API나 Feed를 통해 받아올 수 있으며, SIEM의 조회 목록과 탐지 규칙에 연결하면, 내부 로그에 등장한 IP・도메인・파일 해시를 알려진 위협정보와 자동으로 대조할 수 있다.

외부에서 받은 IoC	내부에서 대조할 항목
악성 활동 관련 IP	VPC FLow Logs・접속 로그의 출발지 또는 목적지 IP
악성 도메인	DNS 질의 로그 등에 기록된 도메인
악성 파일의 해시	FIM・DFIR 수집 결과의 파일 해시

Wazuh SIEM의 경우는, 외부 IoC를 Wazuh가 조회할 수 있는 CDB(Constant Database) 목록으로 변환하고, 탐지 규칙을 통해 내부 로그의 필드값과 비교한다. CDB 목록은 특정 IP・도메인・해시 등이 목록에 포함되어 있는지 빠르게 확인하기 위한 조회 목록을 말한다.

예를 들어 WAS 서버의 통신 목적지 IP가 유효한 악성 IP 목록에 포함되어 있으면 일치 경보를 생성하고, 이후 같은 서버에서 발생한 의심 프로세스 실행 기록 등을 함께 연결하면, 외부 위협 정보와 내부 행위를 결합한 상관분석이 가능한 것이다.

다만 IoC 일치는 침해사고의 확정이 아니라 조사 근거이며, 정보의 최신성과 출처, 실제 통신의 허용 여부, 관련된 내부 행위를 함께 확인하여 판단해야 한다.

TIP - 여러 출처의 IoC를 통합 관리

그런데, 외부 위협정보 소스가 여러 개로 늘어나면 새로운 문제가 생긴다. 소스마다 정보 형식이 다르고, 같은 IoC가 중복되거나 출처와 관찰 시점, 신뢰도도 달라지기 때문이다. 한 소스에 특정 IP가 등록되어 있지 않다고 해서 그 IP가 안전하다는 뜻도 아니다.

따라서 여러 출처의 위협정보를 한곳에 모아 공통된 형식으로 정리하고, 출처・신뢰도・유효성을 관리하는 체계가 필요하다. 이러한 역할을 수행하는 플랫폼을 TIP(Threat Intelligence Platform)라고 하며, 대표적인 오픈소스 도구로는 MISP, OpenCTI가 있다.

관리 항목	목적
IoC 유형과 값	IP・도메인・파일 해시를 구분하고 공통 기준으로 정리
출처와 판단 근거	어떤 기관이 무엇을 관찰했는지 확인
신뢰도	근거의 확실성을 평가하고 활용 우선순위 결정
최초・최근 관찰 시각	정보의 최신성 확인
유효기간・만료 상태	오래된 지표가 계속 탐지에 사용되는 문제 방지
중복・예외 정보	출처별 근거를 보존하면서 중복과 오탐 관리

4️⃣ 공격자를 발견했다면, 이제 어떻게 대응할 것인가?

앞 단계에서 내부 로그와 외부 위협정보를 연결하여 의심스러운 활동을 판단할 수 있게 되었다. 그런데 공격자가 발견되어 SIEM에서 알림을 생성했지만, 담당자가 이를 늦게 확인하고 차단하는 조치를 했다면 어떻게 될까?

탐지가 정상적으로 동작 했어도 실제 대응까지 시간이 걸리는 동안 공격이 계속될 수 있었을 것이다. 따라서 CERT 인프라는 위협을 발견하는 것뿐 아니라, 탐지 결과를 적절한 대응으로 연결하는 구조를 갖추는 것도 중요하다.

Incident Response・Containment - 탐지를 피해 확산 방지로 연결

Incident Response(침해사고 대응)는 사고를 분석하고, 피해 확산을 억제하며, 공격 원인을 제거하고 서비스를 복구하는 일련의 과정을 말한다.

여기서 Containment(봉쇄・격리)는 공격이 더 이상 진행되거나 다른 시스템으로 확산되지 않도록 제한하는 단계로, 악성 IP의 웹 요청을 차단하거나, 탈취된 계정의 접근을 제한하거나, 침해된 서버를 네트워크에서 격리하는 조치 등이 해당한다.

다만 IP를 차단 했다고 사고 대응이 끝나는 것은 아니다. 이미 서버에 침입 했거나 다른 접근 수단을 확보했을 수도 있으므로, 관련 증거를 보존하고 침해 범위와 원인을 조사하는 과정이 뒤따라야 한다.

Automation - 대응을 자동화

관리자가 탐지된 알림을 확인하지 못하고, 즉각적인 대응이 불가능한 상황을 해소하려면 탐지 결과에 적절한 대응 작업을 실행하도록 연결해야 하는데, 이를 Automation(자동화)라고 한다.

예를 들어 내부 시스템에 악성 IP의 행위가 판단되어 SIEM이 탐지 결과를 생성 했다면, 해당 IP를 자동으로 차단하게 끔 만드는 것이다. AWS 인프라에서 예시를 든다면, WAF의 차단용 IP 목록에 해당 주소를 자동으로 추가하도록 구성하면 된다.

False Positive・Confidence - 오탐과 신뢰도

그런데, 자동 차단이 항상 좋을까? 꼭 그렇지는 않다.

만약 위협정보 소스 하나가 정상적인 IP를 악성 IP로 잘못 등록했다면, 자동 대응에 의해 정상적인 접근을 차단하는 상황이 발생할 수도 있다.

이처럼 정상적인 활동을 위협으로 잘못 판단하는 것을 False Positive(오탐)라고 한다. 자동화는 대응 시간을 줄여주지만, 오탐으로 인한 서비스 장애도 일으킬 가능성이 있다.

따라서 자동 대응 여부는 Confidence(신뢰도)와 조치의 영향을 함께 고려해야 한다. 외부 위협 정보 하나만으로 판단하기보다는, 실제 공격 행위, 대상 자산의 중요성, 차단 범위와 복구 가능성을 함께 확인하여 우선순위를 정하는 것이 중요하다.

ex) 오탐 가능성이 있거나, 자동 차단 시 가용성을 저해할 수 있는 경우 관리자의 추가 조사나 모니터링이 필요한 것으로 Low Confidence로 분류

Playbook - 대응 조건과 절차 정의

Playbook은 특정 보안 침해사고가 발생했을 때, 어떻게 대응해야 하는지 단계별로 정의한 대응 절차서이다.

단계별 구성요소	역할
트리거	Playbook을 시작할 조건
분석 및 검증	탐지된 위협이 정탐인지 오탐인지 확인하는 단계(Confidence 확인)
격리 및 대응	공격의 확산을 막는 조치
치료 및 복구	피해 시스템을 정상 상태로 돌려놓는 단계
사후 보고	사건 발생 원인을 분석하고 플레이북을 개선하는 단계

보안 침해사고에 대응하기 위해서 보안팀에서는 자동 차단의 기준과 허용 범위를 포함한 Playbook을 사전에 정의하는 것이 필요하다.

SOAR - Playbook과 승인 절차를 시스템으로 실행

그런데 Playbook이 문서로만 정의되어 있으면, 관리자는 여전히 수동으로 시스템에 접속해 대응을 수행해야 한다.

SOAR(Security Orchestration, Automation and Response)는 여러 보안 도구를 연결하고, 정해진 Playbook을 자동으로 실행하도록 돕는 플랫폼이다.

예를 들어 SIEM의 경보를 받은 뒤 TIP에서 위협정보를 확인하고, 자동 차단 기준을 검사한 다음, 조건에 따라 자동 차단하거나 관리자의 승인(Approval Workflow)을 대기하도록 구성할 수 있게 된다.

여기서 Approval Workflow(승인 절차)는 영향이 큰 작업을 실행하기 전에 권한 있는 관리자의 판단을 받도록 하는 과정으로, 승인 요청에는 탐지 근거, 대상, 예상 영향, 차단 기간과 복구 방법을 함께 전달해야 한다. 승인이 거부되거나 정해진 시간 안에 관리자의 응답이 없으면 자동 차단을 실행하지 않고 알림을 다시 보내거나 상위 관리자에게 전달하도록 설계하면 된다.

그리고, 대응 작업 이후에는 실행 결과와 승인 이력을 기록하고, 실제 적용 여부를 점검한다.

따라서 네 번째 CERT 인프라 설계의 목표는 모든 탐지결과에 대한 알림을 자동으로 차단하는 것이 아니라, 신뢰도와 영향에 따라 자동 대응과 관리자의 승인 절차를 구분하는 것으로 한다.

5️⃣ 사고를 조사하고, 판단의 근거를 남기자

앞 단계들을 통해 CERT 인프라 설계를 마쳤다. 이제 실제 사고가 났다고 가정하고, 사고를 조사해보자.

사고 예시

03:12 의심 프로세스 실행

03:14 외부 IP 접속

03:17 의심 파일 생성

03:23 다른 서버 접근 시도

이 사고 기록들은 각각 서버의 감사 로그, 네트워크 로그, 파일 변경 기록 등에 남아 있을 수 있다. 이제는 CERT 인프라에서 흩어진 기록을 연결하여 시간 순으로 어떤 일이 일어났고, 어디까지 영향을 받았는지 조사한다.

Incident Timeline - 흩어진 기록을 시간순으로 연결

Incident Timeline(사고 타임라인)은 사고와 관련된 행위와 대응 조치를 시간순으로 정리한 기록이다. 각 사건에 발생 시각, 대상 서버, 계정, 수행 행위와 증거를 연결하여 사고의 흐름을 재구성한다.

이때 SIEM에 로그가 도착한 시간과 실제 보안 이벤트가 발생한 시간을 구분해야 한다. 실제로 Wazuh SIEM의 경우에는 aws-s3 모듈로 S3 버킷에 저장되고 있는 AWS Native 로그를 가져올 수 있는데, 실시간으로 로그를 가져오는 방식이 아닌, 모듈 활성화 시 설정한 interval 에 맞춰 수집하기 때문에 실제 이벤트가 발생한 시간과 Wazuh Dashboard에서 경보를 발생해 주는 시간의 오차가 발생한다.

MITRE ATT&CK - 관찰된 공격 행위의 목적과 방법을 분류

Timeline은 보안 이벤트를 시간 순으로 정리한 것이라고 하면, MITRE ATT&CK는 공격자의 행위를 공통된 공격 전술 단위로 분류하는 기준이 된다.

공격 전술	의미	분류에 필요한 근거
Initial Access	최초 시스템 접근	외부 로그인 등 진입 경로, 취약점 악용
Execution	악성 코드나 명령 실행	실행 기록과 명령 내용
Persistence	재접속 가능하도록 접근 유지	지속 접근을 위한 설정
Lateral Movement	다른 내부 시스템으로 이동	East-West Traffic, 다른 서버에 대한 원격 로그인・실행 기록과 성공 여부
Command & Control	침해된 시스템과 공격자 서버의 통신	악성 도메인으로의 연결, 외부 통신 기록, 원격 명령 전달이나 반복 통신 패턴

우리는 사고 조사를 위해 관련 기록을 시간순으로 연결하고, 나아가 확인된 공격 행위를 MITRE ATT&CK의 전술과 기술에 매핑한다면 인프라의 보안 공백이 어디서 발생하는지 쉽게 알 수 있을 것이다.

다만 시간적으로 가까운 사건이라고 해서 모두 같은 공격에 의한 것이라고 단정할 수는 없다. 각 행위를 연결하는 근거를 확인하고, 확인된 사실과 추정을 구분해야 한다.

Evidence・DFIR - 판단의 근거를 확보

실제로 의심 파일이 생성 되어 파일 변경 알림이 발생해도, 이 알림 만으로는 파일의 목적까지 알 수는 없기 때문에실제 파일의 내용과 해시, 관련 실행 기록, 자동 실행 등록 여부 등을 추가로 조사해야 한다.

이때 판단을 뒷받침하는 로그・파일・메모리 자료 등을 Evidence(증거)라고 한다. 앞서 소개한 DFIR 도구인 Velociraptor를 활용해 필요한 자료를 수집하고, Wazuh에서 확인한 기록과 함께 분석할 수 있다. 그리고, 분석 결과를 타임라인에 연결하면, 강력한 사고 조사 보고서를 만들 수 있을 것이다.

Case Management - 조사 과정과 결과를 사건 단위로 관리

타임라인을 만들고, MITRE ATT&CK의 전술과 기술에 매핑하여 조사 결과를 남겼다. 하지만, 조사 결과만 남기면 다른 담당자는 어떤 자료를 어떻게 분석 했는지 알기 어렵고, 다음 사고 때 이 조사 과정을 재현 하기도 힘들다. 따라서, 사고의 조사 과정에서 발견된 경보, 증거, 타임라인, 대응 이력 등을 함께 관리할 필요가 있다.

이처럼 한 사고의 조사 과정과 결과를 사건 단위로 관리하는 것을 Case Management라고 한다.

각 사건에는 사건 번호를, 각 증거에는 증거 식별자를 부여해 타임라인에서 증거 식별자를 참조하도록 구성하면, 조사 과정을 재현할 때 판단의 근거를 쉽게 찾아 확인할 수 있다.

Chain of Custody - 증거의 취급 이력을 보존

그리고, 증거는 수집한 이후에도 누가 언제 수집・전달・분석했는지 추적할 수 있어야 하고, 무결성을 보장해야 한다.이처럼 증거를 보관, 관리, 인계, 분석 등의 모든 이력을 Chain of Custody라고 한다.

위 개념들을 활용해 사고의 타임라인을 작성해보면, 다음과 같은 결과를 만들 수 있다.

사고 타임라인

발생 시각	사건・행위	MITRE ATT&CK	확인 도구	근거 데이터
미확인	최초 침입	Initial Access	Wazuh, Velociraptor	WAF・웹 접근 로그
03:12	의심 프로세스 실행	Execution	Wazuh, Velociraptor	auditd의 감사 로그, 실행 파일 경로, 명령행, 계정, PID・PPID
03:14	외부 IP로 통신	Command & Control	Wazuh, MISP Velociraptor	VPC Flow Logs, IoC
03:17	의심 파일 생성	Persistence	Wazuh FIM, Velociraptor	파일 변경 이벤트, 경로, 해시, 파일 내용
03:23	다른 서버로 접근 시도	Lateral Movement	Wazuh, Velociraptor	양쪽 서버의 네트워크 기록, 대상 서버 인증 로그, 원격 실행 기록

💁 마무리

이번 과정에서는 설계한 서버와 네트워크 인프라에 보안 업무 수행을 위한 CERT 인프라를 더했다. 인프라의 보안 유지를 위해 활용할 수 있는 보안 개념과 도구에 대해 이해 하였고, 실제 사고를 가정해 타임라인 분석을 통해 사고 조사 과정도 함께 배울 수 있었다.

다음에는 각 조사 단계별로 우리 팀 근두운 인프라가 아직 완성하지 못한 단계가 어디인지 비교해 현재 구성의 문제점을 파악하고, 어떻게 개선해 나갈지 고민하는 시간을 가져볼 것이다.