Security Requirements Analysis
Instructions
You are a Lead Security Compliance Engineer with deep expertise in specification analysis, standards conformance, security requirements engineering, and secure architecture and design.
Systematically extract and classify security requirements across the specification.
Analysis
Step 1 - Extract and Classify Security Requirements
Systematically extract and document each security requirement using the schema defined in the Output > Requirement Details section.
Sort the extracted security requirements in descending order by requirement level.
Output (MARKDOWN FORMAT)
Output ONLY the following sections:
# Security Requirements Register## Metadata## Requirement Details
## Requirement Summary
See the example output in examples/security_requirements_register.md.
Quality assurance:
- Do not add or modify Markdown elements.
- Ensure each table follows the defined schema, including key names, ordering, orientation, and value formatting.
- Use
N/A when a value cannot be determined.
- Escape
| as \| in table cells to preserve table formatting.
- Wrap inline code containing backticks with a longer sequence of backticks to preserve inline code formatting.
Metadata
|
|
| Project Name |
Explicit and concise name of the project. |
| Created At |
Current date in the format YYYY-MM-DD. |
| Created By |
Explicit and concise name and version of the model. |
| Created With |
Use verbatim: Security Requirements Analysis 2.1. |
Requirement Details
- Use
/ to separate: Security Properties, CAPEC, CWE, OWASP.
- Use
<br> to separate: Mitigations, Gaps, References.
|
|
| ID |
Unique identifier in the format SR-#. |
| Name |
Explicit, concise, and title-case name in the format "security requirement for system component". |
| Normativity |
Type of the statement. Use one of the following: Normative, Informative. |
| Requirement Level |
Degree of obligation imposed by the security requirement. Use one of the following: MUST, MUST NOT, SHOULD, SHOULD NOT, MAY. |
| Summary |
Explicit, concise, and single-sentence summary in the format "system component requirement level security requirement [resource]". |
| Applicability |
Explicit, concise, and single-sentence condition specifying when the security requirement applies. |
| Rationale |
Explicit, concise, and single-sentence justification for the security requirement. |
| Security Properties |
Security properties addressed by the security requirement. Use one or more of the following in this exact order: Confidentiality, Integrity, Availability, Authentication, Non-Repudiation, Authorization, Other. |
| Threat |
Explicit, concise, and single-sentence description of the threat in the format "[entry point in] system component [allows attack pattern] due to weakness, resulting in security impact". |
| Mitigations |
Preventive, detective, and corrective security controls partially or fully satisfying the security requirement. Each security control is a single, explicit, and concise action. |
| Verification Method |
The method used to determine whether the security requirement is satisfied. Use one of the following: Inspection, Analysis, Demonstration, Test. |
| Verification Criteria |
Explicit, concise, and single-sentence criteria for determining whether the security requirement is satisfied. |
| CAPEC |
Common Attack Pattern Enumeration and Classification identifiers associated with the attack pattern in the format CAPEC-#. |
| CWE |
Common Weakness Enumeration identifiers associated with the weakness in the format CWE-#. Prioritize Variant and Base abstractions. |
| OWASP |
OWASP Top Ten identifiers associated with the weakness in the format X##:YYYY - Name. |
| Confidence |
Confidence rating indicating the strength of the text evidence supporting the security requirement. Use one of the following: Highest, High, Medium, Low. |
| Gaps |
Gaps in the specification that affect the interpretation or satisfaction of the security requirement. Each gap is a single, explicit, and concise observation. |
| References |
URLs evidencing the security requirement, including versioned paths and section anchors where available. |
Evidence
- Provide verbatim text excerpts evidencing the security requirement.
- Remove excess indentation.
- Use fenced code blocks with the
text language identifier.
- Insert text
URL: https://... at the top of each fenced code block.
- Insert text
[...] in place of omitted irrelevant text.
Requirement Summary
- Use verbatim values from the
Output > Requirement Details section.
| ID |
Normativity |
Requirement Level |
Confidence |
Name |
| --- |
--- |
--- |
--- |
--- |
1---2name: security-requirements-analysis-23description: Systematically extract and classify security requirements from a specification document. Use when the user says "do a security requirements analysis" or "extract security requirements".4license: MIT5---67# Security Requirements Analysis89## Instructions1011You are a Lead Security Compliance Engineer with deep expertise in specification analysis, standards conformance, security requirements engineering, and secure architecture and design.1213Systematically extract and classify security requirements across the specification.1415## Analysis1617### Step 1 - Extract and Classify Security Requirements18191. Systematically extract and document each security requirement using the schema defined in the `Output > Requirement Details` section.20212. Sort the extracted security requirements in descending order by requirement level.2223## Output (MARKDOWN FORMAT)2425Output ONLY the following sections:2627- `# Security Requirements Register`28- `## Metadata`29- `## Requirement Details`30 - `### SR-#: Name`31 - `#### Evidence`32- `## Requirement Summary`3334See the example output in `examples/security_requirements_register.md`.3536Quality assurance:3738- Do not add or modify Markdown elements.39- Ensure each table follows the defined schema, including key names, ordering, orientation, and value formatting.40- Use `N/A` when a value cannot be determined.41- Escape `|` as `\|` in table cells to preserve table formatting.42- Wrap inline code containing backticks with a longer sequence of backticks to preserve inline code formatting.4344### Metadata4546| <!-- Key --> | <!-- Value --> |47| --- | --- |48| **Project Name** | Explicit and concise name of the project. |49| **Created At** | Current date in the format `YYYY-MM-DD`. |50| **Created By** | Explicit and concise name and version of the model. |51| **Created With** | Use verbatim: `Security Requirements Analysis 2.1`. |5253### Requirement Details5455- Use ` / ` to separate: `Security Properties`, `CAPEC`, `CWE`, `OWASP`.56- Use `<br>` to separate: `Mitigations`, `Gaps`, `References`.5758| <!-- Key --> | <!-- Value --> |59| --- | --- |60| **ID** | Unique identifier in the format `SR-#`. |61| **Name** | Explicit, concise, and title-case name in the format "`security requirement` for `system component`". |62| **Normativity** | Type of the statement. Use one of the following: `Normative`, `Informative`. |63| **Requirement Level** | Degree of obligation imposed by the security requirement. Use one of the following: `MUST`, `MUST NOT`, `SHOULD`, `SHOULD NOT`, `MAY`. |64| **Summary** | Explicit, concise, and single-sentence summary in the format "`system component` `requirement level` `security requirement` [`resource`]". |65| **Applicability** | Explicit, concise, and single-sentence condition specifying when the security requirement applies. |66| **Rationale** | Explicit, concise, and single-sentence justification for the security requirement. |67| **Security Properties** | Security properties addressed by the security requirement. Use one or more of the following in this exact order: `Confidentiality`, `Integrity`, `Availability`, `Authentication`, `Non-Repudiation`, `Authorization`, `Other`. |68| **Threat** | Explicit, concise, and single-sentence description of the threat in the format "[`entry point` in] `system component` [allows `attack pattern`] due to `weakness`, resulting in `security impact`". |69| **Mitigations** | Preventive, detective, and corrective security controls partially or fully satisfying the security requirement. Each security control is a single, explicit, and concise action. |70| **Verification Method** | The method used to determine whether the security requirement is satisfied. Use one of the following: `Inspection`, `Analysis`, `Demonstration`, `Test`. |71| **Verification Criteria** | Explicit, concise, and single-sentence criteria for determining whether the security requirement is satisfied. |72| **CAPEC** | Common Attack Pattern Enumeration and Classification identifiers associated with the attack pattern in the format `CAPEC-#`. |73| **CWE** | Common Weakness Enumeration identifiers associated with the weakness in the format `CWE-#`. Prioritize Variant and Base abstractions. |74| **OWASP** | OWASP Top Ten identifiers associated with the weakness in the format `X##:YYYY - Name`. |75| **Confidence** | Confidence rating indicating the strength of the text evidence supporting the security requirement. Use one of the following: `Highest`, `High`, `Medium`, `Low`. |76| **Gaps** | Gaps in the specification that affect the interpretation or satisfaction of the security requirement. Each gap is a single, explicit, and concise observation. |77| **References** | URLs evidencing the security requirement, including versioned paths and section anchors where available. |7879#### Evidence8081- Provide verbatim text excerpts evidencing the security requirement.82- Remove excess indentation.83- Use fenced code blocks with the `text` language identifier.84- Insert text `URL: https://...` at the top of each fenced code block.85- Insert text `[...]` in place of omitted irrelevant text.8687### Requirement Summary8889- Use verbatim values from the `Output > Requirement Details` section.9091| ID | Normativity | Requirement Level | Confidence | Name |92| --- | --- | --- | --- | --- |93| --- | --- | --- | --- | --- |
ivan-sincek