mirror of
https://github.com/mukul975/Anthropic-Cybersecurity-Skills.git
synced 2026-06-14 06:54:57 +03:00
Expand 4 remaining SKILL.md stubs with researched content
This commit is contained in:
mukul975
@@ -14,20 +14,218 @@ license: Apache-2.0
|
||||
|
||||
# Analyzing Linux Audit Logs for Intrusion
|
||||
|
||||
Parse auditd logs to detect file access violations, privilege escalation,
|
||||
suspicious syscalls, and unauthorized process execution.
|
||||
|
||||
|
||||
## When to Use
|
||||
|
||||
- When investigating security incidents that require analyzing linux audit logs for intrusion
|
||||
- When building detection rules or threat hunting queries for this domain
|
||||
- When SOC analysts need structured procedures for this analysis type
|
||||
- When validating security monitoring coverage for related attack techniques
|
||||
- Investigating suspected unauthorized access or privilege escalation on Linux hosts
|
||||
- Hunting for evidence of exploitation, backdoor installation, or persistence mechanisms
|
||||
- Auditing compliance with security baselines (CIS, STIG, PCI-DSS) that require system call monitoring
|
||||
- Reconstructing a timeline of attacker actions during incident response
|
||||
- Detecting file tampering on critical system files such as `/etc/passwd`, `/etc/shadow`, or SSH keys
|
||||
|
||||
**Do not use** for network-level intrusion detection; use Suricata or Zeek for network traffic analysis. Auditd operates at the kernel level on individual hosts.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Familiarity with log analysis concepts and tools
|
||||
- Access to a test or lab environment for safe execution
|
||||
- Python 3.8+ with required dependencies installed
|
||||
- Appropriate authorization for any testing activities
|
||||
- Linux system with `auditd` package installed and the audit daemon running (`systemctl status auditd`)
|
||||
- Root or sudo access to configure audit rules and query logs
|
||||
- Audit rules deployed via `/etc/audit/rules.d/*.rules` or loaded with `auditctl`
|
||||
- Recommended: Neo23x0/auditd ruleset from GitHub for comprehensive baseline coverage
|
||||
- Familiarity with Linux syscalls (`execve`, `open`, `connect`, `ptrace`, etc.)
|
||||
- Log storage with sufficient retention (default location: `/var/log/audit/audit.log`)
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Verify Audit Daemon Status and Configuration
|
||||
|
||||
Confirm the audit system is running and check the current rule set:
|
||||
|
||||
```bash
|
||||
# Check auditd service status
|
||||
systemctl status auditd
|
||||
|
||||
# Show current audit rules loaded in the kernel
|
||||
auditctl -l
|
||||
|
||||
# Show audit daemon configuration
|
||||
cat /etc/audit/auditd.conf | grep -E "log_file|max_log_file|num_logs|space_left_action"
|
||||
|
||||
# Check if the audit backlog is being exceeded (dropped events)
|
||||
auditctl -s
|
||||
```
|
||||
|
||||
If the backlog limit is being reached, increase it:
|
||||
|
||||
```bash
|
||||
auditctl -b 8192
|
||||
```
|
||||
|
||||
### Step 2: Deploy Intrusion-Focused Audit Rules
|
||||
|
||||
Add rules that target common intrusion indicators. Place these in `/etc/audit/rules.d/intrusion.rules`:
|
||||
|
||||
```bash
|
||||
# Monitor credential files for unauthorized reads or modifications
|
||||
-w /etc/passwd -p wa -k credential_access
|
||||
-w /etc/shadow -p rwa -k credential_access
|
||||
-w /etc/gshadow -p rwa -k credential_access
|
||||
-w /etc/sudoers -p wa -k privilege_escalation
|
||||
-w /etc/sudoers.d/ -p wa -k privilege_escalation
|
||||
|
||||
# Monitor SSH configuration and authorized keys
|
||||
-w /etc/ssh/sshd_config -p wa -k sshd_config_change
|
||||
-w /root/.ssh/authorized_keys -p wa -k ssh_key_tampering
|
||||
|
||||
# Monitor user and group management commands
|
||||
-w /usr/sbin/useradd -p x -k user_management
|
||||
-w /usr/sbin/usermod -p x -k user_management
|
||||
-w /usr/sbin/groupadd -p x -k user_management
|
||||
|
||||
# Detect process injection via ptrace
|
||||
-a always,exit -F arch=b64 -S ptrace -F a0=0x4 -k process_injection
|
||||
-a always,exit -F arch=b64 -S ptrace -F a0=0x5 -k process_injection
|
||||
-a always,exit -F arch=b64 -S ptrace -F a0=0x6 -k process_injection
|
||||
|
||||
# Monitor execution of programs from unusual directories
|
||||
-a always,exit -F arch=b64 -S execve -F exe=/tmp -k exec_from_tmp
|
||||
-a always,exit -F arch=b64 -S execve -F exe=/dev/shm -k exec_from_shm
|
||||
|
||||
# Detect kernel module loading (rootkit installation)
|
||||
-a always,exit -F arch=b64 -S init_module -S finit_module -k kernel_module_load
|
||||
-a always,exit -F arch=b64 -S delete_module -k kernel_module_remove
|
||||
-w /sbin/insmod -p x -k kernel_module_tool
|
||||
-w /sbin/modprobe -p x -k kernel_module_tool
|
||||
|
||||
# Monitor network socket creation for reverse shells
|
||||
-a always,exit -F arch=b64 -S socket -F a0=2 -k network_socket_created
|
||||
-a always,exit -F arch=b64 -S connect -F a0=2 -k network_connection
|
||||
|
||||
# Detect cron job modifications (persistence)
|
||||
-w /etc/crontab -p wa -k cron_persistence
|
||||
-w /etc/cron.d/ -p wa -k cron_persistence
|
||||
-w /var/spool/cron/ -p wa -k cron_persistence
|
||||
|
||||
# Monitor log deletion or tampering
|
||||
-w /var/log/ -p wa -k log_tampering
|
||||
```
|
||||
|
||||
Reload rules after editing:
|
||||
|
||||
```bash
|
||||
augenrules --load
|
||||
auditctl -l | wc -l # Confirm rule count
|
||||
```
|
||||
|
||||
### Step 3: Search for Intrusion Indicators with ausearch
|
||||
|
||||
Use `ausearch` to query the audit log for specific events:
|
||||
|
||||
```bash
|
||||
# Search for all failed login attempts in the last 24 hours
|
||||
ausearch -m USER_LOGIN --success no -ts recent
|
||||
|
||||
# Search for commands executed by a specific user
|
||||
ausearch -ua 1001 -m EXECVE -ts today
|
||||
|
||||
# Search for all file access events on /etc/shadow
|
||||
ausearch -f /etc/shadow -ts this-week
|
||||
|
||||
# Search for privilege escalation via sudo
|
||||
ausearch -m USER_CMD -ts today
|
||||
|
||||
# Search for kernel module loading events
|
||||
ausearch -k kernel_module_load -ts this-month
|
||||
|
||||
# Search for processes executed from /tmp (common attack staging)
|
||||
ausearch -k exec_from_tmp -ts this-week
|
||||
|
||||
# Search for SSH key modifications
|
||||
ausearch -k ssh_key_tampering -ts this-month
|
||||
|
||||
# Search events in a specific time range
|
||||
ausearch -ts 03/15/2026 08:00:00 -te 03/15/2026 18:00:00
|
||||
|
||||
# Interpret syscall numbers and format output readably
|
||||
ausearch -k credential_access -i -ts today
|
||||
```
|
||||
|
||||
### Step 4: Generate Summary Reports with aureport
|
||||
|
||||
Use `aureport` to produce aggregate summaries for triage:
|
||||
|
||||
```bash
|
||||
# Summary of all authentication events
|
||||
aureport -au -ts this-week --summary
|
||||
|
||||
# Report of all failed events
|
||||
aureport --failed --summary -ts today
|
||||
|
||||
# Report of executable runs
|
||||
aureport -x --summary -ts today
|
||||
|
||||
# Report of all anomaly events
|
||||
aureport --anomaly -ts this-week
|
||||
|
||||
# Report of file access events
|
||||
aureport -f --summary -ts today
|
||||
|
||||
# Report of all events by key (maps to custom rule keys)
|
||||
aureport -k --summary -ts this-month
|
||||
```
|
||||
|
||||
### Step 5: Reconstruct the Attack Timeline
|
||||
|
||||
Combine ausearch queries to build a chronological narrative:
|
||||
|
||||
```bash
|
||||
# Identify the initial access timestamp
|
||||
ausearch -m USER_LOGIN -ua 0 --success yes -ts this-week -i | head -50
|
||||
|
||||
# Trace what the attacker did after gaining access
|
||||
ausearch -ua <UID> -ts "03/15/2026 14:00:00" -te "03/15/2026 18:00:00" -i | aureport -f -i
|
||||
|
||||
# Extract all commands executed during the incident window
|
||||
ausearch -m EXECVE -ts "03/15/2026 14:00:00" -te "03/15/2026 18:00:00" -i
|
||||
|
||||
# Check for persistence mechanisms installed
|
||||
ausearch -k cron_persistence -ts "03/15/2026 14:00:00" -i
|
||||
ausearch -k ssh_key_tampering -ts "03/15/2026 14:00:00" -i
|
||||
```
|
||||
|
||||
### Step 6: Forward Audit Logs to SIEM
|
||||
|
||||
Configure `audisp-remote` or `auditbeat` to ship logs to a central SIEM:
|
||||
|
||||
```bash
|
||||
# Using audisp-remote plugin (/etc/audit/plugins.d/au-remote.conf)
|
||||
active = yes
|
||||
direction = out
|
||||
path = /sbin/audisp-remote
|
||||
type = always
|
||||
|
||||
# Remote target (/etc/audit/audisp-remote.conf)
|
||||
remote_server = siem.internal.corp
|
||||
port = 6514
|
||||
transport = tcp
|
||||
```
|
||||
|
||||
## Key Concepts
|
||||
|
||||
| Term | Definition |
|
||||
|------|------------|
|
||||
| **auditd** | Linux Audit daemon that receives kernel audit events and writes to `/var/log/audit/audit.log` |
|
||||
| **auditctl** | CLI to control the audit system: add/remove rules, check status, set backlog size |
|
||||
| **ausearch** | Query tool for searching audit logs by message type, user, file, key, or time range |
|
||||
| **aureport** | Reporting tool that generates aggregate summaries for triage and compliance |
|
||||
| **audit rule key (-k)** | User-defined label on audit rules for fast filtering with ausearch and aureport |
|
||||
| **augenrules** | Merges `/etc/audit/rules.d/` files into `audit.rules` and loads into the kernel |
|
||||
|
||||
## Verification
|
||||
|
||||
- [ ] auditd is running and rules are loaded (`auditctl -l` returns expected rule count)
|
||||
- [ ] No audit backlog overflow (`auditctl -s` shows lost: 0)
|
||||
- [ ] ausearch returns events for each custom key
|
||||
- [ ] aureport generates non-empty summaries for authentication, executable, and file events
|
||||
- [ ] Timeline reconstruction produces a coherent chronological sequence
|
||||
- [ ] Critical file watches trigger alerts on test modifications
|
||||
- [ ] Logs are forwarding to central SIEM
|
||||
- [ ] Audit rules persist across reboot (rules in `/etc/audit/rules.d/`)
|
||||
|
||||
@@ -14,20 +14,158 @@ license: Apache-2.0
|
||||
|
||||
# Detecting OAuth Token Theft
|
||||
|
||||
Analyze OAuth sign-in telemetry for indicators of token theft including
|
||||
impossible travel, device fingerprint changes, and token replay attacks.
|
||||
|
||||
|
||||
## When to Use
|
||||
|
||||
- When investigating security incidents that require detecting oauth token theft
|
||||
- When building detection rules or threat hunting queries for this domain
|
||||
- When SOC analysts need structured procedures for this analysis type
|
||||
- When validating security monitoring coverage for related attack techniques
|
||||
- Investigating alerts for impossible travel or anomalous token usage in Microsoft Entra ID
|
||||
- Responding to a suspected session hijacking or pass-the-cookie attack
|
||||
- Configuring proactive defenses against OAuth token theft in an Azure/M365 environment
|
||||
- Detecting OAuth device code phishing campaigns that bypass MFA
|
||||
- Analyzing sign-in logs for token replay indicators
|
||||
- Implementing Token Protection conditional access policies to bind tokens to devices
|
||||
|
||||
**Do not use** for on-premises Kerberos ticket attacks (pass-the-ticket, golden ticket); use Active Directory-specific investigation techniques for those scenarios.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Familiarity with identity security concepts and tools
|
||||
- Access to a test or lab environment for safe execution
|
||||
- Python 3.8+ with required dependencies installed
|
||||
- Appropriate authorization for any testing activities
|
||||
- Microsoft Entra ID P2 license (required for Identity Protection risk detections and conditional access)
|
||||
- Global Administrator or Security Administrator role in the Entra admin center
|
||||
- Microsoft Defender for Cloud Apps (MDCA) license for session anomaly detection
|
||||
- Access to Entra ID Sign-in Logs and Audit Logs (Diagnostic Settings to Log Analytics or Sentinel)
|
||||
- Familiarity with OAuth 2.0 authorization flows (authorization code, device code, client credentials)
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Understand the Token Theft Attack Surface
|
||||
|
||||
Key token types and theft vectors:
|
||||
|
||||
| Token Type | Lifetime | Theft Vector | Impact |
|
||||
|---|---|---|---|
|
||||
| Access Token | 60-90 min | Memory dump, proxy interception | API access for token lifetime |
|
||||
| Refresh Token | Up to 90 days | Browser cookie theft, malware | Persistent access |
|
||||
| Primary Refresh Token | Session-based | Mimikatz, AADInternals | Full SSO to all M365/Azure apps |
|
||||
| Session Cookie | Varies | XSS, AitM proxy | Full session hijacking |
|
||||
|
||||
### Step 2: Configure Entra ID Sign-in Risk Detection
|
||||
|
||||
Enable Identity Protection to flag anomalous token usage:
|
||||
|
||||
```
|
||||
Entra Admin Center > Protection > Identity Protection > Risk Detections
|
||||
|
||||
Key risk detections for token theft:
|
||||
- Anomalous Token : Unusual token characteristics
|
||||
- Token Issuer Anomaly : Token from unusual issuer
|
||||
- Unfamiliar Sign-in : New location for user
|
||||
- Impossible Travel : Geographically impossible sign-ins
|
||||
- Malicious IP Address : Known malicious source
|
||||
```
|
||||
|
||||
Configure risk-based conditional access:
|
||||
|
||||
```
|
||||
Policy: "Block High-Risk Sign-ins"
|
||||
Users: All users (exclude break-glass accounts)
|
||||
Conditions: Sign-in Risk = High
|
||||
Grant: Block access
|
||||
|
||||
Policy: "Require MFA for Medium-Risk"
|
||||
Conditions: Sign-in Risk = Medium
|
||||
Grant: Require MFA + password change
|
||||
```
|
||||
|
||||
### Step 3: Enable Token Protection
|
||||
|
||||
Bind sign-in session tokens to device TPM:
|
||||
|
||||
```
|
||||
Entra Admin Center > Protection > Conditional Access > New Policy
|
||||
|
||||
Policy: "Enforce Token Protection"
|
||||
Users: Pilot group (expand after validation)
|
||||
Cloud Apps: Office 365 Exchange Online, SharePoint Online
|
||||
Conditions: Device Platforms = Windows
|
||||
Session: Require token protection for sign-in sessions
|
||||
Grant: Require compliant or Hybrid Azure AD joined device
|
||||
```
|
||||
|
||||
### Step 4: Detect Token Replay in Sign-in Logs
|
||||
|
||||
KQL queries for Microsoft Sentinel or Log Analytics:
|
||||
|
||||
```kusto
|
||||
// Detect anomalous token usage
|
||||
SigninLogs
|
||||
| where TimeGenerated > ago(7d)
|
||||
| where RiskDetail contains "token" or RiskEventTypes_V2 has "anomalousToken"
|
||||
| project TimeGenerated, UserPrincipalName, IPAddress, Location,
|
||||
RiskDetail, RiskLevelDuringSignIn, AppDisplayName
|
||||
| sort by TimeGenerated desc
|
||||
|
||||
// Detect impossible travel with token reuse
|
||||
SigninLogs
|
||||
| where TimeGenerated > ago(7d)
|
||||
| where ResultType == 0
|
||||
| summarize Locations=make_set(Location), IPs=make_set(IPAddress),
|
||||
Count=count() by UserPrincipalName, bin(TimeGenerated, 1h)
|
||||
| where array_length(Locations) > 1
|
||||
|
||||
// Detect device code flow abuse (phishing)
|
||||
SigninLogs
|
||||
| where TimeGenerated > ago(7d)
|
||||
| where AuthenticationProtocol == "deviceCode"
|
||||
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName
|
||||
```
|
||||
|
||||
### Step 5: Investigate and Respond
|
||||
|
||||
```powershell
|
||||
# Revoke all refresh tokens for compromised user
|
||||
Connect-MgGraph -Scopes "User.ReadWrite.All"
|
||||
Revoke-MgUserSignInSession -UserId "user@contoso.com"
|
||||
|
||||
# Force password reset
|
||||
Update-MgUser -UserId "user@contoso.com" -PasswordProfile @{
|
||||
ForceChangePasswordNextSignIn = $true
|
||||
}
|
||||
|
||||
# Review and revoke malicious OAuth app consent grants
|
||||
Get-MgUserOauth2PermissionGrant -UserId "user@contoso.com"
|
||||
Remove-MgOauth2PermissionGrant -OAuth2PermissionGrantId "<grant-id>"
|
||||
|
||||
# Check for mail forwarding rules (common post-compromise action)
|
||||
Get-MgUserMailFolderRule -UserId "user@contoso.com" -MailFolderId "Inbox" |
|
||||
Where-Object { $_.Actions.ForwardTo -ne $null }
|
||||
```
|
||||
|
||||
### Step 6: Enable Continuous Access Evaluation (CAE)
|
||||
|
||||
```
|
||||
Entra Admin Center > Protection > Conditional Access > Continuous Access Evaluation
|
||||
Strictly enforce location policies: Enabled
|
||||
|
||||
CAE triggers near-real-time token revocation when:
|
||||
- User account disabled/deleted
|
||||
- Password changed/reset
|
||||
- Admin explicitly revokes tokens
|
||||
- Identity Protection detects elevated risk
|
||||
```
|
||||
|
||||
## Key Concepts
|
||||
|
||||
| Term | Definition |
|
||||
|------|------------|
|
||||
| **Primary Refresh Token (PRT)** | Long-lived device-bound token providing SSO to all Azure AD apps |
|
||||
| **Token Protection** | Conditional access feature binding tokens to device TPM |
|
||||
| **Continuous Access Evaluation** | Near-real-time policy enforcement on token revocation |
|
||||
| **AitM (Adversary-in-the-Middle)** | Phishing that proxies auth flow to capture session cookies post-MFA |
|
||||
| **Device Code Flow** | OAuth grant for input-constrained devices; abused in phishing campaigns |
|
||||
|
||||
## Verification
|
||||
|
||||
- [ ] Identity Protection risk detections generating alerts for anomalous tokens
|
||||
- [ ] Conditional access policies block high-risk sign-ins and require MFA for medium-risk
|
||||
- [ ] Token Protection confirmed working (test from unregistered device fails)
|
||||
- [ ] KQL queries return results against synthetic anomaly events
|
||||
- [ ] CAE enabled and verified (revoke session, confirm access blocked within minutes)
|
||||
- [ ] Incident response runbook includes token revocation and OAuth consent review
|
||||
|
||||
@@ -14,20 +14,190 @@ license: Apache-2.0
|
||||
|
||||
# Implementing DevSecOps Security Scanning
|
||||
|
||||
Automate SAST, SCA, container image, and secret scanning in CI/CD
|
||||
pipelines with fail/pass gates based on severity thresholds.
|
||||
|
||||
|
||||
## When to Use
|
||||
|
||||
- When deploying or configuring implementing devsecops security scanning capabilities in your environment
|
||||
- When establishing security controls aligned to compliance requirements
|
||||
- When building or improving security architecture for this domain
|
||||
- When conducting security assessments that require this implementation
|
||||
- Setting up automated security scanning in a new or existing CI/CD pipeline
|
||||
- Shifting security left by catching vulnerabilities before production
|
||||
- Meeting compliance requirements (SOC 2, PCI-DSS, ISO 27001) mandating automated security testing
|
||||
- Integrating SAST, DAST, and SCA for comprehensive application security coverage
|
||||
- Establishing security gates that block deployments with critical/high vulnerabilities
|
||||
|
||||
**Do not use** as a replacement for manual penetration testing. Automated scanning catches common patterns but cannot replace human-driven assessments for business logic flaws.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Familiarity with application security concepts and tools
|
||||
- Access to a test or lab environment for safe execution
|
||||
- Python 3.8+ with required dependencies installed
|
||||
- Appropriate authorization for any testing activities
|
||||
- CI/CD platform: GitHub Actions, GitLab CI, Jenkins, or Azure DevOps
|
||||
- Container runtime (Docker) for running scanning tools
|
||||
- A staging environment URL for DAST scanning
|
||||
- Tool requirements: Semgrep (free), Trivy (free), OWASP ZAP (free), Gitleaks (free)
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Add Secrets Detection with Gitleaks
|
||||
|
||||
```yaml
|
||||
# .github/workflows/security.yml
|
||||
name: DevSecOps Security Pipeline
|
||||
on:
|
||||
push:
|
||||
branches: [main, develop]
|
||||
pull_request:
|
||||
branches: [main]
|
||||
|
||||
jobs:
|
||||
secrets-scan:
|
||||
name: Secrets Detection (Gitleaks)
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
- name: Run Gitleaks
|
||||
uses: gitleaks/gitleaks-action@v2
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
```
|
||||
|
||||
### Step 2: Add SAST Scanning with Semgrep
|
||||
|
||||
```yaml
|
||||
sast-scan:
|
||||
name: SAST (Semgrep)
|
||||
runs-on: ubuntu-latest
|
||||
container:
|
||||
image: semgrep/semgrep
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- name: Run Semgrep SAST scan
|
||||
run: |
|
||||
semgrep scan \
|
||||
--config p/security-audit \
|
||||
--config p/owasp-top-ten \
|
||||
--severity ERROR \
|
||||
--error \
|
||||
--json --output semgrep-results.json .
|
||||
- uses: actions/upload-artifact@v4
|
||||
if: always()
|
||||
with:
|
||||
name: semgrep-results
|
||||
path: semgrep-results.json
|
||||
```
|
||||
|
||||
### Step 3: Add SCA and Container Scanning with Trivy
|
||||
|
||||
```yaml
|
||||
sca-scan:
|
||||
name: SCA & Container Scan (Trivy)
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- name: Trivy filesystem scan (dependencies)
|
||||
uses: aquasecurity/trivy-action@0.28.0
|
||||
with:
|
||||
scan-type: 'fs'
|
||||
scan-ref: '.'
|
||||
severity: 'CRITICAL,HIGH'
|
||||
exit-code: '1'
|
||||
format: 'json'
|
||||
output: 'trivy-fs-results.json'
|
||||
- name: Build and scan container image
|
||||
run: |
|
||||
docker build -t app:${{ github.sha }} .
|
||||
- uses: aquasecurity/trivy-action@0.28.0
|
||||
with:
|
||||
image-ref: 'app:${{ github.sha }}'
|
||||
severity: 'CRITICAL,HIGH'
|
||||
exit-code: '1'
|
||||
```
|
||||
|
||||
### Step 4: Add DAST Scanning with OWASP ZAP
|
||||
|
||||
```yaml
|
||||
dast-scan:
|
||||
name: DAST (OWASP ZAP)
|
||||
runs-on: ubuntu-latest
|
||||
needs: [deploy-staging]
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- name: ZAP Baseline Scan
|
||||
uses: zaproxy/action-baseline@v0.14.0
|
||||
with:
|
||||
target: ${{ vars.STAGING_URL }}
|
||||
rules_file_name: '.zap/rules.tsv'
|
||||
```
|
||||
|
||||
Configure `.zap/rules.tsv` alert thresholds:
|
||||
|
||||
```tsv
|
||||
40012 FAIL (Cross Site Scripting - Reflected)
|
||||
40014 FAIL (Cross Site Scripting - Persistent)
|
||||
40018 FAIL (SQL Injection)
|
||||
90019 FAIL (Server Side Code Injection)
|
||||
10038 FAIL (Content Security Policy Header Not Set)
|
||||
```
|
||||
|
||||
### Step 5: Enforce Security Gates
|
||||
|
||||
```yaml
|
||||
security-gate:
|
||||
name: Security Gate
|
||||
runs-on: ubuntu-latest
|
||||
needs: [secrets-scan, sast-scan, sca-scan]
|
||||
if: always()
|
||||
steps:
|
||||
- name: Check scan results
|
||||
run: |
|
||||
if [[ "${{ needs.secrets-scan.result }}" == "failure" ]]; then
|
||||
echo "BLOCKED: Secrets detected"; exit 1
|
||||
fi
|
||||
if [[ "${{ needs.sast-scan.result }}" == "failure" ]]; then
|
||||
echo "BLOCKED: SAST critical/high findings"; exit 1
|
||||
fi
|
||||
if [[ "${{ needs.sca-scan.result }}" == "failure" ]]; then
|
||||
echo "BLOCKED: Vulnerable dependencies"; exit 1
|
||||
fi
|
||||
echo "All security gates passed"
|
||||
```
|
||||
|
||||
### Step 6: Configure Pre-commit Hooks
|
||||
|
||||
```yaml
|
||||
# .pre-commit-config.yaml
|
||||
repos:
|
||||
- repo: https://github.com/gitleaks/gitleaks
|
||||
rev: v8.22.1
|
||||
hooks:
|
||||
- id: gitleaks
|
||||
- repo: https://github.com/semgrep/semgrep
|
||||
rev: v1.102.0
|
||||
hooks:
|
||||
- id: semgrep
|
||||
args: ['--config', 'p/security-audit', '--error']
|
||||
```
|
||||
|
||||
```bash
|
||||
pip install pre-commit
|
||||
pre-commit install
|
||||
pre-commit run --all-files
|
||||
```
|
||||
|
||||
## Key Concepts
|
||||
|
||||
| Term | Definition |
|
||||
|------|------------|
|
||||
| **SAST** | Static Application Security Testing - analyzes source code without execution |
|
||||
| **DAST** | Dynamic Application Security Testing - tests running applications |
|
||||
| **SCA** | Software Composition Analysis - scans dependencies for known vulnerabilities |
|
||||
| **SBOM** | Software Bill of Materials - inventory of all components |
|
||||
| **Shift Left** | Moving security testing earlier in the SDLC |
|
||||
| **Security Gate** | CI/CD checkpoint blocking deployment on scan failures |
|
||||
|
||||
## Verification
|
||||
|
||||
- [ ] Gitleaks blocks commits containing hardcoded secrets
|
||||
- [ ] Semgrep runs on every PR and reports findings
|
||||
- [ ] Trivy detects known-vulnerable dependencies
|
||||
- [ ] OWASP ZAP baseline scan runs against staging URL
|
||||
- [ ] Security gate blocks merges when critical/high findings exist
|
||||
- [ ] Branch protection rules enforce required status checks
|
||||
- [ ] Pre-commit hooks catch issues locally before push
|
||||
|
||||
@@ -14,20 +14,176 @@ license: Apache-2.0
|
||||
|
||||
# Implementing Privileged Session Monitoring
|
||||
|
||||
Monitor privileged sessions (SSH, RDP, database) with real-time command
|
||||
logging, anomaly detection, session recording, and compliance reporting.
|
||||
|
||||
|
||||
## When to Use
|
||||
|
||||
- When deploying or configuring implementing privileged session monitoring capabilities in your environment
|
||||
- When establishing security controls aligned to compliance requirements
|
||||
- When building or improving security architecture for this domain
|
||||
- When conducting security assessments that require this implementation
|
||||
- Deploying session recording for all privileged access to critical servers and databases
|
||||
- Meeting compliance requirements (PCI-DSS 10.2, SOX, HIPAA, ISO 27001) mandating privileged activity monitoring
|
||||
- Investigating incidents where an administrator may have performed unauthorized actions
|
||||
- Implementing real-time alerting for high-risk commands during privileged sessions
|
||||
- Establishing a forensic audit trail of all administrative actions on production infrastructure
|
||||
|
||||
**Do not use** for monitoring standard user sessions; use EDR/UBA for general user behavior monitoring.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Familiarity with identity access management concepts and tools
|
||||
- Access to a test or lab environment for safe execution
|
||||
- Python 3.8+ with required dependencies installed
|
||||
- Appropriate authorization for any testing activities
|
||||
- CyberArk PAM or Privilege Cloud with Digital Vault, or open-source alternative (Teleport)
|
||||
- PSM (Privileged Session Manager) or PSMP installed on hardened jump server
|
||||
- Network architecture routing all privileged access through the PSM proxy
|
||||
- Sufficient storage for recordings (estimate: 50-250 KB/min for RDP, 5-20 KB/min for SSH)
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Route All Privileged Access Through PSM
|
||||
|
||||
```
|
||||
Architecture:
|
||||
Admin User --> PVWA (Web Portal) --> PSM (Jump Server) --> Target Server
|
||||
|
||||
Network Controls:
|
||||
- DENY direct RDP (3389) / SSH (22) to targets from user networks
|
||||
- ALLOW RDP/SSH to targets ONLY from PSM server IPs
|
||||
- ALLOW PVWA access (443) from admin user networks
|
||||
```
|
||||
|
||||
### Step 2: Configure PSM Connection Components
|
||||
|
||||
```
|
||||
PVWA > Administration > Connection Components
|
||||
|
||||
For Windows RDP:
|
||||
Connection Component: PSM-RDP
|
||||
Record Sessions: Yes
|
||||
Recording Format: AVI (video) + Keystrokes (text)
|
||||
Record Windows Titles: Yes
|
||||
|
||||
For Linux SSH:
|
||||
Connection Component: PSM-SSH
|
||||
Record Sessions: Yes
|
||||
Record Unix Commands: Yes
|
||||
```
|
||||
|
||||
### Step 3: Configure Session Recording Policies
|
||||
|
||||
```
|
||||
PVWA > Platform Management > Session Management
|
||||
|
||||
Enable Session Recording: Yes
|
||||
Keystroke Logging: Enable Transcript + Window Events
|
||||
Storage: Vault (encrypted, tamper-proof)
|
||||
|
||||
Retention periods (per compliance):
|
||||
PCI-DSS: 1 year available, 3 months accessible
|
||||
SOX: 7 years
|
||||
HIPAA: 6 years
|
||||
|
||||
Per-Safe policies:
|
||||
Production-Servers-Admin: Record all, real-time monitoring
|
||||
Third-Party-Vendor-Access: Record all, dual authorization required
|
||||
```
|
||||
|
||||
### Step 4: Enable Real-Time Monitoring and Alerting
|
||||
|
||||
Configure CyberArk Privileged Threat Analytics (PTA):
|
||||
|
||||
```
|
||||
PTA > Configuration > Security Events
|
||||
|
||||
Rule: High-Risk Command Detected
|
||||
Trigger patterns:
|
||||
- rm -rf /
|
||||
- chmod 777
|
||||
- useradd / passwd root
|
||||
- wget http* | sh / curl * | bash
|
||||
- nc -e /bin/sh
|
||||
Action: Alert SOC + Flag session as high-risk
|
||||
|
||||
Rule: Credential Access Attempt
|
||||
Trigger:
|
||||
- mimikatz.exe
|
||||
- procdump.exe targeting lsass
|
||||
- ntdsutil.exe
|
||||
Action: Terminate session + Alert SOC + Lock account
|
||||
|
||||
Rule: Unusual Session Duration
|
||||
Trigger: Session > 4 hours
|
||||
Action: Alert SOC for review
|
||||
```
|
||||
|
||||
### Step 5: Configure Session Review Workflow
|
||||
|
||||
```
|
||||
PVWA > Recordings > Search and Review
|
||||
|
||||
Review features:
|
||||
- Video playback with timeline scrubbing
|
||||
- Keystroke transcript alongside video
|
||||
- Window title log for application tracking
|
||||
- Risk events highlighted on timeline
|
||||
- Text search within keystroke transcript
|
||||
- Auditor can mark: Reviewed-OK, Suspicious, Requires-Investigation
|
||||
```
|
||||
|
||||
### Step 6: Open-Source Alternative - Teleport
|
||||
|
||||
```yaml
|
||||
# /etc/teleport.yaml
|
||||
teleport:
|
||||
nodename: teleport-proxy.corp.internal
|
||||
|
||||
auth_service:
|
||||
enabled: yes
|
||||
session_recording: "node-sync"
|
||||
audit_sessions_uri: "s3://teleport-session-recordings/sessions?region=us-east-1"
|
||||
enhanced_recording:
|
||||
enabled: true
|
||||
command_events: true
|
||||
network_events: true
|
||||
```
|
||||
|
||||
```bash
|
||||
# List recorded sessions
|
||||
tsh recordings ls --from=2026-03-15
|
||||
|
||||
# Play back a session
|
||||
tsh play <session-id>
|
||||
|
||||
# Export session events for SIEM
|
||||
tsh recordings export <session-id> --format=json > session_events.json
|
||||
```
|
||||
|
||||
### Step 7: Forward Session Metadata to SIEM
|
||||
|
||||
```
|
||||
CyberArk PTA > SIEM Integration
|
||||
Protocol: TCP + TLS (Syslog CEF)
|
||||
Destination: siem.corp.internal:6514
|
||||
|
||||
Events forwarded:
|
||||
- Session start/stop with user, target, duration
|
||||
- High-risk command alerts
|
||||
- Session termination events
|
||||
- Dual-authorization approvals/denials
|
||||
```
|
||||
|
||||
## Key Concepts
|
||||
|
||||
| Term | Definition |
|
||||
|------|------------|
|
||||
| **PSM** | Privileged Session Manager - proxy recording all sessions in video and text |
|
||||
| **PSMP** | PSM for SSH Proxy - Linux-based proxy for SSH, SCP, SFTP sessions |
|
||||
| **PTA** | Privileged Threat Analytics - behavioral analytics and risk scoring for sessions |
|
||||
| **Dual Authorization** | Two authorized users must approve before a privileged session is established |
|
||||
| **Session Isolation** | All admin access proxied through PAM; no direct connections to targets |
|
||||
| **Keystroke Transcript** | Searchable text log of all keystrokes during a recorded session |
|
||||
|
||||
## Verification
|
||||
|
||||
- [ ] All privileged access routes through PSM (direct RDP/SSH blocked by firewall)
|
||||
- [ ] Session recordings stored encrypted with tamper protection
|
||||
- [ ] Keystroke transcripts captured and searchable for SSH and RDP
|
||||
- [ ] PTA rules trigger alerts for high-risk commands (test with benign trigger)
|
||||
- [ ] Real-time monitoring dashboard shows active sessions with correct metadata
|
||||
- [ ] Recordings play back in PVWA HTML5 player with timeline and transcript
|
||||
- [ ] Retention policies match compliance requirements
|
||||
- [ ] Dual authorization enforced for vendor and high-risk access
|
||||
- [ ] Session metadata and alerts forwarding to SIEM
|
||||
|
||||
Reference in New Issue
Block a user