Security Test Strategy, Plan and Standards

Why This Topic Matters
Security testing without a strategy is just random poking at an application. The CSSLP exam treats the security test strategy, the security test plan, and the standards that guide them as the foundation of Domain 6 (Secure Software Testing). The reason is simple: testing is the point in the SDLC where you verify that the security requirements, threat-model mitigations, and secure design decisions made earlier actually ended up in the running software. If the strategy is weak, high-risk components may never be tested, test results cannot be trusted, and the organization cannot demonstrate due diligence to auditors, regulators, or customers. Expect roughly 14% of the CSSLP exam to come from Domain 6, and a meaningful share of those questions probe whether you understand how to plan security testing rather than simply which tool to run.

What It Is: Three Distinct but Related Artifacts

1. Security Test Strategy
The strategy is the high-level, organization- or program-level document that defines the overall approach to security testing. It answers questions such as: What is our risk appetite? Which types of testing (static, dynamic, manual, automated, penetration) will we use and when? What is the balance between internal testing and third-party testing? How do we prioritize what gets tested? A good strategy is risk-based, meaning that components with the highest threat exposure, highest data sensitivity, or largest attack surface receive the most rigorous testing. The strategy is usually stable across many projects and changes only when the organization's risk posture, technology stack, or regulatory obligations change.

2. Security Test Plan
The plan is the project-level, detailed document that operationalizes the strategy for a specific release or product. It typically contains:
- Scope: which modules, interfaces, APIs, and environments are in and out of scope.
- Objectives: the specific security requirements and threat-model mitigations to be verified.
- Test approach: the techniques to be applied (SAST, DAST, IAST, fuzzing, manual code review, penetration testing, misuse/abuse case testing, regression testing).
- Test cases and traceability: a Requirements Traceability Matrix (RTM) linking every security requirement and identified threat to one or more test cases.
- Entry and exit criteria: conditions that must be met before testing begins (e.g., code freeze, build passes unit tests) and before testing is declared complete (e.g., no open critical or high findings, coverage targets achieved).
- Test environment and test data: isolated environments that mirror production, sanitized or synthetic test data, and rules preventing real customer data from leaking into test systems.
- Roles and responsibilities: who executes tests, who triages defects, who approves exceptions, and who signs off.
- Schedule and resources: timelines, tooling, licenses, and budget.
- Defect management: how findings are logged, rated (commonly using CVSS), prioritized, retested, and closed.
- Risks and contingencies: what happens if testing uncovers a showstopper late in the cycle.

3. Security Testing Standards
Standards are external or internal benchmarks that define how testing should be performed and what constitutes acceptable evidence. The CSSLP expects familiarity with:
- ISO/IEC/IEEE 29119: the international software testing standard covering test processes, documentation, and techniques (it superseded IEEE 829 for test documentation).
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment; defines planning, execution, and post-execution phases for security assessments including penetration testing.
- OWASP ASVS (Application Security Verification Standard): a checklist of verification requirements at three levels of assurance, widely used to define test coverage for web applications.
- OWASP Web Security Testing Guide (WSTG) and Mobile Application Security Testing Guide (MASTG): detailed test procedures.
- ISO/IEC 25010: software quality model that lists security as a quality characteristic (confidentiality, integrity, non-repudiation, accountability, authenticity).
- Common Criteria (ISO/IEC 15408): evaluation assurance levels (EALs) for security products, where testing depth increases with the EAL.
- PCI DSS, HIPAA, SOC 2, FedRAMP: regulatory or contractual drivers that mandate specific testing (e.g., PCI DSS requires annual penetration testing and testing after significant changes).
- ISTQB glossary and processes, often referenced for general testing vocabulary (test oracle, test basis, test condition).

How It Works: From Strategy to Executed Tests

Step 1 – Derive the test basis. Security test cases are not invented from scratch. They are derived from security requirements, the threat model, abuse and misuse cases, attack surface analysis, architecture risk analysis, and applicable compliance obligations. If a threat model identified SQL injection in the search feature, there must be a test case that attempts it.

Step 2 – Prioritize by risk. Not everything can be tested to the same depth. The strategy directs testers to classify assets and features by likelihood and impact, so that authentication, authorization, cryptography, session management, input handling, and privileged operations receive the deepest coverage.

Step 3 – Select test types. The plan maps each requirement to appropriate techniques:
- Functional security testing verifies that security controls work as specified (e.g., account lockout after five failed attempts).
- Non-functional / negative testing verifies that the software does not do what it should not (e.g., rejecting malformed input, failing securely).
- White-box (SAST, code review) uses internal knowledge; black-box (DAST, external pen test) simulates an outside attacker; gray-box blends both.
- Fuzzing feeds random or malformed data to find crashes and input-handling flaws.
- Penetration testing simulates real adversaries, usually following NIST SP 800-115 phases: planning, discovery, attack, reporting.
- Regression testing confirms that fixes do not reintroduce old vulnerabilities; security regression tests should be automated and run on every build.

Step 4 – Prepare environment and data. Tests must run in an isolated environment that closely mirrors production configuration. Production data must be masked, tokenized, or replaced with synthetic data; using live personal or payment data in test is a classic exam trap.

Step 5 – Define test oracles and pass/fail criteria. Every test case must have an expected result. For security, the oracle is often the requirement itself or a standard such as ASVS.

