Threat modeling (위협 모델링)

2026. 6. 3. 23:44·Security

Thraet modeling: 시스템의 보안 위협을 식별하고, 우선순위를 정하며, 적절한 대응책을 수립하기 위한 체계적인 프로세스.

매번 필요할 때 마다 다시 공부하는데 공부할 때 마다 이해하는게 달라 이번 기회에 제대로 다시 정리해본다.

혹시 틀린 부분이 있다면 언제든 댓글 환영

시작하기 전에

  • 헷갈리는 용어 - Threat vs Vulnerability: 취약점(Vulnerability) 은 시스템에 존재하는 약점이다. 예를 들어 패치되지 않은 소프트웨어, 입력값 검증 누락 등이 있다. 위협(Threat) 은 그 약점을 악용하여 피해를 일으킬 수 있는 잠재적 행위나 사건이다. 예를 들어 공격자가 SQL Injection을 수행하는 경우가 있다. 간단히 말하면, 취약점은 결함이고 위협은 그 결함을 악용하는 것이다. 위험은 둘이 함께 존재할 때 발생한다.

Contents

  • Threat, Vulnerability, Risk (위협, 취약점, 위험)
  • Process Overview
  • Step 1: Scope Definition (범위 정의)
  • Step 2: System Analysis
  • Step 3: Threat Identification (위협 식별)
  • Step 4: Threat Assessment & Prioritization (위협 평가 및 우선순위 지정)
  • Step 5: Mitigation (대응책 도출)
  • Step 6: Validation & Documentation (검증 및 문서화)
  • Roles in assessing threats (위협 평가에서의 역할)
  • Threat Modeling Tools example (위협 모델링 도구 예시)

Threat, Vulnerability, Risk (위협, 취약점, 위험)

  • Threat (위협): 공격자, 악성코드, 내부자 오용, 자연재해와 같이 원치 않는 사고의 잠재적 원인.
  • Vulnerability (취약점): 설계, 구현, 설정 또는 프로세스에 존재하며 위협에 의해 악용될 수 있는 약점.
  • Risk (위험): 위협이 취약점을 악용할 때 발생할 수 있는 손실이나 피해 가능성. 일반적으로 발생 가능성과 영향을 기준으로 평가한다.

Relationship

  • 위협은 취약점을 대상으로 하며, 이로 인해 위험이 발생한다.
  • 취약점이 없다면 위협이 의미 있는 위험으로 이어지지 않을 수 있다.
  • 실무적인 위험 평가는 보통 다음과 같이 모델링된다.
    $$ Risk \approx ~ Likelihood \times Impact $$
  • 발생 가능성은 취약점의 존재 여부와 위협 행위자의 역량에 따라 달라진다.

Threat modeling process comparison

Approach Primary Focus Key Method Best For
NIST SP 800-30 위험 평가 프로세스 위험 식별 → 발생 가능성/영향 분석 → 위험 대응 정부, 컴플라이언스 중심 조직
MS Threat Modeling Tool DFD 기반 위협 식별 + DREAD + 위험 평가 위협 식별: DFD 구성 요소에 STRIDE per Element 적용, 위협과 완화책 자동 생성; 위험 점수화: DREAD — 5가지 요소 점수화(Damage, Reproducibility, Exploitability, Affected Users, Discoverability) 개발자 중심, 설계 단계의 위협 식별 및 우선순위 지정
OWASP Threat Dragon 시각적 다이어그램 중심 위협 모델링 다이어그램 기반; STRIDE, LINDDUN, CIA, DIE, PLOT4ai 지원 오픈소스 팀, 협업 기반 위협 모델링 세션
Shostack (Threat Modeling) 실무자 중심의 실용적 위협 모델링 4가지 질문 프레임워크: 무엇을 만들고 있는가? 무엇이 잘못될 수 있는가? 무엇을 해야 하는가? 제대로 했는가? 위협 모델링을 처음 시작하는 팀, 체계적 커버리지

