Joltlined

Notes & literary analysis

FBLA · National 2026–27

Cybersecurity

13 two-page sheets · 26 printable pages · 24 lines per page

Read a sheet, then open “Sources, practice, lab and scope notes” beneath it for questions, answers and the module lab. Plain and colored downloads contain the same notes. Use your browser's Print command for one numbered sheet per page.

Official scope: 2026–27 CONNECT guideline. The notes and companion deck have been reviewed; neither certifies your mastery or a competition result. Objective IDs are local study labels, and source-reading limits are recorded in the source ledger.

Confirm qualification, entry limits and conference-specific rules with your adviser. Studying all four events does not establish eligibility to enter all four.

Course contents

  1. Security Goals, Trust, and Number Bases
  2. Access, Factors, and Defensive Decoys
  3. Actors, Malware, and Software Weaknesses
  4. Social, Service, Cryptographic, and Wireless Threats
  5. Secure Platforms and Architecture
  6. Segmentation, Isolation, and IoT
  7. Resilience and Security Testing
  8. Cryptography and Data Protection
  9. Data States and Access Control
  10. Policies, Continuity, and Secure Communication
  11. Firewall Types and Least-Privilege ACLs
  12. Secure Protocols, Detection, and Data Methods
  13. Password Security, Patching, and Authorized Testing

Security Goals, Trust, and Number Bases

Security Fundamentals

Download plain · Download colored

Security Goals, Trust, and Number Bases

Page 1 · Lines 1–24

o Overview
-> CIA and Zero Trust
-> Identity, Attestation, and AAA
o CIA and Zero Trust
-> Confidentiality limits data reading to authorized parties.
-> Integrity resists unauthorized change or destruction.
-> Availability gives authorized users timely access.
-> Encryption supports confidentiality, not data truth.
-> Audit controls can expose changes; logs need protection.
-> Tested backups support recovery and availability.
-> Zero Trust gives no trust from location alone.
-> Evaluate user, device, resource, and context per request.
-> Example: verify worker and device before payroll access.
o Identity, Attestation, and AAA
-> Proofing links a claimed identity to a real person.
-> Resolution finds a unique identity in the served population.
-> Validation checks evidence and attribute facts.
-> Verification checks applicant is rightful evidence owner.
-> Authentication later checks control of a bound authenticator.
-> Attestation signs hardware-secured measurements for review.
-> Attestation describes device measurements, not human identity.
-> Trust depends on keys, measurements, and verifier policy.
-> AAA: authentication, authorization, and accounting.
-> Authorization permits actions; accounting records activity.

Security Goals, Trust, and Number Bases

Page 2 · Lines 25–48

o Overview
-> Nonrepudiation and Least Privilege
-> Binary, Decimal, and Hex
o Nonrepudiation and Least Privilege
-> Nonrepudiation seeks evidence resisting denial of an action.
-> A signature alone cannot prove who controlled its key.
-> Identity binding, key custody, intent, and time matter.
-> Legal and system assumptions bound attribution claims.
-> Least privilege grants only necessary resource/action rights.
-> Use narrow roles and time-bound elevation where feasible.
-> Review grants; revoke access when duties or roles change.
-> It limits blast radius, not all misuse or compromise.
-> OWASP says least DB privilege limits injection damage.
o Binary, Decimal, and Hex
-> Binary is base 2; decimal is base 10; hex is base 16.
-> Hex digits are 0-9 and A-F; A-F represent values 10-15.
-> Place values are powers of the base, right to left.
-> Binary 1011 equals decimal 8+2+1, or 11.
-> Hex 2F equals decimal 2*16+15, or 47.
-> Four binary bits form one hex digit: 1011 becomes B.
-> Pad on left: 11010 becomes 0001 1010, or hex 1A.
-> A byte is 8 bits; two hex digits display one byte.
-> Hex displays bits compactly; it does not encrypt them.
-> Hashes output fixed-length digests; encoding adds no strength.
Sources, practice, lab and scope notes

Objectives

  • CS-SF-01
  • CS-SF-04
  • CS-SF-07
  • CS-SF-02
  • CS-SF-03
  • CS-SF-06

Sources

  • 2026-2027 FBLA Cybersecurity Guidelines — fetched; Read study guide pages 5-6 for current scope and wording of assigned Security Fundamentals and Cyber Threats and Vulnerabilities objectives; used only to establish scope, not technical mechanisms.
  • NIST SP 800-63A-4: Identity Proofing and Enrollment — fetched; Read identity proofing overview and passages on resolution, evidence/attribute validation, verification of rightful owner, enrollment, and assurance limits.
  • NIST SP 800-63B-4: Authentication and Authenticator Management — fetched; Read authentication definition, AAL summaries, distinct-factor MFA, authenticator control, phishing resistance, OTP and out-of-band limitations.
  • NIST CSRC Glossary: Attestation — fetched; Read definition: digitally sign hardware-secured measurements and have requester validate signature and measurements; glossary term context is SP 1800-19B.
  • NIST CSRC Glossary: Honeypot — fetched; Read definition of an attractive system/resource for potential intruders. NIST glossary term identifies resource examples, not a complete taxonomy of honeynet or honeyfile.
  • NIST SP 800-207: Zero Trust Architecture — fetched; Read official abstract: no implicit trust based solely on physical/network location; ZTA focuses on users, assets, and resources. Full publication not read.
  • OWASP SQL Injection Prevention Cheat Sheet — fetched; Read SQL injection mechanism, parameterized query, allow-list structural choices, and least-privilege passages.
  • CISA: Understanding Denial-of-Service Attacks — fetched; Read DoS flood and SYN-flood mechanics, botnet-based DDoS, compromised devices as victims, monitoring, and response. Page is explicitly archived/outdated; use for basic mechanism only.
  • RFC 9325: Recommendations for Secure Use of TLS/DTLS — fetched; Read TLS version/fallback guidance: TLS 1.2 clients must not fall back to earlier deprecated versions; document recommends modern secure deployment and notes guidance is point-in-time.
  • RFC 6962: Certificate Transparency — fetched; Read hash-tree definitions: SHA-256 digests, distinct leaf/node prefixes for second-preimage resistance, and proof construction. Does not state birthday bound; used for hash/digest context only.

Practice (answers below)

1. A compliant laptop requests payroll access. Give a Zero Trust decision.

Verify user, device, and resource-specific policy; allow only the required payroll action for an appropriate session. LAN/VPN presence alone is not authorization.

2. Convert binary 1101 to decimal and one hex digit.

8+4+1=13 decimal; four bits map to hex D. Hex is a representation of the same bits, not encryption.

Safe fictional phishing and availability tabletop

  1. Read a fictional payroll voice-call scenario asking for an SMS code and bank change.
  2. Identify vishing cues; choose independent verification and approved reporting path.
  3. Discuss fictional service slowdown: identify resource/provider, preserve event notes, notify response lead.
  4. Name approved mitigation options; do not generate traffic, scan, click links, or contact real numbers.

Expected: No code or payment change is disclosed; callback uses a known contact route. Participants distinguish DoS capacity exhaustion from ordinary outages and identify provider/response coordination. No live systems, credentials, traffic, or personal logs are used.

Limitations: NIST CSRC glossary provided a direct honeypot definition; separate authoritative NIST entries for honeynet and honeyfile were not found. Those common instructional distinctions are explicitly qualified. CISA DoS article is archived and may not reflect current policy; it is used only for basic attack mechanics, while mitigation is described cautiously. RFC 6962 supports hash/digest and Merkle-tree mechanics but not the birthday bound itself; the generic birthday estimate is standard probability analysis and is labeled as an idealized bound.

Access, Factors, and Defensive Decoys

Security Fundamentals

Download plain · Download colored

Access, Factors, and Defensive Decoys

Page 1 · Lines 1–24

o Overview
-> Proofing, Factors, and Device Trust
-> AAA, MFA, and Zero Trust
o Proofing, Factors, and Device Trust
-> Proofing links a person identity at stated assurance.
-> It resolves, validates evidence, then verifies owner.
-> Authentication checks control of an account authenticator.
-> A device report is not user proof; login is not device proof.
-> Attestation signs hardware-secured measurements for review.
-> It depends on trusted measurement, signing key, and verifier.
-> Authentication shows account control, not real-world identity.
-> Assurance reduces risk; it does not promise certainty.
-> Enrollment and recovery also need secure proofing controls.
o AAA, MFA, and Zero Trust
-> Authentication verifies control; authorization permits use.
-> Accounting: record relevant use for review and investigation.
-> MFA uses distinct types: know, have, or are.
-> Two passwords are both know factors, not MFA by themselves.
-> Password plus registered security key combines know and have.
-> SMS codes can be intercepted/phished; not phishing-resistant.
-> Zero Trust checks identity/context for each resource request.
-> Managed device and verified worker get payroll read access.
-> Network location or VPN alone does not grant implicit trust.
-> Device posture is a signal; it does not identify the user.

Access, Factors, and Defensive Decoys

Page 2 · Lines 25–48

o Overview
-> Least Privilege
-> Honeypots, Honeynets, and Honeyfiles
o Least Privilege
-> Grant only resources/actions needed for assigned work.
-> Separate routine accounts from administrative elevation.
-> A reporting service may read a view, not own the database.
-> Use role scopes and expire temporary permissions.
-> Review access after job, project, or status changes.
-> Remove stale rights; protect service/database accounts too.
-> Least privilege limits harm from bugs or stolen accounts.
-> It does not stop every authorized misuse or compromise.
-> OWASP treats it as damage reduction, not injection prevention.
o Honeypots, Honeynets, and Honeyfiles
-> NIST calls honeypot an attractive resource for intruders.
-> A decoy service/file can make unexpected access observable.
-> Honeynet commonly means connected decoy systems.
-> Honeyfile commonly means monitored decoy document/artifact.
-> No separate NIST glossary entries for these labels were found.
-> Access can alert defenders; decoys do not block attacks.
-> Isolate decoys from production; restrict outbound connections.
-> Use synthetic content, monitor alerts, assign response owner.
-> Never place real credentials or sensitive records in decoys.
-> Containment and safe isolation are separate design controls.
Sources, practice, lab and scope notes

Objectives

  • CS-SF-02
  • CS-SF-03
  • CS-SF-04
  • CS-SF-07
  • CS-SF-05

Sources

  • 2026-2027 FBLA Cybersecurity Guidelines — fetched; Read study guide pages 5-6 for current scope and wording of assigned Security Fundamentals and Cyber Threats and Vulnerabilities objectives; used only to establish scope, not technical mechanisms.
  • NIST SP 800-63A-4: Identity Proofing and Enrollment — fetched; Read identity proofing overview and passages on resolution, evidence/attribute validation, verification of rightful owner, enrollment, and assurance limits.
  • NIST SP 800-63B-4: Authentication and Authenticator Management — fetched; Read authentication definition, AAL summaries, distinct-factor MFA, authenticator control, phishing resistance, OTP and out-of-band limitations.
  • NIST CSRC Glossary: Attestation — fetched; Read definition: digitally sign hardware-secured measurements and have requester validate signature and measurements; glossary term context is SP 1800-19B.
  • NIST CSRC Glossary: Honeypot — fetched; Read definition of an attractive system/resource for potential intruders. NIST glossary term identifies resource examples, not a complete taxonomy of honeynet or honeyfile.
  • NIST SP 800-207: Zero Trust Architecture — fetched; Read official abstract: no implicit trust based solely on physical/network location; ZTA focuses on users, assets, and resources. Full publication not read.
  • OWASP SQL Injection Prevention Cheat Sheet — fetched; Read SQL injection mechanism, parameterized query, allow-list structural choices, and least-privilege passages.
  • CISA: Understanding Denial-of-Service Attacks — fetched; Read DoS flood and SYN-flood mechanics, botnet-based DDoS, compromised devices as victims, monitoring, and response. Page is explicitly archived/outdated; use for basic mechanism only.
  • RFC 9325: Recommendations for Secure Use of TLS/DTLS — fetched; Read TLS version/fallback guidance: TLS 1.2 clients must not fall back to earlier deprecated versions; document recommends modern secure deployment and notes guidance is point-in-time.
  • RFC 6962: Certificate Transparency — fetched; Read hash-tree definitions: SHA-256 digests, distinct leaf/node prefixes for second-preimage resistance, and proof construction. Does not state birthday bound; used for hash/digest context only.

