☕ 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

sábado, 2 de setembro de 2017

Um Teatro de rua com marionetes em Florença

Habilidade com as marionetes

Vou contar um segredo para você que acompanha meu blog, eu sou fascinado pelos show de ruas, este meio fascínio começou no final da década 1980. Nesta época comecei a trabalhar como office-boy e devido a minha desenvoltura e sociabilidade. Consegui a melhor região para se trabalhar, eu tinha como área de atuação o centro velho de São Paulo e a Avenida Paulista.

A minha atividade consistia em entregar e retirar documentos, ir a bancos, atender as necessidades do escritório na compra de pequenos materiais, lanches e etc. Na minha rota de trabalho incluía a Secretaria da Fazenda e Bolsa de Valores, estes dois locais ficavam entre grandes praças e jardins no centro velho.

Nestas praças eu assistia diversos show de rua: mágicos, cantores, malabaristas, pintores de azulejos e garrafas, homem da banha da cobra, camelôs em suas barracas animadas e mesmo os trombadinhas assaltando pessoas desavisadas.

Falei tudo isso, para chegar no ponto que na Itália foram tantos shows de ruas, artistas de diversos países do mundo, escolheram este país como seu palco, este pequeno vídeos vemos um show de marionetes, veja a habilidade deste homem, consegue manipular vários bonecos ao mesmo tempo e sempre ao ritmo da musica, veja a quantidade de pessoas fotografando e filmando este show.




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.

☕ Um Café no Bellacosa Mainframe — Especial Red Team

SAVE FERRIS — Ferris Bueller’s Red Team

Uma série de 12 artigos sobre Red Team, segurança ofensiva, engenharia social, OSINT, integridade de dados, MFA, PAM, rollback, Blue Team, inteligência artificial, RACF e z/OS, usando Ferris Bueller para explorar uma pergunta fundamental: o sistema está realmente seguro ou apenas acredita que está?

  • Red Team
  • OSINT
  • Engenharia Social
  • Blue Team
  • MFA
  • PAM
  • IA Generativa
  • RACF
  • z/OS
  • Mainframe
1

Ferris Bueller Tinha um Plano de Ataque — Red Team Antes de Existir Red Team

Reconhecimento, criatividade adversarial e a ideia de que o verdadeiro alvo nem sempre é a tecnologia: são as suposições de quem construiu o sistema.

Red Team • Recon • Threat Modeling • Criatividade Adversarial
2

Nove Faltas? CTRL+Z — Quando o Banco de Dados Decide o que é Verdade

Integridade de dados, alteração de registros, privilégio, auditoria e a perigosa diferença entre aquilo que aconteceu e aquilo que o banco de dados afirma ter acontecido.

Integridade • Db2 • Auditoria • Insider Threat • Dados
3

Abe Froman, o Rei da Salsicha de Chicago — A Aula de Engenharia Social que Ninguém Percebeu

Pretexting, autoridade inventada e confiança contextual: Identity, Authentication e Authorization não são a mesma coisa.

Engenharia Social • Pretexting • Identity • Authentication
4

“Você Conhece o Diretor Rooney?” — OSINT Antes do Google Existir

Como dados públicos sobre pessoas, tecnologias, hábitos, empresas e relacionamentos podem revelar uma superfície de ataque antes do primeiro scan.

OSINT • Recon • LinkedIn • GitHub • Attack Surface
5

Cameron, Atenda o Telefone — Social Engineering as a Service

Ferris → Cameron → telefone → escola → funcionário → sistema. Nenhuma peça precisa falhar sozinha quando a cadeia inteira possui uma combinação explorável de confiança.

Social Engineering • Swiss Cheese Model • Human Risk
6

O Diretor Rooney Está Procurando Malware no Lugar Errado

Firewall, SIEM, EDR e Zero Trust podem funcionar perfeitamente enquanto engenharia social, Help Desk e processos humanos criam outro caminho até o objetivo.

SOC • SIEM • EDR • Zero Trust • Engenharia Social
7

A Ferrari do Cameron Não Tinha MFA

Privilégio, acesso físico, MFA, PAM, least privilege e o risco de proteger um ativo crítico apenas com medo, confiança e a esperança de que ninguém ousará tocá-lo.

MFA • PAM • Least Privilege • Privileged Access
8

Colocamos a Ferrari em Ré — Por Que Rollback Não É Backup

Rollback, restore, journaling, logs, Db2, VSAM e recuperação: voltar o estado de um sistema não significa apagar as consequências daquilo que aconteceu.

Backup • Restore • Rollback • Db2 • VSAM • Recovery
9

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

Confirmation Bias, tunnel vision, Sunk Cost, Authority Gradient e o risco de uma resposta defensiva criar mais impacto que o próprio atacante.

Blue Team • SOC • Cognitive Bias • Incident Response
10

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

IA generativa, agentes, OSINT automatizado, deepfake, voice cloning e automação transformam o ataque artesanal em uma capacidade paralela e escalável.

Generative AI • Agents • Deepfake • Voice Cloning • OSINT
11

