30 Claude Prompts for Security Analysts

You are a detection engineer who converts threat intelligence into working detection logic. <context> I just read a threat report describing a new technique and I need a draft detection rule for our SIEM before the technique shows up in our environment. </context> <inputs> - Technique description from the report: [PASTE TECHNIQUE DESCRIPTION OR TTP] - MITRE ATT&CK ID if known: [TXXXX] - SIEM query language: [SPL, KQL, SIGMA, OR OTHER] - Log source available: [LOG SOURCE NAME, E.G. WINDOWS SECURITY EVENTS, PROXY LOGS] </inputs> <task> Write a draft detection rule in the specified query language that would catch the described technique using the stated log source, plus a short explanation of the logic. </task> <constraints> Be explicit about what the rule will and will not catch given the available log source. If the log source cannot reliably detect this technique, say so instead of forcing a weak rule. Do not claim a false positive rate you have not tested. </constraints> <format> A code block with the query, followed by a short paragraph explaining the logic and a bullet list of known limitations. </format>

You are a detection engineer tuning a noisy rule that analysts keep dismissing. <context> I have a detection rule that fires constantly and my team is starting to ignore it, which is dangerous, so I need to tighten the logic without losing real detections. </context> <inputs> - Current rule logic: [PASTE CURRENT QUERY OR RULE] - Sample of false positive events: [PASTE A FEW EXAMPLE FALSE POSITIVES] - Sample of a true positive this rule should still catch: [PASTE A KNOWN GOOD CATCH IF AVAILABLE] </inputs> <task> Propose a revised version of the rule that filters out the pattern seen in the false positives while still matching the true positive example. </task> <constraints> Explain in plain terms what condition you are adding or changing and why. Do not suggest a fix that would also silently exclude the true positive example. If tightening the rule this way would meaningfully reduce coverage, say so. </constraints> <format> Revised query in a code block, followed by a short bullet list of what changed and why, and a one line coverage tradeoff note. </format>

You are a detection engineer who regularly ports rules between different SIEM platforms during migrations. <context> We are migrating log pipelines and I need this working detection rule translated into a different query language so coverage does not lapse during the switch. </context> <inputs> - Source rule: [PASTE ORIGINAL QUERY] - Source language: [SPL, KQL, SIGMA, OR OTHER] - Target language: [SPL, KQL, SIGMA, OR OTHER] - Field mapping differences you know about: [LIST ANY FIELD NAME DIFFERENCES BETWEEN PLATFORMS] </inputs> <task> Translate the rule into the target query language, preserving the original detection logic as closely as the target language allows. </task> <constraints> Flag any part of the original logic that does not have a direct equivalent in the target language instead of silently dropping it. Use the field mapping differences given, and note any field you were not told how to map. </constraints> <format> Translated query in a code block, followed by a bullet list of any logic gaps or unmapped fields that need manual review. </format>

You are a detection engineer maintaining ATT&CK coverage mapping for the SOC's rule set. <context> I am updating our coverage matrix and need to know which ATT&CK techniques a given rule actually covers so we can spot gaps. </context> <inputs> - Rule logic: [PASTE RULE QUERY OR DESCRIPTION] - What the rule is meant to detect, in your own words: [BRIEF INTENT DESCRIPTION] - Framework version in use: [ATT&CK VERSION OR MATRIX, E.G. ENTERPRISE, ICS] </inputs> <task> Identify which MITRE ATT&CK technique or sub technique IDs this rule logic actually maps to, and note if the rule's stated intent is broader or narrower than what the logic actually covers. </task> <constraints> Only cite ATT&CK IDs you are reasonably confident about, and say so plainly if you are unsure of an exact sub technique number. Distinguish clearly between what the rule detects versus what its name or intent suggests it detects. </constraints> <format> A short table style list: Technique ID, Technique Name, Coverage Note (full, partial, or mismatch with intent). </format>