Practice (answers below)

1. Why do device attestation and identity proofing establish different facts?

Attestation lets a requester validate signed hardware measurements; proofing links a human claim to a real person. Keys, measurement trust, and proofing evidence each have limits.

2. A finance analyst needs one report. Name a least-privilege grant.

Grant read access only to that report/view, log its use, and review or revoke when duties change; broad database administration is unnecessary risk.

Safe fictional phishing and availability tabletop

  1. Read a fictional payroll voice-call scenario asking for an SMS code and bank change.
  2. Identify vishing cues; choose independent verification and approved reporting path.
  3. Discuss fictional service slowdown: identify resource/provider, preserve event notes, notify response lead.
  4. Name approved mitigation options; do not generate traffic, scan, click links, or contact real numbers.

Expected: No code or payment change is disclosed; callback uses a known contact route. Participants distinguish DoS capacity exhaustion from ordinary outages and identify provider/response coordination. No live systems, credentials, traffic, or personal logs are used.

Limitations: NIST CSRC glossary provided a direct honeypot definition; separate authoritative NIST entries for honeynet and honeyfile were not found. Those common instructional distinctions are explicitly qualified. CISA DoS article is archived and may not reflect current policy; it is used only for basic attack mechanics, while mitigation is described cautiously. RFC 6962 supports hash/digest and Merkle-tree mechanics but not the birthday bound itself; the generic birthday estimate is standard probability analysis and is labeled as an idealized bound.

Actors, Malware, and Software Weaknesses

Cyber Threats and Vulnerabilities

Download plain · Download colored

Actors, Malware, and Software Weaknesses

Page 1 · Lines 1–24

o Overview
-> Threat Actors and Motives
-> Virus Varieties and Other Malware
o Threat Actors and Motives
-> Insiders have organizational access; outsiders do not.
-> Either may act deliberately or cause harm through error.
-> Financial gain can motivate theft, extortion, or fraud.
-> Espionage seeks protected information for strategic advantage.
-> Data theft may support resale, fraud, or later intrusion.
-> Disruption or ideology may motivate service or data attacks.
-> Assess capability, access, opportunity, and target as well.
-> Motive is a hypothesis, not proof of actor identity.
-> Controls should address behavior and access, not stereotypes.
o Virus Varieties and Other Malware
-> Malware is software used to harm, spy, extort, or control.
-> A virus attaches to a host file or boot area to spread.
-> File virus infects executable files when they run.
-> Boot-sector virus targets startup records or boot media.
-> Polymorphic viruses vary code/signature during replication.
-> Variation may evade simple signatures; behavior checks help.
-> Trojan masquerades as benign software to induce execution.
-> A worm self-propagates across systems or networks.
-> Logic bomb activates when a time/event condition is met.
-> One malware sample may combine more than one behavior.

Actors, Malware, and Software Weaknesses

Page 2 · Lines 25–48

o Overview
-> Vulnerabilities and Exploit Classes
-> Reduce Exposure
o Vulnerabilities and Exploit Classes
-> Vulnerability is a weakness; exploit is a way to use it.
-> Injection treats input as command/query syntax, not data.
-> Parameterized SQL separates values from query structure.
-> Buffer overflow writes beyond allocated memory bounds.
-> Race occurs when timing changes shared state unexpectedly.
-> Atomic operations/locks can prevent unsafe check-use races.
-> Jailbreaking weakens platform restrictions or sandboxing.
-> Backdoor is hidden access; zero-day has no effective fix yet.
-> Known unpatched flaws may have fixes; test and apply patches.
o Reduce Exposure
-> Bind untrusted data; do not concatenate into SQL syntax.
-> Allowlist identifiers and sort choices from fixed options.
-> Least database privilege limits damage, not injection itself.
-> Use bounds-safe code and safe shared-state access.
-> Apply security updates after risk-appropriate testing.
-> Remove unused services and reduce exposed attack surface.
-> Limit user/service rights to reduce malware blast radius.
-> Backups support recovery but do not prevent infection.
-> Signatures can miss new or altered malware.
-> Use layered controls; no single tool guarantees prevention.
Sources, practice, lab and scope notes

Objectives

  • CS-CTV-02
  • CS-CTV-03
  • CS-CTV-07
  • CS-CTV-01
  • CS-CTV-04

Sources

  • 2026-2027 FBLA Cybersecurity Guidelines — fetched; Read study guide pages 5-6 for current scope and wording of assigned Security Fundamentals and Cyber Threats and Vulnerabilities objectives; used only to establish scope, not technical mechanisms.
  • NIST SP 800-63A-4: Identity Proofing and Enrollment — fetched; Read identity proofing overview and passages on resolution, evidence/attribute validation, verification of rightful owner, enrollment, and assurance limits.
  • NIST SP 800-63B-4: Authentication and Authenticator Management — fetched; Read authentication definition, AAL summaries, distinct-factor MFA, authenticator control, phishing resistance, OTP and out-of-band limitations.
  • NIST CSRC Glossary: Attestation — fetched; Read definition: digitally sign hardware-secured measurements and have requester validate signature and measurements; glossary term context is SP 1800-19B.
  • NIST CSRC Glossary: Honeypot — fetched; Read definition of an attractive system/resource for potential intruders. NIST glossary term identifies resource examples, not a complete taxonomy of honeynet or honeyfile.
  • NIST SP 800-207: Zero Trust Architecture — fetched; Read official abstract: no implicit trust based solely on physical/network location; ZTA focuses on users, assets, and resources. Full publication not read.
  • OWASP SQL Injection Prevention Cheat Sheet — fetched; Read SQL injection mechanism, parameterized query, allow-list structural choices, and least-privilege passages.
  • CISA: Understanding Denial-of-Service Attacks — fetched; Read DoS flood and SYN-flood mechanics, botnet-based DDoS, compromised devices as victims, monitoring, and response. Page is explicitly archived/outdated; use for basic mechanism only.
  • RFC 9325: Recommendations for Secure Use of TLS/DTLS — fetched; Read TLS version/fallback guidance: TLS 1.2 clients must not fall back to earlier deprecated versions; document recommends modern secure deployment and notes guidance is point-in-time.
  • RFC 6962: Certificate Transparency — fetched; Read hash-tree definitions: SHA-256 digests, distinct leaf/node prefixes for second-preimage resistance, and proof construction. Does not state birthday bound; used for hash/digest context only.

Practice (answers below)

1. Contrast a file virus, worm, Trojan, and logic bomb.

Virus attaches to a host; worm self-propagates; Trojan masquerades as legitimate; logic bomb waits for a trigger. A sample can combine behaviors.

2. A query concatenates a submitted name into SQL. What flaw and fix?

This creates injection risk because input can become SQL syntax. Bind the value as a parameter; use fixed allowlists for structural choices. Binding does not grant authorization.

Safe fictional phishing and availability tabletop

  1. Read a fictional payroll voice-call scenario asking for an SMS code and bank change.
  2. Identify vishing cues; choose independent verification and approved reporting path.
  3. Discuss fictional service slowdown: identify resource/provider, preserve event notes, notify response lead.
  4. Name approved mitigation options; do not generate traffic, scan, click links, or contact real numbers.

Expected: No code or payment change is disclosed; callback uses a known contact route. Participants distinguish DoS capacity exhaustion from ordinary outages and identify provider/response coordination. No live systems, credentials, traffic, or personal logs are used.

Limitations: NIST CSRC glossary provided a direct honeypot definition; separate authoritative NIST entries for honeynet and honeyfile were not found. Those common instructional distinctions are explicitly qualified. CISA DoS article is archived and may not reflect current policy; it is used only for basic attack mechanics, while mitigation is described cautiously. RFC 6962 supports hash/digest and Merkle-tree mechanics but not the birthday bound itself; the generic birthday estimate is standard probability analysis and is labeled as an idealized bound.

Social, Service, Cryptographic, and Wireless Threats

Cyber Threats and Vulnerabilities

Download plain · Download colored

Social, Service, Cryptographic, and Wireless Threats

Page 1 · Lines 1–24

o Overview
-> Social Engineering
-> DoS and DDoS Mechanics
o Social Engineering
-> Phishing deceives users into revealing data or unsafe action.
-> Spear-phishing tailors lures to a person or group.
-> Smishing uses SMS/text; vishing uses voice or phone calls.
-> Scammers impersonate banks, vendors, coworkers, or help desks.
-> Urgency, secrecy, payment changes, code requests warn users.
-> Sender display and caller ID can be spoofed.
-> Verify through a known independent number or contact path.
-> Never disclose passwords or one-time login codes to callers.
-> Report suspicious messages through the approved route.
o DoS and DDoS Mechanics
-> DoS makes a service unavailable to legitimate users.
-> Flooding can exhaust link capacity or server request handling.
-> SYN flood leaves TCP handshakes incomplete, holding state.
-> Application requests consume CPU, memory, or worker slots.
-> DDoS coordinates many machines against one target.
-> Botnet is compromised devices under remote control.
-> Compromised devices are victims as well as traffic sources.
-> Distributed sources complicate attribution and filtering.
-> Traffic spikes and maintenance can mimic attack symptoms.
-> Monitor traffic; coordinate with admin and provider.

Social, Service, Cryptographic, and Wireless Threats

Page 2 · Lines 25–48

o Overview
-> Hash Collisions and Birthday Effect
-> Downgrades and Wireless Weaknesses
o Hash Collisions and Birthday Effect
-> A hash maps input data to a fixed-length digest.
-> Collision means distinct inputs share a finite digest.
-> Preimage seeks input for a chosen digest: a different goal.
-> For ideal n-bit hash, generic collision work is about 2^(n/2).
-> Birthday effect finds any pair sooner than target preimage.
-> This is a probability/work estimate, not an exact threshold.
-> Collision is not decryption or original-message recovery.
-> Hashing differs from reversible, key-based encryption.
-> RFC 6962 uses domain-separated SHA-256 Merkle-tree hashes.
o Downgrades and Wireless Weaknesses
-> Downgrade induces peers to use weaker protocol/options.
-> Fallback to obsolete versions can expose known weaknesses.
-> RFC 9325 says TLS 1.2 clients must not fall back earlier.
-> Use maintained protocols; compatibility can limit versions.
-> Evil twin imitates a trusted Wi-Fi name to lure users.
-> SSID display alone does not authenticate the access point.
-> WEP's weak IV/key design lets traffic aid key recovery.
-> WEP is obsolete; use modern WPA2/WPA3 configuration instead.
-> Hidden SSID and MAC filtering do not replace encryption.
-> HTTPS/VPN have limits; rogue access-point risk remains.
Sources, practice, lab and scope notes

Objectives

  • CS-CTV-05
  • CS-CTV-02
  • CS-CTV-06
  • CS-CTV-08
  • CS-CTV-09

Sources

  • 2026-2027 FBLA Cybersecurity Guidelines — fetched; Read study guide pages 5-6 for current scope and wording of assigned Security Fundamentals and Cyber Threats and Vulnerabilities objectives; used only to establish scope, not technical mechanisms.
  • NIST SP 800-63A-4: Identity Proofing and Enrollment — fetched; Read identity proofing overview and passages on resolution, evidence/attribute validation, verification of rightful owner, enrollment, and assurance limits.
  • NIST SP 800-63B-4: Authentication and Authenticator Management — fetched; Read authentication definition, AAL summaries, distinct-factor MFA, authenticator control, phishing resistance, OTP and out-of-band limitations.
  • NIST CSRC Glossary: Attestation — fetched; Read definition: digitally sign hardware-secured measurements and have requester validate signature and measurements; glossary term context is SP 1800-19B.
  • NIST CSRC Glossary: Honeypot — fetched; Read definition of an attractive system/resource for potential intruders. NIST glossary term identifies resource examples, not a complete taxonomy of honeynet or honeyfile.
  • NIST SP 800-207: Zero Trust Architecture — fetched; Read official abstract: no implicit trust based solely on physical/network location; ZTA focuses on users, assets, and resources. Full publication not read.
  • OWASP SQL Injection Prevention Cheat Sheet — fetched; Read SQL injection mechanism, parameterized query, allow-list structural choices, and least-privilege passages.
  • CISA: Understanding Denial-of-Service Attacks — fetched; Read DoS flood and SYN-flood mechanics, botnet-based DDoS, compromised devices as victims, monitoring, and response. Page is explicitly archived/outdated; use for basic mechanism only.
  • RFC 9325: Recommendations for Secure Use of TLS/DTLS — fetched; Read TLS version/fallback guidance: TLS 1.2 clients must not fall back to earlier deprecated versions; document recommends modern secure deployment and notes guidance is point-in-time.
  • RFC 6962: Certificate Transparency — fetched; Read hash-tree definitions: SHA-256 digests, distinct leaf/node prefixes for second-preimage resistance, and proof construction. Does not state birthday bound; used for hash/digest context only.

