SEToolkit Simulator

# Lab: Social Engineering Awareness with SEToolkit (Beginner) — Expanded Edition **Tool:** SEToolkit Simulator — Awareness Training (Practice Sandbox) **Level:** Beginner — no prior security knowledge required **Environment:** Fully offline, defensive training tool. No real emails are sent, no real websites are cloned, and no malware of any kind is created. Every example inside is a static, clearly-labeled training artifact built only so you can learn to recognize it. **Time:** 45–60 minutes --- ## Before you start — what this tool actually is The name "SEToolkit" comes from a well-known real-world tool that security professionals use — carefully, and only with permission — to test whether an organization's employees can be tricked. This simulator is **not** that tool. It cannot send anything, generate anything usable, or touch anything outside your own screen. What it *does* do is walk you through the same six categories of trick that real attackers use, so that when you see one of these patterns in your actual inbox, on a website, or on a USB drive someone hands you, you recognize it immediately instead of falling for it. **Social engineering**, in plain terms, means: tricking a person, rather than hacking a computer, into doing something that helps an attacker — clicking a link, typing a password somewhere it doesn't belong, or plugging in a device they shouldn't. Launch the simulator from your dashboard. You'll see a menu of six numbered modules. Click any one to open it. ## Learning objectives By the end of this lab you will be able to: 1. Name and briefly describe all six major categories of social-engineering attack 2. Recognize the specific warning signs inside a real-looking phishing email 3. Explain why a website "looking right" is not the same as a website "being right" 4. Explain why plugging in an unknown USB drive is dangerous, even out of curiosity 5. Describe, in your own words, at least one concrete defense for each category 6. Apply what you learned to a short "spot the trick" self-check at the end of this lab --- ## How each module works Every module you open follows the same three-part structure — get comfortable with this pattern, because you'll use it six times: 1. **What this looks like** — a fake, clearly-labeled training example so you can see the actual pattern, not just a definition 2. **How to defend against this** — a short list of concrete, practical steps 3. **Your notes** — a text box where you write, in your own words, how you'd personally catch this if it happened to you Writing your own notes in every module is not optional busywork — it's the part of this lab that actually builds recognition. Reading someone else's defense list and writing your own version of it in your own words are two very different learning experiences, and only one of them sticks. --- ## Part 1 — Spear-Phishing Attack Vectors Open **Module 1**. **Task:** Read the training example email carefully — twice. Then, without looking at the "How to defend against this" section yet, write down **on your own** every single thing about that email that seems off to you. Only after that, open the defend list and check what you missed. **Guided questions to answer in your notes box:** - What was wrong with the sender's email address, specifically? - What emotional reaction was the email trying to create in you (calm? panic? curiosity?), and why does that matter? - What should you do instead of clicking the link in an email like this? **Why this matters:** Spear-phishing is *targeted* — the attacker has done some homework on you specifically, which is what makes it more convincing than random spam. This is the module most people will actually encounter in real life. ## Part 2 — Website Attack Vectors Open **Module 2**. **Task:** Read the description of a fake login page. This module doesn't show you an actual fake page (for safety reasons) — it describes one. That's fine; the skill being taught here is about *habits*, not about spotting one specific fake page. **Guided questions to answer in your notes box:** - What's the difference between a website "looking real" and a website "being real"? - Name one browser habit that protects you here, even if you're in a hurry. - Why doesn't seeing a padlock icon or "https" guarantee a site is genuine? (Read the defend list carefully for this one — it's a common misconception even among people who think they're careful.) **Why this matters:** This is the module people are most often *wrong* about before taking a lab like this. Most people believe "HTTPS = safe." That belief is exactly what makes fake login pages work. ## Part 3 — Infectious Media Generator Open **Module 3**. **Task:** Read the USB drive scenario. Imagine you are walking through a parking lot and see a USB drive on the ground labeled something curiosity-inducing. **Guided questions to answer in your notes box:** - Honestly — before this lab, would you have plugged it in "just to see"? Why or why not? - What's the correct action to take with a found USB drive, according to the defend list? - Why is curiosity specifically the thing attackers are relying on here, more than fear or urgency? **Why this matters:** This attack works because it doesn't ask you to trust anything — it just relies on ordinary human curiosity. That's what makes it effective against people who are already suspicious of emails and links. ## Part 4 — Create a Payload and Listener Open **Module 4**. **Task:** Notice something different about this module: there's no fake example to look at. Read why. **Guided questions to answer in your notes box:** - In your own words, what does this category represent, even though you weren't shown how it works? - Why do you think this lab deliberately shows *no* example for this one category, when every other module has one? - Name one everyday habit (something you already do or could start doing) that defends against this category. **Why this matters:** Not every category of attack is safe to demonstrate, even in a training tool. Recognizing the *term* when you encounter it in a real security article or a workplace security briefing is genuinely useful, even without seeing "how it works." ## Part 5 — Mass Mailer Attack Open **Module 5**. **Task:** Read the training example. Compare it side-by-side (in your notes) to the spear-phishing example from Part 1. **Guided questions to answer in your notes box:** - What's the key difference between this attack and spear-phishing from Module 1? - Why can an attacker still profit from an attack like this, even if 99% of people ignore it? - Name one thing you should specifically **not** do with an email like this, even out of curiosity about what happens. **Why this matters:** This module teaches you that not every phishing attempt is personalized or sophisticated — some rely purely on volume. Recognizing "too good to be true" is a skill on its own. ## Part 6 — Third Party Modules Open **Module 6**. **Task:** Read the description. This is the most abstract module — there's no single fixed example, because this category represents an open-ended, ever-changing set of techniques. **Guided questions to answer in your notes box:** - Why does it make sense that this category doesn't have one fixed example? - The defend list says the underlying pattern matters more than the specific technique. Restate that idea in your own words, using an example that's *not* already in this lab (something you've heard of from the news, a friend, or your own inbox). - What's the one universal check the defend list recommends when you're unsure about any unexpected request? **Why this matters:** Attackers constantly invent new specific tricks. If you only memorize the six examples in this lab, you'll miss trick #7 next year. The pattern-recognition skill — "something is trying to get me to click, trust, or hand something over" — is what actually transfers. --- ## Part 7 — Self-check: spot the trick Without opening the simulator again, answer these from memory. This tests whether the lab actually built recognition, not just module-reading. For each mini-scenario below, name **which of the six modules it belongs to**, and the **one specific detail** that gives it away: 1. An email from "support@yourbank-secure-verify.com" saying your account will be suspended in 30 minutes unless you click a link. 2. A USB drive labeled "2026 Bonus List" sitting by the office coffee machine. 3. A text message you didn't expect, from a number you don't recognize, saying you've won a free iPhone — just "click to claim." 4. A login page that looks pixel-perfect identical to your email provider, but the address bar says something slightly different from what you normally see. *(Write your answers in your final notes — you don't need to submit them separately, but they should be part of your saved project write-up.)* --- ## Common mistakes to avoid - **Skipping the "write it yourself first" step.** Reading the defend list before trying to spot the problem yourself feels faster, but it's the difference between recognizing this pattern in real life and just recognizing this lab's specific example. - **Assuming HTTPS or a padlock means "safe."** This is the single most common wrong belief this lab is designed to correct — see Part 2. - **Treating Module 4 and Module 6 as "less important" because they have no example.** They're testing whether you can generalize a defense from a description alone, which is arguably the harder and more valuable skill. - **Writing generic notes like "be careful."** Your notes should be specific enough that a future version of you, reading them again in six months, would actually know what to look for. ## Glossary - **Social engineering** — tricking a person (rather than hacking a computer) into taking an action that helps an attacker - **Phishing** — a social-engineering attack delivered by email, designed to get you to click a link, open an attachment, or hand over information - **Spear-phishing** — phishing that is targeted at a specific person, using details that make it more convincing - **Mass mailer / bulk phishing** — the same idea as phishing, but sent to a large number of people with no personalization, relying on volume rather than precision - **Look-alike domain** — a website address deliberately designed to closely resemble a real one, to trick you into thinking it's genuine - **Infectious media** — a physical device (like a USB drive) left somewhere a target is likely to find and use it out of curiosity --- ## Submit your work Click 💾 Save My Training Notes as a Project** inside the simulator before you close it — this saves every module you opened along with the personal notes you wrote for each one. Title it clearly, e.g. `"Social Engineering Awareness — Beginner Lab"`, and include your Part 7 self-check answers in your final write-up. ## Stretch goals (optional) 1. Think of one real email, text message, or website you've personally encountered that matches one of these six categories. Without including any personal or sensitive details, describe in 2–3 sentences what tipped you off (or what almost tricked you). 2. Explain this lab's six categories to a friend or family member who hasn't taken it, in your own words, without looking back at your notes. If you get stuck explaining any of them, that's a sign to revisit that module. 3. For Module 6 (Third Party Modules) specifically — do a little of your own research (a quick search is fine) on one recent, real-world social-engineering technique that isn't already covered by Modules 1–5. Summarize it in 3–4 sentences and explain which existing defense list it would still fall under.