Process Overview

1. Scope Definition (범위 정의)
      ↓
2. System Analysis — Asset Identification / Data Flow Mapping (자산 식별 / 데이터 흐름 파악)
      ↓
3. Threat Identification (위협 식별)
      ↓
4. Threat Assessment & Prioritization (위협 평가 및 우선순위 지정)
      ↓
5. Mitigation (대응책 도출)
      ↓
6. Validation & Documentation (검증 및 문서화)

Step 1: Scope Definition (범위 정의)

  • 모델링할 대상 시스템 또는 기능을 명확히 정의한다.
  • 보안 목표를 정의한다 — Confidentiality, Integrity, Availability.
  • Trust Boundaries (신뢰 경계)를 설정한다.
  • stakeholder (이해관계자)와 attacker perspectives(공격자 관점)를 정의한다.

Step 2: System Analysis

Asset Identification (자산 식별)

  • 보호해야 할 데이터, 서비스, 인프라를 나열한다.
  • 예시: 사용자 개인정보, 인증 토큰, DB, API 서버

Data Flow Diagram (DFD) Construction (DFD 작성)

  • 시스템 구성 요소와 데이터 흐름을 시각화한다.
  • 주요 요소:
    • Process: 데이터를 처리하는 구성 요소. 계산, 변환 등을 수행한다.
    • Data Store: DB, 파일, 캐시, 메모리 저장소.
    • External Entity: 사용자, 외부 시스템, 서드파티 서비스.
    • Data Flow: 구성 요소 간 데이터 이동 경로. 프로토콜/메서드와 함께 표시한다.
    • Trust Boundary: 보안 수준이 바뀌는 경계. 신뢰 영역과 비신뢰 영역 사이의 선을 의미한다. 예를 들어 사용자 입력과 내부 시스템 사이, 애플리케이션과 외부 API 사이, 사용자 애플리케이션과 데이터베이스 사이가 있다. 이 경계를 넘는 모든 데이터에는 검증과 보안 점검이 필요하다.

Q. 왜 Trust Boundary를 정의하는가?
A. Trust Boundary를 정의하면 민감한 데이터를 보호하고 무단 접근을 방지하기 위해 보안 통제가 필요한 지점을 식별할 수 있다.

Q. DFD에서 어떤 요소가 자산으로 간주되는가?
A. 자산은 침해, 손실 또는 중단될 경우 비즈니스, 기술적, 법적 피해를 유발하는 모든 것이다. 모든 DFD 요소는 자산이 될 수 있다. Process(예: 인증 로직), Data Store(예: 데이터베이스), External Entity(예: 사용자 계정), Data Flow(예: 전송 중인 토큰)는 모두 후보가 된다. 자산은 DFD 자체를 넘어 확장된다. 소스 코드, 인프라, 서비스 가용성, 자격 증명, 브랜드 평판, 규제 준수 상태도 모두 자산이 될 수 있다. DFD는 자산이 어떻게 흐르고 처리되는지 매핑한다. 자산 식별은 무엇을 보호할 가치가 있는지 결정한다.


Step 3: Threat Identification (위협 식별)

Threat Classification Methods

Name Description
STRIDE Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege를 다루는 위협 분류 모델.
LINDDUN Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness, Non-compliance를 다루는 개인정보 위협 모델링 프레임워크.
CIA 고전적인 보안 3요소 — Confidentiality, Integrity, Availability.
DIE Data, Identity, Environment — 위협이 무엇을 대상으로 하는지에 따라 분류하는 모델.
PLOT4ai AI 시스템의 Privacy, Loss of Control, Operational, Trust 위협을 다루는 AI 특화 위협 모델링 프레임워크.

STRIDE Model

