6.6 KiB
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 |
|
|
|
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 검토.