Practice (answers below)

1. A caller demands an SMS code and urgent payment change. Respond safely.

Treat as possible vishing: do not share the code or alter payment. Verify using a known contact number and report. Caller ID can be forged.

2. Does a birthday collision attack decrypt a hashed message?

No. It seeks any colliding pair; ideal n-bit hash generic collision work is about 2^(n/2). It neither decrypts nor finds a chosen message's preimage.

Safe fictional phishing and availability tabletop

  1. Read a fictional payroll voice-call scenario asking for an SMS code and bank change.
  2. Identify vishing cues; choose independent verification and approved reporting path.
  3. Discuss fictional service slowdown: identify resource/provider, preserve event notes, notify response lead.
  4. Name approved mitigation options; do not generate traffic, scan, click links, or contact real numbers.

Expected: No code or payment change is disclosed; callback uses a known contact route. Participants distinguish DoS capacity exhaustion from ordinary outages and identify provider/response coordination. No live systems, credentials, traffic, or personal logs are used.

Limitations: NIST CSRC glossary provided a direct honeypot definition; separate authoritative NIST entries for honeynet and honeyfile were not found. Those common instructional distinctions are explicitly qualified. CISA DoS article is archived and may not reflect current policy; it is used only for basic attack mechanics, while mitigation is described cautiously. RFC 6962 supports hash/digest and Merkle-tree mechanics but not the birthday bound itself; the generic birthday estimate is standard probability analysis and is labeled as an idealized bound.

Secure Platforms and Architecture

Security and Design

Download plain · Download colored

Secure Platforms and Architecture

Page 1 · Lines 1–24

o Overview
-> Cloud responsibility and service models
-> Cloud choices, effects, and shared duties
o Cloud responsibility and service models
-> Cloud moves workloads; it does not remove customer duties.
-> Provider secures cloud facilities, hardware, managed layers.
-> Customer secures data, identities, settings, and lawful use.
-> Exact responsibility depends on service and configuration.
-> IaaS rents compute, storage, and network infrastructure.
-> IaaS customer normally manages guest OS and applications.
-> PaaS provider manages platform/runtime; customer manages app.
-> SaaS vendor runs app; customer manages users and data.
-> More abstraction reduces customer control and admin work.
o Cloud choices, effects, and shared duties
-> Example: IaaS customer patches guest; provider patches host.
-> SaaS customer controls account access and sharing settings.
-> Provider controls do not correct customer misconfiguration.
-> Public cloud can scale quickly without owning facilities.
-> Costs shift toward usage; careless usage can raise bills.
-> Cloud dependence adds provider, network, and outage risks.
-> Classify data before selecting cloud storage or region.
-> Review contract, duties, audit, and recovery options.
-> AWS calls this security of the cloud versus in the cloud.
-> A cloud service is not automatically safer than local hosting.

Secure Platforms and Architecture

Page 2 · Lines 25–48

o Overview
-> Microservices and API security
-> Distributed policy and complexity
o Microservices and API security
-> Microservices are small components communicating over APIs.
-> An API endpoint accepts requests for a defined operation.
-> Each reachable endpoint adds code and attack surface.
-> Authenticate the caller; separately authorize each action.
-> A valid login does not grant every endpoint permission.
-> Service-to-service calls also need identity and access rules.
-> NIST lists authentication and access management as core needs.
-> Secure channels help protect service communications.
-> Mutually authenticate services; authorize each API operation.
o Distributed policy and complexity
-> Many services multiply routes, keys, versions, and policies.
-> Service discovery locates changing service instances.
-> Incorrect discovery can direct requests to hostile endpoints.
-> Gateways centralize some edge checks and traffic controls.
-> Internal services still require correct authorization checks.
-> A service mesh can package communication/security functions.
-> Frameworks reduce repetition but add configuration complexity.
-> Monitoring and rate limits help detect or constrain abuse.
-> Microservices scale independently, not securely by default.
-> Review boundaries; test denied and allowed API calls.
Sources, practice, lab and scope notes

Objectives

  • CS-SD-01
  • CS-SD-02

Sources

  • NIST SP 800-204, Security Strategies for Microservices-based Application Systems — fetched; Read pp. 1, 6-8, 15-16, 17-19, 21-24, 25-30, 33-36. Microservice API security features, identity/access management, discovery, secure communications, monitoring, gateway/service mesh, disadvantages, threats and strategies.
  • AWS Security and Compliance: Shared Responsibility — fetched; Read shared responsibility passages: AWS security of the cloud and customer security in the cloud; AWS manages facilities/hardware while customer retains control of content, platforms, applications, systems, and networks.
  • Docker Docs: What is a container? — fetched; Read explanation and Containers versus VMs: containers are isolated processes sharing a kernel; a VM includes an operating system and its own kernel; VMs and containers may be used together.
  • NIST CSRC Hash Functions — fetched; Read hash definition mapping arbitrary-length messages to fixed-length digests, approved FIPS hash families, stated expected hash properties, and collision-resistance strength table.
  • NIST: Blockchain — fetched; Read NIST description of shared tamper-evident/tamper-resistant ledgers, blocks cryptographically linked to prior blocks, replicated nodes, validation and consensus; NIST notes different implementations and research into security guarantees.
  • RFC 9162: Certificate Transparency Version 2.0 — fetched; Read Merkle-tree passages: efficient inclusion and consistency proofs, append-only log property, and detecting log misbehavior. This is a concrete hash-tree integrity mechanism, not evidence that ledger inputs are true.
  • NIST SP 800-57 Part 1 Rev. 5, Key Management — fetched; Read publication description on key types, security services, cryptographic keying material protection and key-management practices. Landing metadata is used only for those stated scopes.
  • NIST SP 800-63-4, Digital Identity Guidelines — fetched; Read publication description identifying identity proofing, authentication, enrollment, authenticators, management, authentication protocols, federation, and assertions; use only for these scope distinctions.
  • NIST SP 800-207, Zero Trust Architecture — fetched; Read NIST summary: no implicit trust based solely on network location or asset ownership; supports explicit per-resource access framing and segmentation discussion.
  • NIST SP 800-34 Rev. 1, Contingency Planning Guide — fetched; Read publication overview describing contingency planning process, plan development, organizational resiliency, and relationship to incident/emergency plans; not used as evidence for backup copy mechanics.
  • NISTIR 8259A IoT Device Cybersecurity Capability Core Baseline — fetched; Read NIST abstract: baseline device capabilities support common controls protecting devices, device data, systems, and ecosystems; detailed capability descriptions not retrieved.
  • NIST CSRC Glossary: Mandatory Access Control — fetched; Read glossary definition: uniform policy across subjects/objects constrains information passing, privilege delegation, security-attribute changes, and access-rule changes, with trusted-subject exceptions.
  • NIST CSRC Glossary: Discretionary Access Control — fetched; Read glossary definition: object owner or authorized controller decides which subjects receive which object access rights.
  • NIST CSRC Glossary: Role-Based Access Control — fetched; Read glossary definition: user access follows role-linked authorizations typically reflecting organizational functions; role hierarchies may inherit permissions.
  • RFC 20: ASCII format for Network Interchange — fetched; Read for ASCII character encoding context only; not evidence for substitution-cipher security.
  • Harvard CS50x: Caesar — fetched; Read Problem to Solve and the rotation formula (p+k) modulo 26, wraparound and reverse-shift examples, plus the explicit warning that this is not secure by modern standards. The ATTACK example is original arithmetic independently checked from that rule.

Practice (answers below)

1. A SaaS team assumes the vendor controls user sharing. What is wrong?

The provider runs the application, but the customer still manages accounts, data, and many sharing settings. Review the service-specific responsibility split and restrict access.

2. Why is API login insufficient to protect every microservice endpoint?

Authentication establishes a caller identity; authorization decides whether that identity may perform this operation. Each endpoint needs an appropriate policy, including service-to-service calls.

Local design and data-protection tabletop

  1. Use fictional cloud app with three API services and sample records.
  2. Mark provider/customer duties for IaaS, PaaS, and SaaS versions.
  3. Draw physical/logical segments and label allowed service paths.
  4. Compare one VM boundary with containers sharing its kernel.
  5. Choose full plus incremental or differential backup and restore order.
  6. Assign fictional roles; test allowed and denied record actions.
  7. Calculate Caesar +3 for CAT, then reverse it; discuss weakness.
  8. Hash two harmless sample strings locally; compare digests.
  9. Identify which claims need identity, trusted key, or external evidence.

Expected: Customer duties remain for cloud identity, data, and settings. Every endpoint has authentication and least-privilege authorization. Segment rules permit required flows and block others. VM guest kernel differs from containers' shared host kernel. Backup restore chain is explicit; RAID is not substituted for backup. Role policy denies unauthorized edits and limits auditor access. CAT shifts to FDW; reverse shift returns CAT; toy is not secure. Hash change can indicate changed bytes but proves neither source nor truth.

Limitations: CS-SD-01 cloud responsibility varies by provider, service model, contract, and configuration; AWS is an illustrative provider source. NIST SP 800-34 publication overview was read, but not its detailed backup-method sections; full/incremental/differential mechanics are basic explanatory notes, not attributed to that overview. NIST SP 800-57 and SP 800-63 fetched pages expose publication scope/metadata; they do not establish every algorithm or authenticator detail stated here. The requested NIST hash and blockchain passages were fetched and read. Blockchain security depends on implementation, governance, consensus, keys, and participants; it does not establish truth or guaranteed immutability. Classical Caesar example is a toy arithmetic illustration, not a modern cryptographic recommendation.

Segmentation, Isolation, and IoT

Security and Design

Download plain · Download colored

Segmentation, Isolation, and IoT

Page 1 · Lines 1–24

o Overview
-> Segmentation and trust boundaries
-> Test segment policy and verify boundaries
o Segmentation and trust boundaries
-> Physical segmentation separates equipment, cabling, or sites.
-> Logical segmentation partitions shared gear with rules.
-> VLANs separate layer-two broadcast domains on shared switches.
-> ACLs and firewalls govern traffic across segment boundaries.
-> Segmentation can limit lateral movement after compromise.
-> A VLAN alone is not encryption or identity authentication.
-> Rules must allow required paths and block unauthorized paths.
-> NIST zero trust rejects trust based only on network location.
-> Segmentation complements, not replaces, access checks.
o Test segment policy and verify boundaries
-> Identify assets, owners, data flows, boundaries first.
-> Permit only needed source, destination, protocol, service.
-> Test intended communication after policy changes.
-> Test forbidden communication from each relevant segment.
-> Monitor boundary traffic for unexpected communication.
-> Physical separation may share unsafe administration.
-> Logical separation may fail through bad rules or trunking.
-> Document exceptions, owners, and review dates.
-> Choose controls from threat and cost needs.
-> A subnet or VLAN is not a complete security boundary.

Segmentation, Isolation, and IoT

Page 2 · Lines 25–48

o Overview
-> Virtual machines and containers
-> IoT risks and safer deployment
o Virtual machines and containers
-> A hypervisor allocates host resources to virtual machines.
-> A VM typically runs a guest OS with its own kernel.
-> Containers isolate processes and package dependencies.
-> Containers commonly share the host operating-system kernel.
-> VMs add guest OS overhead; containers can be lighter.
-> VM isolation can fail through hypervisor flaws or settings.
-> A container kernel escape may threaten other host containers.
-> Patch hosts, hypervisors, guest systems, images, libraries.
-> Limit privileges, mounts, capabilities, and network access.
o IoT risks and safer deployment
-> VMs and containers may be combined on one host.
-> Isolation reduces some risks; it is not an absolute guarantee.
-> IoT means networked sensors, cameras, appliances, and devices.
-> Default passwords and open services expose IoT devices.
-> Old firmware and weak updates leave known flaws unpatched.
-> Constrained power or memory can limit security monitoring.
-> Excess device data collection creates privacy risk.
-> Inventory device, owner, firmware, network, support end date.
-> Change defaults; disable unused features; patch and isolate.
-> NIST baseline groups device capabilities supporting controls.
Sources, practice, lab and scope notes

