Course audit report

Computer and Data Security

Done Role: Security Engineer 4 Findings Computer Security — Principles, Management, And Defensive Controls
Auditor Done Market Fit Done Topics Done
Run another role
4 findings · 2 high 2 medium
Outdated chapter2.pptx, Slide 24 (speaker notes, 'Asymmetric Encryption Algorithms (1 of 2)')

What the slide says

"Currently, a 1024-bit key size (about 300 decimal digits) is considered strong enough for virtually all applications."

Primary source ✓ Source checked

nvlpubs.nist.gov

FIPS 186-5 §5.1: "This standard specifies the use of a modulus whose bit length is an even integer and greater than or equal to 2048 bits."

What to learn instead

Teach RSA modulus sizes ≥ 2048 bits as the current minimum (FIPS 186-5, Feb 2023; NIST SP 800-131A Rev. 2 disallowed 1024-bit RSA generation in 2014). For new deployments, 3072-bit (112-bit security) or larger is preferred, and ECC (e.g., P-256/P-384) gives equivalent strength at much smaller key sizes.

Security risk chapter3.pptx, Slide 15 ('Improved Implementations') and speaker notes

What the slide says

"Recommended hash function is based on MD5… Uses an inner loop with 1000 iterations to achieve slowdown… The recommended hash function for many UNIX systems, including Linux, Solaris, and FreeBSD, is based on the MD5 secure hash algorithm (which is similar to, but not as secure as, SHA-1)."

Primary source ✓ Source checked

pages.nist.gov

NIST SP 800-63B §5.1.1.2: "Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function… Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2)… and Balloon. A memory-hard function SHOULD be used… For PBKDF2… the iteration count SHOULD be as large as verification server performance will allow, typically at least 10,000 iterations." The KDF must use "an approved one-way function" — MD5 is not in the SP 800-107 approved list.

What to learn instead

Teach modern password-hashing KDFs: Argon2id (winner of PHC 2015), scrypt, or bcrypt as preferred; PBKDF2-HMAC-SHA256 with ≥600,000 iterations as a FIPS-approved fallback. Drop the description of md5crypt as 'recommended' — it has been considered obsolete in glibc since 2012, and MD5 is not an approved KDF primitive under NIST SP 800-63B.

Outdated chapter2.pptx, Slide 24 / Slide 27 (speaker notes, 'Digital Signature Standard')

What the slide says

"The DSS makes use of SHA-1 and presents a new digital signature technique, the Digital Signature Algorithm (DSA)... most recently in 2013 as FIPS 186-4. FIPS 186-4 specifies the use of one of three digital signature algorithms: Digital Signature Algorithm (DSA), RSA Digital Signature Algorithm, Elliptic Curve Digital Signature Algorithm (ECDSA)."

Primary source ✓ Source checked

nvlpubs.nist.gov

FIPS 186-5 (Feb 3 2023), Section 4: "The Digital Signature Algorithm (DSA) is no longer specified in this standard and may only be used to verify previously generated digital signatures." The standard supersedes FIPS 186-4 and approves only RSA, ECDSA, and EdDSA.

What to learn instead

