위협 모델링 (Threat Modeling)

핵심 인사이트 (3줄 요약)

본질: 위협 모델링(Threat Modeling)은 시스템의 구성 요소, 신뢰 경계, 데이터 흐름을 분석하여 잠재적 보안 위협을 체계적으로 식별하고, 각 위협의 가능성과 영향을 평가하여 보안 통제를 우선순위화하는 구조화된 분석 방법론이다.

가치: 위협 모델링을 통해 보안 통제에 대한 투자가 명확한 근거에 기반하게 되어, 가장 위험한 위협에 먼저 대응하고, 보안 예산과 노력을 효과적으로 배분할 수 있다. 사전에 식별된 위협은 사후 대응 비용의 1/10 수준에서 수정 가능하다.

융합: 위협 모델링은 소프트웨어 아키텍처(컴포넌트 구조, 신뢰 경계), 보안 전문가(STRIDE, ATT&CK 프레임워크), 비지니스(ROI 분석, 컴플라이언스)와 직결되며, DevSecOps의 설계 단계 필수 요소로 자리잡았다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념 정의

위협 모델링(Threat Modeling)은 소프트웨어 시스템이나 네트워크 아키텍처를 설계 단계에서 분석하여, 잠재적인 보안 위협을 체계적으로 식별하고, 그 위협에 대한 완화(mitigation) 전략을 수립하는 구조화된 방법론이다. 위협 모델링의核心質問은 "어떤 위협이 시스템에 존재하는가?", "각 위협의 가능성과 영향은 어느 정도인가?", "각 위협에 대한 적절한 대응은 무엇인가?" 이다. 이를 체계적으로 수행하기 위해 다양한 방법론(STRIDE, PASTA, ATT&CK, CVSS)이 활용되며, 이들 방법론은 서로 다른 초점과 세밀함 수준을 제공한다.

필요성

보안은 사전 예방이 사후 대응보다 비용 효과적이다. 설계 단계에서 취약점이 발견되면 아키텍처 변경으로 해결 가능하지만, 시스템이 완성되고 배포된 후에 발견되면 대규모 코드 변경, Regression 테스트, 배포 업데이트가 필요하므로 비용이 급증한다.威胁 모델링은 이러한 비용 구조를改善하기 위해 설계 단계에서 보안을 통합하는 "Shift Left" 실천의 핵심 요소이다. 또한 규제 환경(PCI DSS, HIPAA, GDPR)에서도 설계 단계의 보안 평가(Threat Modeling)를要求하거나 권장하며, 이를 통해 컴플라이언스 입증에 활용된다.

💡 비유

위협 모델링은 도시 계획을 수립할 때의保安 분석과 같다. 도시 기획자는 도시의 주요 시설(은행, 병원, 政府廳舍, 变电站)을 分析하고, 각 시설에 대한 위협(범죄, 테러, 자연재해, 정전)을 식별하며, 각 위협의 가능성과 영향(피해 규모)을 평가하여, 보안 카메라, 경비원, 방화벽, 대체 전원 등의 보안 통제를優先순위대로 배치한다. 시스템 설계에서 위협 모델링은 이러한保安 분석을 소프트웨어/네트워크 구조에 적용하여,潜在적 보안 위험을 사전에 식별하고 대응策을 수립하는 데 활용된다.

등장 배경 및 발전 과정

위협 모델링의 方法論은 1990년대 Loren Kaindl이 제시한 "Architectural Risk Analysis"에서 비롯되었으며, 1999년 Microsoft의 사내 방법론으로 발전한 STRIDE(2005년公开发表)가 업계에 널리 알려졌다. 2007년 Robert Seacord 등은 "Secure Coding"에서威胁建模를 소프트웨어 개발 생명주기에 통합하는 방법을 제시했다. 2010년 OWASP는 Threat Risk Modeling을OWASP 가이드에 포함시켰으며, 2016년 NIST SP 800-154는 "Insider Threat" 보호를 위한威胁建模 가이지를 发布했다. 2010년대 이후로는 PASTA(Process for Attack Simulation and Threat Analysis), MITRE의 ATT&CK 프레임워크와 함께 위협 모델링의自動化와 통합이 진전되고 있다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

위협 모델링 프로세스