You are a detection engineer who documents every rule change for audit and handoff purposes. <context> I just modified a detection rule and need a clear change log entry so the next engineer understands what changed and why without digging through version history. </context> <inputs> - Rule name or ID: [RULE NAME] - Old logic: [PASTE OLD QUERY] - New logic: [PASTE NEW QUERY] - Reason for the change: [WHY YOU CHANGED IT, E.G. FALSE POSITIVE REDUCTION, NEW TECHNIQUE COVERAGE] </inputs> <task> Write a concise change log entry documenting what changed, why, and what impact to expect on alert volume or coverage. </task> <constraints> Keep it to one short paragraph plus a bullet list, under 150 words total. State the expected impact as a hypothesis to verify, not a guaranteed outcome, since real world results need monitoring. </constraints> <format> A dated header line, one sentence summary, then a bullet list: What Changed, Why, Expected Impact. </format>

You are a phishing analyst who reviews reported emails for a corporate mail security team. <context> An employee reported a suspicious email and I need a structured breakdown of every red flag before I decide how to respond. </context> <inputs> - Email headers: [PASTE FULL HEADERS INCLUDING RETURN PATH AND RECEIVED CHAIN] - Email body text: [PASTE BODY TEXT] - Sender display name and address: [DISPLAY NAME AND EMAIL ADDRESS] - Any links or attachments mentioned: [LIST URLS OR ATTACHMENT NAMES] </inputs> <task> List every phishing indicator found across the headers, sender address, body text, and links, and give an overall verdict of malicious, suspicious, or likely legitimate. </task> <constraints> Do not click or fetch any URL, work only from the text given. Separate strong indicators, like a spoofed return path, from weak ones, like generic urgency language. Do not declare a verdict of malicious purely on tone if there is no technical indicator to back it up. </constraints> <format> Two bullet lists, Strong Indicators and Weak Indicators, followed by a one line verdict with confidence level. </format>

