한줄 결론: CERT 인프라는 로그 저장소 하나가 아니라 Endpoint 기록, 중앙 수집, 탐지·상관분석, 위협 정보, 대응 자동화, 사건 관리와 증거 보존을 연결한 체계다.
CERT(Computer Emergency Response Team)는 침해사고를 조사하고 대응하는 조직이다. 사고가 났을 때 서버에 접속해 현재 상태만 확인하면, 이미 종료된 명령이나 삭제된 파일을 놓칠 수 있다.
따라서 평소에 기록을 모으고, 여러 기록을 연결해 사건을 판단하고, 필요한 조치와 증거를 남길 수 있는 기반이 필요하다.
이 글은 근두운 프로젝트의 Wazuh·Falco·AWS 로그를 바탕으로 한 CERT 인프라 설계 보고서다. 도구를 많이 설치하는 것보다 하나의 사고를 처음부터 끝까지 설명할 수 있는 흐름을 만드는 데 목적이 있다.
현재 확인된 내용과 설계안을 구분하기
CERT 인프라를 기능 중심으로 나누면 다음과 같습니다.
근거: ,
2. Mission 1 · 서버에서 무슨 일이 있었는가?
현재 화면보다 평소 기록이 중요하다
ps는 현재 실행 중인 프로세스를 보여주고, history는 모든 명령 실행을 완전하게 남기는 보안 기록이 아니다. 사고 전후를 조사하려면 아래 기록을 지속적으로 수집해야 한다.알고 싶은 것 | 필요한 기록 | 대표 내용 |
누가 접속했나? | 로그인·인증 로그 | 사용자, 접속 시각, 성공·실패 |
어떤 명령이 실행됐나? | 프로세스 실행 기록 | 실행 파일, 명령, 부모 프로세스 |
어떤 파일이 바뀌었나? | 파일 변경 기록 | 파일 경로, 생성·수정·삭제 |
어디와 통신했나? | 네트워크 연결 기록 | 출발지·목적지 IP, 포트 |
어떤 AWS 권한을 썼나? | CloudTrail | Role, API 이름, 대상 리소스, 오류 |
같은 IP라는 이유만으로 같은 공격이라고 확정하지 않는다. WAF의 요청자 IP는 외부 사용자, CloudTrail의 출발지 IP는 EC2나 NAT 쪽 주소일 수 있다. ALB 뒤에 서버가 여러 대라면 애플리케이션 요청 ID와 대상 서버 기록이 있어야 더 정확히 연결할 수 있다.
4. Mission 3 · 외부 위협 정보로 판단 보강하기
내부 기록이 “무슨 행동이 있었나?”를 보여준다면 Threat Intelligence(위협 정보)는 그 IP·도메인·파일이 외부에서 어떻게 관찰됐는지 알려준다.
IOC(공격 흔적)는 비교 가능한 단서다. 대표적으로 IP, 도메인·URL, 파일 해시가 있다. 해시는 파일 내용을 바탕으로 만든 식별값이다.
예를 들어 내부 서버가 접속한 IP가 악성 활동과 관련됐다는 외부 정보가 있다면 조사 우선순위를 높일 수 있다. 그러나 공유 IP, 오래된 정보, 잘못된 분류도 있으므로 일치만으로 공격을 확정하지 않는다.
확인할 항목은 출처, 관찰 시점, 신뢰도, 유효기간, 내부 행동과의 관계다. 여러 정보원이 같은 원본을 복사한 경우 독립적인 증거 여러 개로 세지 않는다.
위협 정보 플랫폼은 언제 필요한가?
여러 곳의 위협 정보를 모아 중복을 정리하고 출처와 관계를 관리하는 도구가 TIP(위협 정보 플랫폼)이다.
- 수집 상태: 로그 전달이 끊기거나 늦어지면 담당자가 알 수 있게 합니다.
초기에는 출처와 만료 기준을 갖춘 작은 IOC 목록으로 시작할 수 있다. 플랫폼 구축은 기본 수집·탐지 흐름을 확인한 뒤 결정한다.
5. Mission 4 · 탐지 후 어떻게 대응할 것인가?
모든 경고를 자동 차단하지 않는다
오탐은 정상 행동을 공격으로 잘못 판단한 경우다. 예를 들어 정상 관리 작업의 Shell 실행을 공격으로 보고 서버를 격리하면 서비스가 중단될 수 있다.
대응은 내부 증거, 자산의 중요도, 판단 신뢰도, 조치 영향을 함께 고려한다.
외부 위협 정보는 알려진 악성 IP, 도메인, 파일의 특징이나 공격 수법에 관한 자료입니다. 내부에서 발견한 흔적과 비교하면 조사의 우선순위를 정하는 데 도움이 됩니다.
위협 정보가 없어도 명확한 내부 증거가 있으면 대응할 수 있다. 반대로 여러 평판 정보가 일치하더라도 내부 상황을 확인해야 한다.
대응 절차를 정해 반복 가능한 작업으로 만들기
Playbook은 “이 경고가 오면 어떤 순서로 조사·대응할지” 적은 절차다. 이를 조회·분기·승인·조치·기록까지 자동 실행하는 도구가 SOAR다. Shuffle을 후보로 검토하되, 초기에는 절차 하나를 먼저 완성한다.
의심 EC2 대응 절차
- 경고와 원본 이벤트를 사건 번호로 묶는다.
- 대상 EC2, Role, 최근 명령과 AWS 호출을 확인한다.
- 추가 증거를 보존하고 서비스 영향을 검토한다.
- 담당자가 격리 여부와 범위를 승인한다.
- 격리용 SG 등 정해진 방법으로 접근을 제한한다.
- 새 연결과 기존 연결이 실제로 차단됐는지 확인한다.
- 승인자, 조치 시각, 변경 전후 설정을 기록한다.
- 원인을 제거하고 승인 후 정상 설정으로 복구한다.
복구 방법도 대응 절차의 일부다. 격리 전에 원래 SG 목록을 저장하고, 조사용 관리·로그 경로의 유지 여부와 조치 재검토 시점을 정한다.
SG 변경만으로 기존 연결이 모두 즉시 끊기는 것은 아니다. 급한 차단에는 실제 연결 상태와 필요 시 추가 통제를 검토해야 한다.
자동화는 어디에 쓰는가?
SOAR는 여러 보안 도구를 연결해 반복 작업을 자동으로 처리하도록 돕는 체계입니다. 경고에 관련 로그를 붙이거나, 외부 정보를 조회하거나, 사건 기록을 만드는 작업부터 적용할 수 있습니다.
계정 정지나 서버 격리처럼 서비스에 영향을 주는 조치는 적용 조건, 승인 담당자, 되돌리는 방법을 미리 정합니다. 자동화 결과가 예상과 달랐을 때 중단하고 확인할 수 있어야 합니다.
7. Mission 5 · 사건과 증거를 추적 가능하게 남기기
사건 기록은 담당자가 바뀌어도 조사와 대응을 이어갈 수 있게 합니다. 대응 과정에서 확인된 사실, 아직 확인하지 못한 내용, 판단 근거를 구분해 적습니다.
남길 항목 | 작성 내용 |
사건 개요 | 발견 시각, 영향을 받은 대상, 담당자 |
시간 순서 | 주요 행동·탐지·조치가 발생한 시각 |
판단 근거 | 원본 로그 위치, 검색 조건, 관련 파일 |
조치와 결과 | 누가 무엇을 했고 어떤 효과가 있었는지 |
후속 작업 | 남은 조사, 복구 확인, 재발 방지 과제 |
증거 파일은 수집 시각, 출처, 수집 방법, 취급한 사람을 기록하고 원본을 보호합니다. 해시로 수집 이후 파일이 바뀌었는지 확인할 수 있지만, 해시만으로 출처나 수집 과정까지 증명되지는 않습니다.
8. 실제로 작동하는지 확인하기
구축 후에는 안전한 시험 환경에서 알려진 테스트 행동을 만들어 전체 흐름을 확인합니다.
- 필요한 기록이 빠짐없이 수집되고 검색되는가?
- 탐지한 경고가 담당자에게 전달되는가?
- 담당자가 근거를 확인하고 대응 절차를 실행할 수 있는가?
- 조치의 효과와 서비스 정상화를 확인할 수 있는가?
- 로그 수집 중단이나 저장 공간 부족도 발견할 수 있는가?
평가는 도구 개수보다 탐지까지 걸린 시간, 담당자의 확인 시간, 대응 효과, 정상 행동을 잘못 경고하는 정도를 기준으로 합니다. 시험과 실제 사고에서 발견한 문제를 반영해 수집 범위와 절차를 계속 개선합니다.
참고 자료
- NIST SP 800-61 Rev. 3 · 사고 대응 권고: 사고 대응의 역할·절차와 탐지·대응·복구의 기본 방향.
- ASD ACSC 등 공동 지침 · 로그 수집과 위협 탐지: 로그 수집, 시간 기준, 중앙 분석, 기록 보호의 기본 원칙.