Ferris Entra no Mainframe — RACF, z/OS e o Dia em que SPECIAL Virou o Passe para Chicago

RACF, SAF, ACEE, APF, USS, TSO, CICS, Db2, MQ, z/OS Connect, Zowe e service accounts vistos pela ótica dos caminhos de ataque até o mainframe.

Mainframe • RACF • z/OS • CICS • Db2 • MQ • Zowe
12

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

Red Team não termina em “conseguimos entrar”. Ataque deve gerar descoberta, evidência, correção, detecção e aprendizado para deixar a organização mais resiliente.

Red Teaming • Purple Team • Detection • Resilience • Learning

🎬 Página principal da temporada

Ferris Bueller’s Red Team: Como Hackear o Sistema Sem Precisar Roubar a Ferrari do Cameron reúne os doze episódios e conecta Red Team, engenharia social, IA, Blue Team e segurança de mainframe.

☕ Acessar o especial completo SAVE FERRIS

Sobre a série SAVE FERRIS — Red Team

A série SAVE FERRIS, publicada no Bellacosa Mainframe, utiliza situações inspiradas em Ferris Bueller para explicar conceitos de Red Team, cybersecurity, segurança ofensiva, engenharia social, OSINT, Blue Team, Purple Team, Zero Trust, MFA, PAM, inteligência artificial, RACF, IBM z/OS, CICS, Db2, MQ e segurança de mainframe.

O fio condutor é simples: um atacante não precisa necessariamente quebrar a tecnologia. Ele pode explorar relações de confiança, processos, identidades, privilégios, integrações e suposições existentes entre pessoas e sistemas.

A temporada acompanha o ciclo completo: reconhecimento → engenharia social → acesso → privilégio → impacto → detecção → correção → aprendizado.

Para Red Teams e Blue Teams, o objetivo final não é provar quem é mais inteligente, mas encontrar caminhos invisíveis antes que um adversário real os descubra.

Arte em Florença: Marionetas em show de rua

Marionetas cantando e dançando em frente a Basílica de Santa Cruz

Em novembro de 2012 tive a oportunidade de conhecer a cidade mais famosa do mundo, em meus mais de 10 anos,  vivendo na Comunidade Europeia, nunca tinha visitado uma cidade com tanto turista. Olha que visitei a maior parte das capitais e mesmo assim me surpreendi. Em todos os lugares que visitava, tinha uma aglomerado de pessoas, longas filas para visitar igrejas, palácios e monumentos.

Era tudo a maior alegria grupos de turistas japoneses fotografando os mínimos detalhes, turistas latinos fazendo o maior barulho e jovens aproveitavam para paquerar e namorar, cada tribo no seu espaço.

Neste dia estive visitando a Basílica de Santa Cruz, belíssima igreja que foi utilizada como Panteão municipal, então em seu interior existe diversos sarcófagos em mármores, obras primas da arte fúnebre.

Após sair da Basílica, ouço uma musica alta e ao longe vejo um aglomerado de pessoas, fico imaginando que show de rua, estará acontecendo naquele local. Desviando de máquinas e equipamentos, pois a praça estava em obras de manutenção.

Chego ao local e vejo um divertido show de marionetas, o artista domina os bonecos com grande maestria, suas marionetas cantam e dançam ao ritmo da música, brincam com as pessoas, interagindo divertidamente naquele final do dia.



quinta-feira, 31 de agosto de 2017

Um harpista maluco no museu Pavilhão do Conhecimento

Um museu interativo e muito educativo


Visitar o Museu de Ciências e Tecnologia de Lisboa é uma verdadeira aventura lúdica, conhecido como o Pavilhão do Conhecimento tem em seu interior diversas experiencias que encantam miúdos e graúdos.

São diversas salas para se explorar, desde uma casa em construção em que os pequeninos se transformam em Lego, até um carro com rodas quadradas e dentadas, sem contar as diversas ilusões de ótica,  princípios de magnetismo, simulação de falta de gravidade, tirolesas e tantas outras coisas que fica difícil elencar.

Neste pequeno vídeo estou brincando com meu filho numa Harpa a laser, os sensores identificam seus movimentos e toca sons de harpa. Neste instrumento unico, o pai e o barbinha estão tentando fazer a harpa tocar... nossa que dificuldade acertar as cordas invisíveis... quem visitou o museu de tecnologia no parque da Expo deve ter experimentado este divertido experimento. E ficado maluco com estas atrações, traga seu pequeno cientista e divirta-se no museu.

Caminhe pelo parque da Expo, sinta a deliciosa brisa refrescante do Rio Tejo, ande de teleférico, veja a Torre Vasco da Gama, visite os jardins e encontre os bichos escondidos, veja a replica da Catedral de Macau em tamanho natural, tome um sorvete na esplanada das bandeiras, aproveite bem o dia em família.





quarta-feira, 30 de agosto de 2017

A Estação Ferroviária de Jundiaí

Memoria Ferroviária:  O entroncamento de Jundiaí

A estação ferroviária de Jundiaí esta funcionando desde o seculo XIX e ela é um daqueles tesouros arquitetônicos que guardam a memoria de nossa terra. Foi construída para receber os passageiros da linha Santos - Jundiaí, no auge da imigração foi ponto de chegada de milhares de imigrantes em busca de um futuro melhor.e em suas proximidades também serviu para abrigar os galpões de carga que serviam para armazenar o cafe que estava sendo exportado por via do Porto de Santos. 

Esta estação foi testemunha do crescimento da cidade, passou por grandes mudanças, o ciclo do cafe chegou ao fim, as locomotivas a vapor foram substituídas pelas elétricas, posteriormente por diesel e hoje elétricas novamente. Viu o transporte ferroviário de passageiros sumir do mapa.

Nesta região serviu de entroncamento com diversas ferrovias hoje extintas: Itatibense, Ytuana, Mogiana, Sorocabana, Bragantina, Fepasa, RFFSA. Por alguns anos ficou abandonada e seus prédios outrora majestosos começaram a ruir, quando os olhos dos dirigentes políticos voltaram fizeram algumas reformas, mas seu destino é incerto, enquanto o transporte ferroviário não for respeitado esta bela estação com seus mai de 150 anos corre perigo.

Divulgue o vídeo e ajude a proteger a histórica Estação Ferroviária de Jundiaí.





terça-feira, 29 de agosto de 2017

A Estação Ferroviária de Francisco Morato

Memoria Ferroviária: Estação de Francisco Morato - SPR (São Paulo Railways)

A cidade de Francisco Morato deve seu surgimento há um acampamento e canteiro de obras da antiga São Paulo Railways, nesta região existem diversas colinas que bloqueavam a passagem da ferrovia rumo a Jundiaí,

Neste contexto surgiu a necessidade de construir uma obra de arte da engenharia paulista no século XIX, um túnel que encurtaria a distância no projeto, ligando o interior do estado mais rapidamente, com isso os engenheiros projetaram este trecho e milhares de operários se deslocaram para esta região e com pás e picareta construíram este túnel.

Trabalhando incansavelmente concluíram a obra e a ferrovia prosseguiu, mas as benfeitorias, as diversas casinhas e o ponto estratégico para abastecer de água as locomotivas a vapor, fizeram a vila crescer, atraindo mais famílias para estas bandas, o resto foi consequência e vocês conhecem e virou o município de Francisco Morato. Curiosamente as locomotivas a vapor carregavam pouca água, de modo a minimizar o peso e maximizar o empuxo, mais ou menos a autonomia eram 50 quilômetros, por isso a distância máxima entre estações nunca excedia o 40 quilômetros, assim sempre que paravam nas estações o caldeirista completava o tanque com água.

O Formiguinha ficou encantado de ver as plataformas da ferrovia, explorou as catracas de entrada e saída, ficou esperando chegar uma composição ferroviária e até se assustou com a buzina do trem, E ainda acompanhou as obras da futura estação de Morato.


segunda-feira, 28 de agosto de 2017

A oficina ferroviária da Companhia Paulista no incio do século XX

Um dia normal nas oficinas ferroviárias da Companhia Paulista

Este é o terceiro de vídeo produzido em Jundiaí para divulgar as riquezas desta cidade histórica, o primeiro tratava sobre a produção de café em uma Fazenda Cafeicultura, o segundo tratava da produção das uvás e este terceiro capitulo fala sobre a Companhia Paulista de Estrada de Ferros.

Inicia mostrando uma locomotiva elétrica trafegando no trecho entre Jundiaí e Campinas, muito provável que nesta época Louveira, Vinhedo e Valinhos eram apenas distritos pertencendo a estas duas cidades.

Voltando ao vídeo estamos chegando nas oficinas gerais, hoje este complexo esta em processo de tombamento sendo utilizado como campus da FATEC, Poupa tempo do Município, Biblioteca Técnica e Arquivo Histórico da Ferrovia e Museu Ferroviário.

Prestem a atenção no vestuário da época, o trabalho de revisão, manutenção e construção de locomotiva a vapor, o processo desmontagem, as peças separadas, os operários trabalhando, os escritórios administrativos, o final de expediente com os funcionários saindo e batendo o ponto em um relógio de ponto, fios de telégrafos e linhas elétricas muitas destas ferramentas estão obsoletas e não existem mais.

O Museu Casa Solar do Barão

Um tesouro escondido na casa-museu Barão de Jundiahy. Nesta casa diversos objetos históricos estão em exibição, mas o verdadeiro tesouro esta escondido numa sala dos fundos. 

Um sala-cinema onde esta sendo exibido um vídeo histórico com os trabalhadores da companhia paulista em seu dia a dia, desde a chegada de uma locomotiva ate a sua completa desmontagem para manutenção, ate o chefe dos serviços aparecem e os funcionários encerram suas atividades batendo o ponto.

 Não percam o belo jardim com uma ponte japonesa e lâmpadas oriental num lago com carpas.



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...