# Gestão de Cenários e Entidades (Asset-Oriented)

### **📋 ÍNDICE**

1. Fundamento e Filosofia
2. Modelo de Gestão por Entidades
3. Arquitetura de Diretórios
4. Classificação de Entidades
5. Gestão de Timeline Distribuída
6. Automação e Ferramentas
7. Workflow de Operação
8. Checklist de Gestão de Cenários

***

### 🎯 **1. FUNDAMENTO E FILOSOFIA**

#### **1.1 O Problema dos Ambientes Complexos**

```yaml
O CENÁRIO REAL:
  Um cliente possui:
    - Site principal (exemplo.com)
    - API de produção (api.exemplo.com)
    - Portal de vendas (vendas.exemplo.com)
    - Ambiente de homologação (homol.exemplo.com)
    - 12 microserviços (auth, billing, inventory, etc.)
    - 3 buckets S3 com configurações diferentes
    - Infraestrutura de Kubernetes com 15 serviços

O CAOS RESULTANTE:
  - Logs do Nmap misturam 20 IPs diferentes
  - Payload do SQL injection do site é diferente da API
  - Screenshots do portal de vendas se perdem com os do admin
  - Relatório final vira uma salada de informações
  - Você não sabe mais O QUE está testando e ONDE

A CAUSA RAIZ:
  A estrutura linear (um projeto, uma timeline) falha quando o escopo é complexo.
  Você precisa de uma estrutura CENTRADA EM ATIVOS (Asset-Centric).
```

#### **1.2 O que é Gestão por Entidades?**

```yaml
DEFINIÇÃO:
  A Gestão por Entidades é uma estrutura recursiva onde cada ativo
  (subdomínio, IP, API, serviço) possui sua própria hierarquia de pastas isolada.

ANALOGIA:
  É como um HOSPITAL com múltiplos prontuários.
  Cada paciente (entidade) tem seu próprio prontuário.
  O hospital (projeto) tem uma visão geral, mas cada caso é tratado individualmente.

DIFERENÇA CRÍTICA:
  Estrutura Linear (um bloco):
    - Uma pasta 01_RECON para TUDO
    - Logs de 20 ativos misturados
    - Timeline única para todo o projeto
    - ❌ Não escala para ambientes complexos

  Estrutura por Entidades (múltiplos blocos):
    - Uma pasta ASSETS com subpastas por ativo
    - Cada ativo tem seu próprio 01_RECON
    - Timeline LOCAL por ativo + MASTER global
    - ✅ Escala para qualquer complexidade
```

#### **1.3 Quando Usar Gestão por Entidades?**

```yaml
✅ QUANDO USAR (MANDATÓRIO):

  MÚLTIPLOS SUBDOMÍNIOS:
    - Mais de 5 subdomínios distintos
    - Cada um com tecnologia/framework diferente

  MÚLTIPLOS AMBIENTES:
    - Produção vs Homologação vs Desenvolvimento
    - Cada ambiente tem regras diferentes

  EQUIPES PARALELAS:
    - Mais de um analista no mesmo projeto
    - Cada um focado em ativos diferentes

  TESTES DE LONGA DURAÇÃO:
    - Projetos com mais de 1 semana
    - Risco de perda de contexto

❌ NÃO USAR (QUANDO SIMPLES BASTA):

  Escopo pequeno:
    - 1-3 subdomínios (site pequeno ~20 paginas no máximo)
    - Tecnologias homogêneas
    - 1 analista
    - Projeto de curta duração (< 3 dias)
```

***

### 🏛️ **2. MODELO DE GESTÃO POR ENTIDADES**

#### **2.1 Conceitos Fundamentais**

```yaml
ENTIDADE (ASSET):
  É o menor objeto de teste rastreável.
  Exemplos: subdominio.com, 10.0.0.1, API endpoint, bucket S3.

ESCOPO (SCOPE):
  Conjunto de entidades que compartilham um objetivo ou tecnologia.
  Exemplos: "APIs de produção", "Front-end marketing", "Infraestrutura legada"

CENÁRIO (SCENARIO):
  Agrupamento lógico de escopos para um objetivo de teste específico.
  Exemplo: "Comprometimento de dados de usuário" (envolve API + Front-end + Banco)

PROJETO (PROJECT):
  Contêiner de todos os cenários para um engajamento específico.
```

#### **2.2 Hierarquia de Organização**

