Other Infrastructure Flashcards

Two positions exist: on-premises is safer (direct control) vs. cloud is safer (provider's expertise). Neither is universally correct — both have distinct advantages. Cloud: no hardware to secure, third party handles infrastructure security, centralized alongside other services, fast changes via API. On-premises: complete control, full data sovereignty, no multi-tenancy risk, local team can act immediately. The key fact the exam tests: from an attacker's perspective, the location of data is irrelevant — they target it regardless. Controls matter; location does not. Data governance and access management are always the customer's responsibility in either model.

A unified console (typically a SIEM + management platform) that aggregates security visibility from all environments — cloud, on-premises, SaaS — into one interface. Benefits: correlated alerts (cross-source attack patterns visible), consolidated log analysis (one query spans all systems), unified patching (missing patches visible regardless of system location). The tradeoff: single point of failure — if the console goes down, visibility across the entire environment is lost simultaneously. As the organization grows, the centralized system must scale to handle increasing log and alert volume.

Bottom-to-top: Infrastructure (physical hardware) → Hypervisor (VMware ESXi, Hyper-V, KVM — manages resource allocation between VMs) → Guest OS (full operating system per VM) → Applications. Each VM has its own complete OS, providing strong isolation — a compromised VM does not automatically affect neighboring VMs. The cost: OS overhead duplicated for every VM. The maximum security risk: VM escape — a vulnerability that allows a process to break out of the guest OS to the hypervisor or other VMs. A hypervisor vulnerability affects all VMs on that host.

Bottom-to-top: Infrastructure (physical hardware) → Host OS (single OS shared by all containers) → Container Engine (Docker — manages container lifecycle and isolation via Linux namespaces/cgroups) → Containers (application + dependencies; no OS — shares host kernel). Benefits over VMs: no OS overhead, millisecond startup, lightweight and portable. Key security difference: all containers share the host OS kernel — a host kernel vulnerability is a shared vulnerability across all containers. Container escape to the host OS affects all tenants on that host.

IoT devices (smart thermostats, video doorbells, sensors, wearables, facility automation) are designed by domain specialists — not security engineers. They routinely ship with: weak default credentials (admin/admin, hardcoded passwords), no automatic firmware updates, unencrypted communications, and unnecessary open services. A single compromised IoT device gives an attacker a network foothold — from which lateral movement to corporate systems is possible. Primary control: dedicated IoT VLAN with ACLs blocking all access to corporate systems. Treat every IoT device as an untrusted network endpoint regardless of its function.

SCADA (Supervisory Control and Data Acquisition) / ICS (Industrial Control System) monitors and controls physical industrial processes — power generation, oil and gas, water treatment, manufacturing. Operators view real-time equipment status and issue control commands from a central control room across all sites. Critical security distinction: a cyberattack on SCADA is not a data breach — it causes physical equipment destruction, safety incidents, or disruption of critical public services (power, water, fuel). This is why SCADA requires the most rigorous segmentation: physical air gap from corporate IT, no direct internet, all remote access through hardened jump servers with full logging.

A deterministic OS that guarantees task completion within exact time constraints — regardless of other system activity. Unlike Windows/Linux (non-deterministic schedulers), an RTOS cannot deprioritize a critical task. Use cases: automotive ABS/airbags, industrial robot controllers, medical devices (pacemakers, insulin pumps), military guidance systems. Security constraint: traditional security tools (antivirus, EDR agents) introduce timing latency incompatible with real-time guarantees — they cannot be deployed on RTOS devices. Security is implemented through isolation (no general-purpose network access, physical protection) and compensating controls at the network boundary, not at the device itself.

Purpose-built devices where hardware and software are designed together for exactly one function. No general-purpose OS interface, no app store, cannot load arbitrary software. Examples: traffic light controllers, digital watches, MRI/CT scanners, industrial sensors and actuators. Security challenges: (1) Long lifecycles (10–20 years) — firmware may be unpatched for years; (2) Limited/no update mechanism — some require physical access with specialized tools to update; (3) No monitoring — no logs, no SIEM visibility; (4) Minimal hardware — no CPU/memory capacity for security software. Primary control: network isolation + compensating controls at the network boundary.

These are distinct concepts that are frequently confused. Redundancy: a spare system available if the primary fails — but it may require manual intervention to bring online. A cold spare in storage is redundant but not highly available. High Availability (HA): continuous operation with automatic failover — the system remains accessible even during a component failure. Two HA modes: Active/Passive — primary handles traffic; standby synchronizes and takes over automatically in seconds. Active/Active — both systems handle traffic simultaneously; failure of one is absorbed by the other with zero interruption, and both nodes must each be capable of handling full load. Higher HA = higher cost.

Active/Passive: One primary system handles all traffic; a passive standby continuously synchronizes with the primary and takes over automatically when the primary fails. Failover time: seconds. Brief disruption possible during switchover. The standby is not serving traffic in normal operation — unused capacity. Active/Active: Both systems are active, sharing the traffic load. If one fails, the other continues handling all traffic — no switchover, no interruption. Also provides scalability: two systems handling load = higher combined capacity. Cost: both nodes must each be sized to handle full load independently (so neither fails under full load after the other fails). Active/Active is more expensive but provides zero-downtime failover.