Threat Type Description Violated Property
Spoofing (스푸핑) 다른 사용자나 시스템으로 위장 Authentication (인증)
Tampering (변조) 데이터 또는 코드 무단 수정 Integrity (무결성)
Repudiation (부인) 행위에 대한 책임 부정 Non-repudiation (부인 방지)
Information Disclosure (정보 노출) 민감 정보에 대한 무단 접근 Confidentiality (기밀성)
Denial of Service (서비스 거부) 시스템 가용성 방해 Availability (가용성)
Elevation of Privilege (권한 상승) 허가되지 않은 높은 권한 획득 Authorization (인가)

#todo: LINDDUN, CIA, DIE, PLOT4ai models


More threat types (beyond STRIDE)
  • Physical Attack (물리적 공격): 하드웨어에 대한 무단 물리적 접근 — 절도, 장치 변조
  • Supply Chain Attack (공급망 공격): 신뢰된 서드파티 공급업체를 통해 소프트웨어 또는 하드웨어를 침해하는 공격
  • Social Engineering (사회공학): 피싱, 프리텍스팅처럼 사람을 조작하여 자격 증명을 공개하거나 접근 권한을 부여하게 만드는 공격
  • Insider Threat (내부자 위협): 정당한 접근 권한을 가진 직원이나 계약자의 악의적 또는 부주의한 행동
  • Zero-Day Exploit (제로데이 익스플로잇): 패치가 존재하기 전에 알려지지 않은 취약점을 공격하는 행위

Threat Identification Methods (위협 식별 방법)

  • DFD의 각 요소에 STRIDE를 적용한다.
  • Attack Trees를 구성한다.
  • 과거 CVE와 공격 패턴을 참조한다 — CAPEC, ATT&CK
  • 브레인스토밍 또는 전문가 리뷰를 수행한다.

Q. STRIDE와 같은 분류 프레임워크를 사용하는 이유는 무엇인가?
A. 구조화된 방법은 여러 범주에 걸쳐 위협을 식별하는 체계적인 방식을 제공하여 포괄적인 커버리지를 보장한다.

Q. 실무에서 가장 일반적인 접근 방식은?
A. STRIDE 또는 LINDDUN과 같은 분류 체계를 사용하여 기본 위협 식별을 수행한다.
CAPEC/CWE/CVE 참조를 사용해 근거를 첨부한다.
CVSS로 심각도를 정량화한다.
결과를 통제 항목 및 컴플라이언스 요구사항에 매핑한다. 예를 들어 NIST와 GDPR이 있다.

Common Threats

  • Malware (악성코드): 바이러스, 웜, 랜섬웨어, 스파이웨어와 같은 악성 소프트웨어. 운영을 방해하고, 데이터를 탈취하거나, 시스템을 암호화하여 금전을 요구할 수 있다.
  • Phishing and Social Engineering (피싱 및 사회공학): 사용자가 자격 증명, 민감 정보, 또는 유해한 행위 승인을 제공하도록 속이는 메시지나 상호작용.
  • Credential Attacks (자격증명 공격): 유출되었거나 약한 비밀번호를 이용하는 Password spraying, brute force, credential stuffing.
  • Insider Threat (내부자 위협): 정당한 접근 권한을 가진 직원, 계약자, 파트너의 의도적 남용 또는 우발적 오용.
  • Web Application Attacks (웹 애플리케이션 공격): SQL injection, XSS, CSRF와 같이 애플리케이션 로직과 입력 처리를 대상으로 하는 공격.
  • Denial of Service (서비스 거부 공격, DoS/DDoS): 서비스에 트래픽을 쏟아붓거나 리소스를 고갈시켜 가용성을 떨어뜨리는 공격.
  • Man-in-the-Middle (중간자 공격, MitM): 전송 보안이 약하거나 잘못 설정된 경우 통신 당사자 사이의 통신을 가로채거나 변경하는 공격.
  • Supply Chain Attack (공급망 공격): 서드파티 소프트웨어, 라이브러리, 업데이트 채널, 서비스 제공자를 통한 침해.
  • Misconfiguration and Unpatched Systems (오구성 및 미패치 시스템): 안전하지 않은 기본 설정, 노출된 서비스, 지연된 취약점 패치로 인해 발생하는 보안 공백.