```mermaid
graph TD
    A[PROJETO] --> B[CENÁRIO 1]
    A --> C[CENÁRIO 2]
    A --> D[CENÁRIO 3]
    
    B --> E[ESCOPO 1.1]
    B --> F[ESCOPO 1.2]
    
    E --> G[ENTIDADE 1.1.1]
    E --> H[ENTIDADE 1.1.2]
    
```

#### **2.3 Exemplo Prático de Hierarquia**

```yaml
PROJETO: TechCorp_2024-06
  │
  ├── CENÁRIO: "Comprometimento de Dados de Cliente"
  │   │
  │   ├── ESCOPO: "Aplicação Web Principal"
  │   │   ├── ENTIDADE: www.techcorp.com
  │   │   ├── ENTIDADE: shop.techcorp.com
  │   │   └── ENTIDADE: login.techcorp.com
  │   │
  │   └── ESCOPO: "API de Autenticação"
  │       ├── ENTIDADE: auth.techcorp.com
  │       └── ENTIDADE: sso.techcorp.com
  │
  └── CENÁRIO: "Movimentação Lateral na Infraestrutura"
      │
      ├── ESCOPO: "Rede Interna"
      │   ├── ENTIDADE: 10.10.10.0/24
      │   └── ENTIDADE: 10.10.11.0/24
      │
      └── ESCOPO: "Serviços de Banco de Dados"
          ├── ENTIDADE: db-master.techcorp.com
          └── ENTIDADE: db-slave.techcorp.com
```

***

### 📂 **3. ARQUITETURA DE DIRETÓRIOS**

#### **3.1 Estrutura Hierárquica para Ambientes Complexos**

```
[YYYY-MM-DD]_[CLIENTE]_[PROJETO]/
│
├── 00_GLOBAL/                          # Artefatos do projeto (não por ativo)
│   ├── scope.md                        # Escopo final aprovado
│   ├── credentials.env.enc             # Credenciais criptografadas
│   ├── contacts.md                     # Contatos do cliente
│   └── meeting_notes/                  # Notas de reuniões
│
├── ASSETS/                             # Contêiner de entidades
│   │
│   ├── entity_001_www_techcorp/
│   │   ├── 01_RECON/
│   │   │   ├── passive/
│   │   │   └── active/
│   │   ├── 02_ENUMERATION/
│   │   ├── 03_EXPLOITATION/
│   │   ├── 04_EVIDENCE/
│   │   ├── 05_REPORTING/
│   │   ├── timeline.md                 # Timeline LOCAL do ativo
│   │   └── manifest.yaml               # Metadados do ativo
│   │
│   ├── entity_002_shop_techcorp/
│   │   └── ... (mesma estrutura)
│   │
│   ├── entity_003_api_auth/
│   │   └── ... (mesma estrutura)
│   │
│   └── entity_004_network_10-10-10-0/
│       └── ... (mesma estrutura)
│
├── SCENARIOS/                          # Agrupamentos lógicos (opcional)
│   ├── scenario_01_data_breach/
│   │   ├── manifest.yaml               # Entidades associadas
│   │   └── notes.md                    # Anotações do cenário
│   │
│   └── scenario_02_lateral_movement/
│       └── ...
│
├── MASTER_TIMELINE.md                  # Timeline GLOBAL (milestones)
├── MASTER_DASHBOARD.md                 # Visão geral do projeto
├── README.md                           # Mapeamento de entidades
└── .gitignore
```

#### **3.2 Manifesto de Entidade (manifest.yaml)**

```yaml
# ASSETS/entity_001_www_techcorp/manifest.yaml

entity:
  name: "www.techcorp.com"
  type: "web_application"           # web_application, api, network, cloud, mobile
  priority: "CRITICAL"               # CRITICAL, HIGH, MEDIUM, LOW
  status: "IN_PROGRESS"              # PENDING, IN_PROGRESS, COMPLETED, BLOCKED
  lead_analyst: "João Silva"
  
discovery:
  source: "nmap_scan_2024-06-10"
  ip: "192.168.1.100"
  ports: [80, 443]
  technologies: ["Apache 2.4.49", "PHP 7.4", "MySQL 5.7"]
  
classification:
  scenario: "data_breach"
  scope: "web_application_main"
  dependencies: ["auth.techcorp.com", "db-master.techcorp.com"]
  
findings:
  - id: "VULN-001"
    title: "CVE-2021-41773 - Apache Path Traversal"
    severity: "HIGH"
    status: "CONFIRMED"
    date: "2024-06-10"
    
  - id: "VULN-002"
    title: "SQL Injection em /search"
    severity: "CRITICAL"
    status: "EXPLOITED"
    date: "2024-06-11"

timeline:
  last_update: "2024-06-11 15:30"
  total_hours: 12.5
  events_count: 23

artifacts:
  screenshots: 15
  logs: 8
  payloads: 4
```