Teach FIPS 186-5 (current standard): DSA is retired; approved signature schemes are RSA (PKCS#1 v2.2 / PSS), ECDSA, and EdDSA (Ed25519/Ed448). Use SHA-2 or SHA-3 — SHA-1 is being phased out by NIST for all signature uses by 2030.

Outdated chapter2.pptx, Slide 18 (speaker notes, 'Security of Hash Functions') / Chapter 3 Slide 15 'similar to, but not as secure as, SHA-1'

What the slide says

Treats MD5 and SHA-1 as merely 'inadequate' due to brute-force collision-machine cost (1994 estimate of 24 days for MD5), and frames SHA-1 as the more-secure alternative to MD5 with no warning that SHA-1 is itself broken/deprecated.

Primary source ✓ Source checked

csrc.nist.gov

NIST Policy on Hash Functions (Dec 15 2022): "NIST is announcing a timeline for a transition for SHA-1… After 12/31/2030, any FIPS 140 validated cryptographic module that has SHA-1 as an approved algorithm will be moved to the historical list. NIST recommends that federal agencies transition away from SHA-1 for all applications as soon as possible. Federal agencies should use SHA-2 or SHA-3 as an alternative to SHA-1."

What to learn instead

State plainly that practical MD5 collisions have been demonstrated since 2004 (Wang et al.) — chosen-prefix MD5 collisions cost <$1 of compute today — and that SHA-1 collisions were demonstrated in 2017 (SHAttered) and chosen-prefix SHA-1 collisions in 2020. Both MD5 and SHA-1 are unsuitable for any collision-resistance-dependent use; teach SHA-256/SHA-3 family instead.

A solid 2010-era defensive-security syllabus (NIST/ISO standards, RBAC/ABAC, DES/AES/RSA, IDS/IPS, syslog/SIEM) that prepares the student to think like a security analyst — but leaves the modern security engineer's day-to-day vocabulary (OWASP Top 10, TLS, OAuth/OIDC/SAML, threat modeling, zero trust, secrets management, Argon2, PCI/SOC2) as named-but-not-taught.

Gaps

OWASP Top 10 web-application risks (enumerate-and-map)

The course names OWASP twice but never enumerates the list. Ch4 Slide 1 (speaker notes) cites 'The Open Web Application Security Project's 2021 report [OWAS21] on the 10 most critical Web application security risks listed broken access control in first place,' and Ch2 Slide 1 cites the same report listing 'cryptographic failures ... as the second highest risk.' Two of the ten categories are already implicitly framed by the existing access-control and cryptography units. Conceptual extension: dedicate one slide that enumerates the 2021 OWASP Top 10 categories and maps each back to a unit already in the course (A01 Broken Access Control → Ch4; A02 Cryptographic Failures → Ch2; A07 Identification & Authentication Failures → Ch3; A09 Logging & Monitoring Failures → Ch18; etc.). This stays at the principles/mechanism level required by the depth bound and turns two passing references into an organising framework. 10 of 12 security postings explicitly demand it.

TLS handshake, certificate validation, and modern transport security configuration

TLS is named only once in the course — Ch2 Slide 28 lists 'X.509 certificates are used in most network security applications, including IP Security (IPsec), Transport Layer Security (TLS), Secure Shell (SSH), and Secure/Multipurpose Internet Mail Extension (S/MIME).' The course already teaches the underlying primitives (X.509, RSA/ECC, AES, HMAC, digital signatures, certificate authorities). Conceptual extension: add 1–2 slides explaining the TLS handshake as an application of those primitives — server-cert validation chain, ephemeral key agreement (Diffie-Hellman), AEAD record-layer encryption — plus one slide on common deployment failures (expired certs, weak ciphers, downgrade) and the role of mTLS in zero-trust architectures. No protocol implementation work is needed; this stays at the mechanism level. 9 of 12 security postings demand TLS competence.

OAuth 2.0 / OpenID Connect federated identity flows

The course already teaches the conceptual framework that OAuth/OIDC implements but never names the protocols. Ch3 Slide 5 introduces the NIST SP 800-63-3 model with 'Registration authority (RA), Credential service provider (CSP) ... Relying party (RP) ... Verifier ... Authenticated assertion between RP and verifier' — these are exactly the OAuth/OIDC roles (Authorization Server, Resource Server, Relying Party). Ch3 Slide 32 then walks through a concrete redirect-based authentication flow for the German eID. Conceptual extension: present OAuth 2.0 (authorization-code + PKCE) and OIDC ID tokens as the dominant web realisation of the NIST 800-63-3 federation roles already taught — at the mechanism/sequence-diagram level used elsewhere in the chapter. 9 of 12 security postings explicitly require OAuth.

SAML / SSO federation patterns

Same partial-coverage anchor as OAuth/OIDC — Ch3 Slide 5's NIST 800-63-3 'Identity proofing ... assertion about the identity of the subscriber to the relying party' is the SAML assertion model in textbook form. Ch3 Slide 36 already discusses 'WebAuthn ... user agent, such as a web browser ... as an intermediary between the authenticator and the authenticating service' — the same broker pattern SAML uses. Conceptual extension: add one slide presenting SAML SP-initiated SSO as an XML-based realisation of the same RP/IdP/verifier triad, contrasted against OIDC for protocol selection. Stays at the protocol-flow level the course already uses. 6 of 12 security postings demand it.

Threat modeling methodologies (STRIDE, systematic attack-tree analysis)

The course teaches the raw materials of threat modeling but never names the methodology. Ch1 Slide 22 already presents 'An Attack Tree for Internet Banking Authentication' with an explicit hierarchical breakdown (User credential compromise → Malicious software installation → Vulnerability exploit, etc.), and Ch14 Slide 23 'Threat Sources' frames threats by 'Motivation / Capability / Resources / Probability of attack / Deterrence' and cites NIST SP 800-30 threat-source taxonomy. Conceptual extension: introduce STRIDE (Spoofing/Tampering/Repudiation/Information disclosure/DoS/Elevation of privilege) as a structured threat-elicitation taxonomy that complements the attack tree already taught, and walk through one worked example using the Ch14 Silver Star Mines case study. No tool-specific lab work needed. 7 of 12 security postings demand it; this is one of the most universally listed core skills for security engineers.

Zero-trust architecture (perimeter-less access, continuous verification)

The course already teaches the principles that zero trust operationalises but stops at the classical perimeter-defence model. Ch9 Slide 8 explicitly states firewalls' limits — 'cannot protect against attacks bypassing firewall ... may not protect fully against internal threats ... laptop ... may be infected outside the corporate network and then used internally' — and Ch9 Slide 30 notes 'enterprise endpoint, including desktop and laptop systems, as the main target.' Ch1 Slide 17 already teaches 'Complete mediation: Every access must be checked against the access control mechanism' and 'Least privilege.' Conceptual extension: present zero-trust architecture as the architectural realisation of complete mediation + least privilege in a perimeter-less / cloud era — every request authenticated, authorised, and encrypted regardless of network location. Builds directly on slides already in the course; no specific vendor framework needed. 6 of 12 security postings list it.

Secrets management as a discipline (centralised vaults, rotation, scoping)

The course teaches cryptographic key management but stops short of operational secrets management. Ch15 Slide 19 (NIST SP 800-53 family 'System and Communications Protection') explicitly lists 'Cryptographic Key Establishment and Management' as a control family, Ch2 Slide 33 discusses 'effective encryption key management scheme' for data at rest, and Ch3 covers shadow password files (separating credentials from application code). Conceptual extension: extend the existing key-management slides by introducing the modern operational pattern — central secrets store, short-lived credentials, automated rotation, machine identity — as the contemporary realisation of the NIST 800-53 key-management control. Stays at the mechanism level (no Vault / AWS-KMS lab walkthrough needed). 8 of 12 security postings demand it.

Argon2 password hashing (modern PHC-winner alongside bcrypt)

The course already teaches the password-hash progression but stops in 1999. Ch3 Slide 15 explicitly enumerates 'crypt(3) ... MD5 ... OpenBSD uses Blowfish block cipher based hash algorithm called Bcrypt ... Bcrypt also includes a cost variable; an increase in the cost variable causes a corresponding increase in the time required.' Conceptual extension: extend that same slide to include Argon2 (Password Hashing Competition winner, 2015) as the current OWASP-recommended algorithm, with a one-sentence note on its memory-hard parameters (m, t, p) and why memory-hardness defeats GPU/ASIC attacks of the kind already discussed on Slide 17 ('AMD Radeon HD7970 GPU ... 8.2 × 10⁹ password combinations each second'). Pure conceptual extension of an existing slide. 5 of 12 security postings demand Argon2 specifically.

PCI-DSS / SOC 2 commercial compliance regimes

The course teaches the government / international standards landscape extensively but does not extend it to the commercial compliance regimes security engineers most often encounter. Ch14 Slides 3–4 catalogue the 'ISO/IEC 27000 Series of Standards on IT Security Techniques,' Ch15 Slides 11–20 walk through 'NIST SP 800-53 Security Controls,' and Ch18 Slide 28 'Security Compliance' already frames audit as 'a process to review the organization's security processes ... verify compliance with the security plan ... use checklists.' Conceptual extension: add one slide to the standards survey naming PCI-DSS (cardholder-data scope) and SOC 2 (trust-services criteria) as the dominant commercial regimes that map onto the same NIST/ISO control families already taught — including which existing 800-53 control families satisfy the most common SOC 2 / PCI requirements. Stays at the standards-and-mappings level the course already operates at. PCI-DSS appears in 5/12 and SOC 2 in 4/12 postings.

What the curriculum actually teaches (30 skills)
  • Discretionary Access Control (DAC), MAC, RBAC, ABAC models · Computer and Data Security
    Ch4 Slide 12: 'Discretionary access control (DAC) ... Mandatory access control (MAC) ... Role-based access control (RBAC) ... Attribute-based access control (ABAC)' — each policy family is defined and contrasted.
  • UNIX file permissions, setuid/setgid, sticky bit, ACLs (FreeBSD setfacl) · Computer and Data Security
    Ch4 Slides 26–28: '12 protection bits ... read, write, and execute permission for the owner, group, and other ... SetUID / SetGID / sticky bit ... FreeBSD allows the administrator to assign a list of UNIX user IDs and groups to a file by using the setfacl command.'
  • XACML (eXtensible Access Control Markup Language) for ABAC · Computer and Data Security
    Ch4 Slide 35: 'Web services have been pioneering technologies through the introduction of the eXtensible Access Control Markup Language (XAMCL).'
  • NIST SP 800-53 control families (catalog-level familiarity) · Computer and Data Security
    Ch15 Slides 11–20 (Tables 15.3 a–j): 'Detailed NIST SP 800-53 Security Controls — Access Control, Audit and Accountability, Configuration Management, Contingency Planning, Incident Response, Risk Assessment, System and Communications Protection ...'
  • ISO/IEC 27000 series (27001/27002/27005) standards landscape · Computer and Data Security
    Ch14 Slides 3–4: 'ISO/IEC 27000 Series of Standards on IT Security Techniques ... ISO 27005 (Information security risk management)'.
  • Qualitative risk assessment (likelihood × consequence matrix, risk register) · Computer and Data Security
    Ch14 Slides 27–31: 'use qualitative, not quantitative, ratings ... Table 14.4 Risk Level Determination ... Table 14.5 Risk Register'.
  • ISO 31000 / NIST SP 800-30 risk-management process and Plan-Do-Check-Act · Computer and Data Security
    Ch14 Slide 7: 'ISO 27005 ... Plan: Establish security policy ... Do: Implement the risk treatment plan ... Check ... Act'.
  • Risk treatment options: accept, avoid, transfer, reduce consequence/likelihood · Computer and Data Security
    Ch14 Slide 33: 'Risk acceptance ... Risk avoidance ... Risk transfer ... Reduce consequence ... Reduce likelihood'.
  • Security awareness, role-based training, education hierarchy (NIST SP 800-50) · Computer and Data Security
    Ch17 Slides 5, 11–14: 'NIST SP 800-50 ... Security awareness ... Cybersecurity basics and literacy ... Role-based training ... Security education and certification'.
  • Incident response lifecycle and CSIRT (NIST SP 800-61) · Computer and Data Security
    Ch17 Slides 15–25: 'NIST SP 800-61 ... Computer security incident response team (CSIRT) ... Triage function ... Responding to incidents ... Documenting incidents'.
  • Security audit trails, syslog, Windows Event Log · Computer and Data Security
    Ch18 Slides 17–27: 'Windows Event Log ... three types of event logs: System / Application / Security ... UNIX Syslog ... syslog(), logger, /etc/syslog.conf, syslogd ... BSD syslog format: PRI / Header / Msg'.
  • SIEM (Security Information and Event Management) — agentless vs agent-based · Computer and Data Security
    Ch18 Slide 38: 'SIEM software is a centralized logging software package similar to, but much more complex than, syslog ... Agentless ... Agent-based.'
  • Audit data analysis: baselining, thresholding, windowing, correlation · Computer and Data Security
    Ch18 Slide 37: 'Basic alerting ... Baselining ... Thresholding ... Windowing ... Correlation seeks relationships among events.'
  • Packet-filter, stateful, application-proxy, circuit-level firewalls · Computer and Data Security
    Ch9 Slides 9–17: 'Packet Filtering Firewall ... Stateful Inspection Firewall ... Application-Level Gateway ... Circuit-Level Gateway ... SOCKS v5 defined in RFC 1928'.
  • Bastion hosts, DMZ topologies, VPN/IPSec, distributed firewalls · Computer and Data Security
    Ch9 Slides 18, 21–24: 'Bastion Hosts ... DMZ (demilitarized zone) network ... a VPN consists of a set of computers that interconnect by means of a relatively unsecure network and that make use of encryption ... Distributed Firewall Configuration'.
  • Host-based and network-based IDS/IPS (HIDS, NIDS, HIPS, NIPS) · Computer and Data Security
    Ch8 Slide 20 + Ch9 Slides 26–32: 'Host-based IDS (HIDS) ... Network-based IDS (NIDS) ... Distributed or hybrid IDS ... Host-Based IPS (HIPS) ... Network-Based IPS (NIPS)'.
  • Anomaly vs signature/heuristic intrusion detection (statistical, knowledge-based, ML) · Computer and Data Security
    Ch8 Slides 23–25: 'Anomaly detection ... Signature/heuristic detection ... Statistical ... Knowledge based ... Machine-learning ... SNORT is an example of a rule-based NIDS'.
  • Snort rule format and Snort Inline (drop/reject/sdrop) · Computer and Data Security
    Ch8 Slides 47–52 + Ch9 Slide 35: 'Snort Architecture ... rule header (Action, Protocol, Source IP, Source port, Direction, Dest IP, Dest port) ... Snort Inline ... Drop / Reject / Sdrop'.
  • Honeypots (low- vs high-interaction, deployment locations) · Computer and Data Security
    Ch8 Slides 43–46: 'Honeypots are decoy systems ... Low-interaction honeypot ... High-interaction honeypot ... a honeypot outside the external firewall (location 1) is useful for tracking attempts to connect to unused IP addresses'.
  • MITRE ATT&CK (named, used as reference for intruder tactics) · Computer and Data Security
    Ch8 Slide 11: 'A more recent, detailed list of intruder tactics and techniques is provided in the MITRE Attack matrix site.'
  • Attack trees and security design principles (least privilege, complete mediation, defense in depth) · Computer and Data Security
    Ch1 Slides 17–22: 'Least privilege ... Complete mediation: Every access must be checked against the access control mechanism ... Layering ... An Attack Tree for Internet Banking Authentication'.
  • Symmetric crypto: DES, 3DES, AES; ECB / modes of operation · Computer and Data Security
    Ch2 Slides 5–11: 'Data Encryption Standard (DES) ... Triple DES ... Advanced Encryption Standard (AES) ... Selected Rijndael in November 2001 ... Electronic codebook (ECB) mode'.
  • Hash functions (MD5, SHA-1/2/3), HMAC, CMAC for message authentication · Computer and Data Security
    Ch2 Slides 16–18: 'Secure Hash Algorithm (SHA) family ... SHA-2 ... SHA-3 ... Cipher-based Message Authentication Code (CMAC) ... HMAC'.
  • Public-key crypto (RSA, Diffie-Hellman, DSA/ECDSA, ECC), X.509 certificates, digital envelopes · Computer and Data Security
    Ch2 Slides 24–29: 'RSA ... Diffie-Hellman key exchange ... Digital Signature Algorithm (DSA) ... Elliptic Curve Digital Signature Algorithm (ECDSA) ... X.509 standard ... Digital Envelopes'.
  • Password hashing (UNIX crypt(3), MD5 crypt, Bcrypt) and salting · Computer and Data Security
    Ch3 Slides 13–15: 'recommended hash function for many UNIX systems ... is based on the MD5 secure hash algorithm ... OpenBSD uses Blowfish block cipher based hash algorithm called Bcrypt ... 128-bit salt to create 192-bit hash value'.
  • Password attacks: dictionary, rainbow tables, John the Ripper · Computer and Data Security
    Ch3 Slide 16: 'Rainbow table attacks ... John the Ripper, an open-source password cracker first developed in 1996'.
  • Multifactor authentication, TOTP, FIDO2/WebAuthn, hardware tokens, smart cards, eID · Computer and Data Security
    Ch3 Slides 7, 34–37, 22–32: 'Multifactor authentication (MFA) ... Time-based one-time password (TOTP) uses HMAC with a hash function ... RFC 6238 ... FIDO2 ... WebAuthn ... Client to Authenticator Protocol 2 (CTAP2) ... Smart Cards ... Electronic Identity Cards (eID)'.
  • NIST SP 800-63-3 identity model (CSP, claimant, verifier, relying party; IAL/AAL) · Computer and Data Security
    Ch3 Slides 5, 8–10: 'an applicant applies to a registration authority (RA) to become a subscriber of a credential service provider (CSP) ... verifier ... relying party (RP) ... three separate levels for each of Identity Assurance Level (IAL) and Authenticator Assurance Level (AAL)'.
  • Biometric authentication and challenge-response remote auth · Computer and Data Security
    Ch3 Slides 40–47: 'Biometric Authentication ... fingerprint ... iris ... operating characteristic curves ... Basic Challenge-Response Protocols for Remote User Authentication'.
  • File-integrity monitoring with Tripwire · Computer and Data Security
    Ch8 Slide 28: 'Tripwire is a well-known system using this approach ... cryptographic checksum to check for any changes from the known good baseline'.

The top three prescriptions — OWASP Top 10 enumeration (0.83), TLS handshake mechanics (0.75), and OAuth 2.0 / OIDC framing of NIST 800-63-3 (0.75) — are each pure conceptual extensions of slides already in the course (Ch4/Ch2, Ch2 Slide 28, Ch3 Slide 5) and together address the modern security engineer's three most-listed vocabulary gaps: web-app risk taxonomy, transport security, and federated identity.

These nine prescriptions cover every gap surfaced by the market-fit agent at the conceptual / mechanism depth this introductory survey is bounded to. They close roughly 75–85% of the named market gap for a security-engineer entry role; the remaining unaddressed market signals (Python tooling fluency, Burp/SAST/DAST hands-on, Kubernetes security, AWS IAM specifics) are intentionally omitted because they require hands-on lab depth or framework-specific tutorials beyond this course's stated scope, and would violate the depth bound if prescribed here. They belong in a follow-on hands-on secure-engineering course, not as extensions to this survey.

#1 ~3h to learn

OWASP Top 10 (2021) — enumerate all ten categories and map each to an existing course unit

Promote OWASP from a name dropped twice in the slides to the top-of-mind taxonomy every security engineer is interviewed on, mapped directly onto the units already taught.

owasp top 10broken access controlcryptographic failuresinjectionssrfsecurity misconfiguration

Where it fits

Computer and Data Security — Ch4 (Access Control), with explicit cross-references to Ch2, Ch3, Ch9, Ch18 · Ch4 Slide 1 already cites the OWASP 2021 report's #1 finding (Broken Access Control) and Ch2 Slide 1 cites the same report's #2 (Cryptographic Failures). One added enumeration slide in Ch4 listing all ten A01–A10 categories with cross-references back to Ch2 (A02), Ch3 (A07), Ch4 (A01), Ch9 (A05/A06), Ch18 (A09) turns two passing footnotes into the organising framework security engineers are expected to recite.

Prerequisites

  • Access control models (DAC/MAC/RBAC/ABAC) · already covered in Computer and Data Security — Ch4 Slide 12
  • Hash/HMAC primitives behind cryptographic failures · already covered in Computer and Data Security — Ch2 Slides 16–18
  • Authentication failure modes · already covered in Computer and Data Security — Ch3 Slides 13–17
  • Logging & monitoring (A09) · already covered in Computer and Data Security — Ch18 Slides 17–37
#2 ~4h to learn

TLS handshake, certificate validation, and modern transport-security configuration

Turn the chapter's X.509/AES/DH primitives into the TLS handshake — the one protocol every security-engineer interview will ask you to draw on a whiteboard.

tlstls handshakex.509 chain validationephemeral diffie-hellmanaeadmtlscipher downgrade

Where it fits

Computer and Data Security — Ch2 (Cryptographic Tools) · Ch2 Slide 28 already names TLS as a consumer of the X.509 certificates and public-key primitives the chapter teaches, but never opens the protocol. Adding 1–2 mechanism-level slides — handshake message flow, server-cert chain validation, ephemeral key agreement, AEAD record layer, common deployment failures (expired certs, weak ciphers, downgrade), and mTLS as the cryptographic substrate of zero-trust — composes the primitives the chapter already teaches into the protocol every security engineer touches daily.

Prerequisites

  • X.509 certificates and CAs · already covered in Computer and Data Security — Ch2 Slide 28
  • RSA / ECC / Diffie-Hellman · already covered in Computer and Data Security — Ch2 Slides 24–26
  • AES and modes of operation · already covered in Computer and Data Security — Ch2 Slides 9–11
  • HMAC for message authentication · already covered in Computer and Data Security — Ch2 Slide 18
#3 ~3h to learn

OAuth 2.0 (authorization code + PKCE) and OpenID Connect as the web realisation of NIST SP 800-63-3 federation roles

Re-label the NIST 800-63-3 identity actors the course already teaches as the OAuth/OIDC roles every modern web security engineer is expected to name.

oauthoauth 2.0oidcauthorization codepkceid tokenaccess tokenrelying party

Where it fits

Computer and Data Security — Ch3 (User Authentication) · Ch3 Slide 5 already teaches the NIST SP 800-63-3 actors (CSP, claimant, verifier, relying party) — these are exactly OAuth's authorization server / resource server / RP triad in different wording. Ch3 Slide 32 already walks a redirect-based eID authentication flow at the right sequence-diagram level. Adding one slide that names OAuth 2.0 authorization-code-with-PKCE and OIDC ID tokens as the dominant web realisation of the same model lets the course's existing concepts land under the names recruiters search for.

Prerequisites

  • NIST SP 800-63-3 identity model · already covered in Computer and Data Security — Ch3 Slides 5, 8–10
  • Redirect-based authentication flows · already covered in Computer and Data Security — Ch3 Slide 32 (eID)
  • TLS as transport security not yet covered
#4 ~3h to learn

Secrets management as a discipline — centralised vault, short-lived credentials, automated rotation, machine identity

Extend the course's cryptographic-key-management slides into the operational secrets-management discipline that 8 of 12 security postings explicitly demand.

secrets managementvaultkey rotationshort-lived credentialsmachine identitycredential scoping

Where it fits

Computer and Data Security — Ch15 (IT Security Controls), extending Slide 19 (NIST SP 800-53 'System and Communications Protection' family) · Ch15 Slide 19 already lists 'Cryptographic Key Establishment and Management' as a NIST SP 800-53 control family, and Ch2 Slide 33 already discusses 'effective encryption key management scheme.' Extending those slides with the operational pattern — central secrets store, rotation, scoped/short-lived credentials, separation of secret material from application code (analogous to the shadow-password split already taught in Ch3) — keeps the discussion at the standards-and-mechanism level the chapter already operates at.

Prerequisites

  • Cryptographic key management (NIST 800-53 SC family) · already covered in Computer and Data Security — Ch15 Slide 19
  • Encryption key management for data at rest · already covered in Computer and Data Security — Ch2 Slide 33
  • Separation of credentials from application (shadow files) · already covered in Computer and Data Security — Ch3
#5 ~3h to learn

STRIDE threat modeling as a structured complement to the attack-tree analysis already taught

Name STRIDE as the systematic six-category lens that pairs with the attack tree the course already draws — the single most-listed core skill on security-engineer postings.

threat modelingstridespoofingtamperingrepudiationinformation disclosuredenial of serviceelevation of privilege

Where it fits

Computer and Data Security — Ch1 (Overview), with worked example pulled from Ch14 · Ch1 Slide 22 already presents 'An Attack Tree for Internet Banking Authentication' with hierarchical breakdown, and Ch14 Slide 23 already teaches the NIST SP 800-30 threat-source taxonomy (Motivation/Capability/Resources/Probability/Deterrence). STRIDE is the canonical six-category elicitation taxonomy that pairs with attack trees to systematically generate the leaves. One slide naming STRIDE plus a worked walk-through using the Ch14 Silver Star Mines case study extends what is already there into the methodology security engineers are interviewed on, without requiring any tool-specific lab.

Prerequisites

  • Attack trees · already covered in Computer and Data Security — Ch1 Slide 22
  • Threat-source taxonomy (NIST SP 800-30) · already covered in Computer and Data Security — Ch14 Slide 23
  • Security design principles (least privilege, complete mediation) · already covered in Computer and Data Security — Ch1 Slides 17–22
#6 ~2h to learn

SAML / SSO federation as an XML-based realisation of the same RP/IdP/verifier triad

Add SAML alongside OIDC as the two competing protocols that realise the federation triad the course already teaches in NIST 800-63-3 vocabulary.

samlssosp-initiated ssosaml assertionidentity providerservice provider

Where it fits

Computer and Data Security — Ch3 (User Authentication), paired with the OAuth/OIDC slide · Same anchor as OAuth/OIDC: Ch3 Slide 5 already presents the NIST SP 800-63-3 'assertion about the identity of the subscriber to the relying party' — that is literally the SAML assertion model. Ch3 Slide 36 already discusses WebAuthn's broker pattern between authenticator and authenticating service, which mirrors SAML's IdP/SP broker. One slide presenting SAML SP-initiated SSO and contrasting it with OIDC for protocol selection completes the federation picture at the protocol-flow depth the chapter already uses.

Prerequisites

  • NIST SP 800-63-3 identity model · already covered in Computer and Data Security — Ch3 Slide 5
  • Broker authentication patterns (WebAuthn) · already covered in Computer and Data Security — Ch3 Slide 36
  • OAuth 2.0 / OIDC for comparison not yet covered
#7 ~2h to learn

Zero-trust architecture as the perimeter-less realisation of complete mediation + least privilege

Frame zero trust as the architectural answer to the perimeter limits Ch9 already names, applying the complete-mediation principle Ch1 already teaches.

zero trustztnacontinuous verificationperimeter-lessleast-privilege accessmtls everywhere

Where it fits

Computer and Data Security — Ch9 (Firewalls), extending Slide 8's discussion of perimeter limits · Ch9 Slide 8 already enumerates the limits of perimeter firewalls ('cannot protect against attacks bypassing firewall ... laptop ... infected outside the corporate network and then used internally'), and Ch1 Slide 17 already teaches 'Complete mediation: Every access must be checked' and 'Least privilege.' Zero trust is the architectural pattern that operationalises both Ch1 principles in answer to the Ch9 limits — one slide framing it that way ties two existing parts of the course together rather than introducing a new vendor framework.

Prerequisites

  • Limits of perimeter firewalls · already covered in Computer and Data Security — Ch9 Slide 8
  • Complete mediation, least privilege · already covered in Computer and Data Security — Ch1 Slide 17
  • mTLS for service-to-service auth not yet covered
#8 ~1h to learn

Argon2 password hashing — the modern PHC winner extending the bcrypt slide

Extend the bcrypt slide one bullet forward to Argon2 — the algorithm OWASP currently recommends and 5 of 12 postings explicitly name.

argon2argon2idmemory-hard kdfphcpassword hashing competitionowasp asvs

Where it fits

Computer and Data Security — Ch3 Slide 15 · Ch3 Slide 15 already enumerates the password-hash progression crypt(3) → MD5-crypt → Bcrypt and discusses Bcrypt's tunable cost variable. Adding Argon2 (Password Hashing Competition winner, 2015; current OWASP-recommended algorithm) with a one-sentence note on memory-hard parameters m/t/p directly continues the timeline on the same slide and explicitly defeats the GPU/ASIC threat already quantified two slides later (Ch3 Slide 17, '8.2 × 10⁹ password combinations each second'). Pure conceptual extension of an existing slide.

Prerequisites

  • Bcrypt and salted password hashing · already covered in Computer and Data Security — Ch3 Slides 13–15
  • GPU-accelerated password attacks · already covered in Computer and Data Security — Ch3 Slide 17
#9 ~2h to learn

PCI-DSS and SOC 2 as the commercial compliance regimes that ride on the NIST/ISO control catalogues already taught

Map the NIST/ISO control catalogues the course already teaches onto PCI-DSS and SOC 2 — the two commercial compliance regimes security engineers are most often hired to evidence.

pci-dsssoc2trust services criteriacardholder data environmentcompliance mapping

Where it fits

Computer and Data Security — Ch14 (IT Security Management), extending the standards survey on Slides 3–4 · Ch14 Slides 3–4 already catalogue the ISO/IEC 27000 series, Ch15 Slides 11–20 walk through NIST SP 800-53 control families, and Ch18 Slide 28 already frames audits as 'verify compliance with the security plan ... use checklists.' Adding one slide that names PCI-DSS (cardholder-data scope) and SOC 2 (trust-services criteria) and shows which existing 800-53 control families satisfy the most common SOC 2 / PCI requirements stays at the standards-and-mappings level the course already operates at and answers the most common 'what compliance regimes have you worked under?' interview question.

Prerequisites

  • ISO/IEC 27000 series · already covered in Computer and Data Security — Ch14 Slides 3–4
  • NIST SP 800-53 control families · already covered in Computer and Data Security — Ch15 Slides 11–20
  • Security audit / compliance process · already covered in Computer and Data Security — Ch18 Slide 28