Enable Claude to assist defenders with comprehensive security hardening, detection rule engineering, security baseline establishment, patch management, and security architecture review. Claude directly analyzes provided configurations, scripts, and system state — then produces specific hardening commands, detection rules, and improvement plans.
Activation Triggers
This skill activates when the user asks about:
Hardening Linux (Ubuntu, RHEL, CentOS, Debian) servers
Hardening Windows Server or Windows workstations (CIS Benchmarks)
Account Security:
[ ] Guest account disabled
[ ] Local Administrator account disabled or renamed
[ ] LAPS deployed (Local Administrator Password Solution)
[ ] No accounts with "Password never expires"
[ ] Account lockout: 5 attempts, 30-min lockout
[ ] Admin accounts not used for daily tasks
Network Security:
[ ] SMBv1 disabled
[ ] LLMNR disabled via GPO
[ ] NBT-NS disabled on all NICs
[ ] RDP restricted to VPN/jump host access only
[ ] WinRM access restricted to admin systems
[ ] PowerShell remoting disabled where not needed
Logging & Monitoring:
[ ] Windows Defender enabled and updated
[ ] EDR agent deployed and communicating
[ ] Sysmon deployed with current config
[ ] Event log size: Security 1GB+, System 512MB+, Application 256MB+
[ ] Log forwarding to SIEM configured
System Configuration:
[ ] BitLocker enabled on all endpoints
[ ] AppLocker or WDAC configured for application control
[ ] UAC: Prompt for credentials for all apps
[ ] Windows Update: Automatic, critical updates immediate
[ ] Unnecessary features removed (Telnet, SMB1, PowerShell 2.0)
[ ] WDAC Code Integrity policies for servers
3. Detection Engineering
When the user asks to create detection rules:
Claude produces complete, ready-to-deploy detection rules.
Detection Rule Development Workflow:
Step 1: Define what you're detecting
- What specific behavior? (not "malware" but "PowerShell download cradle")
- Which ATT&CK technique? (T1059.001 — PowerShell)
- What data sources? (PowerShell logs, process creation, network)
Step 2: Collect sample telemetry
- Capture true positive examples (from lab, red team, threat intel)
- Collect false positive examples (legitimate activity)
Step 3: Identify unique indicators
- What distinguishes malicious from legitimate?
- Avoid indicators that change between variants (file names, IPs)
- Prefer behavioral indicators (parent-child process, network pattern)
Step 4: Write and tune the rule
- Start with high-confidence, low-noise detection
- Test against both TP and FP datasets
- Add exceptions for known-legitimate patterns
Step 5: Deploy and monitor
- Track alert volume: sudden increase = new FP
- Review untuned rules monthly
Detection Rule Templates:
# Sigma Rule: Suspicious Process Spawned from Office Applicationtitle:OfficeApplicationSpawningScriptInterpreterid:d2b45b6c-7b4e-4c2f-a8b9-1234567890abstatus:stabledescription:DetectsOfficeapplicationsspawningscriptinterpreters—commoninmacro-basedinitialaccessreferences:-https://attack.mitre.org/techniques/T1566/001/tags:-attack.initial_access-attack.t1566.001-attack.execution-attack.t1059logsource:category:process_creationproduct:windowsdetection:selection_parent:ParentImage|endswith:-'\WINWORD.EXE'-'\EXCEL.EXE'-'\POWERPNT.EXE'-'\MSACCESS.EXE'-'\MSPUB.EXE'-'\outlook.exe'selection_child:Image|endswith:-'\cmd.exe'-'\powershell.exe'-'\wscript.exe'-'\cscript.exe'-'\mshta.exe'-'\regsvr32.exe'-'\rundll32.exe'condition:selection_parentandselection_childfalsepositives:-Somelegitimatemacrosmayspawncmd.exeforadministrativepurposes(rare)level:high
When the user asks to define or monitor security baselines:
Baseline Definition Framework:
## Security Baseline — [System Type] — [Environment]### Normal Behavior Profiles**Authentication Baseline:**- Admin accounts: Only log in during business hours (08:00–18:00 local)
- Service accounts: Never have interactive logon (Event 4624 Type 2)
- Failed logins: <5 per user per day (>5 = investigate)
- New login locations: Alert on first-time country/city
**Process Baseline:**- Web server: Never spawns cmd.exe or powershell.exe
- Database: No outbound network connections except DB clients
- System processes: Parent process matches expected (e.g., services.exe → svchost.exe)
**Network Baseline:**- Workstations: No direct SMB to other workstations (server-to-server OK)
- DNS: <100 queries per minute per host; 50+ unique domains per hour = investigate
- Egress: Only expected protocols (HTTPS, DNS, SMTP for mail servers)
**File System Baseline:**- System directories: No new executables in \Windows\System32\ between patches
- User directories: Alert on new .exe, .dll, .ps1 in %APPDATA%
- Logs: Never deleted (alert on Event ID 1102)
Automated Baseline Checks:
# Linux: Track listening services
netstat -tulnap > /tmp/services_current.txt
diff /tmp/services_baseline.txt /tmp/services_current.txt
# Compare against known-good process list
ps auxf > /tmp/processes_current.txt
diff /tmp/processes_baseline.txt /tmp/processes_current.txt
# Find recently modified system files
find /bin /sbin /usr/bin /usr/sbin /lib -newer /tmp/baseline_timestamp -type f 2>/dev/null
# Windows: Compare running services
Get-Service | Where-Object {$_.Status -eq "Running"} | Select-Object Name,DisplayName | Sort-Object Name
Current OS baselines — Windows 11 / Server 2025 and recent Linux CIS benchmarks; enforce LAPS (Windows LAPS), Credential Guard, and Attack Surface Reduction (ASR) rules.
Telemetry that matters — deploy a maintained Sysmon config (SwiftOnSecurity/Olaf base), enable PowerShell script-block + module logging, command-line auditing, and ship to the SIEM; on Linux use auditd + eBPF (Falco/Tetragon).
Detection-as-code — manage Sigma detections in git with tests and CI conversion to the target SIEM; track ATT&CK coverage as a measurable metric (DeTT&CT-style).
Identity hardening — phishing-resistant MFA (FIDO2/passkeys), conditional access, and tiered admin (PAW) to counter token theft and AD escalation.
Zero Trust maturity — assess against CISA's Zero Trust Maturity Model pillars (identity, device, network, app, data) and report a maturity score per pillar.
Cloud & container hardening — extend baselines to cloud workloads and Kubernetes (ties to Skill 10); validate with the included checker and CSPM.
Precision rule: every recommendation pairs the hardening change with the detection that proves it (or catches its bypass).
