사이버레인지 훈련 시나리오는 공격을 보여 주는 대본이 아니라, 조직의 사고 대응 능력을 검증하는 실행 설계서입니다.
사이버레인지 훈련을 만든다고 하면 많은 사람이 먼저 공격 시나리오를 떠올립니다. 어떤 침투가 일어나고, 어떤 로그가 남고, 방어팀이 어떻게 막을지를 생각합니다. 하지만 이 순서로 접근하면 훈련이 자극적인 공격 재현이나 문제 풀이로 흐르기 쉽습니다.
REWIRE Cyber Range 문서를 기준으로 보면 출발점은 다릅니다. REWIRE는 사이버레인지를 머신, 컨테이너, 네트워크 가상화 위에서 시나리오를 배포하고, 자동·반자동·수동 방식으로 실행하며, 트래픽 생성기, 공격 생성기, 이벤트 탐지기, 관리 인터페이스, 대시보드, 보안 접속, 트레이너·훈련생 문서, 시나리오 패키징까지 포함하는 훈련 플랫폼으로 봅니다.
이 기준을 적용하면 질문이 바뀝니다. "어떤 공격을 넣을까"가 아니라 "어떤 대응 능력을 검증할까"가 먼저입니다. 이 글에서는 REWIRE 구성 요소를 기준으로 실제 사고 대응 훈련 시나리오를 어떻게 설계하면 좋은지 설명합니다.
들어가며: 시나리오는 공격 대본이 아니다
좋은 사이버레인지 시나리오는 해킹 절차를 자세히 설명하지 않습니다. 대신 방어자가 무엇을 보고, 어떤 판단을 하고, 누구에게 보고하고, 어떤 기준으로 차단과 복구를 선택해야 하는지 설계합니다.
예를 들어 "계정 탈취 의심" 훈련을 만든다고 해 보겠습니다. 훈련의 핵심은 공격자가 어떤 방법으로 계정을 훔쳤는지가 아닙니다. 방어팀이 이상 로그인 경보를 보고, 관련 계정과 세션을 확인하고, 업무 영향을 따져 계정 잠금 여부를 결정하고, 경영진에게 영향 범위를 보고하고, 훈련 후 탐지 룰과 절차를 개선하는지가 핵심입니다.
따라서 시나리오 문서에는 다음 질문이 들어가야 합니다.
- 어떤 대응 능력을 검증할 것인가
- 어떤 가상 환경이 필요한가
- 어떤 이벤트와 로그를 참가자에게 보여 줄 것인가
- 자동으로 진행할 부분과 트레이너가 수동으로 주입할 부분은 무엇인가
- 훈련 중 무엇을 관찰하고 평가할 것인가
- 훈련 후 어떤 문서와 개선 과제를 남길 것인가
이 질문들이 정리되어야 사이버레인지가 단순 실습장이 아니라 사고 대응 훈련 플랫폼으로 작동합니다.
REWIRE 구성 요소로 보는 시나리오 구조
REWIRE 기준의 사이버레인지 시나리오는 여러 구성 요소가 함께 맞물려야 합니다. 각각을 사고 대응 훈련에 맞춰 풀어 보면 다음과 같습니다.
| REWIRE 구성 요소 | 훈련 시나리오에서의 의미 | 계정 탈취 의심 훈련 예시 |
|---|---|---|
| 머신·컨테이너·네트워크 가상화 | 실제 운영망과 분리된 훈련 환경 구성 | 훈련용 웹 포털, 인증 서버, 로그 서버 |
| 시나리오 프로비저닝 | 훈련에 필요한 계정, 로그, 이벤트를 미리 준비 | 정상 로그인 기록과 이상 로그인 기록 준비 |
| 자동·반자동·수동 실행 | 이벤트를 어떤 방식으로 진행할지 결정 | 자동 로그 주입 + 트레이너 상황 카드 |
| 트래픽 생성기 | 정상 업무 흐름과 이상 징후를 함께 구성 | 정상 로그인, 업무 API 호출, 비정상 접근 흔적 |
| 공격 생성기 | 방어 관찰점 중심의 의심 이벤트 생성 | 의심 세션, 권한 사용 흔적, 인증 실패 급증 |
| 이벤트 탐지기 | 참가자가 확인할 경보와 로그 제공 | SIEM 경보, 인증 이상 알림, 위치 이상 경보 |
| 관리 인터페이스와 대시보드 | 트레이너가 진행 상황과 대응 품질 관찰 | 경보 확인 시간, 보고 제출 여부, 조치 시간 |
| 보안 접속 인프라 | 참가자가 안전하게 훈련 환경에 접속 | VPN, 임시 계정, 권한 제한 |
| 트레이너·훈련생 문서 | 역할별 지시문과 운영 기준 제공 | 훈련생 안내문, 트레이너 운영 카드 |
| 시나리오 패키징 | 다음 훈련에서도 재사용 가능한 묶음 구성 | README, 체크리스트, 평가표, 로그 데이터 |
이 표에서 중요한 점은 모든 요소가 "훈련 목적"으로 연결되어야 한다는 것입니다. 가상화 환경은 멋진 인프라를 보여 주기 위한 것이 아니라 안전한 실패를 만들기 위한 장치입니다. 대시보드는 점수를 보여 주기 위한 화면이 아니라 훈련 후 무엇을 개선할지 확인하는 관찰 도구입니다.
예시: 계정 탈취 의심 대응 시나리오
가장 현실적인 예시로 계정 탈취 의심 대응 훈련을 생각해 보겠습니다. 많은 조직에서 계정 탈취는 랜섬웨어, 내부 이동, 데이터 유출로 이어질 수 있는 초기 신호입니다. 그래서 사고 대응 훈련의 첫 주제로 적합합니다.
훈련 개요
훈련명은 "계정 탈취 의심 사고 대응 훈련"으로 잡을 수 있습니다. 목적은 인증 이상 징후를 탐지한 뒤 계정 잠금, 영향 범위 판단, 서비스 영향 확인, 내부 보고, 재발 방지 과제 도출까지의 흐름을 검증하는 것입니다.
훈련 유형은 시나리오 기반 사고 대응 훈련입니다. 이 안에는 Live-Fire 관점의 여러 요소가 들어갈 수 있습니다. CDX처럼 방어팀이 실시간으로 분석하고 대응할 수 있고, CTF처럼 특정 로그 단서를 찾는 작은 과제를 넣을 수도 있습니다. 하지만 핵심은 둘을 비교하는 것이 아니라 협업, 커뮤니케이션, 비기술 판단, Table-top, SLA 판단까지 하나의 대응 흐름 안에 넣는 것입니다.
참가자 역할
훈련에는 최소한 다음 역할이 필요합니다.
| 역할 | 책임 | 산출물 |
|---|---|---|
| 사고 지휘자 | 우선순위 결정, 역할 배정, 보고 승인 | 상황 보고서, 의사결정 기록 |
| 보안 분석가 | 경보 확인, 로그 분석, 침해 가능성 판단 | 분석 메모, 침해 범위 추정 |
| 인프라 담당자 | 계정 잠금, 세션 종료, 시스템 상태 확인 | 조치 기록, 복구 확인 |
| 서비스 담당자 | 업무 영향과 SLA 영향 판단 | 서비스 영향 평가 |
| 고객지원 담당자 | 고객 문의 가능성 검토, 공지 문안 초안 | 고객 응대 문안 |
| 트레이너 | 상황 주입, 진행 통제, 평가 기록 | 진행 로그, 평가표 |
이 역할을 나누는 이유는 실제 사고가 기술팀 안에서만 끝나지 않기 때문입니다. 계정을 잠그면 업무가 멈출 수 있고, 고객 영향 가능성이 있으면 공지 판단이 필요하며, 법적 리스크가 있으면 별도 검토가 필요합니다.
시나리오 흐름을 시간 순서로 설계하기
시나리오는 시간 순서로 설계하면 운영하기 쉽습니다. 다만 공격 절차를 자세히 쓰는 것이 아니라 방어자가 관찰해야 할 이벤트와 기대 행동을 중심으로 작성해야 합니다.
| 시간 | 상황 주입 | 참가자 기대 행동 | 평가 포인트 |
|---|---|---|---|
| T+0 | 인증 이상 경보 발생 | 경보 확인, 담당자 지정 | 최초 확인 시간 |
| T+10 | 특정 계정의 평소와 다른 접근 흔적 확인 | 계정 활동 범위 조사 | 로그 해석 정확도 |
| T+20 | 서비스 담당자가 사용자 불편 가능성 문의 | 차단과 서비스 영향 비교 | SLA 판단 |
| T+30 | 추가 의심 세션 발견 | 계정 잠금 또는 세션 종료 판단 | 조치 기준 명확성 |
| T+45 | 경영진이 영향 범위 보고 요청 | 짧은 상황 보고 작성 | 보고 문장 품질 |
| T+60 | 고객지원팀이 공지 필요 여부 문의 | 고객 영향 판단, 공지 기준 검토 | 비기술 협업 |
| T+75 | 상황 안정화 | 복구 확인, 재발 방지 과제 정리 | 사후 개선 품질 |
이 흐름에서 중요한 장면은 T+20과 T+45입니다. 많은 훈련은 기술 분석에 집중하지만 실제 사고에서는 서비스 영향과 보고가 빠르게 따라옵니다. 보안팀이 의심 세션을 차단하고 싶어도 서비스 담당자는 업무 중단을 걱정할 수 있습니다. 경영진은 기술 세부정보보다 "무슨 일이 발생했고, 영향은 어디까지이며, 지금 무엇을 결정해야 하는지"를 알고 싶어 합니다.
트레이너 운영 카드 만들기
트레이너 운영 카드는 훈련 중 참가자에게 주입할 상황 문장입니다. 실제 사고의 불완전한 정보와 부서 간 충돌을 안전하게 재현하는 장치입니다.
예시는 다음과 같습니다.
- 서비스 담당자가 "계정 잠금 시 일부 업무가 중단될 수 있다"고 알립니다.
- 고객지원팀이 "고객 문의가 들어오면 어떤 문장으로 답해야 하느냐"고 묻습니다.
- 경영진이 "5분 안에 현재 영향 범위를 한 문단으로 보고하라"고 요청합니다.
- 일부 시스템의 로그 시간이 5분 늦게 기록된 것으로 확인됩니다.
- 같은 사용자의 정상 업무 활동과 의심 활동이 섞여 있어 단정이 어렵습니다.
이런 카드가 있어야 훈련이 현실에 가까워집니다. 실제 사고에서는 로그가 완벽하지 않고, 모든 사람이 같은 정보를 동시에 보지 못하며, 기술 조치와 업무 영향이 자주 충돌합니다.
성공 기준과 감점 기준
훈련의 성공 기준은 "공격을 막았다"처럼 쓰면 안 됩니다. 대응 행동과 산출물 중심으로 정해야 합니다.
성공 기준 예시는 다음과 같습니다.
- 최초 경보를 제한 시간 안에 확인했다.
- 의심 계정과 관련 로그를 근거로 침해 가능성을 설명했다.
- 계정 잠금 또는 세션 종료의 업무 영향을 확인했다.
- 사고 지휘자가 차단, 관찰, 보고 중 우선순위를 결정했다.
- 경영진 보고 문장에 발생 사실, 영향 범위, 현재 조치, 다음 결정이 포함됐다.
- 훈련 후 개선 과제와 탐지 룰 보완 항목을 남겼다.
감점 기준도 필요합니다.
- 근거 없이 침해 여부를 단정했다.
- 서비스 영향 확인 없이 차단만 수행했다.
- 필요한 로그를 보존하지 못했다.
- 보고가 기술 용어 중심이라 의사결정자가 이해하기 어려웠다.
- 훈련 종료 후 개선 과제가 남지 않았다.
이 기준을 미리 정하면 훈련 후 리뷰가 훨씬 명확해집니다. 누가 잘했는지보다 어떤 절차가 막혔는지, 어떤 도구가 부족했는지, 어떤 보고 문장이 통하지 않았는지를 볼 수 있습니다.
훈련 후 남겨야 할 산출물
사이버레인지 훈련은 끝난 뒤가 더 중요합니다. REWIRE가 문서와 시나리오 패키징을 강조하는 이유도 여기에 있습니다. 훈련 결과가 남아야 다음 훈련이 좋아집니다.
훈련 후에는 최소한 세 가지 문서를 남기는 것이 좋습니다.
첫째, 사고 대응 타임라인입니다. 언제 어떤 경보가 보였고, 누가 어떤 판단을 했고, 어떤 조치를 했는지 시간 순서로 남깁니다.
둘째, 상황 보고서입니다. 발생 사실, 영향 범위, 수행한 조치, 확인 중인 항목, 다음 결정 사항을 한 페이지 안에 정리합니다.
셋째, 개선 과제 목록입니다. 로그, 탐지, 권한, 보고, SLA 기준에서 무엇을 고칠지 정리합니다. 예를 들어 "인증 로그 보관 기간 확대", "위치 이상 경보 기준 조정", "계정 잠금 승인 절차 명확화", "경영진 보고 양식 개선" 같은 항목이 나올 수 있습니다.
시나리오 패키징 체크리스트
마지막으로 시나리오를 재사용 가능한 패키지로 남겨야 합니다. 다음 체크리스트를 활용할 수 있습니다.
- 시나리오 목적이 한 문단으로 정리되어 있다.
- 환경 구성 요소가 문서화되어 있다.
- 필요한 계정과 접근 권한이 정리되어 있다.
- 로그와 이벤트 데이터의 주입 방식이 정리되어 있다.
- 자동·반자동·수동 실행 범위가 구분되어 있다.
- 트레이너 운영 카드가 준비되어 있다.
- 훈련생 안내문이 준비되어 있다.
- 평가표와 성공 기준이 준비되어 있다.
- AAR 양식과 개선 과제 양식이 준비되어 있다.
- 다음 훈련에서 바꿀 수 있는 변수 목록이 있다.
이 체크리스트가 있으면 훈련이 한 번의 이벤트로 끝나지 않습니다. 같은 시나리오를 난이도만 바꿔 반복할 수도 있고, 다른 부서나 다른 교육 과정에 맞춰 조정할 수도 있습니다.
결론
REWIRE 사이버레인지 구성 요소를 기준으로 시나리오를 만들면 훈련의 초점이 분명해집니다. 사이버레인지는 단순한 실습장이 아니라 가상화 환경, 시나리오 실행 체계, 이벤트 탐지, 대시보드, 보안 접속, 문서화, 패키징이 결합된 훈련 플랫폼입니다.
따라서 훈련 시나리오도 공격 장면 중심이 아니라 대응 능력 중심으로 설계해야 합니다. 어떤 경보를 볼 것인지, 어떤 로그로 판단할 것인지, 어떤 순서로 차단과 복구를 선택할 것인지, 누구에게 어떤 문장으로 보고할 것인지, 훈련 후 무엇을 개선할 것인지가 핵심입니다.
사이버레인지 훈련의 가치는 "실감 나는 공격"이 아닙니다. 실제 사고 전에 조직의 대응 절차가 어디서 끊기는지 찾아내고, 그 약점을 안전하게 고칠 수 있게 해 주는 데 있습니다.
FAQ
Q. 작은 조직도 사이버레인지 시나리오가 필요한가요?
필요할 수 있습니다. 다만 처음부터 복잡한 환경을 만들 필요는 없습니다. Table-top으로 역할과 의사결정 흐름을 먼저 점검하고, 이후 로그 분석 실습과 제한된 시나리오 훈련으로 확장하면 됩니다.
Q. CTF와 Live-Fire를 따로 비교해야 하나요?
이 글의 관점에서는 굳이 비교할 필요가 없습니다. CTF는 기술 단서 찾기 요소로, CDX는 실시간 방어 훈련 요소로, Live-Fire는 협업·커뮤니케이션·비기술 판단·SLA까지 포함하는 넓은 훈련 관점으로 보면 됩니다.
Q. 공격 시나리오를 자세히 써야 현실적인 훈련이 되나요?
아닙니다. 사고 대응 훈련에서는 공격 절차보다 방어 관찰점과 의사결정 지점이 더 중요합니다. 참가자가 무엇을 보고, 어떤 근거로 판단하고, 누구에게 보고했는지를 평가해야 합니다.
참고자료
- REWIRE, Cyber Range: https://rewireproject.eu/cyber-range/
- REWIRE Cyber Range Platform documentation: https://docs.crp.kypo.muni.cz/
- NIST, The Cyber Range: A Guide: https://www.nist.gov/system/files/documents/2023/09/29/The%20Cyber%20Range_A%20Guide.pdf