Non-Functional Security Requirements

Why This Topic Matters
Non-functional security requirements (NFRs) are one of the most heavily tested ideas in CSSLP Domain 2 because they define how well software must protect itself rather than what it does. Functional requirements describe features ("the user can log in"); non-functional security requirements describe quality attributes and constraints ("authentication must resist brute force with lockout after five failed attempts and must complete within 2 seconds"). Most costly breaches trace back not to missing features but to unstated or poorly specified quality attributes such as availability, confidentiality under load, auditability, or recoverability. If these are not captured early, they cannot be designed in, tested for, or verified later. The CSSLP emphasizes that security must be built in from requirements, and NFRs are the primary vehicle for doing so.

What Non-Functional Security Requirements Are
Non-functional requirements (sometimes called quality attributes, "-ilities," or constraints) specify the operational characteristics, properties, and boundaries the software must satisfy. Security-focused NFRs typically derive from the CIA triad plus AAA and related assurance goals:
• Confidentiality – data at rest, in transit, and in use must be protected (encryption strength, key management, data masking).
• Integrity – data and code must not be altered without authorization (hashing, digital signatures, input validation standards).
• Availability – uptime targets, Maximum Tolerable Downtime (MTD), Recovery Time Objective (RTO), Recovery Point Objective (RPO), resistance to denial of service.
• Authentication – strength of credential verification, multi-factor mandates, password policy, session management.
• Authorization – least privilege, separation of duties, role- or attribute-based access control models.
• Accountability / Auditing – logging content, log protection, retention periods, non-repudiation.
• Privacy – data minimization, consent, retention and disposal, regulatory mandates (GDPR, HIPAA, PCI DSS).
• Reliability and Resiliency – graceful degradation, fail-secure behavior, error handling that does not leak information.
• Performance and Scalability – security controls (e.g., encryption) must not degrade throughput below acceptable thresholds.
• Maintainability and Supportability – patchability, secure configuration management, ability to update cryptographic libraries.
• Portability and Interoperability – secure operation across platforms and with trusted third-party systems.
• Deployment and Operational constraints – environment hardening, secure defaults, compliance with organizational standards.

How Non-Functional Security Requirements Work in the SDLC
1. Sources. NFRs are derived from internal policies and standards, external regulations and laws, contractual obligations (SLAs), industry standards (ISO/IEC 27001, NIST SP 800-53, OWASP ASVS), threat modeling results, and business risk appetite. The CSSLP stresses that compliance requirements (legal, regulatory, privacy) are a primary source of NFRs.

2. Elicitation. Security practitioners work with business analysts and stakeholders using interviews, policy decomposition, data classification, and use/misuse case analysis. Misuse cases and abuse cases are especially valuable because they expose the quality attributes needed to resist attackers.

3. Specification. Good NFRs are SMART: Specific, Measurable, Attainable, Realistic, and Time-bound (or Testable). "The system shall be secure" is a poor requirement. "The system shall encrypt all cardholder data at rest using AES-256 with keys rotated at least annually" is a good one. Each NFR should be unambiguous, verifiable, and traceable to a source.

4. Traceability. A Requirements Traceability Matrix (RTM) maps each security requirement to its origin (policy, regulation, threat), to design elements, to code, and to test cases. This proves coverage and supports audits.

5. Prioritization. Because NFRs often conflict (strong encryption versus performance; strict logging versus privacy; availability versus confidentiality), they must be prioritized using risk analysis and business impact, with trade-offs documented and accepted by the business owner.

6. Verification. NFRs are validated through non-functional testing: performance and load testing, penetration testing, fuzzing, availability/failover testing, log review, and compliance audits. If a requirement cannot be tested, it was not properly written.

Key Distinctions the Exam Expects You to Know
• Functional vs. Non-Functional: Functional = behavior/feature ("shall authenticate users"). Non-functional = quality/constraint ("authentication shall use MFA and lock out after five failures"). Many security requirements can be expressed either way; the exam usually classifies strength, performance, compliance, and quality attributes as non-functional.
• Requirements vs. Design: NFRs state the goal and measurable threshold, not the implementation. "Use bcrypt" is design; "passwords shall be stored using a salted adaptive one-way hash resistant to offline attack" is a requirement.
• Availability metrics: MTD is the business tolerance; RTO must be less than or equal to MTD; RPO defines acceptable data loss.
• Fail-secure vs. fail-safe: Software typically should fail secure (deny access on error); physical safety systems may fail open/safe. Error handling must not disclose sensitive internals.
• Secure by default / secure by design / secure in deployment: NFRs often specify secure default configurations.
• Data classification drives NFRs: The sensitivity level of data determines required confidentiality, retention, and handling controls.

Common Pitfalls
• Writing vague, untestable requirements.
• Treating security as an afterthought to be "added" rather than specified up front.
• Ignoring conflicts between NFRs and failing to document accepted trade-offs.
• Confusing policy statements with requirements—policies must be decomposed into measurable requirements.
• Omitting privacy and regulatory obligations, which are mandatory and non-negotiable.
• Failing to maintain traceability, so coverage cannot be proven to auditors.

Exam Tips: Answering Questions on Non-Functional Security Requirements
1. Identify the category first. When a scenario describes uptime, response time, encryption strength, audit retention, or regulatory compliance, you are looking at a non-functional requirement. If it describes a user-visible feature or action, it is functional.
2. Choose the measurable answer. If options include a vague statement ("the system must be highly secure") and a quantified one ("the system shall maintain 99.9% availability"), the CSSLP always favors the specific, testable requirement.
3. Think "earliest phase" and "build security in." The exam rewards answers that capture security needs during requirements gathering rather than fixing them in testing or production.
4. Look for the source. When asked where a requirement comes from, favor policies, regulations, standards, contracts, data classification, and threat modeling over developer preference.
5. Remember traceability. Questions about proving that all security requirements were implemented and tested point to the Requirements Traceability Matrix.
6. Know your availability acronyms. Be able to distinguish MTD, RTO, RPO, SLA, and understand that RTO cannot exceed MTD.
7. Trade-off questions: When two NFRs conflict, the correct approach is risk-based prioritization with documented business acceptance—not simply picking the strongest control.
8. Requirement, not design. If an option names a specific technology or algorithm and another states the measurable goal, the requirement-level answer is usually the goal.
9. Compliance is mandatory. Legal, regulatory, and privacy requirements are never optional and typically take precedence in prioritization questions.
10. Eliminate distractors that place security requirements solely on the security team; the CSSLP expects collaboration between business owners, analysts, architects, developers, and security professionals.
11. Watch wording cues: "shall," "must," and numeric thresholds indicate properly written requirements; "should," "user-friendly," and "robust" without metrics indicate poorly written ones.
12. Fail securely: When asked how software should behave on error, default to denying access and not exposing internal details.

Summary
Non-functional security requirements translate security goals, policies, and regulations into measurable quality attributes—confidentiality, integrity, availability, authentication, authorization, auditing, privacy, reliability, performance, and maintainability. They must be derived from authoritative sources, written to be SMART and testable, prioritized by risk, traced through the SDLC, and verified through non-functional testing. On the CSSLP exam, favor the specific, measurable, early-phase, risk-based, and traceable answer, and clearly separate quality attributes (non-functional) from features (functional) and from implementation details (design).