Step 4: Threat Assessment & Prioritization (위협 평가 및 우선순위)

Overview

  DREAD Priority Matrix
Purpose 추정된 위험을 기준으로 위협 순위 지정 발생 가능성 × 영향을 기준으로 위협 분류
Output 위협별 1–10 숫자 점수 사분면 라벨(High / Medium / Low)
Input 5개 기준에 대한 주관적 판단 추정된 발생 가능성과 비즈니스 영향
Objectivity 낮음 — 평가자 의존적 중간 — 추정 품질에 따라 달라짐
Scope 위협 수준(설계/아키텍처) 위협 또는 위험 수준
Audience 내부 개발/보안팀 경영진, 빠른 분류
Standardization 없음. 내부 사용 없음. 조직별 정의
Limitation 주관적이며 팀 간 일관성이 떨어짐 수치 정밀도 없음. 거친 단위의 분류
Best used when 초기 설계 단계, 빠른 내부 점수화 경영진 보고, 빠른 우선순위 지정

DREAD

Item Description
Damage 공격 성공 시 피해 규모
Reproducibility 공격을 재현할 수 있는 가능성
Exploitability 공격 실행의 용이성
Affected Users 영향을 받는 사용자 범위
Discoverability 취약점이 발견될 가능성

*각 항목은 1~10점으로 평가한다.

Risk Score (위험도) = (D + R + E + A + D) / 5

Priority Matrix (우선순위 매트릭스)

  Low Likelihood High Likelihood
High Impact 🟡 Medium 🔴 High — 즉시 조치
Low Impact 🟢 Low 🟡 Medium

Vulnerability assessment: 특정 약점을 식별하고 점수화한다. 예: SQL Injection 취약점에 대한 CVSS
Threat assessment: 잠재적 공격 시나리오와 그 발생 가능성 및 영향을 평가한다.
Risk assessment: 위협 평가와 취약점 평가를 결합하여 완화 조치의 우선순위를 정한다.

Q. 평가 지표를 선택하는 기준은?
A. 목적과 맥락에 따라 선택한다.

  • DREAD: 초기 설계 단계에서 내부 팀 단위 위협 모델링에 적합하다. 빠르게 적용할 수 있지만 주관적이다. 점수는 평가자의 판단에 따라 달라진다.
  • Priority Matrix (Likelihood × Impact): 경영진 커뮤니케이션 또는 빠른 분류에 적합하다. 수치 정밀도 없이 직관적인 시각적 우선순위를 제공한다.

실무에서는 빠른 내부 우선순위 지정을 위해 DREAD 또는 Priority Matrix를 사용하고, 공식 문서화나 조직 간 비교 가능성이 필요한 경우 CVSS를 사용한다.


Step 5: Mitigation (대응책 도출)

각 위협에 대해 다음 네 가지 대응 전략 중 하나를 선택한다.

Strategy Description Example
Mitigate
(완화)
위협 발생 가능성 또는 영향을 줄인다. 입력 검증, 암호화 적용
Accept
(수용)
비용 대비 위험이 낮을 때 위험을 감수한다. 낮은 위험도 취약점은 모니터링만 수행
Transfer
(전가)
책임을 외부로 이전한다. 보험 가입, 외부 서비스 이용
Eliminate
(제거)
위협 자체를 유발하는 기능 또는 자산을 제거한다. 불필요한 기능 비활성화

Common Countermeasures per STRIDE (STRIDE별 일반적인 대응책)

Threat Key Countermeasures
Spoofing 강력한 인증 — MFA, 디지털 서명
Tampering HMAC, 디지털 서명, 접근 제어
Repudiation 감사 로그, 타임스탬프
Information Disclosure 전송 중/저장 시 암호화, 최소 권한 원칙
Denial of Service Rate limiting, 이중화, CDN
Elevation of Privilege 최소 권한 원칙, RBAC, 샌드박스