#### **3.3 Manifesto de Cenário (manifest.yaml)**

```yaml
# SCENARIOS/scenario_01_data_breach/manifest.yaml

scenario:
  name: "Comprometimento de Dados de Cliente"
  objective: "Validar se é possível acessar dados sensíveis de clientes"
  status: "IN_PROGRESS"
  priority: "CRITICAL"
  
assets_in_scope:
  - entity_001_www_techcorp
  - entity_002_shop_techcorp
  - entity_003_api_auth
  - entity_008_database_master
  
attack_paths:
  - path: "Web → SQLi → Database"
    status: "CONFIRMED"
    evidence: "04_EVIDENCE/sqli_poc.png"
    
  - path: "API → Auth Bypass → Admin Access"
    status: "PENDING"
    
findings_summary:
  total: 8
  critical: 2
  high: 3
  medium: 2
  low: 1

recommendations:
  - "Aplicar patch CVE-2021-41773 em www.techcorp.com"
  - "Implementar prepared statements no endpoint /search"
  - "Revisar política de CORS na API de autenticação"
```

***

### 📊 **4. CLASSIFICAÇÃO DE ENTIDADES**

#### **4.1 Matriz de Priorização**

| Critério                       | CRITICAL     | HIGH       | MEDIUM    | LOW   |
| ------------------------------ | ------------ | ---------- | --------- | ----- |
| **Dados sensíveis**            | Sim          | Parcial    | Não       | N/A   |
| **Acesso externo**             | Sim          | Sim        | Parcial   | Não   |
| **Ponto de entrada**           | Primário     | Secundário | Terciário | N/A   |
| **Impacto de comprometimento** | Catastrófico | Alto       | Médio     | Baixo |
| **Tempo estimado de teste**    | 8h+          | 4-8h       | 2-4h      | <2h   |

#### **4.2 Tipos de Entidade**

```yaml
WEB_APPLICATION:
  - Tecnologias: PHP, ASP.NET, Node.js, Ruby on Rails
  - Ferramentas típicas: Burp Suite, OWASP ZAP, Nikto
  - Exemplo: www.exemplo.com, admin.exemplo.com

API:
  - Tecnologias: REST, GraphQL, SOAP
  - Ferramentas típicas: Postman, Insomnia, custom scripts
  - Exemplo: api.exemplo.com, graphql.exemplo.com

NETWORK:
  - Tecnologias: Routers, Switches, Firewalls
  - Ferramentas típicas: Nmap, masscan, custom scanners
  - Exemplo: 10.0.0.0/24, 192.168.1.1

CLOUD:
  - Tecnologias: AWS S3, EC2, Lambda; Azure Blob; GCP Buckets
  - Ferramentas típicas: CloudEnum, ScoutSuite, custom scripts
  - Exemplo: bucket-name.s3.amazonaws.com

MOBILE:
  - Tecnologias: iOS, Android APK/IPA
  - Ferramentas típicas: MobSF, Frida, Objection
  - Exemplo: com.exemplo.app

DATABASE:
  - Tecnologias: MySQL, PostgreSQL, MongoDB, Redis
  - Ferramentas típicas: SQLmap, Redis CLI, MongoDB Compass
  - Exemplo: db-master.exemplo.com:3306
```

#### **4.3 Tags e Filtros para Organização**

```yaml
TAGS RECOMENDADAS:

  POR AMBIENTE:
    #prod, #homol, #dev, #staging

  POR TECNOLOGIA:
    #apache, #nginx, #wordpress, #react, #java, #python

  POR CRITICIDADE:
    #crown-jewel, #pci, #pii, #phi, #hipaa

  POR STATUS:
    #tested, #pending, #blocked, #retest

  POR DESCOBERTA:
    #sqli, #xss, #idor, #rce, #auth-bypass

EXEMPLO DE USO NO manifest.yaml:
  tags:
    - "#prod"
    - "#apache"
    - "#crown-jewel"
    - "#pending"
```

