Cybersecurity Engineering

Cybersecurity engineering is broader than operating individual security products. The central problem is to identify assets, trust boundaries, threats, and failure modes and then design, operate, and continuously validate a system that reduces risk to an acceptable level. Firewalls, endpoint protection, SIEM, IAM, penetration testing, and vulnerability scanners are tools inside that system; none of them is security by itself.

This course connects governance, architecture, identity, networks, platforms, applications, detection, incident response, and resilience. Application-level details are covered more deeply in Secure Software Engineering, while the evidence lifecycle belongs to Digital Forensics Engineering.

Unit 1: Cybersecurity as an Engineering Problem

Assets, threats, vulnerabilities, and risk

asset + threat + vulnerability + impact context -> risk

A vulnerability does not determine risk on its own. Exposure, exploit preconditions, business impact, data classification, existing controls, and recovery capability all matter.

The CIA triad remains useful:

• Confidentiality: preventing unauthorized disclosure,
• Integrity: preventing unauthorized or undetected modification,
• Availability: keeping required services usable when needed.

Engineering often adds authenticity, accountability, privacy, safety, and resilience. In cyber-physical systems, an incorrect command may matter more than disclosure of the command itself.

Cyberspace, cyber ecosystems, and attack surface

Cybersecurity is not limited to protecting computers connected to the public Internet. A useful distinction can be made among cyberspace, cyber ecosystems, and cyber terrain/topology. The distinction remains useful: cyberspace includes networks, devices, software, identities, data, and the physical infrastructure that supports them; the ecosystem also includes users, operators, suppliers, regulators, and adversaries.

An attack surface is therefore broader than exposed IP addresses. It includes at least:

• network services and protocols,
• user and service identities,
• administrative interfaces,
• client applications,
• import/export paths,
• supply-chain and update mechanisms,
• physical access,
• cloud and third-party integrations,
• human and operational processes.

A system can appear “closed” at the perimeter while remaining reachable through e-mail, removable media, software packages, or compromised credentials.

Distinguishing cybercrime, attack, threat, and risk

Cybercrime, cyberattack, threat, cyberwarfare, cyberespionage, cyberterrorism, and cyberextortion are separate concepts. They are not merely synonyms.

• A threat is a potential cause or actor capable of harming an asset.
• An attack is a concrete technical or operational action.
• A vulnerability is a weakness the attack may exploit.
• Risk combines threat, vulnerability, likelihood, and impact within a particular context.
• Cybercrime is a legal characterization and varies by jurisdiction.
• Cyberespionage emphasizes information acquisition, while cyberextortion uses coercion to obtain economic or other benefit.
• Cyberwarfare and cyberterrorism depend heavily on actor, purpose, context, and law rather than on any one technical method.

Engineering should begin with the technical question: which asset, behind which trust boundary, must resist which adversary capability and which unacceptable impact?

Threat-actor model

Calling every adversary a “hacker” produces weak designs. A threat-actor model should describe:

motivation
+ capability
+ access level
+ time / patience
+ resources
+ target knowledge
+ operational security

An insider, criminal group, supplier, automated opportunistic scanner, state-supported actor, and accidental misconfiguration do not call for the same controls. Rate limiting may be effective against Internet credential spraying, while a privileged insider requires separation of duties, strong audit, and independent approval.

Beyond confidentiality, integrity, and availability

The CIA triad remains foundational:

• Confidentiality: preventing unauthorized disclosure.
• Integrity: preventing unauthorized or undetected modification.
• Availability: making services and data available when authorized users need them.

Modern systems often need explicit treatment of:

• authenticity,
• accountability,
• evidence supporting non-repudiation claims,
• privacy,
• safety,
• resilience.

An industrial controller may prioritize integrity and safety, a health system must protect both privacy and availability, and a financial transaction system strongly depends on integrity and accountability.

Unit 2: Governance, Risk, and Security Economics

Governance and Cyber Risk Management

NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes around six concurrent functions:

GOVERN
IDENTIFY
PROTECT
DETECT
RESPOND
RECOVER

The explicit Govern function is a major CSF 2.0 change. Risk appetite, accountability, supply-chain expectations, policy, and investment decisions belong to organizational governance rather than only to a security operations team.

A defensible program should answer:

1. Which assets are critical?
2. Which adversaries and failure modes are credible?
3. Which risks are accepted, mitigated, transferred, or avoided?
4. Who owns each control?
5. Which measurement demonstrates that it works?
6. Who has decision authority during an incident?

Security Metrics and Engineering Economics

Metrics should support decisions. Useful examples include:

• coverage of critical assets,
• patch latency,
• MFA coverage,
• time to close high-risk findings,
• MTTD and MTTR,
• restore-test success rate,
• telemetry coverage and delay,
• excessive-privilege counts,
• supply-chain verification coverage.

Averages may hide queueing and tail behavior. In critical systems, p95 or p99 detection and recovery times can be more informative.

Security-investment trade-offs

Every control has costs: latency, CPU, operational complexity, user friction, licensing, and staffing. Security engineering seeks better risk reduction per unit of total cost without casually removing essential trust boundaries for performance.

Unit 3: Trust Boundaries, Security Architecture, and Threat Modeling

Trust Boundaries and Security Architecture

Security architecture should not assume that an “internal network” is inherently trustworthy. Every transition of data or authority can be modeled as a trust boundary.

user
  ↓ identity
client
  ↓ protocol
API / service
  ↓ authorization
data layer
  ↓
storage / external system

For each boundary, examine authentication, authorization, confidentiality, integrity, replay, failure behavior, and logging.

Least privilege and separation of duties

A service should access only the resources and operations required for its function and preferably only for the necessary duration. Separating administration, operation, and audit roles limits the damage of one compromised identity.