Step 6: Validation & Documentation (검증 및 문서화)

Validation (검증)

  • 도출한 대응책이 실제로 위협을 완화하는지 확인한다.
  • 보안 테스트와 연계한다 — 침투 테스트, 코드 리뷰.
  • 잔여 위험을 평가한다.

Documentation Items (문서화)

  • 식별된 위협 목록 및 STRIDE 분류
  • 위협별 위험도 점수
  • 대응책 및 담당자
  • 검토 일정 및 이력

Roles in assessing threats (위협 평가에서의 역할)

  • Security Team: 위협 모델링 방법론에 대한 전문 지식을 제공하고, 위협 식별을 지원하며, 기술적 위험을 평가한다.
  • Development Team: 시스템 설계, 구현 세부 사항, 완화책의 실현 가능성에 대한 통찰을 제공한다.
  • Product Management: 비즈니스 맥락을 제공하고, 사용자 영향 및 전략적 목표에 따라 위협 우선순위 지정을 지원한다.
  • Compliance/Audit: 식별된 위협과 완화책이 규제 요구사항 및 업계 표준과 일치하는지 확인한다.
  • Executive Leadership: 고수준 위험 평가를 검토하고 완화 노력에 대한 자원 할당을 승인한다.

Vulnerability Classification and Scoring System

Tool Scope Maintained by Primary Use
CVE 특정한 알려진 취약점 인스턴스 MITRE / NVD (NIST) 공개된 취약점을 참조하고 추적
CWE 약점 유형 / 근본 원인 범주 MITRE 설계 또는 코드의 약점 패턴을 분류하고 식별
CWSS CWE 약점에 대한 점수화 모델 MITRE 기술적 영향과 발생 가능성에 따라 약점 우선순위 지정
CAPEC 공격 패턴 카탈로그 MITRE 공격자 기법과 공격 패턴 식별 및 분류
CVSS 취약점 심각도 점수화 시스템 FIRST 표준화된 점수로 취약점 심각도를 정량화하고 전달

CVE (Common Vulnerabilities and Exposures)

  • 알려지고 공개된 취약점 목록. 각 취약점에는 고유 식별자가 부여된다. 예: Log4Shell의 CVE-2021-44228
  • MITRE가 관리하고, NVD(National Vulnerability Database) 가 CVSS 점수와 참고 자료를 보강한다.
  • CVE 항목은 무엇이 취약한지, 즉 제품과 버전, 그리고 어떻게 악용될 수 있는지를 설명하지만, 근본 원인은 설명하지 않는다.
  • 위협 모델링에서 범위 내 구성 요소에 알려진 취약점이 있는지 확인하고, 결과를 공개된 익스플로잇 데이터와 연결하는 데 사용한다.

CVE ID format: CVE-<year>-<sequence> 예: CVE-2024-3094

CWE (Common Weakness Enumeration)

  • 소프트웨어 및 하드웨어 약점 유형에 대한 커뮤니티 기반 카탈로그. 취약점으로 이어지는 근본 원인을 설명한다.
  • MITRE가 관리하며, 계층적 분류 체계로 구성된다. 예: CWE-89: SQL Injection, CWE-79: XSS, CWE-200: Information Exposure
  • 특정 인스턴스인 CVE와 달리, CWE는 여러 제품과 코드베이스에 적용될 수 있는 약점 범주를 설명한다.
  • 위협 모델링에서 위협 뒤에 있는 약점 유형을 라벨링하고 안전한 설계 결정을 안내하는 데 사용한다.
Level Example Meaning
Class CWE-20: Improper Input Validation 넓은 약점 범주
Base CWE-89: SQL Injection 특정 약점 유형
Variant CWE-564: SQL Injection via Hibernate 언어/기술 특화 인스턴스

