E se o problema não estiver no alerta?

Em segurança cibernética, existe uma pergunta aparentemente simples:

O que estamos protegendo?

Sistemas? Dados? Credenciais? Infraestrutura? Aplicações?

A resposta mais interessante talvez seja:

Estamos protegendo relações.

Uma credencial se relaciona com uma identidade.

Uma identidade se relaciona com um dispositivo.

Um dispositivo se relaciona com uma rede.

Uma aplicação se relaciona com dados.

Um dado pode revelar comportamento.

E um comportamento, quando combinado com outros sinais, pode revelar um ataque.

É nesse ponto que Cybersecurity deixa de ser apenas uma coleção de ferramentas e passa a ser capacidade de raciocínio.

1. O princípio antes da ferramenta

Os princípios fundamentais de Cybersecurity são frequentemente apresentados através da tríade CIA:

• Confidentiality — Confidencialidade
• Integrity — Integridade
• Availability — Disponibilidade

Em um ambiente bancário, entretanto, esses princípios não existem isoladamente.

Imagine uma aplicação financeira funcionando normalmente.

A disponibilidade está preservada.

Mas um atacante conseguiu alterar um parâmetro antes do processamento de uma operação.

A aplicação continua disponível.

Porém, a integridade foi comprometida.

Agora imagine que nenhuma informação tenha sido alterada, mas credenciais legítimas tenham sido obtidas por engenharia social.

A confidencialidade pode estar ameaçada.

Isso conduz a uma reflexão:

Um sistema estar funcionando significa que ele está seguro?

Não necessariamente.

Segurança não pode ser confundida com disponibilidade.

2. Sistema operacional: onde a aplicação realmente vive

Uma aplicação não existe no vácuo.

Ela depende de:

Aplicação
 ↓
Runtime / Bibliotecas
 ↓
Sistema Operacional
 ↓
Processos
 ↓
Memória
 ↓
Sistema de arquivos
 ↓
Rede
 ↓
Infraestrutura

Por isso, conhecer sistemas operacionais é também compreender segurança.

Permissões, processos, serviços, usuários, logs, atualizações, arquivos e conexões de rede podem produzir sinais importantes para uma investigação.

Um comportamento isolado pode parecer irrelevante.

Uma sequência de comportamentos pode ser outra história.

3. Máquina virtual: laboratório ou nova superfície de ataque?

Máquinas virtuais são excelentes para aprendizagem, testes e ambientes controlados.

Mas existe uma armadilha conceitual:

Virtualizar não significa automaticamente tornar seguro.

Uma VM ainda possui:

• sistema operacional;
• aplicações;
• serviços;
• credenciais;
• interfaces de rede;
• armazenamento;
• configurações;
• vulnerabilidades.

E existe ainda uma camada adicional:

Hardware
 ↓
Host
 ↓
Hypervisor
 ↓
Guest / VM
 ↓
Aplicação

Portanto, a virtualização cria isolamento, mas também introduz novas relações que precisam ser compreendidas.

Em um laboratório bancário simulado, isso permite estudar ataques e defesas sem utilizar dados reais.

Controle de ambiente é parte da segurança.

4. Coleta: o primeiro erro é coletar sem saber por quê

Coletar dados não é o mesmo que produzir inteligência.

Logs, eventos de autenticação, conexões, processos, indicadores de rede e informações de aplicações podem ser úteis.

Mas quantidade não significa qualidade.

Imagine:

10.000 eventos
      ↓
    dados
      ↓
 filtragem
      ↓
  contexto
      ↓
  correlação
      ↓
   hipótese
      ↓
  investigação

O desafio não é simplesmente encontrar um evento.

É descobrir qual evento merece atenção.

Essa diferença separa monitoramento de investigação.

5. OSINT e engenharia social: o ataque pode começar fora do banco

Nos estudos anteriores, OSINT apareceu como uma forma de buscar informações utilizando fontes abertas.

Isso possui uma relação direta com engenharia social.

Um atacante pode não começar tentando explorar tecnicamente um sistema.

Pode começar tentando compreender pessoas, processos e contexto.

Informações públicas podem revelar:

• estrutura organizacional;
• tecnologias utilizadas;
• cargos;
• fornecedores;
• padrões de comunicação;
• informações sobre projetos;
• documentos publicados;
• relacionamentos entre pessoas e organizações.

Nenhuma dessas informações precisa ser, isoladamente, uma vulnerabilidade.

O problema pode surgir da combinação.

E aqui aparece uma das ideias centrais deste debate:

Informação pública pode se transformar em vantagem privada quando é correlacionada.

6. O fator humano não é o “elo fraco” por definição

É comum ouvir:

“O usuário é o elo mais fraco.”

Essa afirmação merece ser questionada.

Se uma pessoa recebe uma mensagem cuidadosamente construída, baseada em informações reais sobre seu ambiente de trabalho, o problema pode não estar simplesmente em sua atenção.

Pode existir uma cadeia:

OSINT
↓
Contexto
↓
Engenharia social
↓
Credencial comprometida
↓
Acesso legítimo
↓
Comportamento anômalo
↓
Evento técnico

Nesse cenário, o ataque atravessa áreas diferentes.

Começou como informação.

Passou por comportamento.

Terminou como evento técnico.