위협 모델링은 체계적인 단계적 프로세스로 수행되며, 각 단계는 이전 단계의 결과를入力으로 활용한다. 가장 널리 알려진 방법론 중 하나인 STRIDE-per-Element를 중심으로 설명한다.

  ┌─────────────────────────────────────────────────────────────────────┐
  │                    위협 모델링 단계별 프로세스                            │
  ├─────────────────────────────────────────────────────────────────────┤
  │
  │  [Step 1: 목적 및 범위 정의]                                         │
  │
  │  - 시스템 경계, 분석 대상 컴포넌트 식별                               │
  │  - 신뢰 경계(Boundary) 정의                                          │
  │  - 데이터 분류 및 보호 요구사항 명확화                                 │
  │
  │  [Step 2: 아키텍처 분해 - DFD (Data Flow Diagram)]                  │
  │
  │  ┌────────────────────────────────────────────────────────────┐    │
  │  │  [외부 개체]     데이터 흐름     [프로세스]    데이터 저장소  │    │
  │  │                                                             │    │
  │  │   [사용자]  ────────────────▶  [웹 앱]  ◀──  [DB]       │    │
  │  │       │                      │                            │    │
  │  │       │    ────────────────▶  │                            │    │
  │  │       │                      ▼                            │    │
  │  │       │                 [인증 서비스]                        │    │
  │  │       │                      │                            │    │
  │  │       ▼                      ▼                            │    │
  │  │   [브라우저] ◀────────── [API Gateway]                     │    │
  │  │                                                             │    │
  │  │  신뢰 경계: 사용자/브라우저 --- 외측                      │    │
  │  │             API Gateway --- 내부                         │    │
  │  └────────────────────────────────────────────────────────────┘    │
  │
  │  [Step 3: 위협 식별 - STRIDE 적용]                                 │
  │
  │  각 요소(외부 개체, 프로세스, 데이터 저장소, 데이터 흐름)에 대해         │
  │  STRIDE 위협 카테고리별로 위협을 식별:                               │
  │
  │  S - Spoofing (스푸핑): 인증 서비스 위장                            │
  │  T - Tampering (변조): API 요청 본문 변조                           │
  │  R - Repudiation (부인): 중요한 操作의 logs 미기록                   │
  │  I - Information Disclosure (정보 유출): DB 데이터 탈취               │
  │  D - Denial of Service (서비스 거부): DB에 과부하                   │
  │  E - Elevation of Privilege (권한 상승): 일반 사용자가 관리자 권한 획득  │
  │
  │  [Step 4: 위협 평가 - CVSS]                                        │
  │
  │  각 위협에 대해 CVSS 스코어 산정:                                   │
  │  - Attack Vector (AV): Network/Adjacent/Local/Physical             │
  │  - Attack Complexity (AC): Low/High                              │
  │  - Privileges Required (PR): None/Low/High                       │
  │  - User Interaction (UI): None/Required                          │
  │  - Impact: Confidentiality/Integrity/Availability                 │
  │
  │  [Step 5: 완화 전략 수립 및 구현]                                   │
  │
  │  - 기술적 통제 (Encryption, Access Control, Validation)            │
  │  - 관리적 통제 (Policies, Training)                               │
  │  - 물리적 통제 (시설 보안)                                         │
  │  - 잔여 위험(Residual Risk)Acceptance 또는 추가 대응 결정             │
  │
  └─────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] Step 1에서 분석의 목적과 범위를 명확히 정의한다. 예를 들어, "新型 웹 서비스의 위협 모델링"이라면 웹 앱, API, DB, 인증 서비스를 분석 대상에 포함하고, 외부 인터넷, 내부 네트워크를 신뢰 경계로 설정한다. Step 2에서 DFD를 작성하여 시스템의 구성 요소와 데이터 흐름을 시각화한다. DFD에서는 외부 개체(사용자, 외부 시스템), 프로세스(웹 앱, 마이크로서비스), 데이터 저장소(DB, 캐시), 데이터 흐름(사용자 → 웹 앱, 웹 앱 → DB)을 식별하고, 신뢰 경계를 명시적으로 표시한다. Step 3에서 각 DFD 요소에 대해 STRIDE 위협 카테고리를 적용하여 위협을 식별한다. 예를 들어, 외부 개체(사용자)에서는 Spoofing(타인 사칭), Repudiation(행위否认)가 주요 위협이며, 프로세스(웹 앱)에서는 Tampering(입력 변조), Information Disclosure(세션 탈취), Elevation of Privilege(권한 상승) 등이 위협이 된다. Step 4에서 CVSS(Common Vulnerability Scoring System)를 적용하여 각 위협의 심각도를 정량적으로 산정한다. Step 5에서 식별된 위협에 대한 완화 전략을 수립하고, 보안 통제를 구현한다.

