home / skills / 404kidwiz / claude-supercode-skills / powershell-security-hardening-skill

powershell-security-hardening-skill skill

unsafe

This skill helps harden PowerShell environments by enforcing least privilege, JEA, constrained language mode, and enterprise security baselines.

npx playbooks add skill 404kidwiz/claude-supercode-skills --skill powershell-security-hardening-skill

Review the files below or copy the command above to add this skill to your agents.

Files (8)

SKILL.md

3.3 KB

---
name: powershell-security-hardening
description: Expert in Windows security hardening and PowerShell security configuration. Specializes in securing automation, enforcing least privilege, and aligning with enterprise security baselines. Use for securing PowerShell environments and Windows systems. Triggers include "PowerShell security", "constrained language mode", "JEA", "execution policy", "security baseline", "PowerShell logging".
---

# PowerShell Security Hardening

## Purpose
Provides expertise in Windows security hardening and PowerShell security configuration. Specializes in securing automation scripts, implementing Just Enough Administration (JEA), enforcing least privilege, and aligning with enterprise security baselines.

## When to Use
- Configuring PowerShell security policies
- Implementing Constrained Language Mode
- Setting up Just Enough Administration (JEA)
- Enabling PowerShell logging and auditing
- Securing automation credentials
- Applying CIS/STIG baselines
- Protecting against PowerShell attacks
- Implementing execution policies

## Quick Start
**Invoke this skill when:**
- Hardening PowerShell environments
- Implementing JEA or constrained language mode
- Configuring PowerShell logging
- Securing automation credentials
- Applying security baselines

**Do NOT invoke when:**
- General Windows administration → use `/windows-infra-admin`
- PowerShell development → use `/powershell-7-expert`
- Active Directory security → use `/ad-security-reviewer`
- Network security → use `/network-engineer`

## Decision Framework
```
Security Requirement?
├── Script Execution Control
│   ├── Basic → Execution Policy
│   └── Strict → AppLocker/WDAC
├── Language Restriction
│   └── Constrained Language Mode
├── Privilege Reduction
│   └── JEA (Just Enough Administration)
└── Auditing
    └── Script Block Logging + Transcription
```

## Core Workflows

### 1. PowerShell Logging Setup
1. Enable Script Block Logging via GPO
2. Enable Module Logging for key modules
3. Configure transcription to secure location
4. Set up protected event log forwarding
5. Create alerts for suspicious patterns
6. Test logging with sample scripts

### 2. JEA Configuration
1. Define role capabilities file
2. Specify allowed cmdlets and parameters
3. Create session configuration
4. Register JEA endpoint
5. Test with limited user account
6. Document role assignments

### 3. Constrained Language Mode
1. Assess application requirements
2. Create AppLocker/WDAC policy
3. Enable CLM for untrusted scripts
4. Whitelist required scripts
5. Test application functionality
6. Monitor for bypass attempts

## Best Practices
- Enable script block logging on all systems
- Use JEA instead of full admin rights
- Store credentials in secure vault (not scripts)
- Apply AMSI for malware detection
- Use signed scripts with AllSigned policy
- Regularly audit PowerShell usage logs

## Anti-Patterns
| Anti-Pattern | Problem | Correct Approach |
|--------------|---------|------------------|
| Credentials in scripts | Exposure risk | SecretManagement vault |
| Disabled logging | No visibility | Enable all logging |
| Bypass execution policy | Security theater | AppLocker/WDAC |
| Full admin for automation | Over-privileged | JEA with minimal rights |
| Ignoring AMSI | Malware blind spot | Keep AMSI enabled |

Overview

This skill provides focused guidance for hardening PowerShell and Windows automation environments. It specializes in configuring execution controls, enabling comprehensive logging, implementing Just Enough Administration (JEA), and enforcing constrained language mode. Use it to align PowerShell configuration with enterprise baselines and minimize attack surface from scripts and automation.

How this skill works

I inspect current PowerShell policy settings, logging configuration, and endpoint session configurations to identify gaps versus recommended baselines. I recommend concrete controls such as execution policy choices, AppLocker/WDAC for strict execution control, enabling script block and module logging, and defining JEA role capabilities. I also provide stepwise workflows to implement, test, and validate each control and to secure automation credentials using vaults.

When to use it

When you need to harden PowerShell across endpoints before production automation
When implementing JEA to reduce administrative privileges for operators
When enabling or auditing PowerShell script block, module logging, or transcription
When applying constrained language mode for untrusted contexts
When aligning PowerShell settings with CIS/STIG or enterprise baselines

Best practices

Enable script block logging and module logging centrally and validate ingestion
Prefer JEA endpoints over granting full administrator rights to automation accounts
Store automation credentials in a secure vault; never hardcode secrets in scripts
Use AppLocker or WDAC for tamper-resistant execution control instead of relying on execution policy alone
Sign production scripts and enforce AllSigned where operationally feasible
Keep AMSI enabled and monitor for telemetry indicating bypass attempts

Example use cases

Locking down a fleet of servers to prevent unauthorized script execution using AppLocker rules and constrained language mode
Creating a JEA endpoint that allows helpdesk staff to run specific maintenance cmdlets without full admin rights
Configuring centralized script block and module logging with secure storage and alerting for suspicious commands
Migrating automation accounts to secret management vaults and removing embedded credentials from runbooks
Validating compliance with a CIS/STIG baseline and remediating deviations in PowerShell settings

FAQ

Will enabling constrained language mode break my automation?

Constrained language mode can restrict some advanced script capabilities. Test policies in a staging environment, whitelist required components via AppLocker/WDAC, and identify necessary language features before enforcing widely.

Is execution policy sufficient to prevent malicious scripts?

No. Execution policy is a user preference and can be bypassed. Use AppLocker/WDAC for enforceable execution control and enable logging and AMSI for detection.