모의 해킹 시나리오 구성을 위한 위협 모델링과 공격 경로 분석 방법론

증상 진단: 내 시스템은 정말 공격받고 있는가?

서버 로그에 지속적인 실패한 로그인 시도가 기록되고. 네트워크 트래픽이 비정상적으로 증가하며, 의심스러운 외부 연결이 감지됩니다. 이는 단순한 스캔일 수도, 표적 공격의 초기 증상일 수도 있습니다. 모의 해킹은 실제 공격자가 취할 수 있는 모든 경로를 사전에 발견해 차단하는 유일한 방법입니다. 막연한 불안감에 머물지 말고, 체계적인 위협 모델링으로 위험을 구체화해야 합니다.

원인 분석: 취약점은 어디에 숨어 있는가

보안 위협은 단일 포인트에서 발생하지 않습니다. 애플리케이션 코드의 결함, 서버 설정 오류, 내부 직원의 보안 의식 부재, 물리적 보안 구멍까지 다차원적으로 존재합니다, 위협 모델링의 핵심은 ‘공격자(adversary)’의 관점에서 자산(asset)을 바라보고, 이 자산에 도달하기 위한 공격 경로(attack path)를 식별하는 것입니다. 이를 통해 무작위적 침투 테스트(Penetration Test)를 넘어, 조직에 맞는 최적화된 보안 투자와 대응 체계를 수립할 수 있습니다.

해결 방법 1: STRIDE 프레임워크를 활용한 체계적 위협 식별

마이크로소프트가 제안한 STRIDE는 시스템 설계 단계부터 위협을 분류하는 표준 방법론입니다. 각 요소에 대한 점검을 시작하십시오.

1. 스푸핑(Spoofing): 인증 시스템을 우회할 수 있는가? 비밀번호 복잡도 정책, 다중 인증(MFA) 적용 여부, 세션 관리 로직을 검토합니다.
2. 변조(Tampering): 데이터 무결성을 훼손할 수 있는가? 전송 중 및 저장 중인 데이터의 암호화, 무결성 검증(해시) 절차, 파일 시스템 권한 설정을 확인합니다.
3. 부인(Repudiation): 사용자가 행위를 부인할 수 있는가? 모든 주요 작업(관리자 로그인, 설정 변경, 데이터 접근)에 대해 감사 추적(Audit Trail) 로그가 남고, 로그의 무결성이 보장되는지 점검합니다.
4. 정보 노출(Information Disclosure): 민감 정보가 유출될 수 있는가? 불필요한 데이터 수집, 오류 메시지 정보 노출, 디렉토리 리스팅, 암호화 키 관리 방식을 검증합니다.
5. 서비스 거부(Denial of Service): 서비스 가용성을 떨어뜨릴 수 있는가? 애플리케이션/네트워크 레벨의 DDoS 대응 능력, 리소스(CPU, 메모리, 대역폭) 한도 설정, 레이트 리미팅(Rate Limiting) 적용 여부를 평가합니다.
6. 권한 상승(Elevation of Privilege): 일반 권한으로 관리자 권한을 획득할 수 있는가? 최소 권한 원칙(Principle of Least Privilege) 준수, 권한 분리, 입력값 검증(Input Validation) 취약점을 분석합니다.

해결 방법 2: 공격자 시나리오 기반의 공격 트리(Attack Tree) 구축

STRIDE로 위협을 분류했다면, 구체적인 공격 시나리오를 시각적으로 설계해야 합니다. 공격 트리는 루트 노드(공격 최종 목표)에서 시작해 리프 노드(실행 가능한 공격 기법)까지의 논리적 경로를 트리 구조로 나타냅니다.

공격 트리 작성 실전 절차

목표: ‘웹 서버의 데이터베이스 내 고객 개인정보 탈취’를 최종 목표(루트 노드)로 설정합니다.

1. 1단계 – 주요 공격 표면 식별: 웹 애플리케이션, 관리자 콘솔, 데이터베이스 직접 접근 포트, 내부 직원 워크스테이션 등을 주요 표면으로 나열합니다.
2. 2단계 – 경로 세분화 (AND/OR 논리 적용):
   • 루트 노드 하위에 ‘웹 애플리케이션 통해 접근’과 ‘내부 네트워크 통해 직접 접근’이라는 두 가지 주요 경로(OR 조건)를 생성합니다.
   • ‘웹 애플리케이션 통해 접근’ 경로를 더 세분화합니다. 예: ‘SQL 인젝션 취약점 이용’ (AND 조건: 인젝션 가능 경로 발견 + 방화벽/WAF 우회).
   • ‘내부 네트워크 통해 직접 접근’ 경로는 ‘피싱으로 내부 직원 자격증명 획득’ 후 ‘VPN을 통한 내부 진입’과 같은 시나리오(AND 조건)로 확장합니다.
