A civic app tier is compromised; the database tier is segmented. What should the tester assume about DB access?
Select an answer to reveal the explanation.
Short Explanation
Owning the café counter does not mean you already have keys to the locked vault in the back—there might be a real door and a real policy in between. Segmentation can block paths even after an app foothold. Check reachability and scope before assuming the database is yours to poke.
Full Explanation
After a civic app tier is compromised while the database tier is segmented, the tester should confirm routing path and scope before treating the DB tier as reachable and testable. App compromise does not always grant automatic interactive DB access—segmentation and credentials may still block it. Segmentation is not cosmetic to ignore after any foothold; it is often the control under test. Copying production databases to a personal laptop to bypass segmentation violates data handling and likely RoE. Exam caveat: reachability and authorization are separate gates for multi-tier municipal apps. Operational check: map app-to-DB paths, verify DB CIDRs and techniques are in scope, attempt only least-impact authorized validation, and keep any data samples minimized and vaulted. In municipal operations, record the rationale in the engagement notes so future testers and city defenders understand which approach was chosen and which failure modes the rejected options would create for civic services. Re-validate the same judgment after the next change window so the control still holds under the city’s current tooling, identity posture, and RoE amendments. Keep secret material and session artifacts in the approved vaulted workflow rather than chat paste or unprotected tickets used by mixed municipal teams.