Zero Trust

Zero Trust is an architectural principle rather than a product. NIST SP 800-207 emphasizes access decisions based on identity, device, policy, resource, and context instead of automatic trust derived from network location. A VPN alone is not a Zero Trust architecture.

Threat Modeling and Attack Surface

Threat modeling is a design activity, not only preparation for a final penetration test.

assets
 ↓
data flows
 ↓
trust boundaries
 ↓
threats
 ↓
controls
 ↓
verification scenarios

STRIDE, attack trees, and abuse cases structure reasoning. The objective is to close high-impact attack paths, not to maximize the length of a threat list.

Attack surface includes more than internet ports: APIs, administration consoles, file formats, update channels, identity providers, package registries, e-mail, human processes, and physical interfaces all contribute.

Defense in depth and common-mode failure

Multiple controls provide true defense in depth only when their failure modes are sufficiently independent. Three products that depend on the same identity provider, management plane, or privileged account can fail together.

MFA + PAM + SIEM
      |
shared privileged management identity
      |
common compromise -> multiple controls affected

Control dependencies belong in the architecture model.

Design review and threat modeling

Before code exists, engineers can model assets, trust boundaries, attacker capabilities, and misuse paths. Authorization or isolation errors visible at design time are expensive to discover only through later fuzzing.

Unit 4: Identity, Authentication, and Authorization

Identity systems are often central attack surfaces. Account takeover, token theft, weak recovery, and excessive privilege can bypass otherwise strong network controls.

Authentication

Password security includes storage algorithms, rate limiting, breached-password handling, MFA, and account-recovery design. Complexity rules in isolation are not a complete policy.

Authorization

principal + action + resource + context -> decision

RBAC makes role-based decisions; ABAC uses attributes and policy. MAC and DAC represent different access-control models. Client-provided claims must not be treated as authoritative without server-side enforcement.

Privileged access

Administrative identities should be separated from routine accounts and protected through strong authentication, short-lived privilege, audit trails, and approval for high-impact actions where appropriate.

Separating authentication from authorization

Authentication and authorization are different security functions. Engineering requires a strict distinction:

• Authentication: establish who or what the subject is.
• Authorization: determine what the authenticated subject may do.
• Accounting/Auditing: record what was done.

Merging these functions creates authorization defects, especially in APIs, microservices, and distributed systems.

Authentication factors

The classical factor classes are:

• something you know,
• something you have,
• something you are.

Two steps are not automatically two factors. Two passwords still belong to one factor class. For phishing resistance, public-key approaches such as FIDO2/WebAuthn can offer materially stronger properties than reusable shared secrets.

Biometric security model

Biometric data is not a replaceable secret. Biometric verification has thresholds, false-accept rates, and false-reject rates. If a biometric template is compromised, the user cannot simply choose a new fingerprint or face. Biometrics should therefore be designed together with sensor trust, liveness detection, device binding, and additional authentication factors.

Access-control models

The source includes RBAC, ABAC, mandatory access control, and related models. They solve different problems:

• RBAC: maps permissions to organizational roles.
• ABAC: evaluates subject, resource, action, and environmental attributes.
• MAC: applies centrally enforced classification policy.
• DAC: permits controlled discretion by resource owners.

Large systems often combine models. A role can grant baseline access while attributes such as device trust, time, location, or data classification further constrain a decision.

Least privilege and separation of duties

Least privilege means granting the smallest set and duration of privilege necessary for the task. Just-in-time elevation, time-limited roles, and approval-based access follow directly from this principle.

Separation of duties prevents one individual from controlling an entire critical process. Payment creation and approval, code authoring and production release, or key generation and key use can be deliberately separated.

Unit 5: Network Foundations, Protocol Stack, and Network Defense

Network Security

Network security combines topology, protocols, segmentation, routing, name resolution, transport security, and observability.

Segmentation

The purpose of segmentation is to reduce the blast radius of a compromise, not merely to create VLANs.

client network -> application tier -> data tier
                       |
                  management plane

Flows should be justified and restricted by default.

Firewalls

Stateful firewalls track connection state; application-aware controls can inspect additional protocol context. No firewall automatically fixes broken authorization or unsafe application logic.

DNS, TLS, and VPNs

DNS is a security dependency because name resolution influences where clients connect. TLS protects confidentiality and integrity in transit when certificate validation and key management are correct. A VPN protects a path but does not automatically make a device or user trustworthy.

Why communication models matter to security

Communication, channels, encoding, noise, and feedback also have security implications. In security engineering these ideas become protocol questions:

who sends?
what is sent?
over which channel?
to whom?
under which identity?
with what integrity protection?
can the message be replayed?
what trust assumption governs the response?

Noise also has an operational meaning: detection systems must separate a low-volume malicious signal from high-volume legitimate activity.

Why networking fundamentals are security fundamentals

The source's OSI, Ethernet, IP, topology, IPv4/IPv6, and subnetting material is directly relevant to security design. Controls can only be placed correctly when engineers understand how data is represented and forwarded.

The OSI model is not a perfect picture of implementation; it is a useful decomposition model. For example:

• MAC addressing and VLAN behavior are primarily link-layer concerns,
• IP routing is a network-layer concern,
• TCP/UDP ports are transport-level concepts,
• HTTP, DNS, SMTP, and proprietary protocols operate at application layers.

Each layer exposes different security mechanisms and failure modes.

Ethernet and local-network security

A source or destination MAC address is not a strong identity. MAC spoofing is practical and modern clients may randomize addresses for privacy. Switched Ethernet still faces risks such as ARP poisoning, incorrect VLAN configuration, and unauthorized device attachment.

Local defense can combine:

