Security Architecture and Engineering

1.1 Threat modeling and the secure design mindset

Domain 3 starts from a posture: build security in as early as possible in any design process, preferably at the initiation phase. Designing security "at the design level and not as an afterthought" lets the system run as efficiently as possible without taking unnecessary risks. Conversely, adding security at later stages forces changes to the existing design, hurting performance and driving up costs.

Threat modeling (reviewed in Domain 1.10) has a role in every phase of the life cycle, from requirements analysis down to real-time attack detection and response. It gives a conceptual view of how the target functions by asking two questions: "What needs protection and what does it need protection from?". By breaking the organization into its parts (each business unit having its own standards, systems and technologies, hence its own vulnerabilities), you align possible threats with those elements and identify existing threats faster.

The core idea is to adopt the attacker's mindset. The manual illustrates it: give a new phone to an ordinary user and they think "What can it do?"; give it to a malicious actor and they think "What can I make it do?". Because we naturally test within our own mindset, it is essential to test using other mindsets - malicious ones, but also uninformed ones.

Key for the exam: threat modeling is a form of testing that identifies critical systems and services and reveals where vulnerabilities might exist, but it does NOT fix the problem. The organization must then feed the results into its remediation process. STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) is the reference methodology for categorizing threats during this exercise.

1.2 Least privilege, separation of duties and defense in depth

Least privilege means granting a user the minimum permissions necessary to perform their explicit job function. Mind the trap: it does NOT mean "low permissions". A system administrator needs a privileged account to do their job and gets one; a senior VP, although a trusted individual, does not need a privileged account to do theirs and so does not get one. The criterion is the function, not rank or degree of trust.

Separation of duties (SoD) requires that a single person, process or system cannot complete a sensitive process alone. There must be checks and balances: at least two independent means to verify the authorization of the action and of the actors. The goal is to reduce the chances of corruption and theft. Procurement example: with no SoD, a manager can get a quote, create a purchase order, issue a check and buy a product alone - they can easily exploit trust. With SoD, a purchasing manager signs the purchase order, then only an accountant can issue the check after receiving that signed order. SoD necessarily degrades operational efficiency but enhances security; it is often effective, inexpensive, yet remains underused.

Defense in depth (DiD), introduced by the NSA, is a layered approach to security posture, sometimes called the castle model: the crown jewels sit at the heart of the castle, protected by successive layers (guards, walls, a moat). Adding layers deters attackers and pushes them toward easier targets. The original model defines the layers: Data, Application, Host, Internal network, Perimeter, Physical, and Policies/procedures/awareness (administrative controls against insider threats).

Exam nuance: DiD is sometimes seen as outdated in the era of cloud, BYOD and edge/fog computing, and was historically very prone to insider threats (to the point some say "defense in depth is dead" as too static). As a concept of protecting the most prized assets under layers it remains useful, but must be re-rationalized to cover all control types - administrative, technological and physical.

1.3 Secure defaults, fail securely and keep it simple

Secure defaults (secure by default) means the system's default configuration settings must be the most secure possible, even if this hurts the user experience. Security and user-friendliness are weighed through risk analysis and usability testing, and a balance is required to maintain security requirements while meeting business goals. The professional must advise and insist on secure defaults, whether on the vendor side or the customer side.

Fail securely: a system designed to fail securely (fail-secure) defaults to a secured state if it crashes, reducing potential data exposure and other risks. The fail-secure approach matters for systems with high exposure potential. Caution: human safety must be considered. The manual's example: for fire-evacuation procedures of a sensitive facility, human safety comes first, even at the expense of exposing sensitive data to evacuated personnel. This is the classic fail-secure vs fail-safe trade-off to know for the exam: human life first.

Keep it simple (KISS): security does not have to be complex. Clear, short, direct and easy-to-follow procedures clarify what acceptable behavior is and what is not; they are easier to execute correctly and harder to get wrong. Simple designs are also easier to test, validate and demonstrate correctness for, far more than complex, sophisticated designs. Complexity is an enemy of security.

1.4 Trust but verify, zero trust, privacy by design and shared responsibility

Trust but verify is the traditional DiD-inherited posture: the user (human or not) is authenticated once on entry into the environment. Once authenticated, they roam freely across the building, campus or internal networks. Sensitive resources stay protected by permissions and authorization checks, but without additional firewalls or boundaries, no further authentication check (to confirm the ID is who or what it claims to be) is performed. Many small LANs operate this way.

Zero trust starts from the observation that, in a trust but verify environment, a user once inside has nearly unlimited ability to roam, locate assets and find exploitable vulnerabilities. By placing more firewalls or boundary-control devices throughout the network, you increase the chances of detecting a troublemaker before harm is done. Many architectures push this to the extreme with microsegmentation of internal networks, enforcing frequent reauthentication of the user ID. This is the exam distinction: trust but verify = one authentication at entry; zero trust = continuous verification and multiplied internal boundaries.

Privacy by design is a design approach published in 2009 by Ann Cavoukian, then Information and Privacy Commissioner of Ontario, Canada. It aims to ensure privacy is considered throughout a system's design and development stages. The concept was adopted by the GDPR, the U.S. FTC, the CPDP and other regulators, in step with growing privacy demands in global legislation. Corollary: privacy by default - the most privacy-protective settings are active without any user action.

Shared responsibility stems from the rise of cloud: maintaining security and compliance becomes a shared responsibility of the provider and the customer. The customer cannot control everything that happens in the cloud; but you cannot place all responsibility on the provider either, since it controls neither the stored data nor its use. Both sides must therefore do their part under defined terms. The contract (often a service-level agreement, SLA) specifies which responsibilities are exclusive to each party and which are shared.

1.5 Synthesis: choosing the right design principle

Objective 3.1 asks you to explain the significance of basic secure design principles. The manual's "Check Your Understanding" lists them together: least privilege, defense in depth, secure defaults, fail securely, separation of duties, keep it simple, trust but verify, zero trust, privacy by design and shared responsibility. On the exam you get a scenario and must name THE applicable principle, not recite a definition.

A few discrimination cues. A user holds too many rights "just in case": least privilege. A single actor can both initiate AND approve a payment: separation of duties. New equipment ships with every service enabled: secure defaults. A system must drop to a safe state on crash, but without trapping people: fail securely (with the human-safety trade-off). A procedure is so convoluted that users bypass it: keep it simple. A once-authenticated user roams everywhere: trust but verify; if instead you want to re-verify continuously and segment: zero trust. You want privacy built in from the start: privacy by design. Data goes to a cloud provider and you must clarify who secures what: shared responsibility via the SLA.

Two cross-cutting ideas unify these principles. First, security is built in early (initiation phase) and in layers: defense in depth gives the frame, the others are its facets. Second, each principle is a deliberate trade-off: SoD and secure defaults degrade efficiency or user experience but reduce risk - the professional's role is to arbitrate that trade-off knowingly.

2.1 What a security model is

A security model defines rules of behavior for an information system in order to enforce security policies, which typically concern confidentiality, integrity, or both. The model sets the allowable behavior for one or more aspects of system operation. Once implemented, technology enforces those rules to ensure the security goals are met.

The model must be distinguished from its implementation. The model is a conceptual, mathematical framework: BLP, for instance, defines no technical construct or solution. It merely states a high-level set of rules that, correctly implemented, prevent the exposure or unauthorized disclosure of information in a system processing multiple classification levels. That is why the manual notes that modern operating systems implement elements of these models, but never perfectly: they aim at a practical implementation consistent with one or more models.

Two families structure this module. The first gathers lattice-based, multilevel models that control information flow between classification or integrity levels: BLP and Biba are the archetypes. The second gathers models that describe how subjects, objects, and rights are created, assigned, and revoked at the most basic level, where other models simply assumed that control existed: Graham-Denning and HRU.

In the exam, the first question to ask about any model is always the same: does it target confidentiality or integrity? That compass avoids most mistakes.

2.2 Bell-LaPadula: confidentiality

The Bell-LaPadula (BLP) model addresses confidentiality in a multilevel security (MLS) system. It defines two primary constructs: subjects (active parties) and objects (passive parties). Subjects are given clearances defining the access modes (read, write) they may use against objects. The BLP system uses labels to track clearances and classifications and applies a set of rules limiting subject-object interactions. It was an early model: it provides no one-to-one mapping of individual subjects and objects, which is a fundamental requirement for building a practical operating system.

BLP defines three properties. The Simple Security property (SS): a subject cannot read or access an object of higher classification, that is no read up. The Star property (written *): a subject can only save or write to an object of equal or higher classification, that is no write down. The Strong Star property: a subject can only write to objects at the same classification level as itself, that is lateral write only (no write down AND no write up).

The logic is intuitive once confidentiality is the goal. Forbidding read up stops a low-cleared subject from reading a secret above its level. Forbidding write down stops a cleared subject from copying a secret down to a lower level where less-cleared subjects would read it. BLP defines no technical constructs: it states high-level rules that, well implemented, prevent the exposure or unauthorized disclosure of information in a multilevel system.

The property names, such as the Star (*), originate in predicate calculus and set theory, where they apply to sets like mathematical operators. For the exam, hold the pairing BLP = confidentiality = no read up / no write down.

2.3 Biba: integrity, the mirror of BLP