***

### ⏳ **5. GESTÃO DE TIMELINE DISTRIBUÍDA**

#### **5.1 Estratégia de Dois Níveis**

```yaml
TIMELINE LOCAL (Por Ativo):
  Localização: ASSETS/entity_XXX/timeline.md
  Conteúdo: DETALHADO, técnico, com comandos e payloads
  Uso: Reprodução de vulnerabilidades, evidências técnicas

TIMELINE MASTER (Global):
  Localização: MASTER_TIMELINE.md
  Conteúdo: RESUMIDO, marcos (milestones), descobertas críticas
  Uso: Visão executiva, relatório final, comunicação com cliente
```

#### **5.2 Estrutura da Timeline Local**

````markdown
# Timeline Local - www.techcorp.com
# Entidade: entity_001_www_techcorp
# Início: 2024-06-10 09:00

---

## 2024-06-10

### 09:15 - RECON - Scan de Portas

**Alvo:** 192.168.1.100
**Ferramenta:** Nmap
**Comando:**
```bash
nmap -sS -p- 192.168.1.100
````

**Resultado:** Portas 80, 443 abertas **Evidência:** `01_RECON/active/2024-06-10_nmap_initial.gnmap`

***

#### 10:30 - ENUM - Identificação de Tecnologias

**Alvo:** [www.techcorp.com:80](http://www.techcorp.com:80) **Ferramenta:** WhatWeb **Resultado:** Apache 2.4.49 **Observação:** ⚠️ Versão vulnerável a CVE-2021-41773

***

#### 14:20 - EXPLOITATION - Teste CVE-2021-41773

**Payload:**

```bash
curl -v --path-as-is http://www.techcorp.com/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd
```

**Resultado:** ✅ LEITURA DE /etc/passwd CONFIRMADA **Severidade:** HIGH **Evidência:** `04_EVIDENCE/screenshots/2024-06-10_path_traversal.png`

***

### 🏁 FIM DO TESTE - ENTIDADE

**Status:** COMPLETED **Total de horas:** 12.5 **Vulnerabilidades confirmadas:** 3

````

### **5.3 Estrutura da Timeline Master (Global)**

```markdown
# MASTER TIMELINE - TechCorp 2024-06
# Projeto: 2024-06-10_TechCorp_045
# Analistas: João Silva, Maria Santos
# Início: 2024-06-10 08:00

---

## 🚀 FASES DO PROJETO

| Data | Hora | Entidade | Evento | Impacto |
|:-----|:-----|:---------|:-------|:--------|
| 2024-06-10 | 09:15 | entity_001 | Scan inicial concluído | INFO |
| 2024-06-10 | 10:30 | entity_001 | Apache 2.4.49 identificado | ⚠️ HIGH |
| 2024-06-10 | 14:20 | entity_001 | CVE-2021-41773 confirmado | 🔴 CRITICAL |
| 2024-06-11 | 09:00 | entity_002 | Início do teste da API | INFO |
| 2024-06-11 | 11:30 | entity_002 | SQL injection confirmada | 🔴 CRITICAL |
| 2024-06-11 | 15:00 | entity_003 | Bucket S3 exposto | 🟠 HIGH |

---

## 📊 RESUMO POR ENTIDADE

| Entidade | Status | Vulnerabilidades | Horas |
|:---------|:-------|:-----------------|:------|
| entity_001_www_techcorp | ✅ COMPLETED | 3 (2 críticas) | 12.5 |
| entity_002_shop_techcorp | 🔄 IN_PROGRESS | 1 (1 crítica) | 6.0 |
| entity_003_api_auth | ⏳ PENDING | - | 0 |

---

## 🚨 EVENTOS CRÍTICOS

### 2024-06-10 14:20 - CVE-2021-41773 Confirmado
- **Entidade:** www.techcorp.com
- **Impacto:** Leitura de arquivos do sistema
- **Status:** Patched solicitado

### 2024-06-11 11:30 - SQL Injection Confirmada
- **Entidade:** shop.techcorp.com
- **Impacto:** Acesso ao banco de dados de produção
- **Status:** Em contenção
````

***

### 🤖 **6. AUTOMAÇÃO E FERRAMENTAS**

#### **6.1 Script de Criação de Entidade (add\_asset.sh)**