• switch-port controls,
• VLAN segmentation,
• 802.1X/NAC,
• DHCP snooping and Dynamic ARP Inspection where appropriate,
• access logging,
• visibility into east-west traffic.

Security effects of IP addressing and subnetting

Subnetting is more than address conservation; it can help express trust boundaries. Management, user, server, production, and guest networks can be separated. A VLAN boundary alone, however, is not an access-control decision. Traffic between segments should pass through an enforcement point or equivalent distributed policy.

IPv6 changes some scanning assumptions but does not eliminate the security problem. Neighbor Discovery, Router Advertisement, dual-stack behavior, and fallback paths need explicit treatment.

Topology and common failure points

Bus, star, ring, tree, mesh, and hybrid topologies can be interpreted in security terms by asking which compromise or failure can affect which region.

A centralized star design can simplify management while creating a critical hub. Mesh designs can improve availability but create more trust relationships and policy complexity. Security architecture should consider topology together with availability and blast radius.

DNS security

DNS is not merely a convenience service. It can support reconnaissance, command-and-control, phishing, and data exfiltration. Defensive design includes:

• controlled resolver use,
• query/response logging,
• DNSSEC validation where appropriate,
• avoiding reputation-only decisions,
• monitoring unusual high-entropy or long queries,
• correct separation of internal and external DNS roles.

TCP/UDP and state

TCP maintains connection state; UDP is connectionless. This matters for firewall and IDS behavior. A stateful firewall can make decisions based on connection state, but malicious application content can still travel through a valid TCP session. Transport validity is not application security.

Firewall architecture

A firewall is a policy-enforcement point, not a device that “makes the Internet safe.” Packet filters, stateful firewalls, application proxies, and next-generation firewalls inspect different amounts of context. Good rule design generally favors:

• default deny,
• opening only what is required,
• explicit source/destination/service scope,
• expiration for temporary rules,
• removal of shadowed or obsolete rules,
• auditable change control,
• separation of management and data planes.

An any-any rule is not only broad access; it also makes it harder to determine which flows were expected during incident analysis.

NAT is not an access-control mechanism

NAT can hide internal addressing from direct external use, but it does not replace policy enforcement. Port forwarding, state tables, outbound sessions, and proxies make “NAT means firewall” a false assumption. Address translation and authorization solve different problems.

VPN and tunnel security

A VPN protects traffic between endpoints; it does not prove that either endpoint is trustworthy. A compromised client can carry apparently legitimate traffic through the tunnel. VPN design therefore includes identity, device posture, access scope, split tunneling, certificate/key lifecycle, and logging.

DoS and DDoS engineering

Denial of service can exhaust different resources:

• bandwidth,
• connection/state tables,
• TLS handshake CPU,
• thread or connection pools,
• database execution,
• disk or queues,
• expensive API operations.

Mitigation must match the bottleneck: rate limits, connection limits, caching, per-request budgets, circuit breakers, upstream filtering, and horizontal scaling solve different failure modes. Capacity testing should measure saturation behavior and tail latency, not only average throughput.

Spoofing and source identity

IP addresses, MAC addresses, e-mail From fields, and HTTP headers are not inherently trustworthy identities. Source verification must depend on the actual guarantees of the protocol and surrounding control plane. Reverse DNS or client IP is often insufficient as an identity mechanism, especially through proxies and NAT.

ARP, DHCP, and local-network attacks

ARP lacks authentication and can be poisoned. Rogue DHCP can distribute malicious gateways or DNS servers. Defense may include DHCP snooping, Dynamic ARP Inspection, port security, and 802.1X in addition to endpoint security.

Wireless-network security

Wireless networks remove the physical cable boundary. Hidden SSIDs are not a security control. WPA2/WPA3 configuration, enterprise authentication, sound EAP methods, certificate validation, and guest/corporate separation matter. Evil-twin access points become particularly effective when clients fail to validate the authentication server.

Protocol Stacks and Attack Surface

Protocol knowledge is not only a networking concern. Security engineers need to understand which layer a control can observe, because a control cannot reliably protect what it cannot interpret. The OSI model is not a literal blueprint of modern applications, but it remains useful for separating responsibilities.

Trust assumptions across layers

A simplified path is:

application data
 -> transport (TCP/UDP/QUIC, etc.)
    -> network (IP)
       -> link (Ethernet/Wi-Fi)
          -> physical medium

Each layer depends on assumptions about lower layers. TLS does not eliminate ARP spoofing on a local network, but correct certificate validation and end-to-end encryption can limit what a local attacker learns from transport interception. Likewise, segmentation does not repair a broken application authorization model.

Ethernet, MAC addresses, and local trust

A MAC address is not a trustworthy user identity. It can be spoofed and a single device may use different addresses on different interfaces. Switch forwarding tables, VLANs, and port controls affect local behavior. A VLAN is not a cryptographic trust boundary; trunk misconfiguration or management-plane compromise can defeat isolation.

IPv4/IPv6 and filtering

An IP address is context, not identity. Many clients may share one external address behind NAT, and dynamic assignments change over time. IPv6 introduces large address spaces, link-local addressing, Neighbor Discovery, and multiple simultaneous addresses. Controls written under IPv4-only assumptions can leave IPv6 as an unintended policy path.

Filtering can evaluate protocol, direction, session state, application identity, and—where available—user and device context in addition to source and destination addresses.

TCP state and security

A TCP connection is more than “an open port.” Handshake state, sequence numbers, retransmission, windows, and close behavior affect how security devices reason about sessions. Stateful firewalls have more context than static ACLs, but their state tables also become resources that can be exhausted under attack.

UDP is connectionless, yet DNS, NTP, QUIC, and many real-time systems depend on it. “UDP is connectionless, therefore insecure” is not a valid conclusion; upper-layer protocols can provide authentication, confidentiality, and reliability properties.

