Assessing and mitigating vulnerabilities I: clients, servers, databases, distributed systems and industrial control

Sub-domain 3.5 is the longest list in Domain 3: assess and mitigate the vulnerabilities of security architectures, designs and solution elements. It names client-based systems, server-based systems, database systems, cryptographic systems, industrial control systems, cloud-based systems, distributed systems, the internet of things, microservices, containerization, serverless, embedded systems, high-performance computing, edge and fog computing and virtualized systems. This lesson covers the traditional architectures and industrial control; lesson 7 covers cloud and the newer models. For each, the exam expects you to recognize the typical weaknesses and the controls that address them.

Client-based systems

Client systems, such as desktops, laptops, phones and the applications running on them, are where people meet technology, and so they are where many attacks begin. Common weaknesses include unpatched operating systems and applications, browsers and plug-ins that render untrusted content, users with local administrator rights, malicious attachments and macros, insecure local storage of credentials and data, and applets or mobile code downloaded from the internet. Older study materials mention Java applets and ActiveX controls; the modern equivalents are browser extensions, scripts and documents with active content. Clients also cache data, which matters when a device is lost or stolen.

Controls include automated patching, removing local administrator rights, application allow-listing, endpoint detection and response, browser isolation for risky sites, disabling macros from the internet by default, full-disk encryption and mobile device management that can wipe a lost phone. Because clients run untrusted content constantly, sandboxing, which runs code in a restricted environment that limits what it can touch, is central to modern browsers and document readers.

Server-based systems

Servers provide services to many clients, so a single compromise can affect many users at once. Server weaknesses include unnecessary services and open ports, default or shared administrator accounts, missing patches, weak configuration of web servers and application frameworks, and data flow control problems, where traffic is not filtered or validated as it moves between tiers. Hardening guides, such as the CIS Benchmarks or vendor security baselines, list settings to remove these weaknesses. Good practice also runs each service with a dedicated least-privilege account, separates tiers so that a web server cannot reach the database directly except through the application, logs administrative actions centrally and applies configuration management so that drift from the baseline is detected.

Database systems

Databases concentrate valuable data and so attract attackers. Beyond the usual concerns of access control, patching and encryption, the exam focuses on three database-specific problems. Aggregation occurs when individually harmless pieces of information combine into something sensitive, such as many unclassified facts that together reveal a classified operation. Inference occurs when a user deduces sensitive information they are not authorized to see from data they can see, for example working out an individual's salary by comparing averages before and after that person joined a small department. Controls for both include restricting query results, refusing queries that would return very small groups, adding noise to statistics and, for classified systems, careful labelling of combined data.

Polyinstantiation is a technique used in multilevel secure databases. Several versions of the same record can exist at different classification levels, so that a low-level user sees a plausible cover entry rather than learning that a classified record exists. For example, an Unclassified user querying a ship's destination might see a training cruise, while a Secret user sees the real mission. Polyinstantiation prevents inference through the absence of data. Other database controls include views that show users only certain columns or rows, stored procedures that enforce well-formed transactions in the Clark-Wilson sense, separation of the database administrator role from security administration, transaction logs and the ACID properties, atomicity, consistency, isolation and durability, which protect integrity when many users update data at once.

Injection remains one of the most damaging database attacks. When an application builds a query by joining user input into a command string, an attacker can submit input that changes the meaning of the command. Parameterized queries and prepared statements, which send data separately from the command, prevent this; input validation and least-privilege database accounts limit the damage if a flaw remains.

Distributed systems

Distributed systems spread processing across many computers that cooperate over a network, from client-server applications to peer-to-peer networks and grid computing. Their weaknesses come from the network itself and from the difficulty of keeping trust consistent across many nodes. Messages can be intercepted, replayed or altered; nodes can be impersonated; and a compromised node may be trusted by the others. Controls include mutual authentication between nodes, encryption and integrity protection of all traffic, replay protection with timestamps or sequence numbers, consistent identity and access management, and monitoring that correlates events across nodes. Distributed ledgers, or blockchains, are a special case that achieve agreement among nodes that do not trust each other through consensus mechanisms and cryptographic chaining of blocks, which makes recorded transactions very hard to alter but does nothing to make the data they record true.