Objectives

  • CS-SD-03
  • CS-SD-04
  • CS-SD-05

Sources

  • NIST SP 800-204, Security Strategies for Microservices-based Application Systems — fetched; Read pp. 1, 6-8, 15-16, 17-19, 21-24, 25-30, 33-36. Microservice API security features, identity/access management, discovery, secure communications, monitoring, gateway/service mesh, disadvantages, threats and strategies.
  • AWS Security and Compliance: Shared Responsibility — fetched; Read shared responsibility passages: AWS security of the cloud and customer security in the cloud; AWS manages facilities/hardware while customer retains control of content, platforms, applications, systems, and networks.
  • Docker Docs: What is a container? — fetched; Read explanation and Containers versus VMs: containers are isolated processes sharing a kernel; a VM includes an operating system and its own kernel; VMs and containers may be used together.
  • NIST CSRC Hash Functions — fetched; Read hash definition mapping arbitrary-length messages to fixed-length digests, approved FIPS hash families, stated expected hash properties, and collision-resistance strength table.
  • NIST: Blockchain — fetched; Read NIST description of shared tamper-evident/tamper-resistant ledgers, blocks cryptographically linked to prior blocks, replicated nodes, validation and consensus; NIST notes different implementations and research into security guarantees.
  • RFC 9162: Certificate Transparency Version 2.0 — fetched; Read Merkle-tree passages: efficient inclusion and consistency proofs, append-only log property, and detecting log misbehavior. This is a concrete hash-tree integrity mechanism, not evidence that ledger inputs are true.
  • NIST SP 800-57 Part 1 Rev. 5, Key Management — fetched; Read publication description on key types, security services, cryptographic keying material protection and key-management practices. Landing metadata is used only for those stated scopes.
  • NIST SP 800-63-4, Digital Identity Guidelines — fetched; Read publication description identifying identity proofing, authentication, enrollment, authenticators, management, authentication protocols, federation, and assertions; use only for these scope distinctions.
  • NIST SP 800-207, Zero Trust Architecture — fetched; Read NIST summary: no implicit trust based solely on network location or asset ownership; supports explicit per-resource access framing and segmentation discussion.
  • NIST SP 800-34 Rev. 1, Contingency Planning Guide — fetched; Read publication overview describing contingency planning process, plan development, organizational resiliency, and relationship to incident/emergency plans; not used as evidence for backup copy mechanics.
  • NISTIR 8259A IoT Device Cybersecurity Capability Core Baseline — fetched; Read NIST abstract: baseline device capabilities support common controls protecting devices, device data, systems, and ecosystems; detailed capability descriptions not retrieved.
  • NIST CSRC Glossary: Mandatory Access Control — fetched; Read glossary definition: uniform policy across subjects/objects constrains information passing, privilege delegation, security-attribute changes, and access-rule changes, with trusted-subject exceptions.
  • NIST CSRC Glossary: Discretionary Access Control — fetched; Read glossary definition: object owner or authorized controller decides which subjects receive which object access rights.
  • NIST CSRC Glossary: Role-Based Access Control — fetched; Read glossary definition: user access follows role-linked authorizations typically reflecting organizational functions; role hierarchies may inherit permissions.
  • RFC 20: ASCII format for Network Interchange — fetched; Read for ASCII character encoding context only; not evidence for substitution-cipher security.
  • Harvard CS50x: Caesar — fetched; Read Problem to Solve and the rotation formula (p+k) modulo 26, wraparound and reverse-shift examples, plus the explicit warning that this is not secure by modern standards. The ATTACK example is original arithmetic independently checked from that rule.

Practice (answers below)

1. Two container apps share a host. What isolation limit matters?

They commonly share the host kernel, unlike VMs with guest kernels. A kernel escape can cross container boundaries; patch the host and limit privileges, while choosing stronger isolation when justified.

2. Name two IoT risks and a practical response to each.

Default credentials call for changing passwords and disabling unused access; unsupported firmware calls for isolation, monitoring, and planned replacement. Network isolation reduces exposure but does not fix device flaws.

Local design and data-protection tabletop

  1. Use fictional cloud app with three API services and sample records.
  2. Mark provider/customer duties for IaaS, PaaS, and SaaS versions.
  3. Draw physical/logical segments and label allowed service paths.
  4. Compare one VM boundary with containers sharing its kernel.
  5. Choose full plus incremental or differential backup and restore order.
  6. Assign fictional roles; test allowed and denied record actions.
  7. Calculate Caesar +3 for CAT, then reverse it; discuss weakness.
  8. Hash two harmless sample strings locally; compare digests.
  9. Identify which claims need identity, trusted key, or external evidence.

Expected: Customer duties remain for cloud identity, data, and settings. Every endpoint has authentication and least-privilege authorization. Segment rules permit required flows and block others. VM guest kernel differs from containers' shared host kernel. Backup restore chain is explicit; RAID is not substituted for backup. Role policy denies unauthorized edits and limits auditor access. CAT shifts to FDW; reverse shift returns CAT; toy is not secure. Hash change can indicate changed bytes but proves neither source nor truth.

Limitations: CS-SD-01 cloud responsibility varies by provider, service model, contract, and configuration; AWS is an illustrative provider source. NIST SP 800-34 publication overview was read, but not its detailed backup-method sections; full/incremental/differential mechanics are basic explanatory notes, not attributed to that overview. NIST SP 800-57 and SP 800-63 fetched pages expose publication scope/metadata; they do not establish every algorithm or authenticator detail stated here. The requested NIST hash and blockchain passages were fetched and read. Blockchain security depends on implementation, governance, consensus, keys, and participants; it does not establish truth or guaranteed immutability. Classical Caesar example is a toy arithmetic illustration, not a modern cryptographic recommendation.

Resilience and Security Testing

Security and Design

Download plain · Download colored

Resilience and Security Testing

Page 1 · Lines 1–24

o Overview
-> Backup methods and recovery
-> RAID, UPS, and CIA design cases
o Backup methods and recovery
-> A backup is a separate recoverable copy of selected data.
-> Full copies selected data; restore is straightforward.
-> Incremental copies changes since the most recent backup.
-> Restore a full backup, then each incremental in sequence.
-> Differential copies changes since the last full backup.
-> Restore a full backup and the latest differential copy.
-> Differentials grow until another full backup is made.
-> Test restores; unreadable copies do not protect.
-> Keep isolated or offline copies to resist ransomware.
o RAID, UPS, and CIA design cases
-> RAID combines disks for performance or fault tolerance.
-> RAID 1 mirrors; RAID 5 tolerates one disk failure.
-> RAID 6 tolerates two disk failures; RAID 0 has no redundancy.
-> RAID cannot protect from deletion, malware, theft, or fire.
-> RAID is not backup; keep independent, versioned copies.
-> UPS battery bridges brief outages and enables safe shutdown.
-> Confidentiality: encrypt backups and restrict key access.
-> Integrity: detect changes with trusted hashes or signatures.
-> Availability: UPS and restores limit outage impact.
-> No single safeguard guarantees all three CIA goals.

Resilience and Security Testing

Page 2 · Lines 25–48

o Overview
-> Security testing and architecture
-> Evidence, remediation, and retesting
o Security testing and architecture
-> Testing checks controls against stated needs and threats.
-> Design review traces assets, identities, flows, boundaries.
-> Configuration review finds excess access and weak settings.
-> Scanners find known issues; validate findings and rank risk.
-> Static analysis examines code without executing it.
-> Dynamic tests exercise a running application or service.
-> Pen tests simulate scoped attacks with authorization.
-> Methods have blind spots; combine them according to risk.
-> Test staging systems with written scope and stop conditions.
o Evidence, remediation, and retesting
-> Record affected asset, evidence, impact, owner, priority.
-> Fix underlying cause rather than only hiding an alert.
-> Retest the original path and nearby paths after a fix.
-> Track exceptions, residual risk, deadlines, and approvals.
-> Recovery plans assign roles, priorities, and restore order.
-> Set recovery time and acceptable data-loss targets.
-> Exercise recovery without risking live data or systems.
-> Use fictional scenario; check backup chain completeness.
-> Expected: team identifies restore order, keys, dependencies.
-> A passed scan or tabletop is not proof of total security.
Sources, practice, lab and scope notes

Objectives

  • CS-SD-06
  • CS-SD-07
  • CS-SD-08

Sources

  • NIST SP 800-204, Security Strategies for Microservices-based Application Systems — fetched; Read pp. 1, 6-8, 15-16, 17-19, 21-24, 25-30, 33-36. Microservice API security features, identity/access management, discovery, secure communications, monitoring, gateway/service mesh, disadvantages, threats and strategies.
  • AWS Security and Compliance: Shared Responsibility — fetched; Read shared responsibility passages: AWS security of the cloud and customer security in the cloud; AWS manages facilities/hardware while customer retains control of content, platforms, applications, systems, and networks.
  • Docker Docs: What is a container? — fetched; Read explanation and Containers versus VMs: containers are isolated processes sharing a kernel; a VM includes an operating system and its own kernel; VMs and containers may be used together.
  • NIST CSRC Hash Functions — fetched; Read hash definition mapping arbitrary-length messages to fixed-length digests, approved FIPS hash families, stated expected hash properties, and collision-resistance strength table.
  • NIST: Blockchain — fetched; Read NIST description of shared tamper-evident/tamper-resistant ledgers, blocks cryptographically linked to prior blocks, replicated nodes, validation and consensus; NIST notes different implementations and research into security guarantees.
  • RFC 9162: Certificate Transparency Version 2.0 — fetched; Read Merkle-tree passages: efficient inclusion and consistency proofs, append-only log property, and detecting log misbehavior. This is a concrete hash-tree integrity mechanism, not evidence that ledger inputs are true.
  • NIST SP 800-57 Part 1 Rev. 5, Key Management — fetched; Read publication description on key types, security services, cryptographic keying material protection and key-management practices. Landing metadata is used only for those stated scopes.
  • NIST SP 800-63-4, Digital Identity Guidelines — fetched; Read publication description identifying identity proofing, authentication, enrollment, authenticators, management, authentication protocols, federation, and assertions; use only for these scope distinctions.
  • NIST SP 800-207, Zero Trust Architecture — fetched; Read NIST summary: no implicit trust based solely on network location or asset ownership; supports explicit per-resource access framing and segmentation discussion.
  • NIST SP 800-34 Rev. 1, Contingency Planning Guide — fetched; Read publication overview describing contingency planning process, plan development, organizational resiliency, and relationship to incident/emergency plans; not used as evidence for backup copy mechanics.
  • NISTIR 8259A IoT Device Cybersecurity Capability Core Baseline — fetched; Read NIST abstract: baseline device capabilities support common controls protecting devices, device data, systems, and ecosystems; detailed capability descriptions not retrieved.
  • NIST CSRC Glossary: Mandatory Access Control — fetched; Read glossary definition: uniform policy across subjects/objects constrains information passing, privilege delegation, security-attribute changes, and access-rule changes, with trusted-subject exceptions.
  • NIST CSRC Glossary: Discretionary Access Control — fetched; Read glossary definition: object owner or authorized controller decides which subjects receive which object access rights.
  • NIST CSRC Glossary: Role-Based Access Control — fetched; Read glossary definition: user access follows role-linked authorizations typically reflecting organizational functions; role hierarchies may inherit permissions.
  • RFC 20: ASCII format for Network Interchange — fetched; Read for ASCII character encoding context only; not evidence for substitution-cipher security.
  • Harvard CS50x: Caesar — fetched; Read Problem to Solve and the rotation formula (p+k) modulo 26, wraparound and reverse-shift examples, plus the explicit warning that this is not secure by modern standards. The ATTACK example is original arithmetic independently checked from that rule.

Practice (answers below)

1. Which is safer to restore: full plus incremental, or RAID alone?

A full plus complete incremental chain provides versioned recovery; RAID mainly handles some disk failures and mirrors unwanted deletion or corruption. Keep independent backups and test restores.

2. A scan finds no vulnerabilities. Is the architecture secure?