```bash
#!/bin/bash
# add_asset.sh - Cria nova entidade no projeto

usage() {
    echo "Uso: ./add_asset.sh <nome_do_ativo> [tipo] [prioridade]"
    echo ""
    echo "Exemplos:"
    echo "  ./add_asset.sh www.techcorp.com web_application CRITICAL"
    echo "  ./add_asset.sh api.techcorp.com api HIGH"
    echo "  ./add_asset.sh 10.10.10.0/24 network MEDIUM"
    exit 1
}

[ -z "$1" ] && usage

ASSET_NAME=$(echo "$1" | sed 's/[^a-zA-Z0-9]/_/g')
ASSET_TYPE="${2:-web_application}"
PRIORITY="${3:-MEDIUM}"
DATE=$(date +%Y%m%d_%H%M%S)
TARGET_DIR="ASSETS/entity_${DATE}_${ASSET_NAME}"

log() { echo "[$(date '+%H:%M:%S')] $1"; }

log "🚀 Criando entidade: $ASSET_NAME"

# Criar estrutura de diretórios
mkdir -p "$TARGET_DIR"/{01_RECON,02_ENUMERATION,03_EXPLOITATION,04_EVIDENCE,05_REPORTING}
mkdir -p "$TARGET_DIR/04_EVIDENCE"/{screenshots,hashes,credentials,logs}

# Criar manifest.yaml
cat > "$TARGET_DIR/manifest.yaml" << EOF
entity:
  name: "$1"
  type: "$ASSET_TYPE"
  priority: "$PRIORITY"
  status: "PENDING"
  lead_analyst: "$(whoami)"
  
discovery:
  source: "manual"
  date: "$(date +%Y-%m-%d)"
  
classification:
  scenario: ""
  scope: ""
  
findings: []

timeline:
  created: "$(date +%Y-%m-%d %H:%M:%S)"
  last_update: "$(date +%Y-%m-%d %H:%M:%S)"
  total_hours: 0
EOF

# Criar timeline local
cat > "$TARGET_DIR/timeline.md" << EOF
# Timeline Local - $1
# Entidade: entity_${DATE}_${ASSET_NAME}
# Tipo: $ASSET_TYPE
# Prioridade: $PRIORITY
# Criado em: $(date '+%Y-%m-%d %H:%M:%S')

---

## 📅 $(date '+%Y-%m-%d')

### $(date '+%H:%M:%S') - INÍCIO - Entidade Criada

**Descrição:** Entidade adicionada ao escopo do projeto
**Status:** PENDING

---

EOF

log "✅ Entidade criada em: $TARGET_DIR"

# Atualizar README principal
echo "" >> README.md
echo "## Entidade: $1" >> README.md
echo "- **Localização:** \`$TARGET_DIR\`" >> README.md
echo "- **Tipo:** $ASSET_TYPE" >> README.md
echo "- **Prioridade:** $PRIORITY" >> README.md
echo "- **Status:** PENDING" >> README.md
echo "" >> README.md

log "✅ README atualizado"
```

#### **6.2 Script de Atualização de Timeline Master**