# Lab: Social Engineering Awareness with SEToolkit (Intermediate) — Expanded Edition **Tool:** SEToolkit Simulator — Awareness Training (Practice Sandbox) **Level:** Intermediate — complete the Beginner lab first. This lab assumes you can already name all six modules and their basic defenses without looking them up. **Environment:** Fully offline, defensive training tool. No real emails are sent, no real websites are cloned, and no malware of any kind is created. **Time:** 75–90 minutes **Format:** 8 parts + a final deliverable — you are no longer just reading modules, you're applying them to situations the tool never shows you directly. --- ## What's different at this level The Beginner lab taught you to recognize the six examples *inside* the simulator. This lab assumes you can already do that, and pushes further: can you recognize the same underlying pattern when it's dressed differently, mixed across categories, or missing the obvious red flags the training example gave you for free? Real attacks rarely look exactly like a textbook example. This lab is built around that gap — applying, comparing, and defending, instead of just reading. Open the simulator and keep all six modules available for reference throughout — you'll be cross-referencing them constantly, not moving through them once in order. ## Learning objectives By the end of this lab you will be able to: 1. Identify the underlying social-engineering *category* of a scenario that isn't a direct copy of the tool's built-in examples 2. Compare and contrast attack categories that are frequently confused with each other 3. Build a personal, generalized "red flag checklist" that works across categories, not just within one 4. Analyze *why* a specific defense works — not just what the defense is 5. Draft a short, real-world awareness communication (the kind a security team would actually send to employees) 6. Evaluate the limitations of static, tool-based training compared to real-world unpredictability 7. Apply everything above to ambiguous, multi-category scenarios where more than one category could plausibly apply --- ## Part 1 — Rebuild the six categories from memory first Before reopening any module, write down — from memory only — a one-sentence description of each of the six categories and one defense for each. Then open the simulator and check yourself. **Task:** Score yourself honestly. For any category where your memory was wrong, vague, or missing, re-read that module fully before continuing — the rest of this lab assumes solid recall of all six, not just the ones you remember best. **Why this matters:** In a real security-awareness role, you won't have the tool open when someone asks you "wait, is this a website attack or a phishing thing?" Recall under pressure is the actual skill. ## Part 2 — Compare the two phishing categories directly Open **Module 1 (Spear-Phishing)** and **Module 5 (Mass Mailer)** side by side. **Task:** These two are the pair most people confuse. Write a short comparison table in your notes: | | Spear-Phishing | Mass Mailer | |---|---|---| | Targeting | | | | Personalization level | | | | Attacker effort required | | | | Typical giveaway sign | | | | Why it still works despite low precision (mass mailer) / high effort (spear-phishing) | | | Then answer: if you received an email that used your actual first name and referenced your actual job title, but the offer inside was a generic "you've won a prize" — which category is it *actually*, and why does that distinction matter for how seriously you should take it? ## Part 3 — Apply the pattern to a scenario the tool never showed you Read this scenario (not from the simulator): > *You receive a LinkedIn message from someone claiming to be a recruiter at a well-known company, complimenting your recent project and asking you to "quickly verify your resume details" on an external site before they can "lock in" an interview slot.* **Task:** This scenario blends elements from more than one module. Answer: - Which module's category does this most closely match, and why? - What secondary category does it also borrow from (think about *where* the "verification" actually happens)? - List three specific red flags in this scenario that were **not** explicitly present in the tool's built-in training example for that category — you have to generalize the pattern, not just pattern-match the exact wording. - Write the one sentence you'd say to a friend who showed you this message and asked "is this real?" ## Part 4 — The module with no example, applied Reread **Module 4 (Create a Payload and Listener)**. Recall that this module deliberately shows no example. **Task:** Without any example to reference, write your own **plausible but harmless** description of how this category might show up in an ordinary person's day — not as an attacker would build it, but as a *target* would experience it. For example: what would it look like from the receiving end if someone had built something in this category and used it against a coworker? Focus entirely on what a victim would notice, never on how to build anything. Then answer: why is "the antivirus/EDR software is up to date" listed as a defense here specifically, when none of the other five modules mention antivirus at all? What's structurally different about this category that makes that particular defense relevant? ## Part 5 — Build your own generalized red-flag checklist You've now seen all six categories applied both inside and outside the tool. **Task:** Write a single, generalized checklist of **8–10 red flags** that work across *multiple* categories, not category-specific advice. For each flag, note which 2+ modules it would have helped you catch. Examples of the kind of thing that belongs here (write your own, better versions — don't just copy these): - Unexpected urgency or a countdown - A request that bypasses a normal, known channel - Something offered for free or too easily - A slight mismatch between what something claims to be and where it actually points This checklist is the actual deliverable of this entire lab — it's what you'd keep taped above your desk, not the six individual modules. ## Part 6 — Draft a real awareness communication Imagine you're on a small company's security team, and you need to send a short internal message to non-technical coworkers **after** a spear-phishing attempt was reported by someone in the company. **Task:** Write a 150–200 word internal email or Slack message that: - Briefly explains what happened, without technical jargon - Gives 3 concrete things to watch for (pulled from your Part 5 checklist) - Tells people exactly what to do if they see something similar (a real, specific action — not "be careful") - Does **not** make anyone feel stupid for almost clicking — tone matters in real awareness communication, and a message that shames people makes future reporting *less* likely, not more This is a real skill gap in security training — knowing the material and being able to communicate it calmly and usefully to non-technical people are not the same skill. ## Part 7 — Evaluate the limits of this tool **Task:** In 5–6 sentences, honestly critique the SEToolkit Simulator itself: - What can a static, six-module training tool **not** prepare you for that a real, unpredictable attack attempt would include? - Why might someone who scores perfectly on a self-check like Part 1 still fall for a real phishing attempt at work six months from now? - What's one thing a real organization should do *in addition to* a tool like this (think: simulated phishing tests, reporting culture, verification habits) to actually reduce risk, rather than relying on training alone? This isn't a trick question about the lab being "bad" — it's testing whether you understand that recognition training is one layer of defense, not a complete solution. ## Part 8 — Ambiguous case review Read these three short scenarios. For each, identify the primary category, note any secondary category it borrows from, and — critically — flag if you genuinely can't tell from the description alone (that's a valid, sometimes correct answer at this level). 1. *A coworker finds a branded-looking flash drive at a conference with the company's own logo printed on it, sitting on a table near the registration desk.* 2. *An SMS message claims to be from a delivery company saying a package couldn't be delivered, with a link to "reschedule" and pay a small redelivery fee.* 3. *A phone call from someone claiming to be from your company's IT department, asking you to read back a one-time verification code you just received by text "to confirm your identity."* **Task:** For scenario 3 specifically — this one is not directly one of the six modules. Explain, using the *pattern*, not a category name, what makes this dangerous, and which module's defense list still applies even though the delivery method (a phone call) doesn't match any built-in example. --- ## Deliverable: Awareness Portfolio Compile your work into a short portfolio with three sections: ### 1. Red Flag Checklist (from Part 5) Your final, cleaned-up 8–10 item list. ### 2. Applied Case Analysis (from Parts 3, 4, and 8) Your category identification and reasoning for each non-tool scenario, written as if explaining your reasoning to someone learning this for the first time. ### 3. Awareness Communication (from Part 6) Your drafted internal message, ready to send as-is. --- ### Grading rubric | Criteria | What "intermediate level" looks like | |---|---| | Recall without the tool open | Part 1 self-test completed honestly before re-checking, gaps identified and addressed | | Pattern generalization | Parts 3, 4, and 8 correctly identify categories in scenarios that don't match the tool's wording exactly | | Checklist quality | Part 5 items are genuinely cross-category, not restated single-module advice | | Communication tone | Part 6 message is accurate, specific, and doesn't shame the person who almost clicked | | Honest self-critique | Part 7 identifies real limitations, not just "this tool is great" | | Comfort with ambiguity | Part 8 correctly flags scenario 3 as not a clean fit for one category, and still reasons about it usefully | --- ## Common mistakes at this level - **Pattern-matching on wording instead of on structure.** If a scenario doesn't use the word "urgent" or "click here," some students assume it's not phishing-related — miss the underlying mechanism, not just the surface language. - **Writing a checklist that's really six separate lists stapled together.** Part 5 should feel meaningfully different from just summarizing all six modules end to end. - **A Part 6 message that lectures instead of informs.** Real people stop reporting incidents if the response to a near-miss feels like a scolding. - **Refusing to say "I'm not sure" on Part 8.** At the intermediate level, correctly recognizing genuine ambiguity is a sign of skill, not a gap — attackers deliberately blend categories specifically to confuse this kind of classification. - **Treating Part 7 as an attack on the lab.** A tool having limits doesn't mean the tool is bad — real security professionals constantly evaluate the limits of their own training programs. This is a professional habit, not a complaint. ## Glossary (new terms at this level) - **Pattern generalization** — recognizing the underlying mechanism of an attack even when the specific wording, channel, or details differ from a known example - **Verification bypass** — when an attacker asks you to confirm sensitive information through a channel other than the one you'd normally trust - **Reporting culture** — an organizational environment where employees feel safe reporting a near-miss or mistake without fear of blame, which directly affects how early real incidents get caught - **Vishing** — phishing conducted by voice/phone call rather than email (relevant to Part 8, scenario 3) - **Smishing** — phishing conducted by SMS/text message (relevant to Part 8, scenario 2) --- ## Submit your work Click **💾 Save My Training Notes as a Project** inside the simulator to preserve your module review history, then attach your full 3-section Awareness Portfolio (Parts 5, 3/4/8, and 6) as a separate write-up. Title the saved project `"Social Engineering Awareness — Intermediate Lab"`. ## Stretch goals (optional) 1. Take your Part 6 awareness message and rewrite it as a 3-slide summary instead of an email — what do you cut, and what do you keep, when the format forces brevity? 2. For Part 8, write a **fourth** ambiguous scenario of your own that deliberately blends two categories, then swap it with a classmate (or revisit it yourself after a week) and see if it's still solvable using your Part 5 checklist. 3. Research one real, publicly reported social-engineering incident (a company breach that started with phishing, a well-known vishing case, etc.) and map it onto your Part 5 checklist — which of your red flags would have caught it, and which wouldn't have, in hindsight?

