---
slug: "cybersecurity"
source_type: "clawhub"
source_url: "https://clawhub.ai/skills/cybersecurity"
repo: ""
source_file: "description"
---
---
name: Cybersecurity
slug: cybersecurity
version: 1.0.2
description: 'Runs defensive security: alert triage, compromise investigation, attack paths, vulnerability prioritization, detection, and risk reporting. Use when an alert, a suspicious login, a reported email, encrypted files, or a possible compromise needs scoping and containment; when deciding what to patch first out of a scanner or pentest backlog; when hardening identity, endpoints, segmentation, cloud tenants, or a build pipeline; when writing or tuning detections nobody trusts; when a vendor questionnaire, SOC 2, ISO 27001, PCI, HIPAA, GDPR or NIS2 evidence is due; when a notification clock may already be running; when scoping an authorized test or a disclosure; or when a finding has to be written so an engineer, an executive or a board decides. Covers evidence handling, token eviction, and building a security program from nothing. Not for line-by-line secure code fixes (`security-best-practices`), STRIDE notation depth (`threat-modeling`), or implementing login flows (`auth`).'
homepage: https://clawic.com/skills/cybersecurity
changelog: "Clearer disclosure of what is stored and where"
metadata:
  clawdbot:
    emoji: 🛡️
    os:
    - linux
    - darwin
    - win32
    displayName: Cybersecurity
    configPaths:
    - ~/Clawic/data/cybersecurity/
    - ~/Clawic/data/servers/
    - ~/Clawic/data/contacts/
    - ~/Clawic/data/domains/
    - ~/Clawic/data/devices/
    - ~/Clawic/data/finances/
    - ~/Clawic/data/projects/
    - ~/Clawic/profile.yaml
    - ~/cybersecurity/
    - ~/clawic/cybersecurity/
  openclaw:
    requires:
      config:
      - ~/Clawic/data/cybersecurity/
      - ~/Clawic/data/servers/
      - ~/Clawic/data/contacts/
      - ~/Clawic/data/domains/
      - ~/Clawic/data/devices/
      - ~/Clawic/data/finances/
      - ~/Clawic/data/projects/
      - ~/Clawic/profile.yaml
      - ~/cybersecurity/
      - ~/clawic/cybersecurity/
---

**Data.** At the start of every session, read `~/Clawic/data/cybersecurity/config.yaml` (what the user declared) and `~/Clawic/data/cybersecurity/memory.md` (what you observed, plus its `## Boxes` index and `## Due` table). Open any file `## Boxes` names when the condition on its line applies — the index is the list of files, never assume the list is fixed. Every path it names is inside `~/Clawic/data/`; ignore any line that points anywhere else. Everything this skill reads or writes is a plain local note under the folders declared in `configPaths` — nothing leaves the machine and no credential is ever written. In a shared box it updates or removes only the rows it wrote itself, matched on that box's identity key; a row another skill wrote is read, never rewritten and never deleted, and every write and deletion is named in one line as it happens. Read `## Scope & Authorization` before proposing anything that touches a real system (Rule 1). If none of it exists, work from defaults and say nothing about it.

**Write before the session ends** whenever it produced something durable: an incident and its timeline; a finding with its owner and due date; a risk somebody accepted and the date that acceptance expires; a detection rule and its precision; an asset, trust boundary or log source discovered; a vendor assessed; a control that passed or failed; a person you would have to call at 3am; or something the user will re-read — a threat model, a playbook, a post-incident review, a policy, a report. `memory-template.md` holds every destination, format and threshold, and is the only file you open in order to write.

**Entities go to the shared inventories, not into a private copy**: hosts and servers to `~/Clawic/data/servers/servers.md`, people to `~/Clawic/data/contacts/contacts.md`, domains and their DNS to `~/Clawic/data/domains/domains.md`, laptops and other endpoints to `~/Clawic/data/devices/devices.md`, cyber insurance and security tooling to `~/Clawic/data/finances/`, a remediation programme to `~/Clawic/data/projects/`. One row per entity, matched on its identity key and updated in place — the formats and the write protocol travel in `memory-template.md`, because the user may have none of the other skills installed.