No. Scans have coverage and detection limits. Combine design, configuration, code, and authorized runtime testing; validate findings and retest fixes.

Local design and data-protection tabletop

  1. Use fictional cloud app with three API services and sample records.
  2. Mark provider/customer duties for IaaS, PaaS, and SaaS versions.
  3. Draw physical/logical segments and label allowed service paths.
  4. Compare one VM boundary with containers sharing its kernel.
  5. Choose full plus incremental or differential backup and restore order.
  6. Assign fictional roles; test allowed and denied record actions.
  7. Calculate Caesar +3 for CAT, then reverse it; discuss weakness.
  8. Hash two harmless sample strings locally; compare digests.
  9. Identify which claims need identity, trusted key, or external evidence.

Expected: Customer duties remain for cloud identity, data, and settings. Every endpoint has authentication and least-privilege authorization. Segment rules permit required flows and block others. VM guest kernel differs from containers' shared host kernel. Backup restore chain is explicit; RAID is not substituted for backup. Role policy denies unauthorized edits and limits auditor access. CAT shifts to FDW; reverse shift returns CAT; toy is not secure. Hash change can indicate changed bytes but proves neither source nor truth.

Limitations: CS-SD-01 cloud responsibility varies by provider, service model, contract, and configuration; AWS is an illustrative provider source. NIST SP 800-34 publication overview was read, but not its detailed backup-method sections; full/incremental/differential mechanics are basic explanatory notes, not attributed to that overview. NIST SP 800-57 and SP 800-63 fetched pages expose publication scope/metadata; they do not establish every algorithm or authenticator detail stated here. The requested NIST hash and blockchain passages were fetched and read. Blockchain security depends on implementation, governance, consensus, keys, and participants; it does not establish truth or guaranteed immutability. Classical Caesar example is a toy arithmetic illustration, not a modern cryptographic recommendation.

Cryptography and Data Protection

Network and Data Security

Download plain · Download colored

Cryptography and Data Protection

Page 1 · Lines 1–24

o Overview
-> Symmetric and public-key cryptography
-> Signatures, exchange, and key limits
o Symmetric and public-key cryptography
-> Cryptography uses algorithms and keys to protect information.
-> Encryption transforms readable plaintext into ciphertext.
-> Decryption with the right key recovers the plaintext.
-> Symmetric cryptography uses one shared secret key both ways.
-> It is efficient; parties must protect and share the secret.
-> Public-key cryptography uses a related key pair.
-> Public key may be shared; private key must remain protected.
-> Encrypt to recipient's public key; private key decrypts.
-> This provides confidentiality, not sender proof alone.
o Signatures, exchange, and key limits
-> Signer uses private key; others verify with public key.
-> Signatures can support integrity and key-possession checks.
-> A signature does not make the signed statement true.
-> Key exchange establishes a shared secret over a channel.
-> Unauthenticated exchange risks an active intermediary attack.
-> Certificates can bind a public key to a named identity.
-> Validate certificate chain, name, dates, and intended use.
-> Protect, rotate, revoke, and recover keys by policy.
-> Hybrid TLS pairs key agreement with symmetric data encryption.
-> Key loss blocks decryption; compromise threatens protection.

Cryptography and Data Protection

Page 2 · Lines 25–48

o Overview
-> Caesar and substitution ciphers
-> Hashing, blockchain, and trust limits
o Caesar and substitution ciphers
-> A shift cipher moves each alphabet letter by a fixed amount.
-> Caesar is a shift cipher, often shown with shift three.
-> Using +3: A becomes D, B becomes E, and X becomes A.
-> Wrap after Z: Y becomes B and Z becomes C.
-> ATTACK with +3 becomes DWWDFN; reverse shift recovers it.
-> Substitution replaces letters using a fixed alphabet mapping.
-> Caesar is one simple special case of substitution.
-> Repeated patterns and frequencies reveal toy ciphers.
-> Small keyspaces are searchable; these ciphers are not secure.
o Hashing, blockchain, and trust limits
-> Hash maps arbitrary-length input to a fixed-length digest.
-> Hashing is not encryption; there is no decryption key.
-> Collision: two distinct inputs have the same digest.
-> Collision resistance makes finding one hard in practice.
-> It is not a promise that collisions are impossible.
-> A trusted digest can help detect changed data.
-> A hash alone does not prove who created the data.
-> Blockchain links blocks by hash and consensus rules.
-> NIST: shared ledgers are tamper-evident, not truth-proof.
-> RFC 9162 Merkle proofs check log inclusion and consistency.
Sources, practice, lab and scope notes

Objectives

  • CS-NDS-01
  • CS-NDS-02
  • CS-NDS-03
  • CS-NDS-07

Sources

  • NIST SP 800-204, Security Strategies for Microservices-based Application Systems — fetched; Read pp. 1, 6-8, 15-16, 17-19, 21-24, 25-30, 33-36. Microservice API security features, identity/access management, discovery, secure communications, monitoring, gateway/service mesh, disadvantages, threats and strategies.
  • AWS Security and Compliance: Shared Responsibility — fetched; Read shared responsibility passages: AWS security of the cloud and customer security in the cloud; AWS manages facilities/hardware while customer retains control of content, platforms, applications, systems, and networks.
  • Docker Docs: What is a container? — fetched; Read explanation and Containers versus VMs: containers are isolated processes sharing a kernel; a VM includes an operating system and its own kernel; VMs and containers may be used together.
  • NIST CSRC Hash Functions — fetched; Read hash definition mapping arbitrary-length messages to fixed-length digests, approved FIPS hash families, stated expected hash properties, and collision-resistance strength table.
  • NIST: Blockchain — fetched; Read NIST description of shared tamper-evident/tamper-resistant ledgers, blocks cryptographically linked to prior blocks, replicated nodes, validation and consensus; NIST notes different implementations and research into security guarantees.
  • RFC 9162: Certificate Transparency Version 2.0 — fetched; Read Merkle-tree passages: efficient inclusion and consistency proofs, append-only log property, and detecting log misbehavior. This is a concrete hash-tree integrity mechanism, not evidence that ledger inputs are true.
  • NIST SP 800-57 Part 1 Rev. 5, Key Management — fetched; Read publication description on key types, security services, cryptographic keying material protection and key-management practices. Landing metadata is used only for those stated scopes.
  • NIST SP 800-63-4, Digital Identity Guidelines — fetched; Read publication description identifying identity proofing, authentication, enrollment, authenticators, management, authentication protocols, federation, and assertions; use only for these scope distinctions.
  • NIST SP 800-207, Zero Trust Architecture — fetched; Read NIST summary: no implicit trust based solely on network location or asset ownership; supports explicit per-resource access framing and segmentation discussion.
  • NIST SP 800-34 Rev. 1, Contingency Planning Guide — fetched; Read publication overview describing contingency planning process, plan development, organizational resiliency, and relationship to incident/emergency plans; not used as evidence for backup copy mechanics.
  • NISTIR 8259A IoT Device Cybersecurity Capability Core Baseline — fetched; Read NIST abstract: baseline device capabilities support common controls protecting devices, device data, systems, and ecosystems; detailed capability descriptions not retrieved.
  • NIST CSRC Glossary: Mandatory Access Control — fetched; Read glossary definition: uniform policy across subjects/objects constrains information passing, privilege delegation, security-attribute changes, and access-rule changes, with trusted-subject exceptions.
  • NIST CSRC Glossary: Discretionary Access Control — fetched; Read glossary definition: object owner or authorized controller decides which subjects receive which object access rights.
  • NIST CSRC Glossary: Role-Based Access Control — fetched; Read glossary definition: user access follows role-linked authorizations typically reflecting organizational functions; role hierarchies may inherit permissions.
  • RFC 20: ASCII format for Network Interchange — fetched; Read for ASCII character encoding context only; not evidence for substitution-cipher security.
  • Harvard CS50x: Caesar — fetched; Read Problem to Solve and the rotation formula (p+k) modulo 26, wraparound and reverse-shift examples, plus the explicit warning that this is not secure by modern standards. The ATTACK example is original arithmetic independently checked from that rule.

Practice (answers below)

1. Encrypt a message to Pat and sign it: which keys are used?

Encrypt using Pat's public key so Pat can decrypt with Pat's private key. Sign with the sender's private key; verify using the sender's public key. Protect keys and authenticate their identity binding.

2. Decode DWWDFN under Caesar shift +3 and assess security.

Shift each letter back three: ATTACK. This demonstrates reversible substitution only; frequency patterns and a tiny keyspace make it unsuitable for modern security.

Local design and data-protection tabletop

  1. Use fictional cloud app with three API services and sample records.
  2. Mark provider/customer duties for IaaS, PaaS, and SaaS versions.
  3. Draw physical/logical segments and label allowed service paths.
  4. Compare one VM boundary with containers sharing its kernel.
  5. Choose full plus incremental or differential backup and restore order.
  6. Assign fictional roles; test allowed and denied record actions.
  7. Calculate Caesar +3 for CAT, then reverse it; discuss weakness.
  8. Hash two harmless sample strings locally; compare digests.
  9. Identify which claims need identity, trusted key, or external evidence.

Expected: Customer duties remain for cloud identity, data, and settings. Every endpoint has authentication and least-privilege authorization. Segment rules permit required flows and block others. VM guest kernel differs from containers' shared host kernel. Backup restore chain is explicit; RAID is not substituted for backup. Role policy denies unauthorized edits and limits auditor access. CAT shifts to FDW; reverse shift returns CAT; toy is not secure. Hash change can indicate changed bytes but proves neither source nor truth.

Limitations: CS-SD-01 cloud responsibility varies by provider, service model, contract, and configuration; AWS is an illustrative provider source. NIST SP 800-34 publication overview was read, but not its detailed backup-method sections; full/incremental/differential mechanics are basic explanatory notes, not attributed to that overview. NIST SP 800-57 and SP 800-63 fetched pages expose publication scope/metadata; they do not establish every algorithm or authenticator detail stated here. The requested NIST hash and blockchain passages were fetched and read. Blockchain security depends on implementation, governance, consensus, keys, and participants; it does not establish truth or guaranteed immutability. Classical Caesar example is a toy arithmetic illustration, not a modern cryptographic recommendation.

Data States and Access Control

Network and Data Security

Download plain · Download colored

Data States and Access Control

Page 1 · Lines 1–24

o Overview
-> Three states of data
-> MAC, DAC, and RBAC models
o Three states of data
-> Data at rest is stored on disk, device, backup, or database.
-> Protect stored data with encryption and account permissions.
-> Data in transit moves between devices or services.
-> Use protected channels and verify communicating endpoints.
-> Data in use is actively processed by an application.
-> Limit process, memory, screen, and log exposure.
-> Encryption at rest may not protect data after unlock.
-> Transit encryption does not protect a compromised endpoint.
-> Select controls based on sensitivity and threat model.
o MAC, DAC, and RBAC models
-> MAC means mandatory access control under central policy.
-> Labels and clearance can govern classified document access.
-> Ordinary users cannot freely override mandatory policy.
-> DAC means discretionary access control assigned by owner.
-> Example: file owner shares a document with colleagues.
-> Sharing can propagate access; review inherited permissions.
-> RBAC means role-based access control tied to job duties.
-> Payroll role reads pay data; approver role authorizes pay.
-> Assign needed roles; remove stale role membership.
-> Models can coexist; choose for risk and workflow.

Data States and Access Control

Page 2 · Lines 25–48

o Overview
-> Authentication and MFA
-> Certificates, tokens, and policy
o Authentication and MFA
-> Authentication checks control of an identity's authenticator.
-> Authorization decides which resource action is permitted.
-> Accounting records access and actions for review.
-> MFA combines distinct types: know, have, or are.
-> Two passwords are both knowledge, not two factors.
-> A password plus authenticator token is two different factors.
-> MFA reduces password-only risk but does not stop every attack.
-> Phishing-resistant authenticators reduce credential relay.
-> Protect enrollment, recovery, and authenticator revocation.
o Certificates, tokens, and policy
-> Certificate binds a public key to an identity under CA trust.
-> Validate chain, service name, dates, and certificate purpose.
-> Certificate authentication does not authorize every action.
-> Token carries an assertion or credential to a resource.
-> Check token issuer, signature, audience, expiry, and scope.
-> Bearer token may be used by whoever steals it; protect it.
-> Short expiry limits exposure but does not prevent theft.
-> Authorize each API action using identity and least privilege.
-> Revoke compromised credentials and review resulting access.
-> NIST 800-63-4 covers proofing, authenticators, and federation.
Sources, practice, lab and scope notes