STRIDE 위협 카테고리별 상세

STRIDE는 Microsoft의 위협 모델링 방법론으로, 각 글자가 다른 위협 카테고리를 代表한다. 각 위협에 대한 완화 통제도 함께 제시된다.

  ┌─────────────────────────────────────────────────────────────────────┐
  │                    STRIDE 위협 카테고리 및 완화 통제                      │
  ├─────────────────────────────────────────────────────────────────────┤
  │
  │  [S - Spoofing (스푸핑)]                                            │
  │  설명: 타인의 인증 정보를 도용하여 시스템에 접근                        │
  │  예시: 타인의 로그인 정보 사용, 세션 쿠kie 탈취 후 세션 하이재킹        │
  │  완화: 인증 (Authentication) - 강력한 인증, MFA, Https/TLS           │
  │
  │  [T - Tampering (변조)]                                             │
  │  설명: 데이터 또는 코드를 부정하게 변경                               │
  │  예시: SQL 주입, XSS, 중간자 공격(MITM), API 요청 변조                │
  │  완화: 변경 방지 (Integrity) - 입력 검증, 해시/Signature, CRC        │
  │
  │  [R - Repudiation (부인)]                                           │
  │  설명: 사용자가 자신이 특정 동작을 수행했음을否认可能                    │
  │  예시: 거래 후 "나는 한 적 없다", 파일 삭제 후 "모르른다"              │
  │  완화: 부인 방지 (Non-repudiation) - 디지털 서명,Logs, Audit Trail   │
  │
  │  [I - Information Disclosure (정보 유출)]                            │
  │  설명: 승인되지 않은 개체가 정보에 접근                               │
  │  예시: 민감 데이터베이스 접근, 네트워크 스니핑, 브라우저 쿠키 탈취     │
  │  완화: 기밀성 (Confidentiality) - 암호화, 접근 통제, 권한 관리        │
  │
  │  [D - Denial of Service (서비스 거부)]                               │
  │  설명: 시스템이나 서비스의 가용성을 의도적으로 저해                    │
  │  예시: DDoS, 시스템 자원 고갈, 애플리케이션 충돌 유발                 │
  │  완화: 가용성 (Availability) - 로드 밸런싱, CDN, Rate Limiting       │
  │
  │  [E - Elevation of Privilege (권한 상승)]                            │
  │  설명: 현재 권한을 초과하는 권한을 무단으로 획득                        │
  │  예시: 일반 사용자가 관리자 기능 접근, 서비스 계정으로 OS 명령 실행    │
  │  완화: 권한 분리 (Authorization) - RBAC, 최소 권한 원칙, 입력 검증    │
  │
  └─────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] STRIDE의 6개 카테고리는 보안의 3대 목표(기밀성, 무결성, 가용성)와 대응한다. Spoofing과 Elevation of Privilege는 인증/인가의 weakness에서 비롯되며, Tampering과 Information Disclosure는 데이터/코드의 보호 실패에서, Repudiation은Logs/증거의 부족에서, Denial of Service는 가용성 공격에서 비롯된다. 각 위협에 대한 완화 통제를 수립할 때는 기술적 통제(Encryption, Access Control, Input Validation)와 관리적 통제(Policies, Training, Audit)를 함께 고려해야 하며, 완화 후에도 잔여 위험(Residual Risk)이容認可能 수준인지 평가해야 한다.

PASTA 위협 모델링