DNS as a security dependency

DNS influences where users and applications connect. Cache poisoning, bad delegation, compromised authoritative infrastructure, or client resolver manipulation can redirect traffic. DNSSEC provides cryptographic origin/integrity validation for DNS data; it does not provide confidentiality and does not make a malicious but correctly signed domain trustworthy.

Enterprise DNS is also valuable telemetry. Newly observed domains, abnormal query volume, DGA-like patterns, and unexpected external resolvers can be useful signals.

Application protocols and plaintext legacy

Protocols such as HTTP, SMTP, FTP, and Telnet were created in environments where security was often added later. Modern assessment must consider not only whether encryption exists, but also downgrade paths, certificate validation, credential exposure, session management, and metadata leakage.

Management protocols belong on a stronger trust boundary. Exposing infrastructure management interfaces to ordinary user networks can turn one application compromise into control-plane compromise.

Egress control

A defense that watches only inbound traffic can miss command-and-control and exfiltration after compromise. Egress policy defines which external services and protocols a system actually needs. Excessively strict policy can break operations; unrestricted outbound traffic gives an attacker unnecessary freedom.

Unit 6: Endpoint and Platform Security

Operating systems, hypervisors, container runtimes, and firmware form the trust base below applications.

Typical controls include:

• supported and patched versions,
• least-privileged service identities,
• disabled unnecessary services,
• hardened defaults,
• application allowlisting where justified,
• disk encryption,
• trusted boot,
• endpoint telemetry,
• configuration-drift detection.

Hardening is not a one-time installation step. Expected configuration should be continuously compared with actual state.

Unit 7: Application, API, Software Vulnerabilities, and Runtime Defense

Application and API Security

OWASP Top 10 is an awareness document, not a complete verification standard. As of 2026, the current released edition is OWASP Top 10:2025, led by Broken Access Control, Security Misconfiguration, and Software Supply Chain Failures.

Major application-risk classes include access-control defects, misconfiguration, supply-chain compromise, cryptographic failures, injection, insecure design, authentication failures, software/data integrity failures, logging and alerting failures, and mishandling of exceptional conditions.

Threat modeling, XSS, SQL injection, SSRF, CSRF, OAuth/OIDC, CI/CD security, and generative-AI application security are treated in depth in Secure Software Engineering.

Classifying software vulnerabilities

The source groups software weakness around memory management, structured-output/injection, race conditions, and side channels. These remain durable classes even as specific technologies change.

Memory safety

Use-after-free, out-of-bounds access, and buffer overflow remain important in memory-unsafe environments. Controls include memory-safe languages where suitable, safer APIs, compiler hardening, ASLR/DEP, sanitizers, and fuzzing.

Injection and structured output

SQL, shell, LDAP, XPath, and template injection share a boundary failure between code and data. Escaping lists alone are fragile; parameterized or structural APIs are preferable.

Race conditions

TOCTOU flaws and concurrent state changes can invalidate security decisions. A check and the protected operation should not be separated by an attacker-controllable window.

Side channels

Timing, power, cache behavior, error messages, and packet sizes can leak information. Cryptographic implementations therefore care about constant-time behavior and controlled failure responses.

Prevention, detection, and mitigation

The source separates three approaches:

1. Prevention: make classes of defect harder to create using language choice, type systems, safe APIs, and secure defaults.
2. Detection: SAST, DAST, SCA, fuzzing, code review, and testing.
3. Mitigation: limit impact when defects remain through sandboxing, least privilege, exploit mitigations, and segmentation.

They are complementary layers. A scanner is not a substitute for secure design.

Runtime defense

Sandboxing, OS privilege boundaries, container isolation, seccomp-style restrictions, and application authorization can reduce blast radius. A sandbox accepted as a security boundary must itself be threat-modeled for escape paths and host privileges.

Trusted and measured boot

Trusted/measured boot records or validates the system's boot chain. It does not make compromise impossible; it provides additional evidence about startup state and critical components. TPM-backed measurements can support attestation scenarios.

Web-session security

After login, web identity is usually represented by a cookie or token. Theft of that value can bypass password knowledge. Controls include:

• high-entropy session identifiers,
• mandatory TLS,
• Secure, HttpOnly, and appropriate SameSite,
• session rotation after authentication,
• logout and expiration,
• reauthentication for critical actions.

CSRF versus XSS

XSS executes attacker-controlled script in a victim's browser context. CSRF causes the browser to send authenticated requests on the victim's behalf. They are different problems. XSS can often bypass CSRF defenses, so output encoding/CSP and CSRF tokens/SameSite controls address different threat classes.

File-upload security

File extensions are insufficient validation. Content type, magic bytes, size, archive expansion, path traversal, and parser risk must be considered. Uploaded content should not become executable inside the web root; expensive parsing should run in isolated workers with explicit resource budgets where practical.

Software-integrity controls

The source treats software integrity as a separate concern. Modern practice extends beyond manually comparing hashes to signed artifacts, provenance, SBOMs, trusted build pipelines, and deployment verification. A signed package is not automatically safe if the signing key or build process is compromised.

Runtime mitigation

ASLR, DEP/NX, stack canaries, CFI, sandboxing, and privilege reduction can make exploitation harder or reduce impact. They do not repair the underlying defect. Defense should combine mitigation with actual remediation.

Unit 8: Cryptographic Engineering and the Key Lifecycle

Cryptography and Key Management

Different primitives solve different problems:

encryption -> confidentiality
hash       -> digest / integrity checking
MAC        -> integrity + shared-secret authentication
signature  -> integrity + private-key authentication

