MP.L2-3.8.7Removeable Media
Control the use of removable media on system components.
[a]
the use of removable media on system components is controlled.
Removable storage denied by default; two documented workflows get an allow-list
Implementation
AO coverage. Addresses the Removable Media objective: the use of removable media on system components is controlled.
Default deny. Mass storage class devices are blocked on all managed endpoints. Human interface devices, cameras, and printers are unaffected, so the policy does not break the mouse — the most common reason a blanket USB block gets rolled back. Optical writers are disabled except on the one designated burner host. On the Linux lab hosts, the equivalent is a device manager rule that refuses to create nodes for mass storage devices outside the allow-list.
The two allowed workflows. First, the large-file customer transfer, which uses organization-issued hardware-encrypted drives allow-listed by device identifier and permitted only for members of the enclave roster. Second, the OT cell's firmware and calibration transfers, which use asset-tagged transfer drives that only mount on the scanning kiosk and the target controllers. Both workflows are written down, including who may perform them and what gets logged.
Allow-listing method. Exceptions are granted to specific device instance identifiers, not to a vendor or product class, so buying the same model at a retail store does not produce a working drive. Read-only allow-listing is used where the workflow only needs to ingest, which covers most of the OT cases.
Visibility. Every mount, allowed or blocked, is logged to the endpoint platform and forwarded to the log platform. Blocked attempts are reviewed weekly — mostly they are people charging phones, but the pattern of a specific user repeatedly trying is worth a conversation. File copy events to allowed media are logged with the file names.
Exceptions. Temporary exceptions require a ticket with a business reason, an approver, and an expiry no longer than 30 days; expiry is enforced by the policy, not by someone remembering.
Maintenance. Quarterly review of the allow-list against the issued media inventory to remove retired drives; verification after each endpoint platform major update that the policy still applies, since defaults have changed on us before.
Accepted gap. A vendor-supplied laptop used for one calibration procedure is outside our management and can therefore mount whatever it likes. It never connects to the network, is used under escort, and the controller it services holds no CUI.
What the evidence looks like
- Device control policy export showing default deny and the allow-listed device identifiers
- Linux device manager rule set for the lab hosts
- Weekly blocked-attempt review notes
- Exception register with expiry dates and the enforcing configuration
- Written procedures for the two permitted workflows
Environment
Tools
Was this example useful?
Quick reaction — no account needed. For reasoning that moves the community meter, cast a full verdict below.
Discussion(0)
No discussion on this example yet
Verdicts capture a conclusion. Use a thread when the interesting part is the argument.
Sign in to start a thread.