PASTA(Process for Attack Simulation and Threat Analysis)는 7단계로 구성된 위험 중심 위협 모델링 방법론으로, 비지니스 목표와 기술적 위협 분석을 통합한다.

  ┌─────────────────────────────────────────────────────────────────────┐
  │                    PASTA 7단계 프로세스                               │
  ├─────────────────────────────────────────────────────────────────────┤
  │
  │  Stage 1: 비지니스 목표 정의 (Business Objectives)                   │
  │  - 조직의 비지니스 목표, 규제 요건, 데이터 분류 파악                    │
  │
  │  Stage 2: 기술 분석 (Technical Analysis)                            │
  │  - 시스템 아키텍처, 컴포넌트, 데이터 흐름, 신뢰 경계 분석               │
  │
  │  Stage 3: 위협 분석 (Threat Analysis)                               │
  │  - CTMS(Threat Intelligence), CVE, MITRE ATT&CK 활용                 │
  │  - 조직에 관련된 위협アクター와其들이 사용하는 공격手法 분석             │
  │
  │  Stage 4: 취약점 분석 (Vulnerability Analysis)                       │
  │  - 기존 취약점 (CVSS, CWE), 설계 결함, 보안 제어 결여 식별             │
  │
  │  Stage 5: 공격 모델링 (Attack Modeling)                              │
  │  - STRIDE, Kill Chain, ATT&CK Matrix 활용                           │
  │  - 공격 경로, 공격 단계, 필요한 자원 분석                            │
  │
  │  Stage 6: 위험 분석 및 영향 평가 (Risk & Impact Analysis)            │
  │  - CVSS 기반 위험 점수 산정, 비지니스 영향 분석                       │
  │
  │  Stage 7: 완화 통제 정의 및 권고 (Mitigation Controls)               │
  │  - 보안 통제 선정, 구현 우선순위, ROI 분석                           │
  │
  └─────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] PASTA는 비지니스 관점(Stage 1)에서 시작하여 기술 관점(Stage 2~5)으로 진입하고, 다시 비지니스 관점(Stage 6~7)으로 돌아오는 일종의 Iterative 프로세스이다. Stage 3 위협 분석에서는 MITRE ATT&CK 프레임워크를 활용하여, 현실 세계의 공격자들이 어떤 TTPs(Tactics, Techniques, Procedures)를 사용하는지 분석한다. 이를 통해 조직에 실제로 존재하는 위협에 집중할 수 있다. Stage 5 공격 모델링에서는 분석된 위협과 취약점을 통합하여 공격 시나리오를 구성하고, Kill Chain이나 ATT&CK Matrix에マッピング하여 공격의 전체 흐름을 시각화한다.

📢 섹션 요약 비유: 위협 모델링은 도시의保安 계획 수립과 같다. 먼저 도시의 주요 시설과 취약한 지점(아키텍처 분석)을 파악하고, 그다음 범죄, 테러, 자연재해 등의 위협(STRIDE)을 식별하며, 각 위협의 가능성과 피해 규모(CVSS)를 평가하여, 보안 카메라, 경비원, 방화벽 등의 통제(완화 전략)를優先순위대로 배치하는 과정이다.

Ⅲ. 융합 비교 및 다각도 분석

주요 위협 모델링 방법론 비교

방법론	초점	세밀함	대상	비고
STRIDE	위협 카테고리	중간	애플리케이션, 시스템	Microsoft发明, 가장 널리 사용
PASTA	위험 중심	높음	기업 전체, 애플리케이션	7단계, 비지니스-기술 통합
ATT&CK	공격자 관점	높음	기업 전체	MITRE, 실제 공격 기술 DB
CVSS	취약점 심각도	중간	개별 취약점	정량적 점수 산정
DREAD	위협 우선순위	중간	애플리케이션	Microsoft (현재 사용 권장하지 않음)

과목 융합 관점

소프트웨어 공학: 위협 모델링은 아키텍처 설계 단계에서 수행되며, 아키텍처 결함(Architectural Flaws)을 조기에 발견하여修正コスト를 줄인다.
컴플라이언스: PCI DSS, HIPAA, GDPR 등은 설계 단계의 보안 평가를 요구하며, 위협 모델링이 이를 충족하는 수단으로 활용된다.
인시던트 대응: 사전에 수립된 위협 모델은 실제 보안 사고 발생 시 대응 전략의根基이 된다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