Key lifecycle is often more important than algorithm branding. Generation, storage, access, rotation, backup, revocation, and destruction must be designed.

“Encryption is enabled” is not a sufficient security statement. Modes, nonces, certificate validation, key access, and error behavior matter.

TLS and PKI

TLS protects confidentiality and integrity in transit; binding the channel to the intended server or client depends on certificate validation. Certificate chain, hostname verification, validity period, key usage, and revocation behavior matter.

root CA
  ↓
intermediate CA
  ↓
leaf certificate
  ↓
private key + identity binding

Protecting the private key is more important than protecting the public certificate. Reusing one private key across many hosts increases blast radius.

Separate cryptographic objectives

Cryptography contains different primitives:

• symmetric encryption provides confidentiality,
• MAC/HMAC provides integrity and authentication,
• hashing produces a fixed-size digest,
• digital signatures support integrity and signer-key verification,
• key agreement derives shared secrets.

A hash is not encryption and has no decryption key. Password storage should use salted, deliberately expensive password KDFs rather than fast general-purpose hashes.

Key management can be harder than algorithm selection

A strong algorithm fails under poor key management. The lifecycle includes:

generation -> distribution -> storage -> use -> rotation -> revocation -> destruction

Secrets embedded in source code, logs, or configuration repositories remain severe weaknesses regardless of algorithm strength. HSMs, TPMs, secure enclaves, and centralized secret managers can form trust boundaries appropriate to different use cases.

Cryptographic agility

Algorithms and key sizes should not be assumed permanent. Cryptographic agility allows controlled migration when standards or threat models change. Agility should not mean exposing arbitrary weak algorithm selection at runtime; the supported profile must remain constrained.

Collision resistance versus password guessing

The collision examples in the source illustrate an important distinction. A hash collision is two inputs producing the same digest. Password guessing compares candidate passwords against stored verification material. A collision weakness does not automatically mean all password hashes can be inverted efficiently.

Cryptographic engineering is more than choosing an algorithm. A strong primitive can be undermined by a bad protocol, nonce reuse, weak key storage, or incorrect certificate validation.

Roles of symmetric and asymmetric cryptography

Symmetric encryption is efficient for high-volume data but requires parties to share secret key material. Asymmetric mechanisms can solve key-establishment and digital-signature problems at greater computational cost. Modern protocols are commonly hybrid:

asymmetric/key agreement
 -> session key
    -> symmetric authenticated encryption

A digital signature does not provide confidentiality. Encryption by itself may not provide integrity. AEAD constructions are designed to provide confidentiality and authenticated integrity together.

Hashes, MACs, and password derivation

A cryptographic hash is unkeyed. A MAC uses a secret key. Password storage is a different problem and should use a password-oriented, deliberately expensive KDF rather than a fast general-purpose hash. A salt prevents identical passwords from producing identical stored values; it does not make guessing impossible.

Nonce and IV reuse

For many modes, nonce or IV uniqueness is part of the security assumption. Reusing a nonce under the same key can catastrophically damage confidentiality or integrity in stream/AEAD constructions. Nonce generation is therefore protocol design, not an incidental call to a random-byte function.

PKI and certificate validation

An X.509 certificate does not mean “this server is safe.” It binds a key to an identity under a trust chain. A client must validate:

• chain construction,
• hostname/SAN matching,
• validity period,
• relevant key-usage/policy constraints,
• revocation status where required.

Training users to bypass certificate warnings as a normal workflow destroys the trust model.

Key lifecycle

Key security spans:

generation -> distribution -> storage -> use -> rotation -> revocation -> destruction

Secrets embedded in source repositories, long-lived shared credentials, or uncontrolled backup copies weaken a system even when the algorithm is strong. HSM/KMS-style services can reduce direct exposure of keys, but authorization and audit remain necessary.

Cryptographic agility — deeper treatment

Algorithms, key sizes, and protocols evolve. Hard-wiring one cryptographic choice into persistent data structures and business logic creates migration debt. Agility means versioned, planned transition—not arbitrary runtime algorithm selection.

Unit 9: Vulnerability Management, Vulnerability Discovery, and Assurance Techniques

Vulnerability and Patch Management

Vulnerability management is a lifecycle:

inventory
 -> discovery
 -> validation
 -> contextual risk
 -> ownership
 -> remediation / mitigation
 -> retest
 -> closure

CVSS helps describe technical severity, but business value, exposure, exploit availability, and compensating controls determine local priority.

Patch management contains two risks: leaving known vulnerabilities unresolved and destabilizing production through uncontrolled change. Testing, phased rollout, rollback, and maintenance windows are therefore security controls as well as operational practices.

Vulnerability management is not a scanner queue

CVE and CVSS provide common vocabulary, but local priority cannot be derived from CVSS alone. Internet exposure, exploit availability, asset criticality, prerequisites, compensating controls, and business impact all matter.

technical severity
× exposure
× exploitability
× asset value
× control effectiveness
→ local risk priority

Patch management and change risk

Failing to patch creates risk; untested patching can also create risk. Critical environments can use:

1. inventory and affected-version detection,
2. technical/business risk assessment,
3. testing,
4. staged rollout,
5. rollback planning,
6. verification,
7. exception and compensating controls.

Vulnerability Discovery and Security Assurance

Vulnerability engineering can be separated into classification, prevention, detection, and mitigation. That remains a useful engineering distinction because no single technique can find or prevent every defect.

Static analysis

Static analysis inspects source or intermediate code without normal execution. Data flow, control flow, taint, type systems, and pattern rules can identify candidate defects. Its advantage is broad path coverage; its cost is false positives and model limits. Findings need contextual prioritization.

Dynamic analysis and sanitizers

Dynamic techniques observe actual executions and can expose memory violations, races, and undefined behavior. They see only executed paths, so coverage and input quality are critical.

