ch015-redteam · git:20260504.c9430d0 · 2026-05-04 · sha256 e95ee909a652f268
ch015-redteam git:20260504.c9430d0C
Immutable. This exact content is served forever at /api/v1/blob/e95ee909a652f268.
# 인프라 설정 보안 리뷰 (Red Team Operations) Skill
> 인프라/네트워크/배포 레벨의 설정 파일과 IaC를 공격자 관점에서 분석하여
> MITRE ATT&CK 프레임워크에 매핑된 공격 경로를 식별합니다.
---
## 서비스 개요
| 항목 | 내용 |
|------|------|
| 서비스명 | 인프라 설정 보안 리뷰 (Red Team) |
| 방법론 | MITRE ATT&CK 매핑 + Kill Chain 관점 설정 분석 |
| 출력물 | 인프라 공격 표면 맵 + Kill Chain + 6-step 영향도 분석 + 수정 가이드 |
| 코드 수정 | ❌ 없음 (읽기 전용) |
| 외부 스캔 | ❌ 없음 (소스코드/설정 분석 기반) |
| 실제 인프라 접근 | ❌ 없음 (레포 내 파일만 분석) |
---
## 역할 범위와 한계
```yaml
Role_Scope:
정의: |
이 스킬은 "인프라 설정 보안 리뷰(Infrastructure Configuration Security Review)"이다.
실제 인프라에 접근하거나 네트워크 트래픽을 생성하지 않으며,
레포 내 설정 파일/IaC/CI/CD 파이프라인을 공격자 관점(Kill Chain)으로 분석한다.
수행_범위:
- "Dockerfile, docker-compose 등 컨테이너 설정 보안 분석"
- "GitHub Actions, GitLab CI 등 CI/CD 파이프라인 보안 분석"
- "Terraform, CloudFormation 등 IaC 보안 분석"
- "Kubernetes manifest, Helm chart 보안 분석"
- "시크릿 관리 아키텍처 분석 (Vault, SSM, SA binding 등)"
- "코드 내 인프라 클라이언트 호출에서 아키텍처 추론"
- "MITRE ATT&CK Kill Chain 관점 공격 경로 도출"
수행_불가:
- "실제 인프라(클라우드, 서버, 네트워크)에 접근 또는 스캔"
- "실행 중인 서비스에 HTTP 요청 또는 네트워크 패킷 전송"
- "운영 환경의 실시간 설정 값 확인"
- "실제 시크릿 유출 테스트 또는 크레덴셜 검증"
Pentest_차이:
설명: |
- Pentest: 실제 HTTP 요청으로 취약점을 라이브 검증 → FP 직접 제거
- Red Team: 설정 파일을 분석하여 인프라 수준 보상 제어를 확인 → FP 간접 제거
사용_시점: |
VA에서 Unverifiable_Infra로 분류된 보상 제어를 설정 파일에서 검증할 때.
Pentest로 검증할 수 없는 인프라 수준 설정(컨테이너 격리, CI/CD 시크릿 보호 등)이 대상.
FP_감소_기여:
직접: "설정에서 확인 가능한 보상 제어 검증 → Effective/Ineffective 판정"
간접: "Kill Chain 분석으로 복합 공격 경로 식별 → 숨겨진 True Positive 발견"
한계: "레포에 없는 설정(운영 환경 전용)은 검증 불가 → INCONCLUSIVE"
```
---
## 설계 원칙: 방법론 기반 + 공격 경로 중심
### 분석 원칙: 방법론, 패턴이 아님
```yaml
Principles:
No_Pattern_Lists: |
"특정 클라우드 서비스 문법, 설정 키, Dockerfile 명령어 목록에 의존하지 않는다.
이런 목록은 닫힌 집합이며, 목록에 없는 위험을 구조적으로 놓친다."
Use_Methodology: |
"행위(무엇이 일어나는가)를 질문하고, AI가 감지된 인프라 스택에 맞는
구체적 설정 패턴을 자율적으로 판단하여 탐색한다."
Kill_Chain_Thinking: |
"개별 설정 결함이 아닌 공격 경로(Kill Chain) 관점으로 분석.
'이 설정이 안전한가'가 아니라 '이 설정을 활용해 어디까지 도달할 수 있는가'를 질문."
Representative_Examples: |
"안티패턴/올바른 패턴은 '대표적 예시'로만 제시.
분석은 이 예시에 한정되지 않으며 — 동일한 구조적 이슈를 가진
모든 변형이 탐지되어야 한다."
```
---
## VA·Pentest·Red Team 비교
| 구분 | VA | Pentest | Red Team |
|------|-----|---------|----------|
| 관점 | 아키텍처 차원 리뷰 | 애플리케이션 공격자 | 인프라/조직 공격자 |
| 대상 | 소스코드 | 소스코드 + API | 설정 파일 + IaC + CI/CD |
| 방법론 | 8대 아키텍처 차원 | 시나리오 기반 공격 | MITRE ATT&CK 매핑 |
| 실행 환경 | 코드 읽기 전용 | 라이브 HTTP 요청 | 코드/설정 읽기 전용 |
| FP 감소 | Self-Verify로 1차 제거 | 라이브 검증으로 직접 제거 (핵심) | 설정 검증으로 간접 제거 |
| 출력 | 차원 건강도 + 6-step 분석 | POC + 라이브 검증 + 6-step | Kill Chain + 6-step 분석 |
---
## Phase 구조
```
Phase 0: Recon → 공통 정찰 (common/recon.md) + 인프라 정찰
Phase 0.5: Binding → 정찰 → 분석 컨텍스트 바인딩
Phase 1: Surface → 인프라/배포 공격 표면 식별
Phase 2: Attack Path → MITRE ATT&CK 기반 공격 경로 분석
Phase 3: Exploit → 익스플로잇 가능성 분석 + POC
Phase 4: Deep Analysis → 원칙 기반 심층 분석
Phase 4.5: Self-Verify → 분석 결과 자체 검증 (도달 가능성, 보상 제어)
Phase 4.6: VA Escalation → VA Unverifiable_Infra 보상 제어 설정 기반 검증 (해당 시)
Phase 5: Report → Kill Chain 다이어그램 + 6-step 영향도 분석 보고서
Phase 5R: Regulatory → 규제 영향 참조 (Finding 기반, 해당 시에만)
```
---
## Phase 0: 인프라 정찰 (Infrastructure Recon)
공통 정찰에 추가로 인프라/배포 관련 정보를 수집합니다.
```yaml
인프라_정찰:
컨테이너화:
methodology: |
컨테이너 설정 파일을 분석하여 보안 관련 설정을 식별:
- 베이스 이미지, 사용자 설정, 포트 노출, 볼륨 마운트
- 시크릿 파일 제외 여부 (.dockerignore)
IaC_설정:
methodology: |
인프라 코드를 분석하여 보안 설정을 식별:
- 클라우드 리소스 설정, 네트워크 정책, IAM 역할
- 배포 설정 (serverless, PaaS, container orchestration)
CI_CD:
methodology: |
CI/CD 파이프라인 설정을 분석:
- 시크릿 주입 방식, 환경 분리, 아티팩트 보안
- 제3자 Action/플러그인 보안
시크릿_관리:
methodology: |
시크릿 관리 아키텍처를 분석:
- .env 파일 존재 및 git 추적 여부
- 시크릿 매니저 사용 여부 및 연동 방식
- 환경별 분리
- 레포 내 설정 파일(config.toml, .env.example 등)이 샘플인지 실제인지 구분
시크릿_매니저_통합:
methodology: |
시크릿 매니저(Vault, AWS SSM, GCP Secret Manager 등) 연동이 감지되면
아래 항목을 추가 분석한다:
분석_항목:
인증_방식:
- "K8s Auth: SA 바운딩 → Vault Role 매핑 — SA annotation, Vault K8s auth config"
- "AppRole: Role ID/Secret ID 주입 경로 — CI/CD 환경변수 또는 파일"
- "Token: 정적 토큰 사용 여부 — 하드코딩, 환경변수, 파일"
- "AWS IAM Auth: EC2/ECS/Lambda 역할 기반 인증"
정책_범위:
- "Vault 정책 파일이 레포에 있으면 와일드카드(secret/*, kv/*) 사용 여부 확인"
- "서비스별 최소 권한 분리: 각 서비스가 자신의 시크릿만 접근하는가"
- "관리자 정책과 서비스 정책의 분리"
토큰_수명:
- "TTL/Max TTL 설정 — 코드 또는 설정에서 확인"
- "토큰 갱신 로직 존재 여부"
- "장기 유지 토큰(orphan token, periodic token) 사용 여부"
Vault_Agent_Sidecar:
- "Agent 설정의 시크릿 렌더링 경로 및 파일 권한"
- "캐시 활성화 시 캐시 파일 경로 및 보호"
- "auto-auth 설정의 sink 파일 보호"
EKS_Vault_패턴:
설명: "EKS + Vault K8s Auth는 가장 일반적인 패턴"
공격_경로:
- "SA 토큰 탈취 → Vault 인증 → 시크릿 접근 (TA0006)"
- "SA 바운딩 과도 → 다른 서비스의 Vault 시크릿 교차 접근 (TA0008)"
- "Vault Agent 캐시/렌더링 파일 → 컨테이너 내 평문 시크릿 잔류 (TA0006)"
- "CI/CD에서 Vault 토큰 로그 노출 → 인프라 전체 접근 (TA0001)"
레포_단서:
- "Go/Python/Node 코드에서 vault 클라이언트 초기화 패턴"
- "Helm chart의 serviceAccount annotation (vault.hashicorp.com/*)"
- "deployment YAML의 vault agent injector annotation"
- "CI/CD workflow의 hashicorp/vault-action 또는 vault CLI 호출"
레포_외부_인프라:
methodology: |
설정 파일이 레포에 없더라도, 코드 내 클라이언트 호출에서
인프라 아키텍처를 추론한다:
- Vault 클라이언트 초기화 → 시크릿 매니저 사용 확인
- K8s 클라이언트/SDK 호출 → EKS/GKE/AKS 사용 추론
- AWS/GCP SDK 호출 → 클라우드 서비스 사용 추론
- 이 경우 설정 파일 부재 자체를 Finding으로 보지 않으며,
코드에서 확인 가능한 범위만 분석한다.
네트워크:
methodology: |
네트워크 설정을 분석:
- 노출 포트, 서비스 간 통신, 외부 접근점
```
---
## Phase 1: 공격 표면 식별 (Attack Surface Mapping)
각 공격 표면 영역은 **방법론 기반**으로 분석됩니다.
아래 점검 항목은 대표 예시이며, AI가 감지된 인프라에 맞게 자율적으로 확장합니다.
### AS1. 컨테이너/런타임 보안
```yaml
Core_Questions:
- "컨테이너가 최소 권한 원칙을 따르는가?"
- "컨테이너 레이어에 민감 정보가 포함되는가?"
- "컨테이너 간 네트워크 격리가 적절한가?"
- "컨테이너 이스케이프의 전제조건(CAP, 커널 버전, 소켓 마운트)이 갖춰져 있는가?"
Representative_Items:
AS1-001: "컨테이너에서 root 사용자로 실행"
AS1-002: "베이스 이미지 버전 고정 미적용"
AS1-003: "불필요한 패키지/도구 설치"
AS1-004: "시크릿이 Docker 레이어에 포함"
AS1-005: "HEALTHCHECK 미설정"
AS1-006: "네트워크 격리 미설정"
AS1-007: "privileged 모드 또는 과도한 capabilities"
AS1-008: "호스트 경로 직접 마운트"
AS1-009: "docker.sock / containerd.sock / cri.sock 마운트"
AS1-010: "IMDSv1 허용 또는 hop-limit > 1 (컨테이너에서 IMDS 접근 가능)"
AS1-011: "automountServiceAccountToken: true + 광범위 RBAC (K8s)"
AS1-012: "hostPath: / 또는 /etc, /var/lib/kubelet 마운트"
AS1-013: "seccomp=Unconfined / AppArmor=unconfined"
AS1-014: "runc/containerd 취약 버전 (CVE-2024-21626, CVE-2019-5736)"
AS1-015: "커널 취약점 노출 (DirtyPipe 범위: 5.8 ≤ ver < 5.16.11)"
Escape_Precondition_Matrix:
# 각 이스케이프 프리미티브의 필요조건을 명시 — Finding 작성 시 모두 Observed 필수
cgroup_v1_release_agent:
requires: ["CAP_SYS_ADMIN", "cgroup v1 (no unified)", "Linux < 5.8 or fallback"]
dirtypipe_lpe:
requires: ["Linux 5.8 ≤ ver < 5.16.11 / 5.15.25 / 5.10.102"]
runc_leaky_handle:
requires: ["runc < 1.1.12"]
hostpath_root:
requires: ["hostPath: / mount"]
docker_sock:
requires: ["/var/run/docker.sock mount"]
Representative_Anti_Patterns:
- "root 사용자로 실행 → 컨테이너 탈출 시 호스트 접근"
- "시크릿이 Docker 빌드 레이어에 포함 → 이미지 접근자 전원에게 노출"
- "IMDSv1 + 애플리케이션 SSRF → IAM Role 탈취 (cloud-aws.md 참조)"
- "hostPath / 마운트 + 비root 컨테이너 → 여전히 /etc/shadow 읽기 가능"
- "CAP_SYS_ADMIN 부여된 비root 컨테이너 → cgroup release_agent 이스케이프"
Representative_Healthy_Patterns:
- "비root 사용자 + 최소 capabilities"
- "multi-stage 빌드 + 시크릿은 런타임 환경변수로 주입"
- "IMDSv2 강제 + hop-limit = 1"
- "automountServiceAccountToken: false"
- "seccomp RuntimeDefault + read-only rootfs"
Deep_Reference:
aws: knowledge-base/tier2-overlays/cloud-aws.md
k8s: knowledge-base/tier2-overlays/cloud-k8s.md
```
### AS2. CI/CD 파이프라인 보안
```yaml
Core_Questions:
- "CI/CD 파이프라인이 공급망 공격에 취약한가?"
- "시크릿이 빌드/배포 과정에서 안전하게 관리되는가?"
- "제3자 코드가 파이프라인에서 실행될 때 권한 범위가 적절한가?"
Representative_Items:
AS2-001: "CI/CD 시크릿 안전 주입 여부"
AS2-002: "제3자 Action/플러그인 핀 고정 (SHA 또는 특정 버전)"
AS2-003: "빌드 아티팩트에 시크릿 포함 여부"
AS2-004: "PR 기반 CI에서 write 권한 범위"
AS2-005: "Self-hosted runner 격리 수준"
AS2-006: "배포 파이프라인 환경 분리"
AS2-007: "아티팩트 서명/무결성 검증"
AS2-008: "CI/CD → Vault 연동 시 토큰 노출 여부 (로그, 환경변수 마스킹)"
AS2-009: "CI/CD → EKS 배포 시 kubeconfig/IAM 인증 방식"
Representative_Anti_Patterns:
- "제3자 Action이 SHA 고정 없이 최신 버전 사용 → 공급망 공격"
- "PR CI가 write 권한 → 악의적 PR로 코드 변경"
- "Vault 토큰이 CI 로그에 마스킹 없이 노출 → 인프라 전체 접근"
- "kubeconfig가 Actions secret에 평문 저장 → 클러스터 접근"
Representative_Healthy_Patterns:
- "모든 Action SHA 고정 + 정기 업데이트"
- "PR CI는 read-only, merge 후에만 배포"
- "Vault 토큰은 OIDC 또는 GitHub OIDC로 단기 발급"
- "EKS 배포는 IAM Roles for Service Accounts(IRSA)로 인증"
```
### AS3. 클라우드/IaC 보안
```yaml
Core_Questions:
- "클라우드 리소스가 최소 권한 원칙을 따르는가?"
- "데이터가 전송 중/저장 시 암호화되는가?"
- "외부 접근이 필요한 리소스만 공개되는가?"
Representative_Items:
AS3-001: "IAM 역할 최소 권한 원칙"
AS3-002: "Storage 버킷 공개 접근"
AS3-003: "Security Group/방화벽 규칙 (0.0.0.0/0 인바운드)"
AS3-004: "데이터베이스 공개 접근"
AS3-005: "암호화 at-rest / in-transit"
AS3-006: "로깅/모니터링 활성화"
AS3-007: "Terraform state 파일 보안"
AS3-008: "서버리스 함수 실행 시간/메모리 제한"
Representative_Anti_Patterns:
- "IAM 역할에 * 와일드카드 권한 → 전체 리소스 접근"
- "데이터베이스 공개 엔드포인트 → 직접 접근 가능"
Representative_Healthy_Patterns:
- "IAM 역할별 최소 필요 권한만 명시"
- "데이터베이스는 VPC 내부에서만 접근"
```
### AS4. Kubernetes 보안 (해당 시)
```yaml
Core_Questions:
- "클러스터 접근 제어가 최소 권한을 따르는가?"
- "Pod 간 네트워크 격리가 적절한가?"
- "시크릿이 안전하게 관리되는가?"
Representative_Items:
AS4-001: "RBAC 최소 권한 (ClusterRole vs Role)"
AS4-002: "NetworkPolicy 존재 및 격리 수준"
AS4-003: "PodSecurityPolicy/PodSecurityStandard"
AS4-004: "시크릿 암호화 (etcd encryption)"
AS4-005: "서비스 어카운트 토큰 자동 마운트 비활성화"
AS4-006: "이미지 풀 정책"
AS4-007: "리소스 Limits/Requests 설정"
```
### AS5. 의존성/공급망 보안
```yaml
Core_Questions:
- "의존성의 무결성이 보장되는가?"
- "알려진 취약점이 있는 의존성이 있는가?"
- "빌드 시 실행되는 스크립트가 안전한가?"
Representative_Items:
AS5-001: "lock 파일 무결성"
AS5-002: "알려진 CVE 의존성"
AS5-003: "의존성 미러/프록시 사용 여부"
AS5-004: "postinstall/pre-build 스크립트 점검"
AS5-005: "의존성 자동 업데이트 설정"
```
---
## Phase 2: MITRE ATT&CK 매핑 공격 경로 분석
발견된 공격 표면을 MITRE ATT&CK 전술(Tactic)에 매핑합니다.
```yaml
MITRE_ATT&CK_매핑:
TA0001_Initial_Access:
- "공개 API 엔드포인트를 통한 초기 접근"
- "CI/CD 파이프라인 타협"
- "공급망 공격 (의존성 변조)"
- "환경 변수/시크릿 유출"
TA0003_Persistence:
- "서비스 어카운트/API 키 장기 유지"
- "CI/CD 파이프라인에 백도어 주입"
- "Docker 이미지 변조"
TA0004_Privilege_Escalation:
- "IAM 역할 가정 (assume-role)"
- "Kubernetes RBAC 에스컬레이션"
- "컨테이너 탈출"
- "DB 특권 함수 실행"
TA0005_Defense_Evasion:
- "로깅 비활성화/우회"
- "감사 로그 변조"
- "CloudTrail 로그 S3 버킷 삭제 권한 오남용"
- "GuardDuty 비활성 region에서 활동 (탐지 사각지대)"
- "Falco/EDR 룰 예외 처리 악용"
- "컨테이너 ephemeral FS에 아티팩트 저장 후 재시작으로 삭제"
TA0006_Credential_Access:
- "하드코딩 시크릿 추출"
- "환경 변수에서 API 키 탈취"
- "Docker/CI 로그에서 시크릿 유출"
TA0007_Discovery:
- "내부 서비스 열거"
- "API 엔드포인트 열거"
TA0008_Lateral_Movement:
- "서비스 간 인증 토큰 재사용"
- "내부 네트워크 피봇"
TA0009_Collection:
- "DB 대량 데이터 추출"
- "Storage/S3 버킷 데이터 접근"
TA0010_Exfiltration:
- "외부 API를 통한 데이터 유출"
TA0040_Impact:
- "서비스 거부 (리소스 소진)"
- "데이터 파괴/변조"
```
### 공격 경로 구성
```yaml
공격_경로_분석:
1_진입점_식별: "MITRE TA0001 후보 중 실현 가능한 진입점"
2_수평_이동: "진입 후 TA0007/TA0008 기반 이동 경로"
3_권한_상승: "TA0004 기반 상위 권한 획득 경로"
4_목표_달성: "TA0009/TA0010/TA0040 기반 최종 영향"
5_Kill_Chain: "진입 → 이동 → 상승 → 달성 전체 경로 시각화"
```
---
## Phase 3: 익스플로잇 가능성 분석
```yaml
분석_기준:
실현_가능성:
HIGH: "공개적으로 접근 가능, 별도 인증 불요"
MEDIUM: "내부 접근 또는 기본 인증으로 접근 가능"
LOW: "다단계 공격 체인 필요, 시간/자원 소모"
THEORETICAL: "이론적으로 가능하나 현실적 장벽 큼"
영향도:
CRITICAL: "전체 시스템 타협, 데이터 전량 유출"
HIGH: "주요 서비스 장애, 대량 데이터 접근"
MEDIUM: "일부 서비스 영향, 제한적 데이터 접근"
LOW: "정보 노출, 설정 결함"
우선순위: "실현_가능성 × 영향도 매트릭스"
```
---
## Phase 4: 원칙 기반 심층 분석
```yaml
Security_Principles:
Least_Privilege: "모든 서비스/컨테이너/역할에 최소 권한만"
Defense_in_Depth: "인프라 레벨 다층 방어"
Zero_Trust: "내부 네트워크도 신뢰하지 않는 아키텍처"
Free_Exploration:
- "인프라 설정 간 상호작용으로 발생하는 보안 갭"
- "배포 환경 특성으로 인한 보안 메커니즘 무력화"
- "멀티 클라우드/하이브리드 환경의 보안 경계 이슈"
```
---
## Root Cause Classification (근본 원인 분류)
```yaml
Root_Cause_Types:
ARCHITECTURE:
description: "인프라 아키텍처 설계 자체의 문제"
examples: "네트워크 격리 설계 미비, Zero Trust 미적용"
CONFIGURATION:
description: "설정 누락 또는 과도한 설정"
examples: "Security Group 과도 허용, RBAC 미설정"
CODE:
description: "IaC/CI 코드의 보안 결함"
examples: "Terraform에 하드코딩 시크릿, Dockerfile root 사용"
PROCESS:
description: "인프라 운영 프로세스 부재"
examples: "시크릿 로테이션 미수행, 설정 변경 리뷰 미실시"
```
## Phase 4.5: 분석 결과 자체 검증 (Self-Verification)
```yaml
Self_Verification:
목적: |
인프라 Finding의 오탐(과대 평가)을 최소화한다.
각 Finding에 대해 아래 2단계를 실행한다.
Step_1_도달_가능성_검증:
설명: "취약 설정이 실제 공격 경로에서 도달 가능한가?"
절차:
- "해당 설정이 프로덕션에 적용되는지 확인 (환경별 분기)"
- "해당 리소스가 외부에서 접근 가능한지 네트워크 설정 확인"
- "도달 불가능하면 Feasibility를 THEORETICAL로 재평가"
Step_2_보상_제어_확인:
설명: "다른 레이어에서 동일 위협을 차단하는 보상 제어가 있는가?"
프로토콜: "common/compensating-control.md의 4단계 프로토콜을 실행한다."
예시:
- "Security Group이 과도하지만 VPC 내부에서만 접근 가능"
- "컨테이너가 root이지만 read-only 파일시스템 + no-new-privileges"
원칙:
- "보상 제어의 존재 ≠ 위협 차단 — 유효성이 설정에서 입증되어야 한다"
- "Effective 판정 외에는 원래 심각도를 유지한다"
적용_우선순위: "모든 Finding에 Step 1~2 필수"
```
---
## Phase 4.6: VA 에스컬레이션 인프라 검증 (VA Escalation Infrastructure Verify)
> VA에서 Unverifiable_Infra (verification_target: REDTEAM)로 분류된 보상 제어를
> 설정 파일/IaC/컨테이너 설정에서 검증하여 VA Finding의 심각도를 재조정합니다.
```yaml
VA_Escalation_Verify:
조건: |
offsec-lead로부터 Pending_Verification.REDTEAM 목록을 수신한 경우에만 실행.
CISO 지시에 Red Team이 포함되어 있어야 한다.
목적: |
VA 코드 분석에서 "인프라 레벨이라 확인 불가"로 판정된 보상 제어를
설정 파일/IaC/Dockerfile 등에서 실제 적용 여부를 검증하여 FP를 줄인다.
Red Team의 인프라 분석 역량(AS1-AS5)을 활용한다.
입력: |
Pending_Verification.REDTEAM 목록:
- finding_id, control, expected_test
검증_절차:
Step_1_설정_파일_탐색: |
VA가 전달한 보상 제어 유형에 따라 관련 설정 파일을 탐색한다:
- 네트워크 격리 → docker-compose.yml 네트워크 설정, K8s NetworkPolicy, Terraform Security Group
- 컨테이너 보안 → Dockerfile (USER, capabilities), compose (security_opt, read_only)
- TEE/Enclave → enclave 설정 파일, VSOCK 설정
- 시크릿 관리 → CI/CD 설정, .env 추적 여부, 시크릿 매니저 연동
- 볼륨 접근 제어 → compose volumes (read-only 플래그), K8s PVC 설정
- Vault 시크릿 주입 → Vault Agent annotation, SA 바운딩, 코드 내 Vault 클라이언트 호출
주의: 레포 내 config 파일(config.toml, .env.example 등)이 샘플 데이터인 경우,
실제 시크릿 주입 경로(Vault, SSM 등)를 코드에서 추적하여 판단한다.
샘플 데이터를 실제 시크릿 노출로 오판하지 않는다.
Step_2_유효성_검증: |
compensating-control.md의 5개 질문을 설정 파일 기반으로 실행한다:
- 범위: 이 보상 제어가 해당 서비스/컨테이너에 실제 적용되는가?
- 정밀도: 이 설정이 해당 위협 벡터를 차단하는가?
- 우회가능성: 설정 자체를 우회할 경로가 있는가?
- 완전성: 모든 관련 서비스/컨테이너에 일관 적용되는가?
- 독립성: 원본 취약점과 같은 설정 누락을 공유하지 않는가?
Step_3_Kill_Chain_연계: |
보상 제어가 유효한 경우, 기존 Red Team Kill Chain에서
해당 보상 제어가 차단하는 단계를 표시한다.
Kill Chain이 완성되지 않으면 실현 가능성을 THEORETICAL로 하향.
판정:
Effective:
조건: "5개 질문 모두 설정에서 확인 + 증거 Observed"
영향: "VA Finding 심각도 1단계 하향 근거"
기록: "보상 제어를 Unverifiable → Effective로 재분류"
Partial:
조건: "일부 질문 통과 + 나머지 설정에서 미확인"
영향: "심각도 유지 (보수적)"
기록: "보상 제어를 Unverifiable → Partial로 재분류 + 미확인 항목 명시"
Ineffective:
조건: "설정에서 보상 제어가 미적용 또는 우회 가능 확인"
영향: "심각도 유지"
기록: "보상 제어를 Unverifiable → Ineffective로 재분류"
Unverifiable_External:
조건: "설정 파일에서도 확인 불가 — 클라우드 콘솔/물리 환경만 가능"
영향: "심각도 유지, Unverifiable_External로 재분류"
기록: "운영 환경 직접 확인 필요로 최종 보고서에 기록"
결과_기록: |
VA Finding 원본의 Compensating_Controls 레코드를 업데이트:
- coverage: Unverifiable → Effective/Partial/Ineffective/Unverifiable_External
- verification_target: REDTEAM → REDTEAM_VERIFIED
- infra_evidence: "[설정 파일 경로:라인 + 설정 내용]"
결과_출력: |
검증 결과를 구조화하여 기록:
┌────────────────────────────────────────────────────────────┐
│ INFRA VERIFICATION RESULT │
├──────────────┬─────────────────────────────────────────────┤
│ VA Finding │ F-XXX │
│ 보상 제어 │ [보상 제어 설명] │
│ 검증 대상 │ [설정 파일 경로] │
│ 5개 질문 결과 │ 범위/정밀도/우회/완전성/독립성 │
│ 최종 판정 │ Effective / Partial / Ineffective / External │
│ 심각도 조정 │ 변경 없음 / 변경 사유 │
└──────────────┴─────────────────────────────────────────────┘
```
---
## Phase 5R: 규제 영향 참조 (Regulatory Impact Reference)
```yaml
Module: "../va/regulatory.md"
Trigger: |
Phase 1~5에서 발견된 Finding 중 규제 관련성이 있는 것이 1건 이상인 경우에만 실행.
규제 관련 Finding이 0건이면 생략한다.
Scope: |
인프라/배포 레벨 취약점 중 규제 관련성이 있는 것을 국내외 법률·규제 조항에 매핑.
특히 CI/CD 통제 부재(ISMS-P 2.9.1), 키 관리 구조(가상자산이용자보호법),
접근 통제(개인정보보호법 제29조) 등이 해당될 수 있다.
상세 프로토콜, 규제 카탈로그, 출력 형식은 모듈 파일 참조.
Key_Principles:
- "법률명 + 조항 번호를 반드시 명시 (모호한 언급 금지)"
- "적용 관할(🇰🇷/🇪🇺/🇺🇸/🌐)을 명시"
- "위반 단정 금지 — '저촉 가능성 있으므로 법무 검토 권장'으로 기술"
- "기술적 심각도를 규제 이유로 변경하지 않음"
```
---
## Finding Structure (6-step 영향도 분석)
모든 발견 사항은 6-step 구조를 따릅니다.
> **ID 명명 규칙**: `knowledge-base/conventions/finding-id-naming.md` 참조 (AS{N}-{NNN} Red Team 전용 + 통합 규칙)
```yaml
Finding_Structure:
F-XXX: "[인프라 이슈 이름]"
Metadata:
Attack_Surface: "AS1~AS5"
MITRE_Tactic: "TA0001~TA0040"
Severity: "CRITICAL / HIGH / MEDIUM / LOW"
Feasibility: "HIGH / MEDIUM / LOW / THEORETICAL"
Location: "파일, 설정"
Root_Cause: "ARCHITECTURE / CONFIGURATION / CODE / PROCESS"
Reference:
CWE: "CWE-NNN (필수 — 가장 정확한 CWE ID. 복수 해당 시 쉼표 구분)"
MITRE_ATT&CK: "TXXXX (필수 — Tactic + Technique ID)"
OWASP_Top10: "A01~A10 (해당 시)"
Note: "CWE/MITRE는 보고서 완전성을 위한 필수 매핑"
Structural_Issue_Description: "구조적 원인 설명"
Evidence: "설정 파일 참조"
Kill_Chain_Impact: "이 발견이 Kill Chain에서 차지하는 위치"
Fix_Recommendation_and_Impact_Analysis:
1_Change_Target: "수정 대상 설정과 방향"
2_Reference_Tracing: "이 설정에 의존하는 모든 서비스/컴포넌트"
3_Impact_Scope: "직접/간접 영향"
4_Side_Effect_Risks: "설정 변경으로 서비스 중단 위험"
5_Co_Requisite_Changes: "동시 변경 항목 (네트워크/IAM/시크릿)"
6_Post_Fix_Verification: "설정 변경 후 검증 항목"
```
---
## Phase 6: Detection Engineering Signals (P3-2 Purple Team 산출물)
> Red Team 산출물에 **Detection Signals 섹션을 필수 포함**한다.
> 목적: SOC/Detection Engineer가 이 공격이 실행되었을 때 어떤 로그·시그니처가
> 남는지, 현재 SIEM/EDR 룰로 탐지 가능한지, 탐지 갭을 어떻게 메울지 알 수 있도록 한다.
### Detection_Signals_Schema
```yaml
Finding_Detection_Appendix:
# 각 Kill Chain / Finding 엔트리에 추가로 부가되는 섹션
attack_artifacts:
- type: "process_exec | file_write | network_conn | api_call | auth_event"
detail: "구체적 아티팩트 예시 (예: /usr/bin/runc -v 실행)"
host_visibility: "kernel | user | none"
log_sources:
- "CloudTrail: <eventName>, <resource>"
- "Kubernetes audit log: <verb>, <resource>, <subject>"
- "EDR/Falco: <rule_name>"
- "WAF access log: <pattern>"
- "application audit: <event>"
detection_queries:
splunk: |
index=cloudtrail eventName=AssumeRole userIdentity.type=AssumedRole ...
elastic: |
event.dataset:aws.cloudtrail AND event.action:AssumeRole AND ...
sigma_rule_id: "proc_creation_lnx_susp_runc_override"
known_edr_coverage:
- vendor: "Falco"
rule: "Mount Launched in Privileged Container"
coverage: "Effective | Partial | None"
- vendor: "Datadog Cloud Workload Security"
coverage: "Partial — hostpath mount detection but not follow-on exploit"
evasion_considerations:
# 공격자 관점 — 어떻게 하면 위 탐지를 회피할 수 있는가?
# 목적은 evasion 가이드가 아니라 SOC가 회피 시도도 탐지할 수 있게 신호 설계.
- "로그 소스 자체를 비활성화하는 사전 액션 (GuardDuty disable)"
- "로그 export 후 S3 삭제"
- "공격을 GuardDuty 비활성 region에서 수행"
soc_action_recommendations:
- "AssumeRole 이벤트 중 cross-account + unusual source IP 알람"
- "GuardDuty 비활성/삭제 이벤트에 즉시 페이지"
- "runc 실행 자체를 컨테이너 내부에서 차단 (seccomp)"
detection_gap:
# 현재 조직이 보유한 검출 스택으로 탐지 불가능한 단계
- stage: "Initial Access via SSRF"
gap: "WAF에서 169.254.169.254 블록은 하되 DNS rebinding은 미탐"
recommendation: "DNS resolve 결과 로깅 + private IP egress 모니터링"
```
### Purple Team 보고서 템플릿 적용 규칙
```yaml
Report_Template_Rule:
- "06b_redteam_result.md의 각 Kill Chain 항목에 'Detection Signals' 하위섹션 필수"
- "Finding별 SOC Action Recommendations를 Jira 'detection-eng' 라벨로 티켓 생성 가능한 형태로 명시"
- "기존 탐지로 커버되지 않는 단계(detection_gap)는 HIGH 우선순위로 별도 목록화"
```
### Evasion Framing Discipline
```yaml
Ethical_Framing:
rule: |
evasion_considerations 섹션은 공격 기법 전수 목적이 아니라
SOC가 '회피 시도까지 탐지'할 수 있도록 하기 위함이다.
구체적 회피 도구 이름이나 bypass payload는 기재하지 않는다.
대신 "로그 소스 X의 비활성화" 같은 추상 수준으로 기술한다.
```