搜索

PythonReactSEOPDF
GitHub Skill

ops-security-audit

Structured workflow for infrastructure security audits including compliance validation, vulnerability assessment, and security posture review.

LerianStudio☆ 86 仓库 Stars10 仓库 Forks

安装与使用

请根据来源仓库和你的 AI 工具说明安装此技能。先阅读技能文件和依赖要求,再添加到工作流。

查看来源 ↗使用指南

技能说明

Security Audit Workflow

This skill defines the structured process for infrastructure security audits. Use it for systematic security assessment and compliance validation.


Security Audit Phases

Phase Focus Output
1. Scope Definition Define audit boundaries Audit plan
2. Automated Scanning Run security tools Scan results
3. Manual Review Deep-dive analysis Finding details
4. Compliance Mapping Map to frameworks Compliance report
5. Remediation Planning Prioritize fixes Remediation plan
6. Verification Confirm fixes Closure report

Phase 1: Scope Definition

Audit Scope Template
## Security Audit Scope

**Audit ID:** SEC-AUDIT-YYYY-NNN
**Audit Period:** YYYY-MM-DD to YYYY-MM-DD
**Auditor:** [name/team]

### In Scope

| Category | Components |
|----------|------------|
| **Accounts** | AWS Account 123456789, 987654321 |
| **Regions** | us-east-1, us-west-2 |
| **Services** | EC2, RDS, S3, IAM, VPC, EKS |
| **Environments** | Production, Staging |
| **Compliance** | SOC2 Type II, PCI-DSS 4.0 |

### Out of Scope

| Category | Reason |
|----------|--------|
| Development accounts | Covered by separate audit |
| Application code | Covered by code review process |
| Third-party SaaS | Covered by vendor assessments |

### Audit Objectives

1. Validate compliance with [framework]
2. Identify security vulnerabilities in infrastructure
3. Assess IAM and access control posture
4. Review network security configuration
5. Evaluate logging and monitoring coverage

Phase 2: Automated Scanning

Security Scanning Tools
Tool Purpose Scope
AWS Security Hub Aggregated findings All AWS services
AWS Config Configuration compliance Resource configuration
GuardDuty Threat detection Account activity
Trivy Container vulnerabilities EKS images
Checkov IaC security Terraform/CloudFormation
ScoutSuite Cloud security audit Multi-cloud
Scan Execution Template
# AWS Security Hub findings
aws securityhub get-findings --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}]}'

# AWS Config compliance
aws configservice get-compliance-summary-by-config-rule

# Trivy container scan
trivy image --severity CRITICAL,HIGH [image]

# Checkov IaC scan
checkov -d /path/to/terraform --framework terraform
Scan Results Template
## Automated Scan Results

**Scan Date:** YYYY-MM-DD
**Tools Used:** Security Hub, Trivy, Checkov

### Summary by Severity

| Source | Critical | High | Medium | Low |
|--------|----------|------|--------|-----|
| Security Hub | X | X | X | X |
| Trivy | X | X | X | X |
| Checkov | X | X | X | X |
| **Total** | **X** | **X** | **X** | **X** |

### Critical Findings Requiring Immediate Action

| Finding ID | Source | Description |
|------------|--------|-------------|
| SEC-001 | Security Hub | [description] |
| SEC-002 | Trivy | [description] |

Phase 3: Manual Review

Review Checklist
IAM Review
  • Root account MFA enabled
  • Root account not used for daily operations
  • Password policy meets requirements
  • No users with inline policies
  • Service accounts use roles, not keys
  • Access keys rotated <90 days
  • Unused IAM users/roles identified
Network Security Review
  • VPC flow logs enabled
  • No 0.0.0.0/0 ingress rules (except public ALB)
  • Security groups follow least privilege
  • NACLs configured appropriately
  • VPC endpoints for AWS services
  • No public RDS instances
  • No public S3 buckets (unless intended)
Data Protection Review
  • S3 buckets encrypted (SSE-S3 or SSE-KMS)
  • EBS volumes encrypted
  • RDS instances encrypted
  • SSL/TLS for data in transit
  • KMS key rotation enabled
  • Secrets in Secrets Manager (not code/config)
Logging & Monitoring Review
  • CloudTrail enabled (all regions)
  • CloudTrail logs encrypted
  • CloudTrail log validation enabled
  • VPC flow logs enabled
  • GuardDuty enabled
  • Security Hub enabled
  • Alert rules for critical events
Manual Review Template
## Manual Review Findings

### IAM Security

| Check | Status | Finding |
|-------|--------|---------|
| Root MFA | PASS | MFA enabled |
| Root usage | PASS | No root activity in 90 days |
| Password policy | PARTIAL | Missing complexity requirement |
| Access key age | FAIL | 3 keys >90 days |

### Network Security

| Check | Status | Finding |
|-------|--------|---------|
| VPC flow logs | PASS | Enabled on all VPCs |
| SG 0.0.0.0/0 | FAIL | sg-xxx allows SSH from anywhere |
| Public RDS | PASS | No public instances |

[Continue for all categories...]

Phase 4: Compliance Mapping