Fuzzing

Fuzzing is especially effective against parsers and protocol surfaces. Structure-aware or coverage-guided fuzzers use knowledge of input grammar or execution coverage. A crash is not automatically remote code execution, but it is a reproducible anomaly that deserves security triage.

A mature fuzzing pipeline retains deterministic seeds, deduplicates and minimizes crashes, and produces reproducible test cases. “Inputs per second” alone is not a quality metric.

Unit 10: Detection, Telemetry, Security Operations, and Measurability

Detection, Telemetry, and Security Operations

Useful detection starts with meaningful data sources:

• identity providers,
• operating systems,
• EDR,
• DNS,
• firewalls and proxies,
• application audit logs,
• databases,
• cloud control planes,
• flows and packet capture where justified.

IDS/IPS and SIEM

IDS/IPS systems detect patterns or behavior; SIEM platforms aggregate, normalize, and correlate events. Collecting more logs does not automatically create better detection. Semantic quality, time synchronization, retention, and low-noise rules matter.

MITRE ATT&CK

ATT&CK organizes adversary behavior into tactics and techniques. It is not a risk score or product checklist. A useful application is visibility mapping: which behaviors are observable, and where are the blind spots?

Accountability and trustworthy logging

The source emphasizes logs as a basis for accountability. A strong logging design requires:

• a consistent time source,
• identity and session context,
• protection from unauthorized modification,
• centralized collection,
• access control,
• retention policy,
• scalable search and correlation.

Logs alone do not create accountability. Shared accounts, shared API keys, and clock drift make attribution difficult.

Threat intelligence and telemetry

Threat intelligence is more than a list of IOCs. Strategic, operational, tactical, and technical intelligence differ in purpose. IP/domain/hash indicators can decay quickly, while behavior and TTP information often lasts longer. Intelligence becomes useful when mapped to the organization's assets and detection capabilities.

SIEM and correlation

A SIEM collects and correlates events; it cannot turn semantically poor logs into reliable evidence. Engineers must first understand time, identity, field meaning, and missing-record behavior. Coverage of high-value attack paths is more useful than an ever-growing count of generic rules.

IDS/IPS boundaries

Signature-based detection is strong against known patterns; anomaly methods can identify new variants but typically produce more false positives. An IPS can interrupt service when it makes a wrong decision, so blocking policy must account for availability risk as well as detection accuracy.

Continuity and Measurability in Security Operations

Security operations should reduce unacceptable risk, not merely generate alerts. Metrics should therefore emphasize detection quality, response delay, and control effectiveness rather than raw alert volume.

Telemetry quality

Collecting logs is not the same as observability. Reconstructing events requires consistent identity, time, source, destination, action, and outcome fields. Clock synchronization and stable event identifiers are core correlation dependencies.

Event, signal, alert, and case

raw event
 -> signal
    -> alert
       -> correlated case
          -> confirmed incident

Not every event should become an alert. Otherwise analyst capacity is consumed by noise. Detection engineering defines the intended threat behavior, required data sources, known false-positive causes, and test cases for a rule.

Limits of MTTD and MTTR

Mean detection or response time can hide long-tail incidents. A team may close most alerts quickly while one severe compromise remains undetected for days. Percentiles and severity-stratified measures often expose the operational distribution more clearly.

Unit 11: Incident Response, Recovery, and Secure Return to Service

Incident Response

NIST SP 800-61 Rev. 3, finalized in April 2025, superseded Rev. 2 and reframed incident response as a risk-management capability spanning CSF 2.0.

A practical flow remains recognizable:

preparation
 ↓
detection and validation
 ↓
containment
 ↓
eradication
 ↓
recovery
 ↓
learning and improvement

Containment decisions affect business continuity and evidence. Immediately powering down a compromised system may stop damage but can also destroy volatile evidence. Digital Forensics Engineering covers that trade-off in detail.

Incident response versus digital forensics

Incident response prioritizes limiting attacker impact and protecting service. Digital forensics places stronger emphasis on repeatable evidence analysis. The goals can conflict: powering down a system can stop damage while destroying volatile evidence. Containment decisions therefore balance business impact, security impact, and evidential value.

Trusted recovery

Recovery is more than restarting servers. Restoring before root cause and persistence are removed can reintroduce the adversary. Trusted recovery combines:

• clean or verified images,
• credential rotation,
• persistence checks,
• vulnerability remediation,
• increased monitoring,
• data-integrity verification.

Unit 12: Malware, Botnets, Ransomware, and Persistence

Malware, Ransomware, and Persistence

Malware labels describe behaviors and objectives rather than mutually exclusive categories. A sample can simultaneously be a downloader, credential stealer, persistence mechanism, and ransomware component.

Ransomware resilience requires more than antivirus:

• reduce initial-access paths,
• constrain privilege escalation,
• restrict lateral movement,
• protect high-value identities,
• maintain isolated or immutable backups,
• test restoration,
• detect and isolate rapidly.

A backup is not a recovery capability until restoration time and integrity have been tested.

Malware, Botnets, and Persistence Engineering

Malware has historically been labeled as viruses, worms, Trojans, rootkits, spyware, and ransomware. Modern samples can combine several behaviors, so defenders often gain more value by modeling capabilities rather than relying only on family labels.

Behavioral dimensions

A malicious component may combine:

• execution,
• privilege escalation,
• credential access,
• persistence,
• discovery,
• lateral movement,
• command and control,
• collection,
• exfiltration,
• impact.

This model allows controls to map to behavior instead of a product or malware family name.

Persistence

