Security Architecture and Engineering · Topic 4 of 8
Vulnerabilities of Architectures and Systems
Assessing and mitigating weaknesses in client, server, database, cloud, ICS, IoT, embedded, virtualized, container, serverless, microservice and edge systems.
- 3 min
- Know the characteristic risk of each architecture type.
- Aggregation and inference threaten databases; polyinstantiation and views help.
- ICS, IoT and embedded systems: isolate, change defaults, plan secure updates.
What it is
Every type of system has typical weaknesses. The exam lists many architectures and expects you to know the characteristic risk of each and a sensible mitigation, always from a design and management view rather than a product view.
How it works
Common system types
| System | Typical vulnerabilities | Mitigations |
|---|---|---|
| Client-based | Malware, unpatched software, local data theft | Endpoint protection, patching, disk encryption, least privilege |
| Server-based | Unneeded services, misconfiguration, data flow weaknesses | Hardening baselines, patching, segmentation |
| Database systems | Injection, inference, aggregation, excessive privileges | Parameterized queries, views, least privilege, polyinstantiation |
| Cryptographic systems | Weak algorithms, poor key management, implementation flaws | Approved algorithms, HSMs, key lifecycle management |
| Industrial control systems (ICS, SCADA) | Legacy protocols without authentication, long patch cycles, safety impact | Network isolation, unidirectional gateways, monitoring, strict change control |
| Cloud-based (SaaS, IaaS, PaaS) | Misconfiguration, weak identity controls, shared responsibility gaps | Configuration management, strong identity, logging, clear contracts |
| Distributed systems | Many trust relationships, data in many places | Strong authentication between components, encryption |
| Internet of Things | Default passwords, no updates, weak encryption | Change defaults, separate networks, vendor update commitments |
| Microservices | Many APIs, east-west traffic, service identity | API gateways, mutual TLS, service identity, least privilege |
| Containerization | Vulnerable images, shared kernel, privileged containers | Image scanning, signed images, no privileged containers, orchestration policies |
| Serverless | Over-privileged functions, event injection, dependency risks | Least-privilege roles per function, input validation |
| Embedded systems | Hard-coded credentials, hard-to-patch firmware | Secure boot, signed firmware updates, network isolation |
| High-performance computing | Shared resources, performance traded for security | Isolation between jobs, access control |
| Edge computing | Physically exposed devices, weak connectivity | Tamper resistance, encryption, remote attestation |
| Virtualized systems | VM escape, VM sprawl, hypervisor compromise | Patch hypervisors, limit management access, inventory VMs |
Database-specific concepts
- Aggregation: combining low-sensitivity items creates more sensitive information.
- Inference: deducing sensitive data from accessible data.
- Polyinstantiation: storing different versions of a record at different classification levels to prevent inference.
- Views: restrict which rows and columns a user can see.
- ACID properties (atomicity, consistency, isolation, durability) protect transaction integrity.
Other architecture weaknesses
| Weakness | Meaning |
|---|---|
| Covert channels | Hidden communication paths: storage channels (shared resources) and timing channels (timing of events) |
| Maintenance hooks / backdoors | Undocumented access left by developers |
| Time-of-check to time-of-use (TOCTOU) | Condition changes between check and use |
| Emanations | Signals leaking from equipment; shielding (for example TEMPEST) mitigates |
ICS and medical systems often cannot be patched quickly or rebooted. The best answer usually isolates them and adds monitoring rather than forcing standard IT patch cycles.
Mitigation priorities
Start with inventory and configuration baselines, apply least privilege and segmentation, protect data with encryption, monitor, and plan updates. For anything that cannot be fixed, use compensating controls and record the accepted risk.
How the exam asks about this
- "Several unclassified facts together reveal a classified one." Aggregation.
- "Users deduce salaries from department totals." Inference.
- "A plant's controllers use protocols without authentication." Isolate the control network and monitor it.
What to remember for the exam
- Know the characteristic risk of each architecture type.
- Aggregation and inference threaten databases; polyinstantiation and views help.
- ICS, IoT and embedded systems: isolate, change defaults, plan secure updates.
- Containers and serverless: scan images, least privilege per function or container.
- Covert channels are storage or timing based.
Virtualization adds a new layer to protect. A compromised hypervisor exposes every guest on it.
Common mistakes
Applying office IT patch practices directly to industrial systems.
Confusing aggregation with inference.
Running containers as privileged for convenience.
Check yourself
What is polyinstantiation used for?
Keeping different versions of data at different classification levels to prevent inference.
What are the two kinds of covert channel?
Storage channels and timing channels.
What is the main mitigation for industrial control systems that cannot be patched quickly?
Network isolation with monitoring and strict change control.
Topic 4 of 8 in Security Architecture and Engineering
Test yourself on Security Architecture and Engineering
The full ISC2 CISSP question bank has 1,113 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISC2. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.