Modeling Non-Functional Security Properties

1. Why This Topic Matters

Most software defects that become security breaches are not failures of a feature that was supposed to exist; they are failures of a quality that was assumed to exist. A login page works (functional), but it accepts unlimited password attempts (non-functional: resistance to brute force). A report exports data correctly (functional), but it takes forty seconds under load and becomes a denial-of-service vector (non-functional: performance and availability). The CSSLP exam places heavy emphasis on this topic because non-functional security properties are where architecture either succeeds or fails, and because they are notoriously difficult to retrofit. You cannot bolt on availability, resilience, or least privilege after the system is built without expensive redesign.

Within Domain 3 (Secure Software Architecture and Design), ISC2 expects candidates to understand that security is a quality attribute of the whole system, not a module. Modeling these properties means making them explicit, measurable, and testable so they can be designed in, verified, and traced through the entire SDLC. Expect exam questions that test whether you can distinguish functional from non-functional requirements, choose an appropriate modeling technique, quantify a property, and reason about trade-offs between competing qualities.

2. What Are Non-Functional Security Properties?

Functional requirements describe what the system does: process a payment, generate a report, authenticate a user. Non-functional requirements (NFRs), also called quality attributes, quality of service requirements, or the -ilities, describe how well the system does it and under what constraints. They are properties of the system as a whole rather than of a single feature.

The security-relevant non-functional properties that CSSLP candidates must know include:

• Confidentiality – information is disclosed only to authorized parties (e.g., data at rest encrypted with AES-256; no sensitive data in logs).
• Integrity – data and code are not altered without authorization and alterations are detectable (e.g., hashing, digital signatures, input validation coverage).
• Availability – the system is accessible when required (e.g., 99.99% uptime, recovery time objective of 15 minutes, graceful degradation under load).
• Authentication and Authorization strength – assurance that identities are genuine and access decisions are correctly enforced (e.g., MFA for privileged roles, complete mediation of every request).
• Accountability / Auditability – actions can be traced to a responsible entity (e.g., tamper-evident logs retained for 12 months).
• Non-repudiation – a party cannot credibly deny an action (e.g., signed transactions with trusted timestamps).
• Reliability – the system performs its intended function without failure over time (mean time between failures).
• Resilience and Recoverability – the system withstands and recovers from attacks or faults (fail secure, circuit breakers, backups tested quarterly).
• Performance and Scalability – security controls must not degrade throughput beyond acceptable limits, and the system must handle load spikes without becoming a DoS victim.
• Maintainability and Supportability – the ability to patch, update cryptographic algorithms (crypto agility), and change configurations securely.
• Usability – security that users can and will use correctly; poorly usable security is bypassed.
• Interoperability and Portability – secure operation across platforms and with other systems, including compatibility of protocols and trust relationships.
• Privacy – data minimization, purpose limitation, retention limits, and consent, often driven by regulations such as GDPR or HIPAA.

A useful mental test: if a requirement can be verified by exercising a single use case and checking the output, it is probably functional. If it must be verified by measuring the system under conditions (load, attack, failure, time), it is probably non-functional.

3. What Does It Mean to Model These Properties?

Modeling means converting vague aspirations (the system should be secure) into explicit, measurable, traceable, and testable statements that drive architectural decisions. A well-modeled non-functional security property has several characteristics:

• Specific and unambiguous – states exactly which asset, component, or interface it applies to.
• Measurable (quantified) – includes a metric and threshold: account lockout after 5 failed attempts within 10 minutes, not prevent brute force.
• Testable / verifiable – a test, review, or measurement can show it is met.
• Traceable – linked to a business driver, regulation, threat, or risk, and forward to design elements and test cases.
• Prioritized – trade-offs are explicit so architects know which attribute wins when they conflict.

4. How It Works: Techniques for Modeling Non-Functional Security Properties

