Before implementation
Requirements shape architecture, data flows, trust boundaries, identities, dependencies, logging, and failure behavior.
High School AdvancedA11.2Secure Software Architecture
Lesson A11.2
Secure Design Requirements
“Make it secure†is not a requirement. A strong security requirement tells the team what behavior is expected, where it applies, who owns it, what evidence should support it, what result counts as acceptable, and what future changes should cause it to be reviewed again.
This lesson turns broad security goals into traceable design requirements that can guide architecture, implementation, code review, safe validation, release decisions, and maintenance.
Lesson Progress
Secure Design Requirements
High School Advanced • A11: Secure Software Architecture • Lesson 2 of 10
20% complete
Readiness Check
A11.2 Entry Readiness
0/4 ready
Professional Hook
Why “Secure†Is Not a Testable Requirement
Imagine a fictional engineering team receives this statement: “The student portal must be secure.â€
The product owner may think it means only approved users can see records. The architect may think it means strong identity. A developer may think it means input validation. A monitoring analyst may think it means complete logging. A release owner may think it means no high-severity findings.
All of those concerns can matter, but the original sentence does not tell the team which behavior is required or how success will be demonstrated.
Good security requirements reduce ambiguity before ambiguity turns into inconsistent design.
Learning Objectives
Five Capabilities for This Lesson
1
Explain why vague statements such as “make it secure†are not strong enough to guide architecture, implementation, review, testing, or release.
2
Write security requirements with clear scope, expected behavior, ownership, evidence, acceptance criteria, and change triggers.
3
Distinguish business goals, security goals, security requirements, implementation choices, assumptions, and validation evidence.
4
Evaluate fictional requirements for identity, authorization, data handling, logging, resilience, configuration, dependencies, and deployment readiness.
5
Build a secure requirements register that becomes a traceable input to later A11 architecture, review, validation, and release work.
Why It Matters
Requirements Connect Every Later Security Decision
Architecture reviews need to know what behavior they are reviewing for. Code reviewers need to know which security assumptions matter. Testers need expected results. Release owners need blocking criteria. Operations teams need to know what behavior should remain observable after release.
A clear requirement becomes the common reference point across all of those activities.
During implementation
Requirements guide code review, configuration review, dependency choices, and validation plans.
After release
Requirements support monitoring expectations, change triggers, exception review, and maintenance decisions.
Core Framework
Goal → Requirement → Design → Evidence
One of the most important architecture skills is keeping different kinds of statements separate. A business goal is not a security requirement. A requirement is not an implementation choice. An implementation choice is not validation evidence.
1
Business goal
What outcome does the organization need?
Example: Counselors need timely access to assigned student-support records so they can provide approved services.
A business goal explains purpose, but it does not define security behavior.
2
Security goal
What security quality should protect that outcome?
Example: Only appropriately authorized users should access student-support records.
A security goal is useful direction, but it can still be too broad for implementation and validation.
3
Security requirement
What specific behavior must the system enforce?
Example: The application must permit counselors to view only records for students assigned to them through the approved assignment source, and denied access attempts must create an audit event.
This is specific enough to influence design, review, and test planning.
4
Design / implementation decision
How will the architecture meet the requirement?
Example: The application service uses the central authorization service to check counselor assignment before returning a record.
This is one way to satisfy the requirement, not the requirement itself.
5
Validation evidence
What evidence supports the claim that the requirement works?
Example: Authorized test evidence shows assigned counselors succeed, unassigned counselors receive the expected denial, and corresponding audit events are recorded.
Evidence supports a claim but does not replace the requirement.
Requirement Quality
Six Properties of a Strong Security Requirement
Specific
Weak
The system should have good access control.
Stronger
Only approved staff roles may perform account-recovery actions, and every successful or denied recovery attempt must create an audit event.
The stronger version identifies actors, action, expected enforcement, and evidence behavior.
Scoped
Weak
All data must always be encrypted.
Stronger
Student-support records must use approved protected transport between the browser, application, API, and storage services, and approved storage protection must be enabled for persistent records.
The stronger version identifies where the requirement applies.
Owned
Weak
Security will check this later.
Stronger
The application team owns implementation, the security reviewer owns requirement review, and the release owner confirms evidence before release.
Explicit ownership reduces abandoned requirements.
Testable
Weak
The login should be secure.
Stronger
The application must require the approved identity provider for staff access and must reject staff sessions that do not contain the required approved role claim.
The stronger statement can be tied to expected outcomes in an authorized test environment.
Evidence-linked
Weak
Logging is enabled.
Stronger
Privileged account changes must generate audit events containing actor, action, target reference, result, timestamp, and correlation identifier without recording secret values.
The requirement says what defenders should be able to verify.
Change-aware
Weak
This requirement is permanent and never needs review.
Stronger
Re-review this requirement when a new privileged role, new data category, new identity provider, or new external integration is introduced.
Changes can invalidate earlier assumptions.
Vocabulary
Requirements Language for A11
Business requirement
A statement describing what the organization, user, or product needs to accomplish.
Security goal
A broad protection objective such as confidentiality, integrity, availability, least privilege, privacy, or auditability.
Security requirement
A specific, reviewable statement describing required security behavior, scope, ownership, evidence, and success conditions.
Acceptance criterion
A condition that must be satisfied before a requirement can be considered complete or acceptable.
Assumption
A belief used by the design that has not necessarily been proven and may need evidence or future review.
Constraint
A limit that influences the design, such as required technology, policy, performance, budget, compatibility, or regulation.
Control
A safeguard, process, design feature, or operational measure used to reduce risk or enforce a requirement.
Traceability
The connection from requirement to architecture, implementation, review, validation, release, and later maintenance evidence.
Change trigger
A future event that requires the requirement or its supporting evidence to be reviewed again.
Requirement owner
The role accountable for keeping the requirement accurate, meaningful, and appropriately reviewed.
Evidence owner
The role or team responsible for producing or maintaining the evidence that supports the requirement.
Residual risk
Risk remaining after the requirement, controls, evidence, and exceptions are considered.
Requirement Domains
Eight Areas a Secure Software Design Should Consider
Not every application needs the same requirement set. The domains below are a review framework: they help teams ask whether important security behavior has been defined.
ID
Identity
Which users or services need identities?
Which identity provider or approved identity source is authoritative?
Which authentication expectations differ by user or action?
How are disabled, expired, or inactive identities handled?
Which account-recovery paths require additional approval or evidence?
Example requirement: Administrative staff access must use the approved workforce identity provider, and disabled staff accounts must not receive new application sessions.
AUTHZ
Authorization
Which roles, attributes, assignments, ownership rules, or workflow states control access?
Which actions are high impact?
Where should authorization be enforced?
What should happen when access is denied?
Which actions require stronger approval or separation of duties?
Example requirement: Counselors may view only assigned student records, and assignment must be checked by the application service before the record is returned.
DATA
Data handling
Which data is sensitive?
What is the minimum data needed for each purpose?
Where may the data flow?
How long should it be retained?
Who owns deletion, archival, export, or correction decisions?
Example requirement: The scheduling integration may receive appointment date, time, and fictional student reference code, but must not receive counseling notes.
LOG
Logging and auditability
Which actions must be visible to defenders?
Which fields are useful for investigation?
Which sensitive values must not be logged?
Who can access the logs?
How is source health monitored?
Example requirement: Every privileged account change must record actor, target reference, action, result, timestamp, and correlation identifier without recording passwords, tokens, or secret values.
RES
Resilience and recovery
Which services must remain available?
What failures need safe degraded behavior?
What must be recoverable?
Who owns rollback?
How is recovery validated?
Example requirement: If the notification provider is unavailable, the core record workflow must remain available and failed notifications must be queued for approved retry.
CFG
Configuration
Which settings are security-sensitive?
What is the approved baseline?
How are changes reviewed?
How is environment separation maintained?
How is drift detected?
Example requirement: Production authorization and logging settings must match the approved configuration baseline, and changes require a reviewed change record.
DEP
Dependencies
Which packages, services, suppliers, or build tools matter to the software?
Who owns them?
What support and provenance evidence is required?
How are updates reviewed?
What changes trigger revalidation?
Example requirement: Business-critical dependencies must have an owner, approved source, recorded version, support status, and defined review trigger.
REL
Release and deployment
What evidence must exist before release?
Which findings are blocking?
What exception process exists?
What rollback and monitoring evidence is required?
What post-release checks confirm expected behavior?
Example requirement: A production release may proceed only when blocking security requirements are Confirmed or covered by an approved, time-bounded exception with an accountable owner.
Fake Dashboard
Northbridge Security Requirements Dashboard
Fictional training data — requirement governance only
Security requirements
24
18 Confirmed, 4 Conditional, 2 Unknown
Requirements with owners
23 / 24
Dependency review ownership missing for one critical component
Traceability coverage
88%
Three requirements lack current validation evidence
Open change triggers
4
New integration, role change, dependency baseline update, logging schema change
Fake SOC Alert
Critical Dependency Requirement Has No Owner
Source: Fictional Requirements Review • Time: 10:32
REQ-DEP-01 requires every business-critical dependency to have an owner, approved source, version, support status, and review trigger. One critical dependency record has no owner.
Defensive recommendation: Keep the requirement incomplete, assign accountable dependency ownership, and collect the missing governance evidence before marking it Confirmed.
Requirements Register
What Traceable Requirements Look Like
A professional requirements register is more than a list of sentences. Each requirement should connect behavior, ownership, evidence, acceptance, status, and future review conditions.
REQ-ID-01IdentityConfirmed
Approved staff access must use the workforce identity provider, and disabled workforce accounts must not receive new application sessions.
Owner
Identity Owner + Application Owner
Evidence
Identity configuration summary, application design note, authorized test result, release checklist.
Acceptance
Approved active staff can establish expected sessions; disabled fictional staff identities cannot.
Change trigger
New identity provider, new staff role, recovery-flow change, or session architecture change.
REQ-AUTHZ-03AuthorizationConfirmed
Counselors may view only records for students assigned to them by the approved assignment source.
Owner
Product Owner + Application Owner
Evidence
Authorization design, peer-review evidence, assignment mapping, authorized positive and negative test results.
Acceptance
Assigned counselor succeeds; unassigned counselor receives expected denial; no record data is returned for the denied request.
Change trigger
New counselor role, assignment-source change, new record type, or new privileged workflow.
REQ-DATA-02DataConditional
The scheduling integration may receive appointment date, time, and fictional student reference code but must not receive counseling-note content.
Owner
Data Owner + Integration Owner
Evidence
Approved field list, data-flow diagram, integration contract, validation result.
Acceptance
Only the approved minimum fields appear in the supplied integration evidence.
Change trigger
New scheduling feature, new field request, new vendor, or changed business purpose.
REQ-LOG-04LoggingConfirmed
Privileged account changes must create audit events with actor, target reference, action, result, timestamp, and correlation identifier without recording secret values.
Owner
Application Owner + Security Monitoring Owner
Evidence
Logging design, supplied sample events, validation results, source-health status.
Acceptance
Required fields are present for approved test events and forbidden secret values are absent.
Change trigger
New privileged action, log schema change, telemetry platform change, or privacy requirement change.
REQ-RES-02ResilienceConditional
The core student-record workflow must remain available when the external notification provider is unavailable.
Owner
Service Owner + Reliability Owner
Evidence
Architecture design, safe failure-mode test, queue behavior summary, recovery evidence.
Acceptance
Core record workflow remains functional; notification failure is recorded and handled according to the approved retry design.
Change trigger
Notification provider change, queue change, major workflow redesign, or recovery architecture change.
REQ-DEP-01DependencyUnknown
Every business-critical software dependency must have a recorded owner, approved source, version, support status, and review trigger.
Owner
Engineering Lead + Dependency Owner
Evidence
Dependency inventory, approval record, support note, update policy.
Acceptance
No business-critical dependency remains without ownership or source metadata.
Change trigger
New dependency, major version change, support-status change, supplier change, or build-system change.
REQ-REL-01ReleaseConfirmed
Production release requires all blocking security requirements to be Confirmed or governed by an approved, time-bounded exception.
Owner
Release Owner + Risk Owner
Evidence
Requirements matrix, exception register, approval record, rollback plan, monitoring readiness.
Acceptance
No blocking requirement is Unknown without formal disposition.
Change trigger
Release-process change, new blocking requirement category, exception-policy change, or major deployment-model change.
Fake Log Panel
Fictional Requirements Review Log
training-log-viewer.log
[08:55] REQ-ID-01 owner=Identity+Application status=CONFIRMED [09:12] REQ-AUTHZ-03 assigned-counselor rule linked to design decision ADR-17 [09:40] REQ-DATA-02 approved field list pending Data Owner signature [10:05] REQ-LOG-04 sample audit events confirm required fields; no secret values observed [10:32] REQ-DEP-01 dependency owner missing -> status UNKNOWN [11:10] REQ-RES-02 failure-mode evidence partial -> status CONDITIONAL [11:44] REQ-REL-01 release rule approved by Release Owner + Risk Owner
Training note: this is fake data for defensive analysis practice only.
Requirement Review
Twelve Questions Before You Approve a Requirement
1
Who or what does the requirement apply to?
2
What specific security behavior is expected?
3
Where in the architecture should the behavior be enforced?
4
Who owns the requirement?
5
Who owns the implementation evidence?
6
What evidence can support the requirement?
7
What result counts as acceptable?
8
What result would block release or require an exception?
9
What assumptions or dependencies affect the requirement?
10
What future changes should reopen the requirement?
11
What sensitive information must not appear in validation or logging evidence?
12
How will the requirement remain traceable through review, release, operation, and maintenance?
Analyze the Evidence
Evidence Analysis: Authorization Requirement
REQ-AUTHZ-03 says counselors may view only assigned student records.
The design note says assignment is checked through the approved assignment source.
Peer review confirms the application calls the central authorization service.
Positive and negative authorized test evidence is attached.
No evidence is supplied for a new temporary counselor role planned next month.
Which conclusion is best supported by the fictional requirement package?
Requirement Anti-Patterns
Seven Ways Requirements Become Weak
1
Vague adjective
Weak example: The application must be very secure.
Why it fails: Words like secure, strong, safe, robust, and hardened do not identify required behavior.
Repair: Describe the actors, action, data, boundary, expected enforcement, evidence, and success condition.
2
Implementation disguised as requirement
Weak example: The application must use Tool X for authorization.
Why it fails: A product may become dependent on one implementation before the actual security need is understood.
Repair: State the security behavior first; record the approved implementation separately.
3
Unbounded universal
Weak example: Everything must be logged forever.
Why it fails: The statement ignores privacy, cost, retention, relevance, source health, and sensitive values.
Repair: Define which events matter, which fields are needed, which values are forbidden, retention, access, and owner.
4
No evidence
Weak example: Admins are protected by strong controls.
Why it fails: The team cannot tell how to prove or review the statement.
Repair: Add expected evidence and acceptance criteria.
5
No owner
Weak example: Someone must review critical dependencies.
Why it fails: The requirement can remain open indefinitely.
Repair: Assign a dependency owner, evidence owner, and escalation path.
6
No change trigger
Weak example: Requirement approved once and never reviewed again.
Why it fails: New roles, data, dependencies, integrations, or deployment patterns can invalidate old assumptions.
Repair: Define the changes that reopen the requirement.
7
Impossible perfection
Weak example: The service must never fail or experience any security problem.
Why it fails: The requirement cannot be realistically validated and may hide the need for resilience and recovery.
Repair: Define availability, recovery, safe failure behavior, monitoring, and acceptable residual risk.
Design Traceability
Follow One Requirement Across the Lifecycle
Use REQ-AUTHZ-03 as a traceability example. The requirement does not end when it is approved. It should remain connected to later evidence.
| Lifecycle stage | Traceability evidence | Question answered |
|---|---|---|
| Plan | Counselors need access to assigned student-support records. | Why does the feature exist? |
| Requirement | REQ-AUTHZ-03 defines assignment-based access. | What behavior is required? |
| Design | Central authorization service checks the approved assignment source. | Where should enforcement happen? |
| Implementation review | Peer review confirms the protected path uses the approved authorization interface. | Does implementation follow the design? |
| Validation | Assigned counselor succeeds; unassigned counselor receives denial; denied request returns no record data. | Does the requirement behave as expected? |
| Release | Requirement status is Confirmed and linked to current evidence. | Is the evidence sufficient for release? |
| Maintenance | New counselor role is introduced. | Which change trigger requires renewed review? |
Safe Fictional Lab
Rewrite Weak Requirements
Use the fictional Northbridge portal. Your job is to rewrite vague statements into requirements that are specific, scoped, owned, evidence-linked, testable, and change-aware.
Weak requirement 1
“Use strong authentication.â€
Which users or actions need stronger authentication?
Which approved identity source is authoritative?
What evidence would show the requirement is met?
What change would reopen the requirement?
Weak requirement 2
“Protect student data.â€
Which data categories are in scope?
Who may access them?
Where may they flow?
What retention or deletion behavior is expected?
Weak requirement 3
“Log suspicious actions.â€
Which actions matter?
Which fields are required?
Which sensitive values must not be logged?
Who owns source health and review?
Weak requirement 4
“Keep the portal available.â€
Which workflow must remain available?
Which dependency failures should degrade safely?
What recovery behavior is expected?
How will the team validate it?
Lab boundary
Do not inspect or test any real application. Use only fictional requirements, invented architecture context, and supplied evidence.
Scenario Decision Lab
Scenario Decision Lab 1 — The Vague Authorization Goal
A fictional product owner writes: “Make access secure for counselors.†Engineering wants to begin implementation immediately, but no one has defined which records counselors may access or what evidence should prove the rule.
Scenario Decision Lab
Scenario Decision Lab 2 — The New Vendor Field
The scheduling integration was approved to receive three minimum fields. A later feature request asks the vendor to receive a fourth sensitive field that was not included in the original purpose or requirement.
Analyze the Evidence
Evidence Analysis: Dependency Requirement
REQ-DEP-01 requires every business-critical dependency to have an owner, approved source, version, support status, and review trigger.
The dependency inventory lists the package name, source, version, and support status.
The owner field is blank.
No exception record explains the missing ownership.
What is the strongest conclusion about REQ-DEP-01?
Advanced Challenge
Create a Requirement That Survives Design Review
Write one fictional requirement for a high-impact account-recovery workflow. Your requirement should be strong enough that an architect, developer, reviewer, tester, release owner, and operations team can all use it.
1
Business purpose
2
Actors and roles
3
Protected action
4
Authorization expectation
5
Required evidence
6
Audit expectation
7
Forbidden sensitive logging
8
Acceptance criteria
9
Requirement owner
10
Evidence owner
11
Blocking condition
12
Change triggers
A strong answer does not need to be long. It needs to be unambiguous, traceable, evidence-based, and reviewable.
Defender Habits
A11.2 Defender Checklist
Skill Check
Seven Questions
Check Your Understanding
A11.2 Mini Quiz: Secure Design Requirements
Choose your answers first. Explanations appear only after submission.
1. Which statement is the strongest security requirement?
2. What is the difference between a security requirement and an implementation decision?
3. Why should a requirement include acceptance criteria?
4. A business-critical dependency has no owner. What is the strongest status?
5. Which is the best reason to define change triggers?
6. What is the strongest logging requirement?
7. A requirement says a new vendor may receive three approved fields. The vendor now requests a fourth sensitive field for a new feature. What should happen?
Portfolio Prompt
Portfolio Build — Secure Requirements Register
Create the second artifact for your A11 Secure Software Design Assessment: a fictional secure requirements register with at least eight requirements spanning identity, authorization, data handling, logging, resilience, configuration, dependencies, and release. For each requirement include ID, scope, owner, evidence, acceptance criteria, status, assumptions or dependencies, and change trigger.
Use fictional systems, roles, data, dependencies, and evidence only.
Keep the requirement separate from the implementation choice.
Use bounded language such as Confirmed, Conditional, Unknown, or Blocked.
Make at least one requirement Unknown because evidence or ownership is missing.
Include at least one requirement that becomes stale when a new integration or role is introduced.
Add a short traceability note showing how one requirement connects to design, review, validation, and release.
Confidence / Readiness Reflection
Are You Ready for A11.3?
A11.3 will use these requirements as inputs to software threat modeling. Before moving on, make sure you can explain the difference between a goal, a requirement, a design choice, and evidence.
1
I can rewrite a vague security goal into specific expected behavior.
2
I can identify requirement scope, owner, evidence, acceptance criteria, and change triggers.
3
I can keep implementation technology separate from the underlying security requirement.
4
I can mark a requirement Unknown when required evidence or ownership is missing.
5
I can explain how requirements guide threat modeling, code review, safe validation, release, and maintenance.
Portfolio Build Guide
How to Make the Requirements Register Look Professional
Use stable IDs
Give each requirement an identifier such as REQ-AUTHZ-03 so architecture, review, testing, release, and maintenance evidence can refer to it consistently.
Keep one requirement focused
Avoid combining five unrelated expectations into one giant sentence. Separate identity, authorization, logging, data, and resilience when their evidence differs.
Make status visible
Use states such as Confirmed, Conditional, Unknown, Blocked, or Not Applicable and explain what evidence supports the status.
Show ownership
Name the accountable role for the requirement and the role responsible for producing evidence.
Show acceptance evidence
State what result would demonstrate the requirement in an authorized test or review context.
Document assumptions
If the requirement depends on an identity provider, assignment source, vendor, data classification, or architecture boundary, make that dependency visible.
Add change triggers
Record the future changes that should reopen the requirement.
Add one traceability example
Show how a requirement maps to design, implementation review, validation evidence, release status, and maintenance trigger.
Key Takeaways
What You Should Remember
1.A security goal is direction; a security requirement is a specific, reviewable behavior.
2.Strong requirements define scope, ownership, evidence, acceptance criteria, and change triggers.
3.Implementation choices should satisfy requirements rather than replace them.
4.Traceability connects the requirement to architecture, implementation, review, validation, release, and maintenance.
5.Unknown is the correct status when required evidence or ownership is missing.
6.Security requirements should cover identity, authorization, data, logging, resilience, configuration, dependencies, and release—not only authentication.
7.Change triggers keep requirements useful as software evolves.
8.The A11 requirements register becomes a core input to threat modeling, code review, testing, and deployment decisions.
Lesson Safety Boundary
Requirements work is defensive design
This lesson does not authorize testing, scanning, probing, exploitation, credential attacks, bypass attempts, fuzzing, or access to real applications, APIs, accounts, repositories, devices, or networks. Use fictional or explicitly authorized evidence only.
Lesson Complete
A11.2 Secure Design Requirements Complete
You now have a requirements framework that can guide the rest of A11. Next, A11.3 uses those requirements, architecture context, data flows, trust boundaries, dependencies, and assumptions to build a safe Software Threat Model.