kevinlupera/aws-incident-response-security-ecuador-demo

# 🔐 aws-incident-response 无服务器管道，当 GuardDuty 发现高严重性威胁时自动检测、隔离并通知——无需人工干预。 ## 架构图 ``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ Pipeline de Respuesta Automática │ │ │ │ ┌────────────┐ ┌──────────────┐ ┌─────────────────────────────┐ │ │ │ │ │ │ │ EventBridge Rule │ │ │ │ GuardDuty │────▶│ Security Hub │────▶│ severity >= 7 (HIGH/CRIT) │ │ │ │ │ │ ASFF │ │ source: aws.guardduty │ │ │ └────────────┘ └──────────────┘ └──────────────┬──────────────┘ │ │ │ │ │ ▼ │ │ ┌───────────────────────┐ │ │ │ Lambda: isolate- │ │ │ │ resource (Node 22) │ │ │ └─────────┬─────────────┘ │ │ │ │ │ ┌─────────────────────────┼────────────────┐ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌──────────────────┐ ┌────────────────────┐ ┌───────┐ │ │ │ EC2 Instance │ │ IAM AccessKey │ │ SNS │ │ │ │ → SG Cuarentena│ │ → Policy DenyAll │ │ Email │ │ │ │ (sin reglas) │ │ (usuario aislado) │ │ Alert │ │ │ └──────────────────┘ └────────────────────┘ └───────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────────────────┐ │ │ │ CloudTrail → S3 (RETAIN + Glacier 365d) + CloudWatch Logs (1 año) │ │ │ └─────────────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` ## 使用的 AWS 服务 | 服务 | 功能 | Stack CDK | |------------------------|------------------------------------------------------|--------------------| | Amazon GuardDuty | 使用 ML + 威胁情报进行威胁检测 | `GuardDutyStack` | | AWS CloudTrail | 多区域 API 调用审计 | `CloudTrailStack` | | AWS Security Hub | 查找结果的聚合与标准化 (ASFF) | `SecurityHubStack` | | Amazon SNS | 通过电子邮件向安全团队发送通知 | `NotificationStack`| | Amazon EventBridge | 按严重性 (>= 7) 路由事件 | `ResponseStack` | | AWS Lambda | 自动隔离受感染的资源 | `ResponseStack` | | Amazon EC2 (SG) | 不含任何规则的隔离安全组 | Lambda | | AWS IAM | 针对已泄露 Access Keys 的 DenyAll 策略 | Lambda | | Amazon S3 | CloudTrail 日志存储 (RETAIN 永久保留) | `CloudTrailStack` | | Amazon CloudWatch Logs | CloudTrail 和 Lambda 的实时日志 | 两个 stacks | ## 仓库结构 ``` aws-incident-response/ ├── bin/ │ └── app.ts # Punto de entrada CDK — instancia todos los stacks ├── lib/ │ ├── config.ts # ⚙️ Configuración central (email, región, severidad) │ ├── guardduty-stack.ts # Stack: detector + protecciones S3/EKS/Malware │ ├── cloudtrail-stack.ts # Stack: trail multi-región + S3 + CloudWatch │ ├── securityhub-stack.ts # Stack: Security Hub + estándar FSBP │ ├── notification-stack.ts # Stack: SNS topic + suscripción email │ └── response-stack.ts # Stack: EventBridge + Lambda + IAM Role ├── lambdas/ │ └── isolate-resource/ │ └── index.ts # Lambda handler — aislamiento EC2/IAM + SNS ├── scripts/ │ └── simulate.sh # Script de simulación con GuardDuty sample findings ├── package.json ├── tsconfig.json ├── cdk.json └── README.md ``` ## 配置前置条件 ### 1. 配置告警电子邮件 编辑 `lib/config.ts` 并更改电子邮件： ``` alertEmail: 'tu-email-real@example.com', // ← Cambia esto ``` ### 2. (可选) 调整区域 ``` region: 'us-east-1', // Cambia si prefieres otra región ``` ### 3. (可选) 调整隔离的最小严重性 ``` minSeverityToIsolate: 7, // 7 = HIGH, 9 = solo CRITICAL ``` ### 4. 验证 AWS 前置条件 ``` # 验证 AWS 活跃凭证 aws sts get-caller-identity # 验证 CDK 是否已安装 cdk --version # 如果是首次在此账户/区域使用 CDK： cdk bootstrap ``` ## 部署命令 ### 步骤 1 — 安装依赖 ``` npm install ``` ### 步骤 2 — 编译 TypeScript ``` npm run build ``` ### 步骤 3 — 部署所有基础设施 ``` cdk deploy --all --require-approval never ``` ## 如何运行模拟 ``` # 授予执行权限（仅第一次） chmod +x scripts/simulate.sh # 运行模拟 ./scripts/simulate.sh ``` 该脚本会自动： 1. 检测 GuardDuty 探测器 ID 2. 创建一个类型为 `UnauthorizedAccess:IAMUser/MaliciousIPCaller` 的示例查找结果 3. 显示需要观察的内容以及预计的传播时间 4. 打印用于实时监控管道的有用命令 ### 预计传播时间 | 阶段 | 服务 | 预计时间 | |------------------|--------------------|----------------| | 查找结果已创建 | GuardDuty | 立即 | | 标准化 | Security Hub | 1–2 分钟 | | 规则触发 | EventBridge | 2–3 分钟 | | Lambda 执行 | Lambda + CloudWatch| 3–5 分钟 | | 收到电子邮件 | SNS | 5–7 分钟 | ## Teardown (删除资源) ``` # 删除所有 stacks（通过 RETAIN 保留的 CloudTrail S3 bucket 除外） cdk destroy --all # 要手动删除 S3 bucket（包含审计日志）： # 前往 AWS 控制台 → S3 → 清空 bucket → 删除 bucket ``` ## GuardDuty 严重性表 | 级别 | 范围 | 颜色 | 是否触发管道？ | 威胁示例 | |----------|------------|--------|----------------|-----------------------------------------------| | LOW | 1.0 – 3.9 | 🟢 | 否 | 来自已知 IP 的端口扫描 | | MEDIUM | 4.0 – 6.9 | 🟡 | 否 | 来自匿名 IP 的 S3 访问 | | HIGH | 7.0 – 8.9 | 🔴 | **是** (默认) | 来自已知恶意 IP 的 API 调用 | | CRITICAL | 9.0 – 10.0 | 🚨 | **是** | 凭证的主动外泄 | 触发管道的最小严重性在 `lib/config.ts` 中配置。 ## 演示说明 - GuardDuty 的 **sample findings** 是合成查找结果——并不代表你账户中的真实威胁 - 自动隔离仅用于**演示**——在生产环境中，对于高严重性事件应实施人工审批 - 对于生产环境，建议启用 **GuardDuty Multi-Account** 和 **Security Hub Organizations** - 设置为 `RETAIN` 的 CloudTrail 日志可确保即使在执行 `cdk destroy` 后取证证据仍然保留 *为演讲 "Nadie Apretó un Botón: Respuesta Automática a Incidentes con AWS Nativo" 生成* *AWS Security Community Ecuador*

标签：AMSI绕过, ASFF, AWS, DevSecOps, DPI, EventBridge, GNU通用公共许可证, GuardDuty, Lambda, Node.js, Security Hub, Serverless, 上游代理, 威胁检测, 安全运营, 扫描框架, 无服务器, 网络调试, 自动化, 自动化攻击, 资源隔离, 通知, 高严重性