É exatamente por isso que segurança precisa pensar de forma multidisciplinar.

7. DevSecOps: segurança não deveria entrar no final

Existe uma pergunta importante:

Por que descobrir um problema de segurança somente depois que o software chegou ao ambiente produtivo?

DevSecOps propõe incorporar segurança ao ciclo de desenvolvimento.

Uma visão simplificada:

Planejamento
   ↓
Desenvolvimento
   ↓
Testes
   ↓
Segurança
   ↓
Deploy
   ↓
Monitoramento
   ↓
Feedback
   ↺

A segurança deixa de ser uma etapa final de aprovação e passa a fazer parte do ciclo.

Isso muda a mentalidade:

não é “desenvolver primeiro e proteger depois”.

É:

desenvolver considerando segurança desde o início.

No setor bancário, essa mentalidade é especialmente relevante porque software, dados, disponibilidade, identidade e confiança estão profundamente conectados.

8. Cenário: 09h17

Imagine um ambiente bancário simulado.

Às 09h17, surge um alerta de autenticação incomum.

Nada parece conclusivo.

O acesso utilizou uma credencial válida.

O sistema respondeu normalmente.

Não existe, naquele momento, evidência suficiente para afirmar que ocorreu um ataque.

Então aparecem outros sinais.

Um evento de rede.

Depois uma alteração incomum em uma aplicação.

Em seguida, uma atividade que não corresponde ao padrão esperado daquele usuário.

Agora temos:

Identidade
 +
Sistema
 +
Rede
 +
Aplicação
 +
Comportamento

A pergunta muda.

Não é mais:

“Qual desses eventos é suspeito?”

Passa a ser:

“Esses eventos podem fazer parte da mesma história?”

9. Evidência, inferência ou hipótese?

Aqui entra uma disciplina fundamental para análise de segurança.

Evidência

Aquilo que foi observado.

Exemplo:

Foi registrado um evento de autenticação.

Inferência

Conclusão razoável derivada das evidências.

Exemplo:

O comportamento diverge do padrão observado.

Hipótese

Explicação possível que ainda precisa ser investigada.

Exemplo:

A credencial pode ter sido comprometida.

A diferença parece pequena.

Não é.

Confundir hipótese com evidência pode transformar uma investigação em conclusão precipitada.

E segurança precisa trabalhar justamente contra esse tipo de erro.

10. O conceito de correlação

É aqui que os temas começam a convergir.

OSINT
│
├── contexto
│
Engenharia Social
│
├── comportamento
│
Identidade
│
├── autenticação
│
Sistema Operacional
│
├── processos / logs
│
Rede
│
├── conexões
│
Aplicação
│
└── eventos
      ↓
   CORRELAÇÃO
      ↓
   CONTEXTO
      ↓
   INVESTIGAÇÃO

O objetivo não é simplesmente produzir mais alertas.

É buscar relações entre sinais de diferentes domínios.

11. Mas existe um problema: correlação também pode enganar

Se dois eventos acontecem próximos no tempo, isso não significa necessariamente que exista relação causal.

Essa é uma armadilha importante.

Evento A
   +
Evento B
   ↓
Correlação?
   ↓
Investigação

Não:

Evento A + Evento B = ataque confirmado

Por isso, um sistema de segurança inteligente precisa preservar a diferença entre:

sinal → correlação → hipótese → evidência adicional → conclusão

Essa disciplina evita transformar automação em falsa certeza.

12. Onde entra a IA?

A IA pode ajudar a encontrar padrões, classificar eventos, resumir informações e apoiar investigação.

Mas existe uma pergunta mais importante:

Quem valida a conclusão?

Um modelo pode sugerir uma relação.

Isso não transforma automaticamente a relação em fato.

No ambiente bancário, a combinação entre IA, dados e Cybersecurity precisa considerar:

• qualidade dos dados;
• contexto;
• rastreabilidade;
• explicabilidade;
• controle;
• validação humana;
• segurança do próprio sistema de IA.

É por isso que segurança de IA e segurança cibernética começam a se aproximar.

13. E se o atacante usar ferramentas legítimas?

Outro ponto provocativo:

Nem todo comportamento malicioso parece tecnicamente malicioso.

Um atacante utilizando credenciais válidas pode parecer um usuário legítimo.

Uma ferramenta administrativa pode ser utilizada por um administrador legítimo — ou abusada por alguém que obteve suas credenciais.

Um serviço pode estar funcionando exatamente como foi projetado.

O problema pode estar no contexto de utilização.

Portanto:

Segurança não é apenas perguntar “o que aconteceu?”. É perguntar “quem fez, quando, onde, por quê e o que aconteceu antes e depois?”.

14. O verdadeiro laboratório é o raciocínio

É possível criar um laboratório gigantesco com dezenas de ferramentas.

Mas isso não garante compreensão.

Também é possível criar um cenário pequeno, controlado e sintético, e utilizá-lo para demonstrar:

• princípios de segurança;
• análise de sistemas;
• redes;
• coleta;
• OSINT;
• engenharia social;
• correlação;
• DevSecOps;
• análise de evidências;
• hipóteses;
• tomada de decisão.

Isso leva a uma conclusão importante:

Capacidade técnica não é medida apenas pela quantidade de ferramentas utilizadas, mas pela qualidade das perguntas que conseguimos fazer com elas.