Objectives

  • CS-NDS-04
  • CS-NDS-05
  • CS-NDS-06
  • CS-SD-02

Sources

  • NIST SP 800-204, Security Strategies for Microservices-based Application Systems — fetched; Read pp. 1, 6-8, 15-16, 17-19, 21-24, 25-30, 33-36. Microservice API security features, identity/access management, discovery, secure communications, monitoring, gateway/service mesh, disadvantages, threats and strategies.
  • AWS Security and Compliance: Shared Responsibility — fetched; Read shared responsibility passages: AWS security of the cloud and customer security in the cloud; AWS manages facilities/hardware while customer retains control of content, platforms, applications, systems, and networks.
  • Docker Docs: What is a container? — fetched; Read explanation and Containers versus VMs: containers are isolated processes sharing a kernel; a VM includes an operating system and its own kernel; VMs and containers may be used together.
  • NIST CSRC Hash Functions — fetched; Read hash definition mapping arbitrary-length messages to fixed-length digests, approved FIPS hash families, stated expected hash properties, and collision-resistance strength table.
  • NIST: Blockchain — fetched; Read NIST description of shared tamper-evident/tamper-resistant ledgers, blocks cryptographically linked to prior blocks, replicated nodes, validation and consensus; NIST notes different implementations and research into security guarantees.
  • RFC 9162: Certificate Transparency Version 2.0 — fetched; Read Merkle-tree passages: efficient inclusion and consistency proofs, append-only log property, and detecting log misbehavior. This is a concrete hash-tree integrity mechanism, not evidence that ledger inputs are true.
  • NIST SP 800-57 Part 1 Rev. 5, Key Management — fetched; Read publication description on key types, security services, cryptographic keying material protection and key-management practices. Landing metadata is used only for those stated scopes.
  • NIST SP 800-63-4, Digital Identity Guidelines — fetched; Read publication description identifying identity proofing, authentication, enrollment, authenticators, management, authentication protocols, federation, and assertions; use only for these scope distinctions.
  • NIST SP 800-207, Zero Trust Architecture — fetched; Read NIST summary: no implicit trust based solely on network location or asset ownership; supports explicit per-resource access framing and segmentation discussion.
  • NIST SP 800-34 Rev. 1, Contingency Planning Guide — fetched; Read publication overview describing contingency planning process, plan development, organizational resiliency, and relationship to incident/emergency plans; not used as evidence for backup copy mechanics.
  • NISTIR 8259A IoT Device Cybersecurity Capability Core Baseline — fetched; Read NIST abstract: baseline device capabilities support common controls protecting devices, device data, systems, and ecosystems; detailed capability descriptions not retrieved.
  • NIST CSRC Glossary: Mandatory Access Control — fetched; Read glossary definition: uniform policy across subjects/objects constrains information passing, privilege delegation, security-attribute changes, and access-rule changes, with trusted-subject exceptions.
  • NIST CSRC Glossary: Discretionary Access Control — fetched; Read glossary definition: object owner or authorized controller decides which subjects receive which object access rights.
  • NIST CSRC Glossary: Role-Based Access Control — fetched; Read glossary definition: user access follows role-linked authorizations typically reflecting organizational functions; role hierarchies may inherit permissions.
  • RFC 20: ASCII format for Network Interchange — fetched; Read for ASCII character encoding context only; not evidence for substitution-cipher security.
  • Harvard CS50x: Caesar — fetched; Read Problem to Solve and the rotation formula (p+k) modulo 26, wraparound and reverse-shift examples, plus the explicit warning that this is not secure by modern standards. The ATTACK example is original arithmetic independently checked from that rule.

Practice (answers below)

1. A file owner shares a folder directly. Which model is illustrated?

DAC: an owner grants access at discretion. Review inheritance and remove unnecessary access. MAC instead applies central labels/rules; RBAC assigns rights through roles.

2. A valid certificate authenticates a user. Does it grant database write access?

No. Certificate validation can authenticate a key under CA trust; authorization separately checks whether that identity may write. A scoped token or policy must grant that action.

Local design and data-protection tabletop

  1. Use fictional cloud app with three API services and sample records.
  2. Mark provider/customer duties for IaaS, PaaS, and SaaS versions.
  3. Draw physical/logical segments and label allowed service paths.
  4. Compare one VM boundary with containers sharing its kernel.
  5. Choose full plus incremental or differential backup and restore order.
  6. Assign fictional roles; test allowed and denied record actions.
  7. Calculate Caesar +3 for CAT, then reverse it; discuss weakness.
  8. Hash two harmless sample strings locally; compare digests.
  9. Identify which claims need identity, trusted key, or external evidence.

Expected: Customer duties remain for cloud identity, data, and settings. Every endpoint has authentication and least-privilege authorization. Segment rules permit required flows and block others. VM guest kernel differs from containers' shared host kernel. Backup restore chain is explicit; RAID is not substituted for backup. Role policy denies unauthorized edits and limits auditor access. CAT shifts to FDW; reverse shift returns CAT; toy is not secure. Hash change can indicate changed bytes but proves neither source nor truth.

Limitations: CS-SD-01 cloud responsibility varies by provider, service model, contract, and configuration; AWS is an illustrative provider source. NIST SP 800-34 publication overview was read, but not its detailed backup-method sections; full/incremental/differential mechanics are basic explanatory notes, not attributed to that overview. NIST SP 800-57 and SP 800-63 fetched pages expose publication scope/metadata; they do not establish every algorithm or authenticator detail stated here. The requested NIST hash and blockchain passages were fetched and read. Blockchain security depends on implementation, governance, consensus, keys, and participants; it does not establish truth or guaranteed immutability. Classical Caesar example is a toy arithmetic illustration, not a modern cryptographic recommendation.

Policies, Continuity, and Secure Communication

Security Operations and Management

Download plain · Download colored

Policies, Continuity, and Secure Communication

Page 1 · Lines 1–24

o Overview
-> Policies and recovery plans
-> Recovery targets and exercise
o Policies and recovery plans
-> AUP states permitted use of organizational systems.
-> InfoSec policy sets security duties and requirements.
-> Policy sets what; procedures describe how to do it.
-> BCP sustains priority business processes through disruption.
-> DRP restores systems and data after a disaster.
-> DRP supports BCP; neither plan is itself a backup.
-> BIA ranks processes, systems, and dependency priorities.
-> Preventive controls reduce likelihood or disruption impact.
-> Plans name activation triggers, teams, contacts, and roles.
o Recovery targets and exercise
-> RTO is the target time to restore a service.
-> RPO is the acceptable age of restored data.
-> RTO limits outage duration; RPO limits data loss.
-> Recovery strategy follows impact and criticality analysis.
-> Define recovery sequence, resources, locations, and contacts.
-> Test, train, and exercise; testing validates recovery ability.
-> Tabletops test decisions; restores test usable recovered data.
-> Compare actual restore time and data age with targets.
-> Record gaps, corrective owners, and retest evidence.
-> Update plans when systems, risks, or roles change.

Policies, Continuity, and Secure Communication

Page 2 · Lines 25–48

o Overview
-> Secure messaging and email
-> Data minimization and change control
o Secure messaging and email
-> Verify recipients and addresses before sending sensitive data.
-> Use approved protected channels for sensitive communications.
-> TLS protects a connection; it does not protect every copy.
-> HTTPS is HTTP protected by TLS, not a separate cipher.
-> Certificate validation helps authenticate the server endpoint.
-> Email encryption depends on keys and recipient configuration.
-> Unexpected urgency, links, or files can signal phishing.
-> Verify unusual payment requests on a separate known channel.
-> Report suspicious messages through approved response channels.
o Data minimization and change control
-> Collect only data needed for a defined business purpose.
-> Less stored data reduces exposure after unauthorized access.
-> Classify data; follow access, retention, and disposal rules.
-> Share only necessary fields with authorized recipients.
-> Masking replaces or removes fields, reducing analytic utility.
-> Masked data can still identify via other attributes.
-> Tokens substitute values; secure any identity mapping.
-> Change requests need recording and security impact review.
-> Test and approve changes before deployment; then verify them.
-> Archive prior baselines for traceability and rollback.
Sources, practice, lab and scope notes

Objectives

  • CS-SOM-01
  • CS-SOM-02
  • CS-SOM-05
  • CS-SOM-06

Sources

  • NIST SP 800-34 Rev. 1 Contingency Planning Guide — fetched; Read Executive Summary and Ch. 1-2 (PDF pp. 13-26): plan distinctions, contingency process, BCP/DRP, resilience. Also inspected Ch. 3 TOC; detailed RTO/RPO passages not separately retrieved.
  • NIST SP 800-41 Rev. 1 Firewall Guidelines — fetched; Read PDF pp. 1-18: firewall policy, packet filtering, stateful inspection, application firewalls, proxy and WAF overview; allowed traffic, specific rules, testing and management.
  • NIST SP 800-128 Security-Focused Configuration Management — fetched; Read PDF pp. 48-53, Sec. 3.3: access restrictions, requested/evaluated/tested/approved changes, verify deployment, emergency change, impact analysis, retain old baseline for rollback.
  • NIST SP 800-63B-4 Authentication and Authenticator Management — fetched; Read normative password and authenticator requirements, Sec. 3.1.1 and AAL summary: 15-character single-factor and 8-character MFA-only minimums, blocklist, composition, manager, rate limiting.
  • RFC 8446 TLS 1.3 — fetched; Read Sections 1-2: secure-channel goals, handshake negotiation and authentication, record protection, and weaker replay/forward-secrecy properties of 0-RTT.
  • RFC 4251 SSH Protocol Architecture — fetched; Read Sections 1, 4.1, 4.4 and 9: SSH transport properties, host-key verification, client authentication, and configuration policy.
  • RFC 5280 X.509 Certificate and CRL Profile — fetched; Read Sections 3.1-3.3: CA-signed key-to-subject binding, certification paths, trust, CRLs and revocation limits.
  • NIST SP 1800-16 TLS Server Certificate Management — fetched; Read certificate background and issuance process: server identity, key-pair CSR, RA review, CA issuance, chain validation, expiry, private-key risks.
  • NIST SP 800-94 IDPS Guide — fetched; Read Executive Summary and Ch. 2: IDS/IPS purposes and signature, anomaly, and stateful protocol detection methodologies. Document dates from 2007; platform-neutral concepts only.
  • NIST SP 800-115 Technical Guide to Security Testing — fetched; Read Executive Summary, Ch. 1-2, and targeted Ch. 5-7 passages: assessment planning, risk, scope, execution/data handling, pen-test phases/logistics, reporting, and ROE appendix identified in TOC.
  • NIST CSRC Glossary: Masking — fetched; Read definition: removing/replacing a field in a way that does not preserve analytic utility; examples include asterisks or random pseudonyms.
  • NIST SP 800-188 De-Identifying Government Datasets — fetched; Read summary of de-identification goals, risk evaluation, removing identifiers, transforming quasi-identifiers, synthetic data, and warning that simple masking may not suffice.
  • CISA et al. Phishing Guidance: Phase One — fetched; Read pp. 3-12: phishing definitions, email/link/attachment lures, filtering, least privilege, patching, training, incident response, and reporting.
  • CISA Use Strong Passwords — fetched; Read guidance on unique passwords, password managers, long/random passwords, and MFA.
  • NIST SP 800-53 Rev. 5 Controls Catalog — fetched; Read publication overview and control families. Catalog scope supports governance context; no individual control text claimed.
  • SplashKit Steganography Guide — fetched; Read guide explaining carrier media and image LSB embedding; explicitly distinguishes hiding message existence from encryption and says combine with encryption for sensitive content.
  • CISA Securing Wireless Networks — recommended; Not fetched; no claim depends on this route.
  • FBLA 2026-27 Cybersecurity objectives inventory — recommended; Local objective inventory read; official PDF not fetched in this pass. Establishes assigned objective scope only, not technical evidence.

Practice (answers below)

1. A restore finishes in 9 hours with a 6-hour RTO. What follows?

The restore test missed the recovery-time target. Identify bottlenecks and dependencies, assign improvement work, then retest; successful backup completion alone does not establish recovery capability.