The Biba model addresses data integrity; it does not address confidentiality. Like BLP, it is a lattice-based, multilevel model that describes subject-object interactions. One vocabulary difference: Biba speaks of observe and modify where BLP speaks of read and write. Above all, Biba assigns integrity levels to subjects and objects based on their trustworthiness, instead of BLP's confidentiality levels. The core of the model is a multilevel approach to integrity meant to stop unauthorized subjects from modifying objects and to keep objects' current integrity state as subjects interact with them.

Biba defines three properties. The Simple Integrity property (simple integrity axiom): a subject cannot read or observe an object of lower integrity, that is no read down. The Star property (*): a subject cannot modify an object of higher integrity, that is no write up. The Invocation property: a subject of lower integrity cannot request access to a higher-integrity object; it can only address objects of equal or lower level.

The contrast with BLP is the single most tested item. BLP protects confidentiality: no read up, no write down. Biba protects integrity: no read down, no write up. The rules are inverted because the goals are. In integrity, no read down keeps a high-integrity subject from being contaminated by untrustworthy data; no write up keeps an untrustworthy subject from corrupting a high-integrity object. BLP's Strong Star does not exist in Biba, and the Invocation property does not exist in BLP.

Mnemonic: for integrity, you do not read below yourself (don't get dirty) and you do not write above yourself (don't dirty others).

2.4 Clark-Wilson and Brewer-Nash

Biba covers only one of the three key integrity goals. The Clark-Wilson model improves on it by targeting integrity at the transaction level and addressing three major integrity goals in a commercial environment. For the second goal, Clark and Wilson realized they needed to stop authorized subjects from making undesirable changes. This required that an authorized subject's transactions be evaluated by another party before being committed to the system: this is separation of duties, the authorized subject's power being limited by another subject empowered to evaluate and complete the transaction.

For internal consistency, Clark and Wilson recommend a strict definition of well-formed transactions: the set of steps in a transaction must be carefully designed and enforced, and any deviation from the expected path makes the transaction fail so that integrity is not compromised. To control every subject-object interaction, the model establishes a system of subject-program-object bindings (the access triple): the subject no longer has direct access to the object; it goes through a program that arbitrates all access, authenticates and identifies the subject, and limits access to the objects under its control. Each interaction then follows a defined set of rules.

The Brewer and Nash model, or Chinese Wall, targets a different problem: preventing conflict of interest when a subject accesses sensitive-information objects belonging to two competing parties. The principle is that a user must not access the confidential information of a client AND one of its competitors. At first, the subject may access either set of objects; but once it accesses an object tied to one competitor, it is instantly prevented from accessing any object on the opposite side, to keep it from sharing information inappropriately, even unintentionally.

These ethical walls are common in financial services, for example to isolate corporate advisory from brokerage and reduce both the opportunity and the temptation to abuse insider information. Brewer-Nash is unusual: its access control rules change based on the subject's behavior (the accesses already made).

2.5 Graham-Denning and HRU: rights management

Where BLP and Biba assume that control over subjects and objects exists, the Graham-Denning model focuses precisely on how subjects and objects are created, how rights (or privileges) are assigned to subjects, and how ownership of objects is managed. It describes the control of subjects and objects at the most basic level.

The Graham-Denning model has three parts: a set of objects, a set of subjects, and a set of rights. A subject is made of two things: a process and a domain; the domain is the set of constraints controlling how subjects may access objects. A subject can also be an object at specific times. The set of rights governs how subjects manipulate passive objects. The model describes eight primitive protection rights, called commands, that subjects execute to influence other subjects or objects. The eight basic rules are: create objects securely, delete objects securely, create subjects securely, delete subjects securely, provision read-access rights securely, provision grant-access rights securely, provision delete-access rights securely, and provision transfer-access rights securely.

The term primitive protection rights plays the role of other models' permissions or privileges. Example: deleting an object is an action done by a subject (often via a task, process, or other software entity); the access control system must not allow it unless the subject has the right. Whether that right is granted for all objects, a subset, or per object depends on the chosen access control model (DAC or MAC, covered in Domain 5).

The Harrison-Ruzzo-Ullman (HRU) model is very close to Graham-Denning: it comprises a set of generic rights and a finite set of commands, and is also concerned with situations where a subject must be kept from gaining particular privileges, by preventing it from accessing the programs or subroutines that execute a given command (for example granting read access).

3.1 Selecting and tailoring standards to context

Section 3.3 starts from a simple idea: you select systems engineering controls that serve the organization's context. The mechanism has two steps. First, you choose appropriate standards as a starting point; then you tailor them to the organization's own context. This two-step move provides confidence that the organization follows a mature path serving its mission, rather than blindly applying a generic catalogue.

Security engineering itself is defined as the use of generally accepted engineering methods to apply systems security theories to specific situations, problems, or needs in practical and effective ways. Two authorities recognize it as a specialty engineering discipline of systems engineering: the International Council on Systems Engineering (INCOSE) and NIST.

The classic trap: assuming a standard deploys as-is. It does not - the standard is a starting point, and tailoring makes it relevant to the context (mission, constraints, risk). This is the same logic as scoping/tailoring seen elsewhere in the curriculum: start from a recognized baseline, then adjust.

3.2 Sources of security engineering standards

Section 3.3 lists commonly accepted sources of engineering and security engineering. The INCOSE Systems Engineering Handbook presents systems engineering principles in terms of affordability and performance, in the context of formal and informal project management structures.

NIST SP800-160 (Systems Security Engineering) addresses the engineering-driven actions necessary to develop more secure and survivable systems, including the components that compose them and the services that depend on them. It starts from a set of well-established international standards for systems and software engineering (published by ISO, IEC, and IEEE) and infuses systems security engineering techniques, methods, and practices into them. That is the precise meaning of engineering-driven: security is built into engineering activities, not added afterward.

Two ISO families round out the picture. ISO/IEC 15026 (Systems and Software Engineering series) focuses on assurance, integrity, and security concepts for systems and software. ISO/IEC/IEEE 15288 provides an overall systems engineering life cycle model; it is an outgrowth of earlier models from various U.S. military standards. Exam trap: do not confuse 15026 (assurance/integrity/security) with 15288 (overall life cycle model).

3.3 Security engineering processes per SP800-160

NIST SP800-160 defines general security engineering processes, consistent with the INCOSE Systems Engineering Handbook and easily related to ISO-based standards, with some minor differences. They fall into four families.

The Technical Processes handle the system itself: business and mission analysis (understand scope and asset-loss consequences), stakeholder needs and requirements definition, system requirements definition, architecture definition, design definition, system analysis, implementation, integration, and verification (produce evidence that the system satisfies its security requirements with the applicable level of assurance). The Technical Management Processes steer the project: project planning, project assessment and control, decision management, risk management (identify, analyze, treat, and monitor security risks), configuration management, information management, measurement, and quality assurance.

The Enabling Processes support the organization: life cycle model management, infrastructure management, portfolio management, human resources management, quality management, and knowledge management. Finally, the Agreement Processes govern contractual relationships: the acquisition process ensures the acquirer's protection needs are covered by its requirements; the supply process ensures the delivered product or service provides the security functions while meeting the constraints expressed by the acquirer. Trap: recognizing which family a given process belongs to (e.g., configuration management = Technical Management; acquisition = Agreement).

3.4 Change management, configuration management, policies and models

The reference stresses up front that engineering, as a discipline, embraces change management and configuration control. Whatever the engineering activity, it revolves around managing the information about the system being brought into existence. Mission or business needs for safety, security, reliability, and performance dictate (or should dictate) how detailed and formal those change management processes must be. Management must determine the right mix of formal change management and flexibility/responsiveness, according to the overall risk management strategy.

In the WLDR University case from the reference, configuration management is ad-hoc across campus IT groups: there is no standard configuration, nor the ability to quickly deploy controls during an incident. The expected answer is to implement configuration management processes to ensure the secure configuration of all systems and network devices based on their unique requirements.

Finally, security policies, models, and architecture connect in development. Systems usually start from statements of business or mission needs, often expressed as policies. A security policy defines what "security" means for a given system, which almost always reflects a compromise between security, operability, cost, and risk impact. Models represent experience gained from building similar systems (equations, flow diagrams, task sequences); engineers use them as starting points to iteratively develop an architecture for the desired system.

3.5 Historical evaluation criteria: TCSEC and ITSEC

Before today's international standards, two families of evaluation criteria shaped how the trust of a security product was rated. The Trusted Computer System Evaluation Criteria (TCSEC), nicknamed the Orange Book, was published by the U.S. Department of Defense. It builds on the Bell-LaPadula confidentiality model and primarily evaluates the confidentiality protection of a multi-user operating system. Its main weakness: it bundles functionality and assurance into a single rating, and addresses neither integrity nor availability.

TCSEC ranks systems into hierarchical divisions. Division D denotes minimal protection (a failed evaluation). Division C covers discretionary protection with C1 (discretionary security protection) and C2 (controlled access protection). Division B covers mandatory protection with B1 (labeled security protection), B2 (structured protection), and B3 (security domains). Division A, with A1 (verified design), requires a formally verified design. The Red Book, or Trusted Network Interpretation (TNI), extends these ideas to networks, whereas the Orange Book only covered standalone systems.

The Information Technology Security Evaluation Criteria (ITSEC) is the European answer. Its decisive contribution is to separate what TCSEC conflated: on one side functionality, rated F1 to F10, describing what the product does; on the other side assurance, rated E0 to E6, describing the confidence that it does so correctly. ITSEC also addresses confidentiality, integrity, and availability, where TCSEC was limited to confidentiality.

