E se o dado que você usa para encontrar uma anomalia também puder ser usado por um atacante para encontrar você?

Essa pergunta muda completamente a forma de enxergar Análise de Dados e Cibersegurança.

Ao estudar bibliotecas como Pandas, NumPy e Matplotlib, é fácil pensar que estamos apenas aprendendo a manipular DataFrames, calcular médias, agrupar informações ou construir gráficos.

Mas existe uma camada mais interessante por trás disso.

Em um ambiente bancário, dados podem representar transações, acessos, comportamentos, eventos de sistemas, chamados, indicadores operacionais ou sinais de segurança.

E quando esses dados são analisados corretamente, eles deixam de ser apenas números.

Eles passam a contar uma história.

O problema é que um defensor não é o único interessado nessa história.

Blue Team: o dado como sensor

Imagine um conjunto de eventos de autenticação.

Isoladamente, cada registro pode parecer normal.

Um acesso daqui.

Uma tentativa dali.

Uma alteração de cadastro.

Uma transação fora do horário habitual.

Agora agrupe os eventos.

Compare períodos.

Observe frequências.

Procure desvios.

Visualize.

De repente, aquilo que parecia ruído pode começar a apresentar um padrão.

É aqui que ferramentas de análise de dados ganham importância para o pensamento de Blue Team.

Pandas pode organizar e filtrar eventos.

NumPy pode apoiar cálculos e transformações numéricas.

Matplotlib pode transformar resultados em visualizações capazes de facilitar a percepção de tendências e comportamentos fora do esperado.

Mas existe uma armadilha:

anomalia não é sinônimo de ataque.

Um comportamento diferente pode ter uma explicação legítima.

Por isso, segurança não deveria funcionar como uma máquina de acusações, mas como um processo de investigação baseado em evidências.

Purple Team: quando o alerta precisa virar aprendizado

É aqui que o raciocínio fica mais interessante.

O Purple Team aproxima ataque e defesa.

O Red Team pergunta:

“Como eu poderia explorar isso?”

O Blue Team pergunta:

“Como eu perceberia isso?”

O Purple Team pergunta:

“O que aprendemos quando colocamos os dois cenários em contato?”

Essa mudança de perspectiva é poderosa.

Um cenário de teste pode gerar eventos.

Esses eventos podem ser analisados.

A análise pode revelar um padrão.

O padrão pode gerar uma hipótese.

A hipótese pode ser confrontada com novas evidências.

E o resultado pode voltar para a defesa como melhoria.

Isso transforma dados em um ciclo de aprendizagem.

Red Team: o atacante também pensa em dados

Agora vem a parte desconfortável.

O atacante não precisa necessariamente invadir diretamente o core bancário para causar impacto.

Ele pode procurar credenciais.

Explorar vulnerabilidades.

Abusar de terceiros.

Manipular pessoas.

Coletar informações aparentemente inofensivas.

E combinar essas informações.

Em agosto de 2026, a Reuters reportou uma onda de ataques contra empresas financeiras dos Estados Unidos em que criminosos utilizaram ligações telefônicas e engenharia social, inclusive se passando por suporte de TI para tentar obter credenciais e códigos de autenticação.

O caso de Apollo Global Management mostra como esse vetor pode atingir diretamente o setor financeiro: a empresa informou que sofreu uma violação entre 6 e 10 de julho, com acesso não autorizado a determinadas plataformas de nuvem e exposição de informações pessoais.

A provocação aqui é simples:

Quanto mais contexto o atacante consegue reunir, menos precisa depender de um ataque “barulhento”.

O banco não termina no banco

Outro aprendizado de 2026 é que a superfície de ataque não precisa estar dentro do prédio, nem necessariamente dentro da infraestrutura principal da instituição.

Em março de 2026, o Standard Bank of South Africa comunicou um incidente envolvendo acesso não autorizado a determinados dados pessoais e posteriormente publicou atualizações sobre o caso.

Em julho, a Reuters reportou que dados de clientes e documentos internos do Bank of Baroda haviam sido expostos na dark web, segundo uma fonte familiarizada com o assunto e um pesquisador de segurança.

Esses casos reforçam uma questão fundamental:

Onde termina o ambiente bancário?

No servidor?

Na aplicação?

No fornecedor?

Na nuvem?

No e-mail corporativo?

No dispositivo do funcionário?

No parceiro que processa alguma etapa?

Na pessoa que atende o cliente?

Talvez a resposta correta seja:

o perímetro é o ecossistema.

E isso muda a estratégia de defesa.

O gráfico não entende o contexto

Aqui voltamos ao ponto inicial da análise de dados.

Um gráfico pode mostrar uma concentração anormal de eventos.

Mas ele não sabe automaticamente por que aquilo aconteceu.

Uma elevação pode representar um ataque.

