063. 위협 모델링 (Threat Modeling)

⚠️ 이 문서는 소프트웨어나 시스템을 본격적으로 개발하기 전(설계 단계)에, 해커의 입장이 되어 우리 시스템의 어느 부분이 어떻게 뚫릴 수 있는지를 논리적이고 구조적으로 예측해 내는 '위협 모델링(Threat Modeling)' 기법을 다룹니다.

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

  1. 본질: 위협 모델링은 아키텍처 설계도(데이터 흐름도, DFD)를 책상에 펼쳐놓고, 데이터가 움직이는 길목마다 "여기를 해커가 스니핑(가로채기)하면? 이 서버가 터지면?"이라는 질문을 던져 보안 구멍을 미리 시뮬레이션(Brainstorming)하는 공학적 분석 기법이다.
  2. 가치: "다 짓고 나서 뚫어보는" 모의해킹(Pen-test)과 달리, 삽을 뜨기도 전인 설계(Design) 단계에서 치명적인 결함을 잡아내어 아키텍처를 수정하므로, 나중에 시스템을 다 갈아엎어야 하는 **재작업 비용(Rework Cost)을 획기적으로 절감(Shift-Left)**한다.
  3. 융합: 분석을 체계적으로 진행하기 위해 마이크로소프트의 STRIDE(위협 식별) 모델과 DREAD(위험도 평가) 모델을 도구로 사용하며, 발견된 위협들은 보안 아키텍처(SABSA)의 설계 요구사항으로 직접 융합된다.

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

건축가가 은행 도면을 그릴 때 "창문을 뚫고 도둑이 들어올 수 있으니 여기는 방탄유리를 쓰자"라고 미리 예측하는 것은 당연하다. 그런데 유독 소프트웨어 세계에서는 "일단 빨리 코딩해서 올려보고, 털리면 그때 막자(Bolt-on Security)"는 기형적인 문화가 만연했다.