Exam trap: remember that TCSEC = confidentiality only, functionality and assurance bundled, based on Bell-LaPadula; ITSEC = functionality (F) AND assurance (E) separated, European, full CIA. The Red Book is not a level but the network extension of TCSEC.

3.6 Common Criteria (ISO/IEC 15408)

The Common Criteria (CC), standardized as ISO/IEC 15408, replaces and unifies the earlier national approaches, including the U.S. TCSEC and the European ITSEC. Its goal is to provide a common, repeatable language to evaluate the security of IT products, and to enable mutual recognition of evaluations across signatory countries through the Common Criteria Recognition Arrangement (CCRA): a product evaluated in one country is recognized in the others, avoiding repeated evaluation.

The CC vocabulary is central for the exam. The Target of Evaluation (TOE) is the product or system being evaluated. The Protection Profile (PP) expresses generic, product-independent security needs, written on the customer or user-community side: it is the demand ("here is what a class of products needs"). The Security Target (ST) is written on the vendor side: it contains the security claims for a specific product and explains how it meets, where applicable, one or more PPs. It is the offer ("here is what my product does").

The content of the claims breaks down into two requirement types. Security Functional Requirements (SFRs) describe the expected security functions (what the product does). Security Assurance Requirements (SARs) describe the verification activities performed to gain confidence in those functions (how thoroughly it was checked). This functionality/assurance split is directly inherited from the spirit of ITSEC.

The overall assurance level is summarized by an Evaluation Assurance Level (EAL), on seven steps: EAL1 (functionally tested), EAL2 (structurally tested), EAL3 (methodically tested and checked), EAL4 (methodically designed, tested, and reviewed), EAL5 (semiformally designed and tested), EAL6 (semiformally verified design and tested), and EAL7 (formally verified design and tested). Central trap: an EAL measures the RIGOR of the evaluation (assurance), not the amount of functionality nor absolute security. A high EAL against a weak PP does not guarantee an absolutely secure product.

3.7 Certification, accreditation, and Authorization to Operate (ATO)

Evaluating a product with the Common Criteria is not enough to authorize its use in an organization: a decision process is needed. That process rests on two steps the exam often contrasts. Certification is the technical evaluation: a detailed verification that a system's security controls satisfy a given set of requirements in a specific operating context. Certification produces evidence, not a decision.

Accreditation (or authorization) is the management act that follows: a designated authority, the Authorizing Official (AO), reviews the certification results and the residual risk, then formally accepts that risk on behalf of the organization. It is a risk management decision, not a technical analysis. The classic trap swaps the two: certification looks at the technical side, accreditation accepts the risk. Without accreditation, a certified system is not authorized.

The NIST Risk Management Framework (RMF) now frames this logic for U.S. federal systems, with its steps (categorize, select, implement, assess, authorize, monitor). The "authorize" step leads to a formal AO decision called the Authorization to Operate (ATO). Three outcomes are possible: a granted ATO (the system may go into service), a conditional ATO (authorization granted provided certain weaknesses are corrected within a defined timeframe, sometimes via an action plan), or a denial of authorization to operate (refusal: the residual risk is judged unacceptable and the system must not operate).

Finally, an authorization is never eternal. The RMF requires continuous monitoring and periodic reassessment: significant changes to the system, to the threat environment, or expiry of the authorization trigger a new assessment and a new AO decision. Trap: an ATO is not a permanent blank check; it is time-bound and revisable.

4.1 Conceptual security models: state machine, information flow, noninterference

Over time, designers have used different security models that emphasize distinct security properties. Many rely on the concepts of subjects and objects: a subject is a process that performs actions on an object, and an object can be a set of data, a hardware or software resource, or a person - which means an object can itself be a subject.

The state machine model identifies the system's starting condition and the end state it must be in once a process completes. The manual's example: a security policy may require that copying an object introduce no deviation from the original; comparing a secure hash of the original and the copy demonstrates the operation met that policy.

The information flow model extends the state machine model by focusing on the movement of information throughout the system. It describes how the privileges granted to subjects constrain their access to objects and the transformations they may apply to those objects. Security is therefore assessed in terms of permitted or forbidden flows, not just states.

The noninterference model ensures that objects and subjects at one level of sensitivity do not inappropriately interact with those at other levels. Each data access attempt is independent of all others and approved, if appropriate, by the security architecture. Crucially, the system's outputs should not disclose the security decisions or the inputs that generated them: a login process should not disclose the input values (login ID, password) in the authentication that results from a successful login.

4.2 Protection rings and processor states (Ring 0 to Ring 3)

The ring model emphasizes the interactions between the underlying hardware's security capabilities and their use by the software layers. Depending on the hardware, software, and system design, a different number of rings may be needed; in many cases four rings are sufficient. The manual's figure shows the ring model from the software perspective: the hardware layers and their burnt-in firmware are contained within Ring 0.

Process isolation increases the farther out the software runs from Ring 0. In addition, every time a service request crosses a ring boundary, the request should be evaluated against the security policy to determine whether it is appropriate. So an application's request to save a file to storage receives more scrutiny from the OS and the security kernel than the OS's decision to scavenge unused memory locations.

