OPSEC — Seguridad de dispositivos y endpoints

OPSEC — Seguridad de dispositivos y endpoints

Sub-nota atomica del manual maestro manual-paranoid-opsec. Cada capitulo es una nota propia para consulta directa por dominio operativo.

5. Device & Endpoint Security

Goal: Prevent endpoint compromise and leakage of identifiers by hardening platforms, controlling execution, encrypting data, and validating boot trust. Controls are mapped to posture levels (L0–L3) from §3.

5.1 Platform Profiles (When to Use What)

  • Qubes OS — strong compartmentalization via Xen VMs; ideal for L2–L3 where isolation between personas/cases is mandatory. https://www.qubes-os.org/
  • Tails — amnesic, Tor‑routed live OS; ideal for one‑off high‑risk browsing or sensitive transfers (L2–L3). https://tails.boum.org/
  • Whonix — Tor‑gateway + workstation model inside VMs; good for anonymity workflows (L1–L2). https://www.whonix.org/
  • Hardened Linux (Debian/Fedora/Ubuntu) — daily driver with AppArmor/SELinux enforced; suitable for L0–L2.
  • Windows 11 (Hardened) — enable BitLocker, VBS/HVCI, WDAC/ASR; enterprise telemetry minimized; suitable for L0–L2.
  • macOS (Hardened) — FileVault, Gatekeeper, notarization; consider Lockdown Mode on iOS companion devices; suitable for L0–L2.
  • Mobile (GrapheneOS) — hardened Android with strong permission model; use as comms endpoint for L1–L3. https://grapheneos.org/

Mapping tip: If your adversary can compel providers or run device exploits → prefer Qubes/Tails + strict compartmentalization.

