ISTQB Specialist (CT-STE v1.0.1) Mock Exam #3 — 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 university keeps three data sets in the same student platform: the public…
A university keeps three data sets in the same student platform: the public course catalogue, the internal exam question bank, and the records of the student health service. Before test planning starts, the security team assigns each data set a protection level. What is the main purpose of assigning security levels to assets in this way?
It states how much protection each data set needs, so the depth and rigour of security testing can be matched to the asset
Correct. Security levels classify assets by the protection they require, and that classification drives how strictly each asset is tested.
It records which university department owns each data set, so that defect reports reach the correct maintainer
Incorrect. Recording an owner supports defect routing and configuration management, whereas a security level states the protection the asset requires, not who repairs it.
It fixes the retention period of each data set, so that obsolete records are purged on schedule
Incorrect. Retention periods are a data-management rule that often follows from regulation, and they say nothing about how much protection the asset needs while it is held.
It ranks the data sets by how likely they are to contain functional defects, so that functional test effort can be distributed
Defect likelihood is an input to functional test prioritisation. Asset security levels are about the value and sensitivity of the asset, not about expected defect density.
Asset security levels express how much protection an asset needs. That judgement is what lets the test team decide how deep and how rigorous the security testing of each asset has to be, instead of treating all data identically.
A ride-hailing platform stores two things behind the same web front end: a public fare table and scanned driver licence documents. Both are reachable through the same set of REST endpoints. How should the difference in sensitivity between these two data sets influence the security testing?
The endpoints handling the licence scans are tested more thoroughly, with stricter checks on access control and on protection in storage and transit
Correct. Higher information sensitivity justifies deeper coverage and stricter pass criteria for the paths that expose that information.
Both data sets are exercised with the same set of test cases, because they are served by one technical interface and one deployment, so the testing effort is spread evenly over the two of them
A shared interface and a shared deployment do not equalise the consequences of a breach. Sensitivity of the information, not deployment topology, sets the required test rigour.
The fare table is tested first and more deeply, because it is publicly reachable and therefore exposed to more traffic
Exposure volume alone does not justify the deeper effort. Public data has little confidentiality value, so a leak of the fare table has minor consequences.
The licence scans are moved out of the test scope and covered by a separate data-protection review, because document confidentiality is a legal matter rather than a test one
Incorrect. Confidentiality of scanned documents is enforced by technical controls that only testing can verify, so a document review cannot substitute for test coverage of the most sensitive asset.
The sensitivity of the information determines how strict the security testing has to be. The more sensitive asset justifies more test coverage and more demanding checks, even when both assets sit behind the same technical interface.
A municipal library is undergoing a security audit of its lending and city-account services. Which two statements correctly describe the role of security testing within such a security audit? (Choose two.)
Security testing provides the audit with evidence on how the implemented controls behave in practice, not only on how they are documented
Correct. Testing turns claimed control behaviour into observed behaviour, which is exactly the evidence an audit needs.
Audit observations can identify areas of the library services where additional security testing is needed
Correct. The audit and the testing feed each other: audit findings become input for further test design.
An audit is the sum of its security test activities, so a finished test report closes it
Incorrect. An audit also reviews policies, processes, roles and documentation, so a test report is one of its inputs.
Security testing is performed only after the audit has been closed, using the audit report as its sole source of test conditions, because the audit defines what is worth testing
Incorrect. Security testing is not confined to a post-audit phase, and its test conditions come from risk analyses, threat models and security requirements as well as from audit observations.
Security testing during an audit is limited to reviewing the library's policy documents against the applicable standard
Incorrect. Comparing documents against a standard is a review; security testing also exercises the running services dynamically.
Security testing supplies the audit with factual evidence about how the implemented controls actually behave, and audit findings in turn identify areas that need to be tested. The audit itself is broader than testing: it also examines policies, processes and documentation.
Which statement best describes the concept of zero trust as a security paradigm?
No request is trusted because of its origin; every request is authenticated and authorised on its own, whether it comes from inside or outside the network
Correct. Zero trust removes implicit trust derived from network position and evaluates each request individually.
Traffic that originates inside the internal network is treated as trusted, while traffic crossing the perimeter is inspected and filtered, so the boundary stays the place where trust is decided
This is the perimeter-based model that zero trust was formulated to replace: trust is granted implicitly on the basis of network location.
Users are granted a single strong authentication at login, after which their session is trusted for all subsequent operations
A one-off authentication that blanket-trusts the rest of the session is the opposite of continuous per-request verification.
All components are treated as untrustworthy, so data is encrypted at rest and no access control decisions are needed
Encryption is one control among many; zero trust relies heavily on access control decisions rather than removing them.
Zero trust removes the assumption that a request is trustworthy because of where it comes from. Every request is authenticated and authorised on its own merits, regardless of network location.
A donation-collection platform is assembled largely from reused open-source software (OSS) components. What is a consequence of this reuse that the security test approach has to take into account?
Publicly known weaknesses of the reused components, and of the components they depend on in turn, are part of the platform's attack surface and must be covered by testing
Correct. Reuse imports both the component and its known weaknesses, including those of its own dependencies.
Because the source code of the components is public and has been inspected by many contributors over the years, the reused parts can be left outside the security test scope entirely
Incorrect. Public inspection lowers but does not retire the risk, and nobody upstream has tested how this platform configures and integrates the component.
Only the versions of the components matter, so recording version numbers in the release notes is a sufficient security measure
Version inventory is useful input, but recording a version is not a test of whether the version's weaknesses are exploitable in this platform.
The reused components shift responsibility for their security defects to their maintainers, so the platform team can confine its own security testing to the donation workflow that it wrote in house
The operator of the deployed system remains accountable for it, and OSS maintainers carry no contractual obligation towards the platform.
Publicly known weaknesses of a widely reused OSS component are known to attackers as well, and the component's own transitive dependencies extend the attack surface. Both mean the reused parts need explicit security test attention, not only the code written in-house.
An agritech company operates 1 800 soil and irrigation sensors installed in open…
An agritech company operates 1 800 soil and irrigation sensors installed in open fields across four regions. Each sensor is a small gateway-connected device in an unlocked plastic housing on a post; anyone walking through the field can physically reach it, open it and attach a cable. The sensors report over a private APN that the original design document calls "the trusted farm network", and the platform therefore accepts any measurement, firmware heartbeat or configuration read-back that arrives from that network without further checks: there is no per-device credential, and the gateway forwards whatever it receives. The security test lead is asked to redesign the tests for this data path applying zero trust. Which test design follows from applying the zero trust paradigm here?
Design tests that submit measurements and configuration reads from a device identity the platform does not know, and from a known device acting outside its assigned scope, both injected from inside the private APN, and require the platform to reject them
Correct. Applying zero trust means the tests must prove that each request is authenticated and authorised on its own merits, so the test position must be inside the supposedly trusted network.
Design tests that confirm the private APN cannot be reached from the public internet and that the gateway rejects connections from any address outside the APN range, since that is where an attacker would sit
Incorrect. This hardens the perimeter and keeps the assumption zero trust discards, since an attacker who reflashes a sensor in the field sends traffic from an address that already lies inside the APN range.
Design tests that check the physical housing of a sample of sensors for tamper marks and verify that field technicians follow the inspection procedure
Physical inspection may be a worthwhile control, but it is not the application of zero trust to the data path and it verifies nothing about how the platform handles requests.
Design tests that measure whether the platform still ingests the full sensor volume when the number of connected devices doubles, so that the trust decisions added by the redesign do not slow ingestion below the agreed rate during the seasonal irrigation peak in all four regions
This is a capacity concern about the redesign. It says nothing about whether the platform verifies the identity and the permissions of the sender.
Design tests that verify the measurement payloads are encrypted end to end, so that intercepted field traffic cannot be read
Confidentiality of the payload is useful, but an attacker with a rogue device on the network sends validly encrypted traffic; only per-device authentication and authorisation address that.
Zero trust removes the implicit trust that the private APN currently confers. Because the device is physically accessible, an attacker can place a rogue or reflashed device on the "trusted" network. So the tests must verify that the platform authenticates and authorises each device and each message on its own, and must be designed to attempt exactly that impersonation from a position inside the private network.
Chapter 2 · Security Test Techniques — 7 questions
A test team working on a real-estate listing platform is given the API…
A test team working on a real-estate listing platform is given the API specification, the database schema and the deployment diagram, but not the application source code. They exercise the running system through its interfaces while using those documents to choose their inputs. How is this security test approach classified?
Grey-box testing, because internal structural information guides tests that are executed through the external interfaces
Correct. Partial internal knowledge combined with interface-level execution is the grey-box case.
White-box testing, because the database schema and the deployment diagram together describe the internal structure of the system under test
White-box security testing works on the implementation itself, typically the source code. Schema and diagrams are partial information, which makes the approach grey-box.
Black-box testing, because the source code is unavailable and every test is executed through the published external interfaces
Incorrect. Black-box testing derives inputs from the specification of behaviour alone, whereas here the schema and deployment diagram are deliberately used to select inputs, which is grey-box.
Static testing, because the specification, schema and deployment diagram are read before testing
Incorrect. Reading documents to design tests does not make the approach static; the tests themselves run against the executing system, which is dynamic testing.
Grey-box testing combines internal information about the structure of the object under test with testing performed through its external interfaces. Full source-code access would be white-box; no internal information at all would be black-box.
The ISTQB Security Test Engineer syllabus notes that the classification of security test types into static and dynamic has "fuzzy overlaps" in practice. What does this observation mean for a test engineer?
A single technique or tool can carry properties of more than one category, so the categories serve as a planning aid rather than as mutually exclusive labels
Correct. The overlap is real, and the classification is still valuable for reasoning about what a test approach does and does not cover.
The classification has no practical value, so test approaches should be selected purely from the list of available tools
Overlapping boundaries do not make the classification worthless; it still structures thinking about coverage and about what evidence each approach yields.
Every security test has to be assigned to exactly one category before execution, and a case that looks ambiguous has to be split into separate tests, one for each category
Forcing an artificial split is not what the observation implies; the point is that a technique may legitimately span categories.
Static techniques and dynamic techniques find the same weaknesses, so applying one of the two is enough for a given test object
The two examine different things, one the artefact and one the running behaviour, and they find different weaknesses. Overlap in classification does not mean equivalence in results.
The categories are useful for reasoning about coverage, but a real technique or tool can sit across a boundary, for example by instrumenting code and observing it while it runs. The engineer should therefore treat the categories as a planning aid rather than as strict, mutually exclusive buckets.
A gaming marketplace separates identification, authentication and authorization in its identity and access management control. Which two of the following are tests of authorization rather than of authentication? (Choose two.)
A logged-in player requests the moderation endpoint that is reserved for marketplace staff, and the request must be refused
Correct. The identity is already established; what is checked is whether that identity is permitted to perform the operation.
A logged-in player retrieves the wallet history of a different player by changing the account identifier in the request
Correct. This tests whether permissions correctly restrict which objects an authenticated identity may reach.
A login attempt is made with a valid user name and a wrong password, and the platform must refuse access without disclosing whether that user name exists
This checks whether the claimed identity can be proven, which is authentication; no permission of an established identity is evaluated.
A sign-in attempt with a valid password is made while the required second factor is deliberately omitted from the request
Incorrect. The second factor is a further proof that the claimed identity is genuine, so omitting it still exercises authentication and not the permissions of an established identity.
An account is locked after a defined number of consecutive failed sign-in attempts
This exercises a protective measure attached to the authentication process, not the evaluation of permissions.
Authentication establishes that a claimed identity is genuine. Authorization establishes what an already authenticated identity is permitted to do. Tests that vary the permitted operation or the accessed object, keeping the identity fixed, target authorization.
A connected-car telematics service encrypts the vehicle position history it stores. Which check belongs to testing the encryption and data protection control itself?
Verifying that the algorithm and key length in use are adequate and that keys are generated with sufficient randomness
Correct. A weak algorithm, an undersized key or a predictable key makes the control ineffective even when encryption is switched on.
Verifying that encrypted position records can be written and read back at the sustained throughput the telematics service requires under load
Incorrect. This measures the performance of the storage path under load; it shows that the encrypted write path keeps up, not that the protection it applies is strong.
Verifying that the vehicle owner can export the position history in a documented file format
Export functionality is a functional requirement, possibly one derived from a regulation, but it is not a test of the encryption control.
Verifying that the field storing the encrypted value is wide enough to hold the ciphertext produced for the longest journey
This is a data-definition check that prevents truncation defects. It does not evaluate the strength of the protection.
Testing an encryption control means examining the properties that make it effective: whether the algorithm and key length are adequate, whether keys are generated with sufficient randomness and handled properly, and whether data really is protected where it is claimed to be.
A municipal library runs malware scanning on every file that patrons upload to the community-notice service. What limitation of malware scanning must the test approach take into account?
The scanner detects the threats its detection data covers, so an upload that passes the scan is not thereby shown to be harmless
Correct. Detection depends on what the scanner has been given to recognise, which is why a clean result is weak evidence.
The scanner inspects only file names and extensions, so any content check has to be added by the application itself
Malware scanners inspect file content. The real limitation lies in the coverage of their detection data, not in a refusal to look inside files.
The scanner reports its findings only after the file has already been written to storage, so an infected upload cannot be rejected before it reaches the shared file store
Incorrect. Where the scan runs is an integration choice: scanning can be placed in the upload path ahead of storage, so this describes one deployment option rather than a limitation of the technique.
The scanner covers executable formats only, so documents and archive files have to be checked by a separate protective technology instead
Incorrect. Scanners also parse documents and archives, including nested ones; the constraint is which threats their detection data recognises, whatever the file format.
A malware scanner recognises what its detection data allows it to recognise. Threats that its signatures and rules do not cover pass through, so tests must not treat a clean scan result as evidence that an upload is harmless.
Which description matches destructive testing as a security test technique?
The test object is deliberately driven beyond its specified limits so that its failure behaviour, and any insecure state left behind, can be observed
Correct. The value of destructive testing lies in what the system does when it breaks, which normal testing never reaches.
Test data is deleted from the environment after each execution so that later tests start from an identical baseline
That describes test-data management and environment resetting, not a technique aimed at failure behaviour.
Findings are exploited until full control of the object is taken, to prove the finding is genuine
Incorrect. Driving a finding through to full control in order to demonstrate it is penetration testing; destructive testing is defined by pushing the object past its specified limits.
The security controls are switched off one at a time so that the contribution each of them makes to the overall protection of the test object can be measured
Disabling controls to measure their contribution is a form of control-effectiveness analysis, and it stays inside the specified operating conditions.
Destructive testing deliberately drives the test object beyond its specified operating conditions, in order to observe how it fails and whether the failure leaves it in an insecure state. That is why it needs an environment where damage is acceptable.
A university runs a student records system used by 340 staff across 11…
A university runs a student records system used by 340 staff across 11 faculties. The access policy defines 14 roles and states exactly which record types each role may read and change. Over the past three years, however, permissions have been granted individually and manually: exam officers who covered for a colleague, doctoral supervisors who needed one extra faculty, contractors added for a migration project. Nobody removed those grants, and the system now holds 2 900 individual permission entries with no record of why most of them exist. The security test lead is asked to design reconciliation testing for these permissions. Which test design does that require?
Extract the effective permissions of every account, derive the permissions the 14 documented roles would grant the same accounts, and report each account whose effective permissions differ from the derived set
Correct. Reconciliation compares the actual state against the policy-derived expected state across the whole population, which is what exposes the accumulated undocumented grants.
Design negative tests in which a sample account from each of the 14 documented roles attempts an operation that its role forbids, and confirm every attempt is refused, since a role that cannot exceed its boundary holds no unjustified grant
Incorrect. This shows that the authorization mechanism enforces each role definition, but the 2 900 entries assign permissions directly to accounts, so correct role enforcement leaves those individual grants unmeasured.
Ask each of the 11 faculty administrators to confirm in writing that the permissions currently held by their staff are still appropriate, and record the signed confirmations as the result of the reconciliation test
A written attestation is a recertification-style administrative step, not a test; it produces opinions about the policy rather than measured facts about the system state.
Run an authenticated vulnerability scan against the records system and its database, then map each finding that concerns access control to the accounts it affects
Incorrect. A scan looks for known weaknesses in the software and its configuration; a permission that is correctly implemented yet contradicts the access policy is not a weakness it can recognise.
Review the audit log of the last three years and design a test for each permission change that was made without a recorded approval reference
Log review may explain how the state arose, but it measures the change history rather than the current gap between effective permissions and policy, and grants predating the log are missed.
Reconciliation testing for identities and permissions compares the permissions actually in effect in the system with the permissions the policy defines, and reports every difference. The essential element is the comparison against the policy as the reference, over the whole population of accounts, so that grants nobody can justify are surfaced.
Chapter 3 · The Security Test Process — 5 questions
A donation platform is starting its security test process. Which combination of inputs does test analysis in the security test process primarily draw on?
The available threat models, the security risk analysis and the security requirements
Correct. These three define the threats to address, their relative importance and the properties the system is required to have.
The defect reports of the previous release and the list of tools the organisation has licensed
Past defects and available tools inform execution and estimation, but they do not establish what has to be protected against what.
The production monitoring dashboards and the incident tickets of the last quarter, which show where the platform was actually attacked
Incorrect. Observed incidents are valuable feedback, yet they record only threats that have already materialised and been noticed, so they cannot serve as the primary basis for analysing what must be protected.
The user documentation and release notes of the reused components
Incorrect. These supply detail while individual tests are designed, but they express neither the risks nor the security requirements that analysis starts from.
Security test analysis works from the available threat models, the security risk analysis and the security requirements. Together these define what has to be protected, against what, and to what degree.
In a security test process, on what basis are the security tests prioritised?
On the test approach together with the identified security risks and the threat models
Correct. Risk and threat information, interpreted through the chosen approach, determines which tests matter most.
On the order in which the components were developed, so that the oldest and least recently reviewed code is examined first
Incorrect. Development sequence says nothing about the significance of a threat or the value of the assets a component protects, and recently written code can carry the higher risk.
On the number of interfaces each component exposes, so that the widest interface is tested first
Interface count is a crude proxy for attack surface, but it ignores the value of the assets behind the interface and the credibility of the threat.
On the execution duration of the tests, so the fastest ones run first
Incorrect. Ordering by duration improves how quickly feedback arrives, which makes it a scheduling tactic rather than the basis on which security test priority is set.
Prioritisation follows the agreed test approach together with the identified security risks and the threat models, so that the tests addressing the most significant threats are executed first.
A ride-hailing company is setting up an environment for security testing. Which two characteristics make such an environment effective for security testing? (Choose two.)
Its configuration, including the protective technologies in place, is close enough to production that a finding there is credible for production
Correct. Security findings depend heavily on configuration, so a divergent environment produces results that do not transfer.
It is isolated and controlled, so aggressive tests can be run without affecting production services or exposing real customer data
Correct. Security testing includes intrusive activity, which needs an environment where the consequences are contained.
It is shared with the functional test team, so that security tests run against the same build as the functional tests and both teams raise their defects from one common environment
Sharing may be convenient, but intrusive security tests disrupt other testing, and a shared environment weakens the control that the security tests need.
It is rebuilt from scratch before every individual test case, so that no residue of an earlier test can influence the next one that runs
Incorrect. A defined starting state matters, but rebuilding per test case is not a characteristic of an effective security test environment and blocks tests that depend on accumulated state.
It runs a copy of the live customer database, so that the test data is realistic in volume and in content
Live personal data in a test environment creates the exposure the testing is meant to prevent; realism is achieved with anonymised or generated data.
An effective security test environment resembles the production configuration closely enough that findings transfer to production, and it is isolated and controlled enough that aggressive or destructive tests can be executed without harming production systems or exposing real data.
A gaming marketplace is designing security tests at component test level for a single service that parses uploaded item-description files. Which test is characteristic of the component test level in security testing?
Malformed and unexpected item-description files are supplied directly to the parsing component's interface to observe how it handles them
Correct. One component, addressed through its own interface, exercised in isolation is the component test level.
A seller uploads an item description through the storefront, and the whole publication workflow is followed through to the public listing page
This exercises the assembled system through the business workflow, which belongs to the system or acceptance level.
The parsing component and the media-conversion component are exercised together through their shared interface, to check that the item data they exchange is validated on both sides
Incorrect. Two components exercised through the interface between them is component integration testing; the component level keeps a single component isolated from its neighbours.
The deployed marketplace is scanned from outside the network to enumerate the services and versions it exposes
This examines the deployed system as a whole from an external position and is not a component-level activity.
At component level the test object is one component in isolation, addressed through its own interface. Sending malformed and unexpected input directly to that component's interface to see how it handles it is a typical component-level security test.
In a ride-hailing platform, three components exchange data over internal HTTP…
In a ride-hailing platform, three components exchange data over internal HTTP calls: the matching service, which picks a driver for a request; the pricing service, which returns the fare for a route; and the trip-ledger service, which stores the completed trip and its amount. The documented security risk analysis and the threat model state that the highest-rated internal threat is a manipulated fare value being accepted by the trip ledger, because pricing responses are consumed without re-validation, and that the pricing service currently trusts any caller inside the cluster. The test lead has to design security tests at the component integration test level. Which test design fits that level and those inputs?
Exercise the internal interfaces directly: send the trip ledger a fare value that no pricing response produced, and call the pricing service from a component that has no business reason to call it, requiring the receiving component to reject both
Correct. The tests act on the interfaces between the components, and they are derived from the two highest-rated threats named in the risk analysis and threat model.
Send malformed and oversized route payloads to the pricing service's own interface, including truncated JSON and out-of-range coordinates, and observe whether the service crashes, returns an unhandled error or exposes internal detail in its response
Incorrect. Driving one service through its own interface and judging its own reaction is a component-level test of pricing in isolation; it never shows whether the trip ledger re-validates the fare it is handed.
Book a trip through the passenger app, complete it in the driver app and confirm that the receipt shown to the passenger matches the amount the trip ledger stored for that trip, including any surcharge that the pricing service applied to the route segment
This validates a security-relevant outcome through the complete business process, which places it at the system or acceptance level rather than at component integration.
Review the source of all three services for places where an HTTP response body is deserialised without checking the declared content type or the identity of the caller
Incorrect. Static examination of the code can point to candidate weaknesses, but it is a review rather than a test and demonstrates no actual behaviour on the interfaces between the services.
Generate 5 000 concurrent matching requests and measure whether pricing responses begin to time out, forcing the trip ledger onto its fallback fare, which is the value an attacker would want accepted
Incorrect. This probes behaviour under load and the fallback path, whereas the rated threat is that a manipulated or unauthorised fare is accepted, which load generation does not exercise.
Component integration testing exercises the interfaces between components, guided by the documented risk analysis and threat model. The right design here injects manipulated and unauthorised traffic on the internal interfaces between matching, pricing and ledger, and verifies that the receiving component validates what it receives, rather than testing one component alone or the whole business flow end to end.
Chapter 4 · Security Testing Standards and Best Practices — 4 questions
A security standard adopted by a real-estate platform contains both mandatory (normative) and optional (informative) clauses. What does that distinction mean when the standard is used in security testing?
Normative clauses have to be satisfied for conformance and become obligatory test conditions, while informative clauses give guidance that may inspire tests without conformance depending on them
Correct. Only the normative part determines conformance; the informative part explains and recommends.
Normative clauses apply when a regulator has made the standard binding on the platform, while informative clauses apply when the platform adopted the standard by its own choice, so the same clause changes category with the route of adoption
How a standard came to bind the organisation, by regulation or by voluntary adoption, decides whether the standard applies at all. The normative or informative status of each individual clause is fixed by the standard itself and does not change with the route of adoption.
Normative clauses set out the security controls that have to be present in the product, while informative clauses set out the test techniques and tool categories by which each of those controls is to be demonstrated during a conformance assessment
Incorrect. The split is not by subject matter: a standard may place a control in an informative annex and a testing obligation in a normative clause. What separates the two is whether conformance depends on the clause.
Normative clauses are the ones the platform kept when it tailored the standard to its context, and the clauses it chose to drop become informative
Incorrect. Tailoring is a decision of the adopting organisation about scope; it cannot reclassify a clause, which keeps the status the standard itself assigns to it.
Normative clauses state what must be satisfied for conformance and therefore become obligatory test conditions. Informative clauses provide explanation and guidance; they may inspire useful tests, but non-conformance to them is not a conformance failure.
A gaming marketplace lets players buy an in-game currency and trade items for…
A gaming marketplace lets players buy an in-game currency and trade items for it. A static analysis run and a design review produced four confirmed weaknesses in the currency service: reliance on client-side validation of the currency amount, insufficient session expiration after logout, missing rate limiting on the item-trade endpoint, and verbose error messages in the currency-transfer API. The security test lead now has to turn each weakness into concrete test cases, and decides to consult a catalogue of attack patterns. The table below records the intermediate result of that work.
How is a catalogue of attack patterns such as CAPEC applied at this point in the work, and what does it contribute that the list of weaknesses alone does not?
It supplies the attack patterns, with their prerequisites and variants, by which each weakness is actually exploited, so every weakness can be turned into executable attack scenarios and their expected technical impact
Correct. The attack-pattern catalogue bridges from a stated weakness to the concrete steps an attacker takes, which is exactly what a test case needs.
It supplies a numerical severity score for each weakness, calculated from its exploitability and its impact, so the four items can be ranked against one another and the two that score highest can be scheduled for testing first
Scoring the severity of a weakness is the purpose of a scoring system such as CWSS or CVSS. An attack-pattern catalogue describes how an attack proceeds, not how severe the underlying weakness is.
It supplies the publicly reported vulnerability entries for the product versions the currency service runs on, so the team learns which of the four weaknesses others have already reported
Publicly reported vulnerability entries for concrete product versions are CVE records. An attack-pattern catalogue is product-independent and describes generalised attacks instead.
It supplies the recommended remediation for each of the four weaknesses, so the test cases can verify that the prescribed fix was implemented correctly
Incorrect. Checking that a prescribed fix was implemented is confirmation testing after a change, whereas the test cases here have to be designed while the weaknesses are still open.
It supplies the threat categories that the four weaknesses fall under, so that each of those categories can be checked for representation
Incorrect. Sorting threats into broad categories is what a model such as STRIDE does; an attack-pattern catalogue works at the level of the individual attack and its steps.
CWE-style weakness information says what is wrong in the product. CAPEC describes the attack patterns by which such a weakness is exploited, so it supplies the attacker steps, prerequisites and variants that a test case needs. That turns a known weakness into concrete, executable attack scenarios rather than a statement of a coding flaw.
A municipal library is threat modelling its new city-services portal with…
A municipal library is threat modelling its new city-services portal with STRIDE. The portal lets residents reserve books, pay parking fines and download their own borrowing history as a PDF; the download is generated by a single synchronous worker that holds the request open while it renders. During the workshop the team records two facts. First, the PDF download is addressed by a URL that contains the borrower number and no other check, so a resident who edits the number receives another resident's history. Second, the render worker accepts an unbounded date range, and a request covering 40 years occupies the worker for roughly 90 seconds while all other download requests queue behind it. Which two STRIDE categories do these two facts belong to, in the order given? (Choose two.)
The editable borrower number in the download URL is Information Disclosure, because data is exposed to someone not entitled to see it
Correct. STRIDE classifies a breach of confidentiality, where information reaches a party that should not have it, as Information Disclosure.
The unbounded date range occupying the single render worker is Denial of Service, because a cheap request makes the function unavailable to others
Correct. Denial of Service covers threats to availability, including resource exhaustion caused by a legitimate-looking request.
The editable borrower number is Spoofing, because the requester effectively presents as the other borrower
Incorrect. Spoofing means falsely claiming an identity in order to be authenticated as it, whereas the requester stays logged in as themselves and merely passes a number the portal fails to check.
The unbounded date range is Tampering, because the attacker modifies the parameters of the request that the worker processes
Tampering concerns unauthorised modification of data or code that the system relies on. Supplying a wide but valid range does not alter stored data; the harm is to availability.
The editable borrower number is Elevation of Privilege, because the resident ends up holding a capability that the portal reserves for library staff who administer other people's accounts
Elevation of Privilege means obtaining a higher privilege level than the one assigned. The resident keeps ordinary resident privileges and merely reaches the data of a peer, which is a breach of confidentiality.
The unbounded date range is Repudiation, because the portal cannot prove afterwards which resident submitted the expensive download request
Incorrect. Repudiation concerns the inability to attribute an action to its author, and nothing in the recorded facts says attribution is lost; the stated effect is that other requests cannot be served.
The unchecked borrower number in the URL lets one resident read another resident's data, which is Information Disclosure: a confidentiality breach. The unbounded date range lets a single cheap request monopolise the only render worker so that legitimate requests cannot be served, which is Denial of Service: an availability breach.
A connected-car supplier uses an industry security standard as the test oracle…
A connected-car supplier uses an industry security standard as the test oracle for its telematics unit: whatever the standard prescribes becomes the expected result. The current edition of that standard was written when the unit had one wired diagnostic port and a single cellular modem. The product now also carries a short-range wireless link to the driver's phone, accepts over-the-air firmware updates from a cloud service, and exposes a companion-app API through which a user can unlock the doors remotely. The test manager wants to keep using the standard but is asked to state its drawbacks in this situation. Which drawback is the most significant one to raise?
Interfaces the standard does not foresee, such as the wireless link, the over-the-air update path and the remote unlock API, yield no expected results, so conformance can be complete while the newest attack surface stays untested
Correct. An oracle can only produce expected results for what it addresses, so gaps in the standard become silent gaps in coverage.
The standard has to be applied exactly as it was published, so the supplier is not permitted to design tests of its own beyond the prescribed set and would need a revision of the standard itself before the new interfaces could be covered
Standards are meant to be tailored to the context and supplemented by the adopting organisation. Additional tests are open to the supplier; the difficulty is that the standard does not point to them.
Using a standard as the oracle yields more findings than the team is able to process, because a consensus document is drafted broadly enough to suit every conceivable product in its domain
The difficulty in this scenario is under-coverage of new interfaces rather than an excess of findings, and the breadth of a standard does not by itself inflate finding counts.
Conformance cannot be demonstrated to a regulator or a customer unless an accredited external body executes the prescribed tests on the supplier's behalf
Who executes the tests is a question of accreditation arrangements, not a drawback of using the standard as an oracle for a product that has outgrown it.
A standard describes defences against typical attacks, so test design for the diagnostic port and the modem starts from a blank page
The opposite holds: for the interfaces the standard covers, it spares the team from starting from a blank page, which is one of its benefits.
A standard is a consensus document and therefore lags the technology it describes. Where it is used as the oracle, anything the standard does not foresee, in this case the wireless link, the over-the-air update path and the remote unlock API, generates no expected result and so no test. Full conformance can be reached while the newest and most exposed interfaces stay uncovered.
Chapter 5 · Adjusting Security Testing to the Organizational Context — 4 questions
A real-estate platform operates in two countries. In the second country a data…
A real-estate platform operates in two countries. In the second country a data localisation rule came into force this year: personal data of residents, including identity documents uploaded by landlords, must be stored and processed exclusively on infrastructure located in that country, and must not be transferred abroad even temporarily. The platform's engineering and test teams sit in the first country and have always tested against a shared staging environment there, restored weekly from a masked copy of the full production database. What is the correct consequence of this regulation for the security testing?
Tests that process the regulated residents' data must be executed in an in-country environment on data that never leaves the country, while the existing shared environment may keep serving the parts of the platform outside the rule's scope
Correct. The rule constrains the location of processing, so it partitions the test environments and test data rather than the test techniques.
Masking the personal data in the weekly restore is sufficient, because records that have been masked are no longer treated as personal data by the rule, so the existing cross-border staging environment can continue to receive the full database as before
Masking lowers exposure but does not by itself place the records outside the scope of the regulation, and the rule as stated prohibits the transfer of the data in the first place.
The regulation governs the production deployment, so the test environments and the test data may stay exactly as they are until the platform promotes a build into production in that country, at which point the localisation requirement is satisfied by the in-country production infrastructure
Incorrect. The rule is written about where regulated data is stored and processed, and a staging environment holding a restored copy processes it just as production does, so the constraint does not stop at the production boundary.
The identity documents have to be dropped from the test scope, since the localisation rule leaves no lawful route by which a test team sitting in the first country could be given access to them
Incorrect. Removing the most sensitive asset from scope leaves its protection unverified, and a lawful route exists: run those tests in country, with in-country testers or in-country infrastructure.
The consequence is confined to reporting: findings about residents' data are recorded in a separate in-country defect tracker, while test execution continues unchanged
Incorrect. Where findings are stored is a real consideration, yet unchanged execution still processes the regulated data abroad, which is the transfer the rule forbids.
The regulation constrains where the regulated data may exist and be processed, which directly constrains where tests touching that data can run and what data they may use. Tests exercising the localised data need an in-country environment and in-country test data; the existing cross-border staging environment can only continue for data outside the rule's scope.
A donation platform has no security testers of its own. It contracts an external…
A donation platform has no security testers of its own. It contracts an external supplier to perform the security testing of each quarterly release. The supplier's staff have no accounts in the platform's issue tracker, no access to the architecture wiki and no visibility of the internal security risk analysis; they receive a URL, a scope statement and a test window of five working days. The platform's test manager must decide how to adjust the security test process to this arrangement. Which adjustment addresses the organisational situation most directly?
Agree before the engagement which artefacts and accesses the supplier receives, including the risk analysis and threat model, and define how their findings are transferred into the platform's own risk handling and retesting
Correct. The two things outsourcing changes are the supplier's information position and the route their findings take back into the organisation, and both have to be arranged explicitly.
Keep the supplier deliberately without internal information, so that their findings reflect what an outside attacker could achieve unaided, and treat that uninformed external view as the complete security test approach for each quarterly release
An uninformed external view has its uses, but adopting it as the whole approach leaves the internally known highest risks untargeted and gives up grey-box and white-box coverage.
Extend the test window from five to ten working days, so that the supplier has time to rediscover by testing the information that the internal team already holds in its risk analysis
More time partly offsets missing information, but paying the supplier to rediscover known facts is inefficient and still leaves the findings without a route into internal risk handling.
Require the supplier to test only the public donation pages, since the internal services cannot be described to a party outside the organisation
Narrowing the scope to what needs no explanation leaves the internal services untested and turns an information-sharing question into a scoping limit.
Have the supplier deliver the report straight to the board, so the findings get attention without passing through engineering
Escalating a report changes who reads it, not whether the findings are actionable or how they enter the risk register.
Outsourcing the testing to a party that is outside the organisation changes what the testers can know and reach. The process therefore has to define, before the engagement, which artefacts and accesses the supplier is granted, and how their findings flow back into the platform's own risk handling. Without that, the supplier is forced into a purely external view and the findings never reach the internal risk register.
A city services portal, operated by the municipality and used for parking…
A city services portal, operated by the municipality and used for parking permits, library accounts and waste-collection bookings, is reviewed after its edge network intrusion detection system raised an unusual alert pattern. Between 09:20 and 10:00 on a Tuesday the NIDS recorded roughly 980 DNS query events attempting to resolve names such as vpn, mail-old, staging, backup and admin under the municipality's domain, together with about 575 probes whose packet characteristics match a known operating-system fingerprinting signature. All of these events originate from one source range, 203.0.113.0/24. Baseline traffic from every other source stays flat throughout. No authentication attempt, no data transfer and no service outage is recorded in the same window.
The security test lead analyses the scenario. Which two conclusions are justified? (Choose two.)
This is the active phase of information gathering: unlike passive collection from public sources, the attacker sends traffic to the municipality's own systems, which is precisely why it appears in the NIDS log at all
Correct. DNS enumeration and OS fingerprinting interact with the target, so they are detectable; passive gathering from search engines, social media and public records leaves no trace on the target side.
The testing response is to establish what this reconnaissance would find: which hosts under the domain are actually resolvable and reachable, including forgotten and non-production ones, and how much platform and version information the exposed services reveal
Correct. The observed activity is mapping the attack surface, so the tests should measure the same attack surface from the same position.
Since no authentication attempt and no data transfer appear in the same window, the pattern is best explained as a misconfigured internal monitoring job that resolves stale host names, and the reasonable response is to correct that job rather than to derive any security tests from the observation
The absence of an attack step is expected during reconnaissance and is not evidence of a benign cause. The traffic arrives from a single external range and matches a fingerprinting signature, which a monitoring job would not produce.
The activity is passive information gathering, because the portal's own data was not read and the municipality suffered no measurable loss during the whole window, and the passive and active categories are distinguished by the harm that results
Incorrect. The two categories are separated by whether the attacker interacts with the target, not by the damage done, and sending DNS queries and fingerprinting probes to the municipality's own systems is interaction.
The 40-minute concentration of events indicates a denial-of-service attempt against the portal's name resolution, so availability tests deserve the priority here
The volumes involved are small and the record shows no outage; the queries enumerate names rather than exhaust the resolver.
Because the source range is known, the test response is to confirm that 203.0.113.0/24 is blocked at the edge and to close the analysis
Blocking one range addresses the observed source, not what the reconnaissance revealed; the exposed attack surface stays unmeasured.
DNS enumeration and OS fingerprinting are active reconnaissance: the attacker sends traffic to the target's own systems and therefore leaves traces in the target's logs, unlike passive information gathering from public sources, which produces no such traces. Because the activity maps the reachable names and platforms rather than attacking them, the reasonable test response is to verify what that mapping would reveal, namely forgotten or non-production hosts under the domain and the exposure of platform and version information.
An online marketplace for game items has been unavailable four times in seven…
An online marketplace for game items has been unavailable four times in seven weeks. Each incident follows the same shape. The item-trade and in-game currency services are flooded from a large, changing set of consumer broadband addresses spread over many countries; the flood begins between 19:40 and 20:10 local time, which is the marketplace's daily traffic peak, and it stops after 50 to 70 minutes. No account is compromised, no item or currency balance is altered, nothing is exfiltrated, and no message demanding payment is received before, during or after any of the four incidents. Comparing the dates with the market, the security analyst notes that each incident falls on a day when a competing marketplace launched a discount campaign, and that no incident occurred on any other day. The analyst has to characterise the likely nature of the attack and derive what to test. Which two conclusions are best supported? (Choose two.)
The absence of any ransom demand and of any theft, combined with timing on the competitor's campaign days at the traffic peak, points to a denial-of-service attack motivated by commercial damage rather than by direct financial gain from the marketplace
Correct. The motivation has to be inferred from what the attacker does and does not do: no extortion, no data theft, but maximum revenue loss at a moment that benefits a competitor.
Tests should reproduce this profile against the trade and currency endpoints, verifying how the platform behaves and degrades under a distributed flood at peak load, and whether the detection and protective measures react to it in time
Correct. The derived tests target the availability of the specific endpoints attacked, under the load profile observed, and cover the effectiveness of the countermeasures.
The absence of a ransom demand shows the flood is a side effect of legitimate demand spilling over from the competitor's campaign, so the response belongs to capacity planning rather than to security testing, and the effort is better spent on autoscaling the two services
Legitimate demand would not arrive as a flood from a changing set of unrelated consumer addresses against two specific endpoints, nor stop abruptly after about an hour.
The wide geographic spread of consumer broadband addresses points to an insider operating from inside the marketplace's own network, who uses employee credentials to generate the traffic from a changing set of rented relay hosts located abroad
Incorrect. An insider abuses access already granted inside the perimeter, whereas the observed traffic arrives from a large external population of consumer addresses and authenticates with no credentials at all.
Because nothing was stolen or altered, the incidents concern availability alone and therefore sit outside the scope of security testing, which deals with confidentiality and integrity
Availability is a security property in its own right, and denial-of-service scenarios sit squarely within the scope of security testing.
The repetition on four occasions indicates an unskilled attacker running a downloaded tool, so the testing effort belongs on published weaknesses of the software
The timing aligns with the daily peak and with a competitor's campaign days, which indicates deliberate target selection rather than opportunistic tool use.
The pattern points to an availability attack whose purpose is commercial: there is no extortion demand and no theft, but the outages land precisely when they cost the marketplace the most revenue and divert players to a competitor's campaign. Distribution across many consumer addresses is characteristic of a botnet used to generate the flood. The testing that follows should measure the platform's behaviour under exactly that load, at peak, and check that protective and detection measures act on the affected endpoints.
Chapter 6 · Adjusting Security Testing to Software Development Lifecycle Models — 4 questions
An agritech company moves its platform development to a DevOps model and adopts DevSecOps practices. What is the main effect of this on the security testing?
Security test activities are shifted earlier and embedded in the delivery pipeline, so that security feedback arrives with each change rather than in a phase before release
Correct. Shift-left and pipeline integration are the defining effects of a DevOps or DevSecOps model on security testing.
Security testing becomes the responsibility of the operations team, since it is operations that runs the delivery pipeline and the production environment in which the platform is exposed
DevSecOps spreads responsibility for security across development, security and operations together rather than handing it to one of the three.
Only automated security tests remain in scope, because each pipeline stage has to finish within minutes and leaves no room for the manual analysis, threat modelling or exploratory security testing done before
Incorrect. Threat modelling, manual analysis and penetration testing stay necessary under DevSecOps; they are planned alongside the pipeline rather than executed inside every run.
The security test process is unchanged, because a lifecycle model settles the release cadence and not the content of the security tests
The lifecycle model changes when, how often and by whom security test activities are carried out, so the process does change.
In a DevOps model security testing is shifted left and embedded in the delivery pipeline, so that security feedback arrives with every change instead of in a phase at the end. Activities that cannot be automated are still needed, but they are planned around the continuous flow.
A university has run its student portal in production for six years without functional changes in the last nine months. Why does security testing still have to continue during operations and maintenance?
New weaknesses become known in the components and platforms the portal relies on, and the environment and its configuration change, so an unchanged system can still become vulnerable
Correct. Security risk depends on the state of the outside world as much as on the code, so testing continues after release.
The findings produced before release lose their validity once a fixed period has elapsed, so the same test set has to be re-executed on a calendar schedule in order to renew the earlier results
Results do not expire on a schedule. Retesting is driven by changes in the system, its environment or the known threats, not by the age of a report.
Testing in production is the way to obtain realistic data volumes, which is why security testing is deferred to the operations phase
Realistic volumes can be arranged in a test environment, and testing before release is not deferred for that reason.
Operational security testing exists to measure the response times of the portal under authentication load, which cannot be observed before the portal goes live
This describes a performance concern. It is not the reason security testing continues during operations and maintenance.
The threat landscape changes independently of the software. New weaknesses become publicly known in the components and platforms in use, and the environment and configuration drift, so a system that has not changed can nevertheless become vulnerable and needs continued security testing.
A ride-hailing platform has been in production for four years. A third-party…
A ride-hailing platform has been in production for four years. A third-party image-processing library, used to accept and transform the driver documents and vehicle photos that riders and drivers upload, is upgraded from version 2.4 to version 3.1 to remove a publicly known weakness in its handling of malformed files. The library's own release notes state that the new major version also tightens metadata parsing, changes the default maximum decoded image size, and replaces the loader used for one of the supported formats. Nothing else in the release changes. The test lead has to determine the security regression test set. What should it contain?
Confirmation tests for the specific weakness, plus regression tests over the upload and transformation paths for every supported format, malformed and oversized inputs against the new decoded-size default, and the surrounding validation, size-limit and error-handling behaviour
Correct. It separates confirmation of the fix from regression coverage of the security-relevant behaviour the new major version could have altered.
Confirmation tests for the specific weakness only, because the platform's own application code was not modified in this release, and an upgrade confined to a third-party dependency therefore leaves the observable behaviour of the uploading and transformation services exactly as it was before
The behaviour that matters is the platform's behaviour, and a new major version of a library it depends on alters that behaviour even when the application code is untouched.
The complete security test set of the platform, including the payment, matching and trip-ledger services, so that no area is left unverified after a change to a dependency that is shared by the whole product and all of its services
Incorrect. Re-running the entire set ignores the analysis of what this change can reach, and it spends the available window on services the image library does not touch instead of on the altered upload paths.
Regression tests over the driver and rider registration workflows, verifying that documents can still be uploaded and displayed and that no upload is rejected after the upgrade
This is functional regression of the happy path. It shows the feature still works but exercises none of the security-relevant behaviour the new version changed.
A software composition analysis run over the dependency tree, confirming that version 3.1 is installed and that no component with a known weakness remains
This verifies which version is deployed, which is inventory evidence rather than a test of how the platform now behaves on malformed or oversized uploads.
Confirmation testing shows the specific weakness is gone. Security regression testing must then cover the security-relevant behaviour that the change could have disturbed: the upload and transformation paths for every supported format, including the format whose loader was replaced, malformed and oversized inputs against the new size default, and the checks that surround the library, such as file-type validation, size limits and error handling, which may behave differently now.
A connected-car supplier develops the telematics software of a vehicle platform…
A connected-car supplier develops the telematics software of a vehicle platform in two-week iterations. Each iteration produces a potentially releasable increment, and the team demonstrates it on a bench vehicle. Software reaching real vehicles, however, is released only once a quarter, through a regulatory approval window: the candidate build is frozen six weeks before the window, submitted to a type-approval process, and only then distributed over the air. In practice, therefore, an increment finished in iteration 1 reaches vehicles about four months later, while iterations 2 to 6 continue to build on it. The test manager analyses how this gap between iteration cadence and release cadence affects security test planning. Which analysis is correct?
Security testing must run inside each iteration and be repeated as a planned re-assessment of the frozen candidate during the freeze-to-release interval, because weaknesses becoming known in that interval cannot be absorbed by the frozen build and the next ordinary release is a quarter away, so an explicit route for post-freeze findings is required
Correct. It identifies both cadences as necessary and locates the risk precisely in the interval where the build is fixed but the threat landscape is not.
Because vehicles receive software only once a quarter, the security testing should be planned as a single campaign carried out in the weeks before each type-approval submission, which spares the team from repeating the same tests six times per quarter and concentrates the scarce specialist effort at the point where the release decision is actually taken
Concentrating security testing at the end removes the early feedback that makes weaknesses cheap to fix, and five iterations of work would be built on an unverified increment.
The gap is a documentation matter: the security test reports of the six iterations have to be consolidated into the evidence package for the type-approval submission, and the planning of the security testing itself needs no change beyond reserving team effort for that consolidation in each iteration
Incorrect. Assembling the evidence is a necessary submission activity, but it reports on testing already done and does nothing about the weaknesses that become known while the candidate build is frozen.
Since each iteration already produces a potentially releasable increment, the security test approach can match that of a continuously deployed service: the same pipeline tests run every two weeks, the approval window is treated as an administrative step that follows the testing, and any weakness found after the freeze is simply carried into the backlog of the iteration that is running at the time
Incorrect. A continuously deployed service can ship a correction within hours, whereas here a correction waits for the next quarterly window, so deferring a post-freeze finding to the running iteration leaves vehicles exposed for months.
The principal risk is that the bench vehicle differs from the production vehicles in sensors and network configuration, so the planning should concentrate on acquiring representative vehicles for each iteration demonstration and for the approval run
Incorrect. Representativeness of the test environment is a genuine concern in its own right, but it is unrelated to the gap between the iteration cadence and the release cadence that this analysis is about.
The iteration cadence and the release cadence serve different purposes here. Security testing inside each iteration keeps the increment verifiable while it is cheap to change, but the security-relevant state of the world moves during the four months to release: new weaknesses become publicly known in the included third-party components and in the platform, and the frozen candidate cannot absorb them. The principal risk therefore lies in the freeze-to-release interval, which needs its own planned re-assessment and a defined route for handling a weakness discovered after the freeze, since the next ordinary opportunity is a quarter away.
Chapter 7 · Security Testing as Part of an Information Security Management System — 4 questions
How do the acceptance criteria agreed for security testing influence the work of the security test team?
They state what has to be demonstrated and to what degree, which determines the approaches and techniques capable of producing that evidence and forms the basis for the exit criteria
Correct. Acceptance criteria drive the selection of approach and technique, because a criterion is only useful if some technique can show it is met.
They fix the number of security test cases to be executed for each release, so that test progress against the agreed plan can be reported to the stakeholders as a percentage of the agreed total
Counting executed test cases is a progress metric. An acceptance criterion expresses a required property of the test object rather than a quantity of tests.
They determine who signs the security test report, since acceptance is a formal decision taken outside the test team
Who accepts is a question of roles and authority. The criteria themselves describe what acceptance requires.
They apply to the acceptance test level alone, so they shape the final test level and leave the levels executed before it unaffected
Agreed criteria for security testing shape the approach across the test levels, since evidence for them is gathered well before acceptance testing.
Acceptance criteria state what has to be demonstrated and to what degree before the object is considered acceptable. That determines which test approaches and techniques can supply the required evidence, and it forms the basis of the exit criteria.
A ride-hailing company operates an information security management system (ISMS). What do the results of its security testing contribute to that ISMS?
Measured evidence of which risks are actually present and how effective the implemented controls are, so that security risks can be managed on facts rather than on assumptions
Correct. The ISMS manages risk continuously, and test results are the empirical input that keeps its risk picture accurate.
The definition of the ISMS scope, since the systems that have been subjected to security testing are by that fact the systems the management system is understood to cover and to protect
The ISMS scope is set by management on the basis of assets and obligations; it is not derived from whatever happened to be tested.
The evidence needed to close the ISMS certification audit and satisfy the external assessor, after which the results have served their purpose and can be archived with the audit file
Incorrect. Audit evidence is one legitimate use of the results, but an ISMS runs a continuing risk-management cycle, so treating the results as spent once the certificate is issued discards their main contribution.
The security policy text itself, because each finding is written up as a new clause and added to the ISMS document set
Findings can motivate policy changes, but they are not policy text, and turning each finding into a clause is not how results feed an ISMS.
Security test results give the ISMS factual, measured evidence about which risks are actually present and how effective the implemented controls are, so that the security risks can be managed actively rather than on the basis of assumptions.
An agritech company wants its ISMS to measure the contribution of security testing. Which two of the following are useful measures for that purpose? (Choose two.)
The proportion of identified security risks for which security tests exist and have been executed
Correct. This links testing to the ISMS risk register and exposes risks that nothing is verifying.
The time taken between the identification of a vulnerability and its confirmed closure, per severity
Correct. It measures how long the organisation remains exposed, which is a genuine attribute of its security posture.
The number of security test cases written per iteration
This counts output volume. A large number of test cases can still leave the significant risks uncovered.
The number of hours that the whole test team spent on security testing during the reporting period
Incorrect. Hours spent describe what the testing cost the organisation, not which risks are covered or how exposed the company still is, so the ISMS learns nothing about its posture from the figure.
The number of different security testing tools in operation across the development teams and the environments they cover
Tool count describes the tool landscape. A wider set of tools does not imply better coverage of the risks that matter.
Useful ISMS measures describe how well risks are covered and how quickly identified weaknesses are dealt with, because both statements say something about the security posture. Measures of test-team activity volume, or of effort spent, describe work performed rather than security achieved.
A university has run an ISMS for three years. Every quarter, the same automated…
A university has run an ISMS for three years. Every quarter, the same automated scan of the same 12 student-facing web applications is executed, the same report template is filled in, and the report is filed with the ISMS. The findings are almost identical each quarter, the risk register has not been amended since the second quarter of the first year, and no risk has ever been re-rated or closed on the basis of a test result. Reports are formally delivered on time. The test manager is asked to raise the maturity of the ISMS specifically by introducing new testing approaches. Which proposal does that?
Add threat modelling of the 12 applications and introduce techniques the scan cannot perform, such as testing of authorization logic and of abuse of the business processes, then feed those findings into a re-rating of the risk register
Correct. These are different approaches, not merely more of the same, and they generate the new information the ISMS needs in order to re-assess its risks.
Extend the same automated scan to the 30 remaining internal applications and to the staff portal, so that the ISMS risk picture covers the whole application landscape of the university instead of only the student-facing part of it that is scanned today
This adds test objects and improves coverage, which is worthwhile, but it is the same approach applied more widely rather than a new approach.
Increase the frequency of the scan from quarterly to monthly, so that the ISMS receives results three times as often and can react to a finding well within the same quarter rather than after it
Incorrect. Running an unchanged scan more often shortens the delay before a known finding is reported, but the scan still returns the same findings, so the ISMS gains no information it was missing.
Replace the report template with an ISMS dashboard showing finding counts per application and per quarter as a trend line that management can read at a glance
Incorrect. A dashboard changes how the same findings are presented; the underlying results and the stale risk picture behind them are untouched, and no new testing approach is introduced.
Require the head of each faculty to countersign the quarterly report, so the findings are formally acknowledged
Adding a signature step strengthens formal accountability without adding any new testing, which is what was asked for.
Maturity can be raised through new test objects, better coverage, or new test approaches. Here the request is specifically for new approaches: adding threat modelling of the applications and techniques the current scan cannot perform, such as testing of authorization logic and business-process abuse, produces findings the repeated scan structurally cannot produce, and therefore new information that forces the risk register to be revisited.
Chapter 8 · Reporting Security Test Results — 3 questions
Why does the criticality of security test results affect how those results are handled and communicated?
A finding usually describes a weakness that is also present in production, so the report is exploitable information and its distribution and tracking have to be controlled
Correct. The report is a description of how to attack the live system, which is why access to it is restricted.
Security findings are reported without technical detail, so that no reader of the report is able to reproduce from it the problem that the finding describes against the running system
The people who have to fix and retest a finding need the technical detail. The answer is controlled access, not the removal of the detail.
Security findings are recorded outside the defect management process, because a weakness is not a defect and is not assigned to a developer
Security findings are managed as defects, in a protected tracker; they are assigned, fixed and retested like other defects.
The criticality decides the language of the report: critical findings for a technical audience, minor ones for management
Reports are tailored to their audience regardless of criticality; severity does not decide which audience a finding is written for.
A security finding usually describes a weakness that also exists in the running production system, so the report is itself exploitable information. Distribution therefore has to be controlled, and the tracking of such findings kept protected, until the weakness has been closed.
On a real-estate platform, a scan of the landlord portal returns one finding…
On a real-estate platform, a scan of the landlord portal returns one finding with no severity value and no impact statement, only this description: the endpoint that returns a listing's document bundle accepts a document identifier supplied by the caller and does not verify that the identifier belongs to a listing owned by the requesting landlord. The test engineer must evaluate the result and determine the technical impact before the finding is reported. Which action produces that determination?
Exercise the endpoint with an ordinary landlord account against identifiers of another landlord's listings, establish what is returned and whether the same route also permits changes, and state the impact in terms of the assets reached
Correct. The technical impact follows from what the weakness actually yields in this system, which has to be established by exercising it and examining the result.
Look up the severity rating that is published for this class of weakness in a public catalogue and record that rating as the technical impact of the finding, so that the report carries a value that is recognised and comparable across teams
A generic rating for a class of weakness ignores what this endpoint returns and which assets it exposes, which is exactly what the impact statement has to express.
Re-run the scan with the deepest configuration profile the tool offers and with authenticated credentials for a landlord account, so that the tool itself supplies the severity and impact fields that are missing from this finding and the report can be built from its output
Incorrect. A deeper authenticated scan may surface further items, yet the fields are missing because the tool cannot judge what the documents behind the endpoint are worth, and another scan does not change that.
Inspect the source of the endpoint to confirm that the ownership check is genuinely absent rather than bypassed elsewhere, and report that missing check as the technical impact of the finding
Incorrect. Reading the code establishes the cause of the weakness, while the technical impact is what an attacker obtains through it, which the code on its own does not reveal.
Ask the landlord-portal product owner how damaging unauthorised access to document bundles would be for the business, and record that assessment as the impact statement
Incorrect. The product owner supplies a business impact judgement that is useful for prioritisation, but it still rests on an unestablished technical picture of what is actually reachable.
Determining the technical impact means establishing what an attacker can actually achieve through the weakness in this system. That requires exercising it: retrieving documents of another landlord's listing with an ordinary account, then examining what those documents contain and whether the same route also permits changes, so the impact can be stated in terms of the assets reached.
An agritech platform has a confirmed weakness in the field-device management…
An agritech platform has a confirmed weakness in the field-device management service: a diagnostic endpoint returns the full configuration of any sensor, including its access token, to any authenticated user of the platform. Two options are on the table. Option A changes the reverse proxy configuration so that the diagnostic path is no longer routed from the internet; the endpoint itself is untouched and still answers requests received from inside the cluster, and any component or service that can reach the service directly still obtains the tokens. Option B changes the service code so that the endpoint verifies that the caller administers the sensor concerned, and removes the token from the response body altogether. The team must choose and must justify the choice in terms of vulnerability closure. What is the correct assessment?
Option A hides the vulnerability, because the weakness persists and stays exploitable from any position that reaches the service; Option B removes it. A may serve as a temporary mitigation, and the finding stays open until B is delivered
Correct. It distinguishes hiding a vulnerability from removing it and assigns the configuration change its proper role as an interim measure.
Both options close the vulnerability, so Option A should be chosen because it can be deployed without a code change, without a new release of the field-device management service and without the regression testing that a code change would require
Only Option B removes the weakness. Treating a routing change as equivalent closure is exactly the confusion between hiding and removing that the assessment has to avoid.
Option A is the stronger measure, because a change at the reverse proxy protects every endpoint of the service at once, whereas Option B addresses only the one endpoint that was found
Breadth at the perimeter does not compensate for leaving the weakness in place; the tokens remain retrievable by anything inside the cluster.
Neither option closes the vulnerability, since the sensor tokens have already been exposed and closure requires rotating the token of every field device
Token rotation is a necessary incident response step, but it does not stop the endpoint from exposing the new tokens the same way; Option B does address the weakness.
Option B is unnecessary once Option A is applied and the diagnostic path is monitored, because any attempt to reach the endpoint is then investigated
Detection tells the operator an attempt occurred; it does not prevent an internal caller from obtaining the tokens, so the weakness is still there.
Option A hides the vulnerability: the weakness remains in the product and stays exploitable from any position that reaches the service, so the closure depends entirely on an external configuration remaining as it is. Option B removes the vulnerability by eliminating the cause. A is acceptable only as a temporary mitigation while B is implemented, and the finding stays open until B is in place.
Chapter 9 · Security Testing Tools — 3 questions
Within the usual categorisation of security testing tools, how is interactive application security testing (IAST) characterised?
It instruments the application and observes its internals while the running application is exercised, combining internal visibility with dynamic execution
Correct. Internal instrumentation plus observation during execution is what distinguishes IAST from static and from purely black-box dynamic tools.
It analyses the source code of the application without executing it and reports the code locations that match the rule set of insecure coding patterns it carries
That describes static application security testing. IAST needs the application to run.
It sends crafted requests to a deployed application from outside and judges the responses it receives, without needing any access to the application's code or runtime internals
Incorrect. This is dynamic application security testing in its black-box form; IAST is distinguished precisely by the internal visibility that this description rules out.
It resolves the dependency tree of the build and matches the components against known weaknesses
That describes software composition analysis, which examines the components used rather than the behaviour of the running application.
IAST instruments the application and observes it from the inside while it is being exercised. It therefore combines internal visibility with dynamic execution, which places it between the purely static and purely black-box dynamic categories.
A municipal library is selecting a security testing tool for its city-services portal. Which consideration is specific to security testing tools and should therefore weigh in the decision?
How frequently the supplier updates the tool's detection content, since the known weaknesses and attack techniques it has to recognise change continuously
Correct. A security tool whose detection content is stale reports against yesterday's threat landscape, which makes update cadence a primary criterion.
Whether the tool can also detect memory leaks and other resource-management defects, so that a single tool serves both the security testing and the general testing of the portal
General-purpose defect detection is not what a security testing tool is selected for, and breadth of that kind does not improve its security coverage.
Whether the tool's user interface is available in the languages spoken by the portal's residents
Interface localisation matters for the portal itself, not for a tool used internally by the test team.
Whether the tool stores its findings in the database product the portal already uses, so no new technology arrives
Uniform infrastructure is a general procurement preference and says nothing about the tool's ability to find security weaknesses.
The value of a security testing tool depends on how current its detection content is, because the threats and known weaknesses it must recognise change continuously. How frequently the supplier updates that content, and whether updates will keep coming, is therefore a central selection criterion.
A connected-car supplier must security test a telematics control unit it bought…
A connected-car supplier must security test a telematics control unit it bought from a subcontractor. The subcontractor delivers the signed firmware binary and an interface description, but contractually withholds the source code and the build. The unit exposes a diagnostic protocol over the vehicle bus and a cellular data channel, and the supplier's own requirement is to observe how the unit behaves while it is running, including when it receives input it was not designed for. Which two tool categories fit this situation? (Choose two.)
Fuzzing tools, to submit malformed and unexpected messages to the diagnostic protocol and the cellular channel of the running unit
Correct. Fuzzing needs only an interface and a running target, and it directly serves the requirement to observe behaviour on input the unit was not designed for.
Dynamic analysis tools, to exercise the unit through its exposed interfaces while it runs and observe its behaviour and responses
Correct. Dynamic tools work against the deployed, running object without needing its source, which matches both constraints.
Static application security testing tools, to examine the unit's source code against a rule set of insecure coding patterns
The source code is contractually withheld, so a source-based static tool has nothing to analyse.
Software composition analysis tools, to resolve the unit's dependency tree from its build manifests and match the components against known weaknesses
Composition analysis of this kind relies on build manifests or lock files from the build, which the subcontractor does not provide.
Interactive application security testing tools, to instrument the unit's code and report weaknesses observed from inside it while it runs
Instrumentation requires the ability to build or modify the application. The firmware is delivered signed and closed, so it cannot be instrumented.
Without source code and without a build, source-based static analysis is not applicable. What remains are dynamic, black-box or grey-box categories: fuzzing tools to submit malformed and unexpected input to the diagnostic protocol and the data channel, and dynamic analysis tools that exercise the running unit through its exposed interfaces and observe its behaviour and responses.