Table 1 — Nine Hardening Targets: Key Controls at a Glance
| Target | Primary Risk | Key Hardening Controls | Management Tool |
|---|---|---|---|
| Mobile devices | Always-connected; personal/corporate data mixed | Updates, data segmentation, strong authentication | MDM |
| Workstations | User-facing; phishing/malware entry point | OS/app/firmware patches, remove unused software, policy management | Active Directory Group Policy |
| Network infrastructure | Backbone compromise; embedded OS, default credentials | Change defaults, configure authentication, apply firmware patches | Vendor management console + TACACS+/RADIUS |
| Cloud infrastructure | Broad blast radius from admin account compromise | Secure management workstation, least privilege, EDR, C2C backup | Cloud-native policy (AWS Config, Azure Policy) |
| Servers | Holds critical data; lateral movement target | OS patches/service packs, strong accounts, limit network access, EDR/AV | Patch management + Group Policy / MDM |
| SCADA / ICS | Physical consequences; critical infrastructure | Air-gap / extensive segmentation, no internet access | Isolated control network |
| Embedded systems | Hard to update; purpose-built firmware | Apply patches when available, segment + firewall | Network-level containment |
| RTOS | Timing disruption; safety-critical processes | Isolate from all networks, minimum services, host-based firewall | Physical isolation + host firewall |
| IoT | Weak defaults; manufacturer not security-focused | Change default credentials, patch quickly, segment to own VLAN | VLAN + firewall rules |
Table 2 — Update Frequency and Urgency by Target
| Target | Update Frequency | Urgency Level | Notes |
|---|---|---|---|
| Mobile devices | Frequent (monthly or more) | High | Unpatched mobiles directly exposed on untrusted networks |
| Workstations | Monthly (Patch Tuesday cycle) | High | Test in pilot group before broad deployment |
| Network infrastructure | Rare (when vendor releases) | Very high when released | Infrequent releases mean each one addresses something significant |
| Cloud infrastructure | Varies (platform-managed vs. self-managed) | High | Cloud workstation and connected endpoints need fastest cycle |
| Servers | Monthly + service packs | High (with change control) | Server reboots have operational impact; test before deploying |
| SCADA / ICS | Rare; change-controlled | Carefully evaluated | Updates require extensive testing due to safety criticality |
| Embedded systems | Rare | High when released | If vendor bothered to release a patch, it addresses something serious |
| RTOS | Very rare | High when released | Any change to RTOS must not affect deterministic timing |
| IoT | Infrequent; often manual | High — deploy quickly | Known CVEs widely published; every unpatched device is an open target |
Table 3 — Segmentation Strategies by Target
| Target | Segmentation Approach | Why |
|---|---|---|
| Mobile (corporate data) | Work profile / managed container separates corporate from personal data | Prevents malware in personal apps from accessing corporate resources |
| Servers | Firewall rules limit which systems can reach each server | Limits lateral movement paths after initial compromise |
| SCADA / ICS | Air-gap or completely isolated network; no internet access | Physical process control — compromise has physical safety consequences |
| Embedded systems | Dedicated network segment + firewall in front | Limits reach of unpatched embedded devices; contains compromise |
| RTOS | Physical network isolation from all general networks | General network traffic disrupts deterministic timing; safety criticality |
| IoT | Dedicated VLAN separated from corporate systems | Weak device security — contain blast radius to IoT segment only |
Table 4 — Cloud Hardening: Four Pillars
| Pillar | What It Means | Why It Matters |
|---|---|---|
| Secure cloud management workstation | Harden, EDR-protect, and restrict access to the machine used to administer cloud resources | Compromise of this workstation = access to entire cloud environment ("keys to the kingdom") |
| Least privilege | Every service, account, and application has only the permissions its function requires — nothing more | Misconfigured cloud permissions are the most common cloud security incident; least privilege limits blast radius |
| EDR on cloud-connected devices | All endpoints accessing cloud management must have behavioral threat detection | Detects endpoint compromise before attacker pivots to cloud; signature-only AV is insufficient |
| Cloud-to-Cloud (C2C) backup | Replicate cloud data to a different provider or region under separate credentials | Outage, accidental deletion, or ransomware at primary provider does not affect backup stored elsewhere |
Table 5 — SCADA/ICS vs. Standard IT: Key Differences
| Dimension | Standard IT Systems | SCADA / ICS |
|---|---|---|
| Primary consequence of compromise | Data breach, service disruption | Physical damage, safety hazards, critical infrastructure failure |
| Network connectivity | Internet-connected; broad network access | Air-gapped or isolated; no internet access |
| Update cycle | Monthly patches; relatively straightforward | Rare updates; extensive safety testing required before any change |
| Availability priority | Balanced with confidentiality and integrity | Availability is paramount — downtime can stop physical processes |
| Hardening approach | Patches, configuration management, EDR | Physical isolation, segmentation, change-controlled updates |
| Who manages it | IT security team | OT (Operational Technology) team, often separate from IT |
Table 6 — IoT Risk Profile and Controls
| IoT Risk Factor | Why It Exists | Hardening Control |
|---|---|---|
| Weak default credentials | Manufacturers prioritize ease of setup; same default on every unit; documented publicly | Change all default credentials immediately at deployment |
| Infrequent security patches | Manufacturer is HVAC/lighting engineer, not security vendor; no long-term patch support | Apply available patches immediately; prioritize IoT patching above other devices |
| Open network services | Default config exposes services for convenience; vendor doesn't consider attack vectors | Disable unused services; segment to VLAN with restrictive firewall rules |
| Unencrypted communications | Low-power devices; no TLS/encryption by default in many devices | Network-level controls; VLAN isolation limits exposure of unencrypted traffic |
| No EDR/AV capability | Limited hardware; no OS with endpoint security support | Compensating controls: network monitoring, VLAN isolation, firewall logging |