3.5 Architecture & Technology Vulnerabilities
3.5 Architecture & Technology Vulnerabilities
Every architecture introduces assumptions, dependencies and trust boundaries.
Security architects must understand how different technologies can fail, how those failures affect the wider system and which controls can reduce the resulting risk.
Understand
Identify components, dependencies, interfaces and trust boundaries.
KNOW THE ARCHITECTUREAssess
Determine how the architecture could be compromised or fail.
KNOW THE WEAKNESSMitigate
Apply controls that reduce likelihood, impact and blast radius.
REDUCE THE RISKThe Big Idea
A technology is not secure or insecure simply because of its name.
Security depends on:
Architecture Assessment Memory Aid
Components · Boundaries · Interfaces · Dependencies · Failure
Architectures You Need to Understand
Endpoints, browsers, applications and user devices.
Shared services and central processing infrastructure.
Structured information and data-management platforms.
Algorithms, keys and cryptographic implementations.
Systems controlling physical processes.
SaaS, PaaS and IaaS architectures.
Multiple interconnected components operating together.
Connected physical devices and associated services.
Loosely coupled services communicating through interfaces.
OS-level workload isolation and application packaging.
Provider-managed execution triggered by events.
Special-purpose computing integrated into devices.
Highly parallel and powerful computational environments.
Processing positioned closer to users, devices or data sources.
Multiple logical systems sharing physical resources.
Common Architectural Vulnerabilities
Different technologies have different attack surfaces, but many weaknesses appear repeatedly.
Secure technology can become insecure through poor configuration.
Users, applications and services receive more authority than required.
Known vulnerabilities remain exploitable.
APIs, management ports and other interfaces become attack paths.
Components trust each other based only on network location or architecture.
Compromise of one shared dependency affects multiple workloads.
One component failure causes widespread loss of service.
Systems begin operation with unnecessary exposure.
Attacks may occur without adequate evidence for detection.
Hardware, software, libraries and services depend on external suppliers.
Inappropriate algorithms, implementations or key management undermine protection.
Large numbers of components and dependencies make security harder to understand and maintain.
Every additional interface, dependency and trust relationship creates something that must be understood, configured, monitored and protected.
💻 Client-Based Systems The attacker is often interacting directly with the endpoint
Client systems include user workstations, laptops, browsers, mobile devices and locally installed applications.
They frequently process sensitive information while operating in environments the organisation cannot completely control.
Typical Vulnerabilities
Malicious code may execute with the user's privileges.
Sensitive information may remain in files, caches, temporary storage or browser data.
Users operating as local administrators increase potential impact.
Mobile users may connect through networks outside organisational control.
Laptops and mobile devices can be stolen or lost.
Browsers process active content from many external sources.
Mitigations
Architecture should limit what one compromised endpoint can access and how far an attacker can move afterwards.
🖥️ Server-Based Systems Central services concentrate value and dependency
Servers often host applications, authentication services, databases, business processes and shared infrastructure.
This makes them attractive targets and important availability dependencies.
Typical Vulnerabilities
Additional services increase attack surface.
Vulnerable operating-system or application components remain exploitable.
Server administrators often possess powerful access.
Management interfaces can become high-value attack paths.
A critical service running on one server may create unnecessary dependency.
Production systems gradually diverge from approved secure baselines.
Mitigations
Server Security
🗄️ Database Systems Large concentrations of valuable information
Databases may hold some of an organisation's most sensitive and valuable information.
Typical Vulnerabilities
Untrusted input may manipulate database queries.
Applications or users receive broader rights than required.
Users bypass controlled application transactions.
Sensitive records or backups may be exposed.
Sensitive queries and changes may not be sufficiently logged.
Users may derive sensitive information from apparently harmless authorised queries.
Multiple low-sensitivity data elements may become highly sensitive when combined.
Database backups can contain complete copies of protected information.
Mitigations
A reporting application needs only:
SELECT
on three reporting tables.
Giving it full database administrator rights creates unnecessary exposure.
Database Risks
🔐 Cryptographic Systems Strong algorithms can still be implemented badly
Cryptographic systems rely on algorithms, protocols, implementations and key-management processes.
Failure in any one of those areas can undermine the protection.
Typical Vulnerabilities
Obsolete or inappropriate algorithms may no longer provide sufficient protection.
Poor key length, randomness or generation reduces security.
Keys stored beside encrypted information may expose the entire system.
Secure algorithms can become vulnerable when implemented incorrectly.
Timing, power, cache or electromagnetic behaviour may reveal useful information.
Secure cryptographic primitives can be combined into an insecure protocol.
A strong cipher does not protect information if an attacker can simply obtain the decryption key.
Cryptographic architecture is covered in much greater depth in:
3.6 Cryptographic Solutions & PKI
🏭 Industrial Control Systems - ICS / OT Cybersecurity can affect physical processes and human safety
Industrial Control Systems and Operational Technology monitor or control physical processes.
Examples include:
A compromised business application may expose information.
A compromised industrial controller may alter a physical process.
Important Priorities
Typical Vulnerabilities
Systems may remain operational for many years.
Updating systems may require production shutdowns or extensive safety testing.
Older industrial protocols may lack modern authentication or encryption.
Connections between corporate and operational networks create attack paths.
Field devices may be physically distributed and difficult to protect.
Security controls cannot be introduced without considering their effect on safe operation.
Mitigations
Do not apply an IT security control to an industrial system without considering operational and safety consequences.
ICS / OT
Cyber compromise can become physical impact.
☁️ Cloud-Based Systems SaaS · PaaS · IaaS and shared responsibility
Cloud computing changes where infrastructure runs, how resources are provisioned and which party is responsible for particular security activities.
Service Models
| Model | Customer generally manages more of... | Provider generally manages more of... |
|---|---|---|
| IaaS | Operating systems, applications, identities, data and many configurations. | Physical infrastructure and virtualisation platform. |
| PaaS | Applications, application configuration, identities and data. | More of the operating platform and underlying infrastructure. |
| SaaS | Users, access, data, tenant configuration and appropriate use. | Application platform and underlying infrastructure. |
Typical Vulnerabilities
Public storage, permissive network rules or insecure tenant settings expose resources.
Powerful cloud identities can control large numbers of resources.
Cloud environments are heavily managed through APIs.
Multi-tenancy creates dependence on provider isolation controls.
Replication and geographic distribution can create legal and governance concerns.
Customers may not have the same low-level visibility available on-premises.
Outages or supplier problems can affect many customer services.
Business units may use cloud services outside approved governance.
Mitigations
The exact boundary differs between SaaS, PaaS and IaaS, but the customer still retains security responsibilities.
Cloud Memory Aid
Provider responsibility grows - customer responsibility never becomes zero.
🌐 Distributed Systems Many components must behave securely as one system
Distributed systems divide processing or data across multiple systems that communicate through networks.
This can improve scalability and resilience, but also increases coordination and trust complexity.
Typical Vulnerabilities
Components rely on network communication and availability.
Systems must know which other components are legitimate.
Multiple copies of information may temporarily disagree.
One component may fail while the rest of the system continues.
Compromise of one trusted node may affect others.
Events must be correlated across many systems.
Mitigations
A distributed application must handle situations where some components remain available while others fail or become unreachable.
📡 Internet of Things - IoT Large numbers of connected devices with physical presence
IoT systems combine connected devices, sensors, software, networks and cloud or backend services.
Typical Vulnerabilities
Devices may ship with weak or shared credentials.
Devices may be difficult or impossible to patch securely.
Devices may remain deployed longer than their software support.
Devices may be placed in homes, factories or public locations.
Small devices may have limited processing, storage or security capabilities.
Sensors may collect significant behavioural or environmental data.
Thousands or millions of devices can create large attack surfaces.
Devices can depend on firmware and components from many suppliers.
Mitigations
Thousands of internet-connected cameras use the same default administrator password.
Compromise of one pattern of device can therefore scale rapidly across a large population.
IoT Risks
🧩 Microservices & APIs Many small services create many trust relationships
Microservices divide an application into smaller independently deployable services.
Those services commonly communicate through APIs.
The architecture must determine how services authenticate, authorise, communicate and fail.
Typical Vulnerabilities
A caller accesses resources or functions they should not be able to use.
One malicious service pretends to be another.
Every new API endpoint may expand the attack surface.
Attackers manipulate or misuse mechanisms used to locate services.
Large numbers of services create complex relationships.
Failure of one service can overload or break dependent services.
API keys, tokens and service credentials require careful protection.
Transactions span multiple services and can be difficult to trace.
Mitigations
Microservices
Small services do not mean a small attack surface.
📦 Containerization Lightweight isolation with a shared host kernel
Containers package an application and its dependencies while relying on operating-system isolation mechanisms.
Unlike traditional virtual machines, containers commonly share the host operating-system kernel.
Typical Vulnerabilities
Container images may contain vulnerable packages or malicious components.
Images may originate from insecure or unauthorised sources.
Privileged containers can weaken isolation from the host.
Kernel vulnerabilities can potentially affect multiple containers.
An attacker may attempt to break out of the container isolation boundary.
Credentials embedded in images can persist through registries and deployment pipelines.
A container orchestration platform can control many workloads.
Short-lived containers can make monitoring and forensic collection more difficult.
Mitigations
Container isolation depends heavily on the security of the underlying container runtime, host operating system and kernel.
Containers
⚡ Serverless Architectures No server management does not mean no security responsibility
In serverless architectures, customers deploy code or functions while the provider manages much of the underlying execution infrastructure.
Functions are commonly triggered by events such as:
Typical Vulnerabilities
One small function may receive broad cloud permissions.
Untrusted event data may reach sensitive processing logic.
Credentials stored in environment variables or code can be exposed.
Functions may rely on many third-party packages.
Compromise of one function may affect downstream functions.
Customers have limited control over underlying execution infrastructure.
Mitigations
Servers still exist.
The important architectural difference is that the cloud provider manages more of the underlying platform.
Serverless
🔧 Embedded Systems Special-purpose computers inside larger products
Embedded systems are computing components integrated into larger devices or products.
Examples include:
Typical Vulnerabilities
Credentials embedded in firmware may be difficult to change.
Low-level software may remain vulnerable for long periods.
Devices may not support secure or automatic patching.
Manufacturing or diagnostic interfaces may remain accessible.
Attackers may gain direct access to hardware.
Limited memory and processing can restrict security functionality.
Mitigations
An embedded product may remain operational for many years after its original development team has moved on.
🚀 High-Performance Computing - HPC Massive computational capability and complex shared infrastructure
High-Performance Computing systems combine large numbers of processors, nodes or accelerators to perform extremely intensive computational workloads.
Typical Vulnerabilities
Many users or research workloads may share powerful resources.
Internal networks may prioritise performance and require specialist security approaches.
Clusters can contain thousands of interconnected nodes.
Administrators and schedulers may control very large amounts of compute capacity.
Systems may process highly valuable scientific or proprietary information.
Security controls must be evaluated for their effect on intensive workloads.
Mitigations
Compromise may provide access not only to valuable information but also to significant computational resources.
📍 Edge Computing Move processing closer to where data is generated or consumed
Edge computing places processing closer to users, sensors, devices or data sources rather than relying entirely on a central data centre or cloud region.
Why Use Edge Computing?
Typical Vulnerabilities
Edge systems may be located outside traditional secure data centres.
Large numbers of remote nodes can be difficult to patch and configure consistently.
Systems may need to remain secure even when disconnected centrally.
Sensitive information may be stored or processed outside the core environment.
The organisation may need confidence that remote hardware has not been tampered with.
Processing is distributed across many locations rather than one central environment.
Mitigations
Edge Computing
🖥️ Virtualized Systems Many logical machines share physical infrastructure
Virtualisation allows multiple virtual machines to run on shared physical hardware.
Typical Vulnerabilities
A compromised hypervisor may undermine isolation between multiple guest systems.
An attacker attempts to move from a guest VM into the hypervisor or host.
Virtual machines can be created rapidly and become difficult to inventory and maintain.
Snapshots may contain sensitive memory, data and credentials.
One workload may consume shared CPU, memory, storage or network resources.
Traffic between VMs on the same host may not traverse traditional physical network controls.
Virtualisation management platforms control large parts of the environment.
Multiple trust domains may share underlying physical resources.
Mitigations
If multiple sensitive workloads rely on its isolation, its trustworthiness becomes critical.
Virtualisation
Compromise the boundary → threaten the guests.
Virtual Machines vs Containers
| Virtual Machine | Container | |
|---|---|---|
| Isolation layer | Hypervisor | Operating-system / container runtime |
| Operating system | Each VM generally runs its own guest OS. | Containers commonly share the host kernel. |
| Typical size | Heavier | Lighter |
| Key security dependency | Hypervisor | Host kernel and container runtime |
| Typical vulnerability concept | VM escape | Container escape |
VM vs Container
VM boundary = Hypervisor · Container boundary = OS / Runtime
Find the Trust Boundaries
Many architecture questions become easier when you identify where trust changes.
Who authenticates whom?
What information crosses the boundary?
Is communication protected?
What happens if one side is compromised?
Concentration & Shared Dependency Risk
Modern architectures gain efficiency by sharing components.
Shared components can also concentrate risk.
| Shared Component | Potential Impact if Compromised |
|---|---|
| Identity Provider | Access to many applications |
| Hypervisor | Multiple virtual machines |
| Container Orchestrator | Large numbers of workloads |
| API Gateway | Many application services |
| Cloud Provider | Multiple customer workloads |
| Shared Database | Multiple applications and datasets |
| Software Library | Every application using the component |
Concentration Risk
A Modern Banking Platform
Consider a modern banking application using multiple architectural technologies.
Potential Vulnerabilities
Stolen credentials, insecure local storage or compromised device.
Broken authentication or authorisation.
Excessive service trust and exposed service credentials.
Vulnerable image or excessive runtime privilege.
Misconfiguration or overly broad cloud identity.
Excessive application privileges or exposed sensitive information.
Security must consider the entire transaction path rather than examining each component in isolation.
🎓 CISSP Scenarios Recognise the architectural vulnerability
Employees have local administrator access on all corporate laptops, and malware executes using those privileges.
Primary architectural issue?
Excessive privilege on client systems.
An application connects to a database using full administrator privileges even though it performs only several predefined queries.
Best mitigation?
Apply least privilege to the application database identity.
A strong encryption algorithm protects backups, but the encryption key is stored in plaintext beside them.
Primary weakness?
Key management.
An industrial control system cannot be patched without shutting down a safety-critical manufacturing process.
Best approach?
Assess operational risk and use appropriate compensating controls until safe remediation is possible.
A cloud storage service containing sensitive information is accidentally configured for public access.
Primary weakness?
Cloud misconfiguration.
One service in a distributed system fails while every other service continues operating.
What architectural condition must be handled?
Partial failure.
Ten thousand internet-connected cameras share the same default administrator password.
Primary IoT weakness?
Shared or default credentials at scale.
Microservice A assumes every request from the internal network comes from a trusted service and performs no service authentication.
Primary architectural weakness?
Implicit trust between services.
A container runs with extensive host privileges and an attacker exploits it.
What security principle should have reduced the risk?
Least privilege and container isolation.
A cloud function has administrator rights over the entire cloud account even though it only needs to read one storage object.
Primary serverless weakness?
Over-privileged function identity.
An embedded medical device contains a diagnostic interface that remains enabled after manufacturing.
Primary concern?
An unnecessary hardware or debug interface expands the attack surface.
A remote edge node is installed in an unattended roadside cabinet.
Which risk becomes especially important?
Physical access and tampering.
An attacker compromises the virtualisation layer supporting ten security-sensitive virtual machines.
Why is this particularly serious?
The hypervisor is a shared security boundary and compromise may affect multiple guests.
Hundreds of unused virtual machines remain running because teams can create them but there is no lifecycle or inventory process.
What is this commonly called?
VM sprawl.
An HPC administrator account controls a large cluster containing highly sensitive research.
What architecture principle is especially important?
Privileged access management and least privilege.
Recognise the Architecture from the Clue
Lost Laptop
Endpoint malware, local storage, local admin.
Client-BasedCentral Shared Service
Hardening, patching, service availability.
Server-BasedInjection / Inference
Structured data and application queries.
DatabaseKeys / Algorithms
Implementation and key-management weaknesses.
Cryptographic SystemSafety / Physical Process
Legacy technology and availability.
ICS / OTShared Responsibility
SaaS, PaaS, IaaS and misconfiguration.
CloudPartial Failure
Multiple networked components.
Distributed SystemMany Small Devices
Weak updates, default credentials and physical exposure.
IoTMany APIs
Service identity and service-to-service trust.
MicroservicesImages / Shared Kernel
Registry, runtime and container escape.
ContainersFunctions / Events
Provider-managed execution and function IAM.
ServerlessFirmware / Hardware
Special-purpose device with long lifecycle.
Embedded SystemMassive Compute
Clusters, schedulers and powerful shared infrastructure.
HPCProcessing Near Device
Distributed physical nodes and local processing.
Edge ComputingHypervisor / VM Escape
Multiple guests sharing hardware.
Virtualisation⚠️ Common CISSP Mistakes Architecture questions are about trade-offs and boundaries
Cloud providers can provide strong security capabilities while the customer can still create insecure configurations.
Responsibility changes depending on the service model but does not disappear.
Containers commonly share the host operating-system kernel.
Virtual machines generally contain independent guest operating systems.
The provider operates the server infrastructure.
Microservices should not rely solely on network location to establish trust.
Availability and human safety can dramatically change security priorities and remediation options.
A small weakness becomes much more significant when deployed across hundreds of thousands of identical devices.
Isolation depends on the security of the hypervisor and surrounding management infrastructure.
Algorithms, implementations, protocols and key management must all be considered.
Distribution can improve resilience but also introduces additional dependencies and partial-failure scenarios.
Quick Architecture Reference
| Architecture | Think About |
|---|---|
| Client | Endpoint compromise, local data, physical loss |
| Server | Hardening, patching, privilege, availability |
| Database | Injection, privilege, inference, aggregation |
| Cryptographic | Algorithms, implementation and key management |
| ICS / OT | Safety, availability, legacy systems |
| Cloud | Shared responsibility, IAM, configuration |
| Distributed | Partial failure and node trust |
| IoT | Scale, updateability, physical exposure |
| Microservices | APIs, service identities, distributed trust |
| Containers | Images, shared kernel, runtime |
| Serverless | Events, function privilege, provider platform |
| Embedded | Firmware, hardware and lifecycle |
| HPC | Scale, shared compute and powerful privileges |
| Edge | Remote nodes, physical security and distributed management |
| Virtualisation | Hypervisor, VM escape and shared hardware |
Architecture Vulnerability Memory Aid
The Architect's Five Questions
Architecture security is largely about boundaries, dependencies and blast radius.
Key Takeaways
Different architectures introduce different security assumptions, dependencies and attack surfaces.
Architecture assessment begins by identifying components, trust boundaries, interfaces and dependencies.
Client systems are particularly exposed to malware, physical loss and untrusted environments.
Server systems concentrate services and privilege and therefore require strong hardening, patching, access control and resilience.
Database architectures require protection against excessive privilege, injection, inference, aggregation and backup exposure.
Cryptographic systems depend not only on strong algorithms but also on sound implementation, protocol design and key management.
ICS and OT environments require security decisions to account for operational availability and human safety.
Cloud security follows a shared-responsibility model, and customer responsibility changes rather than disappears as services move from IaaS toward PaaS and SaaS.
Distributed systems must handle node trust, communication security, consistency and partial failure.
IoT architectures combine large device populations, long lifecycles, physical exposure and sometimes limited security capabilities.
Microservice architectures create many service identities, APIs and dependencies that must be authenticated, authorised and monitored.
Containers commonly share the host kernel, making image security, runtime configuration and host security particularly important.
Serverless platforms remove much infrastructure administration from the customer but do not remove responsibility for code, identities, configuration and information.
Embedded systems require secure firmware, update mechanisms and lifecycle planning.
High-Performance Computing environments combine valuable information with extremely powerful shared computational resources.
Edge computing moves processing closer to devices and users but also expands the physical and distributed attack surface.
Virtualised systems rely heavily on the hypervisor as an isolation boundary between guest systems.
Efficiency through shared components can create concentration risk: compromise of one common dependency may affect many systems at once.
The goal is not simply to identify vulnerabilities. The security architect must understand how a weakness could affect the wider system and select controls that reduce likelihood, impact and blast radius.
📚 Sources & Further Reading Architecture and technology security guidance
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-82 Rev. 3 - Guide to Operational Technology Security
View NIST OT and ICS security guidance - NIST SP 800-190 - Application Container Security Guide
View NIST container security guidance - NIST SP 800-204 - Security Strategies for Microservices-Based Application Systems
View NIST microservices security guidance - NIST SP 800-204A - Building Secure Microservices-Based Applications Using Service-Mesh Architecture
View NIST service-mesh security guidance - NIST IR 8259 Rev. 1 - Foundational Cybersecurity Activities for IoT Product Manufacturers
View current NIST IoT cybersecurity guidance - NIST SP 800-125 - Guide to Security for Full Virtualization Technologies
View NIST virtualization security guidance - NIST IR 8320 - Hardware-Enabled Security for Cloud and Edge Computing Use Cases
View NIST cloud and edge platform security guidance - NIST Cloud Computing Publications
Explore NIST cloud security publications