5.2 Boot & Firmware Trust

  • UEFI Secure Boot: ON; vendor keys or custom MOK where needed. Linux check: mokutil --sb-state; Windows check: Confirm-SecureBootUEFI.
  • TPM 2.0: present and owned; bind disk encryption to TPM+PIN where feasible.
  • BIOS/UEFI: admin password set; external boot disabled; Thunderbolt security enabled; DMA protection on.
  • Firmware updates: apply via LVFS/fwupd where supported: fwupdmgr get-devices && fwupdmgr get-updates (https://fwupd.org/). Record versions in the case log.

5.3 Storage, Encryption & Secrets

5.4 Application Control & Sandboxing

  • Windows:
    • WDAC (Windows Defender Application Control) policy or AppLocker allowlists for L2–L3.
    • ASR Rules (Attack Surface Reduction): block Office child processes, script abuse, and LSASS credential theft. Enable via PowerShell (see §5.13).
    • Controlled Folder Access for ransomware mitigation.
  • Linux:
  • macOS:
    • Gatekeeper enabled; restrict to App Store + identified developers; leverage TCC prompts; avoid kexts; disable unsigned system extensions.

5.5 Peripherals, USB & Side‑Channels

  • USB:
    • Disable autorun everywhere.
    • Linux: USBGuard (allowlist policy): https://usbguard.github.io/
    • Windows: Group Policy → Device Installation Restrictions (block new device classes except approved).
  • Network radios: disable unused (BT/NFC); randomize Wi‑Fi MAC; avoid auto‑join.
  • HID injection defenses: restrict new keyboards/mice; verify device IDs on connection; prefer data‑only USB cables for charging.

5.6 Updates, Telemetry & Logging

  • Patching: OS and firmware monthly (or faster for L2–L3); browser daily.
  • Telemetry: reduce to minimum compatible with security; avoid 3rd‑party analytics in investigative compartments.
  • Logging: capture local security logs needed for audits, but export to an encrypted vault separate from operational compartments. Do not transmit logs to external cloud SIEMs from sensitive personas without de‑identification policies.

5.7 Backup & Recovery (3‑2‑1)

5.8 Mobile Endpoints

  • Device policy: separate phones for personal vs. operational personas; prefer GrapheneOS for Android; iOS use Lockdown Mode where threat justifies.
  • Baseband risk: assume cellular radio is observable; avoid sensitive ops on mobile networks; prefer wired or trusted Wi‑Fi via VPN/Tor.
  • Permissions: deny default access to mic/camera/location; use hardware camera shutters and mic mute switches when available.

5.9 Golden Images & Reproducibility

  • Maintain golden VM templates per posture level (L0–L3).
  • Provision ephemeral linked clones per case/persona; destroy after operation.
  • Automate hardening with Ansible (Linux) or PowerShell DSC/Intune (Windows) to keep builds consistent and auditable.

5.10 EDR/AV Considerations (Trade‑offs)

  • Windows Defender with ASR + cloud protection on is acceptable for many L0–L1 use cases; for L2–L3 consider stricter WDAC and reduced telemetry profiles.
  • Linux/macOS: lightweight AV (ClamAV) as needed; rely on sandboxing and least‑privilege.
  • Avoid vendor agents that introduce identifiable telemetry into sensitive compartments.

5.11 Validation Checklists & Commands

Boot & encryption status

  • Linux:
    • Secure Boot: mokutil --sb-state • TPM: tpm2_getcap properties-fixed
    • LUKS volumes: lsblk -f then cryptsetup status <mapper>
  • Windows PowerShell:
    • Secure Boot: Confirm-SecureBootUEFI
    • BitLocker: Get-BitLockerVolume | Select MountPoint,VolumeStatus,EncryptionMethod
    • VBS/HVCI: Get-CimInstance -ClassName Win32_DeviceGuard | Select *
  • macOS:
    • FileVault: fdesetup status • Gatekeeper: spctl --status

Sample hardening commands (Windows, run as Admin)

# Enable key ASR rules (example subset)
$rules = @(
  "D4F940AB-401B-4EFC-AADC-AD5F3C50688A", # Block Office child processes
  "3B576869-A4EC-4529-8536-B80A7769E899", # Block credential stealing from LSASS
  "5BEB7EFE-FD9A-4556-801D-275E5FFC04CC", # Block execution of potentially obfuscated scripts
  "BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550"  # Block executable content from email and webmail
)
Add-MpPreference -AttackSurfaceReductionRules_Ids $rules -AttackSurfaceReductionRules_Actions Enabled

# Turn on Controlled Folder Access
Set-MpPreference -EnableControlledFolderAccess Enabled

# Check BitLocker status
Get-BitLockerVolume | Format-Table -AutoSize

Sample hardening commands (Linux)

# AppArmor enforcing
sudo aa-status || sudo aa-enforce /etc/apparmor.d/*

# Verify Secure Boot and firmware updates
mokutil --sb-state
fwupdmgr get-devices && fwupdmgr get-updates

# Create and mount a LUKS2 container
sudo dd if=/dev/zero of=secure.img bs=1M count=4096
sudo cryptsetup luksFormat --type luks2 --pbkdf argon2id secure.img
sudo cryptsetup open secure.img securevault
sudo mkfs.ext4 /dev/mapper/securevault && sudo mount /dev/mapper/securevault /mnt

5.12 Posture Mapping (L0–L3) — Key Endpoint Controls

Posture OS/Env Boot Trust Encryption Exec Control Network/Browser Notes
L0 Hardened Linux/Win/macOS Secure Boot on FDE on Basic AV, no unsigned installs VPN, hardened browser Routine OSINT
L1 Hardened Linux/Win/macOS Secure Boot + TPM FDE + vaults ASR/AppArmor enforcing VPN/Tor; anti‑leak checks Separate persona VM
L2 Qubes/Whonix/Tails Secure Boot strict FDE + offline backups WDAC/AppLocker; SELinux enforcing Tor‑first; kill‑switch Air‑gapped evidence
L3 Qubes + Tails Custom keys, measured boot FDE + deniable containers Full allowlist; no dynamic code Tor bridges; no personal devices Dedicated hardware, no reuse

Record all settings (with commands and outputs) in the case log for auditability and repeatability.

🔥 Extreme Practices (Optional)

  • Rely only on disposable devices (burner laptops/phones) that are physically destroyed after the mission.
  • Configure hardware entirely offline with custom firmware (e.g., coreboot, Heads) and your own Secure Boot keys.
  • Never store credentials or keys in RAM – assume adversaries can perform cold boot attacks.
  • Split operations across dedicated machines: one for research, one for communications, one for data analysis.
  • Apply an air-gap-first policy: evidence analysis and archival should only occur on machines with no network interfaces.
  • In extreme contexts: use hardware purchased abroad, operated only locally, never transported across borders.

Themes