**위협 모델링(Threat Modeling)**은 이러한 문화를 타파하고 내재적 보안(Security by Design)을 실천하기 위한 가장 핵심적인 방법론이다. 개발자, 아키텍트, 보안 담당자가 한 방에 모여 화이트보드에 그림을 그리고 해커의 시선(Attacker's Perspective)으로 시스템을 산산조각 내보는 창의적이면서도 구조화된 방어 훈련이다.

📢 섹션 요약 비유: 성을 쌓기 전 모래사장에 성의 모형을 만들어두고, 방어 대장(설계자)과 가상의 적군(해커 역할)이 "내가 밤에 몰래 땅굴을 파서 우물에 독을 타면 어떻게 할래?"라며 장기판에서 수 싸움을 벌이며 성의 약점을 미리 고쳐나가는 작전 회의입니다.

Ⅱ. 위협 모델링의 4단계 프로세스

마이크로소프트(MS) 등에서 권장하는 위협 모델링은 일반적으로 다음의 4가지 질문과 단계를 거친다.

  1. 무엇을 만들고 있는가? (Decompose the Application)
    • 시스템의 생김새를 분해한다. **데이터 흐름도(DFD, Data Flow Diagram)**를 그려서 외부 사용자, 웹 서버, DB 서버 간에 데이터가 어떻게 흘러가는지(화살표), 신뢰 경계선(Trust Boundary, 예: 인터넷과 내부망의 경계)은 어디인지를 명확히 시각화한다.
  2. 무엇이 잘못될 수 있는가? (Determine and Rank Threats)
    • 그려놓은 DFD의 각 요소(프로세스, 데이터 저장소, 흐름선)마다 어떤 공격이 들어올 수 있는지 식별한다. 이때 그냥 막연히 상상하는 것이 아니라 STRIDE 모델 같은 공식표를 대입하여 체계적으로 털어본다.
  3. 그 문제를 어떻게 해결할 것인가? (Determine Countermeasures)
    • 발견된 위협(예: 데이터 전송 중 가로채기)에 대해 방어책(예: TLS 암호화 적용)을 수립하고, 설계도에 이를 반영하여 수정한다.
  4. 우리가 일을 제대로 했는가? (Mitigate and Review)
    • 이 방어책이 실제로 위협을 없앴는지 리뷰하고, 잔여 위험(Residual Risk)이 수용 가능한 수준인지 경영진과 합의한다.
┌────────────────────────────────────────────────────────────────────────────────┐
│           데이터 흐름도(DFD) 기반의 위협 모델링 예시 시각화                    │
├────────────────────────────────────────────────────────────────────────────────┤
│                                                                                │
│ [신뢰 구역 (안전 X)]       │ 신뢰 경계선 (Trust Boundary)                      │
│                        │                                                       │
│  ┌──────────┐  (위협 1) │ (위협 2)     ┌─────────────────┐                     │
│  │ 외부 클라이언트│ ──(로그인 ID/PW)──▶ │   인증 서버 프로세스  │              │
│  │ (모바일 앱) │ ◀──(세션 토큰 반환)── │  (Authentication) │                   │
│  └──────────┘          │            └────────┬────────┘                        │
│                        │                     │(위협 3)                         │
│ -----------------------┼---------------------▼------------                     │
│                        │               ┌───────────┐                           │
│ [신뢰 구역 (안전 O)]       │               │ 회원 DB (저장소)│                 │
│                        │               └───────────┘                           │
│                                                                                │
│ * 브레인스토밍 (해커의 빙의):                                                  │
│  - 위협 1 (Spoofing): 해커가 남의 ID/PW를 훔쳐서 앱으로 접속하면?              │
│  - 위협 2 (Tampering): 인터넷 전송 중에 암호가 평문으로 날아가면 털리지 않나?  │
│  - 위협 3 (Info Disc.): 내부 직원이 DB를 몰래 복사해 가면 어쩌지?              │
└────────────────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 위협 모델링의 시작점인 DFD다. 점선으로 표시된 '신뢰 경계선(Trust Boundary)'을 넘어가는 저 화살표 구간이 가장 해킹당하기 쉬운 취약점이다. 아키텍트는 화살표 위에 "TLS 1.3 통신"이라는 보완책을 그리고, DB 위에는 "AES-256 암호화 저장"이라는 방패를 그려 넣음으로써, 코딩을 1줄도 시작하기 전에 완벽한 아키텍처 방어벽을 완성해 낸다.

  • 📢 섹션 요약 비유: 은행 금고 설계도를 벽에 걸어놓고 "환풍구(신뢰 경계)로 도둑이 기어들어 올 수 있으니 여기에 철창(보안 대책)을 달자"고 빨간 펜으로 표시하는 과정입니다. 건물을 다 짓고 나서 환풍구를 뜯어고치는 것보다 100배는 빠르고 쌉니다.

Ⅲ. 실무 적용의 짝꿍: STRIDE와 DREAD 모델

"무엇이 잘못될까?"를 백지에서 생각하면 놓치는 것이 많다. 그래서 마이크로소프트는 위협(Threat)의 종류를 6개로 정형화한 STRIDE 모델과, 그 위협이 얼마나 치명적인지 점수를 매기는 DREAD 모델을 창안했다. 위협 모델링 회의에서 아키텍트가 쥐고 있는 핵심 무기다. (상세 내용은 이어지는 064, 065 문서에서 깊게 다룬다.)

  • STRIDE (어떤 공격이 들어올까?): 신분 위장(S), 데이터 변조(T), 발뺌(R), 정보 유출(I), 서비스 거부(D), 권한 상승(E)의 앞 글자를 딴 6대 위협 분류표.
  • DREAD (얼마나 위험할까?): 발견된 위협이 터졌을 때 회사가 망할 수준인지(Damage), 해커가 찌르기 쉬운지(Exploitability) 등을 0~10점으로 계산하여 "이것부터 고치자"라고 우선순위를 정해주는 채점표.

Ⅳ. 최신 트렌드: MITRE ATT&CK과의 맵핑

과거의 위협 모델링(STRIDE)은 "데이터가 변조될 수 있다"는 다소 원론적인 수준에 머물렀다. 최신 보안 아키텍처들은 이를 보완하기 위해 실전 해커들의 전술/기법 백과사전인 MITRE ATT&CK 프레임워크를 위협 모델링에 융합한다.

  • 적용 시나리오:
    1. DFD 상의 '인증 서버'에 위협 모델링을 한다.
    2. 단순하게 "권한 상승(Elevation) 위협이 있다"고 적지 않는다.
    3. MITRE ATT&CK 매트릭스를 열고 "T1110 (Brute Force 공격)과 T1558 (Credential Stuffing 공격)이 들어올 확률이 높다"고 구체적인 해커의 '전술/기법(TTPs)' 수준으로 맵핑한다.
    4. 방어책으로 "로그인 5회 실패 시 잠금, reCAPTCHA 도입, FIDO 인증 적용"이라는 아주 날카롭고 실전적인 보안 설계가 도출된다.

Ⅴ. 결론

"해킹의 90%는 코더의 오타가 아니라, 아키텍트의 오판에서 비롯된다." 위협 모델링(Threat Modeling)은 개발자들에게 코드를 짜기 전 잠깐 멈춰서(Stop) "해커라면 이 코드를 어떻게 요리할까?"를 묻게 만드는 생각의 전환(Mindset Shift)이다. 이를 건너뛴 시스템은 모래 위에 지은 성과 같으며, 위협 모델링은 그 성의 기초를 암반까지 파고들어 단단하게 다지는 소프트웨어 생명주기(SDLC)의 가장 빛나는 첫 단추다.

📌 관련 개념 맵

  • 소프트웨어 보안(SDLC): Security by Design (가장 상위 철학) $\rightarrow$ Threat Modeling (설계 단계 구현체)
  • 핵심 도구 모델: STRIDE (위협 식별), DREAD (위험도 산정), PASTA (위협 모델링 프로세스)
  • 다이어그램 도구: DFD (Data Flow Diagram, 데이터 흐름도), 신뢰 경계(Trust Boundary)
  • 진화된 프레임워크: MITRE ATT&CK (실전 전술 기반 위협 식별)

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

  1. 게임을 만들기 전에, "만약 나쁜 유저가 벽을 뚫고 들어가서 혼자 아이템을 다 털어가면 어떡하지?" 하고 미리 걱정해 보는 시간이에요.
  2. 걱정만 하는 게 아니라, 게임 지도(데이터 흐름도)를 펼쳐놓고 "여기에 투명 벽(방어책)을 세우자!"라고 미리 그림을 고치는 거죠.
  3. 이렇게 게임을 만들면 진짜로 나쁜 유저가 들어왔을 때 우리가 세워둔 투명 벽에 쿵 부딪혀서 아무것도 훔쳐 가지 못한답니다!