063. 위협 모델링 (Threat Modeling)

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

1. 본질: 위협 모델링(Threat Modeling)은 시스템 설계 단계에서 자산, 공격면, 신뢰 경계, 위협을 체계적으로 찾는 보안 분석이다.
2. 가치: 개발이 끝난 뒤 취약점을 찾는 것보다, 설계 초기에 공격 경로를 막는 편이 훨씬 싸고 효과적이다.
3. 판단: STRIDE, DREAD, MITRE ATT&CK 같은 틀을 사용해 위협을 분류하고 우선순위를 정해야 한다.

Ⅰ. 개요 및 필요성

보안 사고는 종종 코드 한 줄보다 설계 한 장에서 시작된다. 어떤 데이터가 어디를 지나고 누가 볼 수 있는지 모르면, 공격자는 그 빈틈을 먼저 찾는다.

위협 모델링은 "무엇이 뚫릴 수 있는가"를 미리 묻는 작업이다. 그래서 시큐어 코딩보다 앞단에서 작동하는 보안 설계 도구다.

• 📢 섹션 요약 비유: 새 집에 들어가기 전에 창문, 문, 담장부터 살펴보는 것과 같다.

Ⅱ. 아키텍처 및 핵심 원리

Assets
  ↓
Data Flow Diagram
  ↓
Trust Boundaries
  ↓
Threat Identification
  ↓
Risk Prioritization
  ↓
Mitigation

위협 모델링은 DFD(Data Flow Diagram)를 그려 흐름을 파악한 뒤, 경계마다 어떤 위협이 가능한지 묻는다. 이때 중요한 것은 "취약점 목록"보다 "공격 시나리오"다.

• 📢 섹션 요약 비유: 집 평면도를 보고 어디로 침입할 수 있는지 상상하는 일이다.

Ⅲ. 비교 및 연결

위협 모델링은 다른 보안 활동을 대체하지 않는다. 대신 어떤 코드를 더 엄격히 봐야 하는지, 어떤 경계를 더 강하게 해야 하는지 알려준다.

• 📢 섹션 요약 비유: 여행 전에 지도를 보고 위험한 길을 미리 피해 가는 것과 같다.

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

체크리스트

1. 자산과 신뢰 경계가 명확한가?
2. 외부 입력과 내부 시스템 경로를 모두 그렸는가?
3. STRIDE 관점으로 각 경로를 검사했는가?
4. 위협별 대응책이 실제 설계에 반영되었는가?
5. 위험 우선순위를 정해 단계적으로 보완하는가?

안티패턴

• 보안 문서를 만들고 실제 설계에는 반영하지 않는 설계
• 공격 경로 대신 기능 목록만 나열하는 설계
• 모든 위협을 동일하게 취급하는 설계
• 개발이 끝난 뒤에야 위협 모델링을 하는 설계

기술사 관점에서는 위협 모델링을 "보안 리뷰"가 아니라 "설계 품질 검증"으로 봐야 한다. 공격자 시나리오를 먼저 생각하면 방어도 명확해진다.

• 📢 섹션 요약 비유: 문지기 없이 문을 여러 개 만든 뒤 나중에 경비를 붙이는 것보다 처음부터 어디가 문인지 정하는 편이 낫다.

Ⅴ. 기대효과 및 결론

위협 모델링은 보안 비용을 앞당겨 지불하게 만들지만, 그 결과 더 큰 사고를 줄인다. 설계 단계에서 막을 수 있으면 운영 중 장애도 줄어든다.

결국 좋은 위협 모델링은 "누가 어떻게 들어올 수 있는가"를 끝까지 상상하는 일이다.

• 📢 섹션 요약 비유: 미리 함정을 찾으면 나중에 다치는 사람이 줄어든다.

관련 개념 맵

Assets
  ↓
Threat Modeling
  ↓
STRIDE / DREAD
  ↓
Mitigation Plan

관련 키워드 및 발전 흐름도

DFD
  ↓
Trust Boundary
  ↓
Threat Modeling
  ↓
Secure Design

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

새 집에 들어가기 전에 어디로 들어올 수 있는지 먼저 봐요.
문, 창문, 담장에 구멍이 없는지 확인해요.
위협 모델링은 그런 구멍을 미리 찾는 일이에요.