2. Why verify recipients even when email uses encryption?

Encryption can protect a channel or message contents, but it cannot prevent disclosure to an incorrectly selected recipient or remove unnecessary data already sent.

Fictional incident and change tabletop

  1. Use only imaginary service, account, and network details.
  2. Sort a suspicious email into verify, report, or safely discard.
  3. Review a sample change request and a short configuration diff.
  4. Map one allowed web-to-data flow and one blocked public flow.
  5. Read a fictional pen-test scope and judge an out-of-scope finding.

Expected: Learner does not open the suspicious file and reports it. Change request includes impact review, approval, test, and rollback. ACL allows only the necessary application flow. Testing stops at the scope boundary and owner is notified.

Limitations: NIST SP 800-94 is a 2007 guide; detection mechanisms are taught conceptually, not as current product recommendations. Tokenization mechanism is summarized at concept level; no dedicated standard on token-vault architecture was fetched. WPA2 is identified as a secure protocol in the current objective list; the NIST wireless guide retrieved is marked technologically outdated, so no detailed WPA2 configuration advice is given. NIST SP 800-34 introductory chapters were read, but detailed numeric RTO/RPO guidance was not independently fetched; notes give conceptual definitions, not mandated values. FBLA official guideline PDF was not fetched in this pass; objective scope comes from the local 2026-27 inventory.

Firewall Types and Least-Privilege ACLs

Security Operations and Management

Download plain · Download colored

Firewall Types and Least-Privilege ACLs

Page 1 · Lines 1–24

o Overview
-> Firewall inspection models
-> NGFW, WAF, and limits
o Firewall inspection models
-> A firewall controls flows across different security postures.
-> Network firewall filters traffic crossing network boundaries.
-> Host firewall filters traffic to and from its endpoint.
-> Stateless filter checks each packet without session tracking.
-> Fields include addresses, protocol, ports, and direction.
-> Stateful inspection tracks flows in a connection state table.
-> Stateful filters compare packets with expected session state.
-> Return traffic may pass when linked to an allowed session.
-> State tracking does not inspect all application meaning.
o NGFW, WAF, and limits
-> Application firewall inspects protocol content and behavior.
-> NGFW commonly combines network controls and added inspection.
-> NGFW capabilities differ across vendors and configurations.
-> WAF focuses on HTTP requests to web applications.
-> WAF can filter web-specific inputs and request patterns.
-> WAF supplements; it does not replace network firewalls.
-> Encrypted traffic can limit inspection without termination.
-> NAT translates addresses; translation alone is not a firewall.
-> Firewalls cannot stop every attack or internal misuse.
-> Use endpoint, identity, and monitoring controls in depth.

Firewall Types and Least-Privilege ACLs

Page 2 · Lines 25–48

o Overview
-> ACL rules and least privilege
-> Segmentation, tests, and operation
o ACL rules and least privilege
-> ACL is an ordered set of permit and deny conditions.
-> Rules match source, destination, protocol, port, direction.
-> Permit only traffic required by documented business need.
-> Narrow addresses and services rather than broad any-any rules.
-> Rule order matters when the first matching rule decides.
-> Default-deny blocks traffic not explicitly permitted.
-> Apply policy to both inbound and outbound flows.
-> Use logs and alerts to observe rule effects and threats.
-> Review stale rules and exceptions through change control.
o Segmentation, tests, and operation
-> Separate public web, application, and data trust zones.
-> Allow web tier to reach only required database service.
-> Block direct public access to internal database systems.
-> Restrict administration to approved hosts and accounts.
-> Test permitted flows and expected denials before rollout.
-> Deploy changes in stages and monitor service impact.
-> Rollback plan reduces outage risk from incorrect rules.
-> Broad rules permit excess access and lateral movement.
-> Overly strict rules can block legitimate business traffic.
-> Review rules periodically and after topology changes.
Sources, practice, lab and scope notes

Objectives

  • CS-SOM-03
  • CS-SOM-04

Sources

  • NIST SP 800-34 Rev. 1 Contingency Planning Guide — fetched; Read Executive Summary and Ch. 1-2 (PDF pp. 13-26): plan distinctions, contingency process, BCP/DRP, resilience. Also inspected Ch. 3 TOC; detailed RTO/RPO passages not separately retrieved.
  • NIST SP 800-41 Rev. 1 Firewall Guidelines — fetched; Read PDF pp. 1-18: firewall policy, packet filtering, stateful inspection, application firewalls, proxy and WAF overview; allowed traffic, specific rules, testing and management.
  • NIST SP 800-128 Security-Focused Configuration Management — fetched; Read PDF pp. 48-53, Sec. 3.3: access restrictions, requested/evaluated/tested/approved changes, verify deployment, emergency change, impact analysis, retain old baseline for rollback.
  • NIST SP 800-63B-4 Authentication and Authenticator Management — fetched; Read normative password and authenticator requirements, Sec. 3.1.1 and AAL summary: 15-character single-factor and 8-character MFA-only minimums, blocklist, composition, manager, rate limiting.
  • RFC 8446 TLS 1.3 — fetched; Read Sections 1-2: secure-channel goals, handshake negotiation and authentication, record protection, and weaker replay/forward-secrecy properties of 0-RTT.
  • RFC 4251 SSH Protocol Architecture — fetched; Read Sections 1, 4.1, 4.4 and 9: SSH transport properties, host-key verification, client authentication, and configuration policy.
  • RFC 5280 X.509 Certificate and CRL Profile — fetched; Read Sections 3.1-3.3: CA-signed key-to-subject binding, certification paths, trust, CRLs and revocation limits.
  • NIST SP 1800-16 TLS Server Certificate Management — fetched; Read certificate background and issuance process: server identity, key-pair CSR, RA review, CA issuance, chain validation, expiry, private-key risks.
  • NIST SP 800-94 IDPS Guide — fetched; Read Executive Summary and Ch. 2: IDS/IPS purposes and signature, anomaly, and stateful protocol detection methodologies. Document dates from 2007; platform-neutral concepts only.
  • NIST SP 800-115 Technical Guide to Security Testing — fetched; Read Executive Summary, Ch. 1-2, and targeted Ch. 5-7 passages: assessment planning, risk, scope, execution/data handling, pen-test phases/logistics, reporting, and ROE appendix identified in TOC.
  • NIST CSRC Glossary: Masking — fetched; Read definition: removing/replacing a field in a way that does not preserve analytic utility; examples include asterisks or random pseudonyms.
  • NIST SP 800-188 De-Identifying Government Datasets — fetched; Read summary of de-identification goals, risk evaluation, removing identifiers, transforming quasi-identifiers, synthetic data, and warning that simple masking may not suffice.
  • CISA et al. Phishing Guidance: Phase One — fetched; Read pp. 3-12: phishing definitions, email/link/attachment lures, filtering, least privilege, patching, training, incident response, and reporting.
  • CISA Use Strong Passwords — fetched; Read guidance on unique passwords, password managers, long/random passwords, and MFA.
  • NIST SP 800-53 Rev. 5 Controls Catalog — fetched; Read publication overview and control families. Catalog scope supports governance context; no individual control text claimed.
  • SplashKit Steganography Guide — fetched; Read guide explaining carrier media and image LSB embedding; explicitly distinguishes hiding message existence from encryption and says combine with encryption for sensitive content.
  • CISA Securing Wireless Networks — recommended; Not fetched; no claim depends on this route.
  • FBLA 2026-27 Cybersecurity objectives inventory — recommended; Local objective inventory read; official PDF not fetched in this pass. Establishes assigned objective scope only, not technical evidence.

Practice (answers below)

1. A database needs web-tier access only. What rule is narrow?

Permit the web-tier source to the required database service, and deny other routes under policy. This follows least privilege and avoids public any-to-any exposure.

2. How do stateless and stateful inspection differ?

Stateless filtering evaluates each packet's fields without tracking a flow; stateful inspection keeps connection state and checks packets against it. Stateful behavior has resource and routing assumptions.

Fictional incident and change tabletop

  1. Use only imaginary service, account, and network details.
  2. Sort a suspicious email into verify, report, or safely discard.
  3. Review a sample change request and a short configuration diff.
  4. Map one allowed web-to-data flow and one blocked public flow.
  5. Read a fictional pen-test scope and judge an out-of-scope finding.

Expected: Learner does not open the suspicious file and reports it. Change request includes impact review, approval, test, and rollback. ACL allows only the necessary application flow. Testing stops at the scope boundary and owner is notified.

Limitations: NIST SP 800-94 is a 2007 guide; detection mechanisms are taught conceptually, not as current product recommendations. Tokenization mechanism is summarized at concept level; no dedicated standard on token-vault architecture was fetched. WPA2 is identified as a secure protocol in the current objective list; the NIST wireless guide retrieved is marked technologically outdated, so no detailed WPA2 configuration advice is given. NIST SP 800-34 introductory chapters were read, but detailed numeric RTO/RPO guidance was not independently fetched; notes give conceptual definitions, not mandated values. FBLA official guideline PDF was not fetched in this pass; objective scope comes from the local 2026-27 inventory.

Secure Protocols, Detection, and Data Methods

Security Protocols and Threat Mitigation

Download plain · Download colored

Secure Protocols, Detection, and Data Methods

Page 1 · Lines 1–24

o Overview
-> SSH, HTTPS, TLS, and WPA2
-> Certificates and trust
o SSH, HTTPS, TLS, and WPA2
-> SSH supports secure remote login over an insecure network.
-> SSH authenticates its server and protects data integrity.
-> Verify SSH host keys to detect server impersonation.
-> HTTPS is HTTP over TLS; TLS is the security protocol.
-> TLS handshake negotiates keys and protocol parameters.
-> TLS server identity is checked against its certificate.
-> TLS record layer protects application data in transit.
-> WPA2 protects a wireless link; use secure configuration.
-> Secure protocol use does not secure a compromised endpoint.
o Certificates and trust
-> Certificate binds a public key to a named subject.
-> A trusted CA signs the binding under its issuance policy.
-> A chain links the server certificate to a trusted root key.
-> Client validates signatures, name, validity, and intended use.
-> Trust depends on local trust anchors and validation policy.
-> A certificate does not guarantee benign site content.
-> CA issues certificate after request and identity checks.
-> Keep the matching private key secret and access restricted.
-> Track expiry; expired certificates may break service.
-> CRLs list revoked certificates; updates introduce time lag.

Secure Protocols, Detection, and Data Methods

Page 2 · Lines 25–48

o Overview
-> IDS and IPS mechanisms
-> Malware, phishing, and data transformation
o IDS and IPS mechanisms
-> IDS monitors events and analyzes them for possible incidents.
-> IPS detects and attempts to stop possible incidents.
-> An IPS can block traffic or change a security control.
-> Signature detection compares events with known patterns.
-> Anomaly detection compares activity with expected behavior.
-> Stateful analysis checks protocol activity against profiles.
-> False positives report benign events as suspicious.
-> False negatives fail to detect a real incident.
-> Tune detections and validate alerts using event context.
o Malware, phishing, and data transformation
-> Filter risky links and attachments at email gateways.
-> Least privilege limits malware damage after execution.
-> Check unexpected sender, destination, and request context.
-> Report suspicious email; avoid opening unexpected attachments.
-> Tokenization substitutes a token for a sensitive value.
-> Token mapping, if retained, needs separate access protection.
-> Masking removes or replaces fields and can lose analytic use.
-> Steganography conceals a message within a carrier medium.
-> Steganography hides presence; it is not encryption.
-> Obfuscation is not encryption; each method has limits.
Sources, practice, lab and scope notes

Objectives

  • CS-SPM-01
  • CS-SPM-06
  • CS-SPM-02
  • CS-SPM-03
  • CS-SPM-04