```bash
#!/bin/bash
# update_master_timeline.sh - Sincroniza timelines locais com a master

MASTER_TIMELINE="MASTER_TIMELINE.md"
TEMP_FILE="/tmp/master_timeline_temp.md"

# Cabeçalho da master timeline
cat > "$TEMP_FILE" << EOF
# MASTER TIMELINE - $(basename $(pwd) | cut -d'_' -f2-)
# Projeto: $(basename $(pwd))
# Gerado em: $(date '+%Y-%m-%d %H:%M:%S')

---

## 📊 VISÃO GERAL DO PROJETO

| Entidade | Tipo | Prioridade | Status | Vulnerabilidades |
|:---------|:-----|:-----------|:-------|:-----------------|
EOF

# Coletar informações de cada entidade
for entity in ASSETS/entity_*/; do
    if [ -f "$entity/manifest.yaml" ]; then
        NAME=$(grep "name:" "$entity/manifest.yaml" | head -1 | sed 's/.*name: //')
        TYPE=$(grep "type:" "$entity/manifest.yaml" | head -1 | sed 's/.*type: //')
        PRIORITY=$(grep "priority:" "$entity/manifest.yaml" | head -1 | sed 's/.*priority: //')
        STATUS=$(grep "status:" "$entity/manifest.yaml" | head -1 | sed 's/.*status: //')
        
        # Contar vulnerabilidades (simplificado)
        VULN_COUNT=$(grep -c "id: VULN-" "$entity/manifest.yaml" 2>/dev/null || echo "0")
        
        echo "| $(basename "$entity") | $TYPE | $PRIORITY | $STATUS | $VULN_COUNT |" >> "$TEMP_FILE"
    fi
done

echo "" >> "$TEMP_FILE"
echo "---" >> "$TEMP_FILE"
echo "" >> "$TEMP_FILE"

# Coletar eventos críticos das timelines locais
echo "## 🚨 EVENTOS CRÍTICOS" >> "$TEMP_FILE"
echo "" >> "$TEMP_FILE"

for entity in ASSETS/entity_*/; do
    if [ -f "$entity/timeline.md" ]; then
        ENTITY_NAME=$(basename "$entity")
        # Buscar por eventos com ✅ ou 🔴
        grep -E "✅|🔴|CRITICAL|SUCESSO|EXPLOIT" "$entity/timeline.md" | while read line; do
            echo "- **$ENTITY_NAME:** $line" >> "$TEMP_FILE"
        done
    fi
done

# Substituir master timeline
mv "$TEMP_FILE" "$MASTER_TIMELINE"

echo "✅ Master timeline atualizada: $MASTER_TIMELINE"
```

#### **6.3 Aliases para Produtividade**

```bash
# ~/.bashrc_aliases

# Navegação entre entidades
alias list-assets='ls -la ASSETS/'
alias go-asset='cd ASSETS/$(ls ASSETS/ | fzf)'

# Gestão de entidades
alias add-asset='~/scripts/add_asset.sh'
alias asset-status='for d in ASSETS/entity_*/; do echo "$(basename $d): $(grep "status:" $d/manifest.yaml 2>/dev/null)"; done'

# Timeline
alias tl-master='cat MASTER_TIMELINE.md'
alias tl-asset='cat $(find ASSETS -name "timeline.md" | fzf)'

# Relatórios
alias report-asset='for d in ASSETS/entity_*/; do echo "=== $(basename $d) ==="; cat $d/05_REPORTING/final_report.md 2>/dev/null || echo "No report yet"; done'
```

***

### 🔄 **7. WORKFLOW DE OPERAÇÃO**

#### **7.1 Fluxo de Trabalho com Entidades**

```mermaid
graph TD
    A[Início do Projeto] --> B[Criar Estrutura Base]
    B --> C[Listar Entidades do Escopo]
    C --> D{Para cada Entidade}
    
    D --> E[Criar Entidade via add_asset.sh]
    E --> F[Executar Recon/Enum]
    F --> G{Encontrou algo?}
    
    G -->|Sim| H[Registrar na Timeline Local]
    G -->|Não| I[Arquivar Entidade]
    
    H --> J[Atualizar Master Timeline]
    J --> K{Próxima Entidade?}
    
    K -->|Sim| D
    K -->|Não| L[Consolidar Relatório]
    
    I --> K
    L --> M[Fim do Projeto]
```

#### **7.2 Operações Diárias**

```yaml
MANHÃ (PLANEJAMENTO):
  1. Revisar MASTER_TIMELINE.md
  2. Identificar entidades prioritárias
  3. Selecionar próxima entidade para teste

DIA (EXECUÇÃO):
  1. cd ASSETS/entity_XXX/
  2. Executar testes na entidade
  3. Registrar eventos na timeline local
  4. Ao final do dia, executar update_master_timeline.sh

FIM DO DIA (REVISÃO):
  1. Revisar timelines locais atualizadas
  2. Verificar master timeline
  3. Commit das mudanças no Git
  4. Planejar próximo dia
```

#### **7.3 Handoff entre Analistas**

```yaml
CENÁRIO: Analista A termina turno, Analista B assume

PASSO 1 - FINALIZAÇÃO DO ANALISTA A:
  1. Commit de todas as mudanças no Git
  2. Atualizar status da entidade no manifest.yaml
  3. Registrar "FIM DE TURNO" na timeline local
  4. Atualizar master timeline

PASSO 2 - COMUNICAÇÃO:
  1. Analista A envia mensagem: "Entidade X em status Y, próxima ação Z"
  2. Indicar entidades bloqueadas ou pendentes

PASSO 3 - ASSUNÇÃO DO ANALISTA B:
  1. Pull do Git
  2. Revisar master timeline
  3. Verificar entidades em andamento
  4. Continuar a partir do ponto parado
```