Step 6 – Execute, record, triage. Results are logged with evidence (screenshots, request/response pairs, tool output). Findings are rated for severity, validated to remove false positives, and tracked to closure. Metrics such as defect density, mean time to remediate, and requirement coverage feed back into the strategy.

Step 7 – Report and sign off against exit criteria. Testing ends when exit criteria are met, not when the schedule runs out. Residual risk that is accepted must be documented and approved by the appropriate risk owner, not by the tester.

Step 8 – Continuous improvement. Lessons learned (missed vulnerabilities, escaped defects found in production) update the strategy, the standards baseline, and future plans. In DevSecOps environments the strategy also specifies which tests run in the pipeline as automated gates.

Key Distinctions the Exam Loves
- Strategy vs. Plan: strategy is broad, long-lived, organizational, and risk-driven; plan is narrow, project-specific, detailed, and schedule-driven. If a question mentions a specific release, dates, named testers, or specific test cases, it is talking about the plan. If it mentions overall approach, risk appetite, or policy, it is the strategy.
- Verification vs. Validation: verification asks "did we build the product right?" (conformance to specification); validation asks "did we build the right product?" (meets user and stakeholder needs). Security testing is primarily verification against security requirements, but acceptance testing adds validation.
- Testing vs. Assessment vs. Audit: testing exercises the software; assessment is a broader evaluation of controls; audit is an independent examination against a standard for compliance evidence.
- Entry vs. Exit criteria: entry criteria gate the start; exit criteria gate completion and release.
- Test coverage: in security context, coverage means requirements and threats covered by tests, not just lines of code executed.

How to Answer Exam Questions on This Topic

CSSLP questions are scenario-based and often ask for the best, first, most important, or primary answer. Use these reasoning patterns:

Pattern 1 – "What should be done first?" The answer is almost always about planning inputs: review the security requirements, consult the threat model, define scope, or establish the risk-based priorities. Running a scanner or starting a penetration test is rarely the right first step.

Pattern 2 – "Which document would contain X?" Map the item: risk appetite, tool philosophy, and testing policy go in the strategy; schedules, named test cases, RTM, environments, and exit criteria go in the plan; verification requirements and procedures come from standards such as ASVS or NIST SP 800-115.

Pattern 3 – "How do we know testing is complete?" The answer is exit criteria defined in the plan and agreed before testing began, never "when the schedule ends" or "when the tool reports zero findings."

Pattern 4 – "Test data" questions. The secure answer is always sanitized, masked, or synthetic data in an isolated environment. Copying production data to test is wrong even if it is "temporary."

Pattern 5 – "Who accepts residual risk?" The business or system owner, not the tester, developer, or security team.

Pattern 6 – "Which standard applies?" Penetration test methodology: NIST SP 800-115. Web app verification requirements: OWASP ASVS. Test documentation and process: ISO/IEC/IEEE 29119. Product security evaluation levels: Common Criteria. Payment card software: PCI DSS. Quality characteristic model: ISO/IEC 25010.

Pattern 7 – "Why did a vulnerability escape to production?" Look for the root cause in the test basis: a missing requirement, a threat not modeled, a test case not traced, or a scope exclusion. The fix is to improve traceability and the strategy, not just to add a tool.

Exam Tips: Answering Questions on Security Test Strategy, Plan and Standards

1. Think like a manager, not a hacker. The CSSLP is a professional certification; the best answer is usually the one that is documented, repeatable, risk-based, and traceable, rather than the one that is technically cleverest.
2. Risk-based wins. When options differ in how testing effort is allocated, choose the one that prioritizes by threat exposure and asset value.
3. Traceability is king. Any answer that links test cases back to security requirements and threat models is a strong candidate.
4. Watch the scope word. Enterprise-wide, long-term, policy-level language signals strategy; release-specific, dated, detailed language signals plan.
5. Eliminate answers that skip planning. "Immediately run DAST," "hire a pen tester now," or "start fuzzing" without defined scope and criteria are distractors.
6. Remember that security testing covers both positive and negative cases. A plan that only tests that controls work, but not that attacks fail, is incomplete.
7. Independence matters. Where a question emphasizes objectivity or regulatory evidence, favor independent or third-party testing, but note that it should complement, not replace, internal testing defined by the strategy.
8. Standards are tools, not substitutes for thinking. If an answer says "following the standard guarantees security," it is wrong; standards define minimum baselines and consistent methods.
9. Regression tests must be automated and repeated. Questions about preventing re-introduction of fixed vulnerabilities point to automated security regression suites integrated into CI/CD.
10. Know the NIST SP 800-115 phases (planning, discovery, attack, reporting) and the OWASP ASVS levels (Level 1 opportunistic, Level 2 standard, Level 3 advanced) because they are easy, frequently tested facts.
11. Do not confuse code coverage with requirement coverage. High line coverage does not mean security requirements were tested.
12. Read for the role in the scenario. A question written from the project manager's view may want schedule and resource answers; from the security architect's view it may want threat-model alignment; from the auditor's view it may want evidence and standards conformance.

Quick Recap
The security test strategy sets the risk-based approach and policy. The security test plan turns that approach into scoped, traceable, measurable work for a specific product with clear entry and exit criteria, safe environments, and defined roles. Standards such as ISO/IEC/IEEE 29119, NIST SP 800-115, OWASP ASVS, and Common Criteria supply the methods, benchmarks, and vocabulary that make results credible and comparable. On the exam, favor answers that plan before testing, trace tests to requirements and threats, prioritize by risk, protect test data, define completion criteria in advance, and place risk acceptance with the business owner.