Pode representar uma mudança operacional.

Pode ser manutenção.

Pode ser uma campanha legítima.

Pode ser erro de integração.

Pode ser dado duplicado.

Pode ser problema de qualidade.

Portanto:

visualização ≠ conclusão.

O gráfico apresenta evidência.

O analista constrói uma hipótese.

A investigação procura novas evidências.

E somente então uma conclusão pode ganhar sustentação.

Essa diferença parece pequena.

Em segurança, ela é gigantesca.

E se o Red Team atacar o próprio modelo?

Existe ainda uma camada mais nerd dessa discussão.

Se utilizamos dados para detectar comportamentos suspeitos, precisamos perguntar:

e se o atacante tentar manipular os próprios sinais que estamos observando?

Isso leva a perguntas sobre:

• qualidade e integridade dos dados;
• eventos ausentes;
• dados duplicados;
• falsos positivos;
• falsos negativos;
• manipulação de registros;
• comportamento adversarial;
• dependências de terceiros;
• exposição de informações utilizadas pelos mecanismos de detecção.

O problema deixa de ser simplesmente:

“Consigo detectar uma anomalia?”

E passa a ser:

“Consigo confiar na evidência que está alimentando minha detecção?”

Essa é uma pergunta muito mais perigosa.

E muito mais interessante.

Do dado isolado à correlação

É aqui que entra uma ideia que considero especialmente relevante para sistemas bancários cognitivos.

Uma transação isolada pode não significar nada.

Um login isolado pode não significar nada.

Uma alteração cadastral isolada pode não significar nada.

Um chamado de suporte isolado pode não significar nada.

Mas e quando diferentes domínios começam a apresentar sinais relacionados?

Transação + autenticação + dispositivo + horário + comportamento + evento de segurança.

A pergunta deixa de ser:

“Esse evento é suspeito?”

E passa a ser:

“O que esses eventos estão dizendo quando analisados juntos?”

Isso é correlação multidomínio.

E também é onde análise de dados, engenharia de software, inteligência artificial e cibersegurança começam a se encontrar.

A defesa não deveria esperar o incidente para aprender

O relatório de 2026 da Verizon traz uma provocação importante para esse debate: a exploração de vulnerabilidades passou a representar 31% das violações analisadas no DBIR, superando credenciais roubadas como vetor inicial mais comum.

O número é importante.

Mas a pergunta mais importante talvez seja outra:

quantos sinais existiam antes do incidente?

Uma vulnerabilidade conhecida.

Um acesso incomum.

Uma configuração inadequada.

Uma credencial exposta.

Um comportamento diferente.

Uma alteração inesperada.

Um fornecedor comprometido.

Um usuário enganado.

A segurança madura tenta enxergar a sequência, não apenas o último evento.

Python não é o herói

Existe uma tentação comum quando aprendemos uma nova tecnologia:

transformar a ferramenta no protagonista.

Mas Python não detecta “o mal”.

Pandas não sabe o que é fraude.

NumPy não sabe o que é um atacante.

Matplotlib não sabe o que é uma ameaça.

A tecnologia executa operações.

Quem transforma resultado em conhecimento é o processo de análise.

E esse processo precisa considerar contexto, qualidade dos dados, hipóteses alternativas e evidências.

Por isso, talvez o verdadeiro aprendizado dessas bibliotecas não esteja em memorizar .groupby(), .describe(), .count() ou plt.show().

Está em aprender a perguntar:

“O que este resultado realmente significa?”

Reflexão

Grandes vazamentos de dados não deveriam ser analisados apenas pelo tamanho do vazamento.

A pergunta mais interessante é:

o que um atacante consegue construir a partir dos fragmentos expostos?

Um dado pode parecer inútil sozinho.

Mas dados combinados podem formar contexto.

Contexto pode formar perfil.

Perfil pode facilitar engenharia social.

Engenharia social pode abrir portas.

E uma porta aberta pode transformar um pequeno sinal em um grande incidente.

Por isso, no contexto bancário, talvez a segurança do futuro não seja apenas uma questão de bloquear ataques.

Talvez seja uma questão de correlacionar sinais antes que eles formem uma história favorável ao atacante.

🔵 Blue Team: observar e detectar.

🔴 Red Team: desafiar e explorar.

🟣 Purple Team: transformar ataque em aprendizado.

Dados + IA: encontrar relações que poderiam passar despercebidas.

Banco: conectar tudo isso sem esquecer que cada dado possui contexto, valor e risco.

No fim, existe uma pergunta que vale mais do que qualquer gráfico:

Estamos apenas analisando dados ou estamos aprendendo a enxergar o ataque antes que ele se torne uma história?

Talvez a diferença entre um dashboard bonito e uma defesa inteligente esteja justamente nessa pergunta.