Persistence varies across operating systems and application ecosystems: startup mechanisms, scheduled tasks, services, extensions, credentials, cloud access keys, and authorized application integrations can all become persistence channels. The deeper question is not simply “which malicious file remains?” but “which trust relationship gives the attacker renewed access?”

Rootkits and visibility

Rootkits attack the reliability of the defender's observation mechanism. A tool running inside the same compromised host can receive a manipulated view from user-space or kernel-level hooks. High-assurance investigations may therefore correlate several observation planes:

host telemetry
+ network telemetry
+ hypervisor/EDR view
+ trusted external acquisition

Independent perspectives reduce common blind spots.

Botnet architecture

A botnet coordinates many compromised nodes under attacker control. Centralized command and control is easier to operate but can be fragile if key servers are removed. P2P or multi-tier C2 can increase resilience. Domain generation, fast flux, proxy chains, and abuse of legitimate cloud services can complicate detection.

Botnets are not limited to DDoS. They can provide spam, credential theft, proxy services, cryptomining, or data theft.

DDoS as a resource problem

DDoS attacks can exhaust different resources:

• network bandwidth,
• connection state,
• TLS/cryptographic CPU,
• application threads,
• database connections,
• third-party quotas or cost budgets.

Defenses must match the exhausted resource. Rate limiting, SYN protection, CDN/Anycast, caching, queue bounds, and application-cost controls solve different problems.

Long-running targeted operations

“APT” is not one tool or malware type. It is a framing for sustained, objective-driven threat operations with meaningful resources. For defense, the useful questions are dwell time, goals, techniques, and detection/response capability rather than the label itself.

Attack progression is rarely perfectly linear. An adversary can move repeatedly among discovery, credential access, persistence, and lateral movement. Defenses therefore need multiple opportunities for detection and interruption.

Unit 13: Cloud, Mobile, IoT, OT, Distributed, and Cyber-Physical Security

Cloud, Mobile, IoT, and OT Security

Cloud security depends on the shared-responsibility boundary, which differs across IaaS, PaaS, and SaaS. Identity and control-plane events can be more important than the traditional network perimeter.

Mobile security combines application sandboxing, hardware-backed keys, device integrity, local storage, and backend API controls.

IoT and OT environments add constraints such as long device lifecycles, limited update capacity, real-time requirements, physical consequences, legacy protocols, and safety obligations. Patching an industrial controller is not operationally equivalent to patching a stateless web server.

Trust in distributed systems

The source devotes substantial attention to decentralized P2P systems, clustering, coordination, and distributed-system vulnerabilities. Security is not achieved by hardening each node independently. Inter-node identity, message integrity, replay handling, membership, and coordination protocols are themselves trust boundaries.

Representative threats include:

• Sybil attacks using many false identities,
• Eclipse attacks that isolate a node behind adversary-controlled peers,
• routing attacks,
• pollution or index poisoning,
• collusion among malicious nodes,
• denial of service against resources or coordination mechanisms.

CAP is not a security theorem

The source connects consistency, availability, and partition behavior with attack scenarios. A conceptual boundary is important: CAP is not itself a security theorem. It describes behavior under network partition. An adversary can nevertheless create or exploit partition-like conditions, making architectural trade-offs visible during a security incident.

Consensus and commit protocols

Two-phase commit coordinates atomic transactions but is not a Byzantine-fault-tolerant security protocol. Raft/Paxos-family designs generally address crash-fault assumptions, while Byzantine-fault-tolerant systems use different fault models. Security properties must be derived from the protocol's actual assumptions.

Security and safety in cyber-physical systems

The source covers CPS domains such as aerospace, automotive, energy, healthcare, manufacturing, and building automation. Cyber incidents in these systems can produce physical consequences. The problem becomes:

cybersecurity risk
      +
physical process state
      +
safety constraint
      +
real-time requirement
      = CPS security problem

A firewall or inspection gateway can itself influence latency and deterministic timing, so security changes require engineering validation against process constraints.

Defense layers for CPS

Useful layers include:

• physical access control,
• IT/OT segmentation,
• secure remote access,
• protocol and asset inventory,
• allow-listing,
• passive network visibility,
• controlled change management,
• verified backups and recovery,
• plans for transitioning to a safe physical state.

“Patch immediately” can be infeasible when production downtime, certification, or vendor support is constrained. Compensating controls then become essential.

Critical Infrastructure and Sector Security

Cyber effects in energy, transportation, communications, healthcare, and other critical sectors can produce physical or societal consequences. In these environments, confidentiality is only one objective; safety, continuity, and physical-process integrity may dominate.

IT versus OT constraints

In enterprise IT, patching or restarting a host can be ordinary maintenance. In OT/CPS environments the same action can stop production or affect a safety function. Long-lived devices and legacy protocols may lack modern authentication or encryption.

OT defenses commonly rely on:

• asset inventory,
• zones and conduits / segmentation,
• controlled remote access,
• allow-listing where feasible,
• passive visibility,
• disciplined change control,
• secure maintenance procedures,
• independent safety layers.

Safety versus security

Safety engineering prevents hazardous physical states. Security controls unauthorized or malicious behavior. They interact but are not the same problem. Because a cyberattack can target a safety system, cyber risk analysis must include credible physical hazard scenarios.

Physical access

Ports, cabinets, serial links, maintenance laptops, and removable media can be as important as network controls. “Not connected to the Internet” is not a security architecture when vendor maintenance paths or portable media still cross the boundary.

Sector-specific risk

Technical severity alone is insufficient. Physical process impact, human safety, environmental consequences, production loss, regulation, and recovery time affect risk. The same software flaw can be moderate on an office workstation and unacceptable on a safety-critical controller.

Unit 14: Software and Supply-Chain Security

The real software supply chain includes far more than source code:

