ISTQB CT-SEC cheat sheet

Risk-based planning ranks assets by impact x likelihood; security test effort per asset is proportional to its rank, not to its line count.

A security test plan states, per asset: confidentiality, integrity and availability objectives, threat profile, entry/exit criteria and the residual risk accepted by the owner.

ISTQB CT-SEC treats security testing as a whole-lifecycle activity: requirements, design, implementation, deployment and operations each need their own test objectives.

Test levels map to security focus: component level = input validation and memory safety; integration = authentication, session and interface hardening; system = attack resistance and resilience; acceptance = compliance and operational security.

Threat modelling (e.g. STRIDE, attack trees) supplies the test basis; each identified threat becomes at least one negative test condition or a documented reason for exclusion.

Entry criteria for security test execution typically include: stable build, known configuration baseline, test accounts with defined privileges, and monitoring/logging enabled.

Exit criteria must be measurable: e.g. zero open critical findings, all high findings with agreed remediation dates, and defined coverage of the threat list.

Security testing needs dedicated environments and data; production-like but isolated, with synthetic or masked data, because real personal data raises legal exposure during attack simulation.

Planning must allocate time for retesting fixes; a finding is not closed until the fix is verified and a regression check confirms no new exposure.

Vulnerability scanning: automated pattern matching against known signatures; high coverage, high false-positive rate, no business-logic insight; repeatable and cheap per run.

Penetration testing: manual, goal-directed exploitation chained across steps; finds logic flaws and chained weaknesses that scanners miss; not repeatable and sample-limited.

Static analysis (SAST) works on source/bytecode without execution; dynamic analysis (DAST) works on the running system without source. They find different defect classes and are complementary.

Interactive analysis (IAST) instruments the running application and correlates runtime data with code location, reducing false positives relative to SAST/DAST alone.

Fuzz testing feeds malformed or random input to interfaces; effectiveness measured by code/interface coverage and by time-to-first-crash, not by number of inputs sent.

Security regression testing re-executes previously failing exploit cases after each change; the historical finding list is the regression suite's basis.

Operational performance under attack (resilience) is tested by load plus hostile traffic: measure degradation, failover behaviour and whether rate limiting triggers before resource exhaustion.

Test execution order matters: reconnaissance (enumeration, fingerprinting) precedes targeted exploitation; results of earlier steps are inputs to later steps.

Evidence discipline: each finding records reproduction steps, request/response or log excerpt, affected component, severity rationale and the environment used, so it can be retested.

Risk-based evaluation asks whether the tests covered the highest-ranked risks; a pass on low-risk areas does not offset an untested critical asset.

Requirements-based evaluation checks traceability: every security requirement (e.g. authentication strength, logging, encryption in transit) maps to at least one test case and a result.

Vulnerability-based evaluation uses defect density and severity distribution per component; concentration of findings in one module signals design weakness, not bad luck.

Severity ratings combine exploitability and impact; a remotely exploitable flaw with high impact outranks a local flaw needing physical access.

Common weakness classifications (e.g. injection, broken access control, cryptographic failures) are used to check test coverage by category rather than by count of tests.

Human factors: social engineering, phishing susceptibility, password-sharing habits and insider misuse are testable through controlled simulations with informed consent and no punishment for those who fail.

Usability of security controls is a test target: if a control is so burdensome that users bypass it, the control fails its objective regardless of technical correctness.

Evaluation must separate confirmed findings from scanner noise; unverified tool output is a lead, not a defect, and inflating it distorts the risk picture.

Residual risk after testing is reported explicitly to the risk owner; testing reduces uncertainty, it does not remove risk, and sign-off means accepting the remainder.

Tool categories: scanning (SAST/DAST/IAST), fuzzing, network and port scanning, interception proxies, vulnerability management, log/SIEM analysis, and cryptographic assessment.

Tool selection criteria: coverage of the technology stack, false-positive profile, integration with the defect workflow, licensing, and whether results are reproducible.

Automated tools cannot judge business-logic abuse or authorization intent; those require human-designed tests, so tool output is an input to, not a substitute for, test design.

Interception proxies let a tester modify requests between client and server; this tests server-side validation, which client-side checks alone never prove.

Standards used as test basis include ISO/IEC 27001 (management system), ISO/IEC 25010 (security as a quality characteristic: confidentiality, integrity, non-repudiation, accountability, authenticity), and OWASP guidance for web/application testing.

Legal and ethical constraints: testing only within written authorization and scope, respecting data-protection law, and reporting findings confidentially through the agreed channel.

Certifications and schemes (e.g. Common Criteria evaluation assurance levels) define depth of evidence required; the assurance level chosen drives how much testing is mandated.

Tool results must be triaged and deduplicated before reporting; identical findings from multiple tools count once, with the strongest evidence attached.

Keeping tool signatures and rule sets current is a maintenance task; stale signatures silently reduce detection and create false confidence in a clean report.