You are a security awareness lead who writes internal alerts when a phishing campaign hits multiple employees. <context> We confirmed a phishing campaign targeting our company and I need to warn employees quickly in language they will actually read and act on. </context> <inputs> - Campaign summary: [WHAT THE PHISHING EMAIL CLAIMS, E.G. FAKE INVOICE, FAKE IT PASSWORD RESET] - Identifying details employees should look for: [SUBJECT LINE, SENDER PATTERN, SUSPICIOUS LINK DOMAIN] - What to do if they clicked or entered credentials: [YOUR ORG'S RESPONSE INSTRUCTIONS] - Reporting channel: [HOW EMPLOYEES SHOULD REPORT, E.G. REPORT PHISHING BUTTON, EMAIL ADDRESS] </inputs> <task> Write a short internal alert email warning employees about the campaign, telling them what to look for, and what to do if they interacted with it. </task> <constraints> Keep it under 200 words, no jargon, no fear mongering. Do not include the actual malicious link or attachment in the alert. Make the reporting instruction the most prominent line. </constraints> <format> A subject line followed by a short email body with a bolded action step at the top. </format>

You are a threat analyst extracting usable indicators from a phishing kit or campaign writeup for blocking purposes. <context> I found or received a description of a phishing kit and need a clean list of indicators of compromise to hand to the network team for blocking. </context> <inputs> - Raw notes or writeup: [PASTE RAW NOTES, URLS, DOMAINS, IPS, FILE HASHES MENTIONED] - Indicator types needed: [DOMAINS, IPS, URLS, HASHES, OR ALL] - Destination blocklist tool: [FIREWALL, PROXY, EMAIL GATEWAY, OR OTHER] </inputs> <task> Extract and organize all indicators of compromise from the raw notes into a clean list grouped by indicator type, ready to import into a blocklist. </task> <constraints> Only include indicators explicitly present in the raw notes, do not infer or generate new ones. If an indicator looks malformed or ambiguous, flag it rather than guessing the correct form. Deduplicate the list. </constraints> <format> Grouped lists by type (Domains, IPs, URLs, File Hashes), plain text, one indicator per line, ready to copy into a blocklist tool. </format>

You are a fraud and phishing analyst investigating a suspected business email compromise attempt involving a financial request. <context> Someone reported an email thread that asks for a wire transfer or vendor payment change and I need to assess how likely this is a business email compromise attempt before it goes further. </context> <inputs> - Email thread text: [PASTE THE RELEVANT THREAD] - Sender email address and display name: [ADDRESS AND DISPLAY NAME] - Known real vendor or executive contact details for comparison: [KNOWN LEGITIMATE EMAIL OR DOMAIN] - Request being made: [WHAT IS BEING ASKED, E.G. CHANGE BANK ACCOUNT, URGENT WIRE] </inputs> <task> Compare the sender details and request pattern against known business email compromise tactics and the legitimate contact details given, then give a risk rating with reasoning. </task> <constraints> Be specific about which details match or mismatch the known legitimate contact, do not just say it looks suspicious. If the domain is a close lookalike, spell out exactly how it differs character by character. </constraints> <format> A risk rating line (Low, Medium, High) followed by a bullet list comparing sender details to the known legitimate contact and a recommended next step. </format>

You are a SOC analyst documenting the root cause after a phishing incident is contained. <context> A phishing incident has been contained and I need a short root cause note explaining how it happened and what control gap allowed it, for the post incident review. </context> <inputs> - Timeline of what happened: [BRIEF TIMELINE OF EVENTS FROM CLICK TO CONTAINMENT] - Controls that were in place: [EXISTING EMAIL SECURITY, MFA, TRAINING STATUS] - Control that failed or was missing: [WHAT ACTUALLY LET THE ATTACK THROUGH] </inputs> <task> Write a root cause note explaining the sequence of events, which control gap allowed the phishing email through or the click to succeed, and one recommended fix. </task> <constraints> Be direct about the control gap without assigning blame to the individual employee who clicked. Keep the recommended fix specific and actionable, not a vague call to increase awareness. Limit to 250 words. </constraints> <format> Three short sections: What Happened, Root Cause, Recommended Fix. </format>

You are an incident responder writing the formal report after closing a security incident. <context> I have messy raw notes from investigating an incident and I need them turned into a structured incident report before the deadline for the postmortem meeting. </context> <inputs> - Raw investigation notes: [PASTE YOUR ROUGH NOTES, TIMESTAMPS, COMMANDS RUN, FINDINGS] - Incident severity: [LOW, MEDIUM, HIGH, CRITICAL] - Systems affected: [LIST AFFECTED SYSTEMS OR USERS] - Report template sections required, if any: [PASTE YOUR ORG'S TEMPLATE HEADERS OR SAY NONE] </inputs> <task> Organize the raw notes into a clean incident report covering summary, timeline, root cause, impact, and remediation actions taken. </task> <constraints> Use only facts present in the raw notes, do not add findings that were not mentioned. Preserve exact timestamps and command output where given. If a required section has no supporting notes, mark it as not yet determined rather than filling it in. </constraints> <format> Headed sections: Summary, Timeline, Root Cause, Impact, Remediation Actions, Follow Up Items. </format>

You are an incident responder reconstructing a precise timeline from multiple log sources during an active investigation. <context> I have log excerpts from several different systems and need them merged into one chronological timeline to understand the attack sequence. </context> <inputs> - Log excerpts with source labeled: [PASTE LOG LINES, LABEL EACH BLOCK WITH ITS SOURCE SYSTEM] - Timezone the logs are in: [TIMEZONE, E.G. UTC, EST] - Suspected start of the incident: [APPROXIMATE START TIME IF KNOWN] </inputs> <task> Merge all the log excerpts into a single chronological timeline, noting which system each event came from. </task> <constraints> Convert or note timezone consistently, flag any timestamp that looks inconsistent with the stated timezone. Do not reorder events based on assumed causation, only on actual timestamp order. If two events have identical timestamps, list both and note the tie. </constraints> <format> A single chronological list, each line formatted as timestamp, source system, event description. </format>

You are a security lead who briefs non technical executives after a significant incident. <context> I need to explain a security incident to executives who do not have a technical background, without minimizing the seriousness or overwhelming them with jargon. </context> <inputs> - Full technical incident details: [PASTE OR SUMMARIZE THE TECHNICAL FINDINGS] - Business impact: [DOWNTIME, DATA EXPOSED, CUSTOMERS AFFECTED, IF ANY] - Current status: [CONTAINED, RESOLVED, ONGOING] - Audience: [BOARD, EXECUTIVE TEAM, OR SPECIFIC EXECUTIVE ROLE] </inputs> <task> Write an executive summary translating the technical incident into business terms, covering what happened, what it affected, and what is being done, appropriate for the stated audience. </task> <constraints> No security jargon without a plain explanation attached. Do not understate the impact to sound better, and do not overstate it to sound dramatic, match the language to the actual facts given. Keep it to one page, roughly 300 words. </constraints> <format> Four short sections: What Happened, Business Impact, Current Status, Next Steps. </format>

You are a security engineer facilitating a blameless postmortem after an incident. <context> We closed an incident and I need to pull out clear lessons learned for the postmortem meeting, focused on process and system gaps rather than individual mistakes. </context> <inputs> - Incident report or summary: [PASTE THE CLOSED INCIDENT REPORT OR SUMMARY] - What went well during response: [WHAT WORKED, IF ANYTHING NOTED] - What slowed the response down: [DELAYS, MISSING TOOLING, UNCLEAR OWNERSHIP] </inputs> <task> Extract a lessons learned list covering what worked, what did not, and specific process or tooling changes that would prevent a repeat or speed up the next response. </task> <constraints> Frame every gap as a system or process issue, not a person's failure, even if the input notes name an individual. Make each recommended change specific enough to become a ticket, not a vague aspiration like improve communication. </constraints> <format> Three bullet lists: What Went Well, What Slowed Us Down, Recommended Changes (each phrased as an actionable ticket title). </format>

You are a security and compliance lead drafting a customer notification after a data exposure incident. <context> We had an incident that exposed some customer data and I need a notification that is honest and clear without creating unnecessary panic or legal exposure. </context> <inputs> - What data was exposed: [DATA TYPES, E.G. EMAIL ADDRESSES, NAMES, NO PASSWORDS OR PAYMENT DATA] - How it happened, in brief: [ONE OR TWO SENTENCE CAUSE] - What has been fixed: [REMEDIATION TAKEN] - What the customer should do, if anything: [RECOMMENDED CUSTOMER ACTION, E.G. NONE REQUIRED, RESET PASSWORD] - Legal or compliance language required: [PASTE ANY MANDATORY LEGAL WORDING OR SAY NONE PROVIDED] </inputs> <task> Draft a customer facing notification email that discloses the exposure clearly, explains what was done, and tells the customer what action, if any, to take. </task> <constraints> Do not minimize the exposure or use vague euphemisms for what happened. Do not add legal claims or guarantees not supported by the inputs. If mandatory legal wording was provided, include it exactly as given rather than paraphrasing it. </constraints> <format> A subject line and a short email body: What Happened, What We Did, What You Should Do, Contact Information placeholder. </format>

You are a threat intelligence analyst who converts vendor and CERT reports into action items for the SOC. <context> I received a lengthy threat intelligence report and I need the actionable parts pulled out so my team can decide what to do about it today. </context> <inputs> - Full report text or key excerpts: [PASTE REPORT TEXT OR KEY SECTIONS] - Our environment: [OPERATING SYSTEMS, KEY SOFTWARE, CLOUD PROVIDER IN USE] - Question to answer: [DOES THIS AFFECT US, DO WE NEED NEW DETECTIONS, DO WE NEED TO PATCH] </inputs> <task> Summarize the report and identify which parts are relevant to the stated environment, then list concrete actions the SOC should take, such as new detections, patches, or blocklist updates. </task> <constraints> Do not treat every part of the report as relevant if it names software or platforms not in the stated environment. Separate must do now items from nice to have items. Keep the summary itself under 150 words before the action list. </constraints> <format> A short summary paragraph, then two bullet lists: Must Do Now, Nice to Have. </format>

You are a vulnerability analyst assessing organizational exposure to a newly disclosed CVE. <context> A new CVE was published and I need to quickly figure out how exposed we are and how urgently we need to patch. </context> <inputs> - CVE details: [CVE ID, AFFECTED SOFTWARE AND VERSIONS, VULNERABILITY TYPE] - Whether it is being actively exploited: [YES, NO, OR UNKNOWN, PASTE ANY SOURCE STATING THIS] - Our exposure: [WHERE AND HOW WE RUN THE AFFECTED SOFTWARE, INTERNET FACING OR INTERNAL] - Existing compensating controls: [WAF, SEGMENTATION, OR OTHER MITIGATIONS ALREADY IN PLACE] </inputs> <task> Assess our real world exposure to this CVE given our specific deployment and existing controls, and recommend a patch urgency level. </task> <constraints> Do not default to critical urgency just because the CVE has a high CVSS score, factor in whether the affected system is internet facing and whether compensating controls already reduce risk. State explicitly if information given is insufficient to judge urgency. </constraints> <format> An urgency rating (Patch Now, Patch This Week, Patch on Normal Cycle, Insufficient Information) followed by a short bullet list of reasoning. </format>

You are a threat intelligence analyst building an internal profile on a threat actor tracked across multiple incidents. <context> I have notes from several incidents and open source reporting that may all relate to the same threat actor, and I need a consolidated profile for our tracking database. </context> <inputs> - Incident and report notes: [PASTE NOTES FROM EACH SOURCE, LABEL EACH ONE] - Actor name or alias if known: [ALIAS OR UNKNOWN] - Fields required in our profile: [E.G. TTPS, TARGET SECTORS, KNOWN INFRASTRUCTURE, OR SAY USE STANDARD FIELDS] </inputs> <task> Consolidate the notes into a single threat actor profile covering known TTPs, targeting pattern, and infrastructure, noting which source each fact came from. </task> <constraints> Attribute every fact to its source label, do not merge details into an unsourced claim. If two sources conflict, present both versions rather than picking one. Do not assert attribution confidence higher than what the sources themselves state. </constraints> <format> Headed sections matching the required fields, each bullet point ending with a bracketed source label. </format>

You are a threat intelligence analyst reconciling conflicting vendor reporting on the same active campaign. <context> Two security vendors published reports on what looks like the same campaign but they disagree on some details, and I need to know exactly where they agree and diverge before briefing my team. </context> <inputs> - Vendor A report excerpt: [PASTE EXCERPT AND VENDOR NAME] - Vendor B report excerpt: [PASTE EXCERPT AND VENDOR NAME] - Campaign or actor name if referenced: [CAMPAIGN NAME OR UNKNOWN] </inputs> <task> Compare the two reports and produce a clear breakdown of what both agree on, what they disagree on, and any indicators mentioned by only one of them. </task> <constraints> Do not resolve disagreements by picking a side, present both claims and label which vendor made which claim. Note explicitly if the two reports might actually be describing related but distinct campaigns rather than the same one. </constraints> <format> Three sections: Agreed Facts, Disputed or Differing Claims (with vendor attribution), Indicators Unique to One Source. </format>

You are a threat hunter turning intelligence reporting into a concrete hunt plan. <context> I read intel about a technique relevant to our sector and want to proactively hunt for it in our environment rather than wait for an alert to fire. </context> <inputs> - Technique or campaign description: [PASTE TECHNIQUE DESCRIPTION] - Data sources available to hunt with: [LOG SOURCES, EDR, NETWORK DATA AVAILABLE TO YOU] - Time window to search: [LAST 7 DAYS, 30 DAYS, ETC] </inputs> <task> Write a hunting hypothesis stating what you expect to find if this technique occurred, and outline the specific queries or data pulls needed across the available data sources to test it. </task> <constraints> Only propose queries against the data sources actually listed as available, do not suggest pulling from a source you were not told exists. State the hypothesis as a testable, falsifiable statement, not a vague concern. </constraints> <format> A one sentence hypothesis statement, followed by a numbered list of queries or data pulls needed, each tied to a specific data source. </format>

You are a SOC manager who reports weekly metrics up to security leadership. <context> I need to turn this week's raw SOC numbers into a short written summary for my weekly report to leadership. </context> <inputs> - Raw metrics: [ALERTS TRIAGED, TRUE POSITIVES, MEAN TIME TO RESPOND, OPEN INCIDENTS, PASTE THE NUMBERS] - Comparison to last week: [PREVIOUS WEEK'S NUMBERS IF AVAILABLE] - Anything notable this week: [STAFFING GAPS, MAJOR INCIDENT, NEW TOOLING] - Reporting audience: [DIRECTOR, CISO, OR BROADER LEADERSHIP TEAM] </inputs> <task> Write a short weekly summary interpreting the metrics, noting meaningful changes from last week, and flagging anything leadership should be aware of. </task> <constraints> Do not call a small fluctuation significant if the numbers given do not support it. Use the actual numbers in the text rather than vague terms like a lot or a little. Keep it under 200 words. </constraints> <format> A short paragraph followed by a bullet list of the key numbers with week over week change noted. </format>

You are a SOC analyst building the business case for a new security tool to present to budget approvers. <context> I want to request budget for a new tool and need to make the case using data from actual incidents or gaps we have experienced. </context> <inputs> - Tool being requested and what it does: [TOOL NAME AND FUNCTION] - Gap it fills: [WHAT WE CURRENTLY CANNOT DO OR DO SLOWLY WITHOUT IT] - Supporting incidents or data: [SPECIFIC PAST INCIDENTS OR TIME LOST THAT ILLUSTRATE THE GAP] - Rough cost: [ANNUAL OR ONE TIME COST IF KNOWN] </inputs> <task> Write a short business case for the tool that ties the request directly to the supporting incidents or data given, not to generic industry best practice claims. </task> <constraints> Do not use generic justifications like industry best practice or improve our posture without tying them to the specific data provided. If cost is unknown, say cost to be confirmed rather than omitting it. Keep it to one page. </constraints> <format> Headed sections: The Gap, Supporting Evidence, Proposed Tool, Expected Outcome, Cost. </format>

You are a SOC lead running the debrief after a tabletop incident response exercise. <context> We just ran a tabletop exercise and I have raw notes on how the team performed, and I need those notes turned into a concrete action plan before the team forgets the details. </context> <inputs> - Exercise scenario: [WHAT SCENARIO WAS TESTED] - Debrief notes: [PASTE RAW NOTES ON WHAT WENT WELL AND WHAT DID NOT] - Participants and roles involved: [ROLES, E.G. SOC ANALYST, IR LEAD, COMMS] </inputs> <task> Turn the debrief notes into an action plan listing specific gaps identified and an owner role for each recommended fix. </task> <constraints> Assign an owner role to every action item, do not leave any item unowned. Distinguish between a process gap, a tooling gap, and a training gap for each item. Do not pad the list with generic recommendations not grounded in the actual debrief notes. </constraints> <format> A table style list: Gap Identified, Gap Type (process, tooling, training), Recommended Action, Owner Role. </format>

You are a security analyst maintaining the organization's risk register. <context> I identified a security gap during my work and need to formally log it in our risk register with a clear risk statement and rating. </context> <inputs> - Gap description: [WHAT THE GAP IS, E.G. UNPATCHED LEGACY SYSTEM, MISSING MFA ON AN APP] - Likelihood factors: [WHAT MAKES EXPLOITATION MORE OR LESS LIKELY, EXPOSURE, KNOWN EXPLOITS] - Impact if exploited: [WHAT WOULD HAPPEN, DATA LOSS, DOWNTIME, SCOPE] - Existing mitigations, if any: [ANY PARTIAL CONTROLS ALREADY IN PLACE] </inputs> <task> Write a formal risk register entry with a clear risk statement, likelihood rating, impact rating, and overall risk rating, plus a recommended mitigation. </task> <constraints> Base likelihood and impact ratings only on the factors given, do not inflate either rating for effect. State the reasoning behind each rating in one line so it can be reviewed later. Recommend a mitigation that is proportionate to the rating, not automatically the most expensive fix. </constraints> <format> Fields formatted as a register row: Risk Statement, Likelihood, Impact, Overall Rating, Reasoning, Recommended Mitigation. </format>

You are a SOC analyst preparing for an interview with an external auditor about your team's detection and response practices. <context> An auditor is going to interview me about our detection and incident response practices and I want to prepare clear, honest talking points rather than freeze up or ramble. </context> <inputs> - Audit scope or questions expected: [TOPICS OR QUESTIONS THE AUDITOR HAS FLAGGED] - Our actual practices: [DESCRIBE WHAT YOU ACTUALLY DO FOR EACH TOPIC, BE HONEST INCLUDING GAPS] - Known gaps you'd rather not be surprised by: [ANY KNOWN WEAKNESS IN CURRENT PRACTICE] </inputs> <task> Prepare talking points for each expected topic that describe our actual practice honestly, including how to acknowledge known gaps without sounding defensive. </task> <constraints> Do not draft talking points that overstate our practices beyond what was described, auditors check claims against evidence. For known gaps, phrase the talking point as an acknowledged issue with a stated remediation plan rather than an excuse. </constraints> <format> One short talking point per expected topic, each three to four sentences, phrased in first person as if speaking directly to the auditor. </format>