Security+ Certification Prep

Two exams on one page

On 7 November 2023, CompTIA launched SY0-701, the seventh version of its Security+ exam. When this lesson was written, on 27 October 2026, CompTIA's Security+ page showed it beside a successor: Security+ V8, exam code SY0-801, which CompTIA expects to launch on or around 17 November 2026. The older exam does not disappear that day. CompTIA lists 11 June 2027 as the retirement date for SY0-701 in English, and 13 August 2027 for its Japanese, Portuguese, Spanish and Thai editions.

So for about seven months two exams are on sale, and passing either one earns the same credential, CompTIA Security+. Your first decision as a candidate is which one to prepare for, and the answer depends on a date you have not chosen yet: the day you sit the exam.

This course follows SY0-801. It has thirty-six lessons, each with a lab and a quiz. At five to seven hours a week, most people need three or four months to finish it, which puts the finish line after SY0-801 launches. Anyone who finishes after 11 June 2027 has no choice at all, because SY0-701 will be gone in English. If you must test before 17 November 2026, only SY0-701 exists, and the crosswalk later in this lesson shows where every one of its objectives is taught here. Whichever you book, check CompTIA's exam page on the day you book: a date described as "on or around" can move.

Exam objectives: this lesson is orientation. It teaches no single objective. Instead it maps all twenty-six SY0-801 objectives, and all twenty-eight SY0-701 objectives, onto the lessons that teach them.

Key idea: pick the exam version by your test date. Before 17 November 2026 it can only be SY0-701; after 11 June 2027 (in English) it can only be SY0-801; in between you may choose, and this course is built for SY0-801.

What the exam looks like

Both versions share a format. The table sets them side by side, using the figures CompTIA published on its V7 and V8 pages and in the two objectives documents.

Two features of that table trip people up. The first is the score. Neither objectives document converts questions answered into scale points. CompTIA gives the pass mark only as 750 on a scale that runs from 100 to 900, so you cannot read it as "75 percent correct." Aim to know the material well, not to hit a guessed percentage.

The second is time. Ninety minutes for up to ninety questions sounds like a minute each, but the questions are not all the same size. A multiple-choice item may take thirty seconds. A simulation with a rule table to fix or a log to read takes several minutes. Lesson 36 is a full rehearsal of pacing; for now, notice that speed on the short items buys time for the long ones.

The point: the pass mark is a scaled 750, not a percentage, and the clock is shared between quick items and slow simulations.

Performance-based questions are simulations

CompTIA's explainer on performance-based questions (PBQs) describes two kinds. Simulations imitate a tool or environment, such as a firewall, a network diagram, a terminal window or an operating system. They have limited functions, but they accept more than one correct path. Virtual environments are real virtual machines running real software. CompTIA lists Security+ among the exams that use simulations only.

That classification has three practical consequences, all stated in CompTIA's explainer:

• A simulation has a reset button that returns it to its starting state if you make a mess of it.
• You can skip a simulation and come back later, and the work you did is saved. Virtual PBQs, which Security+ does not use, must be finished when you meet them.
• Partial credit may be given, so a simulation you can half solve is worth attempting rather than abandoning.

A reasonable plan follows from those rules. When a simulation appears and you cannot see the way in, skip it, bank the multiple-choice questions, and return with the time you have saved. Throughout this course the labs train the same skills the simulations test: reading a rule table, reading a log, matching a control to a threat, and putting the steps of a process in order.

What matters here: Security+ PBQs are simulations, which you can reset, skip and revisit, and which can earn partial credit.

Five domains, twenty-six objectives

CompTIA organizes each exam into domains, broad areas weighted by their share of the exam. Each domain holds numbered objectives, and each objective lists examples of the terms and tasks it covers. The SY0-801 domains, their weights, and the SY0-701 weights for comparison, are below, with the lessons that teach each.

Security Operations is the heaviest domain in both versions, at just over a quarter of the exam. Program management shrank the most, from 20 to 14 percent, while General Security Concepts grew from 12 to 16. On SY0-701 the second domain was called Threats, Vulnerabilities, and Mitigations; SY0-801 renamed it Threats, Vulnerabilities, and Attacks and moved the mitigations into Security Operations objective 4.1.

Reading both documents side by side shows what else moved. These are the changes most likely to matter to your study:

• Artificial intelligence arrives. A new objective, 2.6, covers threats to and from AI systems, such as prompt injection, poisoning and hallucinations. Objective 2.4 lists large language models as an attack surface, and objective 4.6 adds AI capabilities to automation.
• Concepts and controls merged. SY0-701 split controls (1.1) from fundamental concepts (1.2); SY0-801 joins them in 1.1, so change management becomes 1.2 and cryptography 1.3.
• CVE and CVSS moved from vulnerability management into 2.1, beside threat intelligence. Recovery metrics such as RTO and RPO moved from risk management into resilience, 3.4.
• New terms appear across the domains, among them Security Service Edge, group managed service accounts, privilege creep, quishing, deepfakes, canary accounts, secrets scanning, BIMI, passkeys, emergency access accounts, ransom negotiation and log-parsing techniques.

Why this matters: weights tell you where the marks are, and the changes tell you which older study materials no longer match the exam you will sit.

Reading an objective like a contract

Each objective begins with a verb, and the verb tells you what kind of knowing is expected. Some begin "Explain," "Summarize" or "Describe": you must know what a thing is and why it matters. Nine SY0-801 objectives begin "Given a scenario," followed by verbs such as apply, analyze, manage, perform or use. Those are 1.2, 2.5, 3.2, 4.1, 4.3, 4.5, 4.6, 4.8 and 5.6. For them, definitions are not enough. Expect a described situation and a question about the best action, the first step, or the most likely cause.

Two more lines in the objectives document deserve your attention. CompTIA says its bulleted lists are examples rather than complete lists, so other technologies and tasks related to an objective can appear on the exam. And it publishes an acronym list it encourages candidates to know. Treat the bullets as a floor, not a fence. This course teaches each listed item and the neighbors a working administrator would also be expected to know.

In short: the verb sets the depth, "Given a scenario" means practice deciding rather than defining, and the bullets are examples, not limits.

If you are sitting SY0-701

Most of SY0-701's content is the same material arranged differently, so this course serves you too. The table maps each SY0-701 objective to the lessons that teach it. Terms that appear only in SY0-701 are taught and flagged where they occur, among them blockchain and the open public ledger, steganography, key stretching, TPMs and HSMs, SD-WAN and SASE, next-generation firewalls, WPA3 and RADIUS, wireless site surveys and heat maps, COPE and CYOD phones, bollards and other physical controls, RFID cloning, birthday and collision attacks, typosquatting, VM escape, and side loading.

Lesson 16, on AI threats, is the one lesson an SY0-701 candidate could skip, and even there the security ideas carry over.

Practical rules before you book

CompTIA delivers its exams at test centers and online through OnVUE, the remote service of its delivery partner Pearson VUE. A few rules from CompTIA's published policies are worth knowing months ahead:

• Identification. At a test center you need two original, unexpired IDs: one government-issued with your name and a recent photo, and a second with at least your name and a signature or photo. Online, you need a valid government-issued photo ID whose name matches your registration exactly.
• Online sessions. OnVUE watches you by webcam and microphone, wants a clear desk and a single display, and does not permit breaks unless an accommodation was approved in advance.
• Candidates under 18. Since 23 June 2026, CompTIA requires parental consent through its CompTIA Central account before a minor registers.
• Retakes. There is no waiting period between a first and second attempt. Before a third or later attempt you must wait at least fourteen calendar days.
• Renewal. Security+ is valid for three years from the date you certify, and you can renew it through CompTIA's continuing education program without retaking the exam.
• Price. CompTIA's exam pages showed no price when this lesson was checked, and prices vary by country, so this course states none. Check CompTIA's store for yours.

One more policy is ethical rather than practical. The objectives document says CompTIA does not condone "brain dumps," sites that sell real exam questions, and that candidates who use them will have their certifications revoked and be suspended from future testing. Every question in this course was written for the course. None comes from the exam.

CompTIA and Security+ are trademarks of CompTIA. CompTIA does not endorse or sponsor this course, and no course can honestly promise that you will pass. What a course can do is teach the material properly and give you practice of the right kind.

How to study with this course

Two habits have unusually strong evidence behind them. In a 2013 review of ten study techniques, Dunlosky and colleagues rated practice testing and distributed practice (spreading study over time) as high utility. They rated highlighting and summarization as low. The course is built around the high-utility pair. Every lesson ends with ten scenario questions, and each explanation says why the right answer is right.

Use them as practice, not as a score. Take the quiz the day you finish a lesson, then take it again a week later before you look at the explanations. Note which objective each missed question belongs to. Keep the tracker you build in this lesson's lab, and let the misses, not the lesson order, decide what you review. Expect the second attempt to feel harder than the first; that effort is the learning.

Remember: recall beats rereading. Quiz yourself, space the repeats, and steer your review by the objectives you miss.

Your first lab: proving a download is genuine

Every lab in this course runs on equipment you own, and the next lesson builds a virtual lab machine from an operating system image you download. Before you trust that image, you will check it. That check introduces two ideas the exam returns to repeatedly: hashing and signatures.

A hash function turns a file of any size into a short, fixed-length value. Change one character of the file and the value changes completely. Microsoft's documentation for PowerShell's Get-FileHash command says its default algorithm is SHA-256. It also warns that MD5 and SHA-1 are no longer considered secure against deliberate tampering, so they should be used only for simple change checks.

A matching hash proves less than people assume. If an attacker can change the file on a download page, they can often change the hash printed beside it too. Canonical's guide to verifying Ubuntu closes that gap with a second step. Ubuntu publishes a list of hashes called SHA256SUMS together with a signature file, SHA256SUMS.gpg, made with Ubuntu's private key. A good signature shows the list came from the key's owner, so the hashes in it can be trusted. You will meet the mathematics behind that in Lesson 5 and the trust chain behind keys in Lesson 6.

So what?: a hash proves a file has not changed since someone computed it; only a signature proves who that someone was.

Common misconceptions

• "SY0-801 replaces SY0-701 on launch day." CompTIA's dates overlap. SY0-701 remains available in English until 11 June 2027, so for about seven months you may book either.
• "750 means I need 75 percent." The 750 is a point on a 100-900 scale. CompTIA publishes no conversion from questions answered, so a percentage target is a guess.
• "If a term is not in the bullets, it will not be tested." CompTIA states that the bulleted examples are not exhaustive and that related content may appear.
• "A performance-based question is all or nothing." CompTIA says partial credit may be given, and Security+ simulations can be skipped and revisited.
• "A matching hash proves the file is safe." It proves the file matches a published value. Whether that value came from the real publisher is what a signature establishes.

Where this leaves us

• This course follows SY0-801, expected on or around 17 November 2026. SY0-701 retires on 11 June 2027 in English and on 13 August 2027 in other languages, and both lead to Security+.
• Both versions allow up to 90 multiple-choice and performance-based questions in 90 minutes, with a pass mark of 750 on a 100-900 scale.
• Security+ PBQs are simulations that can be reset, skipped and revisited, and that may earn partial credit.
• SY0-801 weights its domains 16, 24, 19, 27 and 14 percent; Security Operations is the largest, and AI threats are new.
• Objective verbs set the depth of knowing, and the bullets are examples, not a complete list.
• Study by retrieval and spacing, steered by the objectives you miss, and verify downloads by signature as well as hash.

Sources

1. CompTIA. (2026). Security+ V8 [Certification page, exam details and domains]. Retrieved October 27, 2026. comptia.org
2. CompTIA. (2026). Security+ V7 [Certification page, exam details and retirement dates]. Retrieved October 27, 2026. comptia.org
3. CompTIA. (2025). CompTIA Security+ SY0-801 V8 certification exam objectives (Document version 2.0). CompTIA (PDF)
4. CompTIA. (2023). CompTIA Security+ SY0-701 certification exam: Exam objectives (Version 6.0). CompTIA (PDF)
5. CompTIA. (n.d.). Performance-based questions explained. comptia.org
6. CompTIA. (n.d.). Candidate ID policy; CompTIA certification retake policy; Online-proctored exam guidelines; Certification renewal policy. comptia.org
7. Canonical. (n.d.). How to verify your Ubuntu download. Ubuntu tutorials. ubuntu.com
8. Microsoft. (2025). Get-FileHash (PowerShell 7.6 reference). Microsoft Learn. learn.microsoft.com
9. Dunlosky, J., Rawson, K. A., Marsh, E. J., Nathan, M. J., and Willingham, D. T. (2013). Improving students' learning with effective learning techniques: Promising directions from cognitive and educational psychology. Psychological Science in the Public Interest, 14(1), 4-58. doi:10.1177/1529100612453266

Two testers, one letter, twenty hours in jail

Shortly after midnight on 11 September 2019, an alarm brought sheriff's deputies to the Dallas County Courthouse in Adel, Iowa. Inside were two employees of Coalfire, a security firm that the Iowa Judicial Branch had hired to test the security of the state's court system. The men showed the deputies a letter of authorization from the Judicial Branch. According to later court filings reported by the Iowa Capital Dispatch, the deputies checked it and told the men they were free to go. Then the county sheriff arrived, and the two testers were arrested.

They were booked and held for about twenty hours on charges of third-degree burglary and possession of burglary tools. The charges were reduced to trespassing and then dropped. The two men sued the county and the former sheriff for false arrest and defamation, and in January 2026, more than six years later, the parties settled for 600,000 dollars.

Here is the puzzle this lesson solves. The testers had a contract. They had a signed letter. They were doing the job they were hired to do. How could that still end in handcuffs? The answer is not that anyone in the story was careless. It is that authorization, the permission that separates a security test from a crime, has more parts than a contract and a signature.

Exam objectives: groundwork for SY0-801 5.3 (rules of engagement), 5.5 (penetration testing) and 4.3 (responsible disclosure and bounty programs), taught in full in Lessons 23, 32 and 34. On SY0-701 the same terms sit under 4.3, 5.3 and 5.5.

Who can say yes

Start with the two positions that were argued in court, as the Iowa Capital Dispatch reported them. Judicial Branch officials said they had not intended to authorize physical break-ins or entry outside normal business hours. The testers' lawsuit said the contract called for physical attacks on buildings, including lock picking. Dallas County argued that the state court administrator had no authority to give permission to enter a courthouse the county owned.

Each position points at a different part of authorization:

• Authority. Permission counts only from someone entitled to give it for that specific asset. A client can authorize testing of what it owns or controls. Whether it could authorize entry to a building someone else owned was exactly the dispute.
• Scope. The written terms must say what is in bounds: which buildings or systems, which techniques, and which hours. If two careful readers can disagree about whether night-time entry was allowed, the scope was not written tightly enough.
• Notification. The people likely to respond to a test, such as police, guards or a security operations center, need either advance notice or a fast way to confirm the test is real.

The point: permission must come from someone with authority over the exact target, describe the exact scope in writing, and be confirmable by the people who will meet you during the test.

What a rules of engagement document holds

The professional answer to the Iowa puzzle is a rules of engagement (ROE) document. NIST Special Publication 800-115, the US government's technical guide to security testing, defines an ROE as the detailed guidelines and constraints for a test. It is agreed before testing starts, and it gives the testers authority to carry out the activities it defines. Appendix B of the guide offers a template. Its main parts are these:

One line in the template reads as if it were written for Adel, Iowa. When physical security is in scope, NIST says the team should carry a form, with signatures and contact information, to show law enforcement or on-site security if they are questioned. A letter is only as good as the phone number on it that someone answers at midnight.

The exclude list deserves a second look. Testers name what they may touch; the exclude list names what they may not, such as a hospital's patient-monitoring network inside an otherwise in-scope range. On the exam, a scenario in which a tester touches a system missing from the scope is a scenario about a breach of the rules of engagement.

In short: an ROE turns permission into a document: who, what, when, where, how, what to do if it goes wrong, and who signed.

The law in the United States

The main US federal statute is the Computer Fraud and Abuse Act (CFAA), 18 U.S.C. 1030. Its best-known section makes it a crime to intentionally access a computer without authorization, or to exceed authorized access, and thereby obtain information from a protected computer. A "protected computer" includes any computer used in or affecting interstate or foreign commerce or communication. The Supreme Court observed in 2021 that this reaches, at a minimum, every computer connected to the internet.

The stakes are real. The Court noted that violations of that section carry penalties from fines and misdemeanor sentences up to ten years in prison. The Act also lets a person who suffers damage or loss sue the violator in a civil case, generally within two years.

What does "exceeds authorized access" mean? In Van Buren v. United States (2021), a police sergeant had used his valid login to look up a license plate for money, against department policy. The Court held, six to three, that the clause covers people who obtain information from areas of a computer, such as files, folders or databases, that are off-limits to them. It does not cover people with improper motives for getting information that is otherwise available to them. The Court called this a "gates-up-or-down" question: either you may enter an area or you may not.

In May 2022 the Department of Justice changed how federal prosecutors use the CFAA. Its Justice Manual now tells them to decline prosecution when the evidence shows the conduct was good-faith security research. That means access solely to test, investigate or correct a security flaw, done in a way designed to avoid harm, with the findings used mainly to improve security. Research done to extort the owners of a system is expressly not good faith. The manual adds that breaking a contract or website terms of service alone generally should not be charged.

Notice the limits. This is guidance for federal prosecutors. It does not rewrite the statute, it cannot stop a company from suing you under the civil provision, and state laws are a separate matter. Physical testing brings in still other laws: the Iowa charges were burglary and trespass, not computer crimes.

What matters here: under the CFAA, authorization is a gate: you are either allowed into an area of a system or you are not. Good intentions may influence a federal prosecutor; they do not create permission.

The law in the United Kingdom

The UK's Computer Misuse Act 1990 has been amended several times, but its structure is easy to hold in your head:

• Section 1 covers unauthorized access to computer material. The offence lies in causing a computer to perform a function with intent to secure access you know is unauthorized, so it does not depend on succeeding.
• Section 2 covers unauthorized access with intent to commit or help commit further offences, such as fraud.
• Section 3 covers unauthorized acts intended to impair a computer's operation, or reckless as to impairing it, such as spreading malware or overwhelming a service.
• Section 3ZA, added in 2015, covers unauthorized acts that cause, or create a significant risk of, serious damage, for example to human welfare or national security.
• Section 3A, added in 2006, covers making, supplying or obtaining articles, which can include software, for use in those offences.

The Act has no specific defense for well-meant security research. When the UK government consulted on changes in 2023, techUK reported, it said that defenses for security professionals needed more work. Laws change, so check the current text on legislation.gov.uk before relying on any summary, including this one. Other countries have their own statutes, and the safe rule travels across every border: test only what you own or have written permission to test.

Why this matters: in both countries the line is permission, not difficulty and not intent. A badly secured system is still someone else's system.

A lab you own

Every hands-on exercise in this course runs in a lab that belongs to you. Its heart is a virtual machine (VM): a complete computer simulated inside your real one by a program called a hypervisor. VirtualBox, a free hypervisor released under the GNU GPL version 3, offers installers for Windows, for macOS on Intel and Apple silicon, and for Linux. If you already use another free hypervisor, such as Hyper-V on Windows, that works too.

A VM gives you two protections that a real computer cannot. The first is isolation. VirtualBox's manual describes several network modes, and choosing the right one decides what your VM can reach:

The second protection is the snapshot: a saved state of the whole VM that you can return to in seconds. Take one after a clean install, and any mistake, misconfiguration or deliberately broken setting is one click from undone.

Inside the VM you will run OWASP Juice Shop, an MIT-licensed web shop that its project calls probably the most modern and sophisticated insecure web application. It is full of deliberate flaws so that people can learn to recognize them legally. Its README gives a Docker command that publishes the shop only on 127.0.0.1, the machine's own loopback address. That detail is a security decision: a deliberately vulnerable application should answer only to the computer it runs on.

Three more rules keep the lab clean. Use invented test accounts and never a password you use anywhere real. If the computer belongs to an employer or a school, get written permission from its owner before installing a hypervisor or security tools. And if you later sign up for an online practice platform, remember that it needs an account and sets its own age rules: read its terms first, with a parent or guardian if you are under 18.

Remember: isolate the lab network, snapshot before you experiment, and bind deliberately vulnerable software to the loopback address.

When you stumble on a flaw

Sooner or later you will notice something wrong in a system that is not yours: a web page that shows another customer's order when a number in its address changes, say. The professional response is short. Stop. Do not change more numbers to see how far it goes, and do not keep any data. Write down what you saw and when. Then report it to the organization.

Many organizations publish how to do that. RFC 9116 defines a file called security.txt, placed at the path /.well-known/security.txt on a website, that must list a contact for reporting vulnerabilities and an expiry date. Others publish a vulnerability disclosure policy or run a bug bounty program, which pays for reports and, crucially, defines a scope in which testing is authorized. Testing inside a program's published scope is permission; testing outside it is not.

Bottom line: finding a flaw by accident is not a crime, but exploring it further without permission can be. Stop, record, report.

Common misconceptions

• "If a system is badly secured, using it is fair game." The CFAA and the Computer Misuse Act turn on authorization, not on how hard entry was. An unlocked door is not an invitation.
• "A signed contract covers whatever I do during the test." It covers what its scope says, and only if the signer had authority over the target. The Iowa case turned on both questions.
• "The DOJ legalized ethical hacking in 2022." It changed federal charging policy for good-faith research. The statute, civil lawsuits and state laws are unchanged.
• "My home network is my lab, so anything on it is fair game." Other people's phones and laptops on your Wi-Fi belong to them, and your router may belong to your provider. Keep tests inside your virtual lab.
• "A bug bounty lets me test the whole company." A bounty program authorizes only the targets and techniques in its published scope.

What you now know

• Authorization has parts: authority over the exact target, a written scope, and a way for responders to confirm the test.
• A rules of engagement document records purpose, scope, people, schedule, site and tools, incident handling, targets and the exclude list, allowed activities, data handling, reporting and signatures.
• The CFAA forbids access without authorization or beyond it; Van Buren read "exceeds authorized access" as a gates-up-or-down test of areas, not motives.
• The 2022 DOJ policy asks federal prosecutors not to charge good-faith security research; it excludes extortion and changes nothing for civil suits or state law.
• The UK Computer Misuse Act covers unauthorized access, access for further offences, impairment, serious damage, and tools for those offences, with no specific research defense.
• Your lab is a VM on an isolated network mode, with snapshots, test-only accounts, and vulnerable software bound to 127.0.0.1.

Sources

1. Iowa Capital Dispatch. (2026, January 22). Iowa lawsuit over courthouse security 'break-in' is headed toward trial. Republished by KCRG. kcrg.com
2. KCRG. (2026, January 30). Cybersecurity testers reach $600,000 settlement after wrongful arrest. kcrg.com
3. Scarfone, K., Souppaya, M., Cody, A., and Orebaugh, A. (2008). Technical guide to information security testing and assessment (NIST SP 800-115), Appendix B, Rules of Engagement Template. National Institute of Standards and Technology. nist.gov (PDF)
4. Computer Fraud and Abuse Act, 18 U.S.C. 1030. Legal Information Institute, Cornell Law School. law.cornell.edu
5. Van Buren v. United States, 593 U.S. 374 (2021), slip opinion No. 19-783, decided June 3, 2021. Supreme Court of the United States. supremecourt.gov (PDF)
6. US Department of Justice. (2022). Justice Manual 9-48.000: Computer Fraud and Abuse Act (charging policy announced May 19, 2022). justice.gov
7. Computer Misuse Act 1990, c. 18 (as amended). The National Archives. legislation.gov.uk
8. techUK. (2023, February 13). Government launches new consultation on the review of the Computer Misuse Act 1990. techuk.org
9. Oracle. (n.d.). Virtual networking (Oracle VirtualBox User Guide). virtualbox.org
10. OWASP Juice Shop project. (n.d.). juice-shop [README and setup instructions]. GitHub. github.com
11. Foudil, E., and Shafranovich, Y. (2022). A file format to aid in security vulnerability disclosure (RFC 9116). RFC Editor. rfc-editor.org

Page five of a ransomware guide

Version 3.0 of CISA's #StopRansomware Guide, published in October 2023, opens its list of best practices with a single instruction: maintain offline, encrypted backups of critical data, and regularly test that they can be restored. Two paragraphs later it asks organizations to create, maintain and regularly exercise a cyber incident response plan. A few pages on it asks for phishing-resistant multifactor authentication on all services, and for application allowlisting or endpoint detection and response on every device.

Each of those recommendations is a security control: a safeguard or countermeasure that protects the confidentiality, integrity or availability of a system and its information. The exam expects you to name every control in two ways. Its category says how it is carried out: by technology, by management decisions, by people following procedures, or by physical barriers. Its type says what it does: stop an incident, discourage it, notice it, repair its damage, stand in for another control, or tell people what to do. A tested backup, for instance, is a corrective control whatever else it is.

This lesson builds both naming systems, lays them side by side, and then uses them to read CISA's guide the way an assessor would.

Exam objectives: SY0-801 1.1 in full. On SY0-701 this material is objective 1.1 plus most of 1.2, including the physical security controls listed there.

The ideas every control serves

Controls exist to protect a short list of properties. The first three come from US federal law, and NIST's glossary quotes them from 44 U.S.C. 3542:

• Confidentiality: preserving authorized restrictions on who can see and disclose information, including protection of personal privacy. Encryption and access permissions serve it.
• Integrity: guarding against improper modification or destruction of information. Hashes, digital signatures and change control serve it.
• Availability: ensuring timely and reliable access to information and systems. Backups, redundancy and protection against denial of service serve it.

Three more ideas sit beside the triad. AAA names a sequence. Authentication proves who or what you are, whether you are a person typing a password or a server presenting a certificate. Authorization decides what that identity may do. Accounting records what it actually did, in logs that can be reviewed later. Non-repudiation is, in NIST SP 800-53's words, protection against an individual who falsely denies having performed an action. A digital signature provides it, because only the holder of the private key could have produced the signature.

Two design principles finish the set. Least privilege grants each person or process only the minimum resources and authorizations it needs for its job. Defense in depth layers controls of different kinds, so that an attack one layer misses is caught by another. Zero Trust, covered in Lesson 18, pushes both ideas further: being on the right network earns no trust by itself, and every request is authenticated and authorized.

What matters here: every control you meet protects confidentiality, integrity or availability, or supports authentication, authorization, accounting or non-repudiation. If you cannot say which, you do not yet understand the control.

Axis one: the category

The category answers the question "who or what carries this control out?" SY0-801 gives each category two names, and either may appear in a question.

The difference between managerial and operational trips up many candidates. Managerial controls decide and oversee: a policy saying backups must be tested quarterly is managerial. Operational controls are the work people actually do: the administrator who restores a test backup every quarter is performing an operational control. Technical controls run without anyone pressing a button once they are configured.

In short: category is about the means. Machines enforce technical controls, management sets managerial ones, people perform operational ones, and the physical world holds physical ones.

Axis two: the type

The type answers a different question: "what does this control do about an incident?" A useful way to hold the six types is a timeline, from before an incident to after it.

Two pairs need care. A deterrent works on the attacker's mind; a preventive control works on the attacker's path. A warning banner deters, a locked door prevents. And a directive control is an instruction, which only works if people follow it, so a policy alone is directive even when its subject is prevention.

Some controls honestly do two jobs. A visible camera deters, and its recording detects. When an exam question asks which type a control is, read the scenario for its purpose. If the camera was installed so that staff can review who entered the server room, its main job there is detective.

Remember: type is about purpose on the incident timeline: direct, deter, prevent, detect, correct, or compensate.

Reading the grid

Put the two axes together and every control gets a two-part name. Here is how a handful of familiar safeguards land:

Notice that the login banner is technical even though it only deters: software displays it. Category and type are independent questions, and a good answer names both.

The ransomware guide, classified

Now read CISA's recommendations as an assessor would. Each row is a recommendation from the October 2023 guide, with the two-part name it earns and the reason.

Read down the type column and the guide's design shows. It mixes preventive, detective, directive and corrective controls on purpose. That mix is defense in depth written as a to-do list: if the phishing-resistant MFA fails, EDR may notice; if detection fails, the offline backup still restores.

Why this matters: classifying controls is not trivia. It is how you find gaps: a program with ten preventive controls and no tested corrective one is a program that cannot recover.

Physical controls the exam names

SY0-701 listed physical security controls by name, and SY0-801 still includes physical and environmental controls and physical attack vectors. Know each one and its usual type:

• Bollards: short, sturdy posts that stop vehicles from reaching a building entrance. Physical, preventive.
• Access control vestibule: a small space between two doors, only one of which opens at a time, so a second person cannot slip through behind the first. Physical, preventive.
• Fencing: marks a boundary and slows or stops entry. Physical, preventive and deterrent.
• Video surveillance: records activity for review and discourages intruders. Physical, detective and deterrent.
• Security guards: people who can check, challenge and respond, which makes them flexible enough to be preventive, detective and deterrent at once.
• Access badges: identify people and, with a reader, open only the doors they are allowed through. Physical, preventive, and a source of accounting records.
• Lighting: removes the darkness intruders rely on and helps cameras work. Physical, deterrent.
• Sensors: infrared sensors respond to body heat, pressure sensors to weight on a floor or mat, and microwave and ultrasonic sensors to movement that changes reflected energy or sound. Physical, detective.

Compensating controls and gap analysis

NIST SP 800-53 defines compensating controls as controls used in place of the ones a baseline calls for, which give equivalent or comparable protection. Picture a factory machine controller that runs software the vendor no longer patches and that cannot be replaced until next year. Patching, the preferred control, is impossible. Compensating controls might isolate the controller on its own network segment, allow connections only from one management workstation, and add monitoring of every connection. None of them is a patch, but together they reduce the same risk.

How do you notice that a control is missing in the first place? A gap analysis compares the controls an organization has against the ones a framework or standard expects, and lists the differences. It appears in SY0-701 objective 1.2 and in SY0-801 objective 5.5, and Lesson 34 shows how to run one. Your classification grid is a gap analysis in miniature: empty cells point to missing kinds of protection.

Worth holding on to: a compensating control is chosen because the preferred control cannot be used, and it must reduce the same risk to a comparable degree.

Common misconceptions

• "A security policy is a preventive control." A policy is directive: it tells people what to do. Prevention happens when a technical or physical control enforces the instruction, or when people follow it.
• "Managerial and operational mean the same thing." Managerial controls decide and oversee, such as a risk assessment or a policy. Operational controls are carried out by people as part of daily work, such as reviewing logs or testing backups.
• "A camera is a preventive control." A camera cannot stop anyone. It deters by being seen and detects by recording.
• "Compensating controls are any extra controls." They are specifically substitutes for a required or preferred control that cannot be implemented, and they must give comparable protection.
• "Defense in depth means buying more of the same tool." Depth comes from different kinds of control, so that one failure mode does not defeat them all.

The short version

• A control has a category (technical, managerial, operational, physical) and a type (directive, deterrent, preventive, detective, corrective, compensating). Name both.
• Category answers "carried out by what or whom?"; type answers "what does it do about an incident, and when?"
• Controls serve confidentiality, integrity and availability, and support authentication, authorization, accounting and non-repudiation.
• Least privilege limits each identity to what its job needs; defense in depth layers different kinds of controls.
• Compensating controls substitute for a preferred control that cannot be used, with comparable protection; gap analysis finds where controls are missing.
• Bollards, vestibules, fencing, cameras, guards, badges, lighting and sensors are the physical controls to recognize.

Sources

1. Cybersecurity and Infrastructure Security Agency, and Multi-State Information Sharing and Analysis Center. (2023). #StopRansomware guide (Version 3.0, October 2023). CISA. cisa.gov
2. Joint Task Force. (2020, updated December 2020). Security and privacy controls for information systems and organizations (NIST SP 800-53 Rev. 5). National Institute of Standards and Technology. csrc.nist.gov
3. National Institute of Standards and Technology. (n.d.). Glossary: entries for confidentiality, non-repudiation, least privilege, defense-in-depth and compensating controls. NIST Computer Security Resource Center. csrc.nist.gov
4. Rose, S., Borchert, O., Mitchell, S., and Connelly, S. (2020). Zero trust architecture (NIST SP 800-207). National Institute of Standards and Technology. csrc.nist.gov
5. CompTIA. (2025). CompTIA Security+ SY0-801 V8 certification exam objectives (Document version 2.0), objective 1.1. CompTIA (PDF)

04:09 UTC, Friday 19 July 2024

At 04:09 Coordinated Universal Time on Friday 19 July 2024, the security company CrowdStrike sent a routine update to its Falcon sensor, the agent that protects Windows computers for its customers. The update was not new software. It was a small file of detection content, known internally as Channel File 291, of the kind the company shipped many times a day. Windows computers running sensor version 7.11 or later that received it crashed to a blue screen. Many crashed again each time they restarted.

CrowdStrike reverted the file at 05:27 UTC, seventy-eight minutes later. By then the damage was done. Microsoft estimated that 8.5 million Windows devices were affected, less than one percent of all Windows machines, yet enough to ground flights, close hospital clinics and stop payment systems around the world. This was not an attack. Nobody broke in. A change went wrong, and the way it went wrong is a tour of everything objective 1.2 asks you to know.

Exam objectives: SY0-801 1.2, a "Given a scenario" objective, in full. On SY0-701 this is objective 1.3.

What went wrong, in CrowdStrike's own words

CrowdStrike published its root cause analysis on 6 August 2024, and its findings are unusually frank. In February 2024, sensor version 7.11 had added a new detection template for Windows interprocess communication. The template's definition said it took 21 input fields, but the sensor code that called it supplied only 20. Nothing noticed, because every test and every earlier content file used a wildcard, a "match anything" value, in the 21st field. A wildcard never needs to read the field, so the missing value was never touched.

On 19 July two new template instances were deployed, and one used a real value in the 21st field. The sensor tried to read a 21st input that did not exist, reading past the end of its data in memory. Because the sensor runs as a driver inside the Windows kernel, the core of the operating system, that bad read crashed the whole computer.

The report lists six findings. The input count was not checked when the sensor was compiled. The code had no runtime check on the size of its input. The tests covered too narrow a range of matching values. The Content Validator, the tool that checks content before release, had a logic error. Template instances were not tested inside the interpreter that would run them. And new content was not deployed in stages. Every one of those is a change management lesson.

Why this matters: the most expensive changes are often the ones nobody thought of as changes. CrowdStrike's report describes the file as configuration data, not code, yet it altered the behavior of a kernel component on millions of machines at once.

The business processes of a change

Change management is the set of processes that decide whether, when and how a change to a production system happens, and what to do if it fails. SY0-801 lists the business processes by name. The table pairs each with what it means and with what the CrowdStrike findings teach about it.

NIST SP 800-128, the government's guide to security-focused configuration management, defines security impact analysis as analysis by qualified staff of the extent to which a change affects the security posture of a system. It says this should happen preferably before a change is approved. Among the things it says a change control process should define are requirements for testing before release, for rollback if problems occur, and for expedited handling of urgent changes such as critical security fixes.

That last item answers a question you will meet in practice and on the exam. An emergency patch for a flaw being actively exploited cannot wait for next month's board meeting. The answer is not to skip change management. It is an expedited, documented path with a smaller approval group, followed by retroactive review.

Key idea: every change needs an owner, an approval, an impact analysis, evidence from testing, and a backout plan written for the way it is most likely to fail.

A backout plan for the failure you will actually get

CrowdStrike's backout worked exactly as designed: at 05:27 UTC it replaced the bad file with a good one. A computer that was still running and downloaded the replacement recovered. But a computer that had already crashed restarted, loaded the sensor early in the boot process, read the bad file again, and crashed again before it could download anything.

Those machines needed hands. Microsoft's recovery article told administrators to start each one in Safe Mode or the Windows Recovery Environment and delete the files matching C-00000291*.sys from the CrowdStrike drivers folder. Many organizations encrypt their disks with BitLocker, so the same article explains how to find the BitLocker recovery key, which may be requested on the way. Thousands of organizations did this by hand, machine by machine, over the following days.

The general lesson is that a backout plan must be written for the failure mode, not for the change. "Revert the file" assumes the system is healthy enough to receive the revert. A plan that asks "what if the system cannot boot?" leads to different preparations: recovery keys stored where you can reach them during an outage, remote console access, and a staged rollout so that the first failure happens on ten machines rather than ten million.

The upshot: test your backout plan against the worst plausible failure, including the case where the system cannot run the undo step itself.

The technical implications of a change

Objective 1.2 also lists technical consequences a change can have. Each is a question to ask during impact analysis:

• Allow lists and deny lists. If application allowlisting is in force, a new version of a program may have a new file hash or signature and be blocked until the list is updated. A change to a deny list can block something legitimate.
• Restricted activities. The change request should say what the implementer may touch and what is off-limits during the work, so a firewall change does not quietly become a server rebuild.
• Downtime. Will users lose a service, and for how long? Downtime is a cost that belongs in the approval discussion and the maintenance window.
• Service restart and application restart. Many changes take effect only after a restart, which interrupts sessions and can itself fail. A service that does not come back is a common way for a simple change to become an outage.
• Legacy applications. Older software may depend on settings, protocols or library versions the change removes, and it may have no vendor left to fix it.
• Dependencies. Other systems may rely on the component being changed. The Falcon sensor's driver loads early in Windows startup, which is exactly why a fault in its content stopped machines from booting.

The point: impact analysis asks what the change will block, interrupt, restart, break or drag down with it, and it asks before approval rather than after the outage.

Staged rollout: testing in production, safely

The sixth finding in CrowdStrike's report is the one most organizations can copy. New content now goes first to a canary group, a small set of systems watched closely for crashes, false alarms or slowdowns. It is promoted to wider rings only after a bake-in period in which telemetry shows no harm. The company also gave customers control over where and when content updates are deployed, which puts maintenance windows back in their hands.

A staged rollout turns test results into a continuous process. Even excellent pre-release testing misses something, as the wildcard in field 21 shows. A canary ring means the thing it misses is discovered on a few machines with a working backout, instead of everywhere at once.

Documentation and version control

A change is not finished when the system works. The objective names two documentation tasks: updating diagrams, so the next person troubleshooting sees the network as it is rather than as it was, and updating policies and procedures, so the SOP matches the new reality. Out-of-date documentation turns the next incident into an archaeology project.

Version control keeps every version of a configuration with a record of who changed what, when and why. NIST SP 800-128 makes the point directly: retaining previous versions of a baseline configuration allows rollback to a previous secure and working version, and it supports incident response and audits. Tools such as Git, built for source code, work just as well for configuration files and infrastructure templates.

In short: diagrams and procedures must change when the system changes, and version control makes every configuration both explainable and reversible.

Common misconceptions

• "Urgent security fixes should bypass change management." NIST's guidance calls for an expedited path for urgent changes, with retroactive analysis and approval, not for skipping the process. An emergency is when a bad change does most damage.
• "A backout plan means the change can always be undone." Only if the undo step can still run. The machines that crashed on 19 July could not receive the revert.
• "Configuration isn't code, so it needs less testing." Anything that changes how production systems behave is a change. Channel File 291 was configuration data.
• "The CAB exists to say no." The board exists to make sure risk was understood before saying yes: impact analyzed, tests passed, backout written, window chosen.
• "Change management is an IT operations topic, not security." Changes alter attack surface, break controls and cause outages; availability is one of the three security goals.

Looking back

• On 19 July 2024 a content file that read a 21st input from a 20-item array crashed an estimated 8.5 million Windows devices; it was a failed change, not an attack.
• Business processes: CAB approval, ownership, stakeholders, impact analysis, test results, backout planning, fail forward, maintenance windows and SOPs.
• Technical implications: allow and deny lists, restricted activities, downtime, service and application restarts, legacy applications and dependencies.
• Write the backout plan for the failure mode, and stage rollouts so a failure starts small.
• Update diagrams and procedures, and keep configurations under version control so every change is explainable and reversible.

Sources

1. CrowdStrike. (2024, August 6). External technical root cause analysis: Channel File 291. crowdstrike.com (PDF)
2. CrowdStrike. (2024, July 24). Falcon content update preliminary post incident report. crowdstrike.com
3. Weston, D. (2024, July 20). Helping our customers through the CrowdStrike outage. Official Microsoft Blog. blogs.microsoft.com
4. Microsoft. (2024). KB5042421: CrowdStrike issue impacting Windows endpoints causing an 0x50 or 0x7E error message on a blue screen. Microsoft Support. support.microsoft.com
5. Johnson, A., Dempsey, K., Ross, R., Gupta, S., and Bailey, D. (2011, updated 2019). Guide for security-focused configuration management of information systems (NIST SP 800-128). National Institute of Standards and Technology. csrc.nist.gov
6. Ubuntu. (n.d.). ufw(8) manual page, Ubuntu 24.04 LTS. manpages.ubuntu.com

Twenty-two bytes

Here is a file of exactly twenty-two bytes: the words Pay Alice 100 dollars, followed by a line break. Run it through the SHA-256 hash function and you get a 64-character value that begins 8ab1c261 and ends 6edae4. Change the 1 to a 9, so the note says 900, and the value becomes one that begins 8efa832d. The two outputs share nothing you could use to guess one from the other.

That small experiment is the start of this lesson. You will take one note and protect it three ways. A hash gives it a fingerprint, so any change shows. Encryption hides its contents from anyone without the key. A digital signature seals it, proving who wrote it and that nobody has altered it since. Then you will run the whole procedure a second time with one changed byte or one wrong password, and watch each protection react. Every command was run with OpenSSL 3.5.5 while this lesson was written, and each uses options documented for OpenSSL 3.0 and later.

Exam objectives: SY0-801 1.3: encryption, key exchange, algorithms, key length, hashing algorithms, salting, digital signatures and obfuscation. Lesson 6 covers the rest of 1.3: PKI, certificates, encryption levels and tools. On SY0-701 this is objective 1.4, which also names key stretching, steganography, blockchain and the open public ledger, all taught here.

Step 1: a fingerprint, with a hash

A cryptographic hash function takes input of any length and produces a fixed-length output, called a hash or digest. Three properties make it useful. It is one-way: you cannot work back from the digest to the input. It is collision resistant: finding two different inputs with the same digest should be infeasible. And a tiny change in the input changes the digest completely, which is called the avalanche effect.

In your lab VM, create the note and hash it:

printf 'Pay Alice 100 dollars\n' > note.txt
openssl dgst -sha256 note.txt

OpenSSL prints the algorithm, the file name and the digest. The coreutils command sha256sum note.txt prints the same 64 characters, and so does PowerShell's Get-FileHash on Windows, in capital letters. If yours begins 8ab1c261, you created exactly the same twenty-two bytes.

Not every hash function is still trustworthy. In December 2022 NIST announced it would phase out SHA-1 by 31 December 2030, because attackers can now create fraudulent messages with the same SHA-1 hash as a genuine one. MD5 fell earlier. Current choices are the SHA-2 family, such as SHA-256 and SHA-384, and SHA-3.

A hash on its own proves only that a file matches a digest. It says nothing about who computed the digest, as Lesson 1's download check showed. Combining a hash with a secret key gives a keyed hash (an HMAC), which proves the sender knew the key. Combining it with a private key gives a signature, which is Step 5.

In short: a hash is a one-way, fixed-length fingerprint for integrity; use SHA-2 or SHA-3, never MD5 or SHA-1 for security.

Step 2: hiding the contents, with symmetric encryption

Symmetric encryption uses one shared key both to encrypt and to decrypt. It is fast, which is why it protects nearly all bulk data, from disks to network traffic. The standard algorithm is AES, defined in FIPS 197, which encrypts 128-bit blocks with keys of 128, 192 or 256 bits. ChaCha20 is a widely used alternative, common on phones because it runs fast in software.

Encrypt the note with AES-256, using a password:

openssl enc -aes-256-cbc -pbkdf2 -iter 600000 -salt -in note.txt -out note.enc

OpenSSL asks for a password twice and writes note.enc. Decrypt it with the same command plus -d, reading from note.enc, and the original line comes back. Two details in that output reward a closer look:

• The encrypted file begins with the eight characters Salted__ followed by eight random bytes, the salt. Encrypt the same note twice with the same password and the two files differ, because each run picks a new salt.
• CBC, the mode used here, chains blocks together but has no integrity check. OpenSSL's manual for this command says it does not support authenticated modes such as GCM, and points to its CMS tool for real bulk encryption.

The second point matters. An authenticated encryption mode, such as AES-GCM or ChaCha20-Poly1305, adds a tag that detects any change to the ciphertext. TLS 1.3, the protocol behind the browser padlock, allows only authenticated modes. Use OpenSSL's enc command to learn, and use tools with authenticated encryption to protect real files.

Some symmetric algorithms belong only in history. NIST SP 800-131A disallowed three-key Triple DES (3DES) for encryption after 31 December 2023; it may still decrypt old data. DES, with its 56-bit key, is far too short for today. RFC 7465 forbids RC4 in TLS of any version.

Remember: symmetric encryption means one shared key; AES and ChaCha20 are the current choices, and an authenticated mode adds the integrity check that plain CBC lacks.

Step 3: turning a password into a key, with salting and stretching

You typed a password, but AES needs a 256-bit key. The -pbkdf2 option derives the key using PBKDF2, a password-based key derivation function, and -iter 600000 tells it to repeat its inner step 600,000 times. OpenSSL's manual notes that high iteration counts increase the time needed to brute-force the file. That is key stretching: making each guess deliberately slow, so an attacker trying millions of passwords is slowed by the same factor.

The salt does a different job. Without a salt, the same password always produces the same key, so an attacker could precompute results for common passwords once and reuse them against every file or account. A salt is a random value mixed in before derivation and stored alongside the result. It does not need to be secret; it needs to be unique, so that every precomputed table is useless.

The same two ideas protect stored passwords. NIST SP 800-63B-4, finalized in July 2025, says passwords shall be salted and hashed using a suitable password hashing scheme. It asks for a salt of at least 32 bits and a cost factor as high as is practical, raised over time. Besides PBKDF2, widely used password-hashing functions include bcrypt, scrypt and Argon2. A fast hash such as plain SHA-256 is the wrong tool for passwords, because fast is exactly what an attacker wants.

The point: salting makes every stored result unique; stretching makes every guess expensive. Passwords need both.

Step 4: the key-sharing problem, and asymmetric cryptography

Symmetric encryption has one hard problem: both sides need the same key, and you cannot safely send it over the network you are trying to protect. Asymmetric, or public-key, cryptography solves it with a key pair. The public key can be given to anyone; the matching private key never leaves its owner. What one key does, only the other can undo.

The common families are RSA, based on factoring large numbers, and elliptic curve cryptography (ECC). Key lengths are not comparable across families. NIST SP 800-57 Part 1 compares them by security strength, the work an attacker needs, in bits:

So a 3072-bit RSA key is about as strong as a 128-bit AES key, and a 256-bit elliptic curve key matches it. That is why ECC is popular on small devices: the same strength for much shorter keys.

Asymmetric operations are far slower than symmetric ones, so real systems use them sparingly. A key exchange lets two parties agree on a shared symmetric key over an open network. In Diffie-Hellman, and its elliptic curve form ECDH, each side combines its own secret with the other's public value and both arrive at the same result, which an eavesdropper cannot compute. When each session uses fresh, temporary key pairs (written DHE or ECDHE, with E for ephemeral), stealing a server's long-term private key later does not unlock recorded past sessions. That property is forward secrecy. The current TLS 1.3 specification, RFC 9846, removes static RSA and Diffie-Hellman key exchange, so every TLS 1.3 key exchange provides it.

Why this matters: real systems are hybrids. Asymmetric cryptography authenticates and agrees on a key; fast symmetric encryption then protects the data.

Step 5: sealing the note, with a digital signature

A digital signature uses the key pair the other way round. The signer hashes the message and transforms the hash with the private key. Anyone with the public key can check the result. A valid signature proves three things: the message has not changed (integrity), it was signed with that private key (authentication of origin), and the signer cannot plausibly deny signing it (non-repudiation). FIPS 186-5, the current Digital Signature Standard, approves RSA, ECDSA and EdDSA signatures. It no longer approves DSA for creating new signatures.

Make a key pair and sign the note:

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out priv.pem
openssl pkey -in priv.pem -pubout -out pub.pem
openssl dgst -sha256 -sign priv.pem -out note.sig note.txt
openssl dgst -sha256 -verify pub.pem -signature note.sig note.txt

The last command prints Verified OK. Notice who holds what. The private key stays on your machine, and you would protect it with a passphrase or hardware in real life. The public key and the signature can travel anywhere. If you prefer a modern curve, openssl genpkey -algorithm ed25519 makes an EdDSA key, signed and checked with openssl pkeyutl and its -rawin option; it reports Signature Verified Successfully.

Key idea: sign with your private key, verify with the public key; a valid signature gives integrity, origin and non-repudiation, which encryption alone does not.

The second run: change one thing

Now break each protection on purpose. Overwrite the note so it says 900 instead of 100, and re-run the checks without re-signing. Then try to decrypt note.enc with a wrong password. Here is what happened when this lesson was written:

The last row hides a lesson. The bad decrypt message comes from a check on the padding at the end of the data, not from an integrity check. Occasionally a wrong key produces padding that happens to look valid, and the output is garbage with no error at all. Authenticated modes remove that uncertainty: a wrong key or a tampered file always fails the tag check.

The upshot: hashes detect change, signatures detect change and prove origin, and encryption hides content; only authenticated encryption also tells you reliably that decryption failed.

Obfuscation: hiding is not locking

SY0-801 lists obfuscation as a cryptographic topic, and SY0-701 named three forms. They make data harder to see or use, but they are not encryption:

• Steganography hides the existence of a message, for example by embedding it in the pixels of an image. NIST's glossary calls it communicating in a way that hides the existence of the communication. Once found, the hidden data is readable unless it was also encrypted.
• Tokenization replaces a sensitive value, such as a card number, with a random token. The real value lives only in a protected token vault, so systems that hold the token hold nothing an attacker can use.
• Data masking hides part of a value, such as showing only the last four digits of an account number on a receipt or screen.

Encoding schemes such as Base64 are not even obfuscation in a security sense: anyone can decode them without a key. Lesson 19 returns to tokenization and masking as data protection methods.

Blockchain and the open public ledger

SY0-701 also lists the blockchain. NIST's overview, IR 8202, describes blockchains as tamper-evident and tamper-resistant digital ledgers, implemented in a distributed way and usually without a central authority. The cryptography is the hash you met in Step 1. Each block includes the hash of the block before it, so changing an old entry changes every hash after it, and every copy of the ledger can see the mismatch. An open public ledger is one anyone can read and verify. A blockchain therefore protects integrity and provides a shared history; it does not provide confidentiality, because a public ledger is readable by design.

Algorithms you should recognize

The last row looks ahead. NIST SP 800-57 warns that its security-strength estimates for RSA and ECC will change significantly once quantum computing becomes practical. On 13 August 2024 NIST published its first three post-quantum standards and urged administrators to start integrating them immediately. Expect the exam to ask why: data recorded today could be decrypted by a future quantum computer.

Common misconceptions

• "Hashing is a kind of encryption." Encryption is reversible with a key; a hash has no key and cannot be reversed. You verify a hash by recomputing it.
• "If it decrypts, it was not tampered with." Plain CBC has no integrity check. Only authenticated encryption, or a separate signature or HMAC, proves the data is unaltered.
• "A salt must be kept secret." A salt is stored beside the hash. Its job is uniqueness, which defeats precomputed tables; the cost factor is what slows guessing.
• "A 2048-bit RSA key is stronger than a 256-bit AES key because 2048 is bigger." Strength is measured in security bits. RSA-2048 gives about 112; AES-256 gives 256.
• "Base64 or steganography protects data." Base64 is an encoding anyone can reverse, and steganography only hides that data exists. Neither replaces encryption.

Putting it together

• Hashes (SHA-2, SHA-3) give integrity fingerprints; MD5 and SHA-1 are broken for security.
• Symmetric ciphers (AES, ChaCha20) protect bulk data with one shared key; authenticated modes add integrity; 3DES, DES and RC4 are retired.
• Passwords need a unique salt and deliberate stretching (PBKDF2, bcrypt, scrypt, Argon2), never a fast hash alone.
• Asymmetric key pairs (RSA, ECC) solve key sharing; compare them by security strength; ephemeral key exchange gives forward secrecy.
• Digital signatures give integrity, origin and non-repudiation; FIPS 186-5 approves RSA, ECDSA and EdDSA.
• Steganography, tokenization and masking obfuscate; blockchains provide tamper-evident shared ledgers; post-quantum standards arrived in 2024.

Sources

1. National Institute of Standards and Technology. (2001, updated 2023). Advanced Encryption Standard (AES) (FIPS 197). csrc.nist.gov
2. National Institute of Standards and Technology. (2023). Digital Signature Standard (DSS) (FIPS 186-5). csrc.nist.gov
3. Barker, E. (2020). Recommendation for key management: Part 1, general (NIST SP 800-57 Part 1 Rev. 5), Table 2. National Institute of Standards and Technology. nist.gov (PDF)
4. Barker, E., and Roginsky, A. (2019). Transitioning the use of cryptographic algorithms and key lengths (NIST SP 800-131A Rev. 2). National Institute of Standards and Technology. csrc.nist.gov
5. National Institute of Standards and Technology. (2022, December 15). NIST retires SHA-1 cryptographic algorithm. nist.gov
6. National Institute of Standards and Technology. (2024, August 13). NIST releases first 3 finalized post-quantum encryption standards. nist.gov
7. Temoshok, D., Fenton, J., Choong, Y.-Y., Lefkovitz, N., Regenscheid, A., Galluzzo, R., and Richer, J. (2025). Digital identity guidelines: Authentication and authenticator management (NIST SP 800-63B-4). National Institute of Standards and Technology. csrc.nist.gov
8. Rescorla, E. (2026). The Transport Layer Security (TLS) protocol version 1.3 (RFC 9846, obsoletes RFC 8446). RFC Editor. rfc-editor.org
9. Popov, A. (2015). Prohibiting RC4 cipher suites (RFC 7465). RFC Editor. rfc-editor.org
10. OpenSSL Project. (n.d.). openssl-enc (OpenSSL 3.0 manual page). docs.openssl.org
11. Yaga, D., Mell, P., Roby, N., and Scarfone, K. (2018). Blockchain technology overview (NIST IR 8202). National Institute of Standards and Technology. csrc.nist.gov

The ticket: "the certificate must have expired"

On Monday morning a help desk ticket arrives: since the weekend's certificate renewal, staff opening the intranet portal at portal.lab.test get a full-page browser warning. The ticket's author has already reached a verdict. The old certificate expired on Saturday, so the new one must not have been installed properly, and the fix is to install it again.

That is a plausible guess, and it is wrong. This lesson follows the investigation one check at a time, using the same OpenSSL commands you will run in this lesson's lab. Each check rules out a cause and teaches a piece of public key infrastructure (PKI): the system of certificate authorities, certificates and trust stores that lets your browser trust a server it has never met. Along the way you will meet the hardware that protects the most valuable keys, and a 2023 intrusion that shows what happens when one of those keys escapes.

Exam objectives: SY0-801 1.3: public key infrastructure, certificates, encryption levels, transport encryption, key escrow and tools. On SY0-701 this is the rest of 1.4, including TPMs, HSMs, key management systems and secure enclaves.

Check one: the dates

A certificate is a signed statement binding a public key to an identity, such as a server name. The standard format, X.509, is profiled for the internet in RFC 5280. Among its fields are a validity period with two dates, notBefore and notAfter. Read them first:

openssl x509 -in server.crt -noout -subject -issuer -dates

On the portal's new certificate the dates run from Saturday to ninety days later. Expiry is ruled out. Had the certificate been expired, OpenSSL's verify command would have said so plainly; when this lesson was written, an expired test certificate produced the message error 10, certificate has expired.

Short lifetimes like ninety days are becoming normal for public certificates. In April 2025 the CA/Browser Forum, the body of certificate authorities and browser makers that sets rules for public TLS certificates, adopted ballot SC-081v3. It cuts the maximum lifetime in steps from 398 days to 47 days, with the reductions taking place between March 2026 and March 2029. Expiry tickets like this one are a reason to automate renewal, not to buy longer certificates.

Check two: the chain of trust

A browser trusts a certificate only if it can build a chain of trust from it to a certificate it already trusts. The server's own certificate, the leaf, is signed by an intermediate CA, whose certificate is signed by a root CA. The root's certificate is self-signed, and it is trusted because it sits in the trust store of the operating system or browser. That pre-installed root is the root of trust: the starting point that everything else is checked against. Roots are kept offline and used rarely; intermediates do the day-to-day signing, so a compromised intermediate can be replaced without replacing the root in every trust store.

Test the chain against the organization's own root certificate:

openssl s_client -connect portal.lab.test:443 -servername portal.lab.test -CAfile lab-root.crt

The output ends Verify return code: 0 (ok), so the chain is sound. Run the same command without the CA file, on a machine that does not trust the private root, and you get the message unable to get local issuer certificate (error 20), followed by unable to verify the first certificate (error 21). A certificate that signs itself with no CA at all produces error 18, self-signed certificate. A self-signed certificate is fine for a lab and wrong for anything users must trust; a third-party certificate from a public CA is trusted by browsers everywhere, and an internal CA's certificates are trusted only by machines that have its root installed.

Remember: trust flows down a chain: leaf, intermediate, root, trust store. A break anywhere produces a warning, whatever the dates say.

Check three: the name

Last, check that the certificate names the host users type. Browsers do not read the familiar Common Name field for this. RFC 9525, the 2023 standard for service identity in TLS, says the Common Name must not be used to identify a service; only the subject alternative name (SAN) extension counts. Ask OpenSSL to check the name for you:

openssl s_client -connect portal.lab.test:443 -servername portal.lab.test -verify_hostname portal.lab.test -CAfile lab-root.crt

This time the output says Verify return code: 62 (hostname mismatch). Printing the extension shows why: the SAN lists only www.lab.test. Whoever generated the renewal request copied the wrong name from an old template. The dates were fine and the chain was fine; the certificate simply described a different server. That is the root cause, and reinstalling would have changed nothing.

Worth holding on to: diagnose certificate errors in order (dates, chain, name), and let the tool's error message, not the ticket's guess, name the cause.

Making the replacement: CSRs, SANs and wildcards

The fix is a new certificate, which starts with a certificate signing request (CSR). The administrator generates a new key pair on the server, then a CSR containing the public key and the requested identity, including the SAN entries. The CSR is signed with the new private key, which proves the requester holds it. The private key itself never leaves the server. The CA checks that the requester controls the names, signs a certificate, and sends it back.

Some organizations ask for a wildcard certificate instead, such as one for *.lab.test, to cover many hosts at once. RFC 9525 sets the rules: the asterisk must be the whole leftmost label, and it matches exactly one label. So *.lab.test covers portal.lab.test and mail.lab.test, but not lab.test itself and not dev.portal.lab.test. Convenience has a price. Every server holding the wildcard's private key can impersonate every host it covers, so one compromised web server exposes them all.

When a certificate must die early: revocation

Sometimes a certificate must stop being trusted before it expires, most often because its private key was stolen. The CA then revokes it, and clients need a way to find out. A certificate revocation list (CRL), defined in RFC 5280, is a signed list of revoked serial numbers that clients download periodically. The Online Certificate Status Protocol (OCSP), defined in RFC 6960, lets a client ask the CA about one certificate as it connects.

OCSP's real-time answers came at a cost. Let's Encrypt, the largest public CA, called OCSP a considerable risk to privacy, because the CA running the responder learns which sites a visitor's address is opening. It removed OCSP addresses from its certificates in May 2025, switched off its responders on 6 August 2025, and now publishes revocation information only through CRLs. Shorter certificate lifetimes help too: a stolen key for a 47-day certificate is useful for weeks, not a year.

Key escrow is a different idea that sounds similar. NIST defines it as retaining the private key of a subscriber's encryption certificate to support key recovery. An organization that escrows encryption keys can still read an employee's encrypted files after that person leaves, at the cost of creating a valuable store of keys that must itself be protected.

Where keys live: TPMs, HSMs, key management services and secure enclaves

Everything above depends on private keys staying private. Four kinds of tool exist to keep them that way:

Why does this matter so much? In May and June 2023, a group Microsoft tracks as Storm-0558 read the email of 22 organizations and more than 500 individuals, including the US Secretary of Commerce, using authentication tokens it forged with a stolen Microsoft signing key. The US Cyber Safety Review Board's report, released in 2024, found that the key had been created in 2016 and was meant to be retired in March 2021. Microsoft had paused manual rotation of these consumer keys after an outage and had not built automated rotation or alerts for aging keys. The State Department detected the intrusion through a custom alert on a mailbox access log. When the Board finished its review, Microsoft still could not show how the key was stolen.

The Board's list of best practices reads like this lesson's vocabulary: automated, frequent key rotation; storing keys in isolated systems such as HSMs; and limiting each key's scope, so one stolen key cannot open everything. A signing key is a CA in miniature. Whoever holds it can mint trust.

The core of it: protect high-value keys in hardware, limit what each key can do, rotate keys automatically, and log every use.

Where encryption lives

Encryption protects data in a particular place against a particular threat. SY0-801 lists the levels by name:

Read the "protects against" column carefully, because exam scenarios turn on it. Microsoft's documentation for transparent data encryption says it protects data files at rest and does not encrypt communication channels; a user with database access still sees the data. Full-disk encryption protects a stolen laptop, but once the owner logs in, malware running as that user reads files in the clear. Choose the level that matches the threat in the question.

Common misconceptions

• "Certificate warnings mean the certificate expired." Expiry is one of several causes. An untrusted issuer, a missing intermediate, a self-signed certificate and a name mismatch all produce warnings.
• "The Common Name is what browsers check." RFC 9525 says the Common Name must not be used to identify a service. Browsers match the subject alternative name.
• "A wildcard covers every subdomain at any depth." It matches exactly one label: *.lab.test covers portal.lab.test, not dev.portal.lab.test or lab.test.
• "The CSR sends my private key to the CA." A CSR carries the public key and identity, signed with the private key. The private key stays on your server.
• "Full-disk encryption protects data from malware." It protects data on a powered-off or stolen device. A running, logged-in system decrypts data for whoever is using it.

The takeaway

• Check certificate problems in order: dates, chain, name. OpenSSL's messages (10, 18, 20, 21, 62) name the cause.
• Trust runs from the leaf through intermediates to a root in the trust store; self-signed certificates suit labs, third-party certificates suit the public.
• CSRs carry the public key and requested names; SANs, not the Common Name, identify the host; wildcards match one label.
• CRLs and OCSP publish revocation; Let's Encrypt moved to CRLs only in 2025, and lifetimes are falling toward 47 days by 2029.
• TPMs, HSMs, KMS and secure enclaves keep keys out of reach; the Storm-0558 review shows why rotation, isolation and scope matter.
• Pick the encryption level (full disk, volume, file, database, record, transport) that matches the threat.

Sources

1. Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and Polk, W. (2008). Internet X.509 public key infrastructure certificate and certificate revocation list (CRL) profile (RFC 5280). RFC Editor. rfc-editor.org
2. Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and Adams, C. (2013). X.509 internet public key infrastructure online certificate status protocol: OCSP (RFC 6960). RFC Editor. rfc-editor.org
3. Saint-Andre, P., and Salz, R. (2023). Service identity in TLS (RFC 9525). RFC Editor. rfc-editor.org
4. Let's Encrypt. (2024, December 5). Ending OCSP support in 2025. letsencrypt.org
5. CA/Browser Forum. (2025, April 11). Ballot SC081v3: Introduce schedule of reducing validity and data reuse periods. cabforum.org
6. Cyber Safety Review Board. (2024). Review of the summer 2023 Microsoft Exchange Online intrusion. US Department of Homeland Security. cisa.gov
7. Microsoft. (2026). Trusted Platform Module technology overview. Microsoft Learn. learn.microsoft.com
8. National Institute of Standards and Technology. (n.d.). Glossary: hardware security module (HSM); key escrow. NIST Computer Security Resource Center. csrc.nist.gov
9. Amazon Web Services. (n.d.). AWS Key Management Service (Developer Guide overview). docs.aws.amazon.com
10. Apple. (n.d.). The Secure Enclave. Apple Platform Security. support.apple.com
11. Microsoft. (2025). Transparent data encryption (TDE). Microsoft Learn. learn.microsoft.com

Four advisories, four adversaries

Between June 2023 and May 2024, CISA and its partners published four warnings about four very different adversaries. On 14 June 2023 they described LockBit, a ransomware operation that rents its tools to affiliates. The FBI counted about 1,700 LockBit attacks in the United States, and roughly 91 million dollars in ransoms paid, since its first US sighting in January 2020. On 16 November 2023 came Scattered Spider, a group that phones help desks while posing as employees. On 7 February 2024 the agencies said that Volt Typhoon, which they assessed to be sponsored by the People's Republic of China, was positioning itself inside US critical infrastructure networks to be ready for disruptive attacks in a crisis. On 1 May 2024 they warned that pro-Russia hacktivists were reaching water-plant control screens over the internet with factory default passwords.

One wanted money, one wanted money through people, one wanted a strategic option in a future war, and one wanted to make a political point. If you call all four "hackers," you will defend against none of them well. This lesson gives you the vocabulary the exam uses to tell them apart, and shows how each profile points to different controls.

Exam objectives: SY0-801 2.2 in full, and the advanced persistent threat from 2.3. On SY0-701 this is objective 2.1, which also lists shadow IT as a threat actor.

Three attributes that sort every actor

The exam describes actors by three attributes, and every scenario gives you clues to at least one of them:

• Internal or external. Does the actor already have legitimate access, as an employee, contractor or partner does, or must they get in from outside?
• Resources and funding. A state intelligence service can pay teams for years. A ransomware business reinvests its profits. A lone teenager has a laptop and free time.
• Level of sophistication and capability. Can the actor find and use new vulnerabilities and stay hidden for years, or do they rely on tools other people wrote and on targets that left the door open?

Motivation, what the actor wants, is the fourth question, and it predicts behavior. A financially motivated actor wants to be paid and will make noise to get paid. An espionage actor wants to stay invisible.

The actors, side by side

Two rows need a word of caution. Real groups blur the categories: Scattered Spider, which MITRE ATT&CK describes as a native English-speaking cybercriminal group active since at least 2022, used social engineering skill that many state actors would envy. And "unskilled" does not mean harmless. The 2024 fact sheet says the pro-Russia hacktivists used mostly unsophisticated techniques, yet at several US water and wastewater utilities they maxed out set points, turned off alarms and changed administrator passwords to lock operators out. Some sites had minor tank overflows before staff switched to manual control.

SY0-701 also listed shadow IT as an actor: systems and services that staff adopt without IT's approval, such as a team's unapproved file-sharing account. Nobody in shadow IT intends harm, but unmanaged systems miss patches, backups and monitoring. SY0-801 moved shadow IT to the vulnerabilities objective, which is a better fit, and Lesson 12 returns to it.

Bottom line: describe an actor by position, resources, sophistication and motive; the four together predict what it will try and how hard it will try.

Motivations, decoded

SY0-801 lists twelve motivations. Most are self-explanatory, but a few are easy to confuse:

• Financial covers any direct profit, such as selling stolen card data. Extortion is profit by threat: pay or we publish, or pay or your files stay encrypted. SY0-701 called a version of this blackmail.
• Espionage is quiet collection of secrets, usually for a state. Intellectual property theft is the commercial cousin, often for a competitor.
• Influence aims to shape opinion or decisions, for example by leaking selected documents. Political and ideological motives drive hacktivists. Fear and chaos are the aim of terrorism.
• Notoriety and general curiosity drive many unskilled attackers. Revenge is the classic motive of a disgruntled insider.
• Ethical describes people who break in to expose weaknesses so they get fixed. Lesson 2 explained why good intentions still need authorization.

SY0-701's list adds data exfiltration, service disruption, disruption and chaos, philosophical beliefs, and war. If a question describes what the attacker did rather than why, translate the action into the motive it serves: stealing quietly suggests espionage, encrypting loudly suggests extortion.

Advanced persistent threats

NIST's glossary defines an advanced persistent threat (APT) as an adversary with sophisticated levels of expertise and significant resources, which uses multiple attack vectors to establish footholds and pursue its objectives over an extended period. "Persistent" is the word to notice. CISA, NSA and the FBI reported indications that Volt Typhoon had kept access to some victims' IT environments for at least five years. It did so largely by "living off the land": using the administration tools already built into Windows rather than bringing malware that antivirus might catch.

APT describes how an adversary behaves, not a single kind of actor. Most APTs are state-sponsored, but the label fits any well-funded group that stays inside for the long term. SY0-801 lists the APT among threat vectors and sources (2.3), because its presence changes what defenders must look for: not a single malicious file, but small, legitimate-looking actions repeated over months.

The point: an APT is skilled, funded and patient, so detecting it means watching how built-in tools and valid accounts are used, not only scanning for malware.

Insiders: the actor already inside

CISA defines an insider as anyone who has or had authorized access to or knowledge of an organization's resources, and an insider threat as the risk that such a person will use that access, intentionally or unintentionally, to cause harm. Its categories are broader than most people expect:

• Unintentional insiders are either negligent, knowing the rules but ignoring them, or accidental, making a genuine mistake such as clicking a malicious link.
• Intentional insiders deliberately harm the organization, often for gain or out of a grievance.
• Collusive insiders work with an outside actor, for fraud, theft of intellectual property or espionage.
• Third-party insiders are contractors and vendors given access without being employees.

Insiders defeat perimeter controls by definition, which is why least privilege, prompt removal of access when people leave, separation of duties and monitoring of privileged actions matter so much.

Why the profile changes the defense

Profiling is worth the effort only if it changes what you do. The advisories make the link explicit:

MITRE ATT&CK makes this kind of profiling repeatable. It is a free knowledge base of adversary tactics and techniques drawn from real-world observations, with pages for named groups. Scattered Spider is group G1015 and Volt Typhoon is G1017; each page lists the techniques the group has used, and each technique page lists mitigations and ways to detect it.

Why this matters: the same organization needs different defenses against a patient state actor, a ransomware affiliate, a help-desk impersonator and a hacktivist with a password list.

Common misconceptions

• "Nation-states only go after governments and the military." Volt Typhoon's victims were mainly in communications, energy, transportation, and water and wastewater.
• "Unskilled attackers cannot do real damage." Hacktivists using default passwords disrupted water utilities in 2024. Low skill plus an open door is enough.
• "Insider threat means a disgruntled employee." CISA's definition includes accidents, negligence, collusion and contractors.
• "APT is a kind of malware." It describes an adversary: skilled, funded and persistent, whatever tools it uses.
• "Criminal groups are less capable than state actors." Some criminal operations are well funded and highly skilled; motivation, not skill, separates them.

Summing up

• Describe actors by position (internal or external), resources, sophistication and motivation.
• Nation-states seek espionage, influence or strategic disruption; organized crime seeks money, often through extortion; hacktivists seek a cause; unskilled attackers seek notoriety.
• Insiders include the malicious, the negligent, the accidental, the collusive and third parties.
• An APT is skilled, funded and patient; Volt Typhoon kept some access for at least five years by living off the land.
• Use ATT&CK group and technique pages to turn a profile into specific mitigations and detections.

Sources

1. CISA, NSA, and FBI. (2024, February 7). PRC state-sponsored actors compromise and maintain persistent access to U.S. critical infrastructure (AA24-038A). cisa.gov
2. CISA and partners. (2023, June 14). Understanding ransomware threat actors: LockBit (AA23-165A). cisa.gov
3. FBI and CISA. (2023, November 16; updated 2025, July 29). Scattered Spider (AA23-320A). cisa.gov
4. CISA, FBI, NSA, EPA, DOE, USDA, FDA, MS-ISAC, and partners. (2024, May 1). Defending OT operations against ongoing pro-Russia hacktivist activity [Fact sheet]. cisa.gov
5. Cybersecurity and Infrastructure Security Agency. (n.d.). Defining insider threats. cisa.gov
6. National Institute of Standards and Technology. (n.d.). Advanced persistent threat [Glossary entry]. NIST Computer Security Resource Center. csrc.nist.gov
7. MITRE. (2026). Scattered Spider, G1015 and Volt Typhoon, G1017. MITRE ATT&CK. attack.mitre.org

Monday morning: six findings, time to fix two

You are the only security administrator at a regional distributor with 300 staff. Monday's vulnerability report lists six findings, and the change calendar has room for two fixes this week. Here they are, with the facts a report typically gives you:

Sorting by score says fix A and E. Many teams do exactly that. By the end of this lesson you will see why B and E are the better pair, and you will be able to defend that choice in the language the exam uses: likelihood, impact, exploitation evidence and exposure.

Exam objectives: SY0-801 2.1 in full: threat feeds, likelihood, impact, intelligence sources, life cycle, CVSS scoring, prioritization, vulnerability types and CVE. On SY0-701 these terms sit in objective 4.3, vulnerability management, which Lesson 23 completes.

The naming system: CVE, CWE and the NVD

Every finding above would arrive with an identifier. The Common Vulnerabilities and Exposures (CVE) program gives each publicly disclosed vulnerability a unique ID, such as CVE-2021-44228. Its mission is to identify, define and catalog publicly disclosed cybersecurity vulnerabilities. IDs are assigned by CVE Numbering Authorities (CNAs): vendors, researchers and coordinators authorized to publish records within a defined scope.

A CVE names one specific flaw in specific products and versions. A Common Weakness Enumeration (CWE) entry names a type of mistake that causes flaws: CWE-89 is SQL injection, CWE-79 is cross-site scripting. MITRE's 2025 CWE Top 25 puts cross-site scripting, SQL injection and cross-site request forgery at the top. CWE is how SY0-801's "vulnerability types" are usually labeled.

NIST's National Vulnerability Database (NVD) adds analysis to CVE records: severity scores, weakness types and lists of affected products. Look up CVE-2021-44228 there and you find Log4Shell: the JNDI features in Apache Log4j2 versions 2.0-beta9 through 2.15.0 did not protect against attacker-controlled lookup endpoints. NIST's score for it is 10.0, Critical.

Reading a CVSS vector

The Common Vulnerability Scoring System (CVSS), maintained by FIRST, turns a vulnerability's characteristics into a score from 0 to 10. The score comes with a vector string that shows its working. Log4Shell's CVSS 3.1 vector from NIST is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Read it left to right:

Put together: anyone on the internet, with no account and no help from a user, could take complete control. That is why it scored 10.0. CVSS 4.0, published by FIRST in November 2023, keeps the same idea with renamed details. It defines four metric groups: Base, Threat, Environmental and Supplemental. It also asks that scores be labeled by the groups used: CVSS-B for base only, CVSS-BT with threat, CVSS-BE with environmental, and CVSS-BTE with all three. The qualitative scale is the same in both versions: None 0.0, Low 0.1-3.9, Medium 4.0-6.9, High 7.0-8.9, Critical 9.0-10.0.

In short: a CVSS vector describes how a flaw can be exploited and what it can damage. The base score summarizes that description for a typical system, not yours.

What the base score leaves out

The CVSS 4.0 specification says that assessing the Threat and Environmental metrics is not required but is highly recommended for more meaningful results. Those are the two things the base score cannot know.

The first is likelihood: is anyone actually exploiting this? A 9.8 that nobody has weaponized may be less urgent this week than a 7.5 that criminals are using today. The second is impact on your organization: how exposed is the vulnerable system, and how much does it matter? Finding A's 9.8 sits on a test server reachable only from one internal subnet and holding nothing sensitive. Finding E's 9.1 sits on an internet-facing server that customers send orders to.

Risk is the combination of the two. A flaw that is likely to be exploited, on a system whose loss would hurt, is the one to fix first. The base score is an input to that judgment, never the whole of it.

Evidence of exploitation: KEV and EPSS

Two free sources answer the likelihood question with data rather than opinion.

CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities with evidence of exploitation in the wild. A vulnerability is added only if it has a CVE ID, there is reliable evidence of active exploitation, and there is clear remediation guidance. Public proof-of-concept code or mass scanning alone does not qualify. CISA strongly recommends that every organization use the catalog to prioritize. For US federal civilian agencies it is mandatory: Binding Operational Directive 26-04, issued on 10 June 2026, replaced the earlier BOD 22-01. It sets remediation priority by asset exposure, KEV status, whether exploitation can be automated, and technical impact. The most urgent class must be fixed or mitigated within three days, with a forensic check for compromise.

FIRST's Exploit Prediction Scoring System (EPSS) estimates the probability that a published CVE will be exploited in the wild in the next 30 days. It publishes a score between 0 and 1 for every CVE, every day, with a percentile. When this lesson was written, EPSS gave Log4Shell 0.99999, the 100th percentile. A score of 0.02 means about a two percent chance of exploitation activity in the next month.

The core of it: severity says how bad exploitation would be; KEV and EPSS say how likely exploitation is; your own environment says how much it matters to you. Prioritize on all three.

Solving Monday's problem

Now return to the six findings. Finding E is in KEV, scores 9.1 and is internet-facing on a business-critical server: first. Finding B scores only 7.5, but it is in KEV and sits on the VPN gateway, the front door for remote access, reachable by the whole internet: second. Attackers prize VPN appliances because a foothold there bypasses most other controls.

Finding A drops despite its 9.8. It has no exploitation evidence, and its reach is limited to one internal subnet. Schedule it, and meanwhile confirm that the test server truly is unreachable from elsewhere. Finding C, the browsers, will usually be fixed by automatic updates within days; confirm they are working rather than spending a change slot. D and F go into normal patch cycles.

Write the reasoning down. An auditor who asks why a 9.8 waited while a 7.5 jumped the queue should get a one-paragraph answer naming KEV status, exposure and asset value. That written record is part of vulnerability management, and Lesson 23 builds the full process around it.

Where threat intelligence comes from

Threat intelligence is information about adversaries and their methods, processed so defenders can act on it. A threat feed is a stream of it, often machine-readable lists of indicators such as malicious IP addresses, domains and file hashes. The sources differ in cost and quality:

Raw feeds are not intelligence until someone turns them into decisions. The US intelligence community describes a six-step cycle that security teams borrow: planning (what decisions need support?), collection, processing (organizing raw data), analysis, dissemination to the people who act, and evaluation of whether the product was relevant, accurate and timely. Skipping the first step is the classic failure: a team subscribes to every feed, drowns in indicators, and still cannot say which threats matter to its own business.

Log4Shell: when the score was right and the hard part was elsewhere

Log4Shell had every warning sign at once. It was disclosed on 9 December 2021. CISA added it to KEV on 10 December with a remediation due date of 24 December for federal agencies. Its CVSS score was 10.0. The US Cyber Safety Review Board's report of July 2022 recorded that, five days after disclosure, Cloudflare was seeing 400 exploitation attempts per second.

Prioritization was not the problem. Finding it was. Log4j is a library built into thousands of other products, and the Board noted that there was no comprehensive list of where it was integrated, so enterprises and vendors scrambled to discover where they used it. One federal cabinet department reported dedicating 33,000 hours to its response. Among the Board's recommendations were the capacity to maintain an accurate IT asset and application inventory, and better software bill of materials (SBOM) tooling. The Board called Log4j an endemic vulnerability that will remain in systems for years, perhaps a decade or longer.

Worth holding on to: intelligence tells you what to fix; only an inventory tells you where it is.

Common misconceptions

• "Patch in order of CVSS score." The base score ignores whether a flaw is being exploited and how exposed and valuable your system is. Combine it with KEV, EPSS and your environment.
• "A CVE and a CWE are the same thing." A CVE is one specific vulnerability in specific products. A CWE is a category of weakness, such as SQL injection, that many CVEs share.
• "Proof-of-concept code means a flaw is in KEV." KEV requires reliable evidence of exploitation in the wild. Published exploit code, research and scanning do not qualify on their own.
• "An EPSS score of 0.3 means a severity of 3." EPSS is a probability of exploitation within 30 days, not a severity rating.
• "More feeds mean better intelligence." Without planning and analysis, feeds become noise. Intelligence starts with the decisions it must support.

What to remember

• CVE IDs name specific vulnerabilities; CWE names weakness types; the NVD adds scores and affected products.
• A CVSS vector shows attack vector, complexity, privileges, user interaction, scope and impact; CVSS 4.0 adds Threat, Environmental and Supplemental groups.
• Risk combines likelihood and impact. KEV lists exploited vulnerabilities; EPSS estimates the 30-day chance of exploitation; your exposure and asset value complete the picture.
• BOD 26-04 (June 2026) replaced BOD 22-01 for federal agencies, prioritizing by exposure, KEV status, automatable exploitation and impact.
• Intelligence sources: OSINT, proprietary feeds, ISACs and government sharing, the dark web and internal data, run through a planning-to-evaluation cycle.
• Log4Shell shows that prioritization is useless without an inventory that says where the vulnerable software runs.

Sources

1. National Institute of Standards and Technology. (2021). CVE-2021-44228 detail (published December 10, 2021, and since updated). National Vulnerability Database. nvd.nist.gov
2. FIRST. (2023, revised 2024). Common Vulnerability Scoring System version 4.0: Specification document. Forum of Incident Response and Security Teams. first.org
3. FIRST. (n.d.). Exploit Prediction Scoring System (EPSS). first.org
4. Cybersecurity and Infrastructure Security Agency. (n.d.). Known exploited vulnerabilities catalog. cisa.gov
5. Cybersecurity and Infrastructure Security Agency. (2026, June 10). BOD 26-04: Prioritizing security updates based on risk. cisa.gov
6. CVE Program. (n.d.). Overview. cve.org
7. MITRE. (2025). 2025 CWE Top 25 most dangerous software weaknesses. cwe.mitre.org
8. Cybersecurity and Infrastructure Security Agency. (n.d.). Automated Indicator Sharing (AIS). cisa.gov
9. Office of the Director of National Intelligence. (n.d.). How the IC works [The intelligence cycle]. intelligence.gov
10. Cyber Safety Review Board. (2022, July 11). Review of the December 2021 Log4j event. US Department of Homeland Security. cisa.gov (PDF)

A text from "IT", August 2022

In early August 2022, employees of Twilio, a company that sends text messages and phone calls for other businesses, began receiving texts that appeared to come from their own IT department. The messages said a password had expired or a schedule had changed, and offered a link to fix it. The links led to convincing copies of the company's sign-in page, at addresses containing words like Twilio, Okta and SSO. Some employees entered their credentials.

On 4 August Twilio became aware of unauthorized access to its internal systems. Its final report, published on 27 October 2022, said the attackers had accessed data belonging to 209 customers, out of a customer base of more than 270,000, and 93 users of its Authy authentication app, out of roughly 75 million. Among its fixes, Twilio said it distributed FIDO2 security keys to all employees.

Notice what the attackers did not need. No software vulnerability, no malware, no clever exploit. They needed a phone number, a believable message and a fake page, and they reached the right people at the right moment. That is social engineering: manipulating people into doing something that serves the attacker, such as revealing a password, approving a request or running a program.

Exam objectives: SY0-801 2.3 for message-, image-, attachment- and human-based vectors, and the social engineering attacks in 2.5. On SY0-701 these sit in 2.2 (human vectors, including business email compromise, pretexting, typosquatting, brand impersonation, misinformation and disinformation) and 2.4.

Why people, not machines

Social engineering works on predictable human responses. Authority makes people comply with someone who seems to be IT, a manager or a government official. Urgency, such as an expiring password or an overdue invoice, cuts thinking short. Familiarity lowers suspicion, which is why messages borrow real names, logos and projects.

The scale is large. In its 2024 report, the FBI's Internet Crime Complaint Center received 859,532 complaints, with reported losses of 16.6 billion dollars. Phishing and spoofing was the most reported crime type, with 193,407 complaints. Business email compromise produced 21,442 complaints and about 2.77 billion dollars in reported losses, second only to investment fraud.

So what?: the attacker's cheapest route into most organizations runs through a person, so defenses must work even when a person is fooled.

Message-based vectors

A threat vector is the path an attack takes to reach its target. SY0-801 groups the messaging paths together, and each has its own attack name:

The last row is not hypothetical. In May 2024 Microsoft described a financially motivated group, Storm-1811, which deploys Black Basta ransomware. It flooded targets' inboxes by signing them up to many mailing lists, then contacted them offering to help with the spam: by phone, and later through Microsoft Teams from accounts named things like "Help Desk" and "IT Support". Once trusted, the caller persuaded the user to grant remote access through Quick Assist, Windows' built-in support tool.

RCS, the richer successor to SMS, and chat apps have not changed the technique; they have only added places for the same messages to arrive. The FBI warned in May 2025 that, since April of that year, attackers had impersonated senior US officials with texts and AI-generated voice messages to build rapport. They then sent links supposedly moving the conversation to another messaging app.

The phishing family, and its relatives

The exam tests the differences between closely related names. Learn them as a set:

• Phishing: broad messages to many people, hoping some respond.
• Spear phishing: a message crafted for a specific person or group, using details about them.
• Whaling: spear phishing aimed at senior executives, whose authority makes the payoff larger.
• Smishing by text, vishing by voice, and quishing by QR code.
• Impersonation: pretending to be a specific trusted person or role. Brand impersonation borrows a company's logos and style.
• Pretexting: inventing a believable scenario, such as an audit, a delivery problem or a locked account, to justify an unusual request.
• Business email compromise (BEC): using a real or convincingly faked business email account, often an executive's or a supplier's, to redirect payments or obtain sensitive data.
• Typosquatting: registering lookalike domains, such as a letter swapped or added, to catch typing mistakes and fool readers.
• Watering hole: compromising a website the target group already visits, rather than luring them to a new one.
• Misinformation and disinformation: false information, spread innocently or deliberately, which can drive people toward malicious sites or harmful decisions.
• Deepfake: AI-generated audio, video or images that imitate a real person.

The point: name the attack by its channel and its target. Text means smishing, voice means vishing, QR means quishing, a chosen person means spear phishing, and an executive target means whaling.

Image-based vectors

Images can carry attacks that text filters miss:

• QR codes hide the destination address until it is opened, and they are usually scanned on a phone, away from corporate web filtering. A sticker over a real parking meter's code is a classic quishing setup.
• Embedded content such as remote images can confirm that a message was opened, and text placed inside an image can slip past filters that only read text.
• CAPTCHA checks, the "prove you are human" boxes, are now imitated as bait. In the technique researchers call ClickFix, which SentinelOne described in May 2025, a fake check tells the visitor to press the Windows key and R, paste, and press Enter. Pasting runs a command the page has already copied to the clipboard. The trick works because people click through such checks quickly and without scrutiny.

Attachment-based vectors

Attachments remain a common delivery route. Office documents with embedded macros, small programs written in Visual Basic for Applications, were a favorite for years. Microsoft's documentation says macros are a common way for malicious actors to deploy malware and ransomware. It changed Office so that macros in files from the internet are blocked by default. Windows marks downloaded files and email attachments with a "Mark of the Web", and Office shows a security-risk banner instead of an Enable Content button.

Rich Text Format (RTF) documents and PDFs are also listed. Both can carry links and embedded objects, and malformed files have been used to exploit flaws in the programs that open them. The defense pattern is the same for all three: keep the opening software patched, block active content by default, and treat an unexpected attachment as a question, not an instruction.

Human-based vectors

Some vectors are people in person. A contractor or visitor may be given physical access and use it to plug in a device or read screens. Impersonation covers the person who arrives in a delivery uniform or calls as the CEO's assistant. A watering hole works on people's habits rather than their inboxes. And biometric vectors aim at the identifiers people carry: a cloned voice to pass a voice check, a manipulated face image, or a person pressured to unlock a device with a fingerprint.

Deepfakes have made the voice route cheap. The FBI's May 2025 warning advised verifying a caller by finding their number independently and calling back, checking addresses and numbers for small differences, being skeptical of familiar-sounding voices, and agreeing a secret word with family members.

Defenses that hold when a person is fooled

Training helps, and Lesson 35 examines how much. But the strongest defenses assume someone will eventually click:

Twilio's own fix illustrates the first row. A FIDO2 key checks the real address of the site it is signing in to, so a key will not complete a sign-in on a lookalike domain, however convincing the page.

Remember: design processes so that a fooled person cannot complete the attack alone. Phishing-resistant MFA and out-of-band verification do that.

Common misconceptions

• "Only careless people fall for phishing." Well-crafted messages use real names, timing and urgency. Twilio's attackers deceived employees of a technology company that runs messaging for others.
• "Any MFA stops phishing." CISA notes that codes sent by SMS or apps can be phished, and push prompts can be bombed until someone accepts. Only phishing-resistant MFA, such as FIDO/WebAuthn, resists it.
• "A familiar voice proves who is calling." AI voice cloning can be nearly indistinguishable, as the FBI warned in 2025. Verify through a channel you already trust.
• "QR codes are safe because they are just pictures." A QR code is a link with its address hidden until opened, scanned on a device that often has no corporate protection.
• "Spear phishing and whaling are the same." Both are targeted; whaling specifically targets senior executives.

Pulling it together

• Social engineering manipulates people with authority, urgency and familiarity; phishing is the most reported cybercrime to the FBI, and BEC cost about 2.77 billion dollars in 2024.
• Message vectors: email, SMS and RCS, voice, instant messaging and collaboration tools such as Teams.
• Attack names: phishing, spear phishing, whaling, smishing, vishing, quishing, impersonation, pretexting, BEC, typosquatting, watering hole, misinformation, deepfake.
• Image vectors include QR codes, embedded content and fake CAPTCHAs; attachment vectors include macros, RTF and PDF files, with internet macros blocked by default in Office.
• Human vectors include contractors, visitors, impersonators, biometric spoofing and watering holes.
• Phishing-resistant MFA, out-of-band verification, help-desk checks, macro blocking, email authentication and fast reporting hold even when a person is fooled.

Sources

1. Twilio. (2022, October 27, updated from August 2022). Incident report: Employee and customer account compromise. Twilio blog. twilio.com
2. Federal Bureau of Investigation, Internet Crime Complaint Center. (2025). Internet crime report 2024. ic3.gov (PDF)
3. Federal Bureau of Investigation. (2025, May 15). Senior US officials impersonated in malicious messaging campaign (Alert I-051525-PSA). ic3.gov
4. Microsoft Threat Intelligence. (2024, May 15). Threat actors misusing Quick Assist in social engineering attacks leading to ransomware. Microsoft Security Blog. microsoft.com
5. Microsoft. (2026). Macros from the internet are blocked by default in Office. Microsoft Learn. learn.microsoft.com
6. Murphy, M. B. (2025, May 22). Caught in the CAPTCHA: How ClickFix is weaponizing verification fatigue to deliver RATs and infostealers. SentinelOne. sentinelone.com
7. Cybersecurity and Infrastructure Security Agency. (2022, October). Implementing phishing-resistant MFA [Fact sheet]. cisa.gov (PDF)
8. Kucherawy, M. (2019). Message header field for indicating message authentication status (RFC 8601). RFC Editor. rfc-editor.org

Two updates, eighteen months apart

In December 2020, CISA reported that an advanced persistent threat actor had compromised SolarWinds' Orion platform, network-management software used by government agencies and companies. Beginning in at least March 2020, the actor had inserted a malicious file into the software's build process. The file was then signed with SolarWinds' own legitimate code-signing certificate, and customers installed it as a trusted update. CISA called the actor patient, well-resourced and focused.

In July 2021, ransomware spread through Kaseya VSA, remote monitoring software that managed service providers (MSPs) use to run their customers' computers. CISA and the FBI described a vulnerability in on-premises VSA servers being exploited, and the ransomware reached both the MSPs and their downstream customers.

Neither attack started at the victims' own front doors. Both arrived through software the victims trusted and had chosen to install. Lesson 9 covered the vectors that work on people. This lesson maps the technical ones: the browser, the network, remote access, endpoints, suppliers, removable media, smart devices, industrial systems, physical entry and radio signals.

Exam objectives: SY0-801 2.3, all vector families except the message, image, attachment and human ones covered in Lesson 9. On SY0-701 these are in 2.2, which also names unsecure wired and wireless networks, open service ports, default credentials, client-based versus agentless software, and unsupported systems.

The vectors, side by side

Read across any row and the pattern is the same: an attack surface, a way the attacker reaches it, and a control that removes or narrows it. The attack surface is the sum of every point where an attacker could try to get in or get data out. Each row below is a slice of it.

The browser: where your sessions live

The browser holds more trust than most people realize. Once you sign in, the site gives your browser a session token, usually stored as a cookie, that proves you already authenticated. MITRE ATT&CK describes what happens when one is stolen, in a technique it calls Web Session Cookie. The adversary imports the cookie into a browser it controls and uses the site as you until the session expires. The technique bypasses some multifactor authentication, because the session has already passed MFA. Information-stealing malware targets exactly these cookies, along with passwords saved in the browser.

Browser extensions are the other browser risk. An extension with permission to read and change data on all websites can see everything you see, so a malicious extension, or a legitimate one whose developer account is hijacked and pushes a bad update, becomes a spy in every tab. JavaScript on a compromised site runs in your browser too. Defenses include letting staff install only approved extensions, shortening session lifetimes for sensitive applications, and binding sessions to the device where possible.

Remote access and the network itself

Remote access services are designed to let outsiders in, which is why attackers try them first. CISA's #StopRansomware Guide tells organizations not to expose services such as the remote desktop protocol on the web. The hacktivists you met in Lesson 7 reached water-plant screens over VNC with default passwords. And VPN gateways, the usual answer to "how do staff connect from home", are themselves internet-facing devices whose flaws attackers hunt, as Lesson 18 shows.

The network's own components are a vector as well. Infrastructure devices such as routers, switches and firewalls run software with vulnerabilities, often patched less often than servers. Virtualized devices, such as virtual firewalls and appliances, inherit the same flaws plus those of their hypervisor. Session keys that are weak, reused or exposed let an attacker read or hijack traffic. SY0-701 also listed unsecure networks: open Wi-Fi, unprotected wired ports in public areas, and Bluetooth left discoverable.

In short: anything that accepts connections from outside is a door. Count the doors, close the ones you do not need, and put MFA and patching on the rest.

Endpoints, and living off the land

Every phone, tablet, laptop and server is an endpoint, and each is a vector when unpatched or misconfigured. Trusted devices, the ones a system lets in with fewer checks, are especially valuable to steal or impersonate.

The subtler endpoint vector is the endpoint's own tooling. In February 2024, CISA, NSA, FBI and partner agencies in Australia, Canada, the UK and New Zealand published joint guidance on living off the land (LOTL): attackers using legitimate tools already present on systems, such as PowerShell and Windows Management Instrumentation, instead of bringing malware. The guidance notes that the technique continues to work with little or no investment in tooling. It also notes that defenders struggle to tell malicious activity from legitimate administration. Volt Typhoon, from Lesson 7, relied on it.

SY0-701 framed a related choice as client-based versus agentless software. A client-based tool installs software on every endpoint, which adds code that must be patched and could be exploited. An agentless tool reaches endpoints remotely instead, which avoids that code but requires remote access credentials and network paths that must themselves be protected.

Key idea: when attackers use your own tools, antivirus has nothing foreign to find. Detection depends on logging how admin tools are used and noticing use that does not fit the baseline.

The supply chain: trust you inherited

A supply chain vector abuses the trust an organization places in its suppliers. SY0-801 names four kinds: third-party providers in general, MSPs, logistics providers, and software-as-a-service (SaaS) providers. The two opening stories show two shapes:

• Compromised software. At SolarWinds, the attacker changed the product before it shipped. Signing did not help, because the malicious file was signed with the vendor's real certificate. Customers who did everything right, installing vendor updates promptly, installed the backdoor.
• Compromised access. At Kaseya, the tool MSPs used to manage customers became the delivery route to those customers. CISA's guidance to MSP customers afterward included keeping MSP accounts out of administrator groups and limiting them to the systems they manage. It also advised enabling MFA on every account, and requiring monitoring, logging and incident notification in MSP contracts.

Lesson 32 covers how to assess and contract with suppliers. For now, notice the core defensive idea: give each supplier only the access its job needs, watch what it does with that access, and plan for the day it is compromised.

Media, smart devices, industrial systems, doors and radios

Malicious USB devices range from ordinary drives carrying infected files to devices that pretend to be keyboards and type commands. ATT&CK's entry on replication through removable media notes they can carry malware onto disconnected or air-gapped networks. Its listed mitigations include blocking untrusted executables from running off USB drives, turning off Autorun, and restricting removable media where the business does not need it.

IoT devices such as cameras, sensors and printers are computers that people forget are computers. They often ship with default passwords and receive few updates. OT, the operational technology that runs physical processes, adds safety consequences, as the water-plant intrusions showed. Physical vectors (locks, access vestibules and access passes) matter because physical access defeats many logical controls; Lesson 14 covers the attacks against them.

Signal-based vectors need the attacker nearby. NIST's guide to Bluetooth security, SP 800-121, exists because Bluetooth creates small networks between devices, and those networks need configuring like any other. Radio frequency more broadly covers wireless keyboards, key fobs and building systems. NFC powers tap-to-pay and many badges, so cards and phones can be read at close range. The defense is the same in every case: turn off radios you are not using, and do not accept pairing or connections you did not start.

Common misconceptions

• "Signed software is safe software." The SolarWinds backdoor was signed with the vendor's legitimate certificate. A signature proves who shipped the code, not that the code is benign.
• "MFA protects an account after login." A stolen session cookie represents a login that already passed MFA, so replaying it can bypass the challenge.
• "No malware found means no intruder." Living-off-the-land attackers use built-in tools and leave few conventional indicators of compromise.
• "Our MSP's security is the MSP's problem." The MSP's tools and accounts reach into your network, so their compromise is yours. Limit and monitor their access.
• "A printer or camera is not worth attacking." Smart devices with default passwords are easy footholds and can be enlisted in larger attacks.

Recap

• Technical vectors: browser, network, remote access, endpoint, supply chain, external media, IoT, OT, physical and signal-based.
• Stolen session cookies and tokens can bypass MFA; extensions see every page you visit.
• Remote access services, network devices and VPN gateways face the internet and attract attackers first.
• Living off the land uses built-in tools, so detection depends on logging and baselines.
• Supply chain attacks arrive through trusted software or supplier access; SolarWinds and Kaseya show both shapes.
• USB devices, smart devices, industrial systems, doors and radios each need their own controls.

Sources

1. Cybersecurity and Infrastructure Security Agency. (2020, December 17; revised 2021, April 15). Advanced persistent threat compromise of government agencies, critical infrastructure, and private sector organizations (AA20-352A). cisa.gov
2. Cybersecurity and Infrastructure Security Agency. (2021, July 12). Kaseya ransomware attack: Guidance for affected MSPs and their customers. cisa.gov
3. CISA, NSA, FBI, and partners. (2024, February 7). Identifying and mitigating living off the land techniques [Joint guidance]. cisa.gov
4. MITRE. (n.d.). Use alternate authentication material: Web session cookie (T1550.004). MITRE ATT&CK. attack.mitre.org
5. MITRE. (n.d.). Replication through removable media (T1091). MITRE ATT&CK. attack.mitre.org
6. Padgette, J., Bahr, J., Batra, M., Holtmann, M., Smithbey, R., Chen, L., and Scarfone, K. (2017, updated 2022). Guide to Bluetooth security (NIST SP 800-121 Rev. 2). National Institute of Standards and Technology. csrc.nist.gov
7. Cybersecurity and Infrastructure Security Agency, and MS-ISAC. (2023). #StopRansomware guide (Version 3.0). cisa.gov

A pull request marked "looks fine"

On Friday 29 March 2024, Andres Freund posted a message to the oss-security mailing list under the subject "backdoor in upstream xz/liblzma leading to ssh server compromise". He had noticed SSH logins on test systems using a lot of CPU and producing errors in a debugging tool. Tracing them led him to malicious code in versions 5.6.0 and 5.6.1 of XZ Utils, a compression library present on many Linux systems. Part of the backdoor existed only in the published release files, not in the source code that reviewers usually read. CISA issued an alert the same day.

That incident sits at the end of this lesson, because it is the one kind of application flaw that careful code review in your own team cannot catch. First comes the kind it can. Imagine a small change to an internal order-lookup service. The reviewer's comment reads: looks fine, it is internal only, and every function has error handling. That comment is the plausible wrong answer this lesson debugs. The change contains six flaws. You will find each one, see why it matters, and fix it.

Exam objectives: SY0-801 2.4, application and code vulnerabilities: race conditions (time-of-check and time-of-use), malicious updates, hardcoded secrets and unsafe exception handling. On SY0-701 this is part of 2.3, which also names memory injection, buffer overflows, SQL injection and cross-site scripting, all covered here.

Flaw 1: building SQL by gluing strings together

The first function looks up an order by its ID:

def get_order(conn, order_id):
    sql = "SELECT * FROM orders WHERE id = '" + order_id + "'"
    return conn.execute(sql).fetchall()

The input is pasted directly into the text of the query, so the database cannot tell where the programmer's SQL ends and the user's data begins. Input containing quote marks and SQL keywords can change what the query does. That is SQL injection, CWE-89, second on MITRE's 2025 list of the most dangerous software weaknesses.

You can see the root cause without attacking anything. When this lesson was written, a test in Python's built-in sqlite3 module looked up a customer named O'Brien with a query built the same way. The apostrophe ended the string early, and the database replied OperationalError: near "Brien": syntax error. An honest customer's name broke the query, which means the input was being treated as code.

The fix is a parameterized query, which sends the SQL and the data separately:

def get_order(conn, order_id):
    sql = "SELECT * FROM orders WHERE id = ?"
    return conn.execute(sql, (order_id,)).fetchall()

Run the same lookup with parameters and O'Brien's record comes back normally. OWASP's prevention guidance puts prepared statements with parameterized queries first among its defenses. In March 2024, CISA and the FBI issued a Secure by Design alert urging software makers to eliminate SQL injection entirely. They noted that SQL injection in a managed file transfer product had recently hit thousands of organizations.

Key idea: never build queries by concatenating input. Parameterize, so data can never become code.

Flaw 2: a password in the source code

The configuration file contains this:

DB_USER = "orders_app"
DB_PASSWORD = "Winter-Orders-2026"

This is a hardcoded secret, CWE-798, use of hard-coded credentials. Everyone who can read the code can read the password: every developer, every contractor, every backup of the repository, and anyone who obtains a copy. Worse, version control remembers. Deleting the line in a later commit does not remove it from the history, so a leaked secret must be revoked and replaced, not just deleted.

The fix is to keep secrets out of code entirely: read them at run time from the environment or, better, from a secrets manager with access control and audit logs. OWASP's secrets management guidance covers both. Add secrets scanning to the repository so that a key committed by mistake is caught before it spreads; Lesson 22 returns to it.

Flaw 3: error handling that helps the attacker

The reviewer was reassured by the error handling. Look closer:

def is_admin(user):
    try:
        return directory.lookup(user).role == "admin"
    except Exception as err:
        log.warning(err)
        return True

If the directory is slow or unreachable, the function grants administrator rights to everyone. It fails open. Elsewhere in the change, another handler returns the raw error to the user: "Database error: " followed by the exception text, which includes table names and file paths. CWE-209 names this second problem: error messages that contain sensitive information.

Both are unsafe exception handling. OWASP's error handling guidance recommends showing users a generic message and logging the details server-side. The authorization check should fail closed: when in doubt, deny. Error handling everywhere is not the same as safe error handling.

The upshot: when something goes wrong, a secure program denies access and reveals nothing useful; the details go to the logs, not the screen.

Flaw 4: checking, then using

A helper writes an export file only if the user is allowed to:

if os.access(path, os.W_OK):
    with open(path, "w") as f:
        f.write(report)

Python's own documentation warns about exactly this pattern. Using access() to check permission before calling open() creates a security hole, it says, because a user might exploit the short interval between the check and the open to manipulate the file. This is a race condition: a time-of-check (TOC) and a separate time-of-use (TOU), with the attacker racing to change things in between, for example by replacing the file with a link to something sensitive. CWE-367 catalogs it.

The documentation's fix is to skip the separate check: try the operation directly and handle the permission error if it fails, so the check and the use become one step. The same principle applies in any language. Make the operation atomic, or recheck after acquiring the resource.

Flaw 5: sixteen bytes and no limit

A small component written in C saves a display name:

void save_name(const char *input) {
    char name[16];
    strcpy(name, input);
}

strcpy copies until it reaches the end of the input, however long that is. Input longer than fifteen characters writes past the end of the 16-byte array into neighboring memory: a buffer overflow, recorded as CWE-787, out-of-bounds write, fifth on the 2025 list. Overwritten memory can crash the program, or, when an attacker controls what is written, change what the program does next. When the attacker's own data ends up being run as instructions, that is memory injection.

Fixes come at two levels. In the code, check lengths and use bounded functions. In the language, avoid the whole class: CISA's December 2023 guidance, The Case for Memory Safe Roadmaps, urges software makers to move to memory safe languages and publish roadmaps for doing so.

Worth holding on to: memory errors come from code that trusts input lengths; bounds checks fix one bug, and memory safe languages remove the class.

Flaw 6: echoing input into a web page

The search page shows what the user searched for:

return "<p>Results for " + query + "</p>"

If the query contains HTML or script, the browser runs it as part of the page. That is cross-site scripting (XSS), CWE-79, first on MITRE's 2025 list. A script running in the page acts with the user's session, so it can read data or perform actions as that user. The fix is to encode output for the place it lands. In HTML text, characters such as the angle brackets become harmless entities. OWASP's cross-site scripting prevention guidance describes encoding for each context.

Notice the pattern across flaws 1 and 6. Both mix data with code: SQL in one case, HTML and script in the other. Both are fixed by keeping data and code apart, with parameters for the database and encoding for the browser.

The flaw no code review catches: a malicious update

Every flaw above was in code your team wrote, and a careful review could catch it. The XZ Utils backdoor was different. It arrived in official releases of a trusted dependency. Part of it was hidden in release files rather than in the visible source repository, and it was discovered by one engineer chasing a performance oddity.

A malicious update is a legitimate-looking update that carries attacker code, whether a compromised maintainer, a hijacked account or a poisoned build process put it there. Lesson 10's SolarWinds case was one at vendor scale. Defenses sit around the update rather than inside your code. Know exactly which versions of which components you run, ideally from a software bill of materials. Pin versions and adopt updates deliberately, through change management, rather than automatically everywhere at once. Verify signatures and checksums. Watch advisories. CISA's response to XZ shows the reaction: downgrade to an uncompromised version, such as 5.4.6, and hunt for signs of malicious activity.

Common misconceptions

• "Internal applications do not need secure coding." Internal systems are reached by phished accounts and compromised devices. Injection behind the firewall is still injection.
• "Escaping or stripping quotes fixes SQL injection." Filtering input is brittle and easy to get wrong. Parameterized queries separate code from data by design.
• "Deleting a committed secret makes it safe." It remains in the repository history and in every copy. Revoke and replace it.
• "Every exception is handled, so the code is safe." Handlers that fail open or print internal details create vulnerabilities of their own.
• "Updating promptly always improves security." Usually, but a malicious update is exactly what prompt automatic updating spreads. Pair speed with version control, verification and staged rollout.

What to carry forward

• Injection (CWE-89) and cross-site scripting (CWE-79) mix data with code; fix them with parameterized queries and context-aware output encoding.
• Hardcoded secrets (CWE-798) live forever in history; keep secrets in a secrets manager and scan repositories.
• Unsafe exception handling fails open or leaks details (CWE-209); fail closed and keep details in logs.
• Time-of-check to time-of-use races (CWE-367) exploit the gap between checking and using; make the operation atomic.
• Buffer overflows and memory injection (CWE-787) come from unchecked lengths; bound every copy and prefer memory safe languages.
• Malicious updates such as XZ Utils 5.6.0 and 5.6.1 arrive through trust; inventory, pin, verify and stage updates.

Sources

1. Freund, A. (2024, March 29). backdoor in upstream xz/liblzma leading to ssh server compromise. oss-security mailing list. openwall.com
2. Cybersecurity and Infrastructure Security Agency. (2024, March 29). Reported supply chain compromise affecting XZ Utils data compression library, CVE-2024-3094. cisa.gov
3. MITRE. (2025). 2025 CWE Top 25 most dangerous software weaknesses. cwe.mitre.org
4. OWASP Foundation. (n.d.). SQL injection prevention cheat sheet. OWASP Cheat Sheet Series. owasp.org
5. CISA and FBI. (2024, March 25). Secure by design alert: Eliminating SQL injection vulnerabilities in software. cisa.gov
6. Python Software Foundation. (n.d.). os: Miscellaneous operating system interfaces (note on os.access). Python 3 documentation. docs.python.org
7. OWASP Foundation. (n.d.). Error handling cheat sheet and Secrets management cheat sheet. OWASP Cheat Sheet Series. owasp.org
8. Cybersecurity and Infrastructure Security Agency. (2023, December 6). The case for memory safe roadmaps. cisa.gov
9. OWASP Foundation. (n.d.). Cross site scripting prevention cheat sheet. OWASP Cheat Sheet Series. owasp.org

Monday of week one: the inventory comes back

You start as the IT and security administrator at a 120-person engineering firm. Your predecessor left no documentation, so on your first Monday you run an inventory of everything you can find on the network and in the company's cloud accounts. By Friday you have this list:

None of these needed an attacker to create it. Each grew out of normal work: a purchase never replaced, a test never cleaned up, a leaver never removed, a shortcut never reversed. This lesson names each type the way the exam does, explains why it matters, and ends with the order you would fix them in.

Exam objectives: SY0-801 2.4, the remaining types after Lesson 11's code flaws: unsupported, unpatched, obsolete and unmanaged systems; ports and services; OS-based and virtualization weaknesses; zero-days; cryptographic vulnerabilities; stale credentials; rogue devices; shadow IT; wireless and low-powered communications; identity providers; mobile devices; misconfiguration; public repositories and public object storage. Large language models, also listed, are Lesson 16's subject. On SY0-701 the matching objective is 2.3, which also names hardware (firmware, end-of-life, legacy), VM escape, resource reuse, side loading and jailbreaking.

Systems nobody is maintaining

Findings 1, 2 and 3 are versions of the same problem: software that is not receiving security fixes.

• An unsupported product no longer gets updates from its maker. Microsoft's own page puts it plainly: support for Windows 10 ended on 14 October 2025, and Microsoft no longer provides software updates, security fixes or technical assistance for it. Consumers who enroll in Extended Security Updates keep receiving critical and important fixes for a limited period; finding 1's PC is not enrolled.
• An unpatched system could be fixed but has not been. An obsolete or legacy system, like finding 2's discontinued storage box, is old enough that patches, parts and expertise are disappearing; SY0-701 grouped such problems under hardware, including outdated firmware and end-of-life devices.
• An unmanaged system, like finding 3's forgotten cloud VM, is outside every process: no owner, no patching, no monitoring, no backups. Unmanaged systems are where attackers like to live, because nobody is looking.

The remedies run in order of preference: replace or upgrade, isolate what cannot yet be replaced (Lesson 3's compensating controls), and decommission what nobody needs. Every system should have a named owner, which Lesson 23's asset management makes routine.

The point: a system without an owner and without updates is a vulnerability whatever software it runs.

Credentials nobody removed, and the identity provider that trusts them

Finding 4 is the one attackers would thank you for. Unmanaged or stale credentials are accounts and secrets that outlived their purpose: leavers' accounts, old service accounts, API keys from finished projects. They work, nobody watches them, and their owners will not notice them being used.

The 2024 Snowflake data thefts show the cost. In June 2024, Mandiant reported that a group it tracks as UNC5537 had used stolen credentials to access Snowflake customer accounts. Mandiant and Snowflake notified about 165 potentially exposed organizations. Mandiant found no evidence that Snowflake's own environment had been breached. Instead, three factors on the customer side made the campaign work: the affected accounts did not have MFA, the credentials had been stolen by malware years earlier and never rotated, some since 2020, and the accounts did not restrict sign-ins to trusted networks.

The identity provider (IdP), the system that signs users in and vouches for them to other applications, raises the stakes further. When dozens of applications trust one IdP, a weakness in it, or a stolen signing key as in Lesson 6's Storm-0558 case, opens all of them at once.

Key idea: remove access when it is no longer needed, rotate secrets, require MFA, and protect the identity provider as the single most valuable system you run.

Configuration: the vulnerabilities you set yourself

In October 2023, NSA and CISA published the ten misconfigurations their red and blue teams found most often in large organizations. The list begins with software and applications left in their default settings, and continues: privileges not properly separated, inadequate internal monitoring, missing segmentation, weak patch management, access controls that can be bypassed, weak or misconfigured MFA, overly permissive access lists on network shares, poor credential hygiene and unrestricted code execution. Nothing on it requires a clever attacker to create.

Finding 5 is the cloud's signature misconfiguration: public object storage. Amazon's S3 documentation says new buckets, access points and objects do not allow public access by default, but users can change policies to allow it. The S3 Block Public Access settings exist to override such mistakes, and Amazon recommends turning all four on for the account. Someone loosened a policy to share files with a partner and opened them to everyone. The fix is to block public access and grant the partner specific, authenticated access.

Finding 8 is the repository version. Public repositories leak secrets, internal hostnames and architecture details. Everything committed to a public repository should be assumed copied the moment it was pushed.

Ports and services belong here too. Every service listening on a network port is code that can be attacked, so each unnecessary one is attack surface with no benefit. Lesson 10's lab listed yours; the rule is to disable what is not needed and restrict who can reach the rest.

Devices that arrived without permission

Finding 6 is a rogue device, which NIST's testing guide defines simply as an unauthorized node on a network. A consumer access point plugged into a wall port can extend the internal network to anyone in range of its signal, bypassing every control at the building's entrance. It is also shadow IT: technology adopted without IT's knowledge, not out of malice but to get work done, and therefore outside patching, monitoring and configuration standards.

Wireless brings its own category: wireless and low-powered communications. Wi-Fi with outdated security, Bluetooth and low-power radios in sensors and smart devices often favor easy pairing over strong authentication, and their firmware is rarely updated.

Phones, virtualization and the operating system underneath

Finding 7 is a mobile device weakness. NIST SP 800-124, the government's guide to managing mobile devices, notes that some users sideload applications onto their devices by allowing installation from untrusted or unknown sources. It advises treating unknown third-party apps as untrusted. Jailbreaking or rooting, it explains, bypasses the device's built-in restrictions on security and other functions. Its recommended controls include restricting which app stores may be used, restricting sideloading, and limiting access for rooted or jailbroken devices through mobile device management.

Virtualization adds weaknesses that physical machines do not have. In a VM escape, code running inside a virtual machine breaks out to the hypervisor that hosts it, and from there can reach every other VM on that host. Resource reuse is the quieter risk: memory or storage released by one virtual machine or cloud tenant handed to another without being cleared. Both are reasons why hypervisors must be patched as urgently as any internet-facing system.

OS-based vulnerabilities, flaws in the operating system itself, sit under everything else, which is why operating system updates come first in any patch plan.

Two kinds of unknown: zero-days and weak cryptography

A zero-day is, in NIST's glossary wording, an attack that exploits a previously unknown hardware, firmware or software vulnerability. By definition there is no patch on the day it is first used, so defenses are general rather than specific: segmentation that limits how far an attacker can move, least privilege, monitoring for unusual behavior, and quick response when the vendor does publish a fix.

Cryptographic vulnerabilities are weaknesses in how cryptography is chosen or used: retired algorithms such as SHA-1 or 3DES, keys that are too short, poor key storage, or certificates left to expire. Lessons 5 and 6 covered the correct choices; an inventory should flag every system still using the incorrect ones.

Fixing week one, in order

Apply Lesson 8's thinking, likelihood and impact, to the eight findings:

1. Finding 4, the leavers' accounts, especially the three with VPN access: disable them today. Stolen or guessed credentials on exposed remote access are a direct route in, as the Snowflake case showed.
2. Finding 5, the public bucket: block public access now, then work out what was exposed and for how long.
3. Finding 6, the rogue access point: remove it and give the drafting team proper coverage.
4. Finding 1, the payroll PC: enroll it in extended updates as a stopgap, isolate it, and schedule its replacement.
5. Findings 3 and 2: decommission test-old if nobody claims it, and replace or isolate the storage box.
6. Findings 7 and 8: enroll company phones in device management with a sideloading policy, and ask the former intern to remove the repository; then treat the hostnames as public.

Your order may differ by a place or two, and that is fine if you can justify it. What matters is that you can say why each item sits where it does.

Common misconceptions

• "If it still works, it is still safe." An unsupported system works perfectly while collecting vulnerabilities that will never be fixed.
• "The Snowflake breach was a Snowflake hack." Mandiant found no breach of Snowflake's environment; stolen customer credentials without MFA, never rotated, did the work.
• "Cloud storage is private unless you make it public on purpose." Defaults are private, but one loosened policy can expose a bucket to everyone. Block Public Access exists for exactly that mistake.
• "Shadow IT is a discipline problem, not a security one." Unapproved devices and services sit outside patching, monitoring and configuration control, which makes them vulnerabilities.
• "Zero-days are the main risk." They are real, but the NSA and CISA list of common misconfigurations is made of known, fixable problems that attackers use far more often.

Where this leaves us

• Unsupported, unpatched, obsolete and unmanaged systems lack fixes or owners; Windows 10 support ended on 14 October 2025.
• Stale credentials and a weakly protected identity provider open many doors at once; Snowflake's 2024 cases came from unrotated stolen credentials without MFA.
• Misconfigurations top the NSA and CISA list with default settings; public object storage and public repositories leak data.
• Rogue devices and shadow IT bypass controls; wireless and low-power radios often favor convenience.
• Sideloading and jailbreaking weaken phones; VM escape and resource reuse threaten virtualization; zero-days and weak cryptography complete the list.
• Prioritize by likelihood and impact, starting with exposed credentials and public data.

Sources

1. Mandiant. (2024, June 10). UNC5537 targets Snowflake customer instances for data theft and extortion. Google Cloud Threat Intelligence blog. cloud.google.com
2. Microsoft. (n.d.). Windows 10 support has ended. microsoft.com
3. NSA and CISA. (2023, October 5). NSA and CISA red and blue teams share top ten cybersecurity misconfigurations (AA23-278A). cisa.gov
4. Amazon Web Services. (n.d.). Blocking public access to your Amazon S3 storage. Amazon S3 User Guide. docs.aws.amazon.com
5. Howell, G., Franklin, J., Sritapan, V., Souppaya, M., and Scarfone, K. (2023). Guidelines for managing the security of mobile devices in the enterprise (NIST SP 800-124 Rev. 2). National Institute of Standards and Technology. csrc.nist.gov
6. National Institute of Standards and Technology. (n.d.). Zero day attack [Glossary entry]. NIST Computer Security Resource Center. csrc.nist.gov
7. Scarfone, K., Souppaya, M., Cody, A., and Orebaugh, A. (2008). Technical guide to information security testing and assessment (NIST SP 800-115), glossary entry for rogue device. National Institute of Standards and Technology. nist.gov (PDF)

Friday 12 May 2017

On Friday 12 May 2017, a ransomware program later named WannaCry began encrypting computers around the world. CISA's alert that day described how it spread. It exploited a flaw in version 1 of Windows' file-sharing protocol, SMB, which Microsoft had patched in March in its MS17-010 update. Once on a network, it scanned for other machines listening on the file-sharing ports and infected them in turn, with no one clicking anything. Each infected computer displayed a demand for about 300 dollars in bitcoin. In June 2018 the US government attributed WannaCry to North Korea.

Britain's National Health Service was among the hardest hit. The National Audit Office's investigation, published on 27 October 2017, found that at least 81 of England's 236 NHS trusts were affected, along with 603 primary care and other NHS organizations, including 595 general practices. NHS England identified 6,912 cancelled appointments and estimated that more than 19,000 were cancelled in all. The infected organizations had unpatched or unsupported Windows systems. The auditors called the attack relatively unsophisticated, and said basic IT security practice could have prevented it.

WannaCry is a useful teacher because it was two kinds of malware at once, and because it left clear traces. This lesson names the malware families the exam lists and the indicators that reveal them.

Exam objectives: SY0-801 2.5, malware attacks and indicators of compromise, a scenario objective. On SY0-701 this is part of 2.4, which also lists bloatware and the indicators blocked content, resource inaccessibility, out-of-cycle logging, published or documented compromise, and missing logs.

Ransomware and worm: what WannaCry was

Ransomware encrypts or locks data and demands payment for its release. Modern ransomware groups often steal data first and threaten to publish it, adding extortion to encryption. WannaCry's ransom note was its most visible feature.

Its speed came from being a worm: malware that copies itself across networks on its own, by exploiting vulnerable services, without needing a user to open anything. CISA's alert described the infected machine scanning nearby addresses for the Windows file-sharing ports and exploiting any that answered. That is why one infected laptop could take down a whole hospital network in hours.

Malware types describe behavior, and one program can show several. Keep the definitions sharp, because the exam's scenarios turn on which behavior they describe.

The malware families, compared

NIST's glossary gives the formal versions of two that confuse people. A logic bomb is code intentionally inserted into a software system that sets off a malicious function when specified conditions are met. A rootkit is a set of tools an attacker uses after gaining root-level access, to hide activity and keep that access covertly. Fileless techniques, as MITRE ATT&CK describes, store data in places such as the registry or the WMI repository rather than ordinary files, which may let them go undetected by tools that only inspect files on disk.

What matters here: identify malware by what it does: spreads alone (worm), hides in something useful (trojan), waits for a trigger (logic bomb), conceals itself (rootkit), lives in memory (fileless), or demands payment (ransomware).

Indicators of compromise

An indicator of compromise (IoC) is an observable sign that a system may have been attacked. SY0-801 lists a dozen. Here they are with where you would see each:

SY0-701 added a few more. Blocked content means security tools suddenly stopping connections or files they used to allow. Resource inaccessibility means files that will not open, as when ransomware strikes. Out-of-cycle logging is log activity at times when nothing should be happening. Missing logs are gaps where events should be. A compromise that is published or documented is one you learn about from outside, such as your data appearing on a leak site.

Why some indicators age faster than others

Not all indicators are equally durable. A hash identifies one exact file, and changing a single byte produces a completely different hash, so an attacker can make every new copy unique. IP addresses and domains change as attackers rent new servers. Behaviors last much longer: a worm scanning the file-sharing ports, a word processor launching PowerShell, an account signing in from two continents at once. That is why mature defenders pair indicator feeds with detections built on behavior, often mapped to ATT&CK techniques.

WannaCry showed both kinds. Its file hashes and its kill-switch domain were shared within hours. Its behavior, many machines suddenly scanning the SMB ports while files were renamed and ransom notes appeared, was visible to anyone watching the network, whatever the hash.

Key idea: hashes, addresses and domains catch yesterday's attack quickly; behavioral indicators catch tomorrow's variant.

What would have stopped it

CISA's 2017 recommendations read like this course's first module applied. Apply the MS17-010 patch. For systems that cannot be patched, disable SMBv1 and block SMB traffic, including TCP port 445, at network boundaries; that is a compensating control. And test backups so they restore when needed, a corrective control. The NAO added that managing internet-facing firewalls would have protected NHS organizations whether or not they had patched. Every one of these controls was available before 12 May.

Common misconceptions

• "Virus and malware mean the same thing." A virus is one type, which needs a host file and a user action to spread. A worm spreads by itself; a trojan disguises itself.
• "If antivirus finds nothing, the system is clean." Fileless techniques and rootkits are designed to avoid exactly the checks antivirus performs. Behavior and logs matter.
• "A blocklist of hashes keeps a known malware family out." Each changed byte makes a new hash; behavior-based detection is needed alongside.
• "Paying the ransom restores everything." Payment does not guarantee working decryption, and data stolen before encryption can still be published. Tested backups are the reliable recovery.
• "Account lockouts are just users forgetting passwords." Many lockouts across many accounts at once is a classic sign of password guessing.

What you now know

• WannaCry (May 2017) combined ransomware with a worm that exploited SMBv1 on unpatched Windows; at least 81 NHS trusts were affected.
• Malware types: ransomware, worm, virus, trojan, spyware, keylogger, adware, bloatware, rootkit, logic bomb and fileless malware, each defined by behavior.
• Indicators of compromise include hashes, IPs, domains, processes, file artifacts, timestamps, log manipulation, resource use, strings, lockouts, impossible travel and concurrent sessions.
• Hashes and addresses are brittle; behaviors are durable, so combine both.
• Patching, disabling SMBv1, blocking port 445 at the boundary and tested backups would have stopped or contained WannaCry.

Sources

1. Cybersecurity and Infrastructure Security Agency. (2017, May 12; revised 2018, June 7). Indicators associated with WannaCry ransomware (TA17-132A). cisa.gov
2. National Audit Office. (2017, October 27). Investigation: WannaCry cyber attack and the NHS. nao.org.uk
3. Souppaya, M., and Scarfone, K. (2013). Guide to malware incident prevention and handling for desktops and laptops (NIST SP 800-83 Rev. 1). National Institute of Standards and Technology. csrc.nist.gov
4. National Institute of Standards and Technology. (n.d.). Glossary: logic bomb; rootkit. NIST Computer Security Resource Center. csrc.nist.gov
5. MITRE. (n.d.). Obfuscated files or information: Fileless storage (T1027.011). MITRE ATT&CK. attack.mitre.org
6. Microsoft. (2026). Microsoft Defender Antivirus event IDs and error codes. Microsoft Learn. learn.microsoft.com
7. Russinovich, M. (2026). Autoruns (Sysinternals). Microsoft Learn. learn.microsoft.com
8. EICAR. (n.d.). Anti malware testfile. European Institute for Computer Antivirus Research. eicar.org

620 gigabits per second

In September 2016, the journalist Brian Krebs's website was hit by a flood of traffic exceeding 620 gigabits per second. A later attack on the French hosting company OVH reached at least 1.1 terabits per second. CISA's alert about the source, issued that October, described Mirai: malware that continuously scanned the internet for Internet of Things devices such as cameras and video recorders. It tried a short list of 62 common default usernames and passwords to log in over Telnet, and recruited every device that accepted one into a botnet.

Mirai combined three ideas this lesson covers: a plaintext protocol, default credentials, and a distributed flood. You will meet each in a procedure you can repeat yourself. Instead of attacking anything, you will open published packet captures in Wireshark, the free network analyzer, and look at the raw material attackers work with. Then the lesson turns to the attacks that need no network at all: the ones that walk in through a door.

Exam objectives: SY0-801 2.5, network and physical attacks, a scenario objective. On SY0-701 these are in 2.4, which also lists amplified and reflected DDoS, wireless attacks, credential replay, malicious code, physical brute force, RFID cloning and environmental attacks.

Step 1: set up Wireshark and the sample files

Install Wireshark from wireshark.org on your computer or lab VM, verifying the download as in Lab 1. Then download four small files from the Wireshark project's SampleCaptures page: telnet-cooked.pcap, dns.cap, dhcp.pcap and arp-storm.pcap. Opening a saved capture sends nothing onto any network, so this procedure is safe anywhere. Wireshark shows each packet in three panes: a list of packets, the decoded fields of the selected packet, and its raw bytes. A display filter typed into the bar above the list hides every packet that does not match.

Step 2: sniffing a cleartext session

Open telnet-cooked.pcap. Telnet is a decades-old remote login protocol that sends everything as plain text. Right-click any packet, choose Follow, then TCP Stream, and Wireshark reassembles the conversation. Whatever was typed in that session is there to read.

That is sniffing: capturing network traffic and reading it. Anyone positioned on the path between two systems can do it, which is what an on-path attack means: the attacker sits between the parties, reading and possibly altering what passes. (The older name was man-in-the-middle.) Mirai's infections ran over Telnet for the same reason sniffing works on it: an old protocol with no protection.

The defense is not to hope nobody is listening. It is to make listening useless. Replace Telnet with SSH, HTTP with HTTPS, and FTP with SFTP. With TLS 1.3 or SSH, a sniffer sees only encrypted bytes.

Why this matters: assume every network you use can be sniffed; only encryption turns captured traffic into noise.

Step 3: DNS in the clear, and cache poisoning

Open dns.cap and apply the filter dns. Each query shows a name being looked up, and each response the address returned. Classic DNS is unencrypted, so it tells a sniffer every site a user visits. Select a query and look for the transaction ID: a 16-bit number the response must match.

That number is the heart of DNS cache poisoning. A caching resolver remembers answers so it does not have to ask again. If an attacker can get a forged answer accepted, every user of that resolver is sent to the attacker's address until the record expires. CERT/CC's 2008 vulnerability note VU#800113 explained why forging was easier than it should be: some resolvers used predictable transaction IDs or a fixed source port. The fixes it describes are source port randomization, which adds roughly 16 more bits an attacker must guess, and DNSSEC, which signs DNS records so that forged ones fail validation.

Other DNS attacks target the records themselves: changing them through a hijacked registrar account, or registering lookalike names, as Lesson 9 described. The exam groups them together; the defenses range from DNSSEC to MFA on the accounts that manage your domains.

Step 4: ARP, spoofing and the on-path position

Open arp-storm.pcap and filter on arp. The Address Resolution Protocol answers one question on a local network: which hardware (MAC) address has this IP address? It has no authentication. Any device can announce that it holds any IP address, and others will believe it.

In ARP spoofing (also called ARP poisoning), an attacker announces that its own MAC address belongs to the gateway's IP address. Neighbors then send their traffic to the attacker, who forwards it onward while reading it: an on-path position created by spoofing, which means forging an identity such as an address. Wireshark watches for the symptom. Its field arp.duplicate-address-detected, labeled Duplicate IP address configured, flags one IP address claimed by two different MAC addresses. Try that filter on the sample and note what you find.

Step 5: DHCP and rogue devices

Open dhcp.pcap and filter on dhcp. You will see the four-message exchange in which a new device asks for, and receives, an IP address, a default gateway and DNS servers. Whoever answers that request controls where the device sends its traffic.

A rogue DHCP server, plugged into the network by mistake or on purpose, can hand out its own address as the gateway or DNS server, creating an on-path position for every device that listens to it. The wireless equivalent is a rogue access point, including the evil twin, which copies a legitimate network's name so devices connect to it. An analyst seeing DHCP offers from two different servers, or a familiar network name broadcast by an unfamiliar access point, is looking at an indicator.

The short form: ARP, DHCP and classic DNS trust whoever answers first. Spoofing, rogue servers and poisoning exploit that trust; encryption, DNSSEC and network access control limit the damage.

Floods: DoS, DDoS, amplification and reflection

A denial of service (DoS) attack exhausts a resource so that legitimate users cannot reach a service. A distributed denial of service (DDoS) uses many sources at once, as Mirai's botnet did, so blocking one address achieves nothing.

Two techniques multiply an attacker's power. In a reflected attack, the attacker sends requests with the victim's address forged as the source, so servers send their replies to the victim. In an amplified attack, those replies are much larger than the requests. CISA's alert on UDP amplification lists the bandwidth amplification factor for common services: 28 to 54 for DNS, about 557 for NTP, and 10,000 to 51,000 for memcached. One small forged request to an exposed memcached server can return tens of thousands of times its size to the victim.

Defenses work at several points. Large services buy DDoS protection that absorbs floods upstream, and rate limiting slows abusive sources. Everyone can avoid becoming an amplifier, by not exposing DNS, NTP or memcached services to the internet unnecessarily. For IoT devices, CISA's Mirai alert recommends replacing default passwords, applying updates and disabling Universal Plug and Play on routers unless it is needed.

Downgrades, replays and wireless tricks

A protocol downgrade attack pushes two parties into using an older, weaker protocol version or cipher than both actually support, so that a known weakness becomes usable. The durable defense is to disable old versions entirely, such as SSL and early TLS, so there is nothing to downgrade to.

A replay attack captures a valid message, such as an authentication exchange or a transaction, and sends it again later. Protocols resist replay with values that are valid only once or briefly: random nonces, timestamps and short-lived session tokens. SY0-701 calls the credential version credential replay. Wireless networks add attacks of their own, such as the evil twin above, which is one reason to require modern Wi-Fi security on every network you run.

Attacks that walk through the door

Physical access defeats many logical controls, so the exam lists physical attacks too:

NIST's guidance on physical access with government smart cards, SP 800-116, makes the cloning point precisely. A card identifier that can be read freely can be cloned easily, which is why NIST deprecated authentication based on it. Mechanisms built on a private key that never leaves the card are highly resistant to cloning, because a skimmer cannot copy the key.

Common misconceptions

• "Our office network is private, so plaintext protocols are fine." ARP spoofing and rogue devices put an attacker on the path inside private networks. Encrypt internal traffic too.
• "Blocking the attacking IP address stops a DDoS." A distributed attack comes from thousands of sources, often with forged addresses in reflected attacks.
• "A DDoS means we were hacked." A flood harms availability without entering any system. It can, however, be used as a distraction, so watch other alerts during one.
• "Badges keep unauthorized people out." Not if someone holds the door. Tailgating defeats badges; vestibules and culture stop it.
• "DNSSEC encrypts DNS." DNSSEC signs records so forgeries fail validation; it does not hide which names are being looked up.

The short version

• Sniffing reads traffic; on-path attackers sit between parties; encryption (SSH, TLS) makes both useless.
• ARP and DHCP trust whoever answers, enabling spoofing and rogue servers; Wireshark flags duplicate IP claims.
• DNS cache poisoning plants forged answers; port randomization and DNSSEC are the fixes from VU#800113.
• DDoS floods from many sources; reflection forges the victim's address and amplification multiplies size, up to 51,000 times for memcached.
• Downgrades push weaker versions (disable old ones); replays resend valid messages (use nonces and timestamps).
• Physical attacks: tailgating, shoulder surfing, skimming, RFID cloning, forced entry and environmental attacks, each with a physical control.

Sources

1. US-CERT, Cybersecurity and Infrastructure Security Agency. (2016, October 14; revised 2017, October 17). Heightened DDoS threat posed by Mirai and other botnets (TA16-288A). cisa.gov
2. US-CERT, Cybersecurity and Infrastructure Security Agency. (2014, January 17; revised 2019, December 18). UDP-based amplification attacks (TA14-017A). cisa.gov
3. CERT Coordination Center. (2008, July 8; revised 2014). Multiple DNS implementations vulnerable to cache poisoning (VU#800113). kb.cert.org
4. Wireshark Foundation. (n.d.). SampleCaptures. Wireshark wiki. wiki.wireshark.org
5. Wireshark Foundation. (n.d.). Display filter reference: Address Resolution Protocol. wireshark.org
6. Ferraiolo, H., Mehta, K., Ghadiali, N., Mohler, J., Johnson, V., and Brady, S. (2018). Guidelines for the use of PIV credentials in facility access (NIST SP 800-116 Rev. 1). National Institute of Standards and Technology. csrc.nist.gov

06:12 on a Monday: two failures per account

You open the identity provider's sign-in report on Monday morning. Overnight there were 4,100 failed sign-ins. They hit 2,050 different accounts, almost exactly two attempts each, from more than 300 IP addresses in residential internet ranges. No account locked out, because your lockout threshold is ten failures. At 03:47 one sign-in succeeded: an account called test-sync-02, created years ago for a migration that finished long ago, with no MFA.

What happened, and what do you do first? Hold your answer. This lesson works through the pattern, then follows an intruder from that one account toward the rest of your systems, naming each attack on the way the exam names it.

Exam objectives: SY0-801 2.5, application and credential attacks, a scenario objective. On SY0-701 these are in 2.4, which also lists cryptographic attacks (downgrade, collision, birthday) and password attacks (spraying and brute force), all covered here.

Reading the pattern: spraying versus brute force

Monday's report is password spraying. OWASP's authentication guidance defines it as testing a single weak password against a large number of different accounts. It notes that lockout counters attached to each account are the most common protection. Spraying is designed to stay under them: two guesses per account never reaches ten.

This is not hypothetical. In January 2024 Microsoft reported that the Russian state actor it calls Midnight Blizzard had breached its corporate systems. The actor used password spraying to compromise a legacy, non-production test account that did not have MFA enabled. Microsoft said the actor kept attempts low to evade detection and avoid account blocks. It also routed traffic through residential proxy networks so its connections blended in with ordinary users. From that test account it moved on to Microsoft's corporate email.

So your first action on Monday is to disable test-sync-02, revoke its sessions and check what it touched. Your second is to find every other account that lacks MFA, because spraying finds them for you.

In short: brute force hammers one account; spraying taps every account lightly. Lockouts stop the first, and only MFA everywhere plus pattern detection stops the second.

User enumeration: confirming who exists

Spraying works better when the attacker knows which usernames are real. User enumeration is discovering valid accounts from how a system responds. A sign-in page that says "no account with that email" for unknown users and "wrong password" for real ones answers the question for free. So can a password reset form, a response that is faster for unknown users, or a different HTTP status code. OWASP's guidance is to return a generic message, its example being "Login failed; Invalid user ID or password," and to make timing and status codes consistent too.

When the second factor is the target: MFA bypass

Attackers who hold a password still face MFA, so they attack the MFA:

• MFA fatigue, or push bombing. In September 2022 Uber reported that an attacker had obtained a contractor's password, probably bought after malware infected the contractor's personal device. The attacker then triggered login approval requests over and over. The contractor eventually accepted one, and the attacker was in. Number matching, which makes the user type a code shown on the sign-in screen, blunts this.
• SIM swapping: persuading a mobile carrier to move a victim's number to the attacker's SIM, capturing codes sent by text or voice. CISA lists SIM swap, along with phishing and push bombing, among the attacks that defeat weaker MFA.
• Phishing proxies and stolen sessions: a fake page that relays the user's password and code to the real site in real time, then keeps the session cookie. Lesson 10 showed why a stolen session cookie can bypass MFA entirely.
• Weak fallback: an account protected by a security key but still allowing recovery by text message is only as strong as the text message.

CISA's fact sheet calls FIDO/WebAuthn authentication the only widely available phishing-resistant form, and urges organizations to make it the goal.

From one account to control: privilege escalation

A sprayed test account is rarely the prize. The intruder's next goal is privilege escalation, which MITRE ATT&CK treats as its own tactic: gaining higher-level permissions on a system or network. Vertical escalation climbs to more power, such as from a normal user to administrator, often by exploiting an unpatched flaw or a misconfiguration. Horizontal escalation reaches other accounts at the same level, such as reading a colleague's data. Least privilege limits how far either can go, and patching closes the flaws escalation relies on.

Attacks on the application itself

Lesson 11 showed the coding flaws; here are the attacks that use them, as the exam names them:

The two forgeries are easy to mix up. In CSRF the attacker abuses the user's browser and the trust a site places in it. In SSRF the attacker abuses the server and the trust internal systems place in it. Directory traversal is CWE-22, sixth on MITRE's 2025 list of dangerous weaknesses.

The point: name application attacks by what is being tricked: the interpreter (injection), memory (overflow), the user's browser (CSRF), the server's outbound requests (SSRF), or the file system (traversal).

Cryptographic attacks: downgrade, collision and birthday

Strong algorithms are rarely broken head-on; attacks go around them. A downgrade, from Lesson 14, forces a weaker protocol version. A collision finds two different inputs with the same hash, which breaks anything that relies on the hash to tell them apart, such as a signature. On 23 February 2017, researchers from CWI Amsterdam and Google announced SHAttered: two different PDF files with the same SHA-1 hash. It took roughly nine quintillion SHA-1 computations, about 6,500 CPU-years and 110 GPU-years of work. It is why NIST is retiring SHA-1.

The birthday attack explains why collisions come sooner than intuition suggests. In a room of only 23 people, there is better than an even chance that two share a birthday, because every pair is a chance to match. In the same way, finding any two inputs with matching n-bit hashes takes about 2 to the power n/2 attempts, not 2 to the power n. A 128-bit hash offers only about 64 bits of collision resistance, which is one reason security-sensitive hashes use 256 bits or more. You can watch the effect with this short Python script, which keeps only the first six hex characters (24 bits) of SHA-256 and stops at the first collision:

import hashlib
seen = {}
i = 0
while True:
    msg = 'invoice-' + str(i)
    short = hashlib.sha256(msg.encode()).hexdigest()[:6]
    if short in seen:
        print('collision after', i + 1, 'messages:', seen[short], 'and', msg, 'share', short)
        break
    seen[short] = msg
    i += 1

When this lesson was written, it printed a collision after 5,576 messages: invoice-76 and invoice-5575 share the prefix 77c621. That is close to the 2 to the 12th, about 4,096, that the birthday bound predicts, and nowhere near the 2 to the 24th, about 16.8 million, that hitting one chosen value would take.

Common misconceptions

• "Account lockout stops password attacks." It stops brute force against one account. Spraying stays under thresholds by design, as Midnight Blizzard did.
• "MFA makes passwords irrelevant." Push bombing, SIM swaps and phishing proxies bypass weaker MFA, and fallback methods weaken strong ones.
• "Test accounts do not matter because they hold no data." They are entry points. Microsoft's 2024 breach began with a legacy test account without MFA.
• "CSRF and SSRF are the same attack." CSRF abuses a user's browser; SSRF abuses the server's ability to make requests.
• "A collision means the hash can be reversed." A collision finds two inputs with the same hash; reversing a hash to its input is a different, much harder attack.

Looking back

• Brute force hits one account many times; password spraying hits many accounts a few times and evades lockouts.
• User enumeration reveals valid accounts through differing responses; generic messages and consistent timing prevent it.
• MFA bypass uses push bombing, SIM swaps, phishing proxies, stolen sessions and weak fallbacks; phishing-resistant MFA resists them.
• Privilege escalation is vertical (more power) or horizontal (other accounts).
• Application attacks: injection, overflow, replay, CSRF, SSRF and directory traversal, each with a matching fix.
• Cryptographic attacks: downgrade, collision (SHAttered broke SHA-1 in 2017) and birthday, which needs only about 2 to the power n/2 attempts.

Sources

1. Microsoft Threat Intelligence. (2024, January 25). Midnight Blizzard: Guidance for responders on nation-state attack. Microsoft Security Blog. microsoft.com
2. Uber. (2022, September 15-19). Security update. Uber Newsroom. uber.com
3. OWASP Foundation. (n.d.). Authentication cheat sheet. OWASP Cheat Sheet Series. owasp.org
4. Cybersecurity and Infrastructure Security Agency. (2022, October). Implementing phishing-resistant MFA [Fact sheet]. cisa.gov (PDF)
5. MITRE. (n.d.). Privilege escalation (TA0004). MITRE ATT&CK. attack.mitre.org
6. OWASP Foundation. (n.d.). Cross-site request forgery prevention cheat sheet and Server side request forgery prevention cheat sheet. owasp.org
7. MITRE. (n.d.). CWE-22: Improper limitation of a pathname to a restricted directory ('path traversal'). cwe.mitre.org
8. Stevens, M., Bursztein, E., Karpman, P., Albertini, A., and Markov, Y. (2017, February 23). SHAttered: The first SHA-1 collision. CWI Amsterdam and Google. shattered.io

"It may be worse"

On 8 December 2025, the UK's National Cyber Security Centre published a blog post with a blunt title: "Prompt injection is not SQL injection (it may be worse)". Its author, Dave Chismon, the NCSC's chief technology officer for architecture, argued that large language models simply do not enforce a security boundary between instructions and data inside a prompt. In his view, prompt injection attacks may never be totally mitigated in the way SQL injection attacks can be.

Nine months earlier, a team of researchers including Edoardo Debenedetti and Nicholas Carlini had published a paper titled, just as bluntly, "Defeating Prompt Injections by Design". Its system, CaMeL, completed 77 percent of the tasks in a standard benchmark with what the authors called provable security, against 84 percent for an undefended system.

Both cannot be the whole truth, and the disagreement matters for anyone who will deploy, approve or defend an AI system. This lesson first lays out the threats SY0-801 added for AI, then weighs the dispute, then turns both into controls you can apply.

Exam objectives: SY0-801 2.6 in full, and large language models as an attack surface from 2.4. This objective is new in V8; SY0-701 candidates can treat this lesson as background, though its security ideas carry over.

Where an AI application can be attacked

A typical application built on a large language model (LLM) assembles a prompt from several sources. A system prompt holds the developer's instructions. The user's input is added. Often the application also retrieves documents, emails or web pages to give the model context, a design called retrieval-augmented generation. Increasingly, the model can call tools: search, send email, run code, issue a refund. NIST's adversarial machine learning taxonomy, NIST AI 100-2 (March 2025), names the root problem plainly. Generative AI models combine the data and instruction channels, so attackers can use the data channel to affect what the system does.

Every source in that list is a door. Training data is one too, earlier in the life cycle. The table maps SY0-801's terms to where they strike:

Ethical considerations sit across the whole table: whether an AI system should be used for a purpose at all, and who is accountable for its errors.

Direct and indirect prompt injection

In direct prompt injection, the user is the attacker, typing instructions meant to override the system prompt, extract it, or break the developer's rules. A jailbreak is the best-known kind.

Indirect prompt injection is the more dangerous form for organizations. NIST AI 100-2 explains that it is mounted not by the primary user but by a third party who controls content the system reads, and that it is often the primary user who is harmed. Picture an AI assistant that summarizes your inbox and can send email for you. An attacker sends you a message containing hidden text addressed to the assistant: forward the last month of mail to this address. You never see the instruction. The assistant reads it as part of its data, and may treat it as a command.

Remember: in an LLM, anything the model reads can act like an instruction, so every document, email and web page it processes is untrusted input.

The dispute: fixable, or only containable?

The case that it cannot be fully fixed. The NCSC's argument starts from why SQL injection was solvable. Parameterized queries create a real boundary: the database engine can never interpret the parameter as an instruction. An LLM has no such boundary; it processes one stream of tokens. Detection filters, and training models to prefer instructions over data, try to impose a distinction the technology does not make. The NCSC calls the LLM an inherently confusable deputy. Its prescription follows: accept a residual risk and design for it. Use deterministic, non-LLM safeguards to constrain what the system can do. When an LLM processes content from a party, drop its privileges to that party's level. Monitor inputs, outputs and tool calls. Where the residual risk is intolerable, do not use an LLM.

The case that design can defeat it. The CaMeL researchers accept that the model itself cannot be trusted to separate instructions from data, and move the separation outside the model. Their system derives the program's control flow from the trusted user query only. Untrusted data retrieved during the task can then never change which actions are taken, only the values passed to them, and those are checked against policies. On the AgentDojo benchmark, that design completed 77 percent of tasks with provable security, compared with 84 percent for the same model undefended. Seven points of capability bought a guarantee that injected text could not redirect the agent.

What would settle it. Notice how much the two positions share. Neither expects the model to defend itself; both put the security boundary in ordinary, deterministic code around the model. The open questions are about scope and durability. Can designs like CaMeL cover the open-ended tasks people actually want from agents, or only well-structured ones? And do defenses hold against adaptive attackers over years? NIST's taxonomy is cautious on the second question. It notes that there are no information-theoretic security proofs for widely used machine learning algorithms, that impossibility results limiting common mitigations have begun to appear, and that many mitigations are empirical and may be broken by new attacks. Evidence that would move the debate includes independent evaluations of design-level defenses against adaptive attacks, and real deployments that keep their guarantees while doing useful open-ended work.

The point: treat prompt injection as a risk to contain by architecture, not a bug to filter away: least privilege for the model, deterministic checks on its actions, and human approval where mistakes are costly.

Hallucinations carry liability

NIST's Generative AI Profile, NIST AI 600-1 (July 2024), defines confabulation as the production of confidently stated but erroneous or false content, colloquially called hallucinations. It explains why: generative models produce outputs that approximate the statistical patterns of their training data, which can be fluent and still false. It also warns of automation bias, people's excessive deference to automated systems.

In February 2024 a Canadian tribunal showed what that costs. In Moffatt v. Air Canada, a customer had relied on the airline's website chatbot, which told him he could apply for a bereavement fare after travel. The airline's actual policy said otherwise. Air Canada argued that the chatbot was a separate legal entity responsible for its own actions. The tribunal rejected that, found the airline had not taken reasonable care to ensure its chatbot was accurate, and ordered it to compensate the customer. An organization owns what its AI says.

Bias, explainability, privacy and ethics

NIST's AI Risk Management Framework, released in January 2023, lists the characteristics of trustworthy AI. They include valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. Several map straight onto SY0-801's list. Bias appears when training data or design produces unfair outcomes for groups. Explainability fails when no one can say why a model decided as it did, which makes errors and discrimination hard to detect. Privacy fails when personal data is collected, retained or inferred without need. A model can sometimes reveal whether a person's data was in its training set, an attack NIST calls membership inference. Data loss happens when staff paste confidential material into AI tools whose terms allow retention or training on it.

Defending AI applications

The OWASP Top 10 for LLM Applications (2025) is the most widely used checklist. Its ten entries, with the control each most needs:

For threat modeling, MITRE ATLAS, a sibling of ATT&CK, catalogs tactics and techniques used against AI-enabled systems. And for staff, the first control is a policy: which AI tools are approved, and what data may never be pasted into any of them.

Common misconceptions

• "A good system prompt prevents prompt injection." The system prompt is just more text in the same channel. Security must come from controls outside the model.
• "Prompt injection only matters if users misbehave." Indirect injection comes from third-party content the model reads, and harms the user who never saw it.
• "Hallucinations are rare glitches that better models will remove." NIST describes confabulation as a natural result of how generative models work. Plan for it with grounding and human accountability.
• "The vendor is responsible for what our chatbot says." Air Canada argued its chatbot was a separate entity; the tribunal held the airline responsible.
• "AI threats are a separate discipline." The defenses are familiar: least privilege, input and output validation, supply chain control, monitoring and human approval.

Putting it together

• LLM applications mix instructions and data in one channel, so anything the model reads can steer it.
• SY0-801 threats: model manipulation, poisoning, direct and indirect prompt injection, jailbreaking, evasion, data loss, privacy, bias, explainability, hallucinations, session hijacking and code execution.
• The NCSC argues prompt injection may never be fully mitigated and must be contained; CaMeL shows design-level separation can give guarantees for many tasks. Both put the boundary outside the model.
• Organizations are accountable for AI output, as Moffatt v. Air Canada showed.
• Use the OWASP Top 10 for LLM Applications, least privilege, output handling, human approval and clear staff policy.

Sources

1. Chismon, D. (2025, December 8). Prompt injection is not SQL injection (it may be worse). National Cyber Security Centre blog. ncsc.gov.uk
2. Debenedetti, E., Shumailov, I., Fan, T., Hayes, J., Carlini, N., et al. (2025). Defeating prompt injections by design (arXiv:2503.18813, v2). arxiv.org
3. Vassilev, A., Oprea, A., Fordyce, A., Anderson, H., Davies, X., and Hamin, M. (2025). Adversarial machine learning: A taxonomy and terminology of attacks and mitigations (NIST AI 100-2 E2025). National Institute of Standards and Technology. csrc.nist.gov
4. National Institute of Standards and Technology. (2024). Artificial intelligence risk management framework: Generative artificial intelligence profile (NIST AI 600-1). nist.gov (PDF)
5. National Institute of Standards and Technology. (2023). AI risk management framework (AI RMF 1.0). nist.gov
6. OWASP GenAI Security Project. (2025). OWASP Top 10 for LLM applications 2025. genai.owasp.org
7. MITRE. (n.d.). ATLAS: Adversarial threat landscape for artificial-intelligence systems. atlas.mitre.org
8. Moffatt v. Air Canada, 2024 BCCRT 149. Civil Resolution Tribunal of British Columbia, decided February 2024. Published on the tribunal's decisions site and on CanLII.

A business network, a pipeline, and one password

On 7 May 2021, Colonial Pipeline, which carries fuel along the US East Coast, found ransomware in its computer systems and shut its pipeline down. CISA later described the result: fuel shortages and long lines at gas stations along the eastern seaboard. At a Senate hearing on 8 June 2021, the company's chief executive, Joseph Blount, said that shutting down the pipeline was absolutely the right decision. The attackers' way in, as reported from that hearing, was a password for a legacy VPN account that, according to the incident responders at Mandiant, lacked multifactor authentication.

Notice what decided the consequences. The ransomware was on the business side; the pipeline is operational technology, the systems that move physical things. How those two worlds connect, what depends on what, and how confidently a company can say one cannot reach the other are questions of architecture. This lesson compares the architecture models SY0-801 names, from the public cloud to the pipeline control room, and the security consequences of each.

Exam objectives: SY0-801 3.1 in full. On SY0-701 this is objective 3.1, which also names containerization, virtualization, IoT, ICS and SCADA, real-time operating systems, embedded systems, software-defined networking, centralized versus decentralized designs, high availability, risk transference and patch availability.

Cloud, defined

NIST's definition of cloud computing, SP 800-145, describes a model with five essential characteristics, three service models and four deployment models. The service models decide how much of the stack you run. In infrastructure as a service (IaaS) you rent virtual machines, storage and networks and manage the operating system up. In platform as a service (PaaS) you deploy code onto a managed platform. In software as a service (SaaS) you use a finished application.

The deployment models decide who shares the infrastructure:

A multicloud strategy uses more than one provider, which can reduce dependence on any one of them but multiplies the consoles, identity systems and configurations a team must secure.

Who is responsible for what

Amazon Web Services sums up the shared responsibility model as security "of" the cloud versus security "in" the cloud. AWS protects the infrastructure that runs its services: hardware, software, networking and facilities. The customer secures what it builds and stores. For a virtual machine, that means the guest operating system and its patches, the applications installed on it, the security group firewall rules, and the data. For more abstracted services such as storage, AWS runs the operating system and platform, and the customer still owns its data, encryption choices and access permissions.

That table is a responsibility matrix, and the top row is the one that matters most: no service model takes your data and your users' access off your hands. The Snowflake cases in Lesson 12 were customer-side failures of exactly that row.

Bottom line: in every cloud model, data and identity are yours to protect; the further up the stack the provider goes, the less else you patch.

Serverless, microservices, containers and virtualization

Serverless computing runs your functions on demand on infrastructure the provider manages entirely. There is no server for you to patch, but your code, its dependencies, its permissions and its triggers remain yours, and every function is another entry point to secure.

Microservices split an application into many small services that talk to each other through APIs. Each service can be updated and scaled independently, but the attack surface becomes the web of connections between them, so service-to-service authentication and authorization matter as much as the front door.

Containers package an application with its dependencies and share the host's operating system kernel. Virtual machines each run a full operating system on a hypervisor. Containers start faster and pack more densely, but a kernel flaw can affect every container on the host. Both depend on their images: an image built on an outdated base carries its vulnerabilities into every copy. Lesson 12's VM escape is the virtualization risk at its sharpest.

Infrastructure as code

Infrastructure as code (IaC) defines servers, networks and storage in text templates that tools deploy automatically. Here is a fragment in Terraform's language, written for this lesson, that configures Amazon S3's Block Public Access settings for a log bucket:

resource "aws_s3_bucket_public_access_block" "logs" {
  bucket                  = aws_s3_bucket.logs.id
  block_public_acls       = false
  block_public_policy     = false
  ignore_public_acls      = false
  restrict_public_buckets = false
}

Each false switches off one of the four protections Amazon recommends turning on, and Terraform's documentation shows all four set to true in its example. In a console, someone would have clicked through four warnings. In a template, the mistake is four short lines, deployed every time the template runs, to every environment built from it.

That is IaC's double edge. Templates can be kept under version control, reviewed like code and scanned automatically before deployment, which makes infrastructure repeatable and auditable. The same automation repeats a mistake perfectly, and templates sometimes carry secrets that belong in a secrets manager.

On-premises, air gaps and segmentation

On-premises infrastructure gives full control of hardware, location and configuration, with full responsibility for all of it. SY0-701 also contrasted centralized designs, simpler to manage but a single point of failure, with decentralized ones, more resilient but harder to secure consistently.

Separation can be physical or logical. An air-gapped network has no connection to other networks at all, the strongest physical segmentation. It is not perfect: MITRE ATT&CK notes that removable media can carry malware onto disconnected or air-gapped networks. Physical segmentation uses separate cabling and devices. Logical segmentation, using VLANs, firewalls and access rules on shared hardware, is cheaper and more flexible, and its strength depends entirely on configuration. Software-defined networking (SDN) moves that configuration into central software, which makes changes fast and makes the controller a high-value target.

Operational technology

NIST's Guide to Operational Technology Security, SP 800-82 Revision 3 (September 2023), describes operational technology (OT) as programmable systems and devices that interact with the physical environment. They detect or cause physical change by monitoring or controlling devices, processes and events. Industrial control systems (ICS), the SCADA systems that supervise pipelines and power grids, building automation and physical access control all count. The guide's purpose, in its own summary, is to secure OT while addressing its unique performance, reliability and safety requirements.

That changes the usual priorities. In OT, availability and safety come first; a patch that reboots a controller mid-process can itself cause harm. Devices run for decades, often on real-time operating systems (RTOS) and embedded firmware with limited computing power, and some can never be patched. Where patching is impossible, Lesson 3's compensating controls take over: segment the OT network from IT, allow only specific connections, monitor everything, and plan how to keep the physical process safe if IT is lost. Colonial's decision to stop the pipeline shows the cost of uncertainty about that boundary.

What matters here: in OT, the question is not only "is the data safe?" but "is the physical process safe?", and an IT incident can stop a physical process even without touching it.

Weighing the options

SY0-801 lists the considerations that decide among architectures. Grouped, with the question each asks:

Common misconceptions

• "Moving to the cloud moves security to the provider." The provider secures the cloud itself; data, identities and configuration remain the customer's in every service model.
• "Serverless means nothing to secure." No servers to patch, but code, dependencies, permissions and triggers remain yours.
• "Infrastructure as code is automatically more secure." It makes configuration reviewable and repeatable, including mistakes, which it repeats everywhere.
• "An air-gapped network cannot be compromised." Removable media and people bridge gaps; air gaps reduce risk rather than remove it.
• "OT should be patched as fast as IT." OT patching must respect safety and availability, and some devices cannot be patched at all, which is why segmentation and monitoring carry so much weight.

The takeaway

• NIST defines cloud by service models (IaaS, PaaS, SaaS) and deployment models (public, private, community, hybrid); multicloud spreads dependence and adds complexity.
• Shared responsibility: the provider secures the cloud, the customer secures what is in it; data and identity always stay with the customer.
• Serverless, microservices and containers move work to providers and APIs but add entry points; images and hypervisors must be maintained.
• Infrastructure as code makes configuration reviewable and repeatable, including its mistakes.
• OT puts safety and availability first, often cannot be patched, and depends on segmentation and compensating controls.
• Choose architectures by availability, recovery, responsibility, patchability, data sovereignty, cost and risk.

Sources

1. Mell, P., and Grance, T. (2011). The NIST definition of cloud computing (NIST SP 800-145). National Institute of Standards and Technology. csrc.nist.gov
2. Amazon Web Services. (n.d.). Shared responsibility model. aws.amazon.com
3. Stouffer, K., Pease, M., Tang, C., Zimmerman, T., Pillitteri, V., Lightman, S., Hahn, A., Saravia, S., Sherule, A., and Thompson, M. (2023). Guide to operational technology (OT) security (NIST SP 800-82 Rev. 3). National Institute of Standards and Technology. csrc.nist.gov
4. HashiCorp. (n.d.). Resource: aws_s3_bucket_public_access_block. Terraform AWS provider documentation. github.com
5. Amazon Web Services. (n.d.). Blocking public access to your Amazon S3 storage. Amazon S3 User Guide. docs.aws.amazon.com
6. CNN, republished by KVIA. (2021, June 8). Colonial Pipeline CEO defends his handling of ransomware attack that crippled East Coast fuel supply. kvia.com
7. Easterly, J., and Fanning, T. (2023, May 7). The attack on Colonial Pipeline: What we've learned and what we've done over the past two years. Cybersecurity and Infrastructure Security Agency. cisa.gov
8. Blount, J. (2021, June 8). Testimony before the US Senate Committee on Homeland Security and Governmental Affairs, hearing on threats to critical infrastructure: examining the Colonial Pipeline cyber attack. Washington, DC.

A directive with a deadline

On 19 January 2024, CISA issued Emergency Directive 24-01, ordering federal civilian agencies to act on two vulnerabilities in Ivanti Connect Secure and Policy Secure, widely used VPN gateways. Chained together, the flaws let an attacker run arbitrary commands on the device. Twelve days later CISA went further: agencies were to disconnect every affected product by 11:59 p.m. on 2 February. They were to rebuild each one before reconnecting it, and to treat domain accounts associated with the devices as compromised. A further update warned that a sophisticated actor might have installed persistence able to survive a factory reset.

A VPN gateway sits at the most trusted point of a traditional network: the door through which outsiders become insiders. When that door fails, everything behind it is exposed. This lesson reviews a network design built on exactly that model, finds its flaws one at a time, and then replaces location-based trust with Zero Trust.

Exam objectives: SY0-801 3.2, a scenario objective, in full. On SY0-701 this is 3.2, which also names device attributes (active and passive, inline and tap), network appliances (jump servers, proxies, IDS and IPS, load balancers, sensors), port security, firewall types, IPsec, SD-WAN and SASE, plus the Zero Trust control and data planes from 1.2.

The design that "looks fine"

A consultant's design for a 40-person medical clinic arrives for review:

• An internet firewall with a screened subnet (often called a DMZ) behind it, containing the patient portal web server, the patient records database, and a file share.
• One flat internal network for staff PCs, servers, medical devices, the printers and the guest Wi-Fi.
• An intrusion prevention system connected to a mirror port on the core switch.
• A VPN appliance that gives remote staff full access to the internal network.
• Administrators managing switches and firewalls over the same internal network, using one shared administrator account.
• Services on three web servers running under a single domain user account whose password has not changed in four years.

The covering note says: "Looks fine: firewall in front, VPN for remote staff, IPS watching everything." Each line hides a flaw. Here they are in order.

Flaw 1: the database in the screened subnet

A screened subnet is a zone for systems that must accept connections from the internet, separated by firewall rules from both the internet and the internal network. Its purpose is containment: if the public web server is compromised, the attacker is stuck in a zone that holds nothing else of value. Putting the patient database there defeats the purpose. The database never needs to accept internet connections, so it belongs in an internal zone. The firewall then allows only the web server to reach the database, and only on the database's port.

That is device placement driven by security zones, and its goal is to shrink the attack surface: the set of systems and services an attacker can reach from a given position.

Flaw 2: one flat internal network

Everything internal shares one network, so a compromised printer or a guest's laptop can reach the records server and the medical devices directly. Divide it into zones by trust and function: staff devices, servers, medical devices and other operational technology, guest Wi-Fi with internet access only, and a management zone. Firewall rules between zones allow only the flows the clinic needs. Lesson 21 covers the controls that enforce those rules.

SY0-801 also lists diversity as an infrastructure consideration: using different vendors or technologies at different layers, so that one product's flaw does not open every layer at once.

The core of it: place each system in the zone its exposure requires, allow only the flows the business needs between zones, and keep internet-facing systems away from everything else.

Flaw 3: an IPS that cannot prevent anything

The IPS is attached to a mirror port, which sends it a copy of traffic. A device on a copy is passive, also described as tap or monitor mode: it can see and alert, as an intrusion detection system (IDS) does, but the original packets have already gone on their way. To block, an intrusion prevention system must be inline, an active device with traffic flowing through it.

Inline devices raise a design question: what happens when the device fails? A fail-open design keeps traffic flowing without inspection, protecting availability at the cost of security. A fail-closed design stops traffic, protecting security at the cost of availability. Neither is always right. A clinic might let its guest Wi-Fi filter fail open, but want the link to the records zone to fail closed.

Flaw 4: a VPN that makes outsiders into insiders

A virtual private network (VPN) builds an encrypted tunnel across an untrusted network. NIST's guide to IPsec VPNs, SP 800-77, describes one common family; TLS-based VPNs are another. The tunnel protects traffic in transit. The flaw in the design is what happens at the end of the tunnel: every authenticated user lands on the whole internal network, so one stolen VPN password, or one exploited gateway, as in the Ivanti case, reaches everything.

Better remote access starts with user management and least privilege: each remote user reaches only the applications their job needs, through strong authentication. That is precisely what Zero Trust formalizes.

Zero Trust: from location to per-request decisions

NIST SP 800-207 defines Zero Trust architecture through seven tenets. The ones that change designs most are these. All communication is secured regardless of network location, because network location alone does not imply trust. Access to individual resources is granted per session, with least privilege. Access is decided by dynamic policy that considers the identity, the application and the observable state of the requesting device. And the enterprise monitors the security posture of all its assets, because no asset is inherently trusted. NIST also says the enterprise private network should not be treated as an implicit trust zone.

NIST names the components that make those decisions:

SY0-801 asks you to apply three practical ingredients. User authentication is strong and repeated, not a one-time login. Device management means knowing each device's inventory and health, such as patch level and whether endpoint protection is running, before trusting its requests. Application access control grants access to specific applications rather than to the network. SY0-701 used related terms: adaptive identity, threat scope reduction and policy-driven access control.

CISA's Zero Trust Maturity Model, version 2.0, turns this into a roadmap with five pillars, three cross-cutting capabilities and four maturity stages: Traditional, Initial, Advanced and Optimal. Delivery models have names too. Secure access service edge (SASE), which NIST SP 800-215 discusses, combines wide area networking such as SD-WAN with security services delivered from the cloud. Security service edge (SSE) is the security half on its own: cloud-delivered web filtering, cloud access security brokering and Zero Trust network access.

Why this matters: Zero Trust replaces "inside means trusted" with a decision for every session, based on who is asking, from what device, for which application.

Flaw 5: managing the network through the network

Administrators reach switches and firewalls over the same network everyone else uses, and they share one administrator account. An attacker on a staff PC can then reach the management interfaces too, and no log can say which person made a change.

NSA's guidance on out-of-band management describes the fix: an alternate communication path for managing infrastructure devices, isolating management traffic from operational traffic. It may be physically separate or virtually separated. NSA recommends that all management traffic use only encrypted protocols such as SSH, HTTPS, SNMPv3, SCP and SFTP. Administrators should use individual accounts, often reaching the management network through a hardened jump server that logs every session.

Flaw 6: one old password for many services

Three web servers run their services under a single ordinary domain account whose password has not changed in four years. Anyone who extracts it from one server can use it on all three, indefinitely.

Windows offers a purpose-built alternative. A group managed service account (gMSA) is a domain account for running services across multiple servers, whose password Windows manages instead of an administrator. Microsoft's documentation explains that domain controllers compute the password from keys that change periodically, and that member servers retrieve the current value as needed. No human ever needs to know it.

Two related ideas complete identity management in SY0-801. Least privilege access accounts separate everyday work from administration: an administrator reads email with a normal account and uses a separate privileged account only for admin tasks. Privilege creep is the slow accumulation of permissions as people change roles without losing old access, which regular access reviews catch.

Other secure communication choices

• End-to-end encrypted messaging encrypts messages so only the participants can read them, not the service in between. In December 2024, after espionage against telecommunications networks, CISA advised highly targeted individuals to use end-to-end encrypted apps such as Signal.
• File transfer should use encrypted protocols such as SFTP or FTPS instead of plain FTP, and file transfer servers deserve hardening: Lesson 32's MOVEit case shows how attackers value them.
• Port security with 802.1X, listed in SY0-701, authenticates devices before a switch port or Wi-Fi network lets them in; Lesson 21 covers it with network access control.

Common misconceptions

• "A DMZ is just another internal zone." A screened subnet holds only internet-facing systems, kept apart from internal ones so that its compromise reaches nothing else.
• "An IPS on a mirror port blocks attacks." A passive device sees copies; only an inline device can stop traffic.
• "A VPN makes remote access secure." It encrypts the tunnel. What the user can reach at the end of it, and the security of the gateway itself, decide the risk.
• "Zero Trust is a product you buy." NIST defines it as tenets and an architecture; products such as ZTNA and SSE implement parts of it.
• "Fail-closed is always more secure, so always choose it." Fail-closed can stop essential services; the choice depends on whether availability or protection matters more on that link.

Summing up

• Place internet-facing systems in a screened subnet and everything else in internal zones; allow only required flows; reduce attack surface; consider diversity.
• Passive (tap or monitor) devices detect; inline devices can block; choose fail-open or fail-closed per link.
• VPNs and tunnels protect traffic in transit; gateways are prized targets, as ED 24-01 showed in 2024.
• Zero Trust (NIST SP 800-207) decides every session by identity, device and policy, through the policy engine, policy administrator and enforcement point.
• Manage infrastructure out of band through jump servers with encrypted protocols and individual accounts.
• Use gMSAs for services, separate privileged accounts, and access reviews against privilege creep.

Sources

1. Cybersecurity and Infrastructure Security Agency. (2024, January 19; supplemental directions January 31 and February 9). ED 24-01: Mitigate Ivanti Connect Secure and Ivanti Policy Secure vulnerabilities. cisa.gov
2. Rose, S., Borchert, O., Mitchell, S., and Connelly, S. (2020). Zero trust architecture (NIST SP 800-207). National Institute of Standards and Technology. nist.gov (PDF)
3. Cybersecurity and Infrastructure Security Agency. (2023). Zero trust maturity model (Version 2.0). cisa.gov
4. Chandramouli, R., and Butcher, Z. (2022). Guide to a secure enterprise network landscape (NIST SP 800-215). National Institute of Standards and Technology. csrc.nist.gov
5. Barker, E., Dang, Q., Frankel, S., Scarfone, K., and Wouters, P. (2020). Guide to IPsec VPNs (NIST SP 800-77 Rev. 1). National Institute of Standards and Technology. csrc.nist.gov
6. National Security Agency. (2020, September). Performing out-of-band network management [Cybersecurity information sheet]. defense.gov (PDF)
7. Microsoft. (2025). Group managed service accounts overview. Microsoft Learn. learn.microsoft.com
8. Cybersecurity and Infrastructure Security Agency. (2024, December). Mobile communications best practice guidance. cisa.gov (PDF)

A request for three years of patient records

A hospital's research team emails the security office. It wants a copy of three years of patient records from the production database: diagnoses, admissions and discharges, medications, plus names, birth dates and addresses so it can link records across systems. The team plans to train a model that predicts which patients are likely to be readmitted. It would like the data in a cloud workspace by next month.

The request is legitimate, the purpose is good, and saying "no" is not an answer. Your job is to decide what the team actually needs, in what form, where it may live, who is responsible for it, and when it must be destroyed. Each of those decisions uses a piece of SY0-801 objective 3.3. Work through them in order and you will have both the answer and the vocabulary.

Exam objectives: SY0-801 3.3 in full. On SY0-701 this is 3.3, which also names data types such as regulated, trade secret and legal information, human- and non-human-readable data, and methods such as segmentation and permission restrictions.

Step 1: what kind of data is this?

Start with data types. Structured data fits a fixed schema, such as database tables of admissions. Unstructured data does not: clinicians' free-text notes, scanned letters, images and email. The research request is mostly structured, but if it includes clinical notes, names and other identifiers can hide anywhere in the text, which makes them far harder to strip out.

Then the categories that carry legal weight. SY0-801 lists health data, personal information, financial data, data about children and minors, intellectual property and legal data under data compliance, with industry standards alongside. SY0-701 used related labels: regulated data, trade secrets, intellectual property, legal and financial information. Patient records are health data and personal information at once, so laws such as the US HIPAA Privacy Rule apply, and records about children may carry extra protections.

Step 2: how sensitive is it? Classification

A classification scheme sorts data by the harm its disclosure would cause, so that controls match. Governments use the scheme in Executive Order 13526: Top Secret for information whose unauthorized disclosure could reasonably be expected to cause exceptionally grave damage to national security, Secret for serious damage, and Confidential for damage. Businesses use their own labels, and the exam lists several:

The patient records are restricted in this scheme. Notice the last row: criticality is about availability and integrity, not only secrecy. A public timetable can still be critical to running trains.

Step 3: in what states will it exist?

Data needs protection in three states:

• At rest: stored on disks, in databases, in backups. Protected by encryption (Lesson 6's full-disk, database and record-level options) and by access control.
• In transit: moving across networks. Protected by TLS, VPNs and other transport encryption.
• In use: loaded in memory while being processed. The hardest state to protect, because programs need the data in usable form. Access control, isolation, and hardware such as the secure enclaves of Lesson 6 help.

The research copy will exist in all three states: stored in the workspace, transferred into it, and loaded while models train. Each needs its own control.

Step 4: does the team need identities at all?

This is the decisive question, and usually the answer is no. A model that predicts readmissions needs diagnoses, dates and outcomes; it does not need names. The protection methods SY0-801 lists let you give researchers useful data without giving them people:

For health data in the United States, the HIPAA Privacy Rule gives two recognized routes to de-identification, in 45 CFR 164.514(b). Under expert determination, a qualified person applies statistical and scientific methods, concludes that the risk of identifying anyone is very small, and documents the method and results. Under safe harbor, the organization removes 18 listed identifiers and has no actual knowledge that the rest could identify someone. The 18 run from names, geographic subdivisions smaller than a state and all date elements except the year, through telephone numbers, Social Security numbers, medical record numbers and IP addresses, to full-face photographs and any other unique identifying number.

So the answer takes shape. Filter to the fields the model needs. Replace medical record numbers with tokens, so the team can link a patient's admissions without knowing who the patient is. Apply safe harbor or an expert determination to the rest. Keep the token vault inside the hospital, out of the research workspace.

So what?: the strongest protection for data is not holding it. Release the minimum, in the least identifiable form that still does the job.

Step 5: who is responsible?

Data needs named people answerable for it. The exam's roles:

• The data owner, usually a senior business leader, is accountable for the data, decides its classification and approves access. Here, the chief medical information officer, perhaps.
• The data custodian stores and maintains the data and applies the controls the owner requires, such as the database and cloud administrators.
• The data steward looks after quality and correct use. NIST's glossary describes stewards as enforcing policies, with functional data managers implementing them and managing day-to-day quality.
• Under privacy law such as the GDPR, the controller determines the purposes and means of processing personal data, and a processor processes it on the controller's behalf, as the UK Information Commissioner's Office explains. A subprocessor is a processor's own supplier. If the hospital uses a cloud workspace, the provider is a processor, and its subcontractors are subprocessors.
• A data operator, in SY0-801's list, is someone who works with the data day to day under these rules, such as the researchers themselves.

Step 6: where may it live, and for how long?

Data handling covers the practical rules. Marking and labeling puts the classification on the data itself, in document headers and metadata, so people and tools such as data loss prevention can recognize it. Data location and data placement decide which regions and systems may hold it, and data sovereignty from Lesson 17 explains why. Geofencing enforces location by refusing access from devices outside an approved area. Endpoints are where much leakage happens, so the research copy should stay in the managed workspace, not on laptops.

The data life cycle runs from creation through management and distribution to retention and disposal. Every stage needs a rule. The research approval should say how long the copy may be kept and how it will be destroyed when the project ends.

How 38 terabytes left through one link

In September 2023 the cloud security firm Wiz described how a public GitHub repository from Microsoft's AI research team told users to download open-source models from an Azure storage link. The link included a shared access signature token that was configured to share the entire storage account, not just the models, and granted full control rather than read-only access. Behind it sat about 38 terabytes of private data, including backups of two employees' workstations containing passwords, secret keys and more than 30,000 internal Teams messages. The token, first committed in July 2020, had had its expiry extended to 2051. Wiz reported it on 22 June 2023, and Microsoft revoked it two days later.

Every lesson of this step is there. Public data and internal data shared the same placement. The sharing mechanism was scoped to everything, with full control and a near-permanent lifetime. Nothing in the life cycle caught it for three years. Wiz's recommendations follow directly: keep data meant for external sharing in dedicated storage, scope and time-limit sharing tokens, log their use, and scan repositories for leaked tokens.

Common misconceptions

• "Encryption at rest protects data everywhere." It protects stored data. Data in transit and in use need their own controls, and an authorized user sees decrypted data.
• "Removing names makes data anonymous." Dates, places and rare details can identify people. HIPAA's safe harbor lists 18 identifier types for that reason.
• "Hashing is a safe way to hide any identifier." A value with few possibilities, such as a birth date or a phone number, can be hashed by an attacker for every candidate and matched. Tokenization or expert de-identification fits better.
• "Tokenization and encryption are the same." An encrypted value can be decrypted by anyone with the key; a token has no mathematical link to the original, which exists only in the vault.
• "The cloud provider is the data owner." The organization remains the owner and, for personal data, usually the controller; the provider is a processor.

What to remember

• Data types: structured and unstructured, with legally weighted categories such as health, personal, financial, children's, intellectual property and legal data.
• Classification sorts by harm: Top Secret, Secret and Confidential in government; public to restricted and critical in business.
• States: at rest, in transit and in use, each with its own controls.
• Methods: de-identification, tokenization, masking, hashing, encryption, filtering, transposition, obfuscation and geographic restriction; release the minimum, least identifiable form.
• Roles: owner, custodian, steward, operator, controller, processor and subprocessor.
• Handling and life cycle: labels, location, geofencing, endpoints, and retention and disposal rules; the 2023 Microsoft research exposure shows what happens without them.

Sources

1. Standards for privacy of individually identifiable health information: Other requirements relating to uses and disclosures of protected health information, 45 CFR 164.514. Legal Information Institute, Cornell Law School. law.cornell.edu
2. Executive Order 13526, Classified national security information (2009), Section 1.2. National Archives, Information Security Oversight Office. archives.gov
3. Information Commissioner's Office. (n.d.). What are controllers and processors? UK GDPR guidance. ico.org.uk
4. National Institute of Standards and Technology. (n.d.). Data steward [Glossary entry]. NIST Computer Security Resource Center. csrc.nist.gov
5. McCallister, E., Grance, T., and Scarfone, K. (2010). Guide to protecting the confidentiality of personally identifiable information (PII) (NIST SP 800-122). National Institute of Standards and Technology. csrc.nist.gov
6. Ben-Sasson, H., and Greenberg, R. (2023, September 18). 38TB of data accidentally exposed by Microsoft AI researchers. Wiz Research. wiz.io

Five backup methods, none working

On 31 January 2017, an engineer at GitLab, the code-hosting company, ran a command against the wrong database server while fixing a replication problem. About 300 gigabytes of production data disappeared before he stopped it. The company's public postmortem, published on 10 February, is one of the most honest documents in the industry. The daily database backups had been failing silently for some time. The backup script used an older version of the database tools than the database itself, and the emails reporting the failures were being rejected. Cloud disk snapshots were not enabled for the database servers, and no one owned testing the backups.

What saved the company was luck: an engineer had happened to take a manual snapshot about six hours earlier. GitLab restored from it and lost roughly six hours of database records, including thousands of projects and comments and about 700 user accounts. Copying the data from slow staging disks stretched the restore to about 18 hours.

This lesson is a procedure for not needing luck. You will set recovery targets for a small firm, design backups, sites and redundancy to meet them, test the plan, and then rerun it with one input changed, as GitLab's day changed theirs.

Exam objectives: SY0-801 3.4 in full, including the recovery metrics RTO, RPO, MTTR and MTBF. On SY0-701 this is 3.4, with the metrics in 5.2 under business impact analysis, and it also names geographic dispersion, journaling, replication and continuity of operations.

Step 1: decide what "recovered" means

Recovery planning starts with a business impact analysis (BIA): which functions matter, and how fast harm grows when they stop. NIST's contingency planning guide, SP 800-34, supplies the vocabulary. The recovery point objective (RPO) is the point in time to which data must be recovered after an outage: in practice, how much recent data you can afford to lose. The recovery time objective (RTO) is the overall length of time a system's components can be in the recovery phase before the outage harms the mission. The maximum tolerable downtime for the business process sits above both.

Two reliability metrics describe the systems themselves. Mean time between failures (MTBF) is the average operating time between breakdowns of a repairable system. Mean time to repair (MTTR) is the average time to restore it. Together they give a system's expected availability: MTBF divided by MTBF plus MTTR. A server that fails on average every 2,000 hours and takes 5 hours to repair is available 2,000 out of every 2,005 hours, about 99.75 percent of the time.

Work an example. A 25-person accounting firm decides, after its BIA, that it can lose at most four hours of bookkeeping entries (RPO of four hours), and that the accounting system must be working again within one business day, eight hours (RTO of eight hours). Every later choice follows from those two numbers.

The upshot: RPO sets how often you must copy data; RTO sets how fast you must be able to restore it. Agree both with the business before buying anything.

Step 2: design backups that meet the targets

An RPO of four hours means a copy at least every four hours: nightly backups alone cannot meet it. The firm might take snapshots every hour, with a full backup each night. Then check each design property the exam lists:

• Frequency and scope: how often, and what is included: data only, or whole systems, configurations and the images needed to rebuild them.
• Retention: how long copies are kept, which decides how far back you can reach if damage is discovered late.
• Onsite and offsite: onsite copies restore fast; offsite copies survive fire, flood and theft. A long-standing US-CERT paper summarizes the 3-2-1 rule: keep three copies of important files, one primary and two backups, on two different media types, with one copy offsite.
• Encryption: backups hold everything, so they deserve the same protection as production.
• Immutability: copies that cannot be changed or deleted for a set period, even by an administrator.
• Snapshots, replication and journaling: point-in-time images, continuous copies to another system, and logs of changes that can be replayed. Replication copies mistakes and malware as faithfully as good data, so it complements backups rather than replacing them.
• Restoration testing: the only proof that a backup works.

CISA's #StopRansomware Guide explains why some of these matter so much: ransomware actors hunt for accessible backups to delete or encrypt them, and use stolen credentials to reach backup systems. Its advice is to keep offline, encrypted backups of critical data, test their availability and integrity, and keep golden images of critical systems. It also notes that automated cloud backups may not be enough, because encrypted local files may sync over good copies. It adds that immutable cloud storage should be used with care, since some configurations do not meet certain compliance requirements and misconfiguration can be costly.

Step 3: decide where recovery happens

If the office is lost, where does work continue? NIST SP 800-34 describes the alternate site options:

NIST adds that an alternate site should be in a geographic area unlikely to be affected by the same hazard as the primary, which is geographic dispersion. Environmental considerations such as flood zones, power supply and cooling apply to every site. For the accounting firm, with an eight-hour RTO, a cloud-hosted accounting system or a warm site fits; a cold site does not.

Step 4: build redundancy so small failures stay small

• Load balancing spreads requests across several servers, so no single one is overwhelmed and one can fail without an outage.
• Clustering groups servers that act as one service, with others taking over a failed member's work. Autoscaling adds or removes cloud instances as demand changes. Together these give high availability.
• Platform diversity uses different vendors, hardware or virtualization platforms so one flaw does not stop everything; multicloud applies the idea to providers.
• Storage redundancy, such as RAID arrays that mirror data or add parity across disks, survives a disk failure. It is not a backup: deletion and encryption are mirrored too.
• Power: an uninterruptible power supply (UPS) bridges the seconds or minutes until a generator starts; a redundant power supply (RPS) gives a server a second internal supply; a surge protector absorbs voltage spikes.

Capacity planning checks that people, technology and infrastructure will be sufficient during a disruption: enough trained staff, enough licenses and bandwidth at the alternate site, enough power.

Step 5: test before you need it

Plans fail at the seams, so test in increasing realism. A tabletop exercise walks the team through a scenario in discussion. A simulation rehearses the steps with realistic but non-production conditions. Parallel processing runs the recovery system alongside production on the same inputs and compares results, without switching over. A failover test actually moves service to the backup system. And every backup design needs routine restoration testing, which GitLab's follow-up plan automated.

A disaster recovery plan restores IT systems; a business continuity plan keeps the business running, which can include manual workarounds while systems are down. SY0-701 also used the term continuity of operations.

The second run: change one input

Now rerun the accounting firm's plan with two changes.

Change 1: ransomware instead of a dead disk. The firm's hourly snapshots live on a network storage box that the file server writes to with an administrator account. The ransomware uses that account and encrypts the snapshots too. The design met the RPO on paper and fails in practice. The fix is a copy the attacker cannot reach or change: offline, or immutable, or in an account with separate credentials, as CISA advises.

Change 2: the restore is slower than the backup. The nightly offsite copy is complete, but restoring two terabytes over the office's internet link takes longer than eight hours. The RTO fails even though nothing is lost, exactly as GitLab's slow disks turned a six-hour data loss into an 18-hour outage. The fix is to measure restore time in tests, and to keep a recent local copy or restore directly at the alternate site.

Key idea: a backup plan is proven by restores, against the failure you actually fear, within the time you actually have.

Common misconceptions

• "RAID or replication is a backup." Both copy deletions, corruption and encryption instantly. Backups preserve earlier points in time.
• "Our backup job reports success, so we can restore." GitLab's backups were failing silently. Only a restore test proves recovery.
• "Cloud sync protects us from ransomware." CISA notes that encrypted local files can sync over good copies; versioning, offline or immutable copies are needed.
• "RPO and RTO are the same idea." RPO is how much data you can lose; RTO is how long you can be down. A plan can meet one and miss the other.
• "A hot site is always best." It is the fastest and among the most expensive. The right site is the cheapest one that meets the RTO.

Pulling it together

• RPO limits data loss, RTO limits downtime; availability is MTBF divided by MTBF plus MTTR.
• Backups need the right frequency, scope, retention, encryption and offsite copy (the 3-2-1 rule), plus an offline or immutable copy against ransomware.
• Cold, warm, hot and mirrored sites trade cost against speed; place them apart from the primary's hazards.
• Load balancing, clustering, autoscaling, platform diversity, RAID and power protection keep small failures small.
• Test with tabletops, simulations, parallel processing, failover and restoration tests; GitLab's 2017 outage shows what untested backups cost.

Sources

1. GitLab. (2017, February 10). Postmortem of database outage of January 31. about.gitlab.com
2. Swanson, M., Bowen, P., Phillips, A., Gallup, D., and Lynes, D. (2010, updated November 2010). Contingency planning guide for federal information systems (NIST SP 800-34 Rev. 1). National Institute of Standards and Technology. csrc.nist.gov
3. National Institute of Standards and Technology. (n.d.). Recovery point objective and Recovery time objective [Glossary entries]. NIST Computer Security Resource Center. csrc.nist.gov
4. Cybersecurity and Infrastructure Security Agency, and MS-ISAC. (2023). #StopRansomware guide (Version 3.0). cisa.gov
5. Ruggiero, P., and Heckathorn, M. A. (2012). Data backup options. US-CERT. cisa.gov (PDF)
6. CompTIA. (2025). CompTIA Security+ SY0-801 V8 certification exam objectives (Document version 2.0), objective 3.4. CompTIA (PDF)

Monday's list

You have joined a 60-person design studio as its first security hire. Your manager hands you last week's complaints:

1. A visitor's laptop on the guest Wi-Fi was seen browsing the studio's file server.
2. The client login page received about 50,000 sign-in attempts in one hour from thousands of addresses.
3. A designer downloaded malware from a site whose name was one letter off a font vendor's.
4. A contractor plugged an unknown device into a conference room network port, and it got an address.
5. Someone using a valid account browsed the finance share at two in the morning, and nobody noticed until Thursday.
6. The office Wi-Fi password is written on a whiteboard in the kitchen.

Each complaint has a network control that answers it. This lesson works through them in order, building the controls SY0-801 lists, and ends with the rule-ordering question that appears in so many performance-based items.

Exam objectives: SY0-801 4.1, a scenario objective: segmentation, access controls, firewalls, IDS and IPS, network access control, content filters, DLP, and deception and disruption technology. Lesson 22 covers the endpoint, application, email and operating system half. On SY0-701 this material spans 2.5 (mitigation techniques), 4.5 (firewalls, IDS and IPS, web and DNS filtering, NAC) and the wireless settings in 4.1.

Complaint 1: guests on the file server

The guest Wi-Fi and the file server share one network. The first fix is segmentation: put guests in their own zone with internet access only, as Lesson 18 designed. The second is access control at the boundary, enforced by a firewall.

A firewall applies rules to traffic, and NIST's firewall guide, SP 800-41, sets the governing principle: firewalls should block all inbound and outbound traffic that has not been expressly permitted, a practice it calls deny by default. Rules are usually rule-based access control lists that match source, destination, port and protocol. Most firewalls read them from the top and act on the first match, which is why order matters, as the table at the end of this lesson shows.

NIST distinguishes several technologies. A packet filter looks at each packet's addresses and ports alone. Stateful inspection tracks each connection in a state table, so a packet claiming to be part of an established connection is checked against one that actually exists. These work at layer 4, the transport layer. Application-layer (layer 7) inspection understands protocols such as HTTP, so it can block particular commands or content. A unified threat management (UTM) device combines a firewall with malware detection and other functions in one system. NIST notes the trade-off: simpler management, but one device must do every job well. SY0-701's next-generation firewall (NGFW) adds application awareness and intrusion prevention to a stateful firewall.

In short: segment first, then filter between segments with deny-by-default rules, choosing layer 4 or layer 7 inspection for what each boundary must see.

Complaint 2: a flood at the login page

Fifty thousand sign-in attempts an hour from thousands of addresses is credential stuffing or password spraying at scale. A network firewall sees only allowed web traffic to port 443. The answer sits in front of the application. A web application firewall (WAF), which NIST describes as a specialized firewall in front of a web server, inspects HTTP requests for attack patterns. Rate limiting caps how many requests a client, account or address may make in a period, slowing automated guessing to uselessness. Pair both with MFA and the account lockout rules from Lesson 15.

Complaint 3: one letter off

The designer typed or clicked a typosquatted domain. Two filters would have stopped it. DNS filtering refuses to resolve known malicious or newly registered suspicious domains. In March 2021, NSA and CISA published guidance on choosing a protective DNS service. It described services that use threat intelligence to block queries to identified malicious domains, and noted that in an NSA pilot the service examined more than 4 billion queries over six months and blocked millions of connections to malicious domains.

A content filter (web filter) judges where users may browse by category, reputation and specific block rules. It can run as a centralized proxy that all office traffic passes through, or as an agent-based filter installed on each device, which keeps protecting laptops away from the office. The same family includes data loss prevention (DLP), which inspects outbound content for sensitive data, such as client files or card numbers, and blocks or flags it.

Complaint 4: an unknown device in the conference room

A network port that hands an address to anything plugged into it is an open door. Network access control (NAC) decides which devices may join. The standard behind it, IEEE 802.1X, defines three roles, which RFC 3580 explains in its guidance on using RADIUS with 802.1X. The supplicant is the device seeking access. The authenticator is the switch or access point, which keeps the port closed. The authentication server, usually a RADIUS server, checks the device's credentials and tells the authenticator whether to open the port. SY0-701 calls this port security, with EAP as the authentication framework carried inside it.

NAC can also check endpoint posture or compliance before admitting a device: is it patched, is its endpoint protection running, is its disk encrypted? Devices that fail go to a remediation network. For guests, a captive portal is the web page that must be accepted or completed before limited access is granted.

Worth holding on to: NAC turns every port and access point into a checkpoint: authenticate with 802.1X, check posture, and give guests only what a captive portal grants.

Complaint 5: the two a.m. browser

A valid account browsing the finance share at night may be a compromised account. Two kinds of control help. The first is detection.

NIST's guide to intrusion detection and prevention systems, SP 800-94, describes the methods. Signature-based detection compares activity against patterns of known threats; it is very effective against known threats and largely ineffective against new ones and variants. Anomaly-based detection compares activity against profiles of normal behavior, so it can spot the unusual, such as an account browsing at two a.m. Stateful protocol analysis compares activity against models of how protocols should behave. The guide also names the deployment types: network-based (NIDS, or NIPS when inline and blocking), wireless (WIPS), network behavior analysis, and host-based (HIDS or HIPS). Lesson 18 explained why prevention needs an inline position.

The second is deception and disruption: plant things only an intruder would touch. A honeypot is a decoy system and a honeynet a decoy network. A honeyfile is a decoy file, such as one named for salaries, that alerts when opened. A honeytoken is a decoy credential or record, such as a fake API key planted in code, that alerts when used. A canary account is a decoy user account that no legitimate person ever signs in to. Because no legitimate user should ever touch them, any alert they raise is worth investigating.

Complaint 6: the password on the whiteboard

A shared Wi-Fi password cannot be revoked from one person, and everyone who has ever seen the whiteboard has it. The Wi-Fi Alliance describes WPA3-Personal as giving users increased protection from password guessing, and WPA3-Enterprise as offering higher-grade security for sensitive networks. For an office, enterprise mode authenticates each user or device individually through 802.1X and a RADIUS server, which SY0-701 lists as AAA/RADIUS. Leavers lose access when their account does. A wireless intrusion prevention system (WIPS) watches the airwaves for rogue access points and evil twins.

The rule table that never worked

Performance-based questions often hand you a firewall rule table and a complaint. Here is one: administrators cannot connect to the web server over SSH from the admin network.

Rule 3 is correct but unreachable. The firewall reads from the top, SSH traffic matches rule 2's deny-everything first, and rule 3 never runs. The fix is to move rule 3 above rule 2. The general lesson: specific allow rules go above the final deny-all, which belongs last as the explicit form of deny by default.

Common misconceptions

• "A firewall at the edge is enough." Without internal segmentation, one compromised device reaches everything inside. Filter between zones too.
• "A network firewall stops web application attacks." It allows legitimate HTTPS to the web server, and attacks travel inside that traffic. A WAF inspects the requests themselves.
• "Signature-based IDS catches new attacks." NIST notes it is largely ineffective against unknown threats and variants; anomaly detection and deception complement it.
• "Rule order does not matter if every rule is correct." First-match processing means a broad rule above a specific one silently overrides it.
• "Honeypots are for researchers." Honeyfiles, honeytokens and canary accounts are cheap, low-noise alarms for ordinary organizations.

Recap

• Segment networks and filter between zones with deny-by-default, first-match rule sets; choose packet, stateful or layer 7 inspection; UTM and NGFW combine functions.
• WAFs and rate limiting protect web applications from request floods and attacks inside allowed traffic.
• DNS filtering, content filters (proxy or agent-based) and DLP control where users go and what data leaves.
• NAC with 802.1X (supplicant, authenticator, RADIUS server), posture checks and captive portals controls who joins.
• Signature, anomaly and protocol-analysis detection, in NIDS, NIPS, HIDS, HIPS and WIPS form, watch for attacks.
• Honeypots, honeynets, honeyfiles, honeytokens and canary accounts raise high-confidence alarms.

Sources

1. Scarfone, K., and Hoffman, P. (2009). Guidelines on firewalls and firewall policy (NIST SP 800-41 Rev. 1). National Institute of Standards and Technology. nist.gov (PDF)
2. Scarfone, K., and Mell, P. (2007). Guide to intrusion detection and prevention systems (IDPS) (NIST SP 800-94). National Institute of Standards and Technology. nist.gov (PDF)
3. Congdon, P., Aboba, B., Smith, A., Zorn, G., and Roese, J. (2003). IEEE 802.1X remote authentication dial in user service (RADIUS) usage guidelines (RFC 3580). RFC Editor. rfc-editor.org
4. National Security Agency. (2021, March 4). NSA and CISA release cybersecurity information on protective DNS. nsa.gov
5. Wi-Fi Alliance. (n.d.). Security [WPA3 and Wi-Fi Enhanced Open]. wi-fi.org
6. Thinkst. (n.d.). Canarytokens documentation. docs.canarytokens.org
7. Ubuntu. (n.d.). auditctl(8) manual page, Ubuntu 24.04 LTS. manpages.ubuntu.com

A deadline for every sender

On 1 February 2024, Google began enforcing new rules for anyone sending mail to personal Gmail accounts. Every sender had to authenticate its mail with SPF or DKIM. Anyone sending more than 5,000 messages a day to Gmail needed SPF, DKIM and DMARC together, aligned with the domain in the From line, plus one-click unsubscribe for marketing mail. For organizations that had put off email authentication, a control they could postpone became a deadline, because mail that failed the checks could be rejected or sent to spam.

Email is one of five places this lesson hardens. The others are the devices people use, the mobile fleet, the applications and code that run on both, and the operating system underneath. Lesson 21 covered the network half of objective 4.1. This lesson covers the rest, and it treats each place with the same method so the comparison does the teaching.

Exam objectives: SY0-801 4.1, the items on hardening, sandboxing, application control, endpoint security (EDR, XDR, antivirus), mobile device management, repositories (secrets scanning), application security (input validation, secure cookies, static code analysis, code signing), email security (DMARC, SPF, DKIM, BIMI) and operating system security (Group Policy, SELinux). For SY0-701 it covers secure baselines, hardening targets, site surveys and heat maps, mobile deployment models and connection methods, and application security from 4.1; hardening techniques from 2.5; and Group Policy, SELinux, secure protocols, email gateways, file integrity monitoring, EDR and XDR, and user behavior analytics from 4.5.

Five ends, one method

Every end of a system gets the same three steps. First, write down what good looks like. Second, enforce it with a tool, so it does not depend on memory. Third, watch for drift and for attacks that get through anyway. The table lines up the five places this lesson covers.

Key idea: hardening is not a one-time cleanup. It is a written standard, a tool that applies it, and a monitor that tells you when reality has drifted from it.

Baselines: write down what good looks like

A secure baseline is the approved configuration for one class of system, such as "Windows 11 staff laptop" or "Ubuntu web server." SY0-701 gives its life three verbs. You establish it, usually by starting from a published benchmark and adjusting it to your needs. You deploy it with a tool, so every machine of that class matches. You maintain it, re-checking machines and updating the baseline when software, threats or business needs change.

Few teams write a baseline from scratch. The Center for Internet Security publishes the CIS Benchmarks, which it describes as prescriptive configuration recommendations produced by a consensus-based effort of security experts. Its catalog lists more than 100 configuration guides covering operating systems, cloud providers, network devices, databases and more. Government agencies publish similar guides, and vendors publish security baselines for their own products.

The hardening techniques SY0-701 lists in objective 2.5 are the usual contents of a baseline:

• Change default passwords before a device touches a network. Default credentials are published in manuals, and botnets such as Mirai (Lesson 14) were built on them.
• Remove unnecessary software and disable unused ports, protocols and services. Code that is not installed cannot be exploited.
• Install endpoint protection, turn on the host-based firewall, and add a host-based intrusion prevention system where the platform supports one.
• Encrypt storage, especially on laptops and phones that can be lost.
• Patch on a schedule, give accounts least privilege, and use configuration enforcement tools that put drifted settings back.

The same steps apply to every hardening target, but each target has a constraint that shapes how far you can go.

SY0-701 also lists two installation steps for wireless devices. A site survey measures the radio environment before and after access points go in: signal coverage, interference, channel use and neighboring networks. A heat map shows signal strength as colors over a floor plan. For security, both show where coverage spills past the walls into a parking lot, and both help spot access points that should not be there.

Endpoint security: antivirus, EDR, XDR and their neighbors

The exam expects you to tell endpoint tools apart by what they watch and what they can do about it. The last two rows are SY0-701 terms, but they appear in many job descriptions too.

Read the tools as layers, not rivals. Antivirus stops the known. EDR records enough to catch and investigate the unknown. XDR joins the endpoint view to the inbox and the sign-in logs, which matters because most intrusions cross all three. A scenario that mentions a process tree, isolating one laptop, or "fileless" activity points to EDR. A scenario about correlating email, identity and endpoint alerts points to XDR.

Application control and sandboxing

Application control decides which code may run at all. A block list runs everything except what is known to be bad. It is easy to manage and weak against anything new. An allow list runs only what is approved and blocks the rest, so a never-seen executable fails even if no antivirus vendor has a signature for it. Microsoft describes its own application control as changing Windows from a system where all code runs unless antivirus objects into one where code runs only if policy allows it. Microsoft also says plainly that application control does not replace antivirus; you run both.

Windows has two technologies for this: App Control for Business and the older AppLocker. Microsoft notes that application control can cover scripts, installers and batch files, not only programs, and that it pushes interactive PowerShell into a restricted mode. On Windows 11 version 22H2 and later, consumers get Smart App Control, built on the same engine, which allows signed code or code a cloud service predicts is safe and blocks the rest.

Allow-list rules can identify software in three common ways, each with a trade-off:

Sandboxing runs code in an isolated space where it can reach little of the real system. You use sandboxes daily without noticing: browsers isolate each site's code, and phone operating systems give each app its own container. Windows Sandbox, in Pro and Enterprise editions, gives you a disposable desktop that is wiped when closed. Email and web gateways use sandboxes differently. They open a suspicious attachment in a virtual machine and watch what it does, a form of dynamic analysis, before deciding whether to deliver it. Some malware checks for signs of a sandbox and waits, so a clean sandbox result lowers risk without removing it.

Key idea: a block list asks "is this known to be bad?" and an allow list asks "is this known to be good?" The second question protects against code no one has seen before, at the price of maintaining the list.

Mobile devices: MDM, MAM and who owns the phone

Mobile device management (MDM) enrolls a device so the organization can require a passcode and encryption, set a minimum OS version, control app installation, report compliance, and lock or wipe the device remotely. NIST SP 800-124 Rev. 2 notes that remote wipe works on enterprise-owned and employee-owned phones alike. Mobile application management (MAM) works at a smaller scale. It controls the organization's apps and their data without enrolling the whole device, and NIST observes that for BYOD programs, MAM may help with users' privacy concerns about their own phones.

The right controls depend on who owns the device, which is what the deployment models describe. The table follows NIST SP 800-124 Rev. 2.

Sources disagree about one detail of CYOD. NIST describes a device the employee buys from a list the employer approves. Many training materials describe the employer buying the device the employee chose. What every definition shares is the approved list, so on the exam, "pick from a list of approved models" signals CYOD. A COPE device belongs to the organization, and NIST stresses that its data does too, even when personal apps are allowed.

Phones also connect in ways a laptop on a desk does not. Cellular data runs over the carrier's network, outside the organization's control, so protection has to travel with the device. Wi-Fi exposes phones to rogue and look-alike networks (Lesson 14), so policies require trusted networks, WPA3 where possible, and a VPN or Zero Trust access for work traffic. Bluetooth pairing and discoverable mode widen the attack surface, and NIST notes that strictly managed deployments may restrict Wi-Fi and Bluetooth through MDM.

Applications and repositories

Objective 4.1 lists four application security controls and one repository control. Each closes a gap you met as a vulnerability in Lesson 11.

Input validation checks every input against what the application expects, such as type, length, format and range, and rejects the rest. It must happen on the server. Checks in the browser help honest users fix typing mistakes, but an attacker can skip the browser entirely. Validation works alongside, not instead of, output encoding against cross-site scripting and parameterized queries against SQL injection.

Secure cookies are cookies whose attributes limit how they can be stolen or misused. MDN's reference for the Set-Cookie header describes three attributes the exam cares about:

Static code analysis examines source code without running it, flagging patterns such as SQL built by joining strings, unchecked buffers and hard-coded passwords. It finds problems early and cheaply, but it produces false positives and cannot see how the running system behaves, which is why teams pair it with dynamic testing of the running application.

Code signing uses a private key, backed by a certificate from a certificate authority, to sign software. The user's system checks the signature before running or installing the code. A valid signature proves two things: who signed the code, and that it has not changed since it was signed. It does not prove the code is safe. The SolarWinds backdoor in Lesson 10 was signed with the vendor's legitimate certificate, because the attackers inserted it before the signing step.

Secrets scanning searches repositories for credentials such as API keys, tokens and passwords that developers committed by mistake. GitHub's documentation says its scanner checks the entire Git history on all branches and raises an alert for each finding, and it advises rotating an exposed credential immediately. The history is the point. Deleting a key in a later commit leaves it in every earlier commit and every copy anyone made, so the fix is always to revoke and replace the secret.

Email: proving which domain sent a message

Email was designed without sender authentication, so any server can claim any domain. Three DNS-published standards repair this, and a fourth builds on them. Read the table row by row, because exam questions usually hinge on what each one proves and what it does not.

SPF records end with a qualifier for everything not listed. RFC 7208 defines -all as fail and ~all as soft fail, so -all is the stricter ending. A DMARC record's policy is the domain owner's instruction to receivers: none expresses no preference, quarantine marks failing mail as suspicious, and reject says failing mail is not valid use of the domain. The rua address receives aggregate reports that show every server sending as your domain, which is how owners find forgotten legitimate senders before moving to reject.

The DMARC specification changed recently. RFC 7489 described it in 2015 as an informational document. In May 2026 the IETF published RFC 9989, a Standards Track version that replaces RFC 7489 and moves reporting into companion documents. It also drops the old pct tag, used to apply a policy to a percentage of mail, in favor of a t tag for testing mode. Older study materials will still mention pct.

An email gateway, a SY0-701 term, sits in the mail path and applies all of this at once. It checks SPF, DKIM and DMARC on inbound mail, scans for spam and malware, rewrites or checks links, opens attachments in a sandbox, and applies DLP and encryption to outbound mail. Transport matters too. RFC 8314, titled "Cleartext Considered Obsolete," directs mail clients to use TLS: implicit TLS on port 465 for submission (with STARTTLS on 587 during a transition), 993 for IMAP and 995 for POP3.

Key idea: SPF, DKIM and DMARC prove which domain a message came from. They cannot tell you whether that domain is honest, so a lookalike domain that publishes its own records passes all three, and the warning signs of Lesson 9 still matter.

Operating systems: Group Policy, SELinux and AppArmor

Group Policy is how Windows domains enforce baselines. Administrators build Group Policy Objects (GPOs) and link them to sites, domains or organizational units in Active Directory. Each GPO pushes settings to computers or users: password and lockout rules, firewall rules, AppLocker rules, limits on removable storage, update settings. Policies apply in the order local, site, domain, then organizational unit, and later ones win where they conflict. On one machine, gpresult /r shows which policies were applied.

SELinux, the Security-Enhanced Linux used by Red Hat and Fedora, adds mandatory access control. Ordinary Linux permissions are discretionary: a file's owner decides who may use it. Red Hat explains that this model cannot express fine-grained, system-wide rules. Under SELinux, an administrator-defined policy decides what each process may touch, whatever the file permissions say. A compromised web server process can then reach only what the web server's policy allows.

The command getenforce prints the current mode, and denials appear in /var/log/audit/audit.log as entries of type AVC. Ubuntu and some other distributions use AppArmor for the same purpose. Ubuntu installs and loads it by default, confines programs with per-program profiles, and runs each profile in enforce mode (blocks and logs) or complain mode (logs only). The command sudo aa-status lists them.

Choosing secure protocols

SY0-701 objective 4.5 asks you to implement secure protocols by choosing the protocol, the port and the transport. In practice that means replacing a cleartext protocol with its protected version, closing the old port, and adding a protected transport, such as a TLS or SSH tunnel or a VPN, where a protocol cannot protect itself. Most of this table is review from Network+.

Common misconceptions

• "A signed program is a safe program." A signature proves who signed and that nothing changed afterward. Code that was malicious before signing stays malicious, as SolarWinds customers learned.
• "SPF stops anyone from forging our From address." SPF checks the envelope sender. Only DMARC ties the result to the From domain readers see, and only an enforcing policy asks receivers to act.
• "Our DMARC record means we are protected." With p=none, receivers send you reports and do nothing else.
• "An allow list makes antivirus unnecessary." Microsoft says the opposite. Allowed programs can still be exploited, and scripts or documents can carry malicious content.
• "Permissive mode is a safe compromise." Permissive SELinux blocks nothing. It is a troubleshooting setting.
• "We deleted the leaked key, so we are fine." The key remains in the repository's history and in every copy. Revoke and replace it.
• "MDM means IT controls my whole personal phone." MAM and work profiles let an organization manage its own apps and data on a BYOD phone without managing the rest.

What to carry forward

• Every end gets the same method: a written baseline, a tool that enforces it, and monitoring for drift and attack.
• Antivirus stops known malware, EDR records and responds on each endpoint, XDR correlates endpoints with email, identity and cloud, FIM watches files, and UBA watches behavior.
• An allow list blocks the unknown; a block list blocks the known bad. Sandboxes observe untrusted code in isolation.
• MDM manages devices, MAM manages apps and data. COPE devices belong to the organization, BYOD to the employee, and CYOD means choosing from an approved list.
• Validate input on the server, mark cookies Secure, HttpOnly and SameSite, scan code and repositories, and remember that a signature proves origin and integrity, not safety.
• SPF authorizes servers, DKIM signs messages, DMARC aligns them with the From domain and sets the policy, and BIMI adds a logo only after enforcement.
• Group Policy enforces Windows baselines; SELinux and AppArmor confine Linux programs and should stay in enforcing mode.

Sources

1. Google. (n.d.). Email sender guidelines. Gmail Help. support.google.com
2. Center for Internet Security. (n.d.). CIS Benchmarks. cisecurity.org
3. Microsoft. (2026). Application Control for Windows. Microsoft Learn. learn.microsoft.com
4. Howell, G., Franklin, J., Sritapan, V., Souppaya, M., and Scarfone, K. (2023). Guidelines for managing the security of mobile devices in the enterprise (NIST SP 800-124 Rev. 2). National Institute of Standards and Technology. csrc.nist.gov
5. MDN Web Docs. (n.d.). Set-Cookie header. Mozilla. developer.mozilla.org
6. GitHub. (n.d.). About secret scanning. GitHub Docs. docs.github.com
7. Microsoft. (2024). Get-AuthenticodeSignature. PowerShell documentation, Microsoft Learn. learn.microsoft.com
8. Kitterman, S. (2014). Sender Policy Framework (SPF) for authorizing use of domains in email, version 1 (RFC 7208). RFC Editor. rfc-editor.org
9. Crocker, D., Hansen, T., and Kucherawy, M. (Eds.). (2011). DomainKeys Identified Mail (DKIM) signatures (RFC 6376). RFC Editor. rfc-editor.org
10. Internet Engineering Task Force. (2026). Domain-based Message Authentication, Reporting, and Conformance (DMARC) (RFC 9989). RFC Editor. rfc-editor.org
11. Moore, K., and Newman, C. (2018). Cleartext considered obsolete: Use of Transport Layer Security (TLS) for email submission and access (RFC 8314). RFC Editor. rfc-editor.org
12. BIMI Group. (n.d.). FAQs for senders and ESPs. bimigroup.org
13. Red Hat. (n.d.). Getting started with SELinux. In Using SELinux, Red Hat Enterprise Linux 9. docs.redhat.com
14. Canonical. (n.d.). AppArmor. Ubuntu Server documentation. ubuntu.com

Two days in March

On 8 March 2017, the US Computer Emergency Readiness Team publicly identified a vulnerability in Apache Struts, an open-source framework for building web applications. The flaw let an attacker run commands on an affected system. Two days later, according to Equifax, unidentified individuals scanned the company's systems for it. They found the server behind Equifax's online dispute portal, where consumers contest items on their credit reports, still running a vulnerable version. They confirmed they could run commands, and took nothing.

Beginning on 13 May 2017, in what Equifax described as a separate incident, attackers entered the same portal. They stayed for about 76 days. When it was over, the personal information of at least 145.5 million people in the United States had been accessed, including names, Social Security numbers, birth dates and addresses. The US Government Accountability Office (GAO) reconstructed the events in report GAO-18-559, published in August 2018, largely from Equifax's own account.

Equifax's investigation named four factors that let the attack succeed: identification, detection, segmentation of access to databases, and data governance. Almost every one is a stage of the process this lesson teaches. The point of retelling it is not to blame the people who ran those systems. GAO's account describes lists, tools and processes that failed, and those failures are common. They are exactly what asset and vulnerability management exist to prevent.

Exam objectives: SY0-801 4.2 (the asset management life cycle: planning and scoping, acquisition and procurement, assignment and accounting, monitoring and tracking, disposal and decommissioning) and 4.3 (identification methods, prioritization, remediation, verification and internal and external reporting, including bounty programs and responsible disclosure policies). For SY0-701 it covers 4.2, including ownership, classification, inventory, enumeration, sanitization, destruction, certification and data retention, and 4.3, including false positives and negatives, exposure factor, environmental variables, risk tolerance, insurance, compensating controls, exceptions and rescanning. CVE, CVSS and threat feeds were taught in Lesson 8.

Stage 1: Know what you own

You cannot patch a server you do not know about, and you cannot ask its owner to patch it if no owner is recorded. Asset management is the foundation under every later stage. The first of the CIS Controls, version 8.1, makes the same point: actively manage, inventory, track and correct all enterprise assets. Control 2 does the same for software.

SY0-701 adds two words worth separating. An inventory is the authoritative list of what you own. Enumeration is the act of discovering what is actually present, through network scans, IP address records or endpoint agents, so the two can be compared. Every difference is a finding: either the list is wrong, or something is on the network that should not be.

Two of Equifax's failures sit in this stage. After the March notice, Equifax circulated it to its system administrators, but GAO reports that the recipient list was out of date, so the people responsible for patching the portal never received it. That is a failure of assignment: the record of who owned what had drifted from reality. And the device meant to inspect encrypted traffic had an expired digital certificate, which GAO says had lapsed about 10 months before the breach. Certificates, licenses and security tools are assets too, with owners and expiry dates to track.

What matters here: an inventory is a security control only if it records an accountable owner for each asset and is reconciled against what is really running. A list that nobody checks drifts, and the drift is where breaches begin.

Stage 2: Find the weaknesses

Objective 4.3 lists several identification methods. Each sees some weaknesses and misses others, so mature programs combine them.

NIST SP 800-115 explains the first two rows. Some network-based scanners log in to each host with administrator-level credentials and read vulnerability information directly. Others have no credentials, so they discover hosts and probe open ports. NIST adds that internal scans usually find more than external ones, but both viewpoints matter, because an external scan shows what an attacker on the internet can reach.

Every scan result then needs confirmation. NIST warns that scanners can have high false positive rates and that people with networking and operating system expertise should interpret the results. The four possible outcomes form a grid:

Equifax's scan was a false negative. GAO reports that the company scanned its network about a week after the vulnerability was announced, and the scan did not detect it on the dispute portal. False positives cost time. False negatives cost far more, because a clean report ends the search. The defense is overlap: a second method, such as a credentialed scan or an inventory check of every system running the affected software, that would catch what the first one missed.

Stage 3: Decide what comes first

No team can fix everything at once, so findings must be ranked. A CVSS base score from Lesson 8 measures a vulnerability in general. Your priority depends on your environment as well:

• Exposure: is the system reachable from the internet, or isolated in a lab?
• Exploitation: is the flaw in CISA's Known Exploited Vulnerabilities catalog, or does its EPSS score suggest attacks are likely soon?
• Asset value: what data or service would be lost? SY0-701 calls the share of an asset's value lost in one event its exposure factor, a term Lesson 31 puts to work.
• Environmental variables and organizational impact: the CVSS environmental metrics let you adjust a score for your own setting, and a hospital and a game studio weigh the same outage differently.
• Risk tolerance: how much risk leadership has agreed to accept, which sets deadlines for each severity.

Here is how those factors reorder three findings from one week's scans.

Prioritization also means reviewing penetration test reports, which SY0-801 lists by name. A tester's report shows how findings chain: two medium-severity issues that together give an outsider administrator access deserve a critical priority, even though no scanner would rate either one that high.

Stage 4: Fix it, or contain what you cannot fix

NIST SP 800-40 Rev. 4 frames patching as preventive maintenance, a routine cost of running technology rather than an emergency. Patching is the usual remedy, but not the only one.

Equifax's other factors belong here, because they are the controls that could have contained an unpatched flaw. GAO reports that the databases were not segmented from one another, so the attackers moved from the portal to other databases. Their search found a repository holding usernames and passwords in unencrypted form, which opened still more databases. And nothing limited how often the database could be queried, so the attackers ran about 9,000 queries, far more than normal operations needed. Each of those was a missing compensating control.

The detection factor shows what happens when a compensating control silently stops working. GAO reports that once the expired certificate was replaced and traffic inspection restarted, an administrator noticed signs of intrusion within the inspected traffic. That was 29 July 2017.

Stage 5: Prove the fix worked

A ticket marked closed is not a fixed vulnerability. Validation of remediation has three common forms. Rescanning runs the same check again and expects silence, ideally with a credentialed scan that reads the installed version. An audit compares records against reality across many systems at once. Verification confirms the specific fix directly, for example by checking a version number or a configuration file. After the breach, Equifax told GAO it was implementing a new process to identify and patch software vulnerabilities and to confirm that they had been addressed. The last clause is this stage.

Stage 6: Report inside and outside the organization

Internal reporting turns findings into decisions. Useful measures include open critical findings by age, time to remediate against the agreed deadline, the number of open exceptions, and the share of assets scanned at all. Equifax also changed reporting at the top: GAO notes that it created a Chief Information Security Officer who reports directly to the Chief Executive Officer.

External reporting runs in both directions. Outsiders need a safe way to tell you about flaws, which is what a responsible disclosure policy, often called a vulnerability disclosure policy (VDP), provides. CISA's Binding Operational Directive 20-01 of 2 September 2020 required US federal civilian agencies to publish one. Each policy must say which systems are in scope, which testing is allowed, and how to submit a report. It must accept anonymous reports and commit the agency not to recommend or pursue legal action against good-faith research that follows the policy. Lesson 2 explained why that promise matters to a researcher.

A bounty program adds payment. It is a disclosure policy plus rewards, usually scaled to severity, and often run through a platform that handles triage. A smaller signpost helps too: RFC 9116 defines a security.txt file at /.well-known/security.txt on a website, with a required Contact field and an Expires date, so researchers know where to report.

The last stage: disposal and decommissioning

Assets leave as carefully as they arrive. Decommissioning removes the system from DNS, the inventory and monitoring; revokes its certificates and service accounts; and deletes firewall rules that pointed at it. Its storage media must then be sanitized. NIST SP 800-88 Rev. 2, published in September 2025, defines three methods:

Cryptographic erase sanitizes the key that encrypted the data, so the data that remains is unreadable. NIST then recommends a certificate of sanitization for each item, a paper or electronic record of what was done, by whom and how it was checked. That record is the "certification" SY0-701 lists. Data retention rules decide when disposal may happen: keep records as long as law or business requires, then dispose of them on schedule, because data kept without a reason is only risk.

Common misconceptions

• "A clean scan means we are not vulnerable." A scanner can produce false negatives. Equifax's scan missed a vulnerability that was present.
• "The highest CVSS score always goes first." Exposure, active exploitation and asset value can rank a 7.5 above a 9.8.
• "An exception means we decided not to worry about it." An exception is a documented, approved, time-limited acceptance of risk, usually paired with compensating controls.
• "Cyber insurance fixes the vulnerability." Insurance transfers some financial loss. The flaw and the chance of exploitation remain.
• "Formatting a drive sanitizes it." A quick format leaves most data recoverable. Use a NIST method and record it.
• "A bug bounty and a disclosure policy are the same thing." A disclosure policy invites reports and promises safe handling; a bounty adds payment.

Where this leaves us

Asset management records what you own, who owns it and how it will leave. Vulnerability management runs in a loop over that list: identify with overlapping methods, confirm results, prioritize by context, remediate or contain, verify, and report. Equifax's account to GAO touches almost every stage, from an out-of-date recipient list and a false negative scan to missing segmentation, unencrypted credentials and an expired certificate. The next lesson turns to the monitoring that should notice when prevention fails.

Sources

1. U.S. Government Accountability Office. (2018). Data protection: Actions taken by Equifax and federal agencies in response to the 2017 breach (GAO-18-559). gao.gov
2. Scarfone, K., Souppaya, M., Cody, A., and Orebaugh, A. (2008). Technical guide to information security testing and assessment (NIST SP 800-115). National Institute of Standards and Technology. csrc.nist.gov
3. Souppaya, M., and Scarfone, K. (2022). Guide to enterprise patch management planning: Preventive maintenance for technology (NIST SP 800-40 Rev. 4). National Institute of Standards and Technology. csrc.nist.gov
4. Chandramouli, R., and Hibbard, E. (2025). Guidelines for media sanitization (NIST SP 800-88 Rev. 2). National Institute of Standards and Technology. csrc.nist.gov
5. Cybersecurity and Infrastructure Security Agency. (2020, September 2). BOD 20-01: Develop and publish a vulnerability disclosure policy. cisa.gov
6. Foudil, E., and Shafranovich, Y. (2022). A file format to aid in security vulnerability disclosure (RFC 9116). RFC Editor. rfc-editor.org
7. Center for Internet Security. (n.d.). The 18 CIS Critical Security Controls (version 8.1). cisecurity.org
8. Lyon, G. (n.d.). Nmap reference guide. Nmap.org. nmap.org
9. CISOfy. (n.d.). Lynis: Security auditing tool for Linux, macOS, and Unix-based systems. cisofy.com

A rule called Big Yellow Taxi

On 15 June 2023, the security operations center (SOC) of the US Department of State noticed anomalies in access to its email. The next day an analyst saw several alerts from a custom rule the team called "Big Yellow Taxi." The rule read a cloud audit log named MailItemsAccessed, which records access to Exchange Online mailboxes, and it flagged applications touching mailboxes in ways that departed from their usual pattern. State triaged the alerts as a moderate event and, on 16 June, contacted Microsoft.

The alert had uncovered Storm-0558, the intrusion you met in Lesson 6. The Cyber Safety Review Board's 2024 report adds two details that make this a monitoring lesson. First, State had seen false positives from the same rule before, and investigated anyway. Second, State could build the rule only because it had bought an enhanced logging license that, the Board heard, few if any other victims had. The Board recommended that cloud providers give customers a minimum standard of audit logging by default, at no extra charge.

Most monitoring stories run the other way. The log that would have shown the attack was never collected, or the alert fired and nobody acted. This lesson builds the monitoring pipeline piece by piece, then debugs six alerts that went nowhere.

Exam objectives: SY0-801 4.4: monitoring systems, applications and infrastructure; the activities of log aggregation, alerting, scanning, archiving, reporting and alert tuning; tools including benchmarks, agents and agentless collection, SIEM, antivirus, DLP, vulnerability scanners, orchestration and packet analyzers; the protocols NetFlow, SNMP, syslog and SCAP; automated alerts, port mirroring, dashboards and network management systems. For SY0-701 it covers 4.4, including alert response and remediation, quarantine, and SNMP traps.

The monitoring pipeline

Monitoring covers three kinds of resource. Systems are servers, workstations and their operating systems. Applications are the software people use, from a web app to a mail service. Infrastructure is the network and platform underneath: switches, firewalls, hypervisors, cloud control planes. Each produces records, and every record travels the same pipeline.

NIST SP 800-92, the classic guide to log management, describes the aggregation step in detail. Aggregation consolidates similar entries into one entry with a count. Normalization converts each field, especially dates and times, into one consistent format. Correlation finds relationships between entries, most often with rules that match several events from one or more sources. A security information and event management (SIEM) system does all three in one product, along with storage, search, alerting and dashboards.

Why this matters: each stage can fail on its own. An attack can be missed because a record was never collected, never normalized, never matched by a rule, or matched by a rule whose alert nobody read.

The data sources and the protocols that carry them

The exam names four protocols. Each carries a different kind of evidence.

Syslog's severities are worth memorizing, because the numbers run backward from what many people expect. RFC 5424 defines eight levels, and the lowest number is the most severe.

SCAP, the Security Content Automation Protocol, is a suite of NIST specifications that standardize how flaw and configuration information is expressed, so that tools from different vendors can read the same checklists. A benchmark published in SCAP format, such as a hardening baseline from Lesson 22, lets a scanner check hundreds of systems the same way and report the results in a standard form.

Some sources capture traffic itself. Port mirroring, often called SPAN, makes a switch copy traffic from chosen ports or VLANs to a monitoring port, where an IDS sensor or a packet analyzer such as Wireshark reads it. A mirror port can drop packets when the switch is busy; a hardware network TAP copies every packet but must be installed in the cable path. A network management system (NMS) watches the infrastructure itself, polling devices and receiving traps, and draws the maps and status dashboards network teams use.

Security tools are sources too. Antivirus and EDR alerts, DLP alerts, vulnerability scanner results and cloud audit logs all flow into the same pipeline. Orchestration platforms, covered in Lesson 27, then act on alerts automatically.

Agents or agentless?

NIST SP 800-92 compares the two ways a SIEM collects logs.

The review: six alerts that went nowhere

A regional freight company, invented for this lesson but built from failures that public reviews describe again and again, found an intruder only when a customer reported stolen data. Its post-incident review traced six monitoring failures. Debug each one before reading the fix.

Failure 1: the alert went to a mailbox. The EDR raised a high-severity alert on day 3. It was sent to a shared mailbox that the one analyst who read it had left months earlier. Root cause: routing and ownership. Fix: send alerts into a ticketing or on-call system that records who acknowledged each one and escalates when nobody does.

Failure 2: the real alert was one of three thousand. On day 9, the SIEM flagged an administrator logon from an unusual host. That day it raised about 3,000 alerts, most from two noisy rules, and analysts had stopped reading that category. Root cause: alert fatigue. Fix: alert tuning. Measure each rule's share of true positives. Exclude known benign activity narrowly, for example one backup account at one time from one host, rather than muting the whole rule, and add context so each alert explains itself. Big Yellow Taxi had produced false positives too; State's team kept it, refined it and still investigated what it raised.

Failure 3: a source went silent. The forwarding agent on the file server crashed after an update three weeks before the intrusion. No one noticed, because no alert fires when nothing happens. Root cause: no health check on collection. Fix: an automated alert when an expected source stops sending, and a coverage dashboard listing each source and its last event time.

Failure 4: the clocks disagreed. A correlation rule should have linked a VPN logon to a file-server download minutes later. The firewall's clock was seven minutes slow and logged local time, while the servers logged UTC, so the events never lined up. Root cause: time. NIST SP 800-92 lists inconsistent timestamps as a core log management problem and recommends syncing every host's clock to a common time source. Fix: NTP everywhere, and normalization of all times to one zone in the SIEM.

Failure 5: the evidence aged out. When investigators asked how the intruder got in, the first 40 days were gone. The SIEM kept 14 days, and the servers' own logs overwrote themselves within a week. Root cause: no archiving policy. Fix: retention sized to how long intrusions go unnoticed and to legal requirements, with older logs moved to cheaper storage that cannot be altered.

Failure 6: the traffic never met a sensor. The IDS watched the internet link, but the stolen data moved from a server VLAN to a staging host inside the network first. No mirror port or flow export covered that segment. Root cause: a blind spot in collection. Fix: port mirroring or a TAP to the sensor for the server segment, and NetFlow on the core switches so internal transfers show up as unusual flows.

Once the pipeline works, alert response follows the incident process in Lesson 28. For a single endpoint the first step is often quarantine: isolating the device or moving a suspicious file where it cannot run, then confirming the threat is gone before release. Every closed alert should end with a short note on whether the rule needs tuning.

Reporting and dashboards

Reporting turns monitoring into decisions. A dashboard shows current state at a glance: open alerts by severity, sources reporting, scan coverage, mean time to acknowledge. A report shows trends over weeks and months for managers and auditors. The best measures say something about the pipeline itself, not just the attackers: the share of assets sending logs, the share of alerts acknowledged within their target time, and the number of rules tuned or retired this quarter.

Scanning belongs here too. Vulnerability and configuration scans run on a schedule, and their results feed the same dashboards, which is how the vulnerability management loop of Lesson 23 and the monitoring loop of this lesson meet.

Common misconceptions

• "More alerts means better security." Past a point, more alerts means fewer are read. Precise, well-routed alerts beat volume.
• "No alerts means no attacks." Silence can also mean a dead agent, a full disk or a rule that never matched. Monitor the monitoring.
• "Syslog severity 7 is the most serious." It is the least: 7 is debug, and 0 is emergency.
• "NetFlow shows what was in the data." Flow records show addresses, ports, sizes and times. Content needs a packet capture.
• "A rule with false positives should be turned off." Tune it narrowly. Turning it off trades noise for blindness, and State's noisy rule found a nation-state intruder.
• "Logs only need to last a few days." Intrusions often go unnoticed for weeks. Retention has to outlast the time it takes to notice.

What you now know

Monitoring is a pipeline: collect from systems, applications and infrastructure; aggregate and normalize in a SIEM; detect with rules and analytics; respond and tune; report and archive. Syslog carries events, SNMP device state and traps, NetFlow conversation metadata, and SCAP machine-readable checks against benchmarks. Port mirroring and TAPs feed packets to sensors and analyzers. Each stage can fail silently, so a working program watches its own coverage, keeps clocks in sync, keeps logs long enough, routes alerts to someone accountable, and tunes rules instead of muting them. The State Department's rule shows the payoff: one well-built alert on the right log found what the provider itself had missed.

Sources

1. Cyber Safety Review Board. (2024). Review of the summer 2023 Microsoft Exchange Online intrusion. US Department of Homeland Security. cisa.gov
2. Kent, K., and Souppaya, M. (2006). Guide to computer security log management (NIST SP 800-92). National Institute of Standards and Technology. csrc.nist.gov
3. Gerhards, R. (2009). The syslog protocol (RFC 5424). RFC Editor. rfc-editor.org
4. Claise, B. (Ed.). (2004). Cisco Systems NetFlow services export version 9 (RFC 3954). RFC Editor. rfc-editor.org
5. Waltermire, D., Quinn, S., Booth, H., Scarfone, K., and Prisaca, D. (2018). The technical specification for the Security Content Automation Protocol (SCAP): SCAP version 1.3 (NIST SP 800-126 Rev. 3). National Institute of Standards and Technology. csrc.nist.gov
6. Australian Signals Directorate's Australian Cyber Security Centre, with CISA, FBI, NSA and international partners. (2024, August 21). Best practices for event logging and threat detection. cisa.gov
7. Microsoft. (n.d.). Get-WinEvent. PowerShell documentation, Microsoft Learn. learn.microsoft.com
8. Microsoft. (n.d.). auditpol get and wevtutil. Windows commands, Microsoft Learn. learn.microsoft.com
9. Ubuntu. (n.d.). journalctl(1) manual page, Ubuntu 24.04 LTS. manpages.ubuntu.com

"It was a complicated password"

On 8 June 2021, Joseph Blount, chief executive of Colonial Pipeline, testified to a US Senate committee about the ransomware attack that had shut down the company's fuel pipeline a month earlier. As CNN reported, the attackers had entered Colonial's network in April using the password of a disused account on a legacy VPN. Blount told senators it was a complicated password, not a "Colonial123"-type password. Mandiant, the firm Colonial hired to investigate, had confirmed that the account was not protected by multifactor authentication. It was still unclear how the attackers obtained the password. Colonial, Blount said, now used tokens for MFA.

The strength of that password made no difference. Once someone else knew it, nothing else stood in the way. This lesson is about what should stand in the way: a second factor, ideally one that cannot be phished, and a password policy built on evidence rather than habit. It ends with a dispute that the exam objectives themselves reflect, because they list "expiration" and "complexity" as password best practices while current NIST guidance forbids requiring either.

Exam objectives: SY0-801 4.5, the items on MFA (hard tokens, soft tokens, biometrics, one-time passwords, backup codes), authentication, and password concepts (passkeys, password managers, passwordless sign-in, and best practices on length, complexity, reuse, expiration, age, compromised credential monitoring, account auditing and policy reports). For SY0-701 it covers the MFA implementations and factors in 4.6, including security keys and "somewhere you are," and its password concepts. The rest of objective 4.5, from provisioning to access models, is Lesson 26.

Factors and what counts as multifactor

An authentication factor is a category of evidence. Multifactor authentication combines evidence from at least two different categories, so that stealing one kind of evidence is not enough.

Two items from the same category are still single-factor. A password plus a security question is two things you know. A password plus a code from your phone is multifactor, because the phone is something you have.

Biometric systems make two kinds of error. The false acceptance rate measures how often an impostor is accepted, and the false rejection rate measures how often the right person is refused. Tightening a sensor's threshold lowers one and raises the other. The point where the two rates are equal, the crossover error rate, is a common way to compare systems: lower is better.

MFA methods, from weakest to strongest

Not all second factors are equal. CISA's fact sheet on phishing-resistant MFA ranks the common methods, and NIST SP 800-63B-4, published in July 2025, draws the key line: phishing resistance requires cryptographic authentication, and one-time passwords and out-of-band methods such as push or SMS are not considered phishing-resistant.

CISA calls OTP apps and push with number matching the best options for organizations that cannot yet deploy phishing-resistant MFA. A backup code is a one-time recovery code issued when MFA is set up. Stored offline, it lets you sign in if the device is lost without falling back to something weaker, such as SMS.

In short: any MFA beats none, as Colonial shows, but codes a person can read can be relayed by a fake site. Only cryptographic methods bound to the real site resist phishing.

Passkeys and passwordless sign-in

The FIDO Alliance describes a passkey as a password replacement that uses a cryptographic key pair instead of a typed secret. When you create one, your device makes a key pair for that one website. The site stores only the public key, so there is no shared secret on the server to steal. To sign in, the site sends a challenge, your device signs it after you unlock it with the same fingerprint, face or PIN you use for the device, and the site checks the signature. The fingerprint never leaves your device; it only unlocks the key.

Because the browser ties each passkey to the site's real domain, a look-alike phishing site receives nothing it can use. Passkeys come in two forms. Synced passkeys are copied across your devices by a provider such as your phone's platform or a password manager, which makes recovery easy. Device-bound passkeys live on one piece of hardware, such as a security key, and cannot be copied. NIST SP 800-63B-4 allows syncable authenticators at its middle assurance level, AAL2, but not at AAL3, because their keys can be exported.

Passwordless sign-in means no password at all: a passkey, a smart card, or a platform method such as Windows Hello for Business. It removes the most-stolen secret entirely instead of adding a second check on top of it.

The dispute: should passwords expire and need symbols?

For decades, password policy meant complexity rules (an uppercase letter, a digit, a symbol) and forced changes every 30 to 90 days. The exam still lists complexity and expiration as best practices, so you must know what they mean. The question is whether they help.

The case for rotation and complexity. Microsoft's reference page for the Windows "Maximum password age" setting still gives the classic argument: expiry limits how long an attacker can use a stolen password. The setting's default in Windows is 42 days. Microsoft adds that many organizations have compliance or insurance mandates that require short password lifespans. Complexity rules aim to make passwords harder to guess by enlarging the set of possible characters.

The case against. NIST SP 800-63B-4 says verifiers shall not require periodic password changes and shall not impose composition rules. It requires a change only when there is evidence of compromise. The UK's National Cyber Security Centre states that "regular password changing harms rather than improves security," because people respond with minor variations of the old password, and it calls complexity requirements a poor defense against guessing. Even Microsoft's page notes that its recommended security baseline leaves out password expiration, as less effective than modern mitigations.

Where the sides meet. They agree on more than the headlines suggest. Both force a change when a password is known or suspected to be compromised. Microsoft keeps expiry only for organizations without modern defenses, saying those without MFA or password-guessing protection should leave it in effect. Expiry, in other words, stands in for detection. Where you can detect compromise and require MFA, it adds burden without benefit.

Two more exam terms belong to the old model. Password reuse is blocked by remembering a history of old passwords. Password age usually means the minimum age: how long a new password must be kept before it can be changed again. Without a minimum age, a user forced to change can change several times in a row and return to the old favorite, defeating the history.

Lockout belongs in the same conversation. The NCSC prefers throttling, which adds a growing delay after failed attempts, because lockout lets an attacker lock real users out. Where lockout is used, it suggests allowing 5 to 10 attempts.

Managers, monitoring, audits and reports

Password managers make long, unique passwords practical, which is the real defense against reuse and the credential stuffing of Lesson 15. NIST requires verifiers to allow them, and the NCSC recommends them.

Compromised credential monitoring checks passwords and accounts against credentials exposed in breaches, then forces a change or raises an alert on a match. It can be done without revealing the password. The Pwned Passwords service, for example, uses a k-anonymity model: a client sends only the first five characters of a password's SHA-1 hash and receives every stored hash suffix that shares them, then checks for a match locally. The service never learns which password was checked.

Account auditing reviews accounts on a schedule for the conditions attackers love: accounts unused for months, accounts without MFA, shared accounts, and privileged accounts whose passwords never change. Colonial's entry point, a disused account on a legacy VPN without MFA, is exactly what such an audit looks for. A policy report summarizes the results for decision makers: the share of accounts with MFA, the number of exceptions to the password policy, and the dormant accounts disabled this quarter.

Common misconceptions

• "A strong password makes MFA unnecessary." Colonial's password was complicated. A stolen or phished password works no matter how strong it is.
• "Any MFA stops phishing." Codes from SMS, apps or tokens can be typed into a fake site and relayed. Only cryptographic methods bound to the real domain, such as passkeys, security keys and smart cards, resist phishing.
• "Biometrics are sent to the website." With passkeys, the biometric only unlocks a key on your device. The site receives a signature.
• "A password plus a security question is two-factor." Both are something you know.
• "Forced rotation is current best practice." NIST now forbids requiring periodic changes without evidence of compromise. Know the exam terms, and know that the guidance moved.
• "Minimum password age is about how old a password may get." That is the maximum age. The minimum age stops users from cycling through the history to reuse an old password.

The short version

• MFA needs two different factor categories. Rank methods by phishing resistance: SMS and simple push at the bottom, OTP apps and number matching in the middle, passkeys, security keys and smart cards at the top.
• Passkeys replace passwords with a key pair tied to the real site, unlocked locally by a biometric or PIN. Synced passkeys trade some assurance for easy recovery.
• NIST SP 800-63B-4 asks for length, blocklists, password managers and changes on compromise, and forbids composition rules and forced periodic changes. Microsoft and the NCSC agree, while noting that compliance mandates and missing defenses keep expiry alive in some places.
• Know the exam terms: complexity, expiration (maximum age), minimum age, reuse and history.
• Compromised credential monitoring, account audits and policy reports find the weak and forgotten accounts, such as an unused VPN account without MFA.

Sources

1. CNN, republished by KVIA. (2021, June 8). Colonial Pipeline CEO defends his handling of ransomware attack that crippled East Coast fuel supply. kvia.com
2. Temoshok, D., Fenton, J., Choong, Y., Lefkovitz, N., Regenscheid, A., Galluzzo, R., and Richer, J. (2025). Digital identity guidelines: Authentication and authenticator management (NIST SP 800-63B-4). National Institute of Standards and Technology. pages.nist.gov
3. Cybersecurity and Infrastructure Security Agency. (2022, October). Implementing phishing-resistant MFA [Fact sheet]. cisa.gov
4. National Cyber Security Centre. (n.d.). Password policy: Updating your approach. ncsc.gov.uk
5. Microsoft. (2017, updated). Maximum password age. Windows security policy settings, Microsoft Learn. learn.microsoft.com
6. FIDO Alliance. (n.d.). Passkeys. fidoalliance.org
7. M'Raihi, D., Machani, S., Pei, M., and Rydell, J. (2011). TOTP: Time-based one-time password algorithm (RFC 6238). RFC Editor. rfc-editor.org
8. Hunt, T. (n.d.). Have I Been Pwned API v3: Pwned Passwords. haveibeenpwned.com

A password in the wrong profile

Between 28 September and 17 October 2023, an attacker had access to files in Okta's customer support system. Okta sells identity services, so the files mattered: some were HAR files, browser recordings that customers upload to help troubleshoot problems, and some of those contained session tokens. Okta reported that files tied to 134 customers were accessed and that the attacker used session tokens to hijack legitimate sessions of five of them.

The way in was an identity problem. In its root cause report of 3 November 2023, Okta's chief security officer wrote that the attacker used a service account stored in the support system. The account's username and password had been saved into an employee's personal Google account, which was signed in to Chrome on an Okta-managed laptop. The most likely route, Okta said, was a compromise of that personal account or device.

Okta's fixes map onto this lesson. It disabled the service account. It blocked personal Google profiles from signing in to Chrome on managed laptops. It added detection rules, and it bound administrator sessions to network location, so a stolen session token forces a new sign-in when used from somewhere else. The story is about one account type, service accounts, but it touches the life cycle, privileged access and monitoring too.

Exam objectives: SY0-801 4.5, the items on provisioning and deprovisioning, permission assignments and implications, identity proofing, federation, SSO (SAML, LDAP, OAuth), account types (user, privileged global and local, service, third-party, emergency access), access control models (rule-based, role-based, time-based, mandatory, discretionary, just-in-time), access management policies (logical or technical and administrative or business) and access review. For SY0-701 it covers the rest of 4.6, including attribute-based access control, time-of-day restrictions, least privilege, interoperability, attestation and privileged access management tools (just-in-time permissions, password vaulting, ephemeral credentials).

The identity life cycle

Every identity moves through the same stages. Most failures happen at the joins between them.

NIST SP 800-63A-4 describes identity proofing in three steps. Resolution establishes that the applicant is one unique, real person. Validation confirms that the evidence, such as a passport or driver's license, is genuine and accurate. Verification confirms that the applicant is the real owner of that evidence. NIST defines three identity assurance levels: IAL1 for basic assurance, IAL2 for stronger evidence and checks, and IAL3, which requires an in-person session with a trained proofing agent and a biometric.

Proofing does not happen only at enrollment. Every password or MFA reset is a fresh claim of identity. CISA's advisory on the Scattered Spider group, published in November 2023 and revised in July 2025, describes actors posing as employees to persuade IT help desk staff to reset passwords and to move a victim's MFA to a device the attackers control. A help desk that resets MFA on a phone call has, in effect, run an identity proofing process at the weakest level.

Permission assignments have implications beyond the single user. Assigning access through groups or roles keeps it consistent and reviewable. Assigning it directly to individuals scatters it where nobody will find it. Some combinations are dangerous even when each permission is reasonable alone, such as the right to create a vendor and the right to approve payments to it. Separating those duties between two people is an administrative control that technical permissions enforce.

Account types and what each needs

Okta's service account shows why service accounts are a category of their own. A password that a person can see, copy and save will end up somewhere it should not. Managed service accounts, such as the group managed service accounts of Lesson 18, and secrets kept in a vault remove the person from the loop.

Emergency access accounts invert some usual rules. Microsoft's guidance for its Entra ID cloud directory recommends at least two of them, cloud-only rather than federated, so an outage at the identity provider cannot lock them out. They should use a phishing-resistant method such as a FIDO2 passkey or certificate-based authentication, different from the methods normal admins use. They should be excluded from sign-in policies that could block them in the emergency they exist for, and every sign-in should trigger an alert and a review.

Remember: match the control to the account type. A person gets MFA and least privilege; a service gets credentials no person handles; a privileged role gets just-in-time activation; an emergency account gets a vault, a different strong method and an alarm.

Federation and single sign-on

Single sign-on (SSO) lets a user authenticate once and reach many applications. Federation extends that trust across organizations: an identity provider (IdP) vouches for the user, and service providers that trust the IdP accept its word. The exam names three technologies, and a fourth completes the picture.

RFC 6749, which defines OAuth 2.0, describes it as a way for a third-party application to obtain limited access to a service. The words to notice are limited and access: OAuth grants scopes, such as read-only calendar access, and the user's consent screen lists them. Attackers abuse this too. A malicious app that tricks a user into granting broad scopes receives a token that works without the user's password and survives a password change. Reviewing which apps hold grants on your accounts is part of this lesson's lab.

Interoperability, a SY0-701 term, is the reason these standards exist: a company's IdP can serve hundreds of applications from different vendors only because they all speak SAML or OpenID Connect.

Access control models compared

Once a user is authenticated, an access control model decides what they may do. The exam expects you to recognize each model from a scenario.

NIST SP 800-162, the federal guide to ABAC, explains why the attribute model matters: it can express rules that would need an explosion of roles in RBAC. In practice, organizations combine models. RBAC sets the baseline, ABAC-style conditions refine it, and JIT governs the most powerful roles.

Two more principles sit under every model. Least privilege grants only what a task needs. Access management policies come in two kinds: logical or technical policies that systems enforce, such as a sign-in rule requiring MFA from unmanaged devices, and administrative or business policies that people follow, such as "a manager approves every access request."

Privileged access management

Privileged access management (PAM) tools protect the accounts that can do the most damage. SY0-701 names three features.

• Just-in-time permissions. Microsoft describes its Privileged Identity Management service as giving users just-in-time privileged access, with time-bound assignments, approval and MFA required to activate a role, a written justification, notifications, access reviews and audit history. An "eligible" admin holds no power until activation, so a stolen account is worth far less.
• Password vaulting. Privileged passwords live in a vault. Admins check them out for a session, the vault records who did, and it changes the password afterward.
• Ephemeral credentials. Short-lived keys or tokens issued for one task, which expire on their own, so there is no long-lived secret to steal.

Access reviews and attestation

An access review asks the people who understand a resource, usually the data owner or the user's manager, to confirm each person's access is still needed. SY0-701 calls the signed confirmation attestation. Reviews catch privilege creep, forgotten third-party accounts and service accounts with no owner. They work only when reviewers see something they can judge, such as "Dana: approve payments, granted 2023 in Finance, now in Marketing," rather than a list of cryptic group names.

Common misconceptions

• "OAuth is a login protocol." OAuth 2.0 delegates authorization through access tokens. OpenID Connect adds the authentication layer.
• "SSO means one password everywhere." SSO means one authentication at a trusted identity provider; the applications never see the password.
• "Service accounts are low risk because no one logs in as them." Okta's breach began with a service account password stored where an attacker could reach it.
• "Role-based and rule-based are the same." Roles depend on who you are; rules apply to everyone, like a firewall rule or a country block.
• "Emergency accounts should follow every sign-in policy." They are excluded from blocking policies so they work in an outage, which is why they need strong methods and an alarm on every use.
• "Changing my password removes an app's access." An OAuth token keeps working until the grant is revoked.

Looking back

Identity has a life cycle: proof, provision, adjust, review and deprovision, with every reset treated as a new proofing event. Account types need different controls, and service and emergency accounts break the usual patterns. SAML carries assertions for enterprise SSO, OAuth delegates limited access, OpenID Connect adds sign-in on top of OAuth, and LDAP queries the directory. Access models range from owner-decided DAC to label-driven MAC, role-based, rule-based, attribute-based, time-based and just-in-time. PAM tools, access reviews and alerts on powerful accounts keep privilege small, temporary and watched. Okta's incident shows how one stored password for one service account can undo all of it.

Sources

1. Bradbury, D. (2023, November 3). Unauthorized access to Okta's support case management system: Root cause and remediation. Okta Security. sec.okta.com
2. Cybersecurity and Infrastructure Security Agency and Federal Bureau of Investigation. (2023, November 16; revised 2025, July 29). Scattered Spider (AA23-320A). cisa.gov
3. National Institute of Standards and Technology. (2025). Digital identity guidelines: Identity proofing and enrollment (NIST SP 800-63A-4). pages.nist.gov
4. Hardt, D. (Ed.). (2012). The OAuth 2.0 authorization framework (RFC 6749). RFC Editor. rfc-editor.org
5. OpenID Foundation. (2014). OpenID Connect Core 1.0. openid.net
6. OASIS Security Services Technical Committee. (2008). Security Assertion Markup Language (SAML) V2.0 technical overview. docs.oasis-open.org
7. Hu, V. C., Ferraiolo, D., Kuhn, R., Schnitzer, A., Sandlin, K., Miller, R., and Scarfone, K. (2014, updated 2019). Guide to attribute based access control (ABAC) definition and considerations (NIST SP 800-162). National Institute of Standards and Technology. csrc.nist.gov
8. Microsoft. (2026). What is Privileged Identity Management? Microsoft Learn. learn.microsoft.com
9. Microsoft. (2026). Manage emergency access admin accounts. Microsoft Learn. learn.microsoft.com

Six chores and three people

Picture a credit union with 900 staff and a security team of three. Their week looks like this:

1. About 60 account changes for joiners, movers and leavers, each typed by hand from an HR email. Leavers' accounts sometimes stay active for weeks.
2. Developers create cloud storage and virtual machines by clicking through a console. Every month an audit finds one exposed to the internet.
3. Laptops drift. Users switch off the firewall to make a game work, or pause antivirus to speed up a download, and nobody notices until an audit.
4. Staff report about 300 suspicious emails a week. Each takes an analyst ten minutes to check links, search other mailboxes and open a ticket.
5. Alerts arrive without context, duplicates pile up, and urgent ones wait in the same queue as trivial ones.
6. The team wants to try AI tools but does not know what they should be allowed to do.

Every item is a repeatable task done by people who should be doing harder work. This lesson hands each one to automation, and then asks what can go wrong when a machine does the same thing a thousand times without pausing to think.

Exam objectives: SY0-801 4.6: use cases of automation and scripting (user provisioning, resource provisioning, desired state management, anomaly detection, ticket management); considerations (guardrails, automation logic, process engineering, complexity, financial, process risks, deployment); AI capabilities (agentic, chatbot, predictive analysis, AI-augmented baselines); intended outcomes; SecOps CI/CD; and automation and integration workflows. For SY0-701 it covers 4.7, including security groups, ticket creation and escalation, enabling and disabling services and access, continuous integration and testing, APIs, and the considerations of single points of failure, technical debt and ongoing supportability.

Chore 1: accounts that follow the HR record

User provisioning automation creates, changes and disables accounts from an authoritative source, usually the HR system. A new hire record creates the accounts and adds the person to the security groups for their role. A role change swaps groups. A termination disables everything, revokes sessions and opens a ticket to recover the laptop. The leaver gap of Lesson 26 closes because nobody has to remember. The same pattern covers enabling and disabling services and access: a contractor's access ends on the date in the record, not when someone notices.

The guardrail: automation must not be able to create privileged accounts from an HR field alone. Privileged roles still need an approval step.

Chore 2: infrastructure from templates

Resource provisioning automation builds servers, networks and storage from code templates rather than console clicks, the infrastructure as code of Lesson 17. A template that always blocks public access means every bucket starts safe. Policy checks run before anything is created and reject a template that opens a database to the internet. This is how automation delivers standard infrastructure configurations and lets an organization scale in a secure manner, in SY0-701's words: the hundredth server is configured exactly like the first.

Chore 3: settings that put themselves back

Desired state management means declaring how a system should be configured and letting a tool check and restore that state on a schedule. Group Policy and MDM (Lesson 22) already work this way for many settings, and configuration management tools extend it to anything scriptable. The first step is detection: a script that compares reality with the baseline and reports drift. The script below does that for three Windows settings and only reads them. You will run and extend it in the lab.

# drift-check.ps1: compare this PC with a small baseline. It only reads settings.
$results = @()
foreach ($p in Get-NetFirewallProfile) {
  $results += [pscustomobject]@{ Check = "Firewall profile " + $p.Name; Pass = ($p.Enabled -eq 'True') }
}
$mp = Get-MpComputerStatus
$results += [pscustomobject]@{ Check = "Defender real-time protection"; Pass = [bool]$mp.RealTimeProtectionEnabled }
$results += [pscustomobject]@{ Check = "Antivirus signatures 3 days old or newer"; Pass = ($mp.AntivirusSignatureAge -le 3) }
$results | Format-Table -AutoSize
$fails = @($results | Where-Object { -not $_.Pass })
if ($fails.Count -gt 0) { "DRIFT: " + $fails.Count + " check(s) failed" } else { "No drift found" }

The same idea for the Ubuntu lab VM, run with sudo:

#!/bin/sh
# drift-check.sh: read-only checks for the lab VM
ufw status | grep -q "Status: active" && echo "PASS firewall active" || echo "FAIL firewall active"
sshd -T | grep -qi "^passwordauthentication no" && echo "PASS SSH passwords off" || echo "FAIL SSH passwords off"
systemctl is-enabled --quiet unattended-upgrades && echo "PASS automatic updates" || echo "FAIL automatic updates"

Automatic correction comes second, after the check has run in report-only mode long enough to show it flags the right things. A fix that runs on the wrong machine is worse than no fix.

Chore 4: a playbook for reported phishing

Orchestration coordinates several tools in one workflow, usually in a security orchestration, automation and response (SOAR) platform, through integrations: the application programming interfaces (APIs) each tool exposes. A phishing playbook might run like this:

1. Parse the reported email: sender, links, attachments, headers, SPF, DKIM and DMARC results (Lesson 22).
2. Check links and attachment hashes against threat intelligence and detonate unknown attachments in a sandbox.
3. Search every mailbox for copies of the same message.
4. Open a ticket with all the evidence attached and a suggested verdict.
5. If the verdict is malicious and an analyst approves, pull every copy from every mailbox, block the sender and links, and thank the reporter.

Steps 1 to 4 run in seconds. Step 5 waits for a person, because deleting mail from 900 mailboxes on a wrong verdict would be a self-inflicted outage.

Chore 5: tickets that route themselves

Ticket management automation creates a ticket for each alert, enriches it with asset owner, data classification and related alerts, merges duplicates, assigns it to the right queue, and escalates when nobody acknowledges it in time. It fixes the first failure of Lesson 24, the alert sent to a mailbox nobody read. Reaction time, one of SY0-701's listed benefits, improves because the routine work of finding context is done before a person looks.

Chore 6: what AI should and should not do

SY0-801 names four AI capabilities for security operations.

Agents deserve the most care. OWASP's 2025 list of risks for LLM applications calls the problem excessive agency: damaging actions taken in response to unexpected, ambiguous or manipulated model output. It traces it to three causes, excessive functionality, excessive permissions and excessive autonomy, and recommends the matching fixes: give the agent only the tools it needs, give those tools only the access they need, require a person to approve high-impact actions, and enforce authorization in the downstream systems rather than trusting the model's judgment. Lesson 16 showed why: an agent that reads attacker-controlled email can be steered by instructions hidden in it.

Bottom line: automate the steps that are repetitive and reversible; put a person, an approval or a staged rollout in front of the steps that are destructive or hard to undo.

The considerations: what automation costs

SY0-701 adds technical debt and ongoing supportability: scripts written quickly by one person become a burden when that person leaves or an API changes. Lesson 4's CrowdStrike outage is the deployment lesson in its purest form. One automated content update reached millions of machines at once, and CrowdStrike's fix was a staged rollout that sends new content to a small canary group first.

The intended outcomes justify the effort when the considerations are handled: efficiency and time saved, baselines enforced continuously, productivity, reduced downtime, continuous improvement as playbooks are refined, and more proactive work, because people freed from toil can hunt threats. SY0-701 also lists employee retention and calls automation a workforce multiplier.

SecOps in the pipeline: CI/CD

Continuous integration merges each developer's changes often and builds and tests them automatically. Continuous deployment (or delivery) moves tested builds toward production automatically. Security belongs inside that pipeline as required checks: static analysis, scanning of dependencies for known vulnerabilities, secrets scanning, infrastructure-as-code checks, and code signing at the end (Lesson 22). A change that fails a check does not merge.

The pipeline is also a target, because it holds signing keys and deployment credentials and its output is trusted everywhere. The SolarWinds attack of Lesson 10 succeeded by tampering with a build. NIST's Secure Software Development Framework, SP 800-218, sets out practices for producing secure software, grouped under preparing the organization, protecting the software, producing well-secured software and responding to vulnerabilities. NIST SP 800-204D gives strategies for building software supply chain security into CI/CD pipelines, and CISA and NSA issued joint guidance on defending CI/CD environments in June 2023.

Common misconceptions

• "Automation removes human error." It removes some errors and repeats others thousands of times. Guardrails and staged deployment are what limit the damage.
• "Automate everything at once." Start with detection and enrichment, prove accuracy, then automate actions, beginning with reversible ones.
• "An AI agent can be trusted with admin rights if the model is good." OWASP's advice is to limit tools and permissions and require approval for high-impact actions, whatever the model.
• "Orchestration and automation are the same." Automation performs a task; orchestration coordinates many automated tasks across tools into one workflow.
• "CI/CD security means scanning the code." The pipeline itself, its credentials and its build steps need protecting too.

Putting it together

Each of the credit union's chores maps to a use case: provisioning from HR, resources from templates, desired state for drift, a SOAR playbook for phishing, automated ticket handling, and AI capabilities with matching controls. The considerations decide whether automation helps or hurts: guardrails, sound logic, a process worth automating, manageable complexity and cost, an honest view of process risk, and careful deployment. CI/CD pipelines carry security checks into every change, and they need protecting in turn. Done well, automation turns a three-person team into one that spends its time on judgment instead of repetition.

Sources

1. Souppaya, M., Scarfone, K., and Dodson, D. (2022). Secure Software Development Framework (SSDF) version 1.1 (NIST SP 800-218). National Institute of Standards and Technology. csrc.nist.gov
2. Chandramouli, R., Kautz, F., and Torres-Arias, S. (2024). Strategies for the integration of software supply chain security in DevSecOps CI/CD pipelines (NIST SP 800-204D). National Institute of Standards and Technology. csrc.nist.gov
3. Cybersecurity and Infrastructure Security Agency. (2023, June 28). CISA and NSA release joint guidance on defending continuous integration/continuous delivery (CI/CD) environments. cisa.gov
4. OWASP GenAI Security Project. (2025). LLM06:2025 Excessive agency. genai.owasp.org
5. CrowdStrike. (2024, August 6). External technical root cause analysis: Channel File 291. crowdstrike.com
6. Microsoft. (n.d.). Get-MpComputerStatus and Get-NetFirewallProfile. PowerShell module reference, Microsoft Learn. learn.microsoft.com

Nine days in February

On 12 February 2024, criminals used compromised credentials to sign in to a Citrix portal that gave remote access to desktops at Change Healthcare, a company that processes health insurance claims and payments across the United States. The portal did not have multifactor authentication. Over the next nine days the intruders moved through Change's systems and copied data out. On 21 February they deployed ransomware.

Change Healthcare had been bought by UnitedHealth Group in 2022, and by its own account touched about one in three US patient records. Its platform was brought to a standstill for more than a month, and pharmacies, hospitals and doctors' offices across the country struggled to process claims and get paid. On 1 May 2024, UnitedHealth's chief executive, Andrew Witty, submitted written testimony to a subcommittee of the House Energy and Commerce Committee. The portal facts above come from it. So does one sentence about the hardest choice of the response: as chief executive, he wrote, the decision to pay a ransom was his. He also described the rebuilding that followed: laptops replaced, credentials changed, the data center network and core services rebuilt.

This lesson follows an incident through every phase the exam lists, using what Witty's testimony and the reporting on it made public. The point is not to second-guess the responders, who faced an attack on a scale few organizations ever see. It is to understand what each phase asks of an organization, so that yours is ready before its own February.

Exam objectives: SY0-801 4.7: preparation (training, testing, tabletop exercises, playbooks, simulation, roles), identification (detection, internal and external advisories, threat hunting), investigation (digital forensics, chain of custody, e-discovery, preservation), containment (quarantine and isolation), negotiation, eradication and recovery, notification and external reporting (stakeholders, customers, law enforcement, mandatory reporting) and post-incident work (lessons learned, root cause analysis, post-incident reports). For SY0-701 it covers 4.8: the process from preparation to lessons learned, training, tabletop and simulation testing, root cause analysis and threat hunting. Forensics in depth is Lesson 29.

One process, three ways to draw it

Incident response has been drawn in several ways, and the exam versions differ. SY0-701 uses seven steps: preparation, detection, analysis, containment, eradication, recovery and lessons learned. SY0-801 regroups them and adds two: investigation as its own phase, and negotiation.

NIST changed its picture too. Its 2012 guide, SP 800-61 Rev. 2, drew a four-phase circle. Rev. 3, published in April 2025, explains that the circle fit a time when incidents were rare, narrow and over in a day or two. It now maps incident response onto the six CSF 2.0 Functions. Govern, Identify and Protect are the broader risk management work that prepares for incidents. Detect, Respond and Recover are the response itself. Lessons learned feed an Improvement category that informs everything.

Preparation: the phase that decides the others

Everything that goes well in an incident was usually prepared beforehand.

• Roles. An incident commander who coordinates and decides; technical leads for investigation and recovery; communications, legal and human resources; an executive with authority for business decisions, such as shutting down a service; and a scribe who records decisions and times.
• Playbooks. Step-by-step plans for common incident types, such as ransomware, a lost laptop or a compromised email account, with contacts and decision points.
• Training. Responders practice their tools; staff learn to report what they see.
• Testing. A tabletop exercise walks people through a scenario in discussion, testing decisions, roles and communication without touching systems. A simulation goes further and exercises real tools and procedures against a staged event, such as restoring from backup or isolating a test host. CISA publishes free tabletop exercise packages with scenarios, objectives and discussion questions for topics including ransomware, phishing and insider threats.
• Out-of-band communication. If the attacker may be reading email and chat, responders need phones, a separate messaging system and printed contact lists.

The core of it: an incident tests preparation, not improvisation. Decisions made calmly in a tabletop exercise, such as who may shut down a service or who talks to the press, are the ones that hold up at 3 a.m.

Identification: learning that something is wrong

Incidents come to light in four ways. Detection is the monitoring of Lesson 24 raising an alert. An internal advisory comes from inside: an employee reports a strange email, a help desk sees a run of lockouts. An external advisory comes from outside: the FBI, CISA, a vendor, a customer or a researcher tells you, sometimes before you know anything. Threat hunting is proactive. Analysts start from a hypothesis, often drawn from a new advisory or ATT&CK technique, and search for activity that no alert caught.

Identification also means triage. Not every event is an incident. Responders confirm what happened, judge its scope and severity, and decide whether to invoke the incident plan.

Investigation and containment

Investigation reconstructs what happened from evidence: logs, endpoint records, memory, disk images and network data. It runs alongside every later phase. Its exam terms, digital forensics, chain of custody, e-discovery and preservation, are the subject of Lesson 29. The key rule for now is that evidence should be preserved before it is changed, wherever the situation allows.

Containment stops the spread. Quarantine and isolation are its main tools: disconnect a host, block an account, cut a network segment, take a service offline. CISA's #StopRansomware Guide gives the order of operations for ransomware. Determine which systems are affected and isolate them immediately, at the switch level if many are hit. Isolate in a coordinated way, using out-of-band channels such as phone calls, because an attacker who sees the response coming may spread ransomware faster. For cloud resources, snapshot volumes for later investigation. Power devices down only if they cannot be disconnected, because powering off destroys evidence held in memory.

Containment is also a business decision. Taking a claims platform offline stops the attacker and stops the business at the same time, which is why the authority to do it should be agreed in preparation.

Negotiation

SY0-801 adds negotiation as a phase, and it is one of the hardest. In ransomware and data extortion, criminals demand payment to decrypt data or to not publish stolen data. Organizations sometimes engage specialist negotiators to buy time, verify what was stolen or bargain.

The #StopRansomware Guide, written by CISA and its partners, states plainly that they do not recommend paying. Payment does not ensure that data will be decrypted, that systems will no longer be compromised, or that stolen data will not be leaked. Paying may also carry sanctions risk: the guide points to the US Treasury's Office of Foreign Assets Control (OFAC) advisory of September 2021 on facilitating ransomware payments, and advises contacting the local FBI field office, in consultation with OFAC, about factors that can mitigate penalties. Whatever the decision, it belongs to executives advised by legal counsel and law enforcement, made in an organization where backups and plans give it real options.

Eradication and recovery

Eradication removes the attacker's access. That means closing the way in, resetting every credential the attacker could have touched, removing malware and persistence, and often rebuilding systems from known-good sources rather than cleaning them. Recovery restores service, from backups tested in advance (Lesson 20), and watches closely for signs that the attacker is back. Witty's description of replaced laptops, changed credentials and a rebuilt data center network shows how far eradication can reach when an intruder has had time to spread.

Notification and external reporting

An incident affects people outside the response team, and some of them must be told.

Communications should be accurate, coordinated and approved through the roles set in preparation. Early statements are often wrong in detail, because investigation is still underway; say what is known, what is not yet known and when the next update will come.

Post-incident: lessons learned, root cause and the report

A lessons learned meeting, held soon after the incident while memories are fresh, asks what happened, what worked, what did not and what should change. It works best when it is blameless, focusing on systems and decisions rather than on punishing individuals, because people who fear blame hide the details the organization needs. Root cause analysis keeps asking why until it reaches a cause that can be fixed. For an entry like Change Healthcare's, the chain might run: stolen credentials worked, because the portal accepted a password alone, because MFA had not been applied to that portal. The fix belongs at the last link. The post-incident report records the timeline, impact, root cause, actions taken and improvements, with owners and dates, and feeds back into preparation.

Common misconceptions

• "Unplug everything immediately." Isolate quickly but in a coordinated way, and prefer disconnecting to powering off, which destroys evidence in memory.
• "Paying the ransom ends the incident." CISA's guide says payment ensures neither decryption nor that stolen data stays private, and it may carry sanctions risk.
• "Tabletop exercises and simulations are the same." A tabletop is a discussion; a simulation exercises real tools and procedures.
• "Incident response starts when the alert fires." NIST's 2025 revision places preparation in Govern, Identify and Protect, long before any alert.
• "Lessons learned means finding who to blame." Blameless reviews surface the system fixes; blame hides them.

The takeaway

Incident response is a sequence of decisions: prepare roles, playbooks and practice; identify through detection, advisories and hunting; investigate with preserved evidence; contain by coordinated isolation; treat negotiation with the caution official guidance urges; eradicate and recover from known-good sources; notify the people and authorities who must know; and finish with lessons learned, root cause analysis and a report that changes the plan. Change Healthcare's story began with a remote access portal that accepted a password alone. Every organization can check its own portals for the same gap today.

Sources

1. Greig, J. (2024, April 30). Congress circles UnitedHealth as effects of ransomware attack continue. The Record, Recorded Future News. therecord.media
2. Kapko, M. (2024, April 30). Change Healthcare cyberattack was due to a lack of multifactor authentication, UnitedHealth CEO says. Healthcare Dive. healthcaredive.com
3. Witty, A. (2024, May 1). Written testimony before the Subcommittee on Oversight and Investigations, Committee on Energy and Commerce, US House of Representatives. Washington, DC.
4. Nelson, A., Rekhi, S., Souppaya, M., and Scarfone, K. (2025). Incident response recommendations and considerations for cybersecurity risk management: A CSF 2.0 community profile (NIST SP 800-61 Rev. 3). National Institute of Standards and Technology. csrc.nist.gov
5. Cybersecurity and Infrastructure Security Agency, and MS-ISAC. (2023). #StopRansomware guide (Version 3.0). cisa.gov
6. Cybersecurity and Infrastructure Security Agency. (n.d.). CISA tabletop exercise packages. cisa.gov

Monday, 07:30

This lesson is a procedure: one investigation, worked through in order. The firm and its people are invented for teaching. Every step follows published guidance: RFC 3227 on collecting evidence, NIST SP 800-86 on forensics, and the US Federal Rules of Civil Procedure on preserving electronic evidence.

The firm is a 40-person accounting practice. At 07:30 on a Monday, its EDR console shows an overnight alert. At 02:13 on Sunday, someone signed in to the file server by Remote Desktop from workstation WS-17, using the account of Maria Ortiz, a senior accountant. Twenty minutes later a 2 GB archive of client folders appeared on a share. Maria says she was asleep.

Your job is to find out what happened, in a way that would hold up if the firm had to prove it to a regulator, an insurer or a court.

Exam objectives: SY0-801 4.8: log and trace data types, data sources (vulnerability scans, automated reports, NetFlow and IPFIX, surveillance footage, security tools, dashboards, packet captures), file and log integrity, system images (memory dump, bit-level copy, snapshot), stakeholders (HR, accounts, legal) and log-parsing techniques; and from 4.7, the investigation items: digital forensics, chain of custody, e-discovery and preservation. For SY0-701 it covers 4.9 (log data and data sources) and the forensic items of 4.8: legal hold, chain of custody, acquisition, reporting, preservation and e-discovery.

Step 1: Before touching anything, decide who is involved

An investigation that might end in a firing, a lawsuit or a regulator's inquiry needs the right people from the start. SY0-801 names three stakeholders.

• Legal decides whether litigation or notification is likely, advises on privilege and on contacting law enforcement, and issues a legal hold: a notice that suspends normal deletion of relevant email, files, logs and backups.
• Human resources joins if an employee might be involved, as victim or suspect, so that interviews, suspensions and privacy rules are handled properly. Nobody confronts Maria before HR and legal agree how.
• Accounts: CompTIA's list does not define this one. We read it as the finance or accounts team, which may need to watch for fraudulent payments, freeze transfers, estimate losses and work with the insurer.

The legal hold matters because evidence that should have been kept can cost a case. Rule 37(e) of the Federal Rules of Civil Procedure covers electronically stored information that should have been kept for litigation. It applies when that information is lost because a party failed to take reasonable steps. A court may then order measures to cure the harm. If it finds intent to deprive the other side of the information, it may presume the lost data was unfavorable, or even end the case. E-discovery is the legal process of identifying, preserving, collecting and producing that electronically stored information, and a good investigation makes it possible.

Step 2: Capture the most volatile evidence first

Evidence disappears at different speeds. RFC 3227 lists the order of volatility, from most to least volatile:

1. Registers and cache
2. Routing table, ARP cache, process table, kernel statistics and memory
3. Temporary file systems
4. Disk
5. Remote logging and monitoring data
6. Physical configuration and network topology
7. Archival media

Collect in that order, so that the act of collecting one thing does not destroy another.

For the file server and WS-17, that means three kinds of system image, each with a different job.

The file server is a virtual machine, so the team takes a snapshot that includes memory. WS-17 is a physical PC. The team captures its memory with a forensic tool, then shuts it down and makes a bit-level copy of its disk. The copy is made through a write blocker, a device that lets the disk be read while blocking any writes to it. They compute a SHA-256 hash of each image at acquisition and work only on copies. Lesson 28's advice applies too: disconnecting a machine from the network preserves memory, while powering it off destroys it.

So what? Acquisition order and hashes are what make evidence usable. A memory capture taken after a reboot does not exist, and an image without a hash taken at acquisition cannot be shown to be unchanged.

Step 3: Start the chain of custody

RFC 3227 says the chain of custody must be clearly documented. The record shows how each item was found and handled, who collected, handled or examined it, and who held it and for how long. It also shows when and how custody passed from one person to the next. In practice that is a form for each item, recording a description, its hash, the date and time of each transfer, and a signature for each handoff. Gaps in that record are what opposing lawyers attack, because they leave room for the evidence to have been altered.

Step 4: Gather the log and trace data

SY0-801 lists the kinds of log and trace data an investigator draws on. The right question for each is: what can this source tell me that the others cannot?

Other data sources fill gaps. NetFlow or IPFIX records, IPFIX being the IETF standard that grew from NetFlow, show how much data WS-17 sent and to where, even without packet contents. Packet captures, if a sensor recorded that segment, show the contents. Surveillance footage confirms or rules out a person at a desk. Security tools and their automated reports and dashboards give the alert history, and vulnerability scans show whether WS-17 had an exploitable weakness.

Windows records how a sign-in happened. Microsoft's reference for event 4624 lists the logon types. Among them are type 2 (interactive, at the keyboard), type 3 (network, such as a file share), type 7 (unlock) and type 10 (RemoteInteractive, meaning Remote Desktop). The 02:13 sign-in on the file server was type 10 from WS-17, so someone was using WS-17 to reach the server.

Step 5: Parse, normalize and build the timeline

Raw logs are long, inconsistent and in different time zones. Log-parsing techniques turn them into answers:

• Filter by event ID, account, host and time window.
• Extract fields with a parser or a regular expression, such as the source address from every SSH or VPN line.
• Normalize timestamps to one zone, usually UTC, and names to one format.
• Count and sort to find outliers, such as the address with the most failures.
• Join on shared keys, such as a logon ID that links a sign-in to the processes it started.

Two short examples. On Windows, in an administrator PowerShell, this counts recent successful sign-ins by logon type:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 500 |
  ForEach-Object { (([xml]$_.ToXml()).Event.EventData.Data | Where-Object { $_.Name -eq 'LogonType' }).'#text' } |
  Group-Object | Sort-Object Count -Descending

On Linux, this counts SSH successes and failures by source address:

journalctl -u ssh --since today | grep -E 'Accepted|Failed' | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn

The firm's firewall logs local time, five hours behind UTC, while the servers log UTC. Once normalized, the timeline reads:

The story the evidence tells is credential phishing, then VPN access with a stolen password, then Remote Desktop to the file server, then theft of client data. Maria was a victim, not a suspect, and the badge log and footage helped show it.

Step 6: Prove integrity

Before the report, the team re-hashes every image and log export and compares the results with the hashes recorded at acquisition. Matching hashes show the evidence was not changed. Logs need protection of their own, because an intruder with administrator rights can edit or clear a local log. The usual defenses are forwarding logs to a separate system as they are written, storing archives where they cannot be altered, and hashing exports. They connect directly to the retention advice of Lesson 24.

Step 7: Report

NIST SP 800-86 describes forensics as collection, examination, analysis and reporting. The report states the questions asked and the evidence examined, with its hashes and custody records. It describes the method and the timeline, gives conclusions with their confidence, and names the limits, such as logs that did not exist. It is written for the readers who will act on it: executives, legal counsel, regulators or a court. Here it also recommends the fixes: phishing-resistant MFA on the VPN, restricted Remote Desktop to the file server, and alerts on large outbound transfers.

Common misconceptions

• "Copy the important files and investigate those." A logical copy misses deleted files and unallocated space, and changes access times. Make a bit-level copy and hash it.
• "Shut the machine down to protect the evidence." Shutting down destroys memory, the most volatile evidence. Capture it first.
• "Chain of custody is only for police." Any evidence that might reach a court, regulator or insurer needs a documented chain.
• "Logs are self-explanatory." Time zones, formats and missing sources mislead. Normalize to UTC and note gaps in the report.
• "The account owner is the culprit." An account's activity shows what the credentials did, not who held them. Here physical access logs and email metadata cleared the employee.

Summing up

An investigation that can be defended starts with the right stakeholders and a legal hold. It captures evidence in order of volatility (memory, then disk or snapshot), hashes everything at acquisition, and documents custody at every handoff. It draws on many data types, from VPN accounting and authentication events to badge logs, NetFlow and metadata. Log-parsing techniques filter, extract, normalize and join them into a timeline. It ends by re-verifying integrity and writing a report that states both conclusions and limits.

Sources

1. Brezinski, D., and Killalea, T. (2002). Guidelines for evidence collection and archiving (RFC 3227, BCP 55). RFC Editor. rfc-editor.org
2. Kent, K., Chevalier, S., Grance, T., and Dang, H. (2006). Guide to integrating forensic techniques into incident response (NIST SP 800-86). National Institute of Standards and Technology. csrc.nist.gov
3. Legal Information Institute. (n.d.). Rule 37. Failure to make disclosures or to cooperate in discovery; sanctions. Federal Rules of Civil Procedure. Cornell Law School. law.cornell.edu
4. Microsoft. (2021). 4624(S): An account was successfully logged on. Microsoft Learn. learn.microsoft.com
5. Claise, B., Trammell, B., and Aitken, P. (Eds.). (2013). Specification of the IP Flow Information Export (IPFIX) protocol for the exchange of flow information (RFC 7011). RFC Editor. rfc-editor.org
6. Wireshark Foundation. (n.d.). Sample captures. Wireshark Wiki. wiki.wireshark.org

A sixth function

On 26 February 2024, NIST published version 2.0 of its Cybersecurity Framework. For a decade the framework had five functions: Identify, Protect, Detect, Respond and Recover. Version 2.0 added a sixth and placed it at the center: Govern, in which the organization's cybersecurity risk management strategy, expectations and policy are established, communicated and monitored.

Regulators moved the same way. In July 2023 the US Securities and Exchange Commission adopted rules requiring public companies to describe, in their annual reports, the board's oversight of risks from cybersecurity threats and management's role in assessing and managing them. Security had become a matter for directors, and directors govern through documents: policies that say what must happen, standards that make it measurable, procedures that make it repeatable, and plans for when things go wrong.

Exam objectives: SY0-801 5.1: guidelines (benchmarks, advisories, implementation guides, reference architecture), standards (baselines, passwords, physical security, RFCs, encryption), procedures (standard operating procedures, runbooks), plans (business continuity, disaster recovery) and policies (BYOD, acceptable use, clean desk, information security, incident response, data classification and retention, access control, data disposal, vulnerability disclosure, privacy). For SY0-701 it covers 5.1, including governance structures, external considerations, monitoring and revision, and roles for systems and data.

Five kinds of document, compared

Many standards borrow their verbs from RFC 2119, a short 1997 document that defines requirement words for the internet's own standards. MUST means an absolute requirement and MUST NOT an absolute prohibition. SHOULD means there may be valid reasons to depart from it in particular circumstances, but the full implications must be understood and weighed first. MAY means truly optional. Writing a company standard with those words removes arguments about what "should" was supposed to mean.

The upshot: a policy says what and why, a standard says exactly what counts, a procedure says how, a guideline offers advice, and a plan says what to do when a particular thing happens.

Guidelines, standards and procedures in the exam's terms

Guidelines are often written by someone else and adopted by reference. SY0-801 names four kinds. Benchmarks, such as the CIS Benchmarks of Lesson 22, recommend configuration settings. Advisories, such as CISA's alerts, describe current threats and what to do about them. Implementation guides from vendors and agencies explain how to deploy a product or control securely. A reference architecture, such as NIST's Zero Trust architecture in SP 800-207 (Lesson 18), is a model design to adapt.

Standards turn intent into checkable requirements. A baseline is a standard configuration for a class of system (Lesson 22). A password standard sets length, screening and MFA rules (Lesson 25). A physical security standard sets badge, visitor and camera requirements. An encryption standard names approved algorithms and key lengths (Lesson 5). Organizations also adopt published RFCs as standards, for example requiring mail clients to use TLS as RFC 8314 directs.

Procedures come in three forms that the exam keeps separate.

Plans for bad days

NIST SP 800-34, the federal contingency planning guide, distinguishes several plans. The two the exam names differ in scope.

• A business continuity plan (BCP) focuses on sustaining the organization's mission and business processes, such as payroll or customer service, during and after a disruption.
• A disaster recovery plan (DRP) applies to major, usually physical disruptions that deny access to the primary facility for an extended period. It is focused on information systems and restores them at an alternate site.

The incident response plan of Lesson 28 sits beside them. A ransomware attack may invoke all three: incident response to contain it, disaster recovery to rebuild systems, and business continuity to keep serving customers by other means in the meantime.

The policies the exam names

SY0-701 also lists policies for the software development life cycle and for change management (Lesson 4), and procedures for onboarding and offboarding.

Who governs: structures and roles

Governance is a structure as well as a set of documents. A board of directors holds ultimate oversight, which the SEC rule now asks public companies to describe. Committees, such as a security steering committee with leaders from IT, legal, HR and the business, set priorities and approve policies. Government entities govern public bodies and regulate private ones. Governance can be centralized, with one team setting rules everywhere, which gives consistency at the cost of speed. Or it can be decentralized, with business units setting their own, which gives local fit at the risk of uneven controls.

Roles for systems and data were covered in Lesson 19: the owner accountable for data, the controller who decides why and how personal data is processed, the processor who processes it on the controller's behalf, and the custodian or steward who handles it day to day. Policies must also respond to external considerations: regulatory, legal and industry requirements at local, regional, national and global levels. And every document needs monitoring and revision. CSF 2.0 asks that policy be reviewed, updated, communicated and enforced as requirements, threats, technology and mission change.

Mapping documents to CSF 2.0 Govern

CSF 2.0 divides Govern into six categories. Each is a place to file the documents in this lesson.

Common misconceptions

• "Policies should contain the technical details." Details belong in standards and procedures, which change more often. A policy full of settings goes stale quickly.
• "Guidelines are mandatory." Guidelines advise. A requirement belongs in a policy or standard.
• "A BCP and a DRP are the same document." A BCP keeps business processes going; a DRP restores information systems, typically at an alternate site.
• "Runbooks and playbooks are interchangeable." A runbook performs a technical operation; a playbook guides the response to a type of incident.
• "Once approved, a policy is done." Policies need scheduled review and revision as laws, threats and the business change.

What to remember

• Policy states intent; standards make it measurable; procedures (SOPs, runbooks, playbooks) make it repeatable; guidelines advise; plans prepare for specific situations.
• Guidelines include benchmarks, advisories, implementation guides and reference architectures; standards include baselines, password, physical security and encryption standards, and adopted RFCs.
• A BCP sustains business processes; a DRP restores information systems after a major disruption.
• Know the named policies: information security, AUP, BYOD, clean desk, access control, data classification and retention, data disposal, incident response, vulnerability disclosure and privacy.
• Boards and committees govern, centrally or not; CSF 2.0's Govern Function, with its six categories, organizes the whole effort.

Sources

1. National Institute of Standards and Technology. (2024, February 26). The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29). doi.org
2. US Securities and Exchange Commission. (2023, July 26). SEC adopts rules on cybersecurity risk management, strategy, governance, and incident disclosure by public companies (Press release 2023-139). sec.gov
3. Bradner, S. (1997). Key words for use in RFCs to indicate requirement levels (RFC 2119, BCP 14). RFC Editor. rfc-editor.org
4. Swanson, M., Bowen, P., Phillips, A., Gallup, D., and Lynes, D. (2010, updated November 2010). Contingency planning guide for federal information systems (NIST SP 800-34 Rev. 1). National Institute of Standards and Technology. csrc.nist.gov
5. SANS Institute. (n.d.). Security policy templates. sans.org

One budget, five requests

A community clinic with 30 staff has set aside $40,000 for security next year. Five requests are on the table: replace the old firewall, buy cyber insurance, move the server room out of the basement, add laptop tracking and encryption, and run phishing-resistant MFA for everyone. Each request is reasonable. Together they cost more than the budget.

Risk management is how the clinic decides. It is a procedure, and this lesson walks through it in order: identify what could go wrong, analyze how likely and how bad it is, put numbers on it where possible, choose a treatment, and record the decision where someone will review it. NIST SP 800-30, the federal guide to risk assessments, describes the purpose simply: to give senior leaders the information they need to choose a course of action.

Exam objectives: SY0-801 5.2: risk identification (asset identification, stakeholder ownership), risk assessment (scoring, categorization), risk analysis (impact, likelihood, owner, current mitigations, qualitative versus quantitative), the risk register (communication, reviews), risk treatment (transferring, accepting, avoiding, mitigating) and business-level considerations (business impact analysis, risk appetite, residual risk, stakeholder involvement, management oversight, regulatory and legal factors, SLE, ALE and ARO). For SY0-701 it covers 5.2, including exposure factor, assessment types, key risk indicators, risk thresholds, appetite types, exceptions and exemptions, and risk reporting.

Step 1: Identify assets, owners and risks

Start with what the clinic must protect: the patient records system, the billing system, staff laptops, the server room, the phone system and the clinic's reputation. Each asset gets an owner, a person with the authority and knowledge to decide about its risks. That is stakeholder ownership, and without it risks have no one to act on them.

Then write each risk as a sentence that links a threat, a weakness and an impact. NIST SP 800-30 builds risk from the same parts: threat sources and events, vulnerabilities and predisposing conditions, likelihood and impact. Examples:

• A thief steals an unencrypted laptop from a car, exposing patient records.
• Heavy rain floods the basement server room, destroying the servers.
• A phishing email captures a password, and an attacker diverts a supplier payment.

Step 2: Score and categorize

Qualitative analysis rates likelihood and impact on simple scales, such as 1 (very low) to 5 (very high), and multiplies or combines them into a score. It is fast and needs no loss data, which is why most organizations start here. Categorization groups risks, for example as operational, financial, compliance or reputational, so that the right people see them.

The weakness of qualitative scoring is that a 4 means different things to different people, and scores cannot be added up into dollars. Its strength is that it lets a team rank twenty risks in an afternoon.

Step 3: Quantify where you can

Quantitative analysis puts money on risk with three formulas the exam expects you to calculate.

Worked example 1: laptops. Replacing a laptop and handling the incident costs about $2,500, and a stolen laptop is a total loss, so EF is 100 percent. SLE = $2,500 x 1.0 = $2,500. The clinic has lost four laptops a year on average, so ARO = 4. ALE = $2,500 x 4 = $10,000 a year.

That figure leaves out the larger cost: an unencrypted laptop full of patient data is a reportable breach. Suppose responding to each such breach, with notification and legal advice, would cost $20,000. Then SLE = $22,500 and ALE = $90,000. Full-disk encryption and tracking cost $6,000 a year. Thefts would continue, so the $10,000 equipment loss remains, but encryption removes the breach cost almost entirely. Expected loss falls from about $90,000 to about $10,000, a reduction of $80,000 for $6,000 a year. Few controls pay back that clearly.

Worked example 2: the basement. The server room's equipment is worth $120,000, and a flood would destroy about half of its value, so EF = 50 percent and SLE = $60,000. Floods that reach the basement are expected about once in 20 years, so ARO = 0.05 and ALE = $60,000 x 0.05 = $3,000 a year. Moving the room upstairs costs $45,000 once. Spread over ten years, that is $4,500 a year, more than the $3,000 expected loss it removes, and the nightly cloud backup already limits the damage. On these numbers the move is hard to justify now. It may make sense when the servers are replaced anyway.

The rule behind both examples: a control is worth its price when the reduction in ALE it buys is greater than its annual cost. Exam questions often add a twist, such as an ARO given as "once every four years" (0.25) or an EF given as a fraction of a dollar value.

Worth holding on to: SLE is the cost of one bad day, ARO is how many bad days a year, and ALE is their product. Compare the drop in ALE with the yearly cost of the control.

Step 4: Choose a treatment

No treatment removes risk entirely. What remains after treatment is residual risk, and someone with authority must accept it. Two terms decide how much is acceptable. NIST's glossary, drawing on its enterprise risk guidance, defines risk appetite as the types and amount of risk, on a broad level, an organization is willing to accept in pursuit of value. Risk tolerance is narrower: the readiness to bear the remaining risk after responding to it, which legal or regulatory requirements can shape. A board's appetite might be moderate for new digital services and near zero for patient safety; tolerance turns that into limits, such as "no critical vulnerability on an internet-facing system for more than 14 days."

SY0-701 describes appetite in three styles: expansionary, willing to take more risk for growth; conservative, preferring to avoid it; and neutral, in between. It also uses risk threshold for the level at which a risk must be escalated or treated.

Step 5: Record it in the risk register

A risk register is the living list of risks and decisions. NIST IR 8286 Rev. 1, published in December 2025, describes how risk registers record cybersecurity risk and roll it up from systems to the whole enterprise. A useful register has, for each risk: an identifier, the risk statement, the asset, the risk owner, category, likelihood, impact and score, current mitigations, the chosen treatment, residual risk, the due date for planned actions, a key risk indicator (KRI) that warns when the risk is rising, and the next review date.

The register is a communication tool. It gives management oversight a single place to see what is open and who owns it, and its reviews, scheduled and after major changes, keep it current. SY0-701 distinguishes assessments that are one-time, ad hoc (in response to an event), recurring (on a schedule) or continuous (automated and ongoing).

Business-level considerations

A business impact analysis (BIA) identifies the critical business processes, how their disruption hurts over time, and the recovery targets they need, such as the RTO and RPO of Lesson 20. It tells the risk team which assets matter most. Stakeholder involvement brings clinicians, finance and legal into the scoring so that impact reflects the business, not only IT's view. Regulatory and legal factors set floors: a clinic cannot simply accept the risk of failing to notify patients of a breach, because the law requires notification whatever the cost-benefit math says.

Common misconceptions

• "ALE is what one incident costs." That is SLE. ALE is SLE multiplied by how often per year.
• "Insurance makes the risk go away." Insurance transfers some financial loss. The breach, the downtime and many costs remain.
• "Accepting a risk means ignoring it." Acceptance is a documented decision by an owner with authority, usually time-limited and reviewed.
• "Quantitative is always better." Numbers built on guesses look precise without being accurate. Use them where data exists and qualitative scoring elsewhere.
• "Appetite and tolerance are the same." Appetite is the broad amount of risk sought or accepted; tolerance is the specific acceptable variation or remaining risk.

Pulling it together

Risk management turns a budget argument into a procedure: identify assets, owners and risk statements; score and categorize; calculate SLE, ARO and ALE where data allows; choose to mitigate, transfer, accept or avoid; and record each decision, its residual risk and its owner in a register that is reviewed. For the clinic, the numbers make laptop encryption an easy yes and the server room move a not-yet, while appetite, tolerance, the BIA and the law set the limits within which those numbers count.

Sources

1. Joint Task Force Transformation Initiative. (2012). Guide for conducting risk assessments (NIST SP 800-30 Rev. 1). National Institute of Standards and Technology. csrc.nist.gov
2. Quinn, S., Chua, J., Ivy, N., Gardner, R., Kent, K., Smith, M., and Witte, G. (2025). Integrating cybersecurity and enterprise risk management (ERM) (NIST IR 8286 Rev. 1). National Institute of Standards and Technology. csrc.nist.gov
3. National Institute of Standards and Technology. (n.d.). Risk appetite. Computer Security Resource Center glossary. csrc.nist.gov
4. National Institute of Standards and Technology. (n.d.). Risk tolerance. Computer Security Resource Center glossary. csrc.nist.gov
5. Swanson, M., Bowen, P., Phillips, A., Gallup, D., and Lynes, D. (2010, updated November 2010). Contingency planning guide for federal information systems (NIST SP 800-34 Rev. 1). National Institute of Standards and Technology. csrc.nist.gov

A payroll file on someone else's server

On 5 June 2023, staff at the BBC, British Airways, Boots and Aer Lingus learned that their personal information had been exposed. None of those companies had been hacked directly. The breach was at Zellis, a UK payroll provider they all used. Zellis said a small number of its customers had been affected by a global issue in MOVEit, a third-party file transfer tool. It said all Zellis-owned software was unaffected and that it had disconnected the server running MOVEit.

Two days later, CISA and the FBI published advisory AA23-158A. It described CVE-2023-34362, a previously unknown SQL injection vulnerability in Progress Software's MOVEit Transfer. According to open-source information cited in the advisory, the CL0P ransomware gang began exploiting it on 27 May 2023. The gang installed a web shell called LEMURLOOT, first seen as a file named human2.aspx and designed to masquerade as a legitimate MOVEit file. It then stole data from MOVEit databases and threatened to publish it on a leak site unless victims paid.

Follow the chain. CL0P attacked a product made by Progress. Zellis ran that product. Airlines, broadcasters and retailers trusted Zellis with their payroll. Their employees trusted their employers. Every link was a victim, and none had to make a mistake for the data to leave: the flaw was a zero-day. That is third-party risk. You can outsource a service, but not the consequences when it fails.

Exam objectives: SY0-801 5.3: vendor selection (RFP, RFI, RFQ, expression of interest, due diligence, conflict of interest), agreement types (SLA, SLO, MOU, MOA, NDA, MSA, SOW), vendor monitoring (right to audit, service-level monitoring, vendor registry, vendor assessment, compliance attestation, penetration testing), limitations and constraints, and rules of engagement. For SY0-701 it covers 5.3, including evidence of internal audits, independent assessments, supply chain analysis, work orders, business partners agreements and questionnaires.

The chain of trust

Your vendor's suppliers are sometimes called fourth parties. You may never have heard of them, but your data passes through their products. The federal guide to cybersecurity supply chain risk management (C-SCRM) is NIST SP 800-161 Revision 1. It sets the goal as identifying, assessing and mitigating cybersecurity risks throughout the supply chain, not only at its first link.

Key idea: outsourcing moves work, not accountability. Every vendor that holds your data or connects to your network extends your attack surface, and the time to manage that is before you sign.

Choosing a vendor

Procurement usually moves from open questions to firm offers, and the exam names each document.

Due diligence is the investigation before signing: security questionnaires, independent audit reports and certifications, financial health, references, breach history, where data will be stored and which subcontractors will touch it. A conflict of interest, such as an evaluator who owns shares in a bidder or a relative who works there, must be disclosed, and the person removed from the decision.

Putting it in writing: agreement types

Whatever the document, the security clauses do the work:

• the controls the vendor must maintain;
• a time limit for notifying you of incidents;
• approval or notice before new subprocessors handle your data;
• where data may be stored;
• a right to audit;
• return and verified deletion of data when the contract ends;
• liability for breaches.

Watching the vendor after signing

A vendor that passed due diligence two years ago may not pass it today. Vendor monitoring keeps the picture current.

• Vendor registry. A list of every vendor with the service it provides, the data it holds, its network access, its criticality tier, the products it depends on where known, the contract owner and incident contacts. When a MOVEit-scale advisory lands, the registry tells you in an hour which vendors to call.
• Vendor assessment. Periodic review scaled to the tier: questionnaires for low-risk vendors, document review and interviews for critical ones, and supply chain analysis of what they in turn depend on.
• Compliance attestation. Independent evidence such as a SOC 2 report, which the AICPA describes as an examination of controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy. A Type 1 report describes controls at a point in time; a Type 2 report also tests whether they operated effectively over a period. ISO/IEC 27001 certification is another common form, and SY0-701 adds evidence of the vendor's internal audits.
• Right to audit. The contractual power to inspect the vendor's controls yourself or through an auditor, used when attestations are not enough.
• Service-level monitoring. Measuring actual availability, response times and incident handling against the SLA.
• Penetration testing. The vendor's own test reports, or your test of their service, but only with their written permission under agreed rules of engagement.

Rules of engagement with third parties

Lesson 2's law applies with extra force here. Paying for a service does not authorize you to attack it. Testing a vendor's systems needs written authorization from the vendor, not just from your own managers, with scope, dates, permitted techniques, contacts and a stop procedure. Many cloud and software providers publish testing policies that say what customers may test without asking; read and follow them. Rules of engagement also cover ordinary cooperation: who contacts whom during an incident, how fast, and through which channel.

Limits and constraints

Third-party risk management never has unlimited reach. SY0-801 names the constraints you will meet.

When the advisory lands

AA23-158A gave MOVEit operators specific steps beyond patching. One shows how persistent an intruder can be. If a victim rebuilt the web server but kept the database, accounts the attackers had created could still give them access, so administrators should audit for unexpected administrative accounts. For organizations downstream, like Zellis's customers, the steps are about the relationship. Use the registry to find exposed vendors and ask them directly. Invoke contractual notification duties, assess what data was involved, and tell affected people what happened and what to do.

Common misconceptions

• "The vendor was breached, so it is the vendor's problem." Your data, your customers and often your legal duties are involved. Accountability does not transfer.
• "A SOC 2 report means the vendor is secure." Check its type, scope and period, and whether the service you use was included.
• "Our contract lets us test the vendor." Only if it says so in writing, with scope and rules. Otherwise testing may be unauthorized access.
• "An SLA covers security." SLAs usually measure availability and response. Security obligations belong in specific contract clauses.
• "We only need to assess vendors once." Vendors change products, owners and subcontractors. Monitoring must continue.

Recap

Third-party risk runs down a chain from software makers to service providers to you and the people whose data you hold, as the MOVEit attacks showed. Manage it before signing with RFIs, EOIs, RFPs and RFQs, due diligence and conflict-of-interest checks. Put it in writing with MSAs, SOWs, SLAs and SLOs, MOUs, MOAs and NDAs that contain real security clauses. After signing, rely on a vendor registry, assessments, attestations such as SOC 2, a right to audit, service-level monitoring and authorized penetration testing. Staffing, jurisdiction, cost, lock-in and the limits of attestations constrain every program, which is why tiering vendors by risk is the first step.

Sources

1. Cybersecurity and Infrastructure Security Agency and Federal Bureau of Investigation. (2023, June 7; updated June 16). #StopRansomware: CL0P ransomware gang exploits CVE-2023-34362 MOVEit vulnerability (AA23-158A). cisa.gov
2. Martin, A. (2023, June 5). BBC and British Airways affected by data breach at payroll company Zellis. The Record, Recorded Future News. therecord.media
3. National Institute of Standards and Technology. (n.d.). CVE-2023-34362 detail. National Vulnerability Database. nvd.nist.gov
4. Boyens, J., Smith, A., Bartol, N., Winkler, K., Holbrook, A., and Fallon, M. (2022, updated 2024). Cybersecurity supply chain risk management practices for systems and organizations (NIST SP 800-161 Rev. 1). National Institute of Standards and Technology. csrc.nist.gov
5. AICPA and CIMA. (n.d.). System and Organization Controls: SOC suite of services. aicpa-cima.com

The largest fine, and a smaller dilemma

On 22 May 2023, the European Data Protection Board announced that Ireland's data protection authority had fined Meta Platforms Ireland 1.2 billion euros. The board called it the largest fine ever imposed under the EU's General Data Protection Regulation (GDPR). It was for transferring Facebook users' personal data to the United States on the basis of standard contractual clauses since July 2020. The company was also ordered to bring those transfers into compliance.

Few organizations will face a fine that size, but every organization that holds personal data meets a smaller, daily dilemma. A customer writes: delete everything you have about me. The finance team says tax law requires keeping her invoices. The legal team says a dispute involving her account is heading to court and nothing may be destroyed. Who wins?

This lesson is built around that dispute. Resolving it takes every part of objective 5.4: privacy rights, legal compliance, the roles of controller and processor, and the monitoring that proves the right thing was done.

Exam objectives: SY0-801 5.4: compliance training (data handling, anti-money laundering and counter-terrorism financing, anti-bribery), compliance monitoring (attestations, acknowledgements), consequences of non-compliance (reputational damage, financial, legal, contractual, sanctions, loss of license), privacy (right to be forgotten, opt-in or opt-out, data correction, processing restrictions, processing prevention, controller versus processor, ownership) and legal compliance (legal hold, legal orders, data retention requirements). For SY0-701 it covers 5.4, including internal and external compliance reporting, due diligence and due care, automation, data subjects, data inventory and retention, and legal implications at local, national and global levels.

The rights in play

Privacy laws give individuals, called data subjects, rights over their personal data. The GDPR applies to organizations that process personal data in the EU or offer goods or services to people there. In the United States, privacy rules are mostly sector by sector: health, financial, education and children's data are each covered by different laws. States add their own, such as the California Consumer Privacy Act (CCPA), as amended by the California Privacy Rights Act.

Lesson 19 introduced the roles. The controller decides why and how personal data is processed and answers to the data subject. The processor processes data on the controller's behalf and instructions, such as a payroll provider or a cloud host. When a request arrives, the controller decides; processors help carry it out. The data owner inside the organization is the person accountable for a data set, who signs off on how requests are handled.

The dispute: erase it, or keep it?

The case for erasure. Data that is gone cannot leak, and privacy law is built on keeping only what is needed. GDPR Article 17 requires erasure without undue delay when a ground applies, and the CCPA gives a similar right to delete, extending to the business's service providers. A company that ignores such requests risks fines. Under GDPR Article 83, infringements of data subject rights fall in the higher tier: up to 20 million euros or 4 percent of total worldwide annual turnover, whichever is higher.

The case for keeping. Other laws require records to be kept. The HIPAA Security Rule, for example, requires covered health organizations to keep its required documentation for six years. The clock runs from creation or from when the document was last in effect, whichever is later. Tax, employment and financial laws set their own periods. Litigation adds a stronger duty still. Once a lawsuit is expected, a legal hold suspends deletion, and Lesson 29 showed that courts can penalize the loss of evidence that should have been kept. Legal orders, such as subpoenas, warrants and court preservation orders, can compel an organization to keep or hand over specific data.

How the law resolves it. The two sides are less opposed than they look, because the privacy laws anticipate the conflict.

• GDPR Article 17(3) says the right to erasure does not apply where processing is necessary for compliance with a legal obligation, or for the establishment, exercise or defense of legal claims, among other exceptions.
• The CCPA lets a business keep information it needs to comply with legal obligations, exercise legal rights or defend legal claims.
• Where data must be kept but should not be used, GDPR Article 18 offers a middle path: restriction. Restricted data may be stored but, with narrow exceptions such as legal claims, not otherwise processed.

So the answer to the customer is rarely all or nothing. Erase what no law or claim requires, restrict what must be kept, tell her plainly what was kept, why and until when, and delete it when the obligation ends. Behind that answer sits the boring machinery that makes it possible. A data inventory shows where her data lives, and a retention schedule states how long each type is kept and why.

The point: privacy rights and retention duties are both law. A compliant organization knows what data it holds, why, and for how long, so it can honor erasure where it can, keep what it must, and show its reasoning.

Training: making compliance part of the job

People cannot follow rules they have never been taught. SY0-801 names three training topics.

• Data handling: how to classify, label, store, share and dispose of data according to policy, and how to recognize and route a privacy request.
• Anti-money laundering and counter-terrorism financing (AML/CTF): for finance and customer-facing staff in regulated sectors, how to recognize and report transactions that could disguise criminal proceeds or fund terrorism.
• Anti-bribery: what counts as a bribe, including gifts and payments to officials, and how to report concerns. Laws in many countries, such as the US Foreign Corrupt Practices Act and the UK Bribery Act 2010, make bribery a serious offense for companies as well as individuals.

Monitoring: proving compliance, not just claiming it

Compliance monitoring produces evidence. An acknowledgement is a person's recorded confirmation that they have read and will follow a policy, such as staff accepting the updated acceptable use policy each year. An attestation is a formal statement that requirements are met. It can come from a manager certifying that their team's access is correct, or from an independent auditor, as with the SOC 2 report of Lesson 32. SY0-701 adds due diligence (investigating before acting) and due care (acting as a reasonable organization would to protect what it holds). It also lists automation that checks configurations against requirements continuously, and compliance reporting to internal leaders and external regulators.

Consequences of non-compliance

Common misconceptions

• "The right to be forgotten means deleting everything on request." GDPR and the CCPA both list exceptions, including legal obligations and legal claims.
• "A legal hold is a reason to ignore privacy requests." The hold covers specific records. Everything else is handled normally, and held data should be restricted and released when the hold ends.
• "The processor decides how to answer a data subject." The controller decides; the processor follows instructions and helps.
• "Opt-out consent is fine everywhere." Where GDPR consent is the legal basis, it must be an affirmative opt-in. California's sale and sharing rules use opt-out.
• "Compliance equals security." Compliance is a minimum set by law and contract. An organization can pass an audit and still be breached.

What to carry forward

• Know the privacy terms: right to be forgotten, correction, restriction, prevention (objection or opt-out), opt-in versus opt-out, controller versus processor, ownership.
• Erasure, retention and legal holds are reconciled, not ranked: erase what you can, restrict what you must keep, explain, and delete when the obligation ends.
• Legal holds, legal orders and retention requirements are part of compliance, and a data inventory and retention schedule make them workable.
• Training covers data handling, AML/CTF and anti-bribery; monitoring relies on acknowledgements and attestations.
• Non-compliance costs money, contracts, licenses and reputation, and GDPR's upper tier reaches 4 percent of worldwide turnover.

Sources

1. European Data Protection Board. (2023, May 22). 1.2 billion euro fine for Facebook as a result of EDPB binding decision [Press release]. Brussels.
2. European Parliament and Council of the European Union. (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union. eur-lex.europa.eu
3. Intersoft Consulting. (n.d.). Art. 17 GDPR: Right to erasure ("right to be forgotten") [Unofficial consolidated text; see also Articles 18, 21 and 83 on the same site]. gdpr-info.eu
4. State of California Department of Justice, Office of the Attorney General. (n.d.). California Consumer Privacy Act (CCPA). oag.ca.gov
5. Legal Information Institute. (n.d.). 45 CFR 164.316: Policies and procedures and documentation requirements. Cornell Law School. law.cornell.edu
6. Legal Information Institute. (n.d.). Rule 37. Failure to make disclosures or to cooperate in discovery; sanctions. Federal Rules of Civil Procedure. Cornell Law School. law.cornell.edu

Checking yourself before someone else does

The Center for Internet Security says the first tier of its CIS Controls, Implementation Group 1, is a foundational set of 56 safeguards that it calls essential cyber hygiene, meant for small and medium organizations with limited IT and security expertise. Fifty-six statements, each answerable with yes, partly or no, make one of the simplest security checks there is: a gap analysis. At the other extreme, a penetration test sends skilled people to attack you, with permission, to find out what a real adversary could do.

Between those two lie audits, examinations, assessments and benchmarks, each asking a different question, done by different people, with different independence. Lesson 2 showed what happens when the paperwork around a test is unclear: in 2019 two testers were arrested inside an Iowa courthouse under a contract whose scope was disputed. This lesson compares the ways of checking, so you can pick the right one and set it up properly.

Exam objectives: SY0-801 5.5: data gathering (sampling, questionnaires and surveys, interviews, assertion, and the reference sources MITRE ATT&CK, the Cyber Kill Chain and the Diamond Model of Intrusion Analysis), scoping (audit charter, frequency), engagement types (gap analysis; internal compliance, audit committee and self-assessments; external examinations, assessments, regulatory reviews and independent third-party audits; benchmarking), penetration testing (known, unknown and partially known environments; physical, offensive, defensive and integrated testing; passive and active reconnaissance), frameworks and standards (industry-based, international, region-specific), functional testing and behavioral testing. For SY0-701 it covers 5.5, including attestation.

The ways of checking, compared

The audit committee is a committee of the board that oversees audit, both internal and external, which gives internal audit a reporting line outside the management it examines. Independence is the thread that runs through the table: the further the checker sits from the people checked, the more others will trust the result.

Why this matters: the exam often describes a need, such as reassuring a customer, satisfying a regulator or finding what is missing, and asks for the engagement. Match the question to the checker, and weigh how independent the answer needs to be.

Scoping: charter, frequency and rules

An internal audit function works under an audit charter, a document approved by the board that sets the function's purpose, authority, responsibilities and independence, including its access to records and people. Each engagement then has a scope: which systems, which period, which controls and which methods. Frequency is part of scope. Regulations and contracts often set annual audits, high-risk areas may be reviewed more often, and continuous monitoring (Lesson 24) fills the gaps between audits. For any test that touches systems, the scope is written into rules of engagement and signed authorization, as Lesson 2 required.

Gathering evidence

• Sampling. Auditors rarely test everything. They select a sample, such as 60 of 4,000 user accounts, and test each one, for example for approval and review records. A well-chosen sample supports conclusions about the whole.
• Questionnaires and surveys. Efficient for many respondents, such as vendors or departments, but they record what people say rather than what is true.
• Interviews. Let the auditor probe, ask for examples and notice gaps between policy and practice.
• Assertion. Management's formal claim about its controls, such as "all privileged access is reviewed quarterly." The auditor's job is to test the assertion against evidence, which is why SOC reports include one.
• Reference sources. Frameworks that organize what to look for, including the three attack models below.

Penetration testing

NIST SP 800-115, the federal guide to security testing, describes a four-stage penetration testing method: planning, in which rules are identified and management approval is documented; discovery; attack; and reporting. The exam uses several pairs of terms to describe tests.

The law of Lesson 2 governs all of it. Active reconnaissance and every later step are authorized only by a written agreement with the system owner, with scope, dates and contacts. Practicing these skills belongs in your own lab, never on systems you do not own.

Three models for reading an attack

Assessors and analysts use three reference models. They overlap, but each answers a different question.

Apply all three to the MOVEit attacks of Lesson 32. In kill chain terms, the attackers found exposed MOVEit servers (reconnaissance), prepared an exploit and web shell (weaponization), sent the SQL injection (delivery and exploitation), planted LEMURLOOT (installation), controlled it over the web (command and control), and stole data for extortion (actions on objectives). CISA's advisory maps the same activity to ATT&CK techniques, including T1190, Exploit Public-Facing Application; T1505.003, Server Software Component: Web Shell; and T1041, Exfiltration Over C2 Channel. In Diamond terms, the adversary was CL0P, the capability the exploit and web shell, the infrastructure the servers the attackers used, and the victims the organizations running MOVEit Transfer.

Frameworks and standards to test against

Audits and assessments measure against something. SY0-801 groups frameworks by reach.

• Industry-based: the PCI Data Security Standard, which the PCI Security Standards Council describes as a baseline of technical and operational requirements to protect payment account data, applying to entities that store, process or transmit cardholder data.
• International: ISO/IEC 27001, the standard for information security management systems, used for certification worldwide.
• Region-specific: for example, the UK's Cyber Essentials, which the National Cyber Security Centre calls the minimum standard of cyber security recommended by the government for organizations of all sizes. Its Plus level adds independent technical testing.

Two final terms describe what a test examines. The objectives do not define them, so we read them by their plain meaning. Functional testing checks that a control does what it is supposed to do: MFA actually blocks a sign-in without the second factor, a backup actually restores. Behavioral testing checks how people and systems behave in realistic conditions: whether staff report a simulated phishing email (Lesson 35), or whether monitoring raises an alert when a tester performs a known technique.

Common misconceptions

• "A vulnerability scan is a penetration test." A scan lists possible weaknesses. A penetration test tries to exploit and chain them, under rules, to show real impact.
• "Unknown-environment tests are always best." They mimic outsiders but waste time on discovery. Known-environment tests find more in the same hours.
• "Passive reconnaissance needs no care." It touches no systems, but collecting personal information still raises privacy and legal questions.
• "A self-assessment satisfies a customer who wants assurance." Customers usually want independence: an external audit or attestation.
• "ATT&CK replaced the kill chain." They serve different purposes and are often used together.

Where this leaves us

Organizations check themselves in many ways, from a quick self-assessment or gap analysis against CIS IG1, through internal and external audits, regulatory examinations and benchmarking, to penetration tests that show what an attacker could do. Each needs a charter or scope, a frequency, and evidence gathered by sampling, questionnaires, interviews and tested assertions. Penetration tests vary by what testers know, what they test and which side they play, and always run under written authorization. ATT&CK, the Cyber Kill Chain and the Diamond Model give three lenses on the same attack, and industry, international and regional standards give the yardsticks.

Sources

1. Scarfone, K., Souppaya, M., Cody, A., and Orebaugh, A. (2008). Technical guide to information security testing and assessment (NIST SP 800-115). National Institute of Standards and Technology. csrc.nist.gov
2. Hutchins, E. M., Cloppert, M. J., and Amin, R. M. (2011). Intelligence-driven computer network defense informed by analysis of adversary campaigns and intrusion kill chains. Lockheed Martin. lockheedmartin.com
3. Caltagirone, S., Pendergast, A., and Betz, C. (2013). The Diamond Model of intrusion analysis. Center for Cyber Intelligence Analysis and Threat Research. activeresponse.org
4. MITRE. (n.d.). Exploit public-facing application, technique T1190. MITRE ATT&CK. attack.mitre.org
5. Cybersecurity and Infrastructure Security Agency and Federal Bureau of Investigation. (2023, June 7; updated June 16). #StopRansomware: CL0P ransomware gang exploits CVE-2023-34362 MOVEit vulnerability (AA23-158A). cisa.gov
6. Center for Internet Security. (n.d.). CIS Controls Implementation Group 1. cisecurity.org
7. PCI Security Standards Council. (n.d.). PCI DSS. pcisecuritystandards.org
8. National Cyber Security Centre. (n.d.). Cyber Essentials overview. ncsc.gov.uk

Two large experiments

In 2025, researchers from UC San Diego and the University of Chicago published one of the largest tests of phishing training ever run. Over eight months they sent ten simulated phishing campaigns to more than 19,500 employees of UC San Diego Health. Completing the annual mandatory cybersecurity training was not meaningfully linked to a lower chance of falling for the emails. Training shown right after someone clicked a simulated link reduced the likelihood of clicking by only about 2 percentage points, and three-quarters of employees spent a minute or less on that training page.

A 2022 study by researchers at ETH Zurich reached a similar conclusion from a different direction. Over 15 months with more than 14,000 employees of a partner company, they found that embedded training did not make employees more resilient to phishing, and could even make some more susceptible. But the same study found something hopeful: employees reporting suspicious emails worked as a collective detection system, spotting new phishing campaigns quickly, with participation that lasted.

Meanwhile the attacks keep working. The FBI's Internet Crime Complaint Center recorded about 2.77 billion dollars in reported business email compromise losses in 2024 (Lesson 9). So the question is not whether people matter to security. It is what kind of awareness program actually helps.

Exam objectives: SY0-801 5.6: types of training (initial or onboarding, ongoing, targeted, corrective), delivery mechanisms (learning management system, self-service portals, one-to-one, one-to-many), reporting and monitoring of effectiveness (metrics, managerial reports, personnel behavior risk scoring) and common training topics (social engineering, emerging security topics, password and credential management, remote and hybrid work, BYOD, business email compromise, removable media and cables, situational awareness, operational security). For SY0-701 it covers 5.6, including phishing campaigns, recognizing and responding to reported messages, anomalous behavior recognition, insider threat, policies and handbooks, and program development and execution.

The dispute: does phishing training work?

The case against. The two studies above are large, long and realistic, and they found little benefit from the most common forms of training: an annual module and a lesson shown after a click. The UC San Diego researchers concluded that technical measures deserve more weight, pointing to two-factor authentication and to password managers that fill in credentials only on the correct domain. A password manager will not type your password into a look-alike site, however convincing it is.

The case for. Awareness programs do more than teach people to spot bad links. NIST SP 800-50 Rev. 1, published in September 2024, treats security and privacy learning as a managed program with a life cycle and with metrics to evaluate and improve it. The UK's National Cyber Security Centre places helping users identify and report phishing as one layer of four, alongside stopping phish before they arrive, limiting the damage of those that get through, and responding quickly. Many topics on the exam's list are procedures, not perception: how to verify a change of bank details, what to do with a found USB drive, how to report a lost phone. Those can be taught and checked.

Where the evidence points. The sides agree more than the headlines suggest. The NCSC itself says that no training package, including phishing simulations, can teach users to spot every phishing attempt, so technical controls must carry most of the load. What training can do well is build reporting, because the ETH study shows reports detect campaigns fast. And blame works against that: the NCSC warns that users who fear reprisals will not report mistakes promptly, if at all.

In short: do not measure an awareness program by how few people click. Measure how many report and how fast, teach procedures that stop fraud even when someone is fooled, and back people up with phishing-resistant MFA, email authentication and password managers.

Types of training

Delivery mechanisms

• Learning management system (LMS): assigns modules, tracks completion and sends reminders. Good for records; completion alone proves little.
• Self-service portals: where staff find policies, how-to guides and the report-phishing button when they need them.
• One-to-one: coaching for a person, such as corrective training or preparing an executive likely to be impersonated.
• One-to-many: briefings, team meetings and all-staff messages, useful for fast alerts about a live scam.

Topics the exam names

SY0-701 adds anomalous behavior recognition: noticing behavior that is risky (disabling security tools), unexpected (a colleague asking for access they do not need) or unintentional (mistakes that expose data). It also includes insider threat awareness and policies and handbooks.

Measuring effectiveness

Choose metrics that describe outcomes, not activity.

Managerial reports turn those metrics into decisions for leaders: where risk is concentrated, which teams need targeted help, and whether reporting is improving. Personnel behavior risk scoring combines signals, such as simulation results, reports made and policy exceptions, into a score per person or team. Used well, it directs support to where it helps. Used badly, it becomes surveillance and blame. Keep the criteria transparent, involve HR and legal, protect the data, and use scores to offer help rather than punishment, or reporting will fall.

Simulated phishing itself needs governance: management authorization, HR and legal review, privacy safeguards, and messages that do not exploit real personal distress, such as fake bonus or layoff notices, which damage trust.

Common misconceptions

• "Annual training keeps people from clicking." Large studies found little effect from annual modules or post-click lessons on who falls for phishing.
• "A low click rate means a safe organization." Click rates vary with how hard the test email was. Reporting rates and technical backstops matter more.
• "Punishing clickers motivates care." The NCSC warns that fear stops people reporting mistakes promptly.
• "Awareness is only about phishing." The exam lists procedures from payment verification to removable media and operational security.
• "Training replaces technical controls." Training is one layer; phishing-resistant MFA and email filtering catch what people miss.

What you now know

The research is sobering: common phishing training barely changes who clicks. The response is not to abandon awareness but to aim it well. Build a reporting habit, which detects campaigns fast. Teach procedures, such as verifying payment changes by phone, that stop fraud even when someone is fooled. Never punish honest mistakes. Back people with technical controls. Use initial, ongoing, targeted and corrective training through an LMS, portals and one-to-one and one-to-many sessions, cover the exam's topics, and judge the program by outcome metrics, managerial reports and carefully governed risk scoring.

Sources

1. Ho, G., Mirian, A., Luo, E., Tong, K., Lee, E., Liu, L., Longhurst, C. A., Dameff, C., Savage, S., and Voelker, G. M. (2025). Understanding the efficacy of phishing training in practice. In 2025 IEEE Symposium on Security and Privacy. sysnet.ucsd.edu
2. University of California San Diego. (2025, September 17). Cybersecurity training programs don't prevent employees from falling for phishing scams. UC San Diego Today. today.ucsd.edu
3. Lain, D., Kostiainen, K., and Capkun, S. (2022). Phishing in organizations: Findings from a large-scale and long-term study. In 2022 IEEE Symposium on Security and Privacy. arXiv:2112.07498. arxiv.org
4. Merritt, M., Hansche, S., Ellis, B., Sanchez-Cherry, K., Snyder, J. N., and Walden, D. (2024). Building a cybersecurity and privacy learning program (NIST SP 800-50 Rev. 1). National Institute of Standards and Technology. csrc.nist.gov
5. National Cyber Security Centre. (n.d.). Phishing attacks: Defending your organisation. ncsc.gov.uk
6. Federal Bureau of Investigation, Internet Crime Complaint Center. (2025). Internet crime report 2024. ic3.gov

Nineteen misses, six gaps

Two weeks before his exam, a learner we will call Dev took a 70-question practice set under timed conditions and missed 19. His first reaction was to reread every lesson. Instead, he wrote each miss in an error log with one column that mattered most: why. Only six misses were true knowledge gaps. The other thirteen came from reading the question badly, choosing a true statement that did not answer it, or running short of time.

That pattern is common, and it is fixable in two weeks in a way that rereading thirty-five lessons is not. This lesson debugs seven of Dev's misses, each standing for a family of errors, then turns to the simulations, the clock, the final review and the day itself. The practice items here were written for this course. CompTIA's objectives document warns that candidates who use unauthorized materials, so-called brain dumps of real exam questions, will have their certifications revoked and be suspended from future testing. Practice questions teach; leaked questions end careers.

Exam objectives: this lesson teaches no new objective. It reviews all five SY0-801 domains through exam technique and applies the format facts from Lesson 1: up to 90 multiple-choice and performance-based questions in 90 minutes, with a passing score of 750 on a scale of 100 to 900. The same techniques apply to SY0-701.

Miss 1: the word FIRST

The question: a user reports a ransom note on screen and files that will not open; what should the help desk do first? Dev chose "restore the files from last night's backup." Root cause: he answered "what fixes it?" instead of "what comes first?" Restoring is correct eventually, but the machine is still connected and may be spreading the infection. The first step, as Lesson 28 taught, is to isolate it.

Fix: when a stem says FIRST, NEXT or BEFORE, picture the process in order (incident response, change management, forensics, vulnerability management) and pick the earliest step not yet done.

Miss 2: the word BEST

The question: which is the best way to protect stored user passwords? Dev chose "encrypt them with AES-256." Encryption protects them, but anyone with the key can reverse it. A salted hash computed with a deliberately slow, key-stretching algorithm (Lesson 5) cannot be reversed and resists guessing. Root cause: he picked an answer that works instead of the one that works best for the stated goal.

Fix: when two or more options would help, rank them against the scenario's goal. The best answer usually addresses the root cause with the fewest side effects.

Miss 3: the constraint in the middle of the stem

The question: a hospital infusion pump runs software its manufacturer does not allow to be patched; what is the best way to reduce its risk? Dev chose "apply the latest operating system patches." Root cause: the stem had already ruled that out. The answer was a compensating control, isolating the device on its own segment (Lessons 17 and 23).

Fix: mark every constraint before reading the options: cannot, must, without, budget, legacy, as quickly as possible, least administrative effort. Options that break a constraint are wrong however good they sound.

Miss 4: look-alike terms

The question: a company can lose at most four hours of data and must be running again within eight hours; which figure is the recovery point objective? Dev chose eight hours. Root cause: he confused RPO, the data loss limit, with RTO, the downtime limit (Lesson 20).

Fix: keep a confusion list and drill it until each pair is automatic. The course's most common pairs:

Miss 5: a true statement that answers a different question

The question: a sign at a warehouse door warns that the area is monitored by cameras; which type of control is the sign? Dev chose "detective," because cameras detect. Root cause: the question asked about the sign, not the cameras. A sign discourages the act, so it is a deterrent control (Lesson 3).

Fix: after choosing, reread the last line of the stem and ask whether your option answers exactly that.

Miss 6: the changed answer

Dev had picked the right answer to a question about certificate revocation, then changed it while reviewing because the other option "sounded more technical." Fix: change an answer only when you can name the specific clue you missed the first time. A vague feeling is not a clue.

Miss 7: fourteen minutes on question one

The practice set opened with a simulation, a firewall rule table, and Dev fought it for fourteen minutes before guessing. He ran out of time on the last eight questions. Lesson 1 described the rules that make a better plan possible: CompTIA's performance-based questions on Security+ are simulations that you can skip and return to, with your work saved, a reset button, and possible partial credit.

Fix: if a simulation does not open up within a minute or two, skip it, bank the multiple-choice questions, and come back with the time you saved.

Remember: most lost points on exam day are reading and timing errors, not missing knowledge. Underline the key word (FIRST, BEST, MOST, LEAST), mark the constraints, answer the question actually asked, and never let one item spend another's minutes.

What the simulations are likely to ask

CompTIA does not publish the content of its simulations. The objectives give a strong hint, though: the nine SY0-801 objectives that begin "Given a scenario" ask you to apply, analyze or perform, which is what simulations test. The table links each one to the lessons and labs that practiced it. It is our inference from the verbs, not a list from CompTIA.

A time plan for 90 minutes

Up to 90 questions in 90 minutes leaves about a minute each on average, and simulations take longer than multiple-choice items. One plan that fits CompTIA's rules:

1. First pass, about 55 minutes: answer every multiple-choice question you can; flag the uncertain ones; skip simulations that do not open up quickly.
2. Simulations, about 25 minutes: return to each skipped simulation, aiming for partial credit where full credit is out of reach.
3. Review, about 10 minutes: revisit flagged items, changing answers only for a named reason. Never leave a question blank.

The last two weeks

Spend review time in proportion to the marks. The SY0-801 weights give a simple split for, say, ten hours of final review.

Within each block, use the methods that research supports. Dunlosky and colleagues' 2013 review of study techniques rated practice testing and distributed practice, spreading study over several sessions, as the most useful. So spend review time answering questions and explaining the answers, in several short sessions, rather than rereading. Keep the error log going. Read the acronym list at the end of the objectives document, which CompTIA encourages candidates to know.

Exam day

Lesson 1 covered the rules in detail; check them again on CompTIA's site the week before, because policies change. At a test center you need two original, unexpired IDs, one government-issued with a photo. Online through OnVUE you need a clear desk, a single display and a quiet room, and breaks are not allowed unless an accommodation was approved in advance. Candidates under 18 now need a parent's consent through CompTIA before registering. If the first attempt does not go well, there is no wait before a second; later attempts need 14 days between them. A pass is valid for three years and can be renewed through continuing education.

Common misconceptions

• "More rereading will fix my score." Practice testing with error analysis finds the reading and timing errors that rereading never touches.
• "Simulations must be done in order." Security+ simulations can be skipped and revisited, with work saved.
• "A blank answer is safer than a guess." An unanswered question cannot earn credit; eliminate what you can and choose.
• "Real exam questions online are a shortcut." CompTIA revokes certifications and bans candidates who use unauthorized materials.
• "Every true statement is a right answer." The right answer is the one that answers this question, under these constraints, best.

The short version

• Log every practice miss with its cause; most are reading and timing, not knowledge.
• Mark FIRST, BEST, MOST and LEAST, and every constraint, before reading the options.
• Drill the look-alike pairs until they are automatic.
• Expect simulations on the nine scenario objectives; skip any that stall, return later, and aim for partial credit.
• Review in proportion to the domain weights, with practice questions spread over several sessions.
• Recheck CompTIA's ID, online-testing and retake rules the week before, and use only legitimate study materials.

Sources

1. CompTIA. (2025). CompTIA Security+ SY0-801 V8 certification exam objectives (Document version 2.0) [including the authorized materials use policy and acronym list]. CompTIA (PDF)
2. CompTIA. (n.d.). Performance-based questions explained. comptia.org
3. CompTIA. (2026). Security+ V8 [Certification page, exam details and domains]. Retrieved October 27, 2026. comptia.org
4. CompTIA. (n.d.). Candidate ID policy. comptia.org
5. Dunlosky, J., Rawson, K. A., Marsh, E. J., Nathan, M. J., and Willingham, D. T. (2013). Improving students' learning with effective learning techniques: Promising directions from cognitive and educational psychology. Psychological Science in the Public Interest, 14(1), 4-58. doi:10.1177/1529100612453266