Security Assessment and Testing

Domain 612% of the exam
Case study & learning material · 5 questions · 5 scenarios
Domain Overview

Domain 6 is how you find out whether controls work: vulnerability assessment, penetration testing, code testing, log review, audits, and the metrics that tell management what the results mean.

The domain case study
Background for the domain as a whole. The practice questions are not set in it — each one carries its own scenario, printed above the question.

Case Study: The "Unchecked Validator" Logic Bomb

Context

FinCorp rushed a mobile check deposit feature for its ATM app to beat a competitor to market. Three weeks behind schedule, the VP of Engineering waived the security gate review and promised to fix anything found afterwards. The feature let a user type the check amount by hand.

What went wrong

A researcher entered a negative amount. The balance logic subtracted the deposit as written: balance minus negative one hundred is balance plus one hundred. Money appeared from nothing.

Four things had to fail for that to ship. Functional testing covered the happy path and no edge cases, so nobody typed a minus sign. No static analysis ran, and a SAST tool would have flagged the unvalidated integer. The vulnerability scanner was running, but the new application server's IP range had been dropped from the scan scope during a firewall change. No penetration test was commissioned, and a tester with ten minutes and a sense of what a deposit should never do would have found it.

The ATM industry has its own business-logic flaw, and the white paper documents it under transaction reversal fraud. The criminal times a card-reader fault so the host reverses a withdrawal whose cash has already been staged, then forces the shutter. It works because the host's reversal logic trusts the wrong signal. No scanner finds that; it takes someone who understands the transaction state machine and tests it on purpose. The negative deposit is the same class of defect on the deposit side.

The 5 scenarios in this domain

One organization each, three to six questions apiece in the printed examination. Nothing here gives an answer away — the scenario is what the question hands you before it asks.

FinCorp: the second report

FinCorp's mobile check deposit accepted a negative amount and credited the customer, and the story reached the press. Nine days later its security mailbox receives a second report. An independent researcher writes that the same mobile deposit endpoint accepts an amount carrying sixteen decimal places, and that the balance service rounds it in the customer's favor. She has not published, gives a ninety-day deadline, and asks for a named contact. FinCorp has no vulnerability disclosure policy, no bug bounty, and no stated position on researchers who test its live application. The VP of Engineering who waived the pre-release security review still owns the release schedule. Legal's first draft reply threatens action under the terms of service.

FinCorp · mobile check deposit for ATM customers

A deposit of minus one hundred

FinCorp's mobile check deposit feature passed every functional test before launch: deposits with valid amounts posted correctly on every device. A researcher later added funds to an account by entering a check amount of minus one hundred, which the application accepted. The chief information security officer wants to know why the weekly vulnerability scan, which ran with current plugins against the correct address range, never reported it. The team also wants the missing input-validation check flagged automatically in the build pipeline, before the application is ever deployed to a test server, and wants evidence the board can rank spending against.

FinCorp · mobile check deposit

Scanning what is actually there

A scan of Kingsmere Insurance's database servers, run without credentials from an adjacent network segment, reports only banner-level findings and misses local misconfigurations the database team knows exist. A post-incident review has separately found that a firewall change had removed a new application server's subnet from the scanner's target list, so for months the reports showed the environment clean while that server sat unassessed. The insurer's test lead wants an automated way to discover how a service handles input its developers never anticipated, without writing a case for each one.

Kingsmere Insurance · vulnerability management

Reading the code and reading the logs

Ravenscar Building Society's development manager has instituted a rule that no change to the deposit service merges until a second developer has read the diff line by line, checking input handling and error paths against the secure-coding standard. A regulator has separately asked the society to categorize its weekly review of application logs within a control framework: the review finds fraud patterns after transactions occur and does nothing to stop one completing. Two days after a critical flaw in a remote-access appliance was published with a detection check, a credentialed scan reported the appliance clean.

Ravenscar Building Society · engineering practice

Shifting the work earlier

A post-incident review at Ellesmere Trust found that a defect would have cost minutes to fix at design time, days at code review and millions after launch, and the chief information security officer's recommendation is to shift security work earlier. A junior assessor must separately verify 300 machine images against the hardening standard, confirming services disabled, patches applied and default accounts removed, and produce consistent repeatable evidence for each. Financial auditors want assurance about a payroll provider's effect on the trust's statements, and the certification auditor wants evidence leadership examines results.

Ellesmere Trust · software assurance

Case study debrief· read after you have attempted the questions; it gives several answers away

What a practitioner does differently

The test plan carries negative, boundary and abuse cases, written from the question "what must this feature never do?" Static analysis runs in the build pipeline on every commit. Dynamic testing and a penetration test run against pre-production, with business-logic cases in the scope, not only the OWASP checklist.

Scan scope is tied to the asset inventory through change control, so the firewall change that moved the server also updated the scanner's targets. A gap in scope is a gap in coverage, and the metric that reports "no critical findings" is worthless if it silently excludes the newest system.

The security gate cannot be waived by the person who benefits from waiving it. A waiver is a risk acceptance: it is signed by the risk owner, recorded, time-boxed, and reviewed. And the researcher needs a door: a published disclosure policy so the report lands with security instead of on social media.

Outcome

The researcher reported the flaw through a support address, and FinCorp closed it. The postmortem replaced "fix it in post" with a gate that only the risk owner can defer, and put the application server back in the scanner's scope.

What the exam tests

Expect questions distinguishing assessment, audit and testing; SAST versus DAST versus manual review and what each can and cannot find; penetration-test phases and rules of engagement; misuse-case and negative testing; scan scope and coverage as management metrics; and who is allowed to accept a risk.

Related reading

The firm in this scenario is a composite. The ATM analogue and the controls are documented in: