☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta Blue Team. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Blue Team. Mostrar todas as mensagens

sexta-feira, 1 de dezembro de 2017

“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora

 

Bellacosa Mainframe e o final do red team

☕ Um Café no Bellacosa Mainframe — Especial Red Team

“A Vida Passa Muito Rápido” — O Red Team Depois que Todo Mundo Foi Embora

🎬 Por que o objetivo de um Red Team não é provar que o atacante é inteligente, mas descobrir aquilo que a organização ainda não sabe sobre si mesma

Depois de onze artigos, alguma coisa mudou.

Começamos com Ferris Bueller olhando para regras e percebendo que regras também têm buracos.

Passamos por registros escolares.

Abe Froman.

Cameron.

Telefone.

Engenharia social.

Swiss Cheese.

Ferrari.

MFA.

PAM.

Rollback.

Backup.

Rooney enlouquecendo atrás de sua própria hipótese.

IA generativa.

Agentes.

Deepfake.

Mainframe.

RACF.

z/OS.

APIs.

Service accounts.

E, em algum ponto dessa bagunça maravilhosa, ficou claro que Red Team nunca foi apenas sobre invasão.

Nunca foi apenas sobre “entrar”.

Nunca foi sobre imprimir root na tela e comemorar como se tivéssemos acabado de derrotar a Estrela da Morte.

Red Team, quando bem feito, é outra coisa.

É uma forma organizada de criar desconforto antes que o mundo real crie algo muito pior.

É um espelho adversarial.

É colocar a organização diante de perguntas que ninguém quer ouvir.

E então observar.

Por isso este último episódio não termina com explosão.

Termina com silêncio.

O dia acabou.

Ferris voltou para casa.

Rooney perdeu a batalha.

Cameron ficou olhando para a Ferrari.

O sistema continuou rodando.

E agora precisamos responder:

o que aprendemos?

Bem-vindo ao último episódio de:

SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula


🔴 Red Team não é esporte de ego

Existe uma tentação.

Uma tentação enorme.

O Red Team consegue acesso.

Escala privilégio.

Atinge objetivo.

E alguém pensa:

“HA! CONSEGUI INVADIR.”

Pronto.

Fim.

Não.

Esse é o começo.

Se o resultado de um Red Team é apenas demonstrar que alguém é inteligente, o exercício falhou.

Talvez tenha sido tecnicamente interessante.

Talvez tenha sido divertido.

Mas o valor organizacional é pequeno.

Porque o objetivo real não é provar que o atacante é esperto.

É descobrir:

o que a organização não sabia sobre si mesma.


🧠 A descoberta é o produto

Isso muda tudo.

O exploit é meio.

A evidência é meio.

A técnica é meio.

O conhecimento novo é o produto.

Imagine:

Ataque
   ↓
Descoberta
   ↓
Evidência
   ↓
Correção
   ↓
Detecção
   ↓
Aprendizado

Isso é Red Team maduro.


☕ Ferris entra. E depois?

Se Ferris conseguiu entrar, excelente.

Agora pergunte:

como?

Por qual caminho?

Qual controle não funcionou?

Qual controle nem existia?

Qual suposição estava errada?

Quem deveria ter percebido?

Quem percebeu e ignorou?

Quanto tempo levou?

Que evidência ficou?

Que privilégio permitiu avançar?

Essa investigação é muito mais importante que a entrada.


🔎 O momento da verdade

Uma operação Red Team deveria produzir um momento desconfortável.

Aquele em que alguém olha para um diagrama e diz:

— Espera.

— Isso é possível?

E alguém responde:

— Sim.

Esse é o valor.

Não humilhar.

Iluminar.


🧠 Segurança é cheia de certezas não testadas

“Essa rede é isolada.”

“Esse usuário não tem acesso.”

“Esse sistema não está exposto.”

“Esse backup funciona.”

“Esse alerta sempre dispara.”

“Essa conta só é usada por aplicação.”

“Esse fornecedor não consegue chegar lá.”

“Esse endpoint não fala com produção.”

Red Team pega cada frase e pergunta:

“Tem certeza?”


🔴 A organização imagina arquitetura. O atacante encontra caminhos.

Esse talvez seja o tema central da série inteira.

Arquitetura desenha caixas.

Atacante segue setas.

A empresa vê:

USER
APP
DB
MAINFRAME

Ferris vê:

Pessoa
 ↓
Confiança
 ↓
Credencial
 ↓
API
 ↓
Service Account
 ↓
Mainframe

O risco não está apenas nos objetos.

Está nas relações.


🧠 O desconhecido é o verdadeiro alvo

Você já sabe que senha fraca é ruim.

Já sabe que MFA ajuda.

Já sabe que least privilege importa.

O Red Team fica valioso quando encontra algo que ninguém tinha modelado.

Por exemplo:

uma dependência esquecida.

Um usuário privilegiado por herança.

Uma API que transforma identidade humana em conta genérica.

Um fornecedor que ainda possui acesso.

Um processo de Help Desk que contorna MFA.

Esse é o ouro.


☕ Não queremos apenas vulnerabilidades

Queremos falhas sistêmicas.

Uma vulnerabilidade é:

“este componente tem problema.”

Uma falha sistêmica é:

“essas cinco coisas juntas criam um caminho.”

E isso é muito mais interessante.


🧀 Swiss Cheese volta pela última vez

Durante toda a série, o queijo suíço apareceu.

Não por acaso.

Red Team vive de alinhamento.

Uma falha pequena.

Outra pequena.

Mais uma.

E pronto.

OSINT
 ↓
Pretexto
 ↓
Reset
 ↓
Conta
 ↓
Privilégio
 ↓
Sistema

Nenhum buraco sozinho era suficiente.

Juntos, eram.


🔵 O Blue Team não deveria perder

Isso também é importante.

Red Team não existe para derrotar Blue Team.

Essa rivalidade pode ser divertida em exercício.

Mas é pedagogicamente pobre quando vira cultura.

Se Red ganha e Blue aprende, organização ganhou.

Se Blue detecta Red cedo e Red aprende como foi detectado, organização ganhou.

O objetivo não é troféu.

É aprendizado.


🧠 Purple Team é maturidade

Quando Red e Blue compartilham conhecimento, o valor sobe.

Red mostra:

“entrei por aqui.”

Blue responde:

“não vimos.”

Engineering corrige.

Depois repete.

Isso é evolução.


🔁 Reteste é fundamental

Corrigir sem retestar é esperança.

Você fecha vulnerabilidade.

Ótimo.

Red tenta de novo.

Funcionou?

Se sim, evidência.

Se não, continue.


☕ Segurança sem feedback vira ritual

Isso é perigoso.

Executar checklist.

Gerar relatório.

Arquivar PDF.

Nada muda.

Pronto.

Red Team virou teatro.

O exercício só tem valor se produzir mudança.


📜 O relatório não é o fim

Relatório deveria responder:

o que aconteceu?

por que aconteceu?

qual impacto?

qual evidência?

como corrigir?

como detectar?

como evitar repetição?

Esse último ponto importa.


🔍 Evidência concreta

Não:

“poderia haver risco.”

Mas:

“este caminho permitiu chegar até aqui.”

Evidence-based.

Captura.

Logs.

Timeline.

Com clareza.


🧠 Vulnerability ≠ Exploitability ≠ Impact

Uma falha pode existir e não ser explorável.

Pode ser explorável e ter baixo impacto.

Pode parecer pequena e abrir caminho gigantesco.

Red Team ajuda a contextualizar.


🎯 Objective-Based Red Team

Por isso objetivo importa.

Não “escaneie portas”.

Mas:

“consiga acessar dado crítico.”

Agora o time precisa pensar como adversário.

Ferris não quer CVE.

Quer resultado.


☕ A pergunta mais adulta da temporada

Depois de todo caos:

“O que isso ensina sobre nosso sistema?”

Essa pergunta transforma ataque em engenharia.


🧠 Talvez a resposta seja tecnologia

Pode ser patch.

Configuração.

MFA.

Segmentation.

PAM.

Fine.


🧠 Talvez seja processo

Help Desk.

Mudança.

Aprovação.

Offboarding.

Incident Response.

Também válido.


🧠 Talvez seja cultura

Autoridade excessiva.

Urgência.

Medo de questionar.

“Depois regularizamos.”

Talvez essa seja a raiz.


🔴 O atacante testa organização inteira

Esse é um ponto essencial.

Não apenas IT.

Segurança.

RH.

Fornecedores.

Gestores.

Processos.

Ferris explorou tudo isso.


🏫 A escola de Ferris era uma organização

Tinha:

diretor;

regras;

registro;

tecnologia;

pessoas;

processos.

Era perfeita para mostrar que superfície de ataque não é apenas digital.


🧠 A empresa moderna é igual, só maior

E mais conectada.

E mais rápida.

E mais complexa.

Então risco cresce.


☕ Complexidade é inimiga silenciosa

Quanto mais sistemas.

Mais integrações.

Mais contas.

Mais exceções.

Mais difícil compreender tudo.

Red Team encontra caminhos que ninguém desenhou.


🕸️ Shadow Paths

Relações não documentadas.

Scripts antigos.

Contas herdadas.

Integrações temporárias.

Esses caminhos são perigosos.


🔎 Attack Surface Management

Conhecer o que existe.

Inventário.

Exposição.

Relações.

Sem isso, você protege o que conhece.

E Ferris usa o que esqueceu.


🧠 O sistema muda mais rápido que documentação

Essa é uma verdade dolorosa.

Hoje arquitetura está certa.

Amanhã alguém cria uma API.

Depois um pipeline.

Depois uma integração.

Depois uma exceção.

Se Red Team roda uma vez por ano, pode testar fotografia antiga.


🔁 Segurança contínua

Threat modeling.

Testing.

Validation.

Monitoring.

Não precisa ser ataque completo toda semana.

Mas precisa existir loop.


☕ Red Team também deve aprender

Essa parte às vezes é ignorada.

O atacante simulado também pode errar.

Criar hipótese ruim.

Focar demais numa técnica.

Perder caminho.

Red Team precisa revisar suas próprias decisões.

Rooney pode existir do lado vermelho também.


🧠 Confirmation Bias no Red Team

“Esse sistema deve estar vulnerável.”

Talvez não.

Se você insiste só porque quer achar algo, perde credibilidade.

O objetivo é verdade.

Não vitória.


🔴 Red Team profissional sabe parar

Se controle funcionou:

registre.

Respeite.

Não force artificialmente só para “ganhar”.

Porque exercício deve refletir risco real.


🧠 Rules of Engagement

Tudo precisa de escopo.

Autorização.

Limites.

Horários.

Critérios.

Red Team sem governança é risco.

Ferris pode improvisar.

Profissional não.


☕ A diferença entre Ferris e um Red Teamer

Ferris quer sair da escola.

Red Team quer melhorar a escola.

Essa é uma boa síntese.


🧾 “Conseguimos entrar” não basta

Precisamos:

documentar caminho;

corrigir;

criar detecção;

retirar privilégio;

melhorar processo.

Senão Ferris volta amanhã.


🔐 Detecção é parte da correção

Você pode não impedir tudo.

Então precisa ver.

Se exploit funciona mas Blue detecta em 30 segundos, resposta é muito diferente.

Red Team deve testar detectabilidade.


⏱️ Time to Detect

Quanto tempo?

Segundos?

Minutos?

Horas?

Dias?

Esse número importa.


🧠 Time to Contain

Depois de detectar, quanto tempo para conter?

Detectar sem agir também falha.


🔴 Detection Engineering

Transformar achado em regra.

Query.

Correlation.

Behavior.

Isso fecha ciclo.


🧪 Reteste da detecção

Red executa novamente.

Blue vê?

Excelente.

Aprendizado virou capacidade.


☕ Ataque sem detecção vira surpresa

E surpresa em produção raramente é divertida.


🦖 Mainframe entra no fechamento

No artigo anterior, vimos que z/OS pode ser extremamente seguro e ainda estar ligado a dezenas de sistemas.

Essa é a síntese perfeita.

Red Team moderno não pode tratar mainframe como ilha.

Precisa testar caminho.


🔐 RACF pode funcionar perfeitamente

E ainda assim o contexto anterior estar comprometido.

Isso é o que aprendemos.


🧠 A segurança local não garante segurança global

Essa frase também merece parede.

Componente seguro dentro de sistema inseguro continua exposto.


🕸️ API é confiança.

MQ é confiança.

Pipeline é confiança.

IAM é confiança.

Tudo precisa ser validado.


☕ A velha Ferrari também volta

A Ferrari estava segura porque ninguém ousava tocar.

Até tocar.

O mesmo vale para produção.

“ninguém mexe nisso” não é controle.


🔐 Controle é verificável

MFA.

PAM.

Logs.

Segregação.

Approval.

Essas coisas não dependem apenas de boa vontade.


🧠 E o rollback?

Também aprendemos:

você pode corrigir estado.

Não necessariamente consequência.

Por isso resposta importa.


🔁 Resilience é mais que backup

É:

detectar;

conter;

recuperar;

aprender.


🔴 E Rooney?

Talvez seja uma das maiores lições.

O defensor também pode ser vulnerabilidade.

Viés.

Ego.

Pressão.

Autoridade.

Security culture precisa proteger decisão.


🧠 A War Room também é sistema

Pessoas.

Processos.

Informações.

Decisões.

Tudo pode falhar.


☕ Red Team cognitivo

Uma ideia poderosa.

Teste não apenas tecnologia.

Teste como equipe reage.

Ambiguidade.

Pressão.

Sinais conflitantes.

Isso aumenta maturidade.


🤖 FerrisGPT também deixa legado

IA trouxe escala.

Mas não mudou fundamentos.

Identity.

Authorization.

Privilege.

Trust.

Context.

Logs.

Mesma história.


🧠 Tecnologia nova, problemas antigos

Talvez essa seja a frase da temporada.

Mudamos interface.

Mantivemos vulnerabilidades humanas.


🔴 O futuro não mata o passado

Mainframe continua.

Cloud cresce.

IA entra.

Tudo coexistindo.

Superfície de ataque vira camada sobre camada.


☕ Sistemas passam muito rápido

Aqui chegamos à frase final.

No filme, Ferris fala sobre vida.

Sobre parar.

Observar.

Porque passa rápido.

Em tecnologia, acontece algo parecido.

Sistema muda.

Versão muda.

Pessoas mudam.

Arquitetura muda.

Fornecedores mudam.

Privilégios acumulam.

APIs surgem.

Agentes entram.

Se você não parar para olhar...

pode perder o mapa.


🧠 O ambiente de hoje não é o de ontem

Isso é simples.

Mas organizações continuam operando com threat model antigo.

“Esse sistema nunca foi exposto.”

Agora tem API.

“Esse usuário não acessa produção.”

Agora está em grupo novo.

“Essa aplicação não fala com cloud.”

Agora fala.

Mudança cria risco.


🔎 Continuous Discovery

Inventário contínuo.

Mapeamento.

Revisão.

Porque o desconhecido cresce.


☕ A melhor descoberta é antes do atacante real

Esse é todo propósito.

Red Team compra aprendizado com risco controlado.

Melhor descobrir falha numa simulação do que num incidente.


🔴 Red Team é caos com contrato

Gostei dessa definição.

Você cria pressão controlada.

Dentro de regras.

Para revelar comportamento real.

É quase Chaos Engineering de segurança.


🧠 Mas cuidado com teatro

Se todos sabem exatamente o script, teste perde realismo.

Ainda assim precisa segurança.

Equilíbrio.


🎯 O sucesso não é “entramos”

Sucesso é:

algo mudou.

Controle melhorou.

Alerta nasceu.

Privilégio caiu.

Processo foi corrigido.

Pessoas aprenderam.

Isso é sucesso.


☕ Métricas melhores

Em vez de:

“Quantos sistemas comprometemos?”

Talvez:

quantos attack paths foram eliminados?

quanto caiu time to detect?

quantas contas privilegiadas foram removidas?

quantos controles foram validados?

Isso mostra maturidade.


🧠 Red Team como sensor organizacional

Ele detecta fraqueza.

Não apenas software.

Cultura.

Processo.

Arquitetura.

Governança.

É quase um instrumento diagnóstico.


🔴 Diagnóstico sem tratamento é inútil

Relatório sem ação vira coleção de PDFs.

Ferris volta.


🧾 Ownership

Cada achado precisa dono.

Prazo.

Prioridade.

Risco.

Reteste.

Caso contrário, desaparece em backlog.


☕ “Aceitamos o risco”

Pode ser legítimo.

Nem tudo precisa corrigir.

Mas aceitação deve ser consciente.

Não esquecimento.


🧠 Risk Acceptance ≠ Neglect

Se negócio aceita, documente.

Contexto.

Compensating control.

Prazo.

Ferris não deve ser surpresa.


🔐 Compensating Controls

Não consegue corrigir agora?

Monitore.

Limite.

Segmente.

Reduza blast radius.

Segurança prática.


🧠 Defense in Depth é admitir imperfeição

Essa é a beleza.

Não acreditamos em controle perfeito.

Criamos vários.

Swiss Cheese invertido.


🔴 O atacante procura alinhamento

Defensor cria desalinhamento.

Isso resume metade da segurança.


☕ “E se alguém já encontrou a porta dos fundos?”

Essa pergunta deveria ser feita periodicamente.

Não por paranoia.

Por maturidade.


🔍 Threat Hunting

Procurar comportamento sem esperar alerta.

Uma extensão natural.

Se Red Team mostrou caminho, Blue pode hunt.


🧠 Assume Breach

Não significa derrotismo.

Significa perguntar:

se já entrou, como vemos?

Isso muda desenho.


🔐 Zero Trust volta

Verifique.

Limite.

Monitore.

Não confie implicitamente.

Ferris não ganha passe vitalício.


☕ Segurança é confiança condicionada

Talvez essa seja melhor definição.

Confiamos.

Mas verificamos.

Limitamos.

Reavaliamos.


🧠 Ferris era especialista em confiança implícita

Pais.

Escola.

Restaurante.

Cameron.

Sistema.

Tudo dependia dela.

Por isso funcionou.


🔴 A grande conclusão da série

Não ataque a tecnologia.

Ataque as suposições.

Essa foi a primeira ideia.

E continua no final.


🧠 As suposições invisíveis

“Usuário não fará isso.”

“Fornecedor não será comprometido.”

“Token não vazará.”

“Agente seguirá prompt.”

“Admin não será enganado.”

Tudo hipótese.

Teste.


☕ Segurança baseada em esperança é esperança com dashboard

Essa frase continua maravilhosa.


🦖 Bellacosa Mainframe fecha o ciclo

Mainframe ensina uma coisa importante.

Confiabilidade vem de disciplina.

Processo.

Controle.

Auditoria.

Recovery.

Não de magia.

Red Team deve adicionar adversarial thinking a essa disciplina.


🧠 Modernização sem esquecer fundamentos

APIs.

IA.

Cloud.

Zowe.

z/OS Connect.

Tudo pode coexistir.

Mas segurança clássica continua:

Identity.

Authorization.

Audit.

Segregation.

Recovery.


🔴 O velho e o novo compartilham o mesmo problema

Confiança.

Sempre confiança.


☕ A pergunta Bellacosa número 1

Depois do Red Team:

“O que descobrimos que não sabíamos?”

Se resposta for “nada”...

talvez o teste tenha sido ruim.

Ou o ambiente seja excelente.

Reteste para saber.


🧠 Pergunta número 2

“Qual controle acreditávamos que funcionava e não funcionou?”


🔴 Pergunta número 3

“Qual controle funcionou e por quê?”

Também aprenda sucesso.


🧠 Pergunta número 4

“O Blue Team percebeu?”


🔐 Pergunta número 5

“Se isso fosse real, qual seria o impacto?”


🧾 Pergunta número 6

“Quem é dono da correção?”


🔁 Pergunta número 7

“Quando retestamos?”


🧠 Pergunta número 8

“Que nova hipótese nasceu desse achado?”

Porque aprendizado cria nova investigação.


☕ O ciclo nunca termina

Ataque.

Descoberta.

Correção.

Detecção.

Aprendizado.

Depois:

novo ataque.

Porque ambiente mudou.


🔄 Security Feedback Loop

Attack
 ↓
Learn
 ↓
Improve
 ↓
Detect
 ↓
Adapt
 ↓
Attack Again

Não é fracasso.

É evolução.


🎬 Todo mundo foi embora

Agora imagine a escola vazia.

Corredores silenciosos.

Rooney foi para casa.

Cameron está pensando na vida.

Ferris terminou sua aventura.

O computador continua ligado.

Os registros continuam lá.

Nada parece diferente.

Mas nós sabemos.

Sabemos que:

o sistema confiou demais.

As pessoas confiaram demais.

Os controles tinham buracos.

O atacante viu caminhos invisíveis.

Essa é a transformação.

Depois de um bom Red Team, você não olha para ambiente da mesma maneira.


🧠 Segurança é aprender a enxergar caminhos

Uma porta.

Uma identidade.

Uma relação.

Uma exceção.

Uma API.

Tudo pode ser parte de algo maior.


☕ Ferris não precisa ganhar de novo

Se a organização aprendeu, próxima vez será diferente.

Talvez Cameron diga não.

Talvez Help Desk verifique.

Talvez MFA bloqueie.

Talvez SOC correlacione.

Talvez RACF negue.

Talvez pipeline exija aprovação.

Aí Red Team cumpriu seu papel.


🔵 Blue Team ficou mais forte

Esse é o troféu.

Não o shell.


🧠 A cultura ficou mais forte

Melhor ainda.

Pessoas começaram a perguntar:

“Como sabemos?”

Isso é maturidade.


🔴 O melhor legado de Ferris é dúvida saudável

Não paranoia.

Dúvida.


☕ “Está no sistema.”

Como sabemos?


☕ “É o diretor.”

Autenticamos?


☕ “Essa conta precisa de privilégio.”

Ainda precisa?


☕ “O backup funciona.”

Testamos?


☕ “A IA não pode fazer isso.”

Quem impede?


☕ “O mainframe é seguro.”

E o caminho até ele?


🎬 Essa é a série inteira numa página

Perguntas.

Ferris sobrevive porque pergunta.

Defesa melhora quando aprende a perguntar também.


🧠 O atacante pensa diferente

Por isso Red Team é valioso.

Ele injeta uma perspectiva que a organização naturalmente perde.

Quem constrói vê intenção.

Quem ataca vê abuso possível.


🔴 Builder vs Breaker

O desenvolvedor pergunta:

“Como isso deveria funcionar?”

O Red Team pergunta:

“Como isso pode funcionar de modo inesperado?”

Ambos são necessários.


☕ Segurança nasce do diálogo entre os dois

Sem builder, nada existe.

Sem breaker, suposições permanecem invisíveis.


🧠 Adversarial Thinking é disciplina

Não cinismo.

Não paranoia.

Disciplina.

Testar hipóteses.

Imaginar mau uso.

Validar.


🔴 O Red Team não é inimigo

É amigo inconveniente.

Aquele que aponta:

“Você deixou a Ferrari destrancada.”

Melhor ouvir dele.


☕ Porque o atacante real não entrega relatório

Essa é talvez a frase mais importante.

O Red Team entrega relatório.

O atacante real entrega incidente.

Escolha qual prefere.


🎬 Ferris olha para a câmera

Última cena.

Ferris abre a porta.

Olha para nós.

Quase como se soubesse que passamos doze artigos transformando uma comédia adolescente numa tese sobre cybersecurity, RACF, AI e engenharia social.

E talvez diga:

— Vocês ainda estão aqui?

Sim.

Estamos.

Porque sistemas são complicados.

Confiança é complicada.

Pessoas são complicadas.

E segurança é a arte de impedir que toda essa complexidade vire desastre.


☕ Epílogo: a vida passa muito rápido

Ferris tinha razão sobre uma coisa.

A vida passa rápido.

Sistemas também.

Arquitetura muda.

Equipe muda.

Ameaça muda.

Tecnologia muda.

Aquilo que era seguro ontem pode não ser amanhã.

Então precisamos parar.

Olhar.

Observar.

Questionar.

Testar.

Porque segurança não é uma fotografia.

É um processo.

E talvez a melhor forma de resumir toda esta temporada seja assim:

Sistemas passam muito rápido. Se você não parar para observá-los de vez em quando, pode não perceber que alguém já encontrou um jeito de sair pela porta dos fundos.

Não precisamos transformar Ferris em vilão.

Nem Rooney em incompetente.

Nem Cameron em vulnerabilidade.

Eles são apenas personagens excelentes para lembrar que todo sistema é feito de componentes humanos e técnicos ligados por confiança.

E toda confiança deveria responder:

quem?

por quê?

por quanto tempo?

com qual evidência?

com qual limite?

Depois de doze cafés, esse é o verdadeiro Red Team.

Não:

“HA! CONSEGUI INVADIR.”

Mas:

“Olha o que aprendemos antes que alguém de verdade descobrisse.”

Então feche o terminal.

Salve os logs.

Atualize o ticket.

Revogue a credencial temporária.

Reteste a correção.

Sirva mais um café.

E olhe novamente para o ambiente.

Porque Ferris já foi embora.

Mas outro adversário talvez esteja chegando.

SAVE FERRIS.

Fim da temporada.

sexta-feira, 1 de setembro de 2017

Rooney Invadiu a Casa Errada — Quando o Blue Team Vira o Próprio Incidente

 

Bellacosa Mainframe e o blue team 

☕ Um Café no Bellacosa Mainframe — Especial Red Team

Rooney Invadiu a Casa Errada — Quando o Blue Team Vira o Próprio Incidente

🕵️ Tunnel vision, confirmation bias e o investigador que fica tão obcecado pelo atacante que começa a quebrar controles 

Existe um momento em Curtindo a Vida Adoidado em que o diretor Rooney deixa de ser apenas o homem tentando descobrir se Ferris matou aula.

Ele atravessa uma linha.

A investigação deixa de ser investigação.

Vira obsessão.

A suspeita deixa de ser hipótese.

Vira certeza.

E, a partir daí, qualquer fato novo precisa se encaixar numa conclusão já pronta:

Ferris é culpado.

Se uma evidência aponta para isso, ótimo.

Se não aponta, então provavelmente é mais uma prova de como Ferris é inteligente.

Essa lógica é maravilhosa porque é quase impossível perder.

E justamente por isso é perigosíssima.

Rooney começa querendo descobrir a verdade.

Termina disposto a atropelar processo, contexto, prudência e, em determinado momento, praticamente a própria dignidade para provar que estava certo desde o início.

Bem-vindo ao nono episódio de:

SAVE FERRIS — Red Team para Quem Aprendeu que o Sistema Também Mata Aula

Hoje o atacante quase pode descansar.

Porque o Blue Team resolveu fazer metade do trabalho por ele.


🔵 O Blue Team também é humano

Nós falamos muito sobre comportamento do atacante.

Criatividade.

Persistência.

Engenharia social.

OSINT.

Mas existe outro lado.

Quem defende também pensa.

Interpreta.

Erra.

Fica cansado.

Fica irritado.

Cria hipóteses.

Se apaixona por elas.

E, sob pressão, pode transformar uma investigação numa máquina de confirmar aquilo que já acredita.

É aí que Rooney entra em produção.


🧠 Confirmation Bias: “Eu sabia!”

Confirmation Bias é a tendência de buscar, interpretar e valorizar informações que confirmam aquilo que já acreditamos.

Rooney acredita que Ferris está fraudando tudo.

Então o mundo começa a ser filtrado por essa certeza.

Qualquer comportamento estranho?

Ferris.

Qualquer inconsistência?

Ferris.

Qualquer explicação alternativa?

Provavelmente armadilha do Ferris.

Isso é perigosíssimo em segurança.


🚨 O alerta que virou religião

Imagine um SOC.

Um analista vê:

03:14 Login Failure
03:15 Login Success
03:17 Query Sensível

Hipótese inicial:

conta comprometida.

Ótimo.

Hipótese é necessária.

O problema começa quando hipótese vira sentença.

A partir daí:

novo login?

comprometimento.

Mudança de senha?

tentativa de persistência.

Usuário afirma que foi ele?

engenharia social.

Gerente confirma?

talvez também esteja comprometido.

Agora temos um sistema fechado.

Tudo confirma tudo.


☕ Hipótese não é conclusão

Esse ponto deveria ser repetido em toda War Room.

Uma hipótese serve para orientar investigação.

Não para encerrá-la.

O processo deveria parecer:

Hipótese
 ↓
Evidência
 ↓
Teste
 ↓
Contradição
 ↓
Revisão

Mas Rooney faz:

Hipótese
 ↓
Certeza
 ↓
Caça seletiva por evidência
 ↓
Certeza maior

Isso não é investigação.

É fanfic operacional.


🔎 Tunnel Vision: quando o mundo desaparece ao redor

Tunnel vision acontece quando alguém se concentra tanto numa explicação que deixa de enxergar alternativas.

Rooney vê Ferris.

Só Ferris.

O resto vira ruído.

Em segurança, isso pode ser desastroso.

Equipe investiga malware.

Enquanto o problema real é credencial.

Investiga insider.

Enquanto o vetor foi fornecedor.

Investiga ataque externo.

Enquanto a falha foi integração.

Investiga ransomware.

Enquanto o que houve foi erro de configuração.

O custo não é apenas epistemológico.

É operacional.

Enquanto você procura no lugar errado, o problema real continua vivo.


🧠 O atacante pode explorar isso

Agora a coisa fica interessante.

Se o atacante perceber que o defensor está convencido de determinada narrativa, pode alimentar essa narrativa.

Isso é quase uma forma de engenharia social defensiva invertida.

Você oferece pistas que parecem confirmar a hipótese errada.

Blue Team corre atrás.

Atacante trabalha em outro lugar.


🎭 Decoy mental

Não precisa ser tecnologia sofisticada.

Pode ser:

um artefato chamativo;

um IOC óbvio demais;

um usuário “suspeito”;

um arquivo com nome sugestivo;

uma ferramenta conhecida;

qualquer coisa capaz de capturar atenção.

O defensor vê aquilo e pensa:

“É isso!”

E pronto.

Rooney encontrou Ferris.

Ou acha que encontrou.


🔴 Quando o investigador começa a quebrar controles

Essa é a parte mais perigosa.

Rooney começa a justificar decisões ruins porque acredita que o objetivo é importante.

Em segurança, isso acontece quando alguém pensa:

“Precisamos agir rápido.”

Então:

desabilita controle;

pula aprovação;

faz mudança direta;

executa script não testado;

bloqueia usuário crítico;

mata processo;

derruba serviço;

apaga evidência;

tudo em nome da resposta.

Blue Team vira incidente.


💣 A contenção derrubou produção

Clássico.

Atacante faz uma coisa.

Resposta faz dez.

Exemplo:

possível comprometimento numa conta.

Em vez de conter cuidadosamente, equipe revoga dezenas de acessos sem mapear dependências.

Resultado:

serviços caem.

Batch falha.

APIs param.

Job crítico não roda.

O atacante talvez nem precisasse fazer tudo isso.

O defensor completou o serviço.


☕ “Mas precisávamos fazer alguma coisa!”

Isso nos leva a outro viés.

Action Bias.

Mesmo não estando na lista principal, ele caminha ao lado de Rooney.

Sob pressão, fazer alguma coisa parece melhor do que aguardar evidência.

Mas ação sem modelo pode piorar.

Às vezes a melhor resposta é observar por mais alguns minutos.

Coletar.

Validar.

Conter com precisão.

Não sair batendo em tudo.


🔁 Plan Continuation Bias: o plano já não funciona, mas seguimos

Agora entramos numa das joias.

Plan Continuation Bias.

Você começa com um plano.

O contexto muda.

Novas evidências mostram que talvez esteja errado.

Mas você continua.

Por quê?

Porque já investiu.

Porque já anunciou.

Porque mudar parece fraqueza.

Rooney domina isso.

Ele começou perseguindo Ferris.

Cada fracasso deveria fazê-lo reconsiderar.

Mas produz efeito oposto.

Quanto mais dá errado, mais ele insiste.


🧠 O plano vira identidade

Isso acontece em War Rooms.

Alguém diz:

“O problema é o firewall.”

A equipe começa.

Quarenta minutos depois, nada.

Mas agora a investigação “é sobre firewall”.

Então todo mundo continua.

Mais uma hora.

Nada.

Mudar de hipótese começa a parecer admitir incompetência.

Isso é veneno.


🔥 Sunk Cost Fallacy: já gastamos demais para parar

Sunk Cost Fallacy entra logo depois.

Você já investiu:

tempo;

energia;

capital político;

reputação.

Então sente que precisa continuar.

Rooney já atravessou tanto desconforto perseguindo Ferris que parar seria reconhecer que tudo foi em vão.

Então continua.

Em segurança:

“Já estamos há seis horas investigando isso.”

Isso não é razão para continuar.

É apenas histórico.


☕ Passado não valida hipótese

Essa frase vale ouro.

Ter investido dez horas numa teoria não a torna mais verdadeira.

Talvez apenas torne o erro mais caro.

A decisão correta precisa considerar evidência atual.

Não ego acumulado.


👔 Authority Gradient: ninguém contradiz Rooney

Agora temos outro problema.

Rooney é diretor.

Autoridade.

Pessoas abaixo podem hesitar em contestar.

Isso é Authority Gradient.

Quanto maior a distância percebida de poder, menor a chance de alguém dizer:

“Chefe, talvez estejamos errados.”

Em aviação, medicina e operações críticas, isso é conhecido há décadas.

Em cybersecurity também deveria ser.


🧠 A frase mais importante numa War Room

Talvez seja:

“Não concordo com essa hipótese.”

Mas cultura precisa permitir isso.

Se discordar de líder causa punição, ninguém desafia.

O erro cresce.

Rooney continua andando.

E todo mundo assiste.


🔵 Blue Team precisa de dissenso estruturado

Não basta dizer:

“Pode falar.”

É preciso criar mecanismo.

Exemplo:

a cada 30 minutos, alguém assume papel de challenger.

Pergunta:

qual evidência contradiz nossa teoria?

qual hipótese alternativa existe?

o que estamos ignorando?

que ação nossa está criando risco?

Isso reduz tunnel vision.


🎯 Red Team pode ajudar Blue Team a pensar melhor

Red Team não serve apenas para explorar tecnologia.

Pode testar processo cognitivo.

Como equipe reage a pistas conflitantes?

Como muda hipótese?

Quem desafia liderança?

Existe espaço para dizer “não sabemos”?

Isso é maturidade operacional.


🧠 Outcome Bias: deu certo, então a decisão foi boa

Outro clássico.

Suponha que Rooney faça algo absurdo.

Por acaso, encontra Ferris.

Depois todos dizem:

“Viu? Funcionou.”

Isso é Outcome Bias.

Confundir resultado com qualidade da decisão.

Uma decisão ruim pode ter bom resultado.

Uma decisão boa pode ter mau resultado.

Processo precisa ser avaliado pelo que era conhecido no momento.


☕ Acertei pelo motivo errado

Isso acontece muito em incidente.

Alguém reinicia servidor.

Problema some.

Conclusão:

“Era o servidor.”

Talvez.

Ou talvez restart apenas mascarou.

Mas como melhorou, a ação ganha legitimidade retroativa.

Perigoso.


🧪 Correlation não é causation, Rooney

Se duas coisas acontecem juntas, não significa que uma causou outra.

Ferris aparece.

Sistema muda.

Rooney conecta.

Talvez correto.

Talvez não.

Segurança precisa trabalhar com evidência.

Não narrativas bonitas.


🧠 Narrativas são sedutoras

Incident response adora histórias limpas.

“Atacante entrou aqui, fez isso, foi detectado, bloqueamos.”

Realidade é bagunçada.

Logs faltam.

Horários divergem.

Usuários lembram mal.

Sistemas não sincronizam.

Se uma história fica perfeita cedo demais, desconfie.

Talvez estejamos preenchendo lacunas com imaginação.


🔎 Premature Closure

Outro viés importante.

Encerrar investigação cedo porque encontramos explicação que parece boa o suficiente.

“Foi phishing.”

Fim.

Mas qual phishing?

Quem clicou?

Qual credencial?

Qual caminho?

Houve persistência?

Outros usuários?

Se você fecha cedo, pode deixar atacante dentro.


🔁 Diagnosis Momentum

Uma hipótese ganha etiqueta.

Depois vira verdade institucional.

Primeiro analista escreve:

“Possible credential theft.”

Segundo lê e assume:

“Credential theft confirmed.”

Terceiro adiciona:

“Known credential theft incident.”

Agora ninguém sabe de onde saiu a certeza.

Rooney em escala corporativa.


🧾 O ticket também pode criar viés

A primeira descrição de um incidente influencia toda a investigação.

Se o ticket chega como:

“Malware no servidor X.”

Todo mundo começa buscando malware.

Talvez problema nem seja malware.

Por isso linguagem inicial deveria ser neutra.

Exemplo:

“Comportamento anômalo observado no servidor X.”

Menos sexy.

Mais correto.


🦖 No mainframe, Rooney pode ser caríssimo

Imagine z/OS.

Uma suspeita.

Alguém decide:

“É esse job.”

Então mata job.

Depois bloqueia usuário.

Depois altera RACF.

Depois cancela started task.

Depois derruba região CICS.

Resultado:

incidente de segurança virou indisponibilidade operacional.

No mainframe, mudanças impulsivas podem ter efeito gigantesco.


🔐 Não use REVOKE como martelo universal

Revogar usuário pode ser necessário.

Mas pergunte:

essa conta é humana?

técnica?

usada por batch?

serviço?

integração?

Bloquear sem contexto pode quebrar cadeia crítica.

Ferris nem precisa tocar produção.

Rooney faz.


🧠 O velho problema da conta compartilhada

Se você vê atividade suspeita numa conta técnica e resolve revogar...

pode derrubar dez aplicações.

Isso mostra por que arquitetura ruim aumenta risco de resposta.

Identidade ruim vira contenção difícil.


🚨 Containment precisa ser proporcional

Resposta madura tenta reduzir risco sem aumentar dano desnecessariamente.

Containment pode ser:

isolar host;

limitar token;

desabilitar função específica;

revogar sessão;

bloquear origem;

não necessariamente desligar o mundo.


☕ O atacante adora resposta previsível

Se defensor sempre reage do mesmo jeito, pode ser manipulado.

Atacante faz barulho numa área.

Blue Team concentra tudo lá.

Outro caminho fica livre.

É diversion.

Rooney chasing Ferris.


🎭 Ferris pode fabricar um Rooney

Isso é divertido como conceito.

Um atacante inteligente pode tentar criar pistas para induzir:

overreaction;

culpa interna;

contenção errada;

bloqueio de usuário legítimo.

Isso transforma psicologia defensiva em superfície de ataque.


🧠 Security Operations também tem attack surface

Não apenas ferramentas.

Processos.

Pessoas.

Escalação.

Comunicação.

Pressão.

Tudo pode ser influenciado.

Se um atacante entende como seu SOC trabalha, consegue prever resposta.

Isso é informação valiosa.


📣 Comunicação ruim amplifica viés

War Room com comunicação caótica é terreno fértil.

Mensagens contraditórias.

Hipóteses misturadas com fatos.

Urgência.

Pessoa mais alta falando mais.

Resultado:

certeza falsa.

Por isso é útil separar:

FACTS
HYPOTHESES
ACTIONS
RISKS
UNKNOWN

Visualmente.


🧾 “Fato” precisa ser fato

Exemplo ruim:

“Usuário comprometido.”

Isso já é conclusão.

Melhor:

“Login às 03:14 de novo dispositivo.”

Fato.

Depois:

“Possível comprometimento.”

Hipótese.

Separar isso reduz Rooneyização.


🧠 Unknown é categoria legítima

Muitas equipes odeiam dizer:

“Não sabemos.”

Mas “não sabemos” é honestidade operacional.

Muito melhor que preencher lacuna com certeza falsa.

Rooney não tolera incerteza.

E por isso se complica.


🔴 Overconfidence Bias

Quanto mais especialista alguém se sente, mais pode superestimar certeza.

Veterano olha:

“Já vi isso cem vezes.”

Talvez.

Mas o 101º pode ser diferente.

Experiência ajuda.

Mas também cria atalhos mentais.


☕ O cérebro otimiza investigação

Heurísticas existem por motivo.

Não dá para analisar tudo do zero.

Mas em cenário adversarial, atacante pode explorar padrões do defensor.

Se sabe como o SOC classifica eventos, pode tentar imitar normalidade.

Ou provocar ruído específico.


🤖 Automation Bias: o SIEM disse que é crítico

Agora Rooney ganha dashboard.

O sistema classifica:

SEVERITY: CRITICAL
CONFIDENCE: 98%

Pronto.

A equipe aceita.

Mas:

como score foi calculado?

quais dados?

qual contexto?

falso positivo?

Automation Bias é aceitar recomendação automática sem questionar.

Ferris moderno adoraria isso.


🧠 A máquina também pode ter tunnel vision

Modelos e regras refletem seus dados.

Se detecção procura apenas certos padrões, atacante pode operar fora deles.

O sistema diz:

“Sem ameaça.”

Não significa:

“Sem ataque.”

Assim como Rooney dizer:

“É Ferris.”

Não torna Ferris automaticamente culpado de tudo.


📊 Dashboard verde, incidente vermelho

Blue Team pode ficar tão preso em ferramenta quanto Rooney fica preso em Ferris.

Dashboard não mostra?

Então não existe.

Essa é versão tecnológica do Confirmation Bias.

A realidade não precisa pedir autorização ao SIEM.


🔎 Base Rate Neglect

Outro viés interessante.

Às vezes equipes superestimam evento raro porque parece dramático.

Um alerta com cara de APT recebe toda atenção.

Enquanto causa comum:

configuração;

credencial reutilizada;

erro operacional;

é ignorada.

Red Team pode usar o fascínio pelo sofisticado contra defesa.


👻 O fantasma do “atacante avançado”

Há uma tendência de imaginar adversário como supergênio.

Então qualquer coisa inexplicável vira:

“APT sofisticado.”

Talvez.

Ou talvez seja DNS.

Às vezes DNS.

Rooney quer Ferris mastermind.

Talvez parte do caos seja banal.


🧠 Occam ajuda, mas cuidado

Explicação simples é útil.

Mas não trate como regra absoluta.

O importante é testar.

Não escolher história mais divertida.


🔄 Plan Continuation na resposta

War Room decide:

“Vamos isolar todos os endpoints.”

Depois percebe que impacto está enorme.

Mas continua porque plano já foi anunciado.

Isso é péssimo.

Plano deve ser adaptável.


🧭 OODA Loop

Observe.

Orient.

Decide.

Act.

Depois observe novamente.

O ciclo importa porque mundo muda.

Rooney falha porque faz:

Decide.

Decide.

Decide.

Sem reorientar.


☕ Red Team é adversarial, Blue Team precisa ser adaptativo

Atacante muda.

Defensor precisa mudar também.

Plano rígido morre em contato com realidade.

Ou com Ferris.


🧠 Pre-Mortem

Uma ferramenta útil.

Antes de ação, pergunte:

“Imagine que isso deu muito errado. O que aconteceu?”

Isso força equipe a pensar em consequências.

Antes de bloquear USER123, por exemplo:

que serviços dependem?

que batch quebra?

que API falha?


🧪 Devil’s Advocate

Outra ferramenta.

Alguém recebe tarefa:

provar que hipótese atual está errada.

Não por ego.

Por método.

Isso combate Confirmation Bias.


🔴 Red Team interno na War Room

Quase literal.

Um participante pode agir como red team cognitivo:

questionar premissas;

simular reação adversarial;

buscar evidência contrária.

Isso é extremamente valioso.


🧠 Checklists reduzem impulso

Sob pressão, cérebro esquece.

Checklist ajuda.

Antes de contenção:

preservamos evidência?

entendemos dependências?

definimos objetivo?

sabemos rollback?

quem aprova?

Isso impede Rooney de entrar pela janela.


🪟 Sim, Rooney entrou na casa errada

A metáfora é perfeita.

Ele acredita tanto na própria história que passa a tratar limites como inconvenientes.

Em segurança, a mesma coisa acontece quando alguém pensa:

“O incidente justifica.”

Não.

Incidente não elimina governança.

Talvez adapte.

Mas não transforma qualquer ação em boa decisão.


⚖️ Autoridade operacional precisa de freios

Quem lidera incidente precisa poder agir.

Mas também precisa ser contestável.

Senão crise vira monarquia.

Ferris agradece.


📣 Psychological Safety

Pessoas precisam conseguir dizer:

“Estamos errados.”

Sem medo.

Isso é segurança operacional real.

Uma equipe que não consegue admitir erro acumula erro.


🧠 Ego é superfície de ataque

Essa frase merece destaque.

Se alguém precisa estar certo, atacante pode explorar.

Provocar.

Desafiar.

Alimentar narrativa.

Fazer defensor exagerar.

Rooney não está apenas investigando Ferris.

Está defendendo seu ego.

A partir daí, perde neutralidade.


🔥 Escalation of Commitment

Quanto mais Rooney investe, mais difícil sair.

Escalation of Commitment é irmão do Sunk Cost.

Você continua comprometendo recursos numa decisão ruim.

Não porque evidência melhorou.

Mas porque desistir dói.


☕ “Já chegamos até aqui”

Uma das frases mais perigosas.

Em investigação:

“Já chegamos até aqui, vamos terminar.”

Talvez não.

Se hipótese morreu, mate com dignidade.


📉 Métricas podem piorar

SOC com KPI de “tempo para fechar incidente” pode incentivar Premature Closure.

KPI de “quantidade de incidentes resolvidos” pode incentivar classificações rápidas.

Goodhart visita Rooney.

Métrica vira alvo.

Processo perde qualidade.


🧠 Incentivos também criam viés

Se analista é premiado por encontrar ameaça, talvez veja ameaça demais.

Se é punido por falso positivo, talvez ignore sinais.

Arquitetura cognitiva inclui incentivos.


🦖 Mainframe War Room sem Rooney

Imagine alerta em Db2.

Acesso incomum.

Equipe deveria perguntar:

qual authid?

qual plan?

qual package?

qual origem?

qual horário?

qual contexto?

qual workload?

Não simplesmente:

“Comprometido!”

Detalhe importa.


🔐 RACF e contexto

Evento de SPECIAL é sério.

Mas:

foi mudança planejada?

emergência?

conta break-glass?

atividade histórica?

Sem contexto, ação pode ser errada.

Logs precisam encontrar processo.


🧾 Change Ticket é contexto

Uma mudança estranha às 02h pode ser ataque.

Ou manutenção aprovada.

O SIEM não sabe sozinho.

Por isso integração operacional é valiosa.

Security precisa conhecer mudança.


🧠 Mas cuidado com normalização de desvio

O oposto também existe.

Se tudo estranho vira “mudança”, atacantes passam.

Equilíbrio.

Não aceitar automaticamente.

Verificar.


☕ Defender não é suspeitar de tudo

Isso também é importante.

Paranoia total destrói operação.

Defesa madura trabalha com evidência e risco.

Não com obsessão.

Rooney é exemplo do que acontece quando suspeita vira identidade.


🔵 Blue Team não precisa “vencer”

Essa é uma mudança cultural importante.

O objetivo não é pegar Ferris a qualquer custo.

É proteger sistema.

Se provar que hipótese estava errada evita dano, isso é vitória.

Admitir erro é sucesso.


🧠 Uma War Room madura muda de ideia rápido

Isso é força.

Não fraqueza.

“Com nova evidência, nossa hipótese mudou.”

Excelente.

É exatamente o que deveria acontecer.


🔎 Evidence-Based Incident Response

Fatos.

Linha do tempo.

Hipóteses testáveis.

Contraprovas.

Ações proporcionais.

Esse é o antídoto Rooney.


📜 Timeline ajuda

Monte cronologia.

03:14 login failure
03:15 login success
03:17 query
03:18 MFA approval
03:20 user call

A sequência reduz narrativas inventadas.


🧩 Graph também ajuda

Quem fez o quê?

Que identidade?

Que sistema?

Que recurso?

Visualizar relações pode desmontar tunnel vision.


🤖 IA pode ajudar — e piorar

IA pode resumir logs.

Correlacionar.

Gerar hipóteses.

Mas também pode reforçar viés se o prompt já vier carregado.

“Explique como Ferris comprometeu o sistema.”

A pergunta já presume culpa.

Melhor:

“Quais hipóteses explicam esses eventos?”

Prompt também pode ser Rooney.


🧠 Framing Effect

A forma como pergunta é feita muda resposta.

“Como o atacante entrou?”

pressupõe que houve atacante.

“Qual a causa provável?”

mais aberta.

Isso vale para humanos e modelos.


☕ A pergunta Bellacosa número 1

Na War Room:

“Qual evidência faria a gente abandonar nossa hipótese atual?”

Se resposta for:

“nenhuma”,

isso não é hipótese.

É fé.


🔴 Pergunta número 2

“O que estamos deixando de observar porque estamos olhando para isso?”

Tunnel vision antidote.


🧠 Pergunta número 3

“Nossa resposta está causando mais impacto que o ataque?”

Dói.

Mas salva.


👔 Pergunta número 4

“Alguém discorda do líder?”

Se ninguém discorda nunca, provavelmente existe Authority Gradient.


🔁 Pergunta número 5

“Estamos continuando porque faz sentido ou porque já investimos demais?”

Sunk Cost detector.


🧪 Tabletop Exercise

Esses vieses podem ser treinados.

Simule incidente com pistas contraditórias.

Veja:

quem muda hipótese?

quem insiste?

quem domina conversa?

quem questiona?

Isso é Red Team de processo.


🧠 Cognitive Red Team

Uma ideia poderosa.

Não atacar só infraestrutura.

Atacar decisões.

Apresentar informação ambígua.

Pressão.

Urgência.

Conflito de sinais.

Ver como equipe reage.


🔴 O atacante real não respeita seu modelo mental

Essa é a grande verdade.

Você pode ter playbook excelente.

Atacante pode agir diferente.

Se equipe só reconhece incidentes que parecem com playbook, fica vulnerável.


🧠 Playbook é guia, não escritura sagrada

Procedimentos ajudam.

Mas precisam permitir adaptação.

Rooney transformaria playbook em mandato.

Não faça isso.


☕ Ferris não precisa ser melhor hacker

Ele só precisa entender Rooney.

Essa frase resume muito.

Se atacante sabe que defensor:

reage a autoridade;

odeia ser contradito;

persegue pistas chamativas;

tem medo de parecer indeciso;

então o ataque ganha nova superfície.

Humana.


🎭 Social Engineering contra o SOC

Imagine alguém ligando para SOC:

“Sou diretor. Preciso que bloqueiem imediatamente essa conta.”

Se processo cede à autoridade, pronto.

Blue Team pode ser manipulado para causar DoS.

A engenharia social não mira só Help Desk.

Pode mirar segurança.


🔐 Segurança também precisa ser autenticada

Quem solicita ação crítica?

Como valida?

Qual canal?

Existe dual approval?

O SOC não deveria obedecer qualquer voz convincente.

Nem Rooney.


💣 Defensive DoS

Um atacante pode tentar fazer defesa bloquear usuários legítimos.

Gerar falsos sinais.

Provocar contenção.

Isso é uma forma interessante de denial of service indireto.

A própria segurança executa.


🧠 Alert Fatigue + Confirmation Bias

Se equipe está cansada, tende a usar atalhos.

Vê padrão familiar.

Classifica rápido.

Isso aumenta viés.

Cansaço é fator de risco.


⏰ Turno de madrugada

Menos pessoas.

Mais pressão.

Menos contexto.

Maior chance de decisões apressadas.

Arquitetura operacional precisa considerar isso.


👥 Pair Analysis

Para incidentes críticos, duas pessoas revisando hipótese pode reduzir erro.

Especialmente antes de ação destrutiva.


🧱 Two-Person Rule para contenção crítica

Bloquear domínio inteiro?

Revogar conta sistêmica?

Derrubar produção?

Talvez exigir dupla validação.

Não porque ninguém confia.

Porque crise distorce julgamento.


☕ Ferris, Rooney e o sistema

Até aqui, nossa série tratou Ferris como atacante criativo.

Mas Rooney revela algo igualmente importante:

defensor também pode introduzir risco.

Isso torna segurança fascinante.

Não existe lado puramente racional.

Todo mundo opera sob informação incompleta.


🧠 Humildade operacional

Uma das melhores características de um bom analista é conseguir dizer:

“Posso estar errado.”

Isso mantém espaço para correção.

Rooney não consegue.

E paga caro.


🔵 Blue Team excelente não é o que nunca erra

É o que detecta o próprio erro rápido.

Recalibra.

Preserva evidência.

Adapta.

Isso é resiliência.


🧠 Feedback Loop

A investigação precisa de feedback.

Ação produz resultado.

Resultado atualiza hipótese.

Se não atualiza, você está só executando ritual.


🔄 Closed Loop Response

Observe
 ↓
Hypothesis
 ↓
Action
 ↓
Measure
 ↓
Reassess

Isso combate Plan Continuation Bias.


🧠 O pior playbook: “eu sabia”

Se depois de tudo a equipe conclui:

“Eu sabia desde o começo”,

cuidado.

Hindsight Bias chegou.

Depois do evento, tudo parece óbvio.

Mas não era.


🕰️ Hindsight Bias

Depois que incidente é entendido:

“Como ninguém viu?”

Porque antes havia centenas de sinais.

Agora escolhemos os três relevantes.

Não humilhe quem não tinha visão futura.

Aprenda.


☕ Postmortem sem caça às bruxas

O objetivo é entender sistema.

Não achar Rooney culpado.

Mesmo Rooney é produto de cultura.

Pressão.

Autoridade.

Incentivos.

Postmortem bom pergunta:

o que tornou essa decisão provável?


🧀 Swiss Cheese também vale para decisões

Viés individual.

Pressão.

Falta de challenger.

Métrica ruim.

Autoridade.

Playbook rígido.

Buracos alinham.

Blue Team vira incidente.


🧠 A cadeia completa

Alerta ambíguo
 ↓
Hipótese precoce
 ↓
Confirmation Bias
 ↓
Authority Gradient
 ↓
Plan Continuation
 ↓
Sunk Cost
 ↓
Ação destrutiva
 ↓
Incidente ampliado

Ferris quase nem aparece.

Rooney faz tudo sozinho.


🎬 Rooney entrou na casa errada

Essa é a beleza narrativa.

Ele acredita estar investigando uma transgressão.

Mas, no processo, começa a transgredir.

Perde perspectiva.

Cruza limites.

A investigação se torna parte do caos.

Essa é a metáfora perfeita para resposta a incidente mal conduzida.


☕ Epílogo: o defensor também precisa de defesa

Nós gastamos fortunas protegendo:

servidores;

identidades;

redes;

mainframes;

APIs.

Mas talvez precisemos proteger também o processo decisório.

Contra:

ego;

pressão;

certeza excessiva;

viés;

hierarquia;

urgência.

Porque atacante não explora apenas software.

Explora comportamento.

Inclusive comportamento do defensor.

Rooney nos ensina que uma certeza forte demais pode ser mais perigosa que uma hipótese fraca.

Que continuar não é necessariamente coragem.

Que autoridade não substitui evidência.

Que resultado bom não transforma decisão ruim em boa.

E que, às vezes, a maior ameaça dentro da War Room é alguém gritando:

“EU SEI QUE É O FERRIS!”

enquanto todo mundo ao redor para de perguntar se isso ainda faz sentido.

Então, da próxima vez que o alerta disparar, antes de invadir a casa errada, pergunte:

O que sabemos?

O que estamos inferindo?

O que contradiz nossa hipótese?

Quem pode nos dizer que estamos errados?

Nossa resposta é proporcional?

Se ninguém conseguir responder...

talvez o Ferris nem precise mais atacar.

O Blue Team já começou.

SAVE FERRIS.

No próximo artigo:

FerrisGPT — Agora o Adolescente Tem um Exército de Estagiários Sintéticos

Porque se Ferris já era perigoso com um telefone, um computador e Cameron...

imagine quando ele ganha agentes, voz sintética, automação e IA generativa.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...