SOC2 Control Mapping
Control Requirement Evidence Status
CC6.1 Logical access controls IAM policies, MFA Compliant
CC6.6 System boundaries VPC, security groups Compliant
CC6.7 Encryption in transit TLS configuration Compliant
CC7.1 System monitoring CloudTrail, GuardDuty Compliant
CC7.2 Anomaly detection GuardDuty findings Partial
PCI-DSS Mapping
Requirement Description Evidence Status
1.3 Firewall configuration Security groups Compliant
3.4 Encryption at rest KMS, S3 encryption Compliant
8.3 Strong authentication MFA, IAM policies Partial
10.2 Audit logging CloudTrail Compliant
11.3 Vulnerability scanning Security Hub Compliant
Compliance Summary Template
## Compliance Status Report

**Assessment Date:** YYYY-MM-DD
**Frameworks:** SOC2 Type II, PCI-DSS 4.0

### Overall Status

| Framework | Total Controls | Compliant | Partial | Non-Compliant |
|-----------|---------------|-----------|---------|---------------|
| SOC2 | 50 | 45 | 3 | 2 |
| PCI-DSS | 40 | 35 | 4 | 1 |

### Non-Compliant Controls

| Framework | Control | Gap | Remediation |
|-----------|---------|-----|-------------|
| SOC2 | CC7.2 | Anomaly alerting incomplete | Enable GuardDuty alerts |
| PCI-DSS | 8.3 | MFA not enforced for all | Enable MFA requirement |

Phase 5: Remediation Planning

Prioritization Matrix
Priority Criteria SLA
P1 Critical vulnerability, compliance blocker 24 hours
P2 High vulnerability, significant risk 7 days
P3 Medium vulnerability, moderate risk 30 days
P4 Low vulnerability, best practice 90 days
Remediation Plan Template
## Remediation Plan

**Plan Created:** YYYY-MM-DD
**Total Findings:** XX
**Critical/High:** XX

### Remediation Actions

| Finding | Priority | Owner | Target Date | Status |
|---------|----------|-------|-------------|--------|
| SEC-001 | P1 | @security | YYYY-MM-DD | In Progress |
| SEC-002 | P2 | @platform | YYYY-MM-DD | Not Started |
| SEC-003 | P2 | @devops | YYYY-MM-DD | Not Started |

### Detailed Remediation

#### SEC-001: IAM Access Keys >90 Days

**Finding:** 3 IAM users have access keys older than 90 days
**Risk:** Credential compromise risk increases over time
**Remediation:**
1. Identify key usage patterns
2. Create rotation schedule
3. Rotate keys for each user
4. Update applications using keys
5. Disable old keys after verification

**Owner:** @security
**Target Date:** YYYY-MM-DD

Phase 6: Verification

Verification Checklist
  • Remediation implemented
  • Re-scan with same tools
  • Finding resolved in scan results
  • No regression introduced
  • Documentation updated
Closure Report Template
## Security Audit Closure Report

**Audit ID:** SEC-AUDIT-YYYY-NNN
**Audit Period:** YYYY-MM-DD to YYYY-MM-DD
**Closure Date:** YYYY-MM-DD

### Summary

| Metric | Count |
|--------|-------|
| Total findings | XX |
| Remediated | XX |
| Accepted risk | XX |
| Deferred | XX |

### Remediation Summary

| Priority | Found | Remediated | Accepted | Deferred |
|----------|-------|------------|----------|----------|
| P1 | X | X | 0 | 0 |
| P2 | X | X | X | 0 |
| P3 | X | X | X | X |
| P4 | X | X | X | X |

### Risk Acceptances

| Finding | Risk Description | Accepting Authority | Review Date |
|---------|------------------|---------------------|-------------|
| SEC-XXX | [description] | CISO | YYYY-MM-DD |

### Next Audit

**Scheduled:** YYYY-MM-DD
**Focus Areas:** [areas based on this audit]

Anti-Rationalization Table

Rationalization Why It's WRONG Required Action
"Internal service, security can be relaxed" Internal breaches are common Apply standards uniformly
"False positive, ignore it" All findings need verification Document evidence
"Too many findings to fix" Prioritize by severity Triage systematically
"Compliance is just checkbox" Compliance reflects real risk Treat as minimum bar
"Security slows us down" Breach slows you permanently Integrate security in process

Pressure Resistance

User Says Your Response
"Skip security review, deadline tomorrow" "Security review is mandatory. Cannot release with unreviewed changes. Scheduling expedited review."
"That's a false positive" "All findings require documented verification. Will assess with evidence."
"Accept all remaining risks" "Risk acceptance requires proper documentation and authority sign-off. Preparing risk acceptance forms."
"Legacy system, different rules" "Legacy systems are higher risk. Stricter standards apply."

Dispatch Specialist

For security audit tasks, dispatch:

Task tool:
  subagent_type: "ring:security-operations"
  model: "opus"
  prompt: |
    SECURITY AUDIT REQUEST
    Scope: [accounts, regions, services]
    Compliance Frameworks: [SOC2, PCI-DSS, etc.]
    Focus Areas: [IAM, network, data, etc.]
    Previous Findings: [reference if follow-up]

使用示例

查看来源仓库中的使用示例与配置说明。

查看来源 ↗

来源历史

收录时间
2026-01-20
索引更新时间
2026-02-04
Branch
main

收录与同步日期属于本站记录。源码修改历史请查看来源仓库。

GitHub ↗

chat Comments (0)

chat_bubble_outline

No comments yet. Be the first to share your thoughts!