시나리오 — 신규 마이크로서비스 도입 시 위협 모델링: 전자상거래 플랫폼에 결제 마이크로서비스를 신규 도입할 때, 해당 서비스의 위협 모델링을 수행하여 신용카드 데이터 흐름, 외부 결제 Gateway 연동, 내부 서비스 간 통신, 데이터 저장소의 보호 요구사항을 분석하고, PCI DSS 준수를 위한 통제를 식별했다.
시나리오 — 레거시 시스템의 위협 모델링 업데이트: 기존 온프레미스 시스템을 클라우드(AWS)로 이전하면서 위협 모델을 업데이트하여, 클라우드 특유의 위협(데이터 유출, 잘못된 권한 설정, 종속-third-party 위험)을 추가하고, 기존 통제의 효과성을 재평가했다.

도입 체크리스트

기술적: 설계 단계에서 위협 모델링이 수행되고 있는가? 식별된 위협에 대한 완화 통제가 구현되었는가?
조직적: 위협 모델링 결과가 문서화되고 정기적으로 업데이트되는가?

안티패턴

사후 위협 모델링: 시스템 배포 후 위협 모델링을 수행하면 설계 결함을修正비용이 크다.
완화 통제 없는 위협 나열: 위협만 식별하고 실질적 완화 통제를 수립하지 않으면 자원 낭비로 이어진다.
정적威胁 모델: 비즈니스 환경, 기술 스택, 위협 환경이 변화하므로 위협 모델도 정기적으로 업데이트해야 한다.
📢 섹션 요약 비유: 위협 모델링은 놀이공원의定期 안전 점검과 같다. 놀이기구의構造(아키텍처)를 분석하고,潜在的 위험(고소落下, 감전, 쏠림)을 식별하며, 그 위험의 가능성과 영향(무게, 높이, 속도)을 평가하여, 안전 프로텍터, 긴급 정지 버튼,、定期 점검 등의 통제를優先순위대로 도입하는 과정이다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

구분	위협 모델링 미실시	위협 모델링 실시	개선 효과
정량	보안 취약점 100개	20개	설계 단계에서 80% 식별
정량	보안 인시던트 대응 비용 $1M	$100K	대응 비용 90% 절감
정성	보안 통제 우선순위 불명확	데이터 기반 의사결정	보안 투자 효율화

미래 전망

AI/ML 기반 위협 인텔리전스와 자동화된 위협 모델링 도구(Augment CN, IriusRisk 등)의 발전으로, 위협 모델링의 자동화와 실시간 업데이트가 가능해지고 있다. 또한 MITRE ATT&CK 프레임워크와 CVSS 4.0의 발전으로 위협 분석의 표준화와 상호운용성이 향상되고 있다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
STRIDE	Microsoft의 위협 모델링 방법론으로, 각 위협 카테고리별(Spoofing, Tampering 등) 완화 통제를 제시한다.
CVSS	취약점의 심각도를 정량적으로 산정하는 표준으로, 위협 모델링에서의 우선순위 결정에 활용된다.
MITRE ATT&CK	실제 공격자들의 TTP(Tactics, Techniques, Procedures)를 정리한 지식 베이스로, 위협 분석의 기초 자료로 활용된다.
PASTA	7단계로 구성된 위험 중심 위협 모델링 방법론으로, 비지니스 목표와 기술적 분석을 통합한다.
Security by Design	설계 단계에서 보안을 고려하는 원칙으로, 위협 모델링은 이를实践하기 위한 핵심 활동이다.

👶 어린이를 위한 3줄 비유 설명

위협 모델링은 비행기 안전 점검표 작성과 같아요. 비행기를 만들기 전에 Engineers들이 "만약 이런 곳이 고장 나면 어떻게 될까?", "어떤 비행 상황이 위험할까?"를 미리 생각하고, 그에 대비한 안전장치(알람, backup 시스템)를 만들어 두는 거예요.
예를 들어, 엔진이 멈추면(위협) 어떻게 될까? → 가장 중요한 엔진이니까 예비 엔진이 필요해! → 조종석에 경고등을 달자! → 만약 이 경고등도 고장 나면? → 수동 조작 방법을 교육하자! 같은 식으로 체계적으로 대비하는 거예요.
컴퓨터 시스템도 마찬가지예요. 설계할 때 "만약 해ackers가 이 부분을 공격하면 어떻게 될까?"를 미리 생각하고, 그것을 방어하는 방법을 만들어 두면, 실제 공격이 와도 안전하게 대응할 수 있어요.