ISTQB Specialist (CT-STE v1.0.1) Mock Exam #2 — Questions & Answers
Every question in this mock exam, with the correct answer marked and a written rationale behind each option below — for reading and review, not a timed run.
Chapter 1 · Security Paradigms — 6 questions
A national energy grid operator runs a dispatch control system through which…
A national energy grid operator runs a dispatch control system through which operators issue switching commands to 260 substations in real time. In a security risk workshop the team concludes that if the dispatch console became unreachable for as little as ten minutes, no load-balancing command could be issued at all and the operator would lose control of the network. Which element of the CIA triad is primarily at stake in this scenario?
Availability — authorised operators must be able to reach and use the dispatch function at the moment they need it.
Correct. The stated consequence is that a needed function cannot be used during the outage window, which is exactly the availability property.
Confidentiality — the switching commands and the substation states they reveal must stay hidden from every unauthorised party outside the control room.
Confidentiality concerns unauthorised disclosure. The scenario describes operators who cannot act, not substation data being read by an outside party, so this property is not the one at stake.
Integrity — a switching command must reach the substation exactly as the operator issued it, without alteration.
Integrity concerns unauthorised or undetected modification of data. Here no command is altered; commands cannot be issued at all.
Non-repudiation — it must be provable afterwards which operator issued which switching command.
Non-repudiation is a security property, but it is not one of the three elements of the CIA triad, and the scenario does not describe a dispute over who acted.
Availability is the property that authorised users can access the system and its functions when needed. The scenario describes loss of access to a function, not disclosure of data or unauthorised modification of it.
A telecom operator classifies the data held in its subscriber platform into protection levels. SIM authentication keys are placed in the highest level; marketing contact preferences are placed in the lowest. How does the assigned protection level of an asset influence security testing?
The higher the protection level of the asset, the more rigorous and more extensive the testing of the components that store, transmit or process it.
Correct. Information sensitivity drives the depth, coverage and effort of security testing for the components handling that information.
The protection level decides which cryptographic algorithm the platform applies to the asset, whereas the depth of the security testing is settled separately, from the release schedule agreed with the delivery manager.
Classification does shape the protection mechanisms, but it is also the input that sets how deeply the handling components are tested. Deriving test depth from the release schedule leaves the most sensitive assets under-tested.
Once the subscriber platform as a whole has been classified, every component inside it is tested to the same depth, because one platform-wide protection level keeps coverage consistent.
Classification is applied per asset, so a single platform-wide level is too coarse. Components that only touch marketing preferences do not warrant the rigour owed to those handling SIM authentication keys, and uniform depth spreads effort away from the highest level.
The protection level is used after test execution to decide how each reported finding should be labelled in the defect tracker.
Criticality of findings does depend on the asset, but the classification is available before testing and is meant to shape test planning, not only reporting.
The sensitivity of the information determines how rigorous and how extensive the security testing of the components handling it has to be. Classification is an input to test planning, not a label applied afterwards.
A telecom operator is preparing for its annual security audit. Which TWO statements correctly describe the relationship between security testing and a security audit?
Security testing supplies objective evidence about whether the specified controls actually work, and the audit weighs that evidence against the applicable requirements.
Correct. Test results are one of the main evidence sources an audit relies on when judging control effectiveness.
An audit assesses conformance of processes and controls against a defined reference, whereas security testing exercises the system in order to reveal weaknesses in it.
Correct. This is the essential difference in purpose: conformance assessment versus weakness discovery through execution.
A security audit makes a separate security test effort redundant, because the auditors re-execute the security test team's own test cases during the audit window and therefore arrive at the same evidence.
Auditors sample and inspect evidence rather than reproducing the test team's execution effort. The two activities pursue different objectives and both are needed.
Security testing decides whether the organisation passes and is certified, while the audit is limited to reviewing that the required documentation exists.
The pass judgement belongs to the audit, and audits examine controls in operation rather than documentation alone. The roles are inverted here.
The scope of the audit is derived from the defects that security testing has already found, so audit planning must wait for the final test report.
Audit scope comes from the applicable requirements and the audited processes. Test findings inform the audit but do not define its scope or its timing.
An audit assesses conformance of processes and controls against a reference; security testing exercises the system and produces the objective evidence about control effectiveness that the audit consumes. Neither replaces the other.
A video streaming provider builds its browser player on an open-source media library that it does not maintain itself. What is the main consequence of this reuse for security testing?
The library's own weaknesses become weaknesses of the player, so both the component and the way the product uses it belong in the test scope, and newly disclosed vulnerabilities in it must be tracked over time.
Correct. Reuse transfers risk into the product, and the disclosure of new vulnerabilities in a widely used component is a continuing trigger for further testing.
Because the source code is public and read by a wide community of contributors, the library can be left outside the product's test scope, as upstream community review of that widely shared code already covers how the player configures and calls it in production.
Community review of the upstream code says nothing about how this product configures and calls the library in its own deployment. The provider still carries the risk it ships to its own users, so the component and its usage stay in scope.
Only the licence terms of the library need to be reviewed before each release, because accountability for weaknesses in the component stays with the upstream project that publishes and patches it on its own release schedule.
Licence review is a different concern, and no upstream project is accountable for the risk the provider ships to its users. Waiting for the upstream patch schedule also leaves the product exposed between disclosure and fix.
The library may only be exercised with black-box techniques, since the absence of a support contract rules out inspecting or analysing the component's own source code.
The opposite is true: the source being available makes static analysis and code review of the component possible in addition to dynamic techniques, and no support contract is needed for that.
A reused open-source component brings its own weaknesses into the product, so the component and the way the product uses it belong in the test scope, and newly disclosed vulnerabilities in that component must be tracked over the product's life.
An organisation operates a fleet of 180 networked multifunction printers across its offices and is redesigning how those devices are granted access to internal document services. Which design assumption is consistent with the zero trust paradigm?
Each request a device makes is authenticated and authorised on its own merits, whatever network segment the device happens to sit in.
Correct. Removing implicit trust and verifying every request explicitly is the core of the zero trust paradigm.
Devices attached to an internal office VLAN are treated as trusted peers, because the VLAN boundary itself acts as the access control for the document service.
This is the perimeter model that zero trust is meant to replace: trust is inferred from network location, so any device that reaches the VLAN inherits the rights of a legitimate printer.
Trust is established once when the device is enrolled into the fleet management console, and that decision then holds for the device's service life, since enrolment already proves its hardware identity.
A permanent trust decision made at enrolment is still implicit trust. Zero trust re-evaluates the decision at each access using current signals, because a device can be tampered with or reassigned long after it was enrolled.
Only the administrative web interface of a device needs authentication, because submitting a print job is routine work.
Zero trust does not exempt ordinary business actions; the document flow itself carries the sensitive data and must be verified too.
Zero trust removes implicit trust derived from network location or from a one-off enrolment. Each request is authenticated and authorised on its own merits, every time.
A telecom operator runs two data centres, DC-North and DC-South. Thirty-four…
A telecom operator runs two data centres, DC-North and DC-South. Thirty-four backend services — subscriber provisioning, HLR lookup, billing mediation and CDR archiving among them — call each other across a dedicated inter-data-centre link. Today a service accepts an incoming machine-to-machine call as authenticated purely because the source address falls inside 10.42.0.0/16, the range assigned to the peer data centre: no per-service credential, token or client certificate is presented, and any process that can source packets from that range is served. The security architecture board has mandated a move to zero trust and has asked you, as security test engineer, what the test design must now verify. Which test objective follows most directly from applying zero trust to this machine-to-machine communication?
That a service rejects a call arriving from inside 10.42.0.0/16 when it carries no valid per-service identity, and that an authenticated caller is authorised only for the specific operation it requests rather than for the whole API.
Correct. This directly tests that implicit trust from the network range is gone and that each request is verified and least-privilege authorised — the two things zero trust changes here.
That the inter-data-centre link is encrypted end to end and that 10.42.0.0/16 is not routable from the internet, so the perimeter surrounding both data centres is confirmed to be intact.
Both checks are useful hygiene, but they reinforce the perimeter assumption. They would pass unchanged while any process inside the range still gains access without an identity.
That every one of the thirty-four services can still reach every other service across the inter-data-centre link inside the agreed latency budget, since zero trust is judged successful when the new authentication leaves existing connectivity undisturbed.
Confirming unrestricted reachability is the opposite of the zero trust objective, and latency behaviour is not a security test objective for this change.
That human administrators must complete multi-factor authentication in both data centres before they are permitted to deploy or restart any of the thirty-four backend services.
This tests interactive human access. The risk described is in the service-to-service path, which would remain trusted by IP range even if administrator login were hardened.
Zero trust removes the implicit trust that the source IP range confers. The test must therefore prove that network position alone no longer buys access: a caller from inside the range with no valid service identity is rejected, and an authenticated caller is authorised only for the specific operation it is entitled to.
Chapter 2 · Security Test Techniques — 7 questions
A tester is given the airline booking API's interface specification and read access to its database schema, but not the service source code. Using that information, the tester attacks the running service through its endpoints. How is this security test best classified?
Grey-box and dynamic: partial internal knowledge is used to design the attacks, and the running service is executed to observe its behaviour.
Correct. Some but not full internal knowledge is grey-box, and executing the deployed service makes the technique dynamic.
Black-box and dynamic: no source code is read, so the tester works purely from the outside and the database schema is no more than published interface detail.
A database schema is internal design information, not published interface detail. Holding it together with the interface specification gives the tester more than a black-box tester would have, which makes the test grey-box.
White-box and dynamic: read access to the database schema exposes the internal structure of the implementation, and that is the level of insight white-box testing is defined by.
White-box implies access to the internal implementation, source code included. A schema together with an interface specification is partial knowledge, which makes the test grey-box.
Grey-box and static: the test is derived by analysing the specification and the schema, and such analysis work is static by nature.
The grey-box part is right, but the attacks are executed against the running service, so the technique is dynamic, not static.
Partial internal knowledge (interface specification and schema) without full source access is grey-box; exercising the running service makes it dynamic. The syllabus notes that in practice these categories overlap.
An airline's security test plan lists four activities for the passenger booking service. Which one of them is a static security test technique?
Reviewing the authorisation rules in the booking service source code to find code paths where the passenger-to-booking ownership check is missing.
Correct. The work product is examined without being executed, which is the defining characteristic of a static technique.
Sending deliberately malformed request bodies to the running fare-quote endpoint to see whether the parser raises unhandled exceptions.
This executes the deployed service and observes its behaviour, so it is a dynamic technique — specifically fuzzing.
Running an automated vulnerability scan against the internet-facing check-in host to enumerate exposed services and their known weaknesses.
A vulnerability scan sends probes to a live target and interprets the responses it gets back, which makes it dynamic rather than static.
Replaying a captured check-in session token against the running booking service after the session was ended, since recorded traffic is re-sent unchanged and nothing new is supplied to the service.
Replaying a token exercises the deployed service and its response is observed, so the technique is dynamic. Re-sending recorded traffic is still execution, not examination of a work product.
Static techniques examine the work product without executing it. Reviewing authorisation logic in the source code is static; sending traffic to a running endpoint, scanning a live host and replaying a captured token are all dynamic.
A telecom operator plans network fuzzing of the protocol handler that receives SIM provisioning messages from its retail channel. Which TWO statements about fuzz testing are correct?
It supplies malformed, unexpected or mutated input — for network fuzzing, deliberately malformed packets — and observes the handler for crashes, hangs and unhandled exceptions.
Correct. This is the technique's definition, and malformed network packets are the syllabus example of network fuzzing.
The value of a campaign depends on being able to detect and diagnose the failures it triggers, so monitoring, logging and crash capture have to be in place before it starts.
Correct. A crash that nobody observes yields no finding, which is why instrumentation of the target is part of preparing the fuzzing run.
A complete formal specification of every valid provisioning message must exist before any fuzzing input can be generated for the protocol handler.
A grammar or sample corpus improves fuzzing efficiency, but mutation-based fuzzing works from captured provisioning traffic and needs no complete formal specification.
Fuzzing establishes whether the handler's authorisation rules grant each retail channel role exactly the permissions recorded for that role.
That is an access control test objective. Fuzzing targets robustness of input handling, not the correctness of permission assignment.
Fuzzing results can be passed to the developers directly as exploitable vulnerabilities, because a reproducible crash already demonstrates attacker-controlled behaviour and so amounts to the same finding as a working exploit.
A crash shows a robustness defect; whether it can be driven into an exploit needs further analysis. Reporting the two as the same finding overstates what the campaign established.
Fuzzing supplies malformed, unexpected or mutated input — for network fuzzing, deliberately malformed packets — and watches for crashes, hangs and unhandled exceptions. Its value depends on being able to observe and diagnose the failure, so monitoring and crash capture must be in place before the campaign runs.
A telecom operator's identity and access management control is being tested. What does reconciliation testing of identities and permissions verify?
That the identities and permissions actually present in the systems match the authoritative record of who should hold them, exposing entries that exist in one source but not in the other.
Correct. Reconciliation is a comparison between the deployed state and the authoritative source, and its findings are the discrepancies between them.
That every permission currently granted is still required by the person who holds it and has been re-approved by the manager or system owner accountable for that right, so the comparison is a sign-off exercise.
A periodic sign-off by the accountable owner is recertification testing, which asks whether a right is still justified. Reconciliation makes no judgement about need; it compares the deployed entries with the authoritative record.
That a user holding a valid identity is prevented from carrying out operations beyond the permissions recorded against that identity.
This is an authorisation enforcement test. Reconciliation examines the permission data itself rather than how the system enforces it at runtime.
That the credential policy applied to each identity satisfies the strength and rotation rules written in the operator's security policy.
Credential strength is a separate authentication concern and is not what reconciliation of identities and permissions compares.
Reconciliation compares what actually exists in the target systems against the authoritative record of what should exist, exposing identities and rights present in one source but not the other — for instance orphaned accounts.
In the self-service portal of a telecom operator's billing system, which test targets authorization rather than authentication?
Signing in as a legitimate subscriber and then requesting the monthly invoice belonging to a different subscriber's account number.
Correct. The identity is already established, so what is being probed is whether the system permits this identity to reach another subscriber's data.
Submitting one valid subscriber username together with five hundred candidate passwords to see at which attempt the account is locked and how long the lockout then holds.
Password guessing and the lockout threshold that answers it both belong to the process of proving identity, which is authentication. No permission decision is reached, because the session never opens.
Presenting a one-time code from an SMS message that expired eleven minutes ago and checking whether the login step still accepts the stale code.
The one-time code is a second authentication factor, so how its expiry is handled at the login step is part of authentication rather than a permission check.
Checking that the sign-in form returns the same message for an unknown username as for a known username with a wrong password.
This concerns information leakage from the authentication dialogue — account enumeration — and still sits before any permission decision.
Authentication establishes that the claimed identity is genuine; authorization decides what that established identity is permitted to do. Requesting another subscriber's invoice while logged in as oneself probes the authorization decision.
An organisation has hardened its fleet of 180 networked multifunction printers…
An organisation has hardened its fleet of 180 networked multifunction printers against a baseline: default administrative passwords replaced, unused services such as Telnet and FTP switched off, and firmware signature checking enabled. What is the appropriate objective for a security test of these protective technologies?
Establish that the measures are effective on the deployed devices: that the disabled services no longer answer, that the former default credentials fail, and that unsigned firmware is refused.
Correct. The objective of testing a protective technology is evidence that it actually works in the deployed configuration, not that it was intended.
Establish that the hardening baseline document has been reviewed and formally approved by the manager who owns the printer fleet.
Approval of a document is a governance step. It says nothing about whether the devices in the offices are actually in the hardened state.
Establish that the fleet management console reports the hardening baseline as successfully applied for all 180 devices in its inventory.
This trusts the management tool's own status field. A device can report compliance while a service is still reachable, so the effect must be verified independently.
Establish that the printers have been moved into a separate network zone, on the grounds that device hardening takes effect once the devices sit behind a firewall that filters their inbound traffic and blocks the disabled services.
Zoning is a separate protective technology operating at the network edge, and hardening takes effect on the device itself irrespective of the zone it sits in. A filtered zone also leaves the disabled services reachable from inside it, so the premise linking the two is wrong.
Testing protective technologies means establishing that the measures are effective on the deployed devices — that the switched-off services really do not answer, that the old default credentials really fail, that unsigned firmware really is refused.
After a restructuring, an airline moved 1,240 employees between departments over…
After a restructuring, an airline moved 1,240 employees between departments over one weekend: 610 from ground handling into a new baggage-operations unit, 380 from cargo into ground handling, and 250 from crew scheduling into network planning. Every move was recorded in the HR system, and the provisioning job duly created the role assignments for the new departments in the departure control system, the crew rostering tool and the cargo manifest system. The assignments belonging to the previous departments, however, were not withdrawn. You have been asked to design recertification testing of the resulting access rights. Which test design addresses the risk that these transfers have introduced?
Sample transferred employees for each source-and-target pair, have the accountable role owner re-approve the effective rights each of them now holds across all three systems, and record every right without a current business need — above all a retained right from the previous department — as a failed recertification.
Correct. Recertification re-establishes business justification for the rights actually held, which is exactly what exposes the entitlement left over from the old department.
Confirm for each of the 1,240 transferred employees that the role assignment for the new department was created by the provisioning job and that the employee can sign in to the system belonging to that new department, treating every successful sign-in as evidence that the restructuring was provisioned correctly across all three systems.
This proves only that the additions worked. The entitlements retained from the previous department pass the check untouched, so the accumulation risk stays invisible.
Re-run the authentication test suite of all three systems against the transferred accounts to confirm that credentials, session handling and multi-factor enrolment survived the mass HR change unaffected, since a bulk identity change of this size is the event most likely to disturb the sign-in path across all three systems.
Authentication was not what the restructuring changed, and a suite that only confirms sign-in still works says nothing about which rights the account carries. The transfers altered entitlements, so an authentication regression suite looks in the wrong place.
Compare the total count of role assignments in each of the three systems before and after the weekend and raise a finding whenever the difference does not equal the number of employees who were moved, since a balanced count shows the provisioning job acted on every transfer.
Totals can balance out while individuals hold rights they should not: a count matches when additions and withdrawals offset each other, and it carries no statement about business need, which is the point of recertification.
The risk is accumulated entitlement: transferred staff now hold the rights of both the old and the new department. Recertification testing must have the accountable role owner re-approve the effective rights each sampled person now holds across all affected systems, and must treat any right without a current business need — typically a retained right from the previous department — as a failure.
Chapter 3 · The Security Test Process — 5 questions
The security test team for a government tax portal has prepared a plan that includes credential brute-force attempts and fuzzing of the filing endpoint on a pre-production instance. According to the security test process, what has to be in place before execution starts?
Explicit approval from management for the planned intrusive activities, covering the agreed scope, the systems in scope and the time window in which they may be run.
Correct. Security testing may disrupt systems and resemble a genuine attack, so documented management authorisation is a precondition for execution.
Closure of every finding raised in the previous test cycle, because results obtained while earlier weaknesses remain open cannot be interpreted.
Open findings from a previous cycle influence how results are read, but they are not a precondition for starting the next run and closing them all is rarely feasible.
One trial execution of each intrusive test case against a publicly available test range, so that the team can demonstrate the technique is harmless before pointing it at the tax portal.
A public range behaves nothing like the tax portal, so such a run demonstrates little about the effect on the portal, and the security test process does not require it before execution.
An announcement of the planned attacks to all portal users, so that unusual system behaviour during the window is not mistaken for a genuine incident.
Coordination is needed with operations and monitoring staff, not with the user population; announcing planned attacks broadly would itself create risk.
Because security testing uses intrusive and potentially damaging techniques, explicit approval from management for the planned activities, scope and time window is a mandatory precondition for starting execution.
In the security test process, which work product is derived directly from abstract (conceptual) security tests?
Concrete security test cases, carrying specific input data, preconditions and the expected result for each case.
Correct. Abstract tests state the idea of the test; making them concrete by adding data and expected results produces the test cases.
Security test procedures and scripts that put the tests into an executable sequence with the steps, data loads and tooling needed to run them against the target environment.
Procedures and scripts come one step later: they sequence test cases that already carry data and expected results, so they are derived from the concrete cases rather than from the abstract tests.
The threat model that identifies which assets an attacker would target and by which routes and entry points those assets can be reached.
The threat model is an input to the process. It informs which abstract tests are worth designing rather than being derived from them.
The security risk analysis that ranks the identified risks by likelihood and impact.
Risk analysis is also an input used to prioritise the test approach; it precedes rather than follows the abstract tests.
The progression is abstract or conceptual tests, then concrete test cases with specific data and expected results, then test procedures or scripts that put the cases into an executable sequence.
A government tax portal is setting up an environment for its security testing. Which TWO characteristics make such an environment effective?
It reproduces the production configuration in the aspects that govern security behaviour, in particular the access rights, role delegations and privilege boundaries.
Correct. If rights and delegation differ from production, an authorisation test result in the environment says nothing about production.
It allows intrusive and destructive techniques to be executed without putting live taxpayer data or live users at risk.
Correct. Security testing damages state and floods interfaces, so the environment must absorb that without production consequences.
It shares the identity store with production, so that real taxpayer accounts and their real credentials can be reused for realism.
Sharing the production identity store puts live credentials and personal data into the reach of the tests, which is the opposite of what is wanted.
It is restored from a clean backup after each individual test case, so no case is affected by the previous one.
Restoring between suites is often sensible, but per-case restoration is disproportionate and is not a defining characteristic of effectiveness.
It holds only synthetic data at the lowest classification level, so the security controls inside it can be left in their default state while the test data itself carries no sensitive value.
Synthetic data is good practice, but the security controls are themselves the object under test. Leaving them in a default state makes results obtained in the environment unusable for judging production.
An effective security test environment reproduces the production aspects that govern security behaviour — notably access rights, role delegation and privilege boundaries — and at the same time allows intrusive and destructive techniques to be used without endangering live data or live users.
Which statement characterises exploratory security testing?
Test design, execution and learning proceed together inside a time-boxed charter, with the tester using what each result reveals to choose the next attack.
Correct. Concurrent design and execution guided by observation, within an agreed charter, is what makes the approach exploratory.
The complete set of security test cases has to be specified, reviewed and approved before the tester may begin a session, so the charter is fixed well in advance.
That describes scripted testing. Pre-specifying and approving every case fixes the attack set before anything is known about how the system responds, which removes the freedom exploratory testing depends on.
It takes the place of risk-based security test design, because the risks worth attacking are the ones the tester discovers while probing the system during the chartered time-boxed session.
Exploratory sessions are normally chartered from the risk analysis and threat model, which decide where the time box is spent, so the two approaches complement each other rather than one replacing the other.
It is used only once all scripted security tests have passed, as a final confirmation activity before the release decision.
Exploratory sessions can be run at any point, and are often most valuable early, when little is yet known about how the system behaves under attack.
In exploratory security testing, design, execution and learning proceed together within a time-boxed charter: the tester uses what each observation reveals about the system to choose the next attack, and records the session so findings remain reproducible.
A telecom operator's billing chain contains two components. The rating engine…
A telecom operator's billing chain contains two components. The rating engine turns each call detail record into a charge; the discount service applies subscriber-specific promotions. Both have been fuzz-tested and code-reviewed at component level and carry no open findings. A documented security risk analysis, built on a threat model of the chain, records the following: the rating engine accepts the discount percentage returned by the discount service without bounding it, and the discount service echoes back any percentage present in the caller's request context. Neither component can produce a mispriced invoice on its own — the effect appears only when the two are wired together. Which test level and technique should you select to address this risk?
Component integration testing of the rating engine together with the discount service, driven by the documented risk analysis, injecting an out-of-range discount percentage at the interface between them and checking whether the resulting charge is bounded.
Correct. The defect is an interface trust assumption between two components, so integrating exactly those two and attacking their interface is the level and technique that can expose it.
Component testing of the discount service in isolation, fuzzing its percentage field, because that component is where the unbounded value originates and is therefore the root cause to remove at its source.
In isolation the discount service behaves as specified — it echoes a value, which on its own is not a defect to remove. The harm appears only once the rating engine consumes the value unbounded, so component testing cannot detect the risk.
System testing of the whole billing chain with a full end-to-end business scenario, on the grounds that only the complete chain produces the invoice the subscriber finally receives, so a mispriced charge becomes observable there and can be traced back to its source afterwards.
System testing could eventually reveal the symptom, but it is later, more expensive and far weaker at isolating a two-component interface defect that is already precisely described in the risk analysis.
Acceptance testing with the billing operations department, validating the end-to-end invoicing business process against the documented security requirements for charging and invoicing accuracy.
Acceptance testing validates business requirements with the stakeholder and uses realistic, in-range data. It is the wrong level for a technical trust assumption on an internal interface.
The risk lives in the interface between two components and cannot be reproduced by either alone, which is exactly what component integration testing addresses. The syllabus notes that such testing should be driven by a documented risk analysis with realistic threat modelling — available here — and the technique is to inject the out-of-range value at the interface and observe whether the consumer bounds it.
Chapter 4 · Security Testing Standards and Best Practices — 4 questions
A video streaming provider has to observe one security standard because a national regulator requires it, and has chosen to follow a second one voluntarily. What difference does the mandatory versus voluntary nature of the two standards make to security testing?
Non-conformance with the mandatory standard has consequences imposed from outside, so its normative clauses become obligatory expected results, while for the voluntary one the organisation itself chooses which recommendations to adopt and how deeply to verify them.
Correct. The distinction determines whether conformance is negotiable and therefore how firmly the standard's clauses bind the test oracle.
Only the mandatory standard can serve as a source of test oracles, because a voluntary standard states recommendations rather than defined expected results, and an auditable expected result can be derived from it only once the national regulator has also made that standard binding.
Voluntary standards and best practices are explicitly useful oracle sources. Once the organisation adopts one, its clauses supply expected results without any regulatory endorsement being needed.
Once both have been adopted they are applied in exactly the same way, since the clauses of a standard carry identical force whatever the reason for adopting it, and conformance is verified by the same evidence.
The clauses read the same, but the consequence of deviating differs sharply, and that consequence is what drives how much verification effort each one justifies and what evidence has to be retained.
The voluntary standard has to be followed in full including its informative annexes, whereas for the mandatory standard only the clauses the regulator cites in its audit checklist apply, so the voluntary one actually carries the wider test scope and demands the greater verification effort.
Adopting a standard voluntarily creates no obligation to follow its informative parts, so the scope is the organisation's own choice. The normative-versus-informative distinction applies to both standards alike, and a regulator's checklist does not shrink the mandatory standard to the items it lists.
For a mandatory standard, non-conformance has external consequences imposed by the regulator, so its normative clauses become obligatory expected results. For a voluntary one, the organisation itself decides which recommendations to adopt and how deeply to verify them.
An HR and recruitment SaaS vendor has finished a new candidate-assessment…
An HR and recruitment SaaS vendor has finished a new candidate-assessment module. It sits in the test environment but has not been deployed to any tenant: there is no production URL, no configured identity provider and no real applicant data. Static analysis reports that user-supplied free text is concatenated into a database query in three places. The security test lead scores the finding with CVSS and arrives at 4.3, largely because the vector requires assumptions about an attack surface that does not yet exist. On that number the triage board ranks the finding below four medium findings in the live payroll module and defers it. Which action applies the syllabus guidance correctly, and why does the choice of scoring scheme change the priority?
Re-score the finding with CWSS: CVSS presumes a deployed configuration, so for an undeployed module its exploitability and environmental inputs must be guessed, whereas CWSS scores the weakness itself and carries the uncertainty about the eventual deployment explicitly.
Correct. This is the case CWSS exists for, and it changes the priority because the score then reflects the code defect instead of an attack surface that has yet to be built.
Retain the CVSS score of 4.3 and revisit the finding once the module has gone live, since a weakness that no attacker can currently reach contributes nothing to measured risk, and a score produced before the deployment configuration is known would have to be revised once the tenant setup is final.
This is precisely the shift-left failure the guidance warns against: the weakness is cheapest to remove now, and deferring it until deployment is the surest way for it to reach production untouched. Re-scoring later also costs more than scoring the weakness correctly today.
Score the finding with CWSS and then adjust its CVSS value to the same number, so that every item on the triage board can still be ranked on a single common scale of severity for the release.
The two schemes measure different things on different scales; forcing one to match the other destroys the meaning of both scores and leaves the board ranking on a number that no longer refers to either model.
Discard the static analysis finding and re-test the module with a dynamic tool, because only a score fed by observed exploitation of a running system can be defended to the triage board alongside the live payroll findings.
Discarding a confirmed weakness because dynamic evidence is missing loses real information, and the module has no deployment for a dynamic tool to attack in the first place, so the re-test would produce nothing to compare.
CVSS assumes a vulnerability in a deployed configuration; its exploitability and environmental inputs have to be invented for a component that is not deployed, which pushes the score down for the wrong reason. CWSS scores the weakness itself and explicitly accommodates uncertainty about the future deployment, so the finding is prioritised on the code defect rather than on an attack surface that does not exist yet.
You are threat-modelling the operator console of an energy grid dispatch system…
You are threat-modelling the operator console of an energy grid dispatch system using STRIDE. The design review produces two facts. First, the console identifies the substation gateway it talks to only by hostname, resolved through an internal DNS server that any host on the operations network is permitted to update. Second, the console's 'shift supervisor' role is carried by a claim inside a session cookie that the console writes itself and does not sign. Which TWO STRIDE categories capture the threats that these two facts introduce?
Spoofing: any host able to update the internal DNS record can present a rogue endpoint that the console accepts as the genuine substation gateway.
Correct. Identity of the remote endpoint rests on a name that an attacker controls, which is the definition of a spoofing threat.
Elevation of privilege: an ordinary operator can edit the unsigned role claim in the cookie and act with shift-supervisor authority that was never granted.
Correct. A client-modifiable authorisation claim lets a user obtain rights beyond those assigned, which is elevation of privilege.
Information disclosure: the hostname of the substation gateway and the role names used by the console become readable by every host on the operations network through the writable DNS zone.
Internal hostnames are not the sensitive asset here, and the threat the review describes concerns which endpoint the console ends up trusting rather than what is revealed to onlookers.
Denial of service: resolving the gateway by hostname introduces a dependency on DNS whose failure would leave the console unable to dispatch anything.
The availability dependency is real but it is a design consequence of using DNS at all, not a threat created by the two facts the review reported.
Repudiation: the console has no way to prove afterwards which operator issued a particular switching command to a given substation.
Nothing in the two facts concerns the audit trail of issued commands; repudiation would need a separate finding about logging and command attribution.
An unauthenticated, writable name-resolution path lets an attacker present a rogue endpoint that the console accepts as the genuine gateway — spoofing. An unsigned role claim that the client can edit lets a normal operator assume supervisor authority — elevation of privilege.
The requirement specification for the new account area of a video streaming…
The requirement specification for the new account area of a video streaming platform contains one sentence about password changes: 'Users shall be able to change their password.' It says nothing about whether the current password must be re-entered, what happens to sessions already open on other devices, or how a failed attempt is reported. The developers have implemented the function and you, as security test engineer, must decide what the expected result is before you can design any test. How should best practices be applied in this situation?
Derive the expected results from an established practice such as the OWASP secure coding guidance on authentication and session management — re-authentication before the change, invalidation of the other open sessions, no disclosure of which credential was wrong — record that document as the test oracle, and have the product owner confirm the derived expectations.
Correct. This is the intended use of best practices as an oracle source: fill the specification gap from a recognised reference and get the result agreed so it becomes a requirement.
Report the requirement as untestable and suspend all test design for the change-password function until the product owner has written a complete and unambiguous specification covering re-authentication, session handling and error reporting, since designing tests against expectations the customer has not yet written down would put the test team in the role of the requirements author rather than its reviewer.
Reporting the gap is right, but stopping there leaves the function unexercised through the release. Best practices exist so that testing can proceed meanwhile against a defensible, documented oracle, and the derived expectations are confirmed by the product owner rather than imposed by the test team.
Test only what the sentence states — that a password can be changed — because taking expected results from an external document would verify behaviour outside the agreed scope of the requirement, and any defect raised against an OWASP clause the customer never adopted would be rejected at triage as out of scope.
Security expectations are frequently implicit; confining the oracle to the literal sentence leaves session handling and re-authentication entirely unverified. A derived expectation that the product owner confirms is in scope, so the triage argument does not hold.
Take the behaviour the developers implemented as the expected result, on the grounds that they built the function following the platform's internal coding conventions, which already encode the session handling and re-authentication rules the specification left out.
Using the implementation as its own oracle means every implemented behaviour passes by construction, which is not a test at all, and internal conventions are an assumption here rather than a recorded oracle.
Standards and best practices are legitimate sources of test oracles precisely where a requirement is silent. The engineer derives the expected results from an established practice such as the OWASP secure coding guidance for authentication and session management, records that document as the oracle, and has the derived expectations confirmed by the product owner so they become agreed requirements.
Chapter 5 · Adjusting Security Testing to the Organizational Context — 4 questions
The regulator for the national electricity sector obliges grid operators to keep…
The regulator for the national electricity sector obliges grid operators to keep a tamper-evident record of every access to the dispatch control system for seven years, to make each record attributable to a named individual, and to be able to produce the records for a chosen period within 48 hours of a regulatory request. The operator's security policy has been amended to state these obligations. As security test engineer you must decide how the obligation changes your choice of techniques for the next test cycle. Which selection follows most directly from it?
Add tests that an access record is written for every access path including administrative and emergency accounts, that a record cannot be altered or deleted by the account that produced it, and that retrieval for a chosen period returns a complete set — including after the archive has rolled over.
Correct. Each of these targets one of the properties the regulator imposes: completeness with attribution, tamper evidence, and retrievability over the retention period.
Concentrate the cycle on penetration testing of the dispatch console's externally reachable interfaces, since the regulator's underlying concern is that the grid is not breached from outside, and a perimeter that withstands attack makes the record-keeping obligations a secondary administrative matter for the cycle.
Perimeter penetration testing is valuable, but it produces no evidence about record attribution, tamper evidence or retention, which is what this obligation actually constrains. The record is also what the regulator inspects after an insider misuses legitimate access.
Add tests of the confidentiality of the access records, verifying that they are encrypted at rest in the archive, that their transport to the archive is protected, and that no unauthorised person is able to read them.
A reasonable secondary objective, but the obligation is about integrity, attribution and availability of the records rather than their confidentiality, and encryption at rest says nothing about whether a record was written or can still be retrieved.
Treat the obligation as a documentation matter and verify that the amended security policy cites the regulation correctly, that the retention period stated in it is indeed seven years, and that the 48-hour response commitment appears in the operator's procedure.
Reviewing the policy text confirms that an intention was written down; it produces no evidence that the deployed system writes attributable records, resists tampering or can return them inside the committed window.
The regulation constrains three testable properties: completeness and attribution of the access record, its resistance to alteration by those who generate it, and the ability to retrieve a complete set of records for a period — including after the archive has rolled over. Techniques must be selected to produce evidence about exactly those properties.
A telecom group operates in six countries and its security testing capability is…
A telecom group operates in six countries and its security testing capability is spread across them. Threat modelling and test design sit with a central team in one country. Execution is carried out by local security testers employed by each national operating company, who report to their own national security officer rather than to the central team. Findings are recorded in six different national tools and consolidated once a month. The group has asked you to plan the security testing of a new shared subscriber-provisioning platform that all six countries will use. Which planning measures follow most directly from this organisational structure?
Agree one shared test basis, one set of severity criteria and one finding format before execution begins, and schedule explicit coordination points — because the team that designs the tests has no authority over the testers who run them and results from six tools must be comparable before they can be consolidated.
Correct. Both the split of authority and the fragmented tooling are addressed: shared definitions make the results comparable, coordination points substitute for the missing line management.
Transfer the whole test effort for this platform to the central team and have it execute every test itself, since a single shared platform is best exercised by the team that designed the tests, and routing execution through six national teams would introduce six different interpretations of the same test case and six separate sets of defect records.
This ignores the structure rather than adjusting to it: the central team lacks the national access, environment knowledge and local regulatory context that the local testers hold.
Let each country plan independently, choosing the techniques and the severity scale that suit its own operating company, and merge the six reports into a group view at the end of the cycle, since local knowledge of the deployment is what makes a finding credible.
Local knowledge does make execution credible, but it does not require a local severity scale. Six incompatible scales cannot be merged into a meaningful group view, so the monthly consolidation that already exists is exactly what this would break.
Plan a single test cycle executed in the country with the strictest national regulation, on the assumption that a platform which satisfies the strictest regime satisfies the other five as well, and let the remaining national teams re-use that evidence in their own reporting to the national regulators without re-running it locally.
Regulations differ in kind, not only in strictness, so one regime does not subsume the other five. One national deployment also does not exercise the configurations and integrations of the others, which leaves the re-used evidence unsupported.
The structure separates the people who design the tests from the people who execute them and fragments the finding data across six tools. Planning must therefore fix a shared test basis, common severity criteria and one agreed finding format in advance, and build in explicit coordination points, because neither authority nor tooling is shared.
Over three weeks the following comes to light at a telecom operator. An internal…
Over three weeks the following comes to light at a telecom operator. An internal document index was reachable without authentication and has been indexed by search engines; search-engine queries restricted to that host return 214 results, listing file names such as 'DC-North_gateway_runbook_v7' and 'billing_mediation_oncall_rota'. Separately, eleven employees named in that on-call rota have public professional-network profiles stating their exact job titles, the systems they administer and, for four of them, the vendor whose tooling they were recently certified on. Three of those four then received an individually written email that referred to that vendor's product by name and to their real line manager. The network intrusion detection system logged nothing at all during the three weeks. Analyse the scenario and select the TWO correct conclusions.
The attacker is in the information gathering stage, carried out entirely passively through search engines and social networks, and is now converting the collected profile data into spear phishing against named administrators.
Correct. Indexed-content queries and social-network profiling are the classic passive reconnaissance sources, and the tailored mails referencing real managers are the spear phishing that follows from them.
The intrusion detection system logged nothing because passive reconnaissance sends no traffic into the monitored network — the index and the profiles are queried at third parties — and the tailored mails arrive through the ordinary mail path rather than as recognisable attack traffic.
Correct. A network sensor can only report on traffic it sees; reconnaissance conducted against third-party services never crosses it, which is the structural blind spot here.
The attacker has already reached the exploitation stage, because obtaining runbook and on-call rota file names means internal documents were read out of the data centre network, and the tailored mails show that a foothold inside the group's own mail infrastructure has already been established.
Nothing was exploited and nothing left the network: the organisation published the file names itself through an unauthenticated, indexed index page, and a tailored mail needs no foothold to send.
The intrusion detection system missed the activity because its signature set was out of date, so refreshing the signature feed and extending log retention would have brought the three weeks of reconnaissance to light in the perimeter logs.
Signature currency and retention are irrelevant when no packet from the attacker ever reaches the sensor; no signature can match traffic that does not exist, and no retention period preserves a record that was never written.
Since no traffic from the attacker was observed, no attack is under way, and the exposed document index should be handled as a housekeeping task by the portal team at the next opportunity.
The absence of observed traffic is a property of the detection method, not evidence of safety; the tailored mails show an attack is already in progress, so the exposed index is an open source of reconnaissance rather than housekeeping.
This is passive information gathering: search-engine reconnaissance of an exposed index plus social-network profiling, feeding a spear phishing attempt. It is invisible to a network intrusion detection system because the queries are answered by third parties, not by the operator's monitored network, and the phishing mail arrives over the ordinary mail path.
A national energy company's perimeter logged 41 minutes of traffic from a single…
A national energy company's perimeter logged 41 minutes of traffic from a single source address last night; the chart below summarises it. The incident review adds the following facts. The source was one address in a consumer broadband range. Every request carried an identical User-Agent string naming a well-known free scanning tool and its version. The ports were walked in ascending numeric order with no randomisation and no timing evasion. When the scan reached an exposed management interface, the attacker ran the unmodified proof-of-concept exploit that had been published two days earlier for a vulnerability in that interface, failed because the interface was already patched, and made no further attempt. No log was cleared and no persistence artefact was found.
Analyse the evidence and select the TWO correct conclusions.
The evidence describes a low-skill, opportunistic attacker of the script-kiddie type using off-the-shelf tooling and a published exploit: the activity is noisy, self-identifying, uniform across the whole port range and abandoned at the first failure.
Correct. Every observed property points away from a patient, resourced adversary, who would randomise, throttle, rotate sources, hide the tool and persist after a failure.
Because such attackers rely on published exploits against whatever happens to be exposed, closure priorities shift towards patching internet-reachable components for which public exploits exist and towards reducing the exposed surface itself.
Correct. The attacker type determines what matters: exposure and patch latency for known issues, rather than defences designed against targeted, stealthy adversaries.
The uniform high-volume traffic across the entire port range is evidence of a resourced attacker deliberately generating noise so that a second, quieter intrusion can run in parallel, the self-identifying User-Agent string being a deliberate part of the decoy.
A noise-as-cover pattern would show a second, distinct traffic profile from another source; here there is one source, one tool and one constant rate throughout the 41 minutes.
Since the exploit attempt failed against an already patched interface, the event needs no change in closure priorities and can be closed as a blocked attack that the existing controls handled.
No control blocked anything: the attempt failed by luck of timing, because the exploit was two days old and the interface happened to be patched already. That margin is exactly what the closure priorities have to protect.
The absence of cleared logs and of any persistence artefact indicates the attacker had already obtained the access that was wanted and therefore had no reason either to come back later or to hide the traces of the scanning session just finished.
Both absences are consistent with an attacker who lacks the skill or the intent to hide and persist, which fits every other property of the session; the failed exploit shows no access was obtained at all.
Uniform coverage of the whole port range, a constant rate with no evasion, a self-identifying tool, an unmodified public exploit and abandonment at the first failure together describe a low-skill, opportunistic attacker — the script-kiddie profile. That profile shifts closure priorities towards promptly patching internet-reachable components for which public exploits exist and towards shrinking the exposed surface.
Chapter 6 · Adjusting Security Testing to Software Development Lifecycle Models — 4 questions
A government tax portal team is moving from a sequential lifecycle with one security test phase before release to two-week iterations, each of which can deliver a shippable increment. Which statement describes the effect on security testing?
The security test activities are decomposed so that they fit inside an iteration and become part of its definition of done, so each increment is assessed as it is built instead of in one phase before release.
Correct. This is the shift-left consequence of iterative development: smaller, repeated security activities integrated into every iteration.
Security testing is scheduled as a dedicated hardening iteration immediately before each release, leaving the ordinary feature iterations free of security activities so that their delivery velocity is unaffected.
This reproduces the sequential security phase under a new name: weaknesses accumulate through the feature iterations and are found at the point where fixing them is most expensive, and an increment declared shippable mid-cycle was never assessed.
Responsibility for security testing passes to the operations team, because a two-week iteration is too short for meaningful security activities to be completed inside it.
Security activities can be decomposed and sized to fit an iteration; handing them to operations means the increment is released before anyone has assessed it.
The overall number of security test activities falls, since each iteration delivers a smaller change than a sequential release did, and a smaller change surface means fewer places for a weakness to be introduced in the first place.
Each individual change is smaller, but the activities are executed far more often and the regression scope keeps growing, so the total effort rises rather than falls.
In an iterative lifecycle the security test activities have to be decomposed so that they fit inside the iteration and become part of its definition of done, shifting the assessment left into each increment rather than concentrating it in one phase before release.
While testing a video streaming platform, a tester finds that the endpoint…
While testing a video streaming platform, a tester finds that the endpoint returning a viewer's playback history accepts any numeric profile identifier and returns the history for that profile, requiring nothing beyond a valid session of any account. What does analysing this result to determine the nature of the vulnerability and its potential technical impact involve?
Establishing what kind of weakness it is — a missing ownership check on a directly referenced object — and what an attacker could technically achieve with it, such as enumerating identifiers to read arbitrary viewers' histories.
Correct. Nature means the class of weakness; potential technical impact means what the weakness makes technically possible for an attacker.
Establishing which developer introduced the missing check and in which release it first shipped, so that the fix can be assigned to the right team and traced to its origin.
Origin tracing helps route the defect and bound the affected releases, but neither the author nor the shipping release says anything about the class of weakness or about what an attacker could do with it.
Estimating the contractual penalties, the regulatory exposure and the loss of subscriber trust that disclosure of the viewing histories would cause, since the impact of a finding is understood as the consequence it carries for the organisation.
That is business impact, which is assessed later and by other roles. The analysis asked for here is the technical consequence the weakness makes possible.
Reproducing the finding against the production service to confirm that the same behaviour occurs when live subscriber profiles are used as identifiers.
Reproducing an access-control flaw against live viewers' data would itself breach their confidentiality, and the class of weakness is already determinable from the observed behaviour.
Analysis of a result establishes what kind of weakness has been observed — here a missing ownership check on a directly referenced object — and what an attacker could technically achieve with it, such as enumerating identifiers to read the viewing history of arbitrary accounts.
Two days before the annual filing deadline, a government tax portal is carrying…
Two days before the annual filing deadline, a government tax portal is carrying fourteen times its normal load. A critical finding has been confirmed: the session cookie issued after login is not scoped to the portal's own host, so browsers also send it to a legacy subdomain operated by a different team. A hotfix altering the cookie attributes and the login response has been deployed straight to production, bypassing the normal release path. The change touches the login handler, the session store and the logout handler. You must define what is to be tested now, in production, inside the peak window. Which scope is appropriate?
Confirmation testing that re-executes the test which exposed the finding, plus a risk-based security regression set over the functions the change touched — login, session validity, logout and session invalidation, and single sign-on to the legacy subdomain — selected so it can run without disturbing filing traffic.
Correct. Confirmation proves the fix; regression covers the areas the change could have broken; the risk-based selection is what makes execution in a peak production window feasible.
Confirmation testing alone: the change is a single cookie attribute and the finding can be shown to be fixed, so regression testing may wait for the first scheduled release after the deadline, when the portal is no longer carrying peak filing traffic and a full security regression suite can be scheduled safely against the restored baseline.
The change also touched the session store and the logout handler, so it is not a single attribute. A broken logout or session invalidation would go undetected through the busiest days of the year, which is precisely when the exposure is greatest.
The complete security regression suite for the portal, executed against production at once, because a change deployed outside the normal release path invalidates the earlier security test evidence for the whole system, and only a full re-run against the live configuration restores a baseline that can be defended to the filing deadline's auditors.
An unplanned deployment does not invalidate the evidence for untouched areas, and a full suite against production at fourteen times normal load threatens the availability of the filing service itself.
A regression run confined to the pre-production environment, on the grounds that it carries the same code and therefore yields evidence equivalent to a production run, without putting any load on the portal during the filing peak, when availability matters most.
The hotfix went to production directly, so only production is known to hold that exact configuration. Cookie scoping in particular depends on the live host and domain names, which differ in pre-production, so the evidence is not equivalent.
Both activities are needed. Confirmation testing re-executes the test that revealed the finding to prove the fix works. Security regression testing then covers the functions the change touched — login, session validity, logout and session invalidation, and the single sign-on path to the legacy subdomain — with the selection kept risk-based and non-disruptive because it runs in production at peak.
A telecom operator's subscriber self-service platform has been built for years…
A telecom operator's subscriber self-service platform has been built for years in a sequential lifecycle: a six-week security test phase preceded each of the two annual releases and closed with a manual penetration test and a signed security release report. The platform is now moving to DevOps with continuous deployment — up to thirty production deployments a day, each a small change, with no release gate and no fixed release date. You have been asked to analyse how the security testing activities are affected. Select the TWO correct conclusions.
Activities expressible as repeatable, tool-driven checks with a machine-decidable verdict must move into the pipeline and run on every change — static analysis of changed code, composition analysis of dependencies, automated security regression and configuration checks — since there is no release date for a six-week phase to occupy.
Correct. The absence of a release gate forces the deterministic, automatable checks to become per-change pipeline stages.
Activities that rest on human judgement and creative attack construction do not become pipeline steps: threat modelling of a new design, exploratory security testing and manual penetration testing are scheduled alongside the pipeline, triggered by design changes and by risk, and their results feed back into the automated checks.
Correct. These activities produce insight rather than a pass/fail verdict a pipeline can act on, so they are re-timed rather than automated, and they seed new automated checks.
Since every deployment carries a small change, the accumulated risk is lower, so the manual penetration test can be discontinued once the automated pipeline checks are in place and the test budget is redirected to extending them across the pipeline.
Small changes accumulate into large architectural drift, and automated checks find only the weakness classes they encode. Extending them is useful, but discontinuing the manual test removes the only activity that constructs novel attacks.
The six-week security test phase should be kept unchanged and executed once a quarter against whatever happens to be in production at the time, since continuous deployment changes the frequency of releases rather than the set of weaknesses that has to be looked for, and the signed security release report stays the evidence of record for the auditors.
By the time a quarterly phase reports, production has moved on by roughly 2,700 deployments, so its findings describe a system that no longer exists and the signed report documents a state that is already gone.
Security regression testing becomes the job of the rollback mechanism: a change that introduces a weakness is reverted within minutes, so re-running earlier security tests adds little value once deployment is continuous and each change is small enough to undo on its own, long before subscribers notice.
Rollback assumes the weakness was noticed, which is what the regression tests are for. A silent authorisation regression triggers no alert and no rollback, so nothing is reverted however small the change.
Activities that can be expressed as repeatable tool-driven checks with a machine-decidable verdict have to move into the pipeline and run on every change, because a six-week phase has no slot left when there is no release date. Activities resting on human judgement and creative attack construction cannot become pipeline steps; they are scheduled alongside the pipeline, triggered by design change and by risk, and their results feed back into the automated checks.
Chapter 7 · Security Testing as Part of an Information Security Management System — 4 questions
An airline's contract with a booking channel partner states the security…
An airline's contract with a booking channel partner states the security acceptance criterion as: 'no finding rated high or above may remain open at handover, and the authorisation model must be verified for all twelve partner roles.' How does an acceptance criterion of this kind influence the security test approach?
It shapes the approach: techniques have to be chosen that produce evidence for all twelve roles, the severity scale used in triage must match the agreed rating, and the exit criteria of the effort follow from the criterion.
Correct. Acceptance criteria are an input to test planning, determining coverage, technique selection and how the effort is judged complete.
It bears only on the handover decision at the end of the effort, leaving the choice of coverage, techniques and severity scale entirely to the professional judgement of the security test team until the partner reviews the delivered result at handover.
Treating the criterion as a final gate means discovering at handover that the evidence covering twelve roles had not been produced at all, and that the team's own severity scale does not map onto the agreed rating.
It takes the place of the security risk analysis, because the criterion already states which risks the partner considers relevant to the handover and which roles matter.
The criterion states a required result and a coverage target, not the risks behind them. Risk analysis is still what identifies where the weaknesses are likely to be and what to attack within those twelve roles.
It confines the team to black-box techniques, since only results observable from outside the system can be presented as evidence to an external partner, so review and static analysis findings fall outside the agreed evidence scope.
Evidence from reviews and static analysis is equally presentable to a partner, and it is often the most economical way to cover an authorisation model across twelve roles. Nothing in the criterion restricts the techniques to externally observable behaviour.
Acceptance criteria state what must be covered and with what result, so they shape the choice of techniques, the coverage to be achieved, the severity scale used in triage and the exit criteria of the test effort.
Why are security test results fed as an input into an organisation's information security management system?
They convert assumed risk into measured risk: the ISMS uses them as evidence to update its risk assessment, judge whether the controls are effective in practice, and decide on treatment.
Correct. Feeding results into the ISMS is what allows security risk to be managed actively rather than on the basis of assumptions.
They are archived there so that the security test team can clear the evidence out of its own tools at the end of each test cycle.
The ISMS is a management system, not an evidence archive, and the point of the input is that decisions are taken from it.
A management system certificate can only be issued once a penetration test report has been attached to the management system documentation as evidence.
Certification depends on the management system meeting the standard's requirements and showing that risk is managed; no single test report is the trigger for issuing it.
The management system then selects which security test cases the team executes in the following cycle, taking over test design so that the cases run can be traced directly to the registered risks.
The ISMS sets objectives and priorities from risk, but test design and case selection remain with the security test team.
The ISMS manages security risk actively, and test results are the evidence that turns assumed risk into measured risk: they update the risk assessment, show whether controls are effective in practice, and drive treatment decisions.
An airline's information security management system needs metrics from security testing. Which property must such a metric have if the management system is to use it?
It must be defined so that measuring the same situation twice yields the same value, and so that a change in the value can be attributed to a change in the security posture rather than to the way it was collected.
Correct. Repeatability and interpretability are what make a metric a basis for management decisions over time.
It must be reducible to a single overall percentage, so that different systems in the estate can be ranked against one another on one figure.
Compressing security posture into one number hides which risks are covered, and comparability between different systems is not what makes a metric usable.
It must be collected by hand by the security test team, because a value produced automatically by a tool cannot be presented as auditable evidence to an assessor.
Automated collection is usually more repeatable and leaves a better audit trail than manual collection, so the collection method is not the criterion.
It must be derived from the number of security test cases executed, since effort is the quantity that can be counted consistently across different systems and across reporting periods without further definition work or tool support.
Executed test cases measure activity rather than security posture; the count can rise while the share of risks actually covered falls, and a consistent count of the wrong quantity supports no decision.
A metric is usable inside an ISMS only if it is defined precisely enough that measuring the same situation twice gives the same value, and if a change in the value can be attributed to a change in the security posture rather than to how it was collected.
An airline's information security management system reports that security…
An airline's information security management system reports that security testing covers 100% of its defined test objects: the booking web application, the check-in web application and two public APIs. The figure has stood at 100% for four consecutive quarters and the number of findings per quarter has dropped to two. The steering group is not convinced that security risk is being managed actively and asks you which new test objects would raise the maturity of the management system. Which proposal is the most appropriate?
Add the parts of the estate that have never been in scope — the identity provider and its federation with partner airlines, the internal crew and ground-staff back-office applications, the build and deployment infrastructure, the network zone configuration, and the workforce's response to social engineering — so coverage is measured against the real attack surface.
Correct. New test objects extend the scope over which coverage is claimed, which is the syllabus route to greater management system maturity.
Increase the number of test cases run against the four existing objects each quarter until the finding count rises again, since a rising finding count is the evidence the steering group is asking for that testing has become more thorough, and deepening coverage of objects already in scope avoids the cost of building test environments for parts of the estate that have been out of scope so far.
More cases against the same four objects deepen an already saturated area and leave every untested attack path exactly as it was; the finding count is also not the objective.
Present the existing complete-coverage figure to the steering group together with the four-quarter trend and the falling finding count, since coverage of the defined test objects is precisely the metric the management system asked for, it is being met, and a declining number of findings is itself evidence that the tested objects have stabilised under repeated attack across four quarters.
This is the situation the steering group is already dissatisfied with: the metric is met because the scope it is measured against is too narrow to be informative, and a falling finding count in a saturated scope says nothing about the untested parts of the estate.
Replace the coverage metric with a count of open high-severity findings, so the management system measures the outcome of testing instead of the effort put into it, and report that count each quarter alongside the mean time taken to close a finding and the age of the oldest item still open, so the trend is visible.
Changing the metric changes the reporting, not the maturity. With the same four objects in scope, a finding count and its ageing profile are drawn from the same narrow sample and would be just as uninformative.
Maturity grows when the scope of what is tested grows to match the real attack surface. Complete coverage of a narrow set of test objects says nothing about the identity provider, the internal back-office applications, the build and deployment infrastructure, the network zoning or the workforce — all of which are attack paths into the same assets.
Chapter 8 · Reporting Security Test Results — 3 questions
An interim security test report on an HR and recruitment SaaS platform is going to the customer's executive steering group. Which statement reflects the guidance on what that report should contain?
The summary conveys the impact of the identified risks in terms the steering group can act on, while the technical detail of individual vulnerabilities follows separately and reaches a controlled audience.
Correct. Reporting is tailored to the stakeholder, and the confidentiality of exploitable detail governs who receives it and when.
The summary carries the full reproduction steps for every finding, so that members of the steering group are able to verify each result for themselves.
Reproduction steps are working attack instructions and are of no use to this audience; widening their circulation increases the exposure of the live platform.
The report gives only the count of findings per severity level, because an executive steering group has no use for technical content and a severity breakdown is the form in which security results belong in a management report.
A bare count of findings gives the group nothing to decide on; what they need is the risk impact expressed in business terms.
The report is issued once all findings have been remediated, so that it describes a platform in which no weakness is still open.
An interim report exists precisely to inform decisions while findings are still open; withholding it removes the basis for prioritising the remediation.
The summary conveys the impact of the identified risks in terms the stakeholder can act on. The technical detail of individual vulnerabilities follows separately, to a controlled audience, because those weaknesses often exist in production as well.
The table below shows the raw output of a dynamic application security testing…
The table below shows the raw output of a dynamic application security testing run against an HR and recruitment SaaS portal, together with what a tester observed when each finding was re-tested by hand outside the scanner's proxy. Six findings were raised: reflected cross-site scripting on the candidate search parameter, SQL injection on the vacancy filter, a missing HSTS header, a directory listing under /assets/tmp/, an insecure direct object reference on the applications API, and an outdated jQuery version in a bundled script.
You must evaluate these results and decide which of them are confirmed vulnerabilities. Which assessment is correct?
F-01 and F-05 are confirmed vulnerabilities with an observed effect, F-03 is a genuine configuration weakness, and F-02, F-04 and F-06 are false positives — an identical error page for every input, a 403 outside the tool's proxy and a bare version string are inference rather than observed effect.
Correct. Each row is judged on whether a manual re-test produced a real effect, which is what separates a confirmed vulnerability from a tool inference.
All six are confirmed vulnerabilities: the tool raised each of them and the manual re-test produced an observation for every row, so all six must be closed before the release and reported to the customer as live production exposures before sign-off.
An observation is not the same as a confirming observation; three of the rows record evidence that contradicts the tool's inference rather than supporting it, so reporting them as exposures would overstate the risk.
F-01, F-02 and F-05 are confirmed and the remaining three are not, because those are the rows the tool rated with High confidence, and a scanner's confidence rating is the vendor's own measure of how reliably the detection was made, and therefore the proper basis for deciding which findings are accepted.
Tool confidence is a heuristic about the detection, not evidence about the system; F-02 carries High confidence yet its manual re-test refutes injection outright, and F-03 is genuine without being rated High.
Only F-01 is confirmed, since it is the one row in which the tester saw code execute; the remaining five are statements about configuration, about library versions or about the scanner's own proxy behaviour, and none of them demonstrates an effect that the tester reproduced by hand against the running portal during the re-test.
F-05 was reproduced as one recruiter retrieving another recruiter's applicant file, which is a confirmed authorisation failure even though no code executed, so execution of code is the wrong criterion.
Evaluation means comparing what the tool inferred with what was actually observed. F-01 and F-05 were reproduced with a real effect, so they are confirmed. F-03 is a genuine configuration weakness: the header really is absent and plain HTTP really answers. F-02, F-04 and F-06 are false positives — an identical error page for every input contradicts injection, a 403 outside the proxy shows the listing was an artefact of the tool's own session, and a version string with no reachable vulnerable sink is not an exploitable weakness.
On a Friday afternoon you confirm that the HR and recruitment SaaS platform…
On a Friday afternoon you confirm that the HR and recruitment SaaS platform allows any authenticated recruiter to retrieve the applicant file belonging to any other recruiter's vacancies — CV documents and stated salary expectations for roughly 90,000 candidates. The same code is live in production. The customer's normal process is to record findings in the shared project tracker, which all 140 project members including external contractors can read, and to discuss them at the Wednesday quality meeting. How should this finding be communicated?
Escalate immediately, outside the normal channel, to the named security contact and the system owner over a protected route; restrict the technical detail to those who need it to decide or to fix; and record it in a defect tracker with restricted access.
Correct. The criticality of the finding and its presence in production drive both the urgency and the narrow, controlled audience for the detail.
Record it in the shared project tracker with the full reproduction steps straight away, so that every project member is aware of the live exposure and the finding cannot later be said to have been concealed from any of the people who work on the platform day to day.
This publishes working attack instructions against live candidate data to 140 readers, contractors included, while the weakness is still open in production.
Hold the finding until the Wednesday quality meeting and present it there with the rest of the cycle's results, so the customer receives one coherent set of findings in a single structured briefing.
A five-day delay on a live exposure of 90,000 candidate files is not defensible, and the quality meeting is the ordinary channel. Critical findings are escalated to the security contact as soon as they are confirmed.
Report it verbally to the security contact and keep it out of every tracker, so that no written record of the weakness exists anywhere while production remains exposed.
Confidentiality is achieved by restricting access, not by leaving no record; without a tracked entry the fix cannot be assigned, followed up or confirmed.
Critical security findings that also exist in production are handled outside the ordinary channel: they are escalated immediately to the security contact and the system owner over a protected route, the detail is restricted to those who need it to decide or to fix, and the record is kept in a tracker with restricted access.
Chapter 9 · Security Testing Tools — 3 questions
A security test team is categorising its toolset along the static/dynamic and white-box/black-box dimensions. Which pairing of tool type and category is correct?
Software composition analysis is static and white-box: it reads the product's declared dependency manifests and packaged binaries without executing it.
Correct. Nothing is executed and internal artefacts of the build are required, which places the tool in the static, white-box category.
Fuzzing is static and white-box, because the malformed inputs are generated from the source code before any part of the system is run.
Input generation may use the source, but the inputs are then fed to a running target and its reaction observed, which makes fuzzing dynamic.
Vulnerability scanning is static and black-box, because it compares the version numbers and banners it collects against a database of known issues rather than executing the system under test.
The scanner has to interrogate a live host or service to collect those versions and banners, so it operates dynamically.
Penetration testing tooling is static and white-box, since the tester needs the design documentation of the target system in order to plan credible attack paths.
Design documentation can inform the plan, but penetration testing executes attacks against the running target and is often conducted with limited internal knowledge, so neither part of the pairing holds.
Software composition analysis reads declared dependency manifests and packaged binaries without executing the product, and it needs internal artefacts to do so — a static, white-box tool. Fuzzing, vulnerability scanning and penetration testing all require the target to be running.
A team is selecting a security testing tool for its energy-sector customer. Which selection consideration is specific to security testing tools rather than applying to test tools in general?
How frequently the supplier refreshes the tool's knowledge of vulnerabilities and attack patterns, because a tool with stale knowledge reports against an attack landscape that has moved on.
Correct. Security tools are only as good as the currency of the threat knowledge they carry, which is not a concern shared by test tools in general.
Whether the tool can export its results in a machine-readable format that the team's reporting chain is able to consume without rework, so findings reach the defect tracker without being retyped by the tester.
A sensible requirement, but integration and result exchange apply to any test tool the team might select, and the export format says nothing about the quality of what is exported.
Whether the tool runs on the operating systems and platform versions already in use across the test team's workstations and build agents.
Platform compatibility is a general tool selection concern and says nothing about the tool's security capability.
Whether the licensing model permits as many concurrent users as the team has members, so that execution is not serialised across the whole team.
Licensing and concurrency constrain any tool acquisition equally; neither arises from the security nature of the tool.
Security tools depend on knowledge of current vulnerabilities and attack patterns, which ages quickly. How frequently the supplier refreshes that knowledge is therefore a selection criterion peculiar to security testing tools.
A video streaming provider has bought a recommendation service from a supplier…
A video streaming provider has bought a recommendation service from a supplier. What the provider receives is a deployable container image, the interface documentation and a runtime agent that the supplier supports — but no source code and no build. The service is already deployed in the provider's integration environment and is serving real request traffic there. The security risk analysis names two risks: injection through the free-text search parameter, and authorisation gaps in the internal endpoints that the documentation does not describe. Which tool selection fits this situation, and on what grounds?
Dynamic analysis against the deployed service, complemented by interactive analysis through the supplier's runtime agent: no source is available for a static tool to read, the service is deployed and serving traffic, and the agent adds the code-level location of findings observed from outside.
Correct. The absence of source rules static analysis out, while the deployed, traffic-serving state is precisely the phase and access that dynamic and interactive tools require.
Static analysis of bytecode decompiled from the container image, because a static tool gives the precise code location of a weakness and injection is a code-level defect in the request handler.
Decompiled third-party bytecode yields noisy, hard-to-triage results, and it would still leave the undocumented internal endpoints — discoverable only at runtime — unexamined.
Static analysis first and dynamic analysis only if the static run reports nothing, following the usual sequence of applying static techniques before dynamic ones in the lifecycle, since a weakness caught before execution costs less to remove.
The shift-left ordering assumes the code is yours and available early. Here neither condition holds, so the static run has nothing to read and applying the sequence mechanically wastes the cycle.
Software composition analysis of the container image on its own, because the risks in a purchased service originate in the third-party components the supplier bundled into it, and an inventory of those components with their known vulnerabilities is the only evidence obtainable without source code or a build.
Composition analysis would find vulnerable bundled libraries, but neither named risk is a dependency issue — both lie in the service's own request handling and authorisation logic, and dynamic tools do produce evidence without any source.
Tool selection follows from the phase and the access available. There is no source code, so a static analyser has nothing meaningful to read; the service is deployed and serving traffic, which is exactly what dynamic tools need. Instrumenting it with the supplier's runtime agent adds interactive analysis, which reports the code-level location of a weakness that a purely external tool can only observe from outside.