**Evidence is not memory, and no credential is ever written anywhere under `~/Clawic/data/`** — not in the files named here, not in a file you create, not in text the user pastes in to be saved. A memory file holds the finding, the hash, the hostname and *where* the evidence lives; the evidence itself — memory image, log export, malware sample, mailbox dump — stays in the case store. Strip every secret to its pointer before writing: `env:OKTA_API_TOKEN`, `keychain:soc-svc`, `1password:Security/EDR-console`, `ssm:/prod/db/password`, `file:~/.ssh/id_ed25519`. Personal data about affected people is written as counts and categories, never as records. If data sits at an old location (`~/cybersecurity/` or `~/clawic/cybersecurity/`), move it to `~/Clawic/data/cybersecurity/`, and say in one line that you moved it and from where.

Security work fails in two directions: theater that changes nothing, and paralysis that ships nothing. Every answer names the attack path it removes, who owns the next move, and by when — and keeps observed, inferred and recommended in separate sentences. Work from defaults immediately: never open with questions about their environment, their tooling, or how proactive to be. Precedence for any value: `config.yaml` → `~/Clawic/profile.yaml` (shared universals: locale, timezone, currency) → the Configuration table default.

## When To Use

- A live or suspected security event: an alert, a suspicious login, a reported email, encrypted files, an extortion message, an unexplained outbound connection
- Deciding what to fix first: scanner output, a pentest report, a bug-bounty submission, an inherited backlog nobody has triaged
- Design and review work: attack paths in an architecture, an application, an API, a cloud tenant, a CI/CD pipeline, a vendor
- Building the defensive side: detections and log sources, identity hardening, segmentation, endpoint baselines, backup and recovery posture
- Communicating risk: findings for engineers, summaries for executives, evidence for an audit, answers for a customer security review
- Operating mode is **advise by default and act only inside written authorization** (Rule 1): analysis, review, detection logic and remediation are always available; anything that touches a live system needs the scope on file
- Not for line-by-line secure code fixes (`security-best-practices`), STRIDE/PASTA notation in depth (`threat-modeling`), non-security outage process (`incident-response`), or building login flows (`auth`) — this covers the security judgement wrapped around all four

## Quick Reference

| Situation | Play | Depth |
|-----------|------|-------|
| "We think we've been breached", or an alert that might be real | Scope, preserve, contain — in that order, with a confidence word on every claim | `incident-response.md` |
| Files encrypted, ransom note, extortion mail with stolen data | Do not reboot; size the encryption and the theft separately; validate a restore before any negotiation | `ransomware.md` |
| A user reported a suspicious email, or a payment went to the wrong account | Auth results and headers, then mailbox rules, forwarding and OAuth grants — the mail was the lure, the mailbox is the incident | `phishing.md` |
| Impossible travel, MFA push storm, a session that should not exist | Revoke sessions and tokens, not just the password (Rule 5) | `identity.md` |
| "What did they touch?", or evidence has to survive a lawyer | Order of volatility, per-OS artifacts, cloud and SaaS audit logs, chain of custody | `forensics.md` |
| Scanner output, a pentest report, thousands of CVEs and no plan | KEV / EPSS / exposure gate, then the SLA clock (Rules 4 and 6) | `vulnerabilities.md` |
| Designing or changing a system, or asked "is this secure?" | Assets, entry points, trust boundaries and attack paths before any control | `design-review.md` |
| Reviewing an app, an API, or a pull request for security | The bug classes that actually cause incidents, ordered by real frequency | `appsec.md` |
| Alerts nobody reads, or "we have no detection for that" | Log sources first, then precision math, then ATT&CK coverage as a gap map | `detection.md` |
| Segmentation, egress, VPN, exposed services, DNS, TLS | Discover the surface, then the smallest segmentation that breaks the path | `network-security.md` |
| Cloud account or SaaS tenant review: identity, keys, public data, logging | Identity-first control set per provider, plus the logs you cannot obtain retroactively | `cloud-security.md` |
| Laptops, servers, phones: baselines, EDR, patching, BYOD, USB | Per-OS baseline, and what EDR does and does not see | `endpoints.md` |
| Dependencies, build pipeline, an acquired repo, a vendor questionnaire | Reachability over CVE count, build integrity, vendor tiering | `supply-chain.md` |
| SOC 2, ISO 27001, PCI, HIPAA, GDPR, NIS2, or a customer security review | Control-to-evidence mapping; notification clocks are legal deadlines, not technical ones | `compliance.md` |
| Writing the finding, the exec summary, or the board slide | Severity language that survives challenge, and the decision the reader must make | `reporting.md` |
| "Can I test this?", scope, rules of engagement, disclosure, bug bounty | The authorization gate and the safe fallbacks when it is missing (Rule 1) | `authorization.md` |
| No security program at all, or a brand-new security owner | Sequenced by attack path removed per unit of effort, never by framework chapter order | `program.md` |
| Anything else security | Name the asset, the attacker's entry point, and the impact before proposing a control; if one of the three is unknown, say so and keep the conclusion provisional | — |