CWE 항목은 CVE와 함께 자주 참조된다. CVE는 특정 취약 제품 인스턴스를 설명하고, CWE는 그 원인이 된 근본 약점 클래스를 식별한다. 이를 통해 개발자는 근본 원인을 이해하고 적절한 완화책을 적용할 수 있다.

CWSS (Common Weakness Scoring System)

  • CWE 약점 유형의 우선순위를 정량화하기 위한 점수화 프레임워크. CWE 분류를 숫자 점수로 보완한다.
  • MITRE가 관리하며, 점수 범위는 0부터 100까지다.
  • 세 가지 메트릭 그룹에 걸쳐 약점을 평가한다.
Metric Group Description
Technical Impact 악용될 경우 기밀성, 무결성, 가용성에 줄 수 있는 잠재적 피해
Acquisition / Finding 약점을 발견하기 쉬운 정도. 가시성, 자동 탐지 가능성 등
Exploitability 약점을 악용하기 쉬운 정도. 인증 필요 여부, 사용자 상호작용 필요 여부, 보편성 등
  • CVSS보다 덜 널리 사용된다. 주로 CWE 중심 분석, 보안 코딩 이니셔티브, 소프트웨어 보증 프로그램에서 사용된다.
  • 특정 CVE 인스턴스와 독립적으로, 코드베이스나 아키텍처에서 어떤 약점 클래스를 우선 해결할지 정할 때 유용하다.

CAPEC (Common Attack Pattern Enumeration and Classification)

  • 알려진 공격 패턴에 대한 공개 카탈로그. 공격자가 시스템, 소프트웨어, 네트워크의 약점을 어떻게 악용하는지 설명한다.
  • MITRE가 관리한다. 각 항목은 예를 들어 CAPEC-66: SQL Injection처럼 공격 기법, 전제 조건, 실행 단계, 적용 가능한 방어책을 설명한다.
  • CWE를 보완한다. CAPEC 항목은 공격자가 어떻게 행동하는지를 설명하고, CWE는 악용되는 약점을 설명한다.
  • 위협 모델링에서 식별된 시스템 구성 요소에 대한 현실적인 공격 시나리오를 나열하고 이를 STRIDE 범주 또는 ATT&CK 기법에 매핑하는 데 사용한다.

CAPEC ID format: CAPEC-<number> 예: CAPEC-116: Excavation

Level Example Meaning
Meta CAPEC-225: Exploitation of Authentication 넓은 공격 범주
Standard CAPEC-66: SQL Injection 특정 공격 기법
Detailed CAPEC-110: SQL Injection through SOAP 좁은 범위의 공격 변형

CAPEC, CWE, CVE는 하나의 연결 관계를 이룬다. CAPEC은 공격자가 CWE 약점을 어떻게 노리는지 설명하고, 그 약점은 실제 제품에서 특정 CVE로 나타난다.

CVSS (Common Vulnerability Scoring System)

  • 업계 표준 취약점 심각도 점수화 시스템.
  • FIRST(Forum of Incident Response and Security Teams) 가 관리한다. 현재 버전은 v3.1과 v4.0이다.
  • 점수 범위: 0.0 – 10.0 → 심각도 수준에 매핑된다.
Score Severity
0.0 None
0.1 – 3.9 Low
4.0 – 6.9 Medium
7.0 – 8.9 High
9.0 – 10.0 Critical

Score Components

Base Score — 시간이나 환경과 독립적인 취약점 자체의 고유 특성

Metric Group Metrics
Exploitability (공격 용이성) Attack Vector (AV), Attack Complexity (AC), Privileges Required (PR), User Interaction (UI)
Scope (범위) Scope (S) — 취약점이 권한 경계를 넘어 다른 구성 요소에 영향을 주는지 여부
Impact (영향) Confidentiality (C), Integrity (I), Availability (A) — 각각 None / Low / High로 평가

Temporal Score — 현재 익스플로잇 및 패치 상태를 기준으로 Base Score를 조정