# Lab: Social Engineering Awareness with SEToolkit — Expert Edition ## Simulated Engagement: Designing a Security Awareness Program for a Fictional Organization **Tool:** SEToolkit Simulator — Awareness Training (Practice Sandbox) **Level:** Expert — complete the Beginner and Intermediate labs first. This lab assumes fluent recall of all six categories and comfort classifying scenarios the tool never shows you directly. **Environment:** Fully offline, defensive training tool. No real emails are sent, no real websites are cloned, and no malware of any kind is created. **Time:** 2–3 hours (can be split across sessions — your saved project preserves your module review history) **Format:** You are not reviewing training content anymore. You are the person **designing** the training program for a real organization, using this tool's six categories as your raw material. --- ## The scenario You've been hired as the security awareness lead for a fictional mid-sized company, **Northfield Logistics** (120 employees, no in-house security team until now, one recent near-miss incident where an employee almost entered credentials on a fake login page before noticing the URL was wrong). Leadership has asked you for one thing: **a working awareness program, not a slideshow.** They don't want a list of six attack types read out loud once a year. They want something that actually changes behavior, gets measured, and gets reported on to the board. The SEToolkit Simulator's six categories are your **content foundation** — the raw material every real awareness program is built from. Your job in this lab is everything a real program needs *around* that content: audience segmentation, delivery strategy, measurement, incident response integration, and a report leadership will actually read. Nothing in this lab involves running anything against a real person or system. Every deliverable is a planning document. --- ## Learning objectives By the end of this lab you will be able to: 1. Translate static training content into an audience-aware program plan 2. Design a phishing-simulation testing approach in principle (not execution) and explain its ethical boundaries 3. Build a measurement framework for whether awareness training is actually working 4. Integrate awareness training with incident reporting and response, not treat them as separate 5. Correctly triage a real incident report against the six categories, including cases that don't cleanly fit any one of them 6. Handle the human factors of security awareness — blame culture, training fatigue, and executive buy-in — not just the technical content 7. Produce a program document that a non-technical executive sponsor could approve as-is --- ## Phase 0 — Program charter (write this first) Before touching the simulator, write a short **program charter**, as if this were a real approved initiative: - **Objective:** reduce successful social-engineering incidents at Northfield Logistics and increase the rate at which employees report suspicious activity (not just avoid clicking — actively report) - **Constraint:** you have a training budget for **one initial rollout plus one refresher per year** — this is not an unlimited-training-hours program, so every design decision below has to justify its cost in time and attention - **Existing signal:** one near-miss incident already occurred (the fake login page). Your program has to explicitly address why that happened and how it won't next time This charter is the document everything else in this lab has to be consistent with. If a later phase's decision contradicts it, that's a flag to revisit — not to ignore. ## Phase 1 — Full content audit Go through all six modules in the simulator one more time, but with a different lens than either previous lab: you're not learning the content now, you're **evaluating it as training material**. **Task:** For each module, rate (High/Medium/Low) how relevant it is specifically to Northfield Logistics employees, given what you know about the company (logistics, 120 employees, no security team, one recent website-related near-miss). Justify each rating in one sentence. Not every category deserves equal training time — an expert-level program prioritizes. ## Phase 2 — Audience segmentation A real awareness program doesn't train every employee identically. **Task:** Define **three employee segments** for Northfield Logistics (you decide what makes sense for a logistics company — e.g., warehouse/operations staff, office/administrative staff, and leadership/finance) and, for each segment: - Which 2–3 modules matter *most* for that group, and why - One module that's genuinely lower-priority for that specific group (not "skip everything else" — pick one real deprioritization and justify it) - The single most likely real-world attack vector that group would actually encounter, based on their day-to-day work **Why this matters:** Finance and leadership face different real risk (executive-targeted spear-phishing, wire-fraud-style social engineering) than warehouse staff (who might be far more likely to encounter Module 3's infectious-media scenario via a delivery-related USB drive, given the company's actual business). Generic, one-size-fits-all training is a well-documented reason real awareness programs fail to change behavior. ## Phase 3 — Delivery and cadence plan **Task:** Design the actual rollout, working within your Phase 0 budget constraint (one initial rollout + one annual refresher): - What order do the segments go through training in, and why that order specifically? - How long is a single training session realistically, given that this is not people's full-time job? - What happens for someone who **fails** a self-check or clearly didn't engage — is there a follow-up, and what does it look like? - How does the refresher differ from the initial rollout? (Hint: repeating the exact same content a year later is a common, low-effectiveness mistake — think about what should change.) ## Phase 4 — Phishing simulation design (planning only) Real awareness programs are often paired with **simulated phishing tests** — sending fake-but-harmless phishing emails to employees to measure real-world response, not just self-reported quiz scores. **Task:** This lab will not have you build or send an actual simulated phishing email — that requires real infrastructure, legal sign-off, and organizational authorization far beyond this tool's scope. Instead: - Describe, at a planning level, how you would structure a simulated phishing test that's **fair and ethical** — what makes a simulation instructive rather than a "gotcha" that damages trust in the security team? - What would you measure from a simulation like this (click rate? report rate? time-to-report?), and why is "report rate" arguably more important to track than "click rate" alone? - What's the single biggest way a badly-run phishing simulation can backfire on an organization's security culture? ## Phase 5 — Incident triage against ambiguous reports Northfield Logistics now has a reporting channel (built as part of your program). Employees have submitted the following four reports. **Triage each one**: primary category, confidence level (High/Medium/Low), and the specific next action a security lead should take. 1. *"A vendor I've worked with for two years emailed asking me to update their bank details for our next invoice payment. The email looked normal, but it came slightly later in the day than they usually email."* 2. *"I got a call from someone claiming to be from our IT helpdesk, asking me to install a 'remote support tool' so they could 'fix an issue with my account' before I'd even reported one."* 3. *"Someone in a delivery uniform asked to be let into our loading dock without a badge, saying their badge reader 'wasn't working today.'"* 4. *"An employee said a friend on social media sent them a link to a 'free logistics industry salary report' that asked them to log in with their work email to view it."* **Task:** For at least one of these four, explain why it does **not** map cleanly onto any single one of the tool's six modules, and what that tells you about the limits of a fixed six-category framework when applied to real, messy incident reports. (Note: report #3 is a physical social-engineering technique — **tailgating/piggybacking** — that isn't one of the tool's six categories at all. Recognizing that gap is itself part of the expert-level skill being tested here.) ## Phase 6 — Metrics and measurement framework Leadership explicitly asked how they'll know this program is working. **Task:** Design a simple measurement framework with **no more than 5 metrics** (more than that, and leadership won't actually read the dashboard). For each metric: - What it measures - Why it's a meaningful signal of real behavior change, not just training completion - One way this specific metric could be gamed or misleading if read in isolation (every metric can be — a mature program plans for that) Example of the *kind* of metric to include (write your own full set — don't just copy this): "percentage of employees who report a simulated phishing email within 24 hours" is a stronger signal than "percentage of employees who completed the training module," because completion doesn't prove retention or behavior change. ## Phase 7 — Culture and human factors **Task:** Answer directly, in 6–8 sentences total: - Northfield's one existing near-miss incident involved an employee who *almost* fell for a fake login page but caught it. How should your program treat that person — and how you treat them sends a signal to everyone else. What's the right response, and why does it matter for future reporting rates? - What's the risk of a security-awareness program that feels punitive (blame-focused) versus one that feels supportive (report-focused)? Which failure mode is more common in real organizations, in your understanding, and why? - Executive/leadership buy-in was mentioned in the scenario. What's one thing you'd specifically ask leadership to do *themselves* (not just approve budget for), to make the program credible to everyone else in the company? --- ## Deliverable: Program Proposal for Leadership Compile everything into a document structured the way a real proposal to executive leadership would be — this is the actual test of the "expert" level. ### 1. Executive Summary (4–6 sentences, no jargon) What the program is, why it's needed now (reference the near-miss without assigning blame to the individual), and the expected outcome. ### 2. Program Charter Your Phase 0 write-up, cleaned up. ### 3. Audience & Content Strategy Your Phase 1 content audit and Phase 2 segmentation, presented as a short table plus explanation. ### 4. Delivery Plan Your Phase 3 rollout and cadence design. ### 5. Testing & Measurement Your Phase 4 simulation design and Phase 6 metrics framework, combined into one section. ### 6. Incident Triage Process Your Phase 5 methodology, using at least one of the four sample reports as a worked example — including the tailgating gap you identified. ### 7. Culture Statement Your Phase 7 answers, reframed as a short statement of how the program will be run, suitable for leadership to read aloud or reference when talking to employees. ### 8. Limitations & Next Steps What this program, as designed, does **not** cover (e.g., physical social engineering beyond what your triage process catches, technical controls like email filtering, multi-factor authentication) — and what you'd propose adding in year two, once budget allows for more than one rollout and one refresher. --- ### Grading rubric | Criteria | What "expert level" looks like | |---|---| | Prioritization under constraint | Phase 1 and Phase 3 make real trade-offs justified by the Phase 0 budget constraint, not "train everyone on everything equally" | | Audience awareness | Phase 2 segments are genuinely differentiated, with real reasoning tied to job function, not generic labels | | Ethical grounding | Phase 4 correctly identifies that live phishing simulation requires real authorization and explains fairness/trust considerations, without attempting to actually design deliverable phishing content | | Handles gaps in the framework | Phase 5 correctly identifies that report #3 (tailgating) falls outside the tool's six categories, and reasons about what that means rather than forcing a bad-fit classification | | Measurement is meaningful, not just measurable | Phase 6 metrics are tied to real behavior change and each includes a stated gaming/misreading risk | | Human factors taken seriously | Phase 7 treats the near-miss employee's reporting as something to reinforce positively, and explains the blame-vs-support trade-off correctly | | Executive-appropriate writing | Executive Summary and Culture Statement are genuinely non-technical and could be read aloud to leadership as-is | --- ## Common mistakes at this level - **Designing a program that's really just "everyone watches all six modules once."** That's the Beginner lab, not a program. Segmentation and prioritization are the actual expert-level skill being tested. - **Forcing report #3 (tailgating) into one of the six categories anyway.** The correct expert-level answer is recognizing the tool's framework has a real gap here, not stretching "infectious media" or another category to cover a physical-access scenario that doesn't fit. - **Designing a phishing simulation as if you were actually going to build and send it.** This lab explicitly stops at planning-level design — actually generating deliverable phishing content is out of scope, both for this lab and generally something requiring real organizational authorization. - **A metrics section that only measures training completion.** Completion rate is the easiest metric to collect and the weakest signal of real change — an expert-level framework goes further. - **Treating the near-miss employee as a cautionary tale in your Culture Statement.** How this lab's fictional program treats that one employee is a direct test of whether you understood Phase 7. Punitive framing is the wrong answer, even implicitly. - **An Executive Summary full of the same terminology as your Technical sections.** If a term needs `Module 1` or `spear-phishing` to explain it, it belongs later in the document, not in the summary. ## Glossary (expert terms used in this lab) - **Awareness program** — an organized, ongoing effort to build employee recognition of and response to security threats, as opposed to a single one-time training - **Phishing simulation** — an authorized, controlled test where an organization sends realistic-but-harmless phishing content to its own employees to measure real response, not just quiz performance - **Report rate** — the percentage of people who correctly report a suspicious message or simulation, as distinct from click rate (who fell for it) - **Tailgating / piggybacking** — a physical social-engineering technique where an attacker gains unauthorized physical access by following an authorized person through a secured entry point - **Training fatigue** — the drop in engagement and retention that happens when security training is repetitive, generic, or perceived as a compliance checkbox rather than genuinely useful - **Blame culture vs. reporting culture** — the organizational contrast between punishing mistakes (which suppresses future reporting) and rewarding early reporting (which surfaces real incidents faster) --- ## Submit your work Click **💾 Save My Training Notes as a Project** inside the simulator to preserve your content-audit review history, then attach your full 8-section Program Proposal (Executive Summary through Limitations & Next Steps) as a separate write-up. Title the saved project `"Social Engineering Awareness — Expert Program Design"`. ## Stretch goals (optional, for going beyond the lab) 1. Draft a single follow-up slide or one-pager specifically for the employee who almost fell for the near-miss incident — not a correction, but genuine positive reinforcement for catching it and reporting it. What tone does this need that's different from your general Culture Statement? 2. Revisit your Phase 6 metrics framework and ask: which single metric, if it were the *only* one leadership looked at, would give the most misleading picture of program success? Explain why, and what you'd pair it with to correct for that. 3. Report #3 in Phase 5 exposed a real gap in the six-category framework (physical social engineering / tailgating). Sketch, in a few sentences, what a **seventh module** for this simulator might look like if the tool were ever expanded — matching the existing structure (description, example, defenses) — without actually writing the full content.