Security Requirement Extraction

Transform threat analysis into actionable security requirements.

When to Use This Skill

• Converting threat models to requirements
• Writing security user stories
• Creating security test cases
• Building security acceptance criteria
• Compliance requirement mapping
• Security architecture documentation

Core Concepts

1. Requirement Categories

Business Requirements → Security Requirements → Technical Controls
         ↓                       ↓                      ↓
  "Protect customer    "Encrypt PII at rest"   "AES-256 encryption
   data"                                        with KMS key rotation"

2. Security Requirement Types

| Type | Focus | Example | | ------------------ | ----------------------- | ------------------------------------- | | Functional | What system must do | "System must authenticate users" | | Non-functional | How system must perform | "Authentication must complete in <2s" | | Constraint | Limitations imposed | "Must use approved crypto libraries" |

3. Requirement Attributes

| Attribute | Description | | ---------------- | --------------------------- | | Traceability | Links to threats/compliance | | Testability | Can be verified | | Priority | Business importance | | Risk Level | Impact if not met |

Templates and detailed worked examples

Full template library lives in references/details.md. Read that file when you need concrete templates for this skill.

Best Practices

Do's

• Trace to threats - Every requirement should map to threats
• Be specific - Vague requirements can't be tested
• Include acceptance criteria - Define "done"
• Consider compliance - Map to frameworks early
• Review regularly - Requirements evolve with threats

Don'ts

• Don't be generic - "Be secure" is not a requirement
• Don't skip rationale - Explain why it matters
• Don't ignore priorities - Not all requirements are equal
• Don't forget testability - If you can't test it, you can't verify it
• Don't work in isolation - Involve stakeholders