4.1 Quality Attribute Scenarios (SEI / ATAM style)
The Software Engineering Institute defines a six-part scenario template that is the most widely cited way to model a quality attribute precisely:
• Source – who or what generates the stimulus (external attacker, insider, malfunctioning service).
• Stimulus – the event (attempts SQL injection, floods the API with 10,000 requests per second, a disk fails).
• Artifact – what is stimulated (web tier, database, authentication service).
• Environment – conditions at the time (normal operation, peak load, degraded mode).
• Response – what the system does (rejects and logs the input, rate-limits the source, fails over).
• Response Measure – how success is measured (100% of malicious inputs blocked, latency stays under 300 ms, failover within 30 seconds).
Example: An unauthenticated external user (source) submits 1,000 login requests in one minute (stimulus) against the authentication service (artifact) during peak hours (environment); the system throttles the source IP and generates an alert (response) with no more than 2% increase in latency for legitimate users (response measure). This scenario is a modeled availability and authentication-strength property.

4.2 Misuse Cases and Abuse Cases
Standard use cases model what legitimate actors do. Misuse cases model what hostile actors attempt, drawn as inverted (black) actors and ovals that threaten normal use cases and are mitigated by security use cases. They surface non-functional needs such as resistance to tampering or replay. Abuse cases are similar but often emphasize legitimate users using the system in unintended ways.

4.3 Threat Modeling (STRIDE, DFDs, Attack Trees)
Data flow diagrams with trust boundaries show where data crosses privilege or network boundaries. Applying STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to each element maps directly to the security properties it violates: Spoofing threatens authentication, Tampering threatens integrity, Repudiation threatens non-repudiation, Information Disclosure threatens confidentiality, DoS threatens availability, and EoP threatens authorization. Attack trees decompose an attacker goal into sub-goals with AND/OR branches, optionally annotated with cost, likelihood, or required skill, which helps quantify where to invest in controls.

4.4 Security-Extended UML and Formal Notations
• UMLsec – UML stereotypes and tags (such as secrecy, integrity, secure links, fair exchange) annotate class, deployment, and sequence diagrams so security constraints can be checked semi-automatically.
• SecureUML – models role-based access control (roles, permissions, constraints) directly in design diagrams.
• State machine / state transition diagrams – model session lifecycles, authentication states, and ensure no path reaches a privileged state without passing through authentication.
• Sequence diagrams – show protocol exchanges and where authentication tokens, nonces, or signatures must appear to achieve non-repudiation or replay resistance.
• Formal methods (Z, B, Alloy, TLA+, model checking) – mathematically specify and prove properties such as information flow (Bell-LaPadula for confidentiality, Biba or Clark-Wilson for integrity). Used in high-assurance systems where the cost of failure justifies the rigor.

4.5 Architecture Views and Tactics
Document the architecture in multiple views (logical, process, deployment, data) and annotate each with the security tactics that achieve the modeled property: detect attacks (intrusion detection, anomaly detection), resist attacks (authenticate, authorize, encrypt, limit exposure, separate entities, validate input), react to attacks (revoke access, lock accounts, inform actors), and recover from attacks (restore, maintain audit trail). Each tactic should trace back to a quality attribute scenario.

4.6 Service Level Agreements and Metrics
Many non-functional properties are formalized contractually: availability percentages, RTO and RPO, maximum patch windows, encryption standards, log retention periods, and incident notification times. Modeling includes expressing these as measurable service level objectives and designing monitoring to prove compliance.

4.7 Secure Design Principles as Constraints
Saltzer and Schroeder principles become non-functional design constraints: least privilege, complete mediation, fail-safe defaults (fail secure), economy of mechanism, open design, separation of duties / privilege, least common mechanism, psychological acceptability, defense in depth, and leveraging existing components. The exam frequently asks which principle a described control implements.

5. Managing Trade-Offs

Non-functional properties routinely conflict, and the architect must model and justify the balance:
• Security vs. Performance – TLS everywhere, strong hashing (bcrypt, Argon2) and encryption add latency; model the acceptable overhead and size infrastructure accordingly.
• Security vs. Usability – MFA and complex password policies reduce convenience; psychological acceptability says overly burdensome security will be circumvented.
• Availability vs. Confidentiality – replicating data for redundancy increases exposure surface; fail-open versus fail-closed decisions pit availability against confidentiality or integrity.
• Maintainability vs. Economy of Mechanism – flexible plug-in architectures increase attack surface.
• Cost vs. Everything – formal methods and high availability clusters are expensive; risk analysis determines whether the asset value justifies them.
Tools such as ATAM (Architecture Trade-off Analysis Method) make these trade-offs explicit by identifying sensitivity points and trade-off points in the architecture. On the exam, the correct answer usually reflects a risk-based, business-aligned balance rather than maximum security at any cost.