Sources

  • NIST SP 800-34 Rev. 1 Contingency Planning Guide — fetched; Read Executive Summary and Ch. 1-2 (PDF pp. 13-26): plan distinctions, contingency process, BCP/DRP, resilience. Also inspected Ch. 3 TOC; detailed RTO/RPO passages not separately retrieved.
  • NIST SP 800-41 Rev. 1 Firewall Guidelines — fetched; Read PDF pp. 1-18: firewall policy, packet filtering, stateful inspection, application firewalls, proxy and WAF overview; allowed traffic, specific rules, testing and management.
  • NIST SP 800-128 Security-Focused Configuration Management — fetched; Read PDF pp. 48-53, Sec. 3.3: access restrictions, requested/evaluated/tested/approved changes, verify deployment, emergency change, impact analysis, retain old baseline for rollback.
  • NIST SP 800-63B-4 Authentication and Authenticator Management — fetched; Read normative password and authenticator requirements, Sec. 3.1.1 and AAL summary: 15-character single-factor and 8-character MFA-only minimums, blocklist, composition, manager, rate limiting.
  • RFC 8446 TLS 1.3 — fetched; Read Sections 1-2: secure-channel goals, handshake negotiation and authentication, record protection, and weaker replay/forward-secrecy properties of 0-RTT.
  • RFC 4251 SSH Protocol Architecture — fetched; Read Sections 1, 4.1, 4.4 and 9: SSH transport properties, host-key verification, client authentication, and configuration policy.
  • RFC 5280 X.509 Certificate and CRL Profile — fetched; Read Sections 3.1-3.3: CA-signed key-to-subject binding, certification paths, trust, CRLs and revocation limits.
  • NIST SP 1800-16 TLS Server Certificate Management — fetched; Read certificate background and issuance process: server identity, key-pair CSR, RA review, CA issuance, chain validation, expiry, private-key risks.
  • NIST SP 800-94 IDPS Guide — fetched; Read Executive Summary and Ch. 2: IDS/IPS purposes and signature, anomaly, and stateful protocol detection methodologies. Document dates from 2007; platform-neutral concepts only.
  • NIST SP 800-115 Technical Guide to Security Testing — fetched; Read Executive Summary, Ch. 1-2, and targeted Ch. 5-7 passages: assessment planning, risk, scope, execution/data handling, pen-test phases/logistics, reporting, and ROE appendix identified in TOC.
  • NIST CSRC Glossary: Masking — fetched; Read definition: removing/replacing a field in a way that does not preserve analytic utility; examples include asterisks or random pseudonyms.
  • NIST SP 800-188 De-Identifying Government Datasets — fetched; Read summary of de-identification goals, risk evaluation, removing identifiers, transforming quasi-identifiers, synthetic data, and warning that simple masking may not suffice.
  • CISA et al. Phishing Guidance: Phase One — fetched; Read pp. 3-12: phishing definitions, email/link/attachment lures, filtering, least privilege, patching, training, incident response, and reporting.
  • CISA Use Strong Passwords — fetched; Read guidance on unique passwords, password managers, long/random passwords, and MFA.
  • NIST SP 800-53 Rev. 5 Controls Catalog — fetched; Read publication overview and control families. Catalog scope supports governance context; no individual control text claimed.
  • SplashKit Steganography Guide — fetched; Read guide explaining carrier media and image LSB embedding; explicitly distinguishes hiding message existence from encryption and says combine with encryption for sensitive content.
  • CISA Securing Wireless Networks — recommended; Not fetched; no claim depends on this route.
  • FBLA 2026-27 Cybersecurity objectives inventory — recommended; Local objective inventory read; official PDF not fetched in this pass. Establishes assigned objective scope only, not technical evidence.

Practice (answers below)

1. A TLS certificate is valid. Does that prove a site is safe?

No. Validation helps authenticate a server name and public key through a trust chain, but it does not certify that the site's content or actions are harmless.

2. An IPS blocks an unusual but valid request. What issue may exist?

It may be a false positive or unsuitable rule. Review the event and detection context, tune controls carefully, and assess service impact before changing prevention policy.

Fictional incident and change tabletop

  1. Use only imaginary service, account, and network details.
  2. Sort a suspicious email into verify, report, or safely discard.
  3. Review a sample change request and a short configuration diff.
  4. Map one allowed web-to-data flow and one blocked public flow.
  5. Read a fictional pen-test scope and judge an out-of-scope finding.

Expected: Learner does not open the suspicious file and reports it. Change request includes impact review, approval, test, and rollback. ACL allows only the necessary application flow. Testing stops at the scope boundary and owner is notified.

Limitations: NIST SP 800-94 is a 2007 guide; detection mechanisms are taught conceptually, not as current product recommendations. Tokenization mechanism is summarized at concept level; no dedicated standard on token-vault architecture was fetched. WPA2 is identified as a secure protocol in the current objective list; the NIST wireless guide retrieved is marked technologically outdated, so no detailed WPA2 configuration advice is given. NIST SP 800-34 introductory chapters were read, but detailed numeric RTO/RPO guidance was not independently fetched; notes give conceptual definitions, not mandated values. FBLA official guideline PDF was not fetched in this pass; objective scope comes from the local 2026-27 inventory.

Password Security, Patching, and Authorized Testing

Security Protocols and Threat Mitigation

Download plain · Download colored

Password Security, Patching, and Authorized Testing

Page 1 · Lines 1–24

o Overview
-> Current password requirements
-> Password use and protection
o Current password requirements
-> NIST minimum is 15 characters for single-factor passwords.
-> MFA-only password minimum is 8 characters under NIST.
-> Use the correct context; 15 is not universal to MFA.
-> NIST rejects extra composition rules for these passwords.
-> Block commonly used, expected, and compromised passwords.
-> Allow password managers, autofill, and paste functionality.
-> Rate limiting helps reduce online guessing attempts.
-> Do not require arbitrary periodic changes absent compromise.
-> Change passwords promptly when compromise evidence exists.
o Password use and protection
-> Use a unique password for each account or service.
-> Long unique secrets reduce reuse and guessing risks.
-> A manager can generate and store distinct passwords.
-> MFA adds a separate factor beyond the password.
-> Password plus another password is not two factor types.
-> Passwords alone are not phishing-resistant authentication.
-> NIST recommends blocklisting weak or breached candidates.
-> Verifiers hash passwords with salt and high work factor.
-> A salt is not secret; it prevents identical hash reuse.
-> Account recovery needs protection too.

Password Security, Patching, and Authorized Testing

Page 2 · Lines 25–48

o Overview
-> Patches and secure change
-> Version control and pen testing
o Patches and secure change
-> Updates repair flaws and may change software behavior.
-> Inventory systems to identify exposed, affected versions.
-> Prioritize patches by risk, exposure, and business impact.
-> Obtain updates through authenticated vendor distribution.
-> Test security and function before production deployment.
-> Approve changes after security-impact assessment and testing.
-> Verify deployment and update affected system documentation.
-> Emergency changes still need later documented review.
-> Patch firewall software to address vendor security flaws.
o Version control and pen testing
-> Version control tracks change history and prior baselines.
-> Review diffs to find unexpected or unsafe configuration edits.
-> Keep passwords, tokens, keys, and private data out of commits.
-> Retain prior known-good versions for tested rollback.
-> Pen testing validates weaknesses under agreed conditions.
-> Obtain explicit written authorization before any testing.
-> Scope lists targets, exclusions, dates, and permitted methods.
-> Rules of engagement set contacts and stop conditions.
-> Protect evidence; report findings for remediation and retest.
-> Out-of-scope discovery means stop and contact the owner.
Sources, practice, lab and scope notes

Objectives

  • CS-SPM-05
  • CS-SPM-07
  • CS-SPM-08

Sources

  • NIST SP 800-34 Rev. 1 Contingency Planning Guide — fetched; Read Executive Summary and Ch. 1-2 (PDF pp. 13-26): plan distinctions, contingency process, BCP/DRP, resilience. Also inspected Ch. 3 TOC; detailed RTO/RPO passages not separately retrieved.
  • NIST SP 800-41 Rev. 1 Firewall Guidelines — fetched; Read PDF pp. 1-18: firewall policy, packet filtering, stateful inspection, application firewalls, proxy and WAF overview; allowed traffic, specific rules, testing and management.
  • NIST SP 800-128 Security-Focused Configuration Management — fetched; Read PDF pp. 48-53, Sec. 3.3: access restrictions, requested/evaluated/tested/approved changes, verify deployment, emergency change, impact analysis, retain old baseline for rollback.
  • NIST SP 800-63B-4 Authentication and Authenticator Management — fetched; Read normative password and authenticator requirements, Sec. 3.1.1 and AAL summary: 15-character single-factor and 8-character MFA-only minimums, blocklist, composition, manager, rate limiting.
  • RFC 8446 TLS 1.3 — fetched; Read Sections 1-2: secure-channel goals, handshake negotiation and authentication, record protection, and weaker replay/forward-secrecy properties of 0-RTT.
  • RFC 4251 SSH Protocol Architecture — fetched; Read Sections 1, 4.1, 4.4 and 9: SSH transport properties, host-key verification, client authentication, and configuration policy.
  • RFC 5280 X.509 Certificate and CRL Profile — fetched; Read Sections 3.1-3.3: CA-signed key-to-subject binding, certification paths, trust, CRLs and revocation limits.
  • NIST SP 1800-16 TLS Server Certificate Management — fetched; Read certificate background and issuance process: server identity, key-pair CSR, RA review, CA issuance, chain validation, expiry, private-key risks.
  • NIST SP 800-94 IDPS Guide — fetched; Read Executive Summary and Ch. 2: IDS/IPS purposes and signature, anomaly, and stateful protocol detection methodologies. Document dates from 2007; platform-neutral concepts only.
  • NIST SP 800-115 Technical Guide to Security Testing — fetched; Read Executive Summary, Ch. 1-2, and targeted Ch. 5-7 passages: assessment planning, risk, scope, execution/data handling, pen-test phases/logistics, reporting, and ROE appendix identified in TOC.
  • NIST CSRC Glossary: Masking — fetched; Read definition: removing/replacing a field in a way that does not preserve analytic utility; examples include asterisks or random pseudonyms.
  • NIST SP 800-188 De-Identifying Government Datasets — fetched; Read summary of de-identification goals, risk evaluation, removing identifiers, transforming quasi-identifiers, synthetic data, and warning that simple masking may not suffice.
  • CISA et al. Phishing Guidance: Phase One — fetched; Read pp. 3-12: phishing definitions, email/link/attachment lures, filtering, least privilege, patching, training, incident response, and reporting.
  • CISA Use Strong Passwords — fetched; Read guidance on unique passwords, password managers, long/random passwords, and MFA.
  • NIST SP 800-53 Rev. 5 Controls Catalog — fetched; Read publication overview and control families. Catalog scope supports governance context; no individual control text claimed.
  • SplashKit Steganography Guide — fetched; Read guide explaining carrier media and image LSB embedding; explicitly distinguishes hiding message existence from encryption and says combine with encryption for sensitive content.
  • CISA Securing Wireless Networks — recommended; Not fetched; no claim depends on this route.
  • FBLA 2026-27 Cybersecurity objectives inventory — recommended; Local objective inventory read; official PDF not fetched in this pass. Establishes assigned objective scope only, not technical evidence.

Practice (answers below)

1. Which password minimum applies: single factor or MFA-only?

NIST SP 800-63B-4 sets 15 characters for single-factor use and 8 when used only as part of MFA. Identify the context before selecting the minimum; do not apply one value to both.

2. A tester sees an admin host outside written scope. What next?

Stop activity on that host and notify the named contact under the rules of engagement. Authorization is limited to the documented scope; curiosity does not extend permission.

Fictional incident and change tabletop

  1. Use only imaginary service, account, and network details.
  2. Sort a suspicious email into verify, report, or safely discard.
  3. Review a sample change request and a short configuration diff.
  4. Map one allowed web-to-data flow and one blocked public flow.
  5. Read a fictional pen-test scope and judge an out-of-scope finding.

Expected: Learner does not open the suspicious file and reports it. Change request includes impact review, approval, test, and rollback. ACL allows only the necessary application flow. Testing stops at the scope boundary and owner is notified.

Limitations: NIST SP 800-94 is a 2007 guide; detection mechanisms are taught conceptually, not as current product recommendations. Tokenization mechanism is summarized at concept level; no dedicated standard on token-vault architecture was fetched. WPA2 is identified as a secure protocol in the current objective list; the NIST wireless guide retrieved is marked technologically outdated, so no detailed WPA2 configuration advice is given. NIST SP 800-34 introductory chapters were read, but detailed numeric RTO/RPO guidance was not independently fetched; notes give conceptual definitions, not mandated values. FBLA official guideline PDF was not fetched in this pass; objective scope comes from the local 2026-27 inventory.