EDR in Monitor Mode, an EOL Line, and a Windows 7 Instrument
A 150-person manufacturer runs Windows 10 and 11 laptops, a few Macs, and an EDR agent that has been in 'monitor only' mode for six months because the previous administrator feared false positives blocking production tooling. Forty machines remain on Windows 10 21H2 because an update broke a line-of-business application last year. In the quality lab, a Windows 7 PC runs instrument-control software; the vendor's supported upgrade costs $18,000 and the lab says the instrument is booked solid for six months. Staff move measurement files to that lab PC using USB drives. On Tuesday the EDR console shows, from a finance workstation, powershell.exe with an encoded command spawned by WINWORD.EXE, followed by an outbound connection to an external IP on port 443. No one has opened the console in three weeks.
1. Triage the alert and decide whether to switch EDR from monitor to block now, mid-alert. Argue both sides and give a decision.
Read the worked answer
Case against flipping to block now: mid-incident configuration change is unplanned change. If the rule set is broad, you may block the finance team's macros and the production line's scripts during the same hour you are trying to contain, and you will not be able to tell a new block from malware breakage.
Case for: Office spawning an encoded PowerShell command followed by an outbound 443 connection is a high-fidelity chain. Waiting means the next host gets the same free pass.
Decision: enable prevention for this behaviour class only, not a global block mode. Specifically: Office child-process spawning, encoded or hidden PowerShell, and script interpreters writing to startup locations. Document the change, its timestamp, and the rule IDs in the incident ticket, and notify the app owners of the affected production tooling before enabling.
In parallel, and in this order:
- Network-contain the finance workstation via EDR rather than powering it off - you keep remote access and volatile state.
- Capture memory and the encoded command string, and decode it; it usually reveals the download URL and staging path.
- Block the external IP/domain at the edge and hunt the IOC across all 150 endpoints in the console - a three-week gap in console review means dwell time is unknown, not zero.
- Reset the user's credentials and revoke sessions, then rebuild the host rather than clean it.
2. The $18,000 upgrade for the Windows 7 lab PC is not funded. Propose a containment architecture and name the residual risk that remains.
Read the worked answer
Accept that the OS cannot be fixed and shrink everything around it.
- Network: dedicated VLAN with no internet route, no inbound from user VLANs, and outbound ACLs limited to the one file share and the instrument's own subnet. Deny everything else, both directions.
- Identity: remove it from the domain if the instrument software allows; otherwise restrict logon rights to a single dedicated local/domain account and deny interactive logon to everyone else. Never let a domain admin credential touch it.
- Host: application allowlisting (AppLocker or vendor equivalent) with a written publisher/path ruleset, host firewall on, full-disk encryption, screensaver lock, and an agent that forwards logs to the SIEM since the OS itself reports little.
- Data path: the USB drive is the real transport. Permit only allowlisted device IDs on that one PC, and route files through a scanning drop folder instead of ad hoc sticks.
- Recovery: scheduled image snapshots so a rebuild takes 20 minutes, plus a tested restore.
Residual risk to record: unpatched remote code execution vulnerabilities remain; allowlisting and ACLs limit blast radius but do not stop a determined attacker with local access, and the integrity of measurement data cannot be guaranteed if the host is compromised. That is a business decision with a named owner and a review date, not a technical one.
3. Design a USB control that keeps the lab working with negligible budget and minimal risk of blocking legitimate work.
Read the worked answer
Do not start with 'block all USB' - the lab will route around it with someone's personal laptop and you lose visibility entirely.
Layered approach:
- Block USB mass storage by class on all endpoints except designated ones, via Group Policy or the EDR's device control. Keyboards and mice keep working; that distinction prevents most of the support complaints.
- Allowlist by device ID for the lab's own encrypted drives. Buying two or three managed, hardware-encrypted sticks is cheaper than any incident and removes the 'we had no choice' argument.
- Create one scanning drop point - a share or a hardened kiosk PC with current anti-malware where files are written and scanned before use on the Windows 7 machine. The lab's workflow becomes copy to share, scan, then pull from the instrument PC over the restricted path.
- Log every USB insertion event centrally and alert on unknown device IDs, so a bypass attempt is visible rather than silent.
Rollout order: publish the two approved sticks and the drop point first, then enable blocking a week later. Measure blocked-device events per week for the first month - a spike is a workflow gap, not defiance, and should be closed with a process fix rather than an exception.