Cryptographic systems

Cryptography fails far more often through implementation and management than through broken mathematics. Common weaknesses include obsolete algorithms such as DES, RC4, MD5 or SHA-1, keys that are too short, poor random number generation, hard-coded keys in source code or firmware, failure to validate certificates, reusing a nonce or initialization vector, and keys that are never rotated. Lessons 8 to 10 cover cryptography in depth, including attacks and post-quantum migration. For now, remember that a cryptographic system is a whole: algorithms, protocols, implementation, keys, people and processes.

Industrial control systems and operational technology

Industrial control systems, or ICS, run physical processes in power grids, water treatment, pipelines, factories and building systems. They are part of operational technology, OT, as opposed to information technology. Key components include supervisory control and data acquisition, or SCADA, systems that monitor and control widely spread assets such as pipelines; distributed control systems, which control processes within a single plant; programmable logic controllers, or PLCs, which execute control logic on the factory floor; remote terminal units; and human-machine interfaces through which operators watch and control the process.

OT security differs from IT security in important ways. Safety and availability come first, because a failed control system can injure people or damage equipment; confidentiality is often the lowest priority. Equipment lasts decades, so many systems run unsupported operating systems and cannot be patched without long planned outages. Protocols such as Modbus and DNP3 were designed for closed networks and often lack authentication. Real incidents show the stakes: Stuxnet damaged uranium enrichment centrifuges in Iran around 2010, attacks on Ukraine's power grid in 2015 and 2016 cut electricity to hundreds of thousands of people, and the TRITON malware discovered in 2017 targeted safety instrumented systems designed to prevent explosions.

The reference architecture for segmenting industrial networks is often called the Purdue model, which divides the environment into levels from the physical process at level 0 through controllers, supervisory systems and site operations to the enterprise IT network at levels 4 and 5, with an industrial demilitarized zone between OT and IT. The ISA/IEC 62443 series of standards builds on this with zones and conduits, security levels and requirements for asset owners, integrators and product suppliers. Typical controls include strict segmentation and data diodes that allow information to flow only outward, passive monitoring that does not disturb sensitive devices, careful remote access through jump hosts with multifactor authentication, asset inventories, compensating controls where patching is impossible, and close cooperation between IT security and plant engineers.

Thinking like a manager

When a scenario involves a database revealing sensitive facts through combinations or statistics, think aggregation and inference, and controls such as minimum group sizes or polyinstantiation. When it involves industrial systems, remember that safety and availability come first: the right answer is rarely to patch immediately or scan aggressively, and more often to segment, monitor and plan maintenance windows. For clients and servers, hardening, least privilege and patching are the usual first steps.

Prioritizing vulnerability remediation across platforms

A large organization may face thousands of findings across laptops, servers, databases and plant systems at any time, so remediation must be prioritized rather than worked in the order found. Severity scores such as CVSS describe technical impact, but they ignore context. Better programmes combine severity with exposure, asking whether the system faces the internet or sits deep inside a segmented zone; with exploitation evidence, such as inclusion in the Known Exploited Vulnerabilities catalogue or an EPSS probability; and with business criticality, drawn from the asset inventory. An internet-facing server with a known exploited flaw comes before a critical-scored issue on an isolated test machine. Industrial systems add a further constraint: patches may need vendor approval and a planned outage, so compensating controls such as tighter segmentation, allow-listing and monitoring often protect the asset until the next maintenance window. Every deferred fix should have an owner, a due date and documented acceptance of the residual risk, so that exceptions do not quietly become permanent. Metrics such as mean time to remediate by severity and the number of overdue exceptions show management whether the programme is working.