***

### ✅ **8. CHECKLIST DE GESTÃO DE CENÁRIOS**

#### **8.1 Checklist de Configuração Inicial**

```markdown
## 📋 CONFIGURAÇÃO DO PROJETO

- [ ] Estrutura base criada (00_GLOBAL, ASSETS, SCENARIOS)
- [ ] README.md com mapeamento inicial
- [ ] .gitignore configurado
- [ ] Credenciais criptografadas em 00_GLOBAL/

## 📋 MAPEAMENTO DE ENTIDADES

- [ ] Todas as entidades do escopo foram listadas?
- [ ] Cada entidade tem um manifest.yaml?
- [ ] Prioridades definidas para cada entidade?
- [ ] Dependências entre entidades mapeadas?

## 📋 CONFIGURAÇÃO POR ENTIDADE

- [ ] add_asset.sh executado para cada entidade
- [ ] manifest.yaml preenchido (tipo, prioridade, tecnologia)
- [ ] Timeline local inicializada
- [ ] Tags e classificações definidas
```

#### **8.2 Checklist de Execução**

```markdown
## 📋 ANTES DE TESTAR UMA ENTIDADE

- [ ] Entidade está no escopo?
- [ ] Permissão do cliente obtida?
- [ ] Manifest.yaml atualizado (status: IN_PROGRESS)
- [ ] Timeline local com horário de início

## 📋 DURANTE O TESTE

- [ ] Cada descoberta crítica registrada na timeline local?
- [ ] Evidências salvas em 04_EVIDENCE?
- [ ] Screenshots nomeados corretamente?
- [ ] Payloads salvos em 03_EXPLOITATION?

## 📋 APÓS TESTAR UMA ENTIDADE

- [ ] Status atualizado no manifest.yaml
- [ ] Timeline local com horário de término
- [ ] Master timeline atualizada
- [ ] Vulnerabilidades documentadas no relatório local
- [ ] Commmit das mudanças no Git
```

#### **8.3 Checklist de Qualidade**

```yaml
✅ CRITÉRIOS DE QUALIDADE:

  ORGANIZAÇÃO:
    [ ] Cada entidade tem estrutura de pastas completa
    [ ] Não há arquivos órfãos ou fora de lugar
    [ ] Nomes de arquivos seguem padrão

  RASTREABILIDADE:
    [ ] Cada vulnerabilidade tem ID único
    [ ] Evidências linkadas nos manifests
    [ ] Timeline local e master consistentes

  SEGURANÇA:
    [ ] Credenciais nunca estão em texto plano
    [ ] Dados sensíveis em volume criptografado
    [ ] .gitignore configurado corretamente

  COLABORAÇÃO:
    [ ] Git utilizado para versionamento
    [ ] Handoff documentado
    [ ] Status das entidades atualizados
```

***

### 📊 **RESUMO EXECUTIVO**

```yaml
GESTÃO DE CENÁRIOS E ENTIDADES:

  🎯 PROPÓSITO:
    Organizar testes em ambientes complexos com múltiplos subdomínios,
    APIs, serviços e infraestruturas heterogêneas.

  🏛️ MODELO:
    Asset-Centric (Centrado em Ativos)
    Cada entidade tem sua própria estrutura isolada.

  📂 ESTRUTURA:
    ASSETS/
      ├── entity_001_www/
      ├── entity_002_api/
      └── entity_003_network/

  ⏳ TIMELINE:
    Local (por entidade) + Master (global)

  🤖 AUTOMAÇÃO:
    add_asset.sh, update_master_timeline.sh

  ✅ BENEFÍCIOS:
    ✓ Isolamento de escopos complexos
    ✓ Paralelização de testes
    ✓ Rastreabilidade granular
    ✓ Handoff limpo entre analistas
    ✓ Escalabilidade para projetos massivos

  ⚠️ QUANDO USAR:
    Projetos com mais de 5 ativos distintos
    Equipes com mais de 1 analista
    Testes de longa duração (> 1 semana)
```


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://0xmorte.gitbook.io/bibliadopentestbr/metodos/limpeza-e-organizacao-de-resultados/gestao-de-cenarios-e-entidades-asset-oriented.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.