1---
2name: security-requirement-extraction
3description: Derive security requirements from threat models and business context. Use when translating threats into actionable requirements, creating security user stories, or building security test cases.
4---
5 
6# Security Requirement Extraction
7 
8Transform threat analysis into actionable security requirements.
9 
10## When to Use This Skill
11 
12- Converting threat models to requirements
13- Writing security user stories
14- Creating security test cases
15- Building security acceptance criteria
16- Compliance requirement mapping
17- Security architecture documentation
18 
19## Core Concepts
20 
21### 1. Requirement Categories
22 
23```
24Business Requirements → Security Requirements → Technical Controls
25         ↓                       ↓                      ↓
26  "Protect customer    "Encrypt PII at rest"   "AES-256 encryption
27   data"                                        with KMS key rotation"
28```
29 
30### 2. Security Requirement Types
31 
32| Type               | Focus                   | Example                               |
33| ------------------ | ----------------------- | ------------------------------------- |
34| **Functional**     | What system must do     | "System must authenticate users"      |
35| **Non-functional** | How system must perform | "Authentication must complete in <2s" |
36| **Constraint**     | Limitations imposed     | "Must use approved crypto libraries"  |
37 
38### 3. Requirement Attributes
39 
40| Attribute        | Description                 |
41| ---------------- | --------------------------- |
42| **Traceability** | Links to threats/compliance |
43| **Testability**  | Can be verified             |
44| **Priority**     | Business importance         |
45| **Risk Level**   | Impact if not met           |
46 
47## Templates and detailed worked examples
48 
49Full template library lives in `references/details.md`. Read that file when you need concrete templates for this skill.
50 
51## Best Practices
52 
53### Do's
54 
55- **Trace to threats** - Every requirement should map to threats
56- **Be specific** - Vague requirements can't be tested
57- **Include acceptance criteria** - Define "done"
58- **Consider compliance** - Map to frameworks early
59- **Review regularly** - Requirements evolve with threats
60 
61### Don'ts
62 
63- **Don't be generic** - "Be secure" is not a requirement
64- **Don't skip rationale** - Explain why it matters
65- **Don't ignore priorities** - Not all requirements are equal
66- **Don't forget testability** - If you can't test it, you can't verify it
67- **Don't work in isolation** - Involve stakeholders
68