Metric Description
Exploit Code Maturity (E) 공개된 동작 가능한 익스플로잇이 있는지 여부
Remediation Level (RL) 공식 패치 또는 우회책이 있는지 여부
Report Confidence (RC) 취약점 보고의 정확성에 대한 신뢰도

Environmental Score — 특정 배포 환경에 맞게 점수를 조정

  • 실제 환경을 반영하기 위해 Base metric을 수정한다. 예를 들어 기밀성이 중요한 시스템에서는 Confidentiality 영향 가중치를 높인다.
  • 벤더가 아니라 점수를 사용하는 조직이 정의한다.

Usage Notes

  • CVSS는 심각도를 측정하지, 위험을 측정하지 않는다. 즉 위협 발생 가능성이나 비즈니스 맥락은 고려하지 않는다.
  • 벤더 권고문과 조직 간 비교에는 CVSS Base Score를 사용한다.
  • 자산 민감도에 맞춘 내부 우선순위 지정에는 Environmental Score를 사용한다.
  • 더 완전한 위험 판단을 위해 threat intelligence와 결합한다. 예: EPSS — Exploit Prediction Scoring System
  Base Score Temporal Score Environmental Score
What it measures 취약점 자체의 고유 심각도 현재 실제 익스플로잇 가능성과 패치 상태 특정 배포 환경에 맞게 조정된 심각도
Changes over time? 아니오 — 공개 시점에 고정 예 — 익스플로잇 공개나 패치 제공에 따라 변경 예 — 환경 변화에 따라 변경
Who defines it? 벤더 / 연구자 벤더 / threat intel 조직 자체
Key inputs AV, AC, PR, UI, Scope, C/I/A 영향 Exploit maturity (E), Remediation level (RL), Report confidence (RC) 수정된 Base metric + 자산 민감도 가중치
Typical use 조직 간 비교, 벤더 권고문, NVD 항목 긴급도 판단. "지금 공개 익스플로잇이 있는가?" 자산 가치에 맞춘 내부 우선순위 지정

실무에서는 먼저 Base Score로 벤더 중립적인 심각도 기준선을 잡는다. 그다음 동작 가능한 익스플로잇이나 패치가 현재 존재하는지 반영하기 위해 Temporal Score를 적용한다. 마지막으로 해당 자산이 실제 환경에서 얼마나 중요한지 반영하기 위해 Environmental Score를 적용한다. 각 단계는 "일반적으로 이 취약점이 얼마나 나쁜가?"에서 "오늘 우리에게 얼마나 긴급한가?"로 범위를 좁힌다.

Summary

Relationships


Threat Modeling Tools example (위협 모델링 도구 예시)

Overview

Name Organization Description
Microsoft Threat Modeling Tool Microsoft Learn DFD 기반의 전통적인 데스크톱 도구. STRIDE 위협과 완화 가이드를 자동 생성한다.
OWASP Threat Dragon OWASP 시각적 위협 모델링과 공격 표면 추적에 중점을 둔 다이어그램 중심 오픈소스 도구.
IriusRisk iriusrisk.com 위험, 통제, remediation workflow 및 일부 AI-assisted input을 제공하는 상용 플랫폼.
Threagile GitHub architecture-as-code와 보고서 생성을 위한 YAML 기반 위협 모델링 툴킷.
OWASP pytm OWASP DFD, sequence diagram, threats를 생성하는 Python 코드 정의 기반 위협 모델링 도구.
ThreatSpec GitHub 코드 주석과 annotation을 통해 수행하는 개발자 중심 위협 모델링.
AWS Threat Composer AWS Documentation AWS 문서와 대응 산출물에 맞춰진 VS Code 기반 위협 모델링 경험.

Input & Output

