Files
2nd/10_Wiki/Topics/Coding/DevSec_Threat_Modeling.md
T
2026-05-09 21:08:02 +09:00

6.6 KiB

id, title, category, status, source_trust_level, verification_status, created_at, updated_at, tags, tech_stack, applied_in, aliases
id title category status source_trust_level verification_status created_at updated_at tags tech_stack applied_in aliases
devsec-threat-modeling Threat Modeling — STRIDE / Trust Boundary Coding draft B conceptual 2026-05-09 2026-05-09
devsecops
threat-modeling
security
vibe-coding
language applicable_to
Process
Security
STRIDE
threat modeling
attack tree
DREAD
OCTAVE
data flow diagram

Threat Modeling

"어떤 공격 가능한가" 사전 분석. STRIDE 가 표준 — Spoofing / Tampering / Repudiation / Info Disclosure / DoS / Elevation. 새 feature design 시.

📖 핵심 개념

  • Asset: 보호할 것 (사용자 데이터, money, reputation).
  • Threat: 위협 (공격 vector).
  • Trust boundary: trust level 변화 (untrusted → trusted).
  • Mitigation: 방어 control.

💻 코드 패턴

STRIDE

S - Spoofing: identity 위조 (다른 사람으로 로그인)
T - Tampering: 데이터 변조 (request body 변경)
R - Repudiation: 부인 (audit log 없어 누가 했는지 모름)
I - Info Disclosure: 정보 누출
D - DoS: 서비스 마비
E - Elevation of privilege: 권한 상승

4-Step process

1. Diagram: 시스템 / data flow 그리기
2. Identify threats: 각 component 에 STRIDE 적용
3. Mitigate: 방어 control 디자인
4. Validate: 검증 (test, audit, pen test)

Data Flow Diagram (DFD)

[User Browser] --HTTPS--> [API Gateway] --gRPC--> [Order Service] --SQL--> [PostgreSQL]
                                                          |
                                                          v
                                                       [Stripe API]

Trust boundaries:
- User browser ↔ API Gateway: external
- API Gateway ↔ Order Service: internal (mTLS)
- Order Service ↔ Stripe: external API

각 component 에 STRIDE

## API Gateway
- S (Spoofing): 다른 user 가 다른 user 로 로그인?
  → JWT signature + short expiry + refresh token rotation
- T (Tampering): Request 변조?
  → HTTPS + JWT signed + body validation (zod)
- R (Repudiation): 사용자가 "안 했다" 부인?
  → Audit log + signed actions
- I (Info Disclosure): 토큰 leak?
  → HttpOnly cookie + Secure + SameSite
- D (DoS): Brute force / flood?
  → Rate limit per IP / per user + WAF
- E (Elevation): 일반 user 가 admin?
  → Role check at every protected endpoint + RLS in DB

## Order Service
- T (Tampering): Order amount 변경?
  → Server-side calc, never trust client amount
- I: Other user's orders?
  → user_id check + RLS
- E: User → admin endpoint?
  → middleware check, separate admin namespace

자주 빠뜨리는

- Time-of-check vs time-of-use (race)
- IDOR (예측 가능 ID + 검증 안 함)
- SSRF (사용자 URL → internal network)
- Mass assignment (extra fields 받음)
- Server-side request smuggling
- Cache poisoning
- Subdomain takeover
- Open redirect
- ReDoS (regex 무한)
- Prototype pollution

Attack tree

Goal: Steal user credentials
├── Phishing
│   ├── Email
│   └── Lookalike domain
├── XSS
│   ├── Stored XSS
│   └── Reflected XSS
├── Token theft
│   ├── localStorage XSS
│   └── Cookie theft (no HttpOnly)
└── Brute force
    └── Weak password + no lockout

→ 모든 leaf 에 mitigation.

LLM agent 에서 새 위협

- Prompt injection (사용자 input → system prompt 우회)
- Data exfiltration (사용자가 LLM 에 다른 사용자 데이터 추출)
- Tool abuse (사용자가 LLM 통해 임의 tool 호출)
- Model poisoning (training data 오염)
// Mitigation
- System prompt 명시 + boundary
- Tool 권한 제한 (per user scope)
- Output filter (PII, harmful content)
- Audit log (모든 LLM call)
- Rate limit

Tools

Microsoft Threat Modeling Tool:    무료, Windows
OWASP Threat Dragon:               OSS, web
PyTM (코드로 model):                python
ATT&CK / D3FEND framework:         knowledge base
LINDDUN (privacy-focused):         GDPR

코드로 model (PyTM)

from pytm import TM, Server, Datastore, Dataflow, Boundary, Actor

tm = TM('My API')
internet = Boundary('Internet')
internal = Boundary('Internal')

user = Actor('User'); user.inBoundary = internet
api = Server('API'); api.inBoundary = internal
db = Datastore('PostgreSQL'); db.inBoundary = internal

f1 = Dataflow(user, api, 'HTTPS request'); f1.protocol = 'HTTPS'
f2 = Dataflow(api, db, 'SQL query'); f2.protocol = 'SQL'

tm.process()

→ Markdown report 자동.

정기 review

- 새 feature design 시
- 외부 통합 추가 시
- 매 6개월
- Incident 후
- 큰 architecture 변경 후

Bug bounty

HackerOne / Bugcrowd 가 외부 검증.
정기 pen test + 일상 bug bounty 결합.

Mitigation 우선순위

DREAD score:
- Damage potential: 1-10
- Reproducibility: 1-10
- Exploitability: 1-10
- Affected users: 1-10
- Discoverability: 1-10

→ 합 / 5 = severity. 큰 거 먼저.

또는 CVSS 가 표준.

Documentation 예

# Order API — Threat model

## Assets
- User data (email, address, payment)
- Money (charges)
- Audit trail

## Trust boundaries
- Internet → API gateway (TLS, auth)
- Service ↔ DB (mTLS, scoped credentials)

## Top threats
1. **IDOR on /orders/:id** (severity: high)
   - Mitigation: user_id check + RLS
   - Test: integration test 다른 사용자 order
2. **Race in payment** (severity: high)
   - Mitigation: Idempotency key
3. **Webhook signature bypass** (severity: critical)
   - Mitigation: HMAC + raw body + replay check

Continuous threat modeling

- PR template 에 "Security considerations?" 항목
- Threat model 가 git 안 (변경 git diff)
- 사고 시 model update

🤔 의사결정 기준

상황 추천
매 feature 짧은 STRIDE
큰 service / 새 architecture Full DFD + STRIDE
Privacy / GDPR LINDDUN
Compliance OWASP ASVS checklist
Quick assessment Attack tree
Long-term Threat Dragon / PyTM

안티패턴

  • Threat model 1회 + 안 update: stale.
  • LIST only — mitigation 안 매핑: 액션 없음.
  • "안전하다 가정": 검증 없음.
  • Compliance checklist 만: 실제 위협 안 봄.
  • 개발자 외 — security 만 작성: 도메인 모름.
  • 매번 처음부터: template 재사용.
  • 공격자 마음 안 들어감: defensive 만.

🤖 LLM 활용 힌트

  • STRIDE per component + Attack tree per goal.
  • LLM = prompt injection / data exfil / tool abuse 별도.
  • 매 PR 가 작은 threat 검토.

🔗 관련 문서