6. Traceability and Verification

Modeled properties must flow into the rest of the SDLC: a requirements traceability matrix links each NFR to design elements, to code modules, and to verification activities such as penetration tests, load tests, fuzzing, failover drills, and code reviews. Verification of non-functional properties typically requires non-functional testing: performance and stress testing, resilience and chaos testing, recovery testing, security scanning, and configuration audits. If a property cannot be verified, it was not adequately modeled.

7. Exam Tips: Answering Questions on Modeling Non-Functional Security Properties

Tip 1 – Classify first. When a question describes a requirement, decide whether it is functional (what the system does) or non-functional (how well, under what conditions). Words like performance, uptime, resilience, scalability, response time, encryption strength, lockout threshold, retention period signal non-functional. Many distractors describe features when the question asks for a quality attribute, or vice versa.

Tip 2 – Prefer measurable, testable wording. If answer choices differ in specificity, the best-written requirement includes a metric and threshold (99.95% availability measured monthly; sessions expire after 15 minutes of inactivity). Vague phrasing such as the system must be highly secure is almost always a wrong answer.

Tip 3 – Map STRIDE to properties automatically. Spoofing → authentication; Tampering → integrity; Repudiation → non-repudiation / accountability; Information Disclosure → confidentiality; Denial of Service → availability; Elevation of Privilege → authorization. Questions often describe a threat and ask which property is at risk, or describe a property and ask which threat category applies.

Tip 4 – Know the six parts of a quality attribute scenario. Source, stimulus, artifact, environment, response, response measure. If a question asks what is missing from a stated scenario, the response measure is the most commonly omitted element.

Tip 5 – Recognize the right technique for the right purpose. Misuse/abuse cases → eliciting security requirements from an attacker perspective; attack trees → decomposing attacker goals and prioritizing mitigations; DFDs with trust boundaries → finding where controls are needed; UMLsec/SecureUML → embedding security constraints in design models; formal methods → proving properties in high-assurance systems; ATAM → evaluating trade-offs between competing quality attributes.

Tip 6 – When in doubt, choose the risk-based, business-aligned answer. CSSLP consistently favors answers that balance security with cost, performance, and usability based on risk, rather than the most restrictive control. However, when the scenario is explicitly high-assurance (safety-critical, national security), stronger measures such as formal verification become correct.

Tip 7 – Fail secure is the default, with one caveat. For confidentiality and integrity, systems should fail closed. Be alert to scenarios involving life safety (fire doors, medical devices) where failing open or failing safe may be the correct answer because availability or human safety outweighs confidentiality.

Tip 8 – Watch for lifecycle timing. Questions about when to model non-functional security properties are answered by requirements and design phases, as early as possible. Answers that defer security qualities to testing or deployment are distractors; retrofitting is the costly mistake the exam wants you to avoid.

Tip 9 – Connect principles to controls. Be ready to identify least privilege, complete mediation, separation of duties, defense in depth, economy of mechanism, open design, and psychological acceptability from a one-sentence description of a control.

Tip 10 – Remember traceability and verification. If asked how to ensure a non-functional property is actually achieved, the answer involves a traceability matrix plus non-functional testing (load, stress, failover, penetration, fuzzing), not merely documenting the requirement.

Tip 11 – Read for the superlative. Questions asking for the best, most, first, or primary answer often have several technically true options. Choose the one that most directly addresses the stated property and reflects the architect's role: making the property explicit, measurable, and designed in.

8. Quick Reference Summary

• Non-functional security properties = the -ilities: confidentiality, integrity, availability, authentication, authorization, accountability, non-repudiation, reliability, resilience, performance, scalability, maintainability, usability, interoperability, privacy.
• Modeling = making them specific, quantified, testable, traceable, and prioritized.
• Key techniques: quality attribute scenarios, misuse/abuse cases, threat modeling with STRIDE and DFDs, attack trees, UMLsec/SecureUML, state machines, formal methods, architecture views with security tactics, SLAs and metrics.
• Always analyze trade-offs (ATAM) and choose a risk-based balance.
• Model early (requirements and design), trace throughout, verify with non-functional testing.

Master these ideas and you will be able to handle both the definitional questions and the scenario-based questions the CSSLP exam uses to test this concept.