source code
+ dependencies
+ compiler
+ build runner
+ package registry
+ base image
+ deployment manifest
+ firmware
= actual supply chain

An SBOM improves visibility but does not automatically establish trust. Package provenance, signatures, build isolation, secret management, dependency policy, and update processes remain necessary.

NIST SSDF v1.1 is the current final SSDF publication. NIST published Version 1.2 as an initial public draft in late 2025; draft and final status should not be conflated.

SCA, inventories, and SBOMs

Modern applications depend on direct and transitive third-party components. Software Composition Analysis can provide visibility into versions, known vulnerabilities, and licensing. An SBOM is a shareable representation of the component inventory. Neither proves that an application is secure; both are inputs to risk management.

Build and source integrity

Source repositories, CI systems, package registries, build agents, and signing keys are part of the software supply chain. A secure codebase can still be compromised through an untrusted build path.

A stronger pipeline is:

reviewed source
 -> controlled build
    -> dependency verification
       -> signed artifact
          -> signature/policy validation at deployment

Unit 15: People, Culture, Social Engineering, Espionage, and Threat Intelligence

People, Process, and Social Engineering

Calling people “the weakest link” can hide design failures. Secure processes should limit the impact of predictable human error.

For example, a high-risk payment change that requires an independent verification channel is more resilient to phishing than a process that accepts e-mail instructions alone.

Awareness training should be combined with MFA, transaction verification, separation of duties, permission boundaries, and anomaly detection.

Human factors are part of the system

The source treats governance, culture, awareness, education, and testing as distinct human-security concerns. Describing users as the “weakest link” can hide design failures. Secure systems should not require exceptional vigilance for routine operation.

Good security UX tends to:

• make critical warnings rare and meaningful,
• use secure defaults,
• make phishing-resistant authentication usable,
• support recovery from mistakes,
• reduce security fatigue.

Awareness, education, and exercises

Awareness means recognizing that a threat exists; education teaches correct behavior; exercises develop the ability to act under pressure. Phishing simulations and tabletop exercises should reveal process friction and incentive problems rather than merely produce failure percentages.

Insider threat and industrial espionage

Valuable assets include research, manufacturing recipes, engineering designs, pricing, bid strategy, customer data, and source code—not only passwords and personal information. Insider risk can be malicious or accidental. Controls can include:

• data classification,
• need-to-know access,
• DLP and telemetry,
• privileged-access control,
• joiner/mover/leaver processes,
• monitoring sensitive export channels.

Social engineering is also a technical-control problem

Training alone cannot solve social engineering. E-mail authentication, phishing-resistant MFA, out-of-band approval for critical changes, macro/script controls, safe document handling, and least privilege reduce the amount of damage that one deceptive message can cause.

Unit 16: Resilience, Continuity, and Integrated Security Engineering

Resilience and Conclusion

Perfect prevention is not realistic. A strong security system aims to:

make attack harder
detect early
limit blast radius
preserve evidence
recover safely
feed root cause back into design

Cybersecurity engineering is therefore a discipline of system design and risk management under uncertainty. Products and attack techniques evolve, but asset visibility, explicit trust boundaries, least privilege, defense in depth, observability, incident readiness, and verified recovery remain durable principles.

Cyber resilience

Resilience is the ability to continue critical service at an acceptable level during attack and recover to a trusted state. Core capabilities include:

• inventory of critical assets and dependencies,
• offline or immutable backups,
• tested restoration,
• segmentation,
• alternate communication paths,
• predefined incident roles and decision authority,
• explicit RTO/RPO,
• post-incident learning.

Creating backups and successfully restoring service are different capabilities; untested backups are not a resilience guarantee.

Backup resilience against ransomware

Having backups does not guarantee recoverability. Backup credentials should be isolated where practical, destructive access should be constrained, and restores should be tested. If an attacker controls the backup management identity, the number of copies alone does not create resilience.

Business continuity and disaster recovery

Business Continuity aims to preserve business functions; Disaster Recovery focuses more directly on restoring technology and data services. RTO represents an acceptable service-outage target and RPO an acceptable data-loss window. These objectives drive architecture and cost; “zero loss and zero downtime” can be prohibitively expensive or physically unattainable.

Exercises and verification

A tabletop exercise, technical failover test, and real restore test validate different things. Critical systems should seek evidence that recovery procedures work, not merely that documents exist. Exercise findings should become tracked remediation work.

References

• Center for Internet Security. CIS Critical Security Controls v8.1. https://www.cisecurity.org/controls/v8-1
• ISO/IEC 27001:2022. Information security management systems — Requirements. https://www.iso.org/standard/27001
• MITRE. ATT&CK. https://attack.mitre.org/
• NIST. Cybersecurity Framework (CSF) 2.0, 2024. https://www.nist.gov/cyberframework
• NIST SP 800-53 Rev. 5. Security and Privacy Controls for Information Systems and Organizations. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
• NIST SP 800-61 Rev. 3. Incident Response Recommendations and Considerations for Cybersecurity Risk Management, 2025. https://csrc.nist.gov/pubs/sp/800/61/r3/final
• NIST SP 800-160 Vol. 1 Rev. 1. Engineering Trustworthy Secure Systems. https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final
• NIST SP 800-207. Zero Trust Architecture. https://csrc.nist.gov/pubs/sp/800/207/final
• NIST SP 800-218. Secure Software Development Framework (SSDF) Version 1.1. https://csrc.nist.gov/pubs/sp/800/218/final
• OWASP Foundation. OWASP Top 10:2025. https://top10.owasp.org/2025/
• RFC 8446. The Transport Layer Security (TLS) Protocol Version 1.3. https://www.rfc-editor.org/rfc/rfc8446
• Ross Anderson. Security Engineering. 3rd ed., Wiley, 2020.