Name Input Output
Microsoft Threat Modeling Tool DFD, trust boundary, data store, process, external entity STRIDE 기반 위협 목록, 완화책, 보고서
OWASP Threat Dragon Diagram, system components, data flow 위협 기록, 완화책, 공격 표면 시각화
IriusRisk Architecture/components/patterns, 일부 AI-assisted inputs Risk, control, requirement, remediation workflow
Threagile YAML로 작성된 architecture model Risks/threats, diagrams, hardening recommendations, reports
OWASP pytm Python 코드로 정의된 system model DFD, sequence diagram, threats
ThreatSpec Code comments/annotations Threat model report, data-flow diagrams
AWS Threat Composer VS Code에서 작성된 threat model documents/components Security issues, response strategy, threat model artifact

Tools & Supported Methods

Tool Methods Notes
Microsoft Threat Modeling Tool STRIDE per Element 생성된 위협과 완화책을 위한 핵심 내장 방법론. (1, 8)
OWASP Threat Dragon STRIDE, LINDDUN, CIA, DIE, PLOT4ai Rule engine은 선택한 모델을 사용해 위협/완화책을 자동 생성할 수 있다. (2, 9)
IriusRisk Methodology-agnostic, custom libraries, framework mapping 예: ATT&CK/NIST/PCI DSS/GDPR/FedRAMP 조직별 분류와 컴플라이언스 중심 분류 오버레이를 지원한다. (10, 11)
Threagile STRIDE + CWE mapping Risk categories는 모델/규칙/보고서에서 STRIDE field와 CWE linkage를 포함한다. (4, 12)
OWASP pytm Rule-based custom threat library, CAPEC/CWE/CVE references, CVSS override Threats는 조건부 규칙에서 생성된다. findings별 severity/CVSS를 커스터마이즈할 수 있다. (5, 13)
ThreatSpec Annotation-based custom taxonomy 예: @threat, @mitigates, optional CWE-style tagging 분류는 주로 코드 annotation과 report template을 통해 팀이 정의한다. (6)
AWS Threat Composer STRIDE metadata classification + Priority Threat entries는 STRIDE labels(S/T/R/I/D/E)와 prioritization metadata를 포함한다. (7, 14)

Other Helpful Tools for Threat Modeling

Tool Description
draw.io / Lucidchart 수동 DFD 작성을 위한 다이어그램 도구

References & Frameworks

  • OWASP Threat Modeling
  • OWASP Threat Modeling Process
  • Microsoft STRIDE
  • MITRE ATT&CK
  • CAPEC (Common Attack Pattern Enumeration and Classification)
  • NIST SP 800-30: Guide for Conducting Risk Assessments
  • NIST SP 800-154: Guide to Data-Centric System Threat Modeling
  • Threat Modeling: Designing for Security — Adam Shostack
  • Security Engineering — Ross Anderson

'Security' 카테고리의 다른 글

26.05.12 트로이목마 실제 해킹 사례: Trojan:Script/Wacatac.B!ml  (0) 2026.05.16
'Security' 카테고리의 다른 글
  • 26.05.12 트로이목마 실제 해킹 사례: Trojan:Script/Wacatac.B!ml
ybjeon.today
ybjeon.today
#Security #AI #LLM #일상 #공부 #연구, 프로필: https://ybjeon.today
  • ybjeon.today
    ybjeon's today
    ybjeon.today
  • 전체
    오늘
    어제
  • 링크

    • Github
    • Homepage
  • 블로그 메뉴

    • 전체 보기
    • Security
    • LLM AI Agent
    • AI Agent Security
    • Development
    • 방명록
  • 태그

    Security
    llm
    NEWS
    coding
    review
    Agent
    ToDo
    ai
  • 인기 글

    • 분류 전체보기 (16) N
      • Dev (4) N
      • Security (2)
      • AI Agent Security (5) N
      • LLM AI Agent (4)
      • Tech News (1) N
  • 공지사항

  • 최근 댓글

  • 최근 글

  • hELLO· Designed By정상우.v4.10.6
ybjeon.today
Threat modeling (위협 모델링)
상단으로

티스토리툴바