A transit engagement finds both Linux and Windows local privilege escalations. How should reporting best help different system owners?
Select an answer to reveal the explanation.
Short Explanation
Linux and Windows teams fix different things with different playbooks. Split the write-ups so each owner sees their root causes and fixes—not one blurry 'you got owned' paragraph.
Full Explanation
When a transit engagement finds both Linux and Windows local privilege escalations, reporting should separate OS families with root-cause classes and owner-appropriate remediations so Linux and Windows system owners can act without decoding a merged blob.
Merging all LPE items into one generic 'get admin' finding loses actionable context. Reporting only Windows issues because Linux owners supposedly never read reports abandons half the estate. Listing every kernel symbol without remediation guidance is noise, not delivery.
Exam caveat: shared themes (credential hygiene) can be cross-referenced while keeping OS-specific technical detail clear.
Operational check: structure findings by platform, map each to owners, and include distinct fix guidance for transit Linux and Windows teams in the remediation roadmap. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services. Re-validate after the next maintenance window that the same finding class still applies under the estate's current patch and configuration baseline. In municipal operations, record the rationale in the engagement notes so future assessors know which control was chosen and which failure modes the rejected options would create for city services.