3. 3단계 – 리프 노드에 실질적 테스트 케이스 매핑: 각 리프 노드(예: ‘인젝션 가능 경로 발견’)에 실제 수행할 모의 해킹 기법을 연결합니다. 이 예시에서는 OWASP ZAP이나 sqlmap을 이용한 자동화 스캔, 수동 페이로드 주입 테스트가 해당됩니다.

이 트리를 완성하면, 단순한 포트 스캔이 아닌 ‘공격자의 사고방식’에 맞춘 시나리오 기반 침투 테스트 체계가 갖춰집니다.

해결 방법 3: 데이터 흐름 다이어그램(DFD)과 결합한 종합적 위협 모델링

가장 강력한 보안 전략은 시스템 구조를 도식화한 DFD에 위협 요소를 중첩하여 복잡한 분산 시스템의 허점을 식별하는 것입니다. 외부 엔터티와 프로세스, 데이터 스토어 간의 흐름을 Level 0에서 Level 2까지 세분화하여 도식화한 뒤, 이를 기존의 단일 보안 진단 방식 및 종합 검토 결과와 대조해 보면 신뢰 경계(Trust Boundary)를 가로지르는 지점에서 잠재적 위험이 집중됨을 명확히 파악할 수 있습니다. 이 경계면의 각 요소에 STRIDE 6가지 관점을 적용해 변조나 서비스 거부 공격 가능성을 진단하고, 식별된 위협의 발생 가능성과 영향도를 평가하여 보안 강화의 우선순위를 결정함으로써 한정된 자원을 실질적인 시스템 방어력 확보에 집중할 수 있습니다.

주의사항: 모의 해킹 시나리오 구성 시 반드시 지킬 것

위협 모델링과 모의 해킹은 강력한 도구이지만, 잘못 사용하면 큰 사고로 이어집니다.

• 사전 승인 없는 테스트는 불법 행위: 반드시 경영층의 서면 승인(Authorization Letter)을 받으십시오. 테스트 범위(IP 대역, 시스템, 시간대), 금지 행위(DoS 테스트, 실제 데이터 변경/삭제 등)를 명확히 정의합니다.
• 프로덕션 환경 직접 테스트 절대 금지: 가능한 한 스테이징(Staging) 또는 별도로克隆된 테스트 환경에서 시나리오를 검증하십시오. 프로덕션 테스트가 불가피할 경우, 롤백 계획과 중단(Abort) 신호를 사전에 합의합니다.
• 문서화는 선택이 아닌 필수: 위협 모델(STRIDE 분석표, 공격 트리, DFD), 테스트 수행 내역, 발견된 취약점, 영향도, 재현 방법, 완화 방안을 상세히 기록한 보고서를 작성해야 지속적인 보안 개선의 근거가 됩니다.

위협 모델링은 일회성 작업이 아닙니다. 새로운 기능 추가, 주요 시스템 변경, 6개월에서 1년 주기의 정기 검토가 반드시 필요합니다. 공격 트리와 DFD(Data Flow Diagram)는 살아있는 문서로 관리하십시오.

가장 취약한 지점은 종종 ‘신뢰 경계를 가로지르는 데이터 흐름’과 ‘외부 엔터티와의 연동 인터페이스’에서 발견됩니다. 이러한 보안 접점에서 발생하는 잠재적 리스크를 파악했다면, 그 리스크가 실제 재난으로 이어졌을 때의 대응력 또한 정교하게 설계되어야 합니다. 특히 위협 모델링에서 식별된 최악의 시나리오에 대비하여 재해 복구 시나리오에서의 목표 복구 시간(RTO) 산정 및 검증 방법론을 수립하는 것은 필수적입니다. 보안 위협이 서비스 중단이라는 결과로 나타났을 때, 비즈니스가 허용하는 최대 시간 내에 시스템을 정상화할 수 있는지(RTO)를 실측 데이터 기반으로 검증해야 비로소 ‘설계된 보안’이 ‘실천적 가용성’으로 완성되기 때문입니다.

모의 해킹 팀과 시스템 개발/운영 팀이 함께 참여하는 위협 모델링 워크샵을 정기화하면, 보안을 사후 조치가 아닌 설계 단계부터 포함시키는 DevSecOps 문화를 정착시킬 수 있습니다. 결국 위협을 예측하는 ‘모델링’과 복구 능력을 수치화하는 ‘RTO 관리’가 결합될 때, 시스템은 어떠한 외부 충격에도 흔들리지 않는 진정한 의미의 회복탄력성(Resilience)을 확보하게 됩니다.