WBP SI common mistakes
WBP SI · Understand the traps and how to avoid them.
Treating the scope and rules-of-engagement brief as background reading and then including out-of-scope hosts, URLs, or accounts in the findings.
Candidates assume the scenario's target list is illustrative and want to show thoroughness by finding 'more'; the exam instead tests disciplined scoping and authorization boundaries.
What to do instead
Before answering any engagement question, extract the authorized hosts, IP ranges, credentials, and time window into a short written scope list, then test each proposed action against it; explicitly flag out-of-scope items as excluded rather than scanning or reporting them.
Describing the methodology as a tool menu ('run Nmap, then Burp, then Nikto') instead of a phased process with objective, inputs, outputs, and decision points for each phase.
Hands-on habits lead candidates to equate methodology with tooling, and the exam rewards process reasoning such as reconnaissance, enumeration, validation, and reporting gates.
What to do instead
Answer with phase-based structure: state the phase objective, the evidence it produces, the exit criterion, and how results feed the next phase; mention tools only as examples of how a phase is executed.
Reporting an asset inventory built only from a single discovery sweep, missing shadow IT, cloud-hosted instances, and assets reachable only through alternate protocols or credential-based enumeration.
A single scan feels complete, and candidates do not consider NAT, segmentation, ephemeral cloud instances, or unauthenticated versus authenticated views of the estate.
What to do instead
Combine passive sources (DNS, certificate transparency, cloud APIs, CMDB, DHCP/ARP data) with active sweeps from multiple network vantage points, and reconcile discrepancies between the inventory and discovered hosts as a finding.
Marking a configuration check as 'pass' because the setting appears in a config file, without verifying the running effective state or whether the control is enforced elsewhere.
Candidates equate presence of a directive with effectiveness and skip validation of runtime behavior, defaults, inheritance, and override precedence.
What to do instead
For each hardening item, define the observable proof of the effective state (runtime query, service response, policy evaluation) and record both the configured value and the verified value; treat unverifiable items as 'not tested' rather than pass.
Presenting scanner output as confirmed vulnerabilities without manual verification, including false positives from version banners or generic signatures.
Automated results look authoritative and time pressure discourages manual checks, but the exam distinguishes identification from verification with reproducible evidence.
What to do instead
For each candidate finding, perform a targeted proof: replay the request or check, capture the exact request/response or command output, confirm exploitability preconditions, and downgrade or discard anything you cannot reproduce.
Testing web applications only through the browser UI and missing authorization flaws, parameter tampering, and server-side behavior exposed by direct request manipulation.
Browser-driven testing hides headers, tokens, and API calls, so candidates never exercise object-level access control or input handling outside rendered forms.
What to do instead
Intercept traffic with a proxy, enumerate endpoints and parameters from JavaScript and API specs, and test horizontal and vertical access control by replaying requests with swapped identifiers and lower-privilege sessions.
Treating logging review as 'logs exist' rather than evaluating whether the required events are generated, forwarded, retained, and alerted on.
Candidates conflate log collection with detection and do not trace a specific attack action end-to-end through the logging pipeline.
What to do instead
Pick concrete adversary actions (failed logins, privilege change, data export), then verify each produces a log entry with needed fields, arrives in the central store within the expected time, and triggers a documented detection or alert.
Altering original evidence, such as editing a log file in place or re-running a destructive test on the only copy, and then reporting from the modified source.
Candidates focus on getting the answer and overlook that investigative integrity depends on preserving originals and documenting every handling step.
What to do instead
Capture evidence first (hash the original, store it read-only, work from copies), maintain a chain-of-custody record with timestamps and handlers, and cite hashes and collection method alongside each finding.
Writing findings that state a technical fact without impact, affected asset, evidence reference, or severity rationale, leaving the reader unable to act.
Candidates compress reports to save time and assume the reader shares their context, but exam reporting criteria reward business-relevant impact and traceable evidence.
What to do instead
Use a fixed finding template: title, affected asset, observation, evidence pointer, business and technical impact, severity with justification, and remediation; review each finding to confirm a non-technical reader could prioritize it.
Closing remediation items on the basis of a vendor statement or a promised fix date rather than retesting and recording verified closure evidence.
Candidates treat remediation tracking as status administration and accept attestations, which fails the requirement for validated, evidence-backed closure and exception handling.
What to do instead
Define closure criteria per finding, retest the original proof of concept, attach the retest evidence and date, and route unresolved or accepted-risk items through a documented exception with owner and expiry.