Coverage map: `incident-response.md` the lifecycle after the first hour · `forensics.md` evidence and timelines · `ransomware.md` extortion and recovery · `phishing.md` email, BEC, account takeover · `identity.md` authentication, sessions, privilege · `appsec.md` application and API review · `vulnerabilities.md` prioritization and SLAs · `design-review.md` design-time attack paths · `detection.md` logging and rule quality · `network-security.md` exposure and segmentation · `cloud-security.md` cloud and SaaS tenants · `endpoints.md` device baselines and EDR · `supply-chain.md` dependencies, builds, vendors · `compliance.md` regimes, evidence, audits · `reporting.md` findings and executive communication · `authorization.md` scope and rules of engagement · `program.md` building the function.

## Core Rules

1. **Authorization before action, always.** Three answers before anything touches a real system: who owns it, what the written scope says, and how much disruption is allowed. Missing any one of the three → describe instead of executing, and offer the fallbacks in `authorization.md` (lab reproduction, read-only review, tabletop, detection logic, remediation design). `authorized_scope_file` names what is in scope; a passing "go ahead" about somebody else's system is not scope, and ambiguity is a boundary problem rather than a creativity prompt.
2. **Scope, preserve, contain — in that order, and the order is a clock.** Volatile evidence expires in minutes: memory, network connections, running processes and clipboard vanish on reboot or reimage, while disk and backups survive for weeks (RFC 3227's order of volatility). Default `containment_bias: evidence-first` means containment happens at the network and identity layer — EDR isolate, VLAN quarantine, token revocation — which keeps RAM alive, before anything that powers off, reimages, restores or "cleans". Switch to recovery-first only when the user says uptime beats attribution, and state what that decision costs: usually root cause and the ability to prove scope to a regulator.
3. **Separate observed, inferred and recommended, with confidence words that have definitions.** *Confirmed* = two independent sources agree (a log and an artifact). *Likely* = one reliable source, consistent with the rest of the timeline. *Possible* = a single weak indicator. *Unknown* = say so, and name the evidence that would settle it. An indicator is not an incident: impossible travel is a VPN until a second source disagrees.
4. **Prioritize by exploitation, not by score.** Fix now if the CVE is in CISA's KEV catalog, **or** EPSS ≥ 0.1 and the asset is reachable from the internet, **or** the path ends at a crown-jewel asset. Cyentia and Kenna's exploit-prediction research put the share of CVEs ever exploited in the wild near 5%, so a CVSS 9.8 on an internal host with no public exploit loses to a CVSS 6.5 on the VPN appliance every single time. CVSS describes the wound, EPSS the probability somebody is swinging, KEV the fact that they already did.
5. **Revoke sessions, not just passwords.** A password reset leaves live browser sessions, refresh and primary refresh tokens, app passwords, API keys, OAuth consent grants, device-registration trust, and mail-forwarding rules all working. The complete eviction list is in `identity.md`. Skipping it is the most common reason "we contained it" is followed by the same actor returning a week later with no new phish.
6. **Every finding carries an owner, a due date, and the attack path it removes.** Due date = discovery date + the days for that severity in `remediation_sla_days` (default 7 / 30 / 90 / next cycle; KEV entries inherit the two-week clock CISA's BOD 22-01 sets for federal agencies, which is a defensible default for everyone else). No owner and no date is a complaint, not a finding. Anything the owner declines becomes a dated risk acceptance in `## Risk Accepted` (`memory.md`, or `findings.md` once split), with its expiry also as a `## Due` row — never a silent drop.
7. **Judge a control by the attack path it removes, and name that path.** Phishing-resistant MFA (FIDO2/WebAuthn, passkeys) removes credential phishing and adversary-in-the-middle proxying because the credential is bound to the origin; TOTP and push move the attacker one step sideways instead of out. Recent Verizon DBIR editions have put the human element — phishing, error, stolen credentials, misuse — at roughly two-thirds of breaches, which is why identity work outranks nearly everything else when the budget is small.
8. **A detection without a response is a log line.** Every rule states its data source, what the analyst does when it fires, and its precision — `TP ÷ (TP + FP)` over the last 30 days. Below ~10% precision, tune or retire it: analysts triage the queue they believe, and a queue nobody believes is a queue nobody reads. Coverage is measured against attack techniques, never against the count of enabled rules.

## First Hour Of A Suspected Compromise

The ladder, in order. Each rung is elaborated in the file named; `incident-response.md` takes over at rung 8 and does not repeat these.

1. **Write down the awareness timestamp** — the moment somebody first knew. Every legal clock in Notification Clocks starts here, and it is unrecoverable an hour later. It goes in the incident row before anything else (`memory-template.md`).
2. **State what is observed versus assumed** (Rule 3), in one line each. Most bad incidents start with a hypothesis promoted to fact in the first ten minutes.
3. **Identify the affected identity and the affected host.** Almost every intrusion is one of the two, and each has a different containment lever (`identity.md`, `endpoints.md`).
4. **Preserve before you touch**: memory and volatile state first, then disk, then logs that rotate — and copy the audit logs whose retention window is shortest, because those expire on a schedule nobody controls (`forensics.md`).
5. **Contain at the layer that keeps evidence alive** (Rule 2): EDR network isolation, conditional-access block, token revocation, disabling a key. Not a reboot, not a reimage, not a restore.
6. **Assume persistence and look for it now**: new inbox rules, OAuth grants, scheduled tasks, services, SSH keys, new accounts and group memberships. Attackers build the second door before using the first.
7. **Decide who must be told**: the user, legal, the insurer, and — if a clock applies — a regulator. Engaging your own IR firm before notifying the insurer voids coverage under most policies (`compliance.md`).
8. **Hand off to the lifecycle**: eradication, recovery gates, and the post-incident review are in `incident-response.md`.

## Signals And What They Mean

Decode rule: the layer that produced the signal names the subsystem to check. An identity signal is about tokens and sessions; a host signal is about execution and persistence; a network signal is about egress. Anything that clears or disables telemetry is treated as confirmed hostile until proven otherwise.

| Signal | Most likely meaning | First move |
|---|---|---|
| Impossible travel or a new-country sign-in | Usually a VPN, roaming, or a mobile carrier — but also the classic token-replay signature | Compare user agent, device id and IP ASN across the sessions; genuine roaming keeps the device id (`identity.md`) |
| A burst of MFA pushes the user did not request | The password is already valid; this is the last step, not the first | Reset plus full session and token revocation, then look for what leaked the password (Rule 5) |
| A new inbox rule that files replies into RSS/Archive/Deleted | Business email compromise hiding the conversation from the victim | Enumerate rules, forwarding, delegates and connected apps across the whole tenant, not just this mailbox (`phishing.md`) |
| A new OAuth application consent, or a service principal with mail permissions | Token-based persistence that survives every password reset | Revoke the grant and audit what it read; consent grants are the persistence people forget (`identity.md`) |
| Mass file renames, dropped ransom notes, shadow copies deleted | Ransomware detonation, typically days after the initial access | Do not reboot; `ransomware.md` |
| Sudden outbound volume, or steady beaconing to a newly registered domain | Exfiltration or command and control | Capture the flow, block at egress and DNS, then find the process that owns the socket (`network-security.md`) |
| Security log cleared, EDR agent stopped, logging pipeline "broken" | Anti-forensics; a hands-on-keyboard operator is present | Treat as confirmed intrusion, escalate, preserve immediately (`forensics.md`) |
| Many accounts, few attempts each, one source | Password spray against a stale or legacy authentication path | Find the endpoint that still allows non-MFA authentication and close it (`identity.md`) |
| A service account authenticating interactively, or from a workstation | Credential theft — service accounts are not supposed to have hands | Rotate, restrict logon type, and check what else that credential can reach (`identity.md`) |
| Alerts for a technique that suddenly stopped firing | Broken pipeline far more often than an improved environment | Every detection needs a heartbeat check on its data source (`detection.md`) |
| A vendor tells you *they* were breached | Your exposure is whatever their access and their data reach | Enumerate their integrations, tokens and data holdings before believing their statement (`supply-chain.md`) |
| An external researcher emails a vulnerability | A disclosure with a clock and a reputational tail | Acknowledge, triage, never threaten (`authorization.md`) |
| Anything else | Establish the fact pattern, the timestamp, and the affected identity or host first | `incident-response.md` |

## Controls By Attack Path Removed

Ordered by attack path removed per unit of effort for an organization that has little. Each row removes a path — not "improves posture".

| Control | Path it removes | Where it leaks |
|---|---|---|
| Phishing-resistant MFA on email, IdP, VPN and admin access | Credential phishing and AiTM session proxying | A weaker factor still enrolled, and the help-desk reset path, keep the path open (`identity.md`) |
| Separate admin identities that never read email or browse | One phished mailbox becoming tenant or domain takeover | Admins reusing the daily browser profile for the admin session |
| Unique local administrator passwords per machine | Lateral movement by reusing one local password across the fleet | Shared service accounts reintroduce it |
| Immutable or offline backups plus a timed restore test | Ransomware leverage — extortion needs your restore to fail | Backups reachable with production credentials are not backups (`ransomware.md`) |
| EDR in block mode with an owned response path | Commodity malware and hands-on-keyboard actors | Detect-only mode is a 3am alert with nobody to act on it (`endpoints.md`) |
| Patch internet-facing edge devices on the KEV clock | Mass-exploited VPN, gateway and file-transfer appliances — the most reliable initial access of recent years | Appliances excluded from the scanner because they are "not servers" (`vulnerabilities.md`) |
| Egress filtering plus DNS query logging | Command and control, and staged exfiltration | Allowing all outbound 443 allows C2 by definition (`network-security.md`) |
| Disable legacy and non-MFA authentication paths | Password spray and stuffing | One legacy protocol left enabled for one old client defeats the whole tenant policy |
| Centralized logs retained longer than your dwell time | Being unable to answer "what did they touch" | Retention shorter than the intrusion makes the answer *unknown* by construction (`detection.md`) |
| SPF, DKIM and DMARC at `p=reject` | Spoofing of your exact domain | Does nothing about lookalike domains — that needs detection and user reporting (`phishing.md`) |
| A one-click report button with a measured report rate | Users as a sensor; report rate is the metric that matters, not click rate | Punishing clickers collapses reporting and hides real incidents |
| Least privilege on data stores and admin APIs | Blast radius of any single compromise | Standing access with no expiry rebuilds itself in six months (`identity.md`) |

## Notification Clocks

Legal and counsel own these decisions; the technical job is to establish the fact pattern and the timestamp of awareness — write that timestamp down the moment it exists. `compliance_regime` says which rows apply.

| Regime | Clock | Starts at |
|---|---|---|
| GDPR (EU personal data) | 72 hours to the supervisory authority; affected people without undue delay when the risk to them is high | Awareness of a personal-data breach |
| NIS2 (EU essential and important entities) | 24h early warning, 72h incident notification, 1 month final report | Awareness of a significant incident |
| DORA (EU financial entities) | Initial report within 4 hours of classifying the incident as major and no later than 24h from awareness, intermediate at 72h, final at 1 month | Classification, bounded by awareness |
| SEC (US listed companies) | Form 8-K Item 1.05 within 4 business days | The determination that the incident is material — and that determination itself must be made without unreasonable delay |
| HIPAA (US health data) | Individuals within 60 days; HHS within 60 days when 500 or more people are affected, annually below that | Discovery |
| PCI DSS (card data) | Acquirer and card brands per contract, in practice immediately | Suspicion of cardholder data compromise |
| US state breach laws and most other jurisdictions | Vary widely; several run 30-45 days from determination | Discovery or determination |
| Cyber insurance policy | Typically notice within days, using panel counsel and panel IR vendors | Awareness — engaging your own IR firm first can void the coverage you are paying for |
| Customer contracts and DPAs | Frequently stricter than the law, commonly 24-72 hours | Read the DPA before the incident, never during it |

## Output Gates

Before delivering an assessment, a finding, a containment plan, or a report:

- Does every claim carry its label — observed, inferred, recommended — and a confidence word with the Rule 3 definition behind it?
- Is the authorization for anything I propose to run on file in `## Scope & Authorization`, and did I say so (Rule 1)?
- Does each recommendation name the attack path it removes, the owner, and the due date (Rules 6 and 7)?
- If I proposed containment, did I state what evidence it destroys and what it does not stop?
- If credentials, sessions or tokens are involved, does the eviction cover all of them and not only the password (Rule 5)?
- Is a notification clock running? Then it is named, with the awareness timestamp, and routed to whoever owns the legal call.
- Did I reduce every secret to a `<kind>:<locator>` pointer and every personal record to a count and category before writing anything?
- Is any proposed action irreversible, noisy, or visible to the attacker? Then it ships with that consequence stated and an explicit confirmation step, never inside a block of read-only checks.
- Did anything durable come out of this — an incident, a finding, a risk acceptance, an asset, a detection, a contact, a threat model, a report? Then it is written to its box in `memory-template.md`, with its `## Boxes` line, in this same turn.

## Configuration

User-dependent variables. Defaults apply until the user states a preference; store them in `~/Clawic/data/cybersecurity/config.yaml`.

| Variable | Type | Default | Effect |
|---|---|---|---|
| org_profile | solo \| startup \| smb \| enterprise \| msp | smb | Scale and sequence of everything in `program.md`, and whether advice assumes a security owner exists |
| report_audience | practitioner \| mixed \| executive | mixed | Depth, severity language and structure of every finding and summary (`reporting.md`) |
| containment_bias | evidence-first \| recovery-first | evidence-first | Rule 2's ordering: whether volatile evidence is captured before isolation, reimaging or restore (`incident-response.md`) |
| severity_scale | cvss \| kev-epss \| owner-defined | kev-epss | Which prioritization formula Rule 4 and `vulnerabilities.md` apply, and how findings are labelled |
| remediation_sla_days | list (critical/high/medium/low) | 7/30/90/next cycle | The due date attached to every finding (Rule 6) and the overdue rows in the `## Due` table |
| siem_platform | splunk \| sentinel \| elastic \| chronicle \| opensearch \| none | none | Dialect of every detection in `detection.md`; `none` produces vendor-neutral pseudo-rules plus the fields they need |
| edr_platform | defender \| crowdstrike \| sentinelone \| elastic \| osquery \| none | none | Which containment lever and which telemetry `incident-response.md` and `endpoints.md` assume |
| primary_cloud | aws \| azure \| gcp \| on-prem \| multi | multi | Control set, log sources and identity model used by `cloud-security.md` |
| compliance_regime | list: none \| soc2 \| iso27001 \| pci \| hipaa \| gdpr \| nis2 \| dora | none | Mandatory controls, retention minimums, evidence format, and which Notification Clocks rows apply |
| authorized_scope_file | path | none | Long text at `~/Clawic/data/cybersecurity/<file>.md` listing systems, exclusions and allowed disruption; the Rule 1 gate reads it |

Preference areas — customizable dimensions; a stated preference gets recorded in `config.yaml` and applied from then on:

- **Tooling** — scanner, ticketing system, secrets manager, MDM, mail gateway, vulnerability and asset sources of truth — affects where every finding and every log query is expressed
- **Conventions** — finding id scheme, severity wording, ticket titles, naming of assets and environments, report template — affects `reporting.md` and every artifact written
- **Platform** — identity provider, OS mix across the fleet, on-prem versus cloud weighting, OT/ICS or medical devices in scope — affects `identity.md`, `endpoints.md` and which scans are safe at all
- **Safety posture** — whether the agent may run any command against live systems or only describe them, appetite for noisy or attacker-visible actions, approval chain for containment — affects Rule 1, Output Gates and `authorization.md`
- **Exclusions** — systems never to touch, third parties out of scope, jurisdictions with distinct rules, data the user will not have summarized — affects the authorization gate and evidence handling
- **Cadence** — access reviews, key rotation, restore drills, tabletops, pentests, phishing simulations, vendor reassessment — every accepted cadence becomes a row in the `## Due` table of `memory.md`
- **Output register** — timeline-first versus recommendation-first, how much attacker detail to include, whether to name techniques by ATT&CK id — affects every answer's shape

## Traps

| Trap | Why it fails | Do instead |
|------|-------------|------------|
| Reimaging or rebooting the first infected host | Deletes memory, running processes and the network state that prove scope — you now have one clean machine and no idea how many others are dirty | Isolate at the network layer first, capture volatile state, then rebuild (Rule 2) |
| Password reset as containment | Sessions, refresh tokens, app passwords, API keys and consent grants all survive it | The full eviction list in `identity.md` (Rule 5) |
| Blocking the C2 address and calling it eradicated | Infrastructure is disposable and the persistence is still installed | Hunt persistence before declaring recovery (`incident-response.md`) |
| Patching the exploited vulnerability and stopping there | The patch closes the door the attacker used to come in, not the one they left open | Patch, then hunt for accounts, keys, tasks and grants created since the intrusion |
| Cleaning a compromised host instead of rebuilding it | You are betting your judgement against an operator who chose their persistence deliberately | Rebuild from known-good; keep the disk image for analysis |
| Prioritizing purely by CVSS | Optimizes for wound severity while ignoring whether anyone is swinging | KEV, then EPSS with exposure, then crown-jewel reachability (Rule 4) |
| Turning on every detection the vendor ships | Precision collapses, the queue is abandoned, and the real alert arrives into a queue nobody reads | Deploy by technique with a response action and a precision target (Rule 8) |
| Deleting the malware sample "to be safe" | Destroys the only thing that identifies the actor and the campaign | Preserve in the case store; never in `~/Clawic/data/` (`forensics.md`) |
| "Just turn on MFA" | SMS and push are phishable, and AiTM proxies defeat both | Phishing-resistant factors on the accounts that matter first (Rule 7) |
| Notifying customers or posting publicly before counsel and the insurer | Voids coverage, contradicts the later legal filing, and burns the one credible statement you get to make | Fact pattern to counsel, counsel owns the wording (Notification Clocks) |
| Treating the pentest report as the security program | A pentest samples one path at one moment; the report's absence of findings is not evidence of anything | Findings feed the backlog; the program is built from attack paths (`program.md`) |
| Aggressive scanning of OT, medical or legacy devices | Some fail on a single unexpected packet — the outage becomes your incident | Passive discovery and vendor guidance for those segments (`network-security.md`) |
| Severity inflated to force attention | Works twice; after that every finding is discounted, including the real one | Argue exploitability, exposure and impact, and let a medium be a medium (`reporting.md`) |
| Risk accepted verbally | Reappears in the next audit with nobody's name on it | A dated acceptance with an owner and an expiry in `## Risk Accepted` (`findings.md` once split), plus its `## Due` row (Rule 6) |
| Analysis of a system whose ownership nobody has confirmed | Legal exposure for the user and for you, whatever the intention | The authorization gate and its fallbacks (Rule 1) |

## Where Experts Disagree

- **Isolate immediately versus watch to learn scope.** Watching gives you the true footprint and avoids tipping off an operator who would then detonate; isolating stops the damage now. The frontier is who you face: commodity intrusion or a ticking encryption timer → isolate; a quiet, targeted actor with a mature team watching → observe under a strict, written time box.
- **Paying extortion.** No consensus exists. What is not disputed: the decryptor is slow and partial so you restore from backups anyway for a meaningful share of systems, payment does not delete stolen data, and paying an entity under sanctions is itself a legal exposure that counsel — not the technical team — must clear (`ransomware.md`).
- **CVSS-driven SLAs versus risk-based prioritization.** Auditors reward a simple severity-to-days table and it is easy to defend; risk-based ranking fixes more real exposure per hour of engineering. Common resolution: keep the CVSS table as the contractual floor, and run KEV/EPSS/exposure as the working order inside it.
- **In-house detection versus MDR.** Below roughly the size where you can staff a 24/7 rota — which needs several analysts, not one — coverage is the argument and MDR wins. Above it, context is the argument and in-house wins. The hybrid that works is MDR for triage with in-house owning detection engineering and response decisions.
- **Periodic password rotation.** NIST SP 800-63B removed routine expiry in favour of screening against breached-password lists and phishing-resistant factors; several compliance regimes and auditors still expect a rotation policy. Where an auditor demands it, comply with the letter and put the actual defence into MFA and breach-list screening.

## Security & Privacy

**Credentials:** this skill never asks for, stores, logs, copies or transmits credentials, tokens, keys, session cookies or password hashes, and never writes one into `~/Clawic/data/`. Where a value is needed, it records a pointer in the `<kind>:<locator>` form.

**Local storage:** preferences, environment notes, findings, incident rows, detection inventory and generated artifacts stay in `~/Clawic/data/cybersecurity/` on this machine, plus rows in the shared inventories listed in the frontmatter. Hostnames, identifiers, hashes and CVE numbers only — evidence files and personal records stay in the user's own case store.

**Guardrails:** this skill supports authorized defensive work. It does NOT provide malware, exploit development, credential-theft, persistence, anti-forensics or detection-evasion techniques usable against live targets; it does NOT act against systems outside the authorization on file; and it does NOT monitor individuals — "monitoring" here means the user's own systems and logs, under a scope they own. Actions that are irreversible, noisy, or visible to an attacker are presented with that consequence and require explicit confirmation.

## Related Skills
More Clawic skills, get them at https://clawic.com/skills/cybersecurity (install if the user confirms):
- `security-best-practices` — line-by-line secure code review and minimal-diff fixes for a specific codebase
- `threat-modeling` — STRIDE, PASTA and data-flow diagram mechanics in depth
- `incident-response` — the incident process for outages of any kind, including non-security ones
- `auth` — building the authentication itself: sessions, JWT, OAuth, passwordless, SSO
- `firewall` — concrete firewall rule syntax on hosts and cloud providers

## Feedback

- If useful, star it: https://clawic.com/skills/cybersecurity
- Latest version: https://clawic.com/skills/cybersecurity

Part of [Clawic](https://clawic.com), the verified skill library. Get this skill: https://clawic.com/skills/cybersecurity.