Ring 0 hosts the most sensitive OS functions, typically "trusted" functions subject to limited oversight; the security kernel monitors the overall operation of the OS and can terminate processing when it detects a possible compromise (Windows' Blue Screen of Death is one manifestation). Ring 1 hosts device drivers with direct hardware access, often requiring certification to meet the OS's security requirements. Ring 2 offers better performance and capability than Ring 3 applications, for tasks limited to users with broad privilege (formatting disks, establishing network connections) or for services rendered to applications (e.g. messaging APIs).

Ring 3 is where applications run; strict process isolation and rigorous authorization of service requests should be enforced there. The failure of an application at Ring 3 does not affect other processes or system functions, and the system can recover gracefully. Caution: these examples are strictly illustrative - some implementations support four rings but do not use Rings 1 and 2, or reserve Ring 1 for hypervisor-related tasks. The theoretical model does not always fully describe a given environment, and taking advantage of it requires implementation in both hardware and software. These levels rely on processor states: privileged mode instructions can directly alter the state of the hardware or of a running task, via special flag bits in the CPU indicating the privilege level of the current task.

4.3 System foundations: memory management, isolation, virtualization, and sandboxing

As early as the 1960s, security engineers had identified a list of critical features needed to build systems able to meet their security policy. These architectural elements have a dual nature: they represent lower-level security policies that components must have, and they offer high-level design templates for achieving the required behavior.

The native capabilities expected of any element intended for a secure system include: memory management (efficient RAM use, support for virtual memory, and segregation of a task's code and data spaces); abstraction layers, which prevent logic at one layer from interfering with or observing the detail of another, decoupling design and easing maintenance; code/data isolation and segregation, enforced by hardware and OS, which prevent one process from reading or writing another's code or data space, prevent execution of instructions loaded into data spaces and writing of instructions into a code space (even its own); file system attributes (read-only, execute-only) associating protective permissions with objects (under Unix/Linux every device is treated as a file); and the security kernel, which monitors all executing programs, including OSs, for errors or alarms signaling a breach, and can force a program into a safe state, stop it, or even shut the system down.

Once these features are present, vital extensions can be added. Access control authenticates a subject's connection requests or authorizes access to objects, with detailed accounting of attempted actions. Virtual machines encapsulate an entire operational system, including its interfaces to peripherals and networks; hardware and OS security and virtualization features then enforce the required isolation of processes, data, and devices.

Sandbox environments leverage virtualization for isolated testing and assessment, whether of systems under development or suspected malware. Finally, cryptographic systems enhance code/data isolation, provide digital signatures for code and data, and protect code and data at rest, in transit, or in use, via a combination of hardware and software elements. Each of these architectural elements links back to one or more security models.

4.4 Hardware roots of trust: TPM and HSM

The Trusted Platform Module (TPM) is a special type of hardware security module (HSM) designed for integration into other products and compliant with a specific standard from the Trusted Computing Group. Most, but not all, servers and end-user devices can be obtained with a TPM chip.

The TPM specification requires the module to include: secure key generation, secure storage, hashing algorithms, a random number generator, and an onboard cryptoprocessor able to perform the functions defined by the standard. The TPM designation further requires a device-unique identity key used for device identification.

The term TPM refers strictly to a module that complies with the TPM standard. Many other manufacturers create equivalent modules referred to as secure elements, secure enclaves, or similar terms. Leveraging the key storage facilities and cryptographic functions of the TPM chip can speed processing and increase a device's security posture. The HSM is the broader category: a hardware module dedicated to cryptographic security (protected key generation, storage, and use), of which the TPM is a standardized, embedded variant. This hardware root of trust anchors the cryptographic capabilities raised in the earlier lessons and is examined further in the subdomains devoted to cryptography.

4.5 Trusted Computing Base, reference monitor, and security kernel

The trusted computing base (TCB) is the set of components - hardware, software, and firmware - that are critical to a system's security: they are what enforce the security policy. Everything inside the TCB is trusted, because its failure could compromise the entire policy; everything outside the TCB need not be trusted. The boundary that separates the TCB from the rest of the system is the security perimeter. Keeping the TCB small and well defined is a major design goal: the smaller it is, the more it can be verified and protected.

The reference monitor is an abstract concept: it is the component that mediates ALL accesses by subjects to objects. No reference to an object may escape its control. Three classic properties are required of it: complete mediation (it is always invoked and cannot be bypassed), tamperproof (it is isolated and protected against any unauthorized modification), and verifiable (it is small and simple enough to be analyzed, tested, and proven correct - small enough to test). The related but distinct Common Criteria NEAT mnemonic lists four requirements of its own: Non-bypassable, Evaluable, Always invoked, Tamperproof.

The security kernel is the concrete implementation of the reference monitor within the TCB: it is the set of hardware, firmware, and software mechanisms that actually enforce access mediation. Where the reference monitor is the idea, the security kernel is the code and the circuitry. It is what, at Ring 0, monitors and enforces access decisions. The distinction is a recurring exam trap.

Even a system with a well-designed TCB can leak information through covert channels: communication paths not intended by the design. A storage covert channel conveys information by writing to a storage location (a file attribute, a disk sector) that another process reads; a timing covert channel modulates the timing of an observable event (response time, CPU usage) to signal bits to a collaborator. Covert channels bypass normal mediation and are a classic theme of trusted-system models.

4.6 Secure boot, measured boot, and trusted execution

A system's security begins before the OS even loads: if the boot chain is compromised (bootkit, malicious firmware), all the software protections built on top become moot. Hence the notion of root of trust: a trusted component, ideally anchored in hardware, from which trust propagates step by step along the boot chain (chain of trust).

Secure boot verifies the digital signature of each component of the boot chain before executing it. In the UEFI ecosystem, the firmware loads a bootloader, then a kernel, only if their signature matches a trusted key enrolled in the firmware. An unsigned or modified component is rejected: secure boot prevents the execution of unapproved code. Key point: secure boot VERIFIES SIGNATURES and blocks anything that does not match; it does not necessarily keep a record of what was loaded.

Measured boot, by contrast, MEASURES: it computes the hash of each stage (firmware, bootloader, kernel, drivers) and extends the TPM's Platform Configuration Registers (PCRs) with those measurements. Measured boot does not block anything by itself; it produces a reliable cryptographic record of the boot state. That record enables remote attestation: the machine can prove to a third party (attestation server, network access control) that its boot chain is in a known, approved state, by presenting the PCR values signed by the TPM. This is the direct link to the TPM seen in the previous lesson.

The trusted execution environment (TEE) extends the idea to run time: it is an enclave isolated from the rest of the system, where sensitive code and data run shielded even from a compromised OS. Intel SGX (application enclaves) and ARM TrustZone (secure/normal worlds) are the canonical examples. The TEE relies on a hardware root of trust to guarantee the confidentiality and integrity of the code that runs in it. Together, root of trust, secure boot, measured boot, and TEE form a continuous chain of trust, from boot to execution.

5.1 Client, server, and distributed systems

Client-based systems are traditionally the endpoints through which users access centrally provided services: workstations, laptops, point-of-sale terminals, or personal devices. They are labeled thick or thin depending on the complexity of the applications and OS they run locally; a thick client has its own storage and connectivity. The line between thick and thin is blurred and shifting. These clients inherit the vulnerabilities of their hardware, OS, and applications (malware, misuse, accidents) and are exposed to theft or loss, endangering residual data. Exploiting them can serve as a springboard to attack the servers they connect to. Mitigations are endpoint management matters: host-based anti-malware and IDS/IPS, endpoint management combined with MDM to handle patches and loss/theft, and network protections (segmentation, firewalls, IDS) that isolate client and network from each other.

Server-based systems fulfill a specific purpose (application, file, print, DNS servers). They are centralized, with limited access, and process far higher data throughput than a workstation, generating massive log volumes to analyze. A major pitfall: they are often kept in service for many years, sometimes with out-of-support software, for lack of redundancy allowing them to be taken offline to apply patches - even critical ones. Being networked exposes them to remote attacks; physical access to the server and its interconnection fabric opens an almost unlimited range of attacks, as does the logistics supply chain. The key mitigation for servers not migrated to the cloud is adding affordable redundancy, which removes the need to defer maintenance downtime and thus shortens the lag between receiving and applying a patch.

In a distributed environment, nodes and processors operate independently; storage and processing are spread across multiple components that synchronize via messaging. Nearly all forms of cloud are distributed systems, as is peer-to-peer. They often offer high redundancy (geographic data replication) and dynamic load balancing providing graceful degradation on failure. Their vulnerabilities: simpler distributed systems may lack the monitoring and control capabilities to detect failures or compromises in time, and the access control to support multiple classification levels. The mitigation is to strengthen access control, health monitoring, and IDS if the infrastructure supports it; otherwise, to isolate the distributed system physically, logically, and administratively.

5.2 Databases: aggregation, inference, polyinstantiation

A database system is built around a DBMS (database management system) and the compute and storage resources hosting it. It can run on an endpoint, a thick client, servers, or clusters, and most now operate in cloud or distributed environments. A database inherits its platform's vulnerabilities and adds database-specific ones: malformed inputs, denial of service, and bypassing access controls. Because they hold large quantities of valuable information and require high transaction throughput, databases are very high-value targets.

Aggregation is the assembling of several pieces of information, each non-sensitive on its own, whose combination reveals sensitive information. A user with legitimate access to several innocuous fields may, by aggregating them, reconstruct a secret they should not have. Inference is more subtle: the subject deduces sensitive information from data they can access, by reasoning, without ever accessing it directly. The classic exam pitfall is confusing the two: aggregation combines data to reach a sensitive total; inference deduces what is not explicitly present.

Polyinstantiation is the flagship countermeasure against inference (and deductive aggregation). It allows multiple instances (versions) of the same record, differentiated by the classification level of the subject viewing it. A low-level user sees a plausible but decoy version, while the real record stays reserved for the cleared level. By presenting divergent values depending on clearance, polyinstantiation prevents the low-level subject from deducing the existence or value of the classified data, and from spotting an inconsistency that would betray a secret.

5.3 ICS/SCADA, embedded systems, and IoT

Industrial control systems (ICS) monitor and control industrial machinery and critical infrastructure. For them, safety requirements often outrank security ones. Seen top-down, they comprise three components: SCADA (supervisory control and data acquisition), event-driven assemblies of equipment automating geographically distributed processes (power grid, pipelines, water treatment, rail); DCS (distributed control systems), confined to an area or plant and process-oriented; and PLCs (programmable logic controllers), ruggedized real-time industrial controllers driving sensors and actuators. Vulnerabilities specific to the embedded components of ICS: limited functionality and protection, long service life (10 to 20 years), high susceptibility to DoS and improper input, and above all attacks that can produce physical effects on the real world. They are often unattended in remote sites. Mitigations: isolated network infrastructure (air gaps or firewalls), connection restrictions and monitoring, highly segmented or microsegmented networks (zero trust), protected channels, and robust configuration control.

Embedded systems are microcontrollers built directly into mechanical, electrical, or hydraulic devices (cars, planes, medical devices, appliances). The boundary with ICS is blurred: an ICS often contains embedded systems, and the ICS itself may be embedded. Their operational risk is high: failure can render the host system inoperable, and their code sometimes resides in non-updatable read-only memory. Vulnerabilities: programming errors, exposed web interfaces, weak authentication or hard-coded credentials, poor cryptography, reverse engineering, malware, and eavesdropping. Stuxnet demonstrated sophisticated attackers' ability to target these systems. Mitigations: integration into the risk management framework with full inventory, patching within support limits, secure coding, and third-party risk management since they often come from vendor products.

IoT extends the miniaturization of embedded systems combined with ubiquitous wireless connectivity. These devices, from a simple status sensor to a calibrated device with safety-of-life implications, are no longer isolated on their own networks and thus present an expanded attack surface. Vulnerabilities: DoS worsened by reliance on wireless protocols (weak standard or proprietary ones) and multi-infrastructure transit; device physical security (theft, data remanence, reverse engineering, manipulation of the monitored environment); and cryptographic limits, since not all devices have the computing horsepower required.

5.4 Cloud: service models, essential characteristics, VM sprawl

Securing a cloud service means assessing every element of the provider's (CSP's) organization and technology. To stay efficient, one relies on standard audits by accredited third parties, supplementing as the organization's circumstances require. NIST defines cloud as a model for on-demand network access to a shared pool of configurable resources that can be rapidly provisioned and released with minimal management effort; the ISO/IEC 17788 definition is similar. NIST states five essential characteristics: on-demand self-service, broad network access, resource pooling (multi-tenant), rapid elasticity, and measured service. ISO/IEC 17788 keeps the five and adds a sixth: multi-tenancy, where physical or virtual resources are allocated and controlled so that processing and data of different tenants are isolated from and inaccessible to one another. This is exactly what Quiz Q3 targets.

Service models describe the split of management between CSP and consumer. NIST identifies three models, ISO/IEC 17789 four categories; the first three coincide. In SaaS, the consumer uses the provider's application without managing the underlying infrastructure. In PaaS, they deploy their own applications built with the provider's languages and tools, without managing the infra but controlling their applications. In IaaS, they provision compute, storage, and network to run arbitrary software (including OSs), with control over OS, storage, and applications. This gradient defines shared responsibility: the further down toward IaaS, the larger the consumer's share. ISO/IEC 17789 adds NaaS (Network as a Service), and offerings extend to IDaaS, SECaaS, CaaS, CompaaS, DSaaS. Deployment models (private, community, public, hybrid, plus GovCloud) describe the business relationships.

Three cloud vulnerabilities deserve attention: increased exposure to external communications; misconfiguration, since many organizations lack the skills and wrongly assume the CSP covers all security, when the consumer remains responsible for their own storage and processing; and becoming outdated, the SLA needing to clarify what the CSP maintains versus the consumer. On the virtualization side, VM sprawl (image management) is a classic pitfall: without control mechanisms and policies, VM images can be loaded and left running, copied to other areas, or exfiltrated (Quiz Q2). Other vulnerabilities: VM escape (an actor exploits a VM's credentials to attack the environment), hypervisor hardware weaknesses (Meltdown/Spectre type), and knowledge gap. Mitigations: change management applied to VMs and granular IAM (RBAC/ABAC) protecting the hypervisor from production workloads.

5.5 Containers, microservices, and serverless

Containerization provides a layer of shared OS services to reduce the size and complexity of individual VMs in a cloud environment. It lowers resource needs, shortens process startup time, and standardizes OSs. Open-source technologies like Docker and Kubernetes sit alongside proprietary approaches; adoption has been fast thanks to container portability across clouds. Vulnerabilities: insecure images (a vulnerable base image makes the container insecure), containers with excessive privilege (privileged flag), unrestricted communication between containers, malicious processes, and improper isolation from the host. Mitigations: image management (limit the number and configuration of images against image sprawl), immutable infrastructure (never patch a running instance but regenerate from a master image), granular security (minimal privileges per container), microsegmentation and firewalls, and proper configuration by trained staff, all the more so as platforms keep evolving.

Microservices are an implementation of service-oriented architecture (SOA) for the cloud: lightweight protocols carry information between highly isolated applications. Converting an application to microservices means breaking a large program into objects managed as separate execution threads, following the principle of "do one thing and do it well." Benefits: simplified maintenance (limited scope per service), conversion of batch processing into real-time without full redesign, and dynamic scaling far easier than on monolithic systems. Vulnerabilities: authorization (a poorly built microservice often runs at high privilege for convenience, dangerous if compromised), quality of service (a poorly structured microservice consumes more resources, e.g. spinning up a whole VM for an ephemeral service), and DoS (reliance on lightweight protocols like REST exposes any protocol weakness). Mitigations: authentication/authorization services (OAuth 2.0, SAML) with least privilege on service accounts, running in containers or serverless, and API gateways to protect access.

Serverless architecture extends the CSP's responsibilities to fully abstract the physical and logical infrastructure. Often called Function as a Service (FaaS), it makes the CSP responsible for elasticity, reallocating resources to match load. Services are accessed as functions reacting to events (other functions, external requests, file update, log entry, database transaction), often via an API gateway. A cloud newcomer, many of its attack patterns match those of other architectures (the topic is detailed by the Cloud Security Alliance). Specific vulnerabilities: malicious injection into the function (malformed inputs causing DoS or disclosure), insecure configuration (options multiplied by vendors to differentiate), and cross-execution data persistency (data kept between executions, unprotected and unpurged). Mitigations: train staff on configuring the vendor environment and apply secure coding with static, dynamic, and interactive testing.

5.6 Edge vs fog computing, HPC, and distributed systems

For the cloud to offer virtualized resources at reduced cost, information must move to the data center, which imposes high latency and raises confidentiality concerns. Edge and fog computing bring processing closer to the data sources to address this. Fog computing places a layer of compute resources closer to the input sources, providing application hosting and device management, and thus optimizes the movement of information into the cloud. Edge computing also encompasses endpoints, often embedded systems, at the network's edge; first at fixed locations, it now includes mobile devices via wireless.

The distinction, formalized by NIST SP 500-325, concerns the level of processing. Fog is hierarchical: it runs applications in a multi-layer architecture that decouples and meshes hardware and software functions, allowing dynamic reconfigurations, and it addresses, beyond compute and networking, storage, control, and processing acceleration. Edge runs specific applications in a fixed logical location and provides a direct transmission service, limited to a small number of peripheral devices. The exam pitfall (Quiz Q5): fog = hierarchical and multi-layer; edge = local, fixed, few devices. Their vulnerabilities: network compromise (edge relies heavily on the network; DoS and physical disruption of connectivity) and increased attack surface (multiplying devices raises the risk that a single misconfigured one becomes a bridgehead). Mitigations: stronger network monitoring and incident response, and hardened inventory/accountability to limit sprawl and rogue or obsolete devices.

High-performance computing (HPC) addresses problems demanding far more resources than usual: modeling nuclear explosions, climate change, or earthquakes, via massive numbers of processors working simultaneously. Long reserved for government agencies, it is now offered commercially, often coupled with the cloud, by maximizing productive use of resources - which may lead to compromising some traditional security controls to gain performance. The particular challenges lie in integrity and availability. Vulnerabilities: latency constraints (traditional tools like IDS/IPS or firewalls would impose unacceptable latency on parallel processes) and improper workloads (a compromised HPC may have its time consumed by unauthorized loads, like the Russian supercomputer diverted to mine Bitcoin in 2018). Mitigations: proper architectural design (secure compute enclaves, perimeter detection to offset reduced internal controls) and suitable monitoring/logging despite their compute cost. Finally, distributed systems (seen in L1) underpin nearly all these cloud architectures and remain a cross-cutting thread.

6.1 Vocabulary and foundations: from plaintext to cryptosystem

At the heart of any encryption system, an original set of data, the plaintext, is transformed into an unintelligible form, the ciphertext. The plaintext can be anything that is digitally representable (executable files, images, queries, database records): it is not necessarily human-readable text. Be careful not to confuse plaintext with cleartext, which refers to information deliberately left in the clear (for example IP packet headers).

An encryption system (or cryptosystem) is the whole set of hardware, software, algorithms, control parameters and operational methods that provide encryption services. The algorithm is the transformation method; the key is the secret parameter that configures that method. Older cryptographers called these parameters the cryptovariables of a system: the key is the cryptovariable par excellence.

The work factor is the effort an attacker must expend to break the encryption. It is tied to the size of the key: a 16-bit key defines a key space of 65,536 values, a 256-bit key a 78-digit number in base 10. But size alone is not enough: Elliptical curve cryptography provides comparable strength with a much shorter key. Key strength therefore results from the combination of key length AND algorithm.

Two founding principles frame the discipline. Kerckhoffs's principle: a well-designed system must remain secure even if everything but the key is known to the adversary; security by obscurity is inherently flawed. Claude Shannon's corollary (1949) sums it up: the enemy knows your system. Only the keys can be protected, and that is precisely what must be done.

6.2 Encoding vs encryption vs hashing

These three transformations are regularly confused on the exam, even though they meet distinct needs. Encoding is a simple mapping of symbols to numbers or to another format: assigning A=0, B=1 ... Z=25, or using a character set such as Unicode-8 or Unicode-16. Encoding does NOT aim for secrecy: it is reversible without a key and provides no confidentiality or integrity.

Encryption transforms plaintext into ciphertext using an algorithm AND a key. It aims for confidentiality (and, depending on the scheme, contributes to authenticity or non-repudiation). It is reversible ONLY with the correct key: it is possession of the key that distinguishes the one who can decrypt from the one who cannot.

Hashing applies a one-way function that produces, from a message of arbitrary length, a fixed-length output called a message digest. Hashing does NOT use a cryptographic key (even though we speak of cryptographic hashing) and is not reversible: it aims for integrity, not confidentiality. Integrity is verified by recomputing the digest and comparing it: a single changed bit changes the digest.

Two properties are essential. The hash must be collision resistant: it must be hard to find two different inputs producing the same digest. And it must be deterministic: the same input always produces the same digest. Symmetrically, encryption must guarantee the absence of collisions (two distinct plaintexts yield two distinct ciphertexts) and deterministic decryption (a ciphertext yields only a single plaintext).

6.3 Symmetric encryption: DES, 3DES, AES, modes, and the one-time pad

Symmetric encryption uses the same key to encrypt and decrypt; decryption is simply the exact inverse of encryption. All classical algorithms are symmetric and often combine substitution (replacing bits with others according to a cryptovariable) and transposition (changing the position of the bits). Two architecture characteristics define these systems: block versus stream. A stream system encrypts one symbol at a time; a block system processes fixed-length groups (the block size is typically measured in 8-bit bytes).

The history of the standards is illuminating for the exam. The Data Encryption Standard (DES), submitted by IBM, was adopted in 1977 as the federal standard for unclassified documents. Its overly short key (56 bits) doomed it: 3DES (Triple DES) extended DES but was to be retired (around 2023 according to NIST). NIST launched the Advanced Encryption Standard (AES) competition in 2000; in November 2001, FIPS 197 approved a variant of the Rijndael algorithm. AES remains the only publicly published cryptographic algorithm capable of protecting data classified up to top-secret level in the United States.

Other symmetric algorithms are worth knowing: Blowfish and Twofish (Bruce Schneier), RC4 (stream, used in WEP and SSL/TLS, banned from TLS by RFC 7465 in 2015), RC5 and RC6 (Ron Rivest, configurable), IDEA (128-bit key, 64-bit blocks), CAST and SAFER (a variant used as a block cipher in Bluetooth). The running key cipher illustrates the use of modular arithmetic: Ciphertext = plaintext + key (modulo 26) for the Latin alphabet.

The one-time pad (Vernam cipher) is the only system considered unbreakable if correctly implemented: the key is as long as the message, perfectly random and used only once. The session keys used on the internet are a form of one-time pad. Advantages of symmetric: fast, lightweight, memory-efficient. Major drawbacks: it depends entirely on a key generation and distribution infrastructure, and it cannot, on its own, ensure either integrity or non-repudiation.

6.4 Asymmetric encryption: RSA, ECC, Diffie-Hellman-Merkle, ElGamal

Asymmetric encryption uses a fundamentally different algorithm and key to encrypt and decrypt. It relies on trapdoor functions (one-way functions): easy to compute in one direction, extremely costly in the other. Two families of mathematical problems underpin common algorithms: discrete logarithms (used by ECC, ElGamal, Diffie-Hellman-Merkle and others) and prime factoring (factoring very large prime numbers, used only by RSA).

Each party holds a key pair: a private key kept secret and a public key that can be freely distributed. The principle is one of zero prior knowledge: two parties with no shared secret can nonetheless establish a shared secret. Diffie, Hellman and Merkle published in 1976 the first key exchange algorithm based on this principle (patent 1977, now expired). RSA (Rivest, Shamir, Adleman, 1977) offers encryption AND signatures, and provides non-repudiation, integrity and source authentication. ElGamal builds on Diffie-Hellman but adds confidentiality and signatures.

Elliptic Curve Cryptography (ECC) has the highest strength per bit of key length of all asymmetric algorithms. This property is central to the exam: ECC achieves equivalent security with much shorter keys. As an example from the manual, a top-secret classification requires a 384-bit ECC key where RSA requires 7680 bits. Hence the value of ECC for smart cards, wireless and any context limited in power, bandwidth or storage.

Advantages of asymmetric: it solves the key distribution problem (exchange over an untrusted channel without prior sharing), it scales well (each party only needs its own key pair) and it provides non-repudiation, access control and integrity. Major drawback: it is very slow, hence impractical for encrypting large amounts of data (inefficient beyond roughly 64 KB). It is reserved for integrity, authentication and non-repudiation.

6.5 Hybrid encryption and the key-count problem

Neither family is ideal on its own: symmetric is fast but struggles to distribute its keys, asymmetric distributes well but is slow. Hybrid encryption combines the strengths of both. The typical scheme: asymmetric encryption is used to produce and transport a session key, which then serves to symmetrically encrypt the content for that session only. SSL and TLS are hybrid systems; almost every internet user invokes their services on every secure page.

Concrete walkthrough (Alice to Bob): Alice encrypts the message with a symmetric key, without worrying about size since symmetric is fast. She produces a ciphertext message (CTM). To transmit the symmetric key over an untrusted channel, she encrypts it with Bob's public key, producing a ciphertext key (CTK). Bob decrypts the CTK with his private key, recovers the symmetric key, then decrypts the CTM. This yields both the speed of symmetric AND the distribution security of asymmetric.

The problem of the number of keys explains why symmetric alone does not scale. In a purely symmetric system, each pair of users needs its own unique key. For N users, the number of keys required is N(N-1)/2. The growth is quadratic: an organization of 10,000 users would need nearly 500 million keys, a management nightmare. Asymmetric solves this problem: each party only needs its own key pair, which is linear growth.

A final operational point: key distribution is done either in-band (over the same channel as the encrypted traffic) or out-of-band (by another means). Historically, many so-called military-grade systems were not broken by attacking the keys themselves, but by subverting the distribution process. This is a risk in both cases, and it is a reminder that security lies in key management, not in the secrecy of the algorithm.

6.6 Hashing, collisions, and random number generation

A hash function applies a one-way operation that produces, from a message of arbitrary length, a fixed-length message digest. Recomputing the digest on a copy and comparing it allows integrity to be verified: if a single bit has changed, the digest differs. Hash functions do not use a cryptographic key; they are strengthened by random number generators via seed values or salt values.

A hash function must satisfy five requirements: be uniformly distributed (unpredictable output), collision resistant (hard to find two inputs giving the same digest), impossible to invert (irreversible), computed on the entire message, and deterministic (same input, same output). Collision is the central risk: two messages producing the same digest. Increasing the size of the digest improves resistance to collisions.

Examples of algorithms to know: MD5 (Rivest, 1992, 128-bit digest) is now deprecated because collisions in it are computable, which makes it unfit for secure communications and signatures. SHA-1 (NIST, 160-bit digest) is more robust than MD5 but has also been subjected to collision attacks. The SHA-2 family (SHA-224 to SHA-512) offers digests of 224 to 512 bits; SHA-3 (2015) has a very different structure and can substitute for SHA-2 if needed.

Random and Pseudorandom Number Generators (RNG/PRNG) are a recurring source of problems. Most cryptographic processes rely on random numbers as seeds, salts or other cryptovariables, for key generation as well as for hash functions. Yet software cannot produce true randomness: a PRNG only provides a sequence with a reasonably random probability of occurrence. PRNG vulnerabilities (clumping, predictability of the next value) have caused many exploits. Hardware implementations exploit physical phenomena (thermal noise, radioactive decay, cosmic ray impacts) to approach true randomness.

7.1 Digital Signatures and Non-repudiation

A digital signature is a block of data produced in two steps: first you hash the message with a hash function, yielding a content-dependent digest (message digest); then you encrypt that digest with the sender's private key. This encrypted digest is the signature. It is appended to the cleartext (unencrypted) message and sent to the recipient.

On receipt, the verifier decrypts the signature with the sender's public key to recover the original digest, then independently recomputes the digest of the received message and compares bit by bit. If they match, three properties hold at once: integrity (the message has not been altered, even by a single bit), source authentication (only the holder of the private key could have produced the signature), and non-repudiation (the sender cannot deny having signed).

Signing must not be confused with encrypting. Signing does NOT protect confidentiality: the message stays readable, and anyone holding the sender's public key can decrypt the digest. To get confidentiality AND proof of origin, you nest two operations (sign with your private key, then encrypt the whole with the recipient's public key). Non-repudiation in the strict sense requires digital signatures: symmetric encryption alone cannot provide it, because the key is shared.

Non-repudiation delivers three services: preventing the sender from denying they sent the message, verifying integrity, and preventing the recipient from claiming they received a different message. NIST published FIPS 186-4 (Digital Signature Standard, DSS), which standardizes the terminology and approved algorithms. Uses are numerous: vendor-signed software updates validated by a trusted installer, signed device drivers, smart contracts, documents and contracts, apostille/notario processes, and chain of custody preservation in digital forensics.

7.2 PKI: CA, RA, VA and the Chain of Trust

A public key is just a string of numbers: by itself it has no link to a person or organization. The problem is therefore to reliably assure that a public key truly corresponds to the signer's private key and to their identity. The public key infrastructure (PKI) solves this: it publishes the public keys tied to an entity, certifies that a public key is bound to an individual or organization, and verifies that a public key is valid and correct. The heart of PKI is its certificate mechanism.

The certificate authority (CA) is the trusted third party that attests a certificate owner truly holds a given public key. To do so, the CA digitally signs the entity's certificate with its own private key. There is one root CA in a PKI system; it can delegate authority to subordinate CAs to share the workload of issuing and validating. This delegation establishes a hierarchy of trust: a user trusts a subordinate CA because that trust ultimately flows back up to the root CA. This is the chain of trust.

The registration authority (RA) accepts and validates the identification information submitted by a user requesting a public key and certificate. The RA may be part of the CA's team or a separate organization; it does not sign certificates. Another entity, the validation authority (VA), provides authentication of a certificate's validity (that it has not expired or been revoked).

PKI rests on the trust placed in the CA. The DigiNotar case (2011) shows the risk: an attacker issued dozens of fraudulent certificates, used for man-in-the-middle attacks against Gmail users in Iran. When a root CA is compromised, all derived trust collapses, forcing browsers and organizations to push emergency patches and update revocation lists. PKI uses the Diffie-Hellman-Merkle key negotiation algorithm to let two parties derive a shared secret (a session key) without transmitting it.

7.3 X.509 v3 Certificates and Revocation

ITU standard X.509, part of the X.500 family for directories, defines how to issue certificates, their contents, and their expiration and revocation processes; it also defines how to verify that a public key truly belongs to the certificate owner. X.509 version 3 is the most widely used today.

An X.509 certificate contains, among other fields: the algorithm used for the signature, the issuer name (the CA's X.500 name), the period of validity (start and end dates), the subject's name (owner of the public key), the subject's public key information (key, algorithm, parameters), optional unique identifiers for issuer and subject, an Extensions field that allows user-defined extensions to certificates - a key feature of v3 - and finally the CA's digital signature, that is, the hash of the certificate encrypted with the CA's private key.

An issued certificate can become unreliable: for example if the subscriber misrepresented their identity to the CA, or if the holder believes their private key was lost or compromised. In that case the CA revokes (permanently invalidates) the certificate and publishes a revocation notice. Typical reasons are: compromised key, changed purpose, the organization ceasing to trade, or a name change.

Two revocation mechanisms coexist. The certificate revocation list (CRL) is a list of revoked certificates the client periodically downloads from the CA to compare serial numbers; its drawback is growing size (bandwidth, latency), so many browsers no longer support it by default. The online certificate status protocol (OCSP) queries the CA for a single certificate and returns a status (good, revoked, unknown, or an error code); more efficient than the CRL, it is nonetheless not fully secure - vulnerable to man-in-the-middle and prone to introducing delays.

7.4 Key Lifecycle, Escrow and Recovery

Key management covers everything involved in generating, recording, transcribing, distributing, installing, storing, changing, and using keys, down to disposing of the equipment that retains key-related data. It is the total control of cryptographic keys. Under Kerckhoffs' principle the algorithm is public: it is the keys that make the system strong. That is why key management is the most critical activity - attacks against keys are far more likely and more effective than attacks against algorithms. Three bodies of practice frame it: NIST SP 800-57 (management practices, governance, implementation details across Parts 1 to 3), ISO 11770 (generation, storage, distribution, deletion, archival of keying material), and ANSI X9.24 for banks and financial institutions.

The lifecycle follows stages. Generation: preferably by automated systems that ensure strong keys and policy enforcement; the quality of random number generators (RNG/PRNG) is critical because predictable seeds or salts weaken everything. Storage: tamperproof hardware security modules (HSMs), passphrase-protected smart cards, key wrapping of session keys with KEKs, splitting and storing in separate locations, with some devices self-destructing under attack. Distribution: the key must be delivered without a third party deducing it (the key distribution problem); a session key is protected with a key encrypting key (KEK) via key wrapping, either in-band (same channel as the encrypted traffic) or out-of-band (a different channel). Expiry: every key must have an expiration date to limit the time available for cryptanalysis. Revocation then destruction: at end of life the key must be destroyed so it cannot be reconstructed; archived encrypted data, however, requires the keys to remain available and backed by valid certificates as long as the data has value.

The session key is an ephemeral symmetric key, used once for one session (a form of one-time pad); it is preferably generated automatically through negotiation between endpoints (Diffie-Hellman-Merkle, KINK). Reusing a session key for too long jeopardizes it: too much ciphertext under one key eases attack. At the end, session keys must be destroyed to prevent recovery.

Key recovery is a backup mechanism ensuring the organization keeps continued access to its own encrypted data if a key is lost or damaged. Key escrow is one form: keys are vaulted with a trusted third party or an RA. Multiparty key recovery splits a key into parts entrusted to separate entities (dual control). Caution: a recovery mechanism mandated by a government (backdoor or lawful code breaking) means the algorithm is no longer secure for everyone, which has been widely rejected.

8.1 Attacks on the key and the algorithm

Ciphertext-based attacks begin by gathering copies of encrypted messages intercepted in transit. Nearly all media (radio, digital networks, PSTN, even printed material) can be intercepted and copied, often without trace. Their two goals: reveal the protected plaintext and recover the key.

The ciphertext-only attack is one of the hardest because the attacker holds only unintelligible data suspected to be an important encrypted message. It gets easier by collecting enough ciphertext to look for patterns and statistics. Frequency analysis is decisive here: it exploits the known frequencies of letters and words of a language (in English, "e" dominates, "the" is the most common trigram). Described as early as the 9th century by Al-Kindi, it remains the weapon of choice against substitution ciphers.

The known plaintext attack assumes the attacker holds both the plaintext and the ciphertext of the same message. Since the algorithm is always assumed known, the goal is to find the relationship between the two: the key. A recovered key decrypts every message encrypted with it. The chosen plaintext attack goes further: the attacker chooses the plaintext and obtains the matching ciphertext, knowing the algorithm or having the cryptosystem. Its adaptive variant lets inputs be modified repeatedly. The historical example: the Midway ruse in 1939-1945, where the Navy had a fake plaintext message broadcast ("Midway is low on fresh water") to confirm that "AF" meant Midway.

The chosen ciphertext attack is the mirror image: the attacker accesses the decryption device and submits chosen ciphertexts to observe the plaintexts and deduce the key; the adaptive version allows modifying the ciphertext before each pass (lunchtime attacks, at very low work factor). Finally, linear cryptanalysis (a known plaintext using a linear approximation of the block cipher) and differential cryptanalysis (a chosen plaintext introducing minor plaintext changes to observe ciphertext changes) target the algorithm structure directly; combined, they raise the odds of success. The algebraic attack, in turn, exploits the mathematical structure of certain block ciphers.

8.2 Attacks on the implementation

Implementation attacks are today among the most common and popular, because they are easy and rely on system elements OUTSIDE the algorithm. Often the weakness lies not in the math but in how the cryptography is implemented.

The brute force attack tries one key after another in the key space, hoping to hit the right one before spending too much time. The longer the key, the more the key space (number of possible values) explodes, and the higher the work factor: beyond 128 bits the attack often becomes impractical. Yet a large key's security is deceptive: weak PRNGs that clump keys, massive VM/botnet cracking in the cloud, sloppy session key management, known algorithm weaknesses, sheer luck, quantum computing, and social engineering all reduce the real work factor. The dictionary attack and the rainbow table (a sorted table of precomputed hashes) sharply speed up attacks on poorly protected hashed password files. The factoring attack targets RSA specifically by factoring the product of large primes, and Shor's 1994 work suggests quantum would make it formidable.

Side channel attacks are passive attacks exploiting a PHYSICAL attribute of the implementation (power consumption, electromagnetic emanations). The timing attack measures variations in operation duration to infer internal structure and shrink the search space; its typical defense is to PAD messages to a standard length so all operations run in constant time, regardless of the secret handled. The probing attack watches (or alters) the circuitry around the cryptographic module to extract clues about the key or algorithm.

The fault analysis attack forces the system into an error state, then compares erroneous results with good ones to guess the key. Fault injection feeds known faulty data or, on hardware, noise on the input/output/power lines, even radio waves into the circuits. Attacking the random number generator exploits a too-predictable RNG to anticipate initialization vectors. Finally, temporary files: every cryptosystem writes temporary files; if they are not securely deleted and overwritten after each operation, they may be read and compromise the cryptanalysis.

8.3 Attacks on the system and the human

Every cryptosystem, like every security control, ultimately depends on humans to be implemented and operated correctly. This is one of the greatest vulnerabilities. Social engineering is the use of deception or intimidation (coercion, bribery, deception) to get a person to provide information they are not authorized to disclose, with no technical means. Historically it is the most SUCCESSFUL attack against cryptographic systems, and it remains central to an advanced persistent threat's (APT) plan. The 2011 RSA compromise proves it: two phishing emails, an Excel spreadsheet exploiting an Adobe Flash zero-day, an installed backdoor, then the network of several U.S. defense contractors hit, and roughly 66 million dollars to replace every SecurID token. The only defense is constant vigilance: awareness, education, training.

The birthday attack rests on the birthday paradox: in a group of 23 people, the probability that two share the same date exceeds 50%. Applied to hashing, it seeks two messages producing the SAME message digest (a collision). The key idea: it is far easier to find TWO messages that collide than to find a message matching a given digest (preimage). Experts consider it a type of brute force, since the attacker hashes messages until a collision appears; strong hash algorithms resist this as much as possible.

The man-in-the-middle (MITM) attack inserts a hostile third party into the channel between sender and recipient to intercept, tamper with data, or masquerade as one to the other, remaining undetected. Ideally the attacker inserts BEFORE the session begins: a public-key request can be hijacked by returning the attacker's own public key. It targets symmetric, asymmetric, and hybrid systems. The replay attack resends captured files or inputs to disrupt processing; without timestamps, one-time tokens, or sequence codes, the system processes duplicates and grants access. Pass the hash is a variant: NTLM/SMB once passed credentials in cleartext, then harvested hashes were replayed during a challenge-response handshake (TGS/TGT included).

Finally, ransomware and ransom attacks: between 2016 and 2018 they rose by more than 350% and are recognized as the second greatest threat after insiders. The response rests on four families of strategies: Denial (clean, verified backups, anti-malware, training), Detection (behavior monitoring, signatures, decoys), Containment (prevent spread and reinfection), and Response and recovery (the major strategic decision: pay or not, to be decided WITH legal counsel before the incident, because paying a sanctioned actor can trigger strict liability). Some attacks are "living off the land," without dedicated malware (e.g., Bitlocker abused).

9.1 CPTED and site design

CPTED (Crime Prevention through Environmental Design) addresses crime through organizational means (people), mechanical means (technology and hardware), and natural means (architecture and circulation flow). Its logic is passive: by directing the flow of people, signaling through discreet cues who should and should not be in a space, and providing visibility into otherwise hidden areas, you reduce the likelihood that a crime will be committed there. CPTED is associated with the broken windows concept: where neglect prevails, crime increases; conversely, an orderly, well-maintained space discourages bad behavior.

Three principles structure the approach. Natural surveillance makes areas visible - lighting, especially around doors, and clear sight lines - so that any abnormal behavior is detected. Natural access control channels visitors: direct them to a single entrance with a reception able to determine the purpose and destination of the visit; shrubbery and hedges deter people from taking certain paths. Territorial reinforcement, also called territoriality, distinguishes public from private spaces through doors and locks, signage, staff uniforms, and the placement of reception and guard desks; this sense of perceived ownership signals that the owners are paying attention.

Design should remain welcoming without turning the facility into a fortress: water and vegetation are both attractive and useful for safety. Critical areas (server rooms) must be isolated from public and employee traffic by placing them off the beaten path. Beware of false controls: a door opened by a guard via a switch can be defeated through intimidation or social engineering, and contact alarms signal a door held open.

Site planning also covers the alternate site: it must be far enough not to suffer the same disaster as the primary site, yet close enough for key personnel to reach in a crisis. It must be geographically distinct, provide processing capability, and undergo its own risk assessment (natural disasters, structural failures, hostile attacks). The security team should be engaged at the design phase (concept of operations), before the building is acquired: the later security is involved, the higher the cost of remediation.

9.2 Server room and data center: HVAC and power

A server room demands a higher level of physical protection than the rest of the facility. Its human traffic is higher: access point security and monitoring/recording of entries are critical. When the space is shared between units or businesses, rack- or equipment-level locking becomes essential. Beware of repurposing: converting an office into a server room without reinforcing floors or sizing cooling endangers the building and its occupants. The cable plant must be inventoried, labeled, and protected: a poorly managed cable plant increases fire load and can cause cable trays to fail.

Data center standards allow facilities to be evaluated and compared. The Uptime Institute Tier Classification System rates from Tier I (basic infrastructure) to Tier IV (fault-tolerant site); it is a de facto standard, not legally mandated. ANSI/TIA 942-A focuses on cabling and network reliability (rated 1 to 4). ANSI/BICSI 002 covers the MEP trades (mechanical, electrical, plumbing) plus fire protection. The European standard EN 50600 rates an Availability Class on four levels, in several parts (construction, power distribution, environmental control, cabling, security systems).

HVAC maintains the temperature range recommended by ASHRAE for uptime and hardware life: between 18 C and 27 C (64 F to 81 F). ASHRAE recommends three temperature sensors per rack (top, middle, bottom), because cooling is often more than half of a data center's operating cost. Airflow also manages contaminants (dust, fumes) and breathable air (CO2 sensors, fresh air intakes).

Power must be delivered constantly and at constant quality: fluctuations shorten system life, outages stop them. Resilience rests on two complementary building blocks. The UPS supplies battery power for the time it takes generators to start and stabilize: it is SHORT-term coverage. Backup generators, sized for the critical load (compute resources) and supporting infrastructure, provide the LONG term as long as fuel is available. Dual-feed redundancy (two supplies from separate substations, transfer switches) further increases resilience. As with data backups, failover to backup power must be tested.

9.3 Fire: classes, detection, and suppression

Fire control follows a layered approach - prevention, detection, suppression - assessed at the building, room, and enclosure (rack) levels. Prevention is the most important: compliance with building codes, reduction of fire load (paper, clutter, flammable materials), regular inspections, no-smoking policies. Data centers face additional requirements due to their specific hazards.

Detection begins with spot-type detectors: ionization measures the electrical current between two charged plates as smoke passes, photoelectric measures light changes due to particles. Newer models combine ionization, photoelectric, carbon monoxide, heat, and flame to broaden detection and reduce false alarms. Aspirating detectors continuously breathe in an air sample: these VESDA (Very Early Smoke Detection Apparatus) systems are integrated into return air and the plenum beneath raised floors; their extreme sensitivity allows several alarm levels - a low threshold triggers an annunciator, a high threshold initiates full suppression.

Fire is grouped into five classes (letters vary by country): Class A (ordinary combustible solids: paper, wood, plastic), Class B (flammable liquids), Class C (electrical fires), Class D (flammable metals), Class K (commercial cooking equipment). For data centers and offices, the main concerns are A, B, and C. Choosing the right agent for the class is crucial: an unsuitable agent is ineffective or dangerous.

Two broad suppression families. WATER-based systems, mainly effective on Class A, safe for people and inexpensive, but they damage equipment: wet pipe (water in pipes, heat-activated heads, the most common), dry pipe (pressurized gas, water released after a head activates, useful against freezing), pre-action (combines wet and dry, often requires both a sensor AND a head), deluge (open heads, all activated simultaneously), and AFFF foam. GAS-based systems are effective against Classes A, B, and C: they inhibit the chemical reaction, reduce heat, or above all lower oxygen; they require people to evacuate and doors to close (suffocation risk). Examples: FM-200, CO2, Argonite, Inergen, hydrofluorocarbons, and the older Halon (withdrawn from commerce). For occupied equipment spaces, nonconductive, nontoxic liquids such as Novec 1230 protect Classes A, B, and C without water damage or suffocation. Pre-engineered rack systems locate the source and concentrate suppression on the affected area.

9.4 Perimeter, mantraps, and physical access control

Physical defense is organized in successive layers, like a medieval castle: a strong fence forms the first line, the building entrance the second, then internal segmentation (a floor, level, or section with restricted access) forms the third. As at Conwy Castle, the moat restricts approach paths and funnels them into a predefined route, allowing defense to be concentrated on specific areas rather than defending the whole site. A single entry point creates a bottleneck that lets staff identify visitors and authorize or deny entry.

Physical access controls favor robust elements. Doors should be solid core: hollow-core doors offer little security, are easily breached, and are poor fire barriers. Windows should not be adjacent to doors (a broken pane would give access to the lock); use laminated glass and protections (grills, screens). Key locks remain the most common way to secure a space. Turnstiles and mantraps (airlocks) are a cost-effective method to control access and limit flow: a mantrap opens the second door only after the first has closed, which prevents tailgating.

Restricted work areas protect spaces where highly sensitive work occurs. SCIFs (Sensitive Compartmented Information Facilities) impose extreme protections: solid or metal-clad doors that resist penetration and deaden sound, electrical connections dedicated solely to the secure environment, ductwork that is isolated or protected against intrusion and audio/RF monitoring, acoustic protections preventing external eavesdropping, visual protections (nondescript exteriors, windows discouraged and treated against visual, acoustic, and RF observation), and IDS with sensors in walls, floors, and ceilings. Born from national security work, these measures also protect companies' most sensitive intellectual property.

Evidence storage rooms are strictly limited-access, heavily monitored areas, with individual lockers or containers per investigation, to guarantee the chain of custody. A break in the chain of custody can render evidence inadmissible in court. As for utility services (electricity, telecom, water, gas), their compromise can render the facility unusable: provide appropriate redundancy, building controls with leak sensors and alarms, and contingency plans that prioritize essential systems.

9.5 Life cycle: from need to secure deployment

Information system life cycle management is the long-term, holistic management of the capabilities an organization needs. Even a successful system will eventually require rearchitecture and rewriting, because needs change. The life cycle covers the activities to create, manage, and ultimately retire and replace a system.

Everything starts from stakeholder needs and requirements. Software security documentation includes a stakeholder map and a requirements traceability matrix. Functional requirements capture business processes and abuse cases; nonfunctional requirements carry security and performance requirements, many of which come from privacy laws and standards. Requirements analysis adds misuse cases: unlike use cases, they require adopting the perspective of a malicious actor.

Architectural design weighs solutions by their ability to satisfy requirements; the system should be self-defending. Threat modeling enumerates the attacks to defend against. Secure architecture principles apply here: open design (security must not rely on secrecy of design), complete mediation (every access request is vetted, a foundation of zero trust), least common mechanism (minimize mechanisms shared among subjects, which are sources of unauthorized exchange), compartmentalization, and reuse of proven libraries with a secrets manager to avoid hard-coded credentials. Microsegmentation and zero trust (NIST SP 800-207) seek a balance between the discouraged authenticate once, trust forever model and the extreme trust nothing.

Development structures the environment for success: up-to-date, verified libraries, an IDE with a linter, a code repository that automatically applies static analysis (SCA/SAST) for immediate feedback to the developer - fixing a bug at writing time costs orders of magnitude less than in production. Up-to-date, safe languages (type safe, no buffer overflow), secure coding training (OWASP Top 10). Integration verifies correct execution between upstream and downstream systems; legacy systems can expand the attack surface and benefit from isolation in network enclaves. Verification and validation adds test evidence against each requirement in the traceability matrix: SAST, DAST, penetration tests, leveraging the OWASP ASVS. Finally, transition/deployment pushes tested code to production under change control, increasingly via CI/CD: continuous integration builds and tests on each merge; continuous delivery moves code between environments with manual production deployment, while continuous deployment automatically releases every change that passes all tests. The CISSP's fundamental question: does the code that reached production match the tested code?

9.6 Operations, change/configuration management, and decommissioning

Once the system is in production, operations and maintenance/sustainment aim to monitor the health of the application, including monitoring for fraud and other attacks. Release notes list known errors and their workarounds, enabling support to respond to users. Service managers' processes embed the new system's incident response plan within a full ITSM wrapper (backup, recovery tests, DR). During production, all new code must be tested via the same processes that transition capability into production: security is never finished.

Change control governs any modification pushed to production. It is the central safeguard of the life cycle: it ensures changes are assessed, approved, traced, and reversible. Deployment passes through it, increasingly automated by the CI/CD pipeline. But the CISSP stays focused on the integrity and security of the end-to-end process: the fundamental question remains whether the code that reached production matches the tested code, and security controls on code control systems must reflect the highest data classification the code processes.

Configuration management relies, as zero days emerge, on a configuration management database (CMDB). It inventories components and their versions, so that as soon as a vulnerability is published, affected systems can be identified quickly and their remediation organized. Without a CMDB, the organization does not know where its vulnerable assets are.

Finally, decommissioning (retire and replace). The life cycle explicitly includes retiring and replacing the system when needs have changed. On the data side, 3.9 reminds us that physical copies must be suitably destroyed at the end of their retention period and useful life. Protection therefore does not stop at operations: a decommissioned asset must have its media secured or destroyed, its encryption keys managed and retired, and its access revoked. The guiding principle stays constant across the whole cycle: confidentiality, integrity, and availability must be preserved from design through to destruction.