A indústria de cibersegurança ficou muito boa em ensinar pessoas a falar sobre cibersegurança. O problema é que falar sobre cibersegurança e trabalhar com cibersegurança são coisas diferentes.
Hoje existe quase um roteiro pronto para quem quer entrar na área: aprender o que é SIEM, decorar a tríade CIA, estudar MITRE ATT&CK, entender phishing, conhecer algumas portas, brincar um pouco com Linux, fazer um laboratório, tirar uma certificação e, naturalmente, atualizar o LinkedIn com algum título que contenha “Cybersecurity”.
Nada disso é errado. O problema começa quando a formação termina exatamente aí.
Porque saber que PowerShell iniciado pelo Word pode ser suspeito não é a mesma coisa que saber investigar por que aquilo aconteceu.
Saber reconhecer algo suspeito é só o começo
Imagine que um analista recebe um alerta informando que o WINWORD.EXE iniciou o PowerShell. Poucos segundos depois, o PowerShell abriu uma conexão SMB com um servidor interno. A autenticação foi bem-sucedida e um arquivo foi criado em um compartilhamento de rede.
Quem estudou para uma entrevista provavelmente consegue dizer que Word iniciando PowerShell é um comportamento potencialmente suspeito.
Ótimo.
Mas agora começa o trabalho de verdade.
Qual documento originou o processo? Havia macro? Qual era a linha de comando? O PowerShell estava codificado? A usuária costuma acessar aquele servidor? O arquivo criado já existia? A conta utilizada era legítima? Houve conexão externa antes disso? Outros hosts apresentaram o mesmo comportamento? Existe persistência? Houve movimentação lateral?
Isso é investigação.
Cibersegurança não é reconhecer palavras assustadoras. É entender contexto, sequência de eventos, comportamento esperado e desvio de padrão.
“Eu sei usar Splunk” não deveria encerrar a conversa
Outra coisa curiosa no mercado é a quantidade de vagas que tratam conhecimento de ferramenta como se fosse sinônimo de conhecimento técnico.
Você conhece Splunk? Sentinel? Elastic? QRadar? XSIAM?
Tudo isso importa. Claro que importa.
Mas existe uma diferença enorme entre saber operar uma interface e saber investigar com a telemetria disponível.
Uma empresa pode trocar de SIEM amanhã. A sintaxe muda. O dashboard muda. O botão muda de lugar. O profissional que aprendeu investigação reclama durante dois dias e segue trabalhando. O profissional que aprendeu apenas o produto entra em uma pequena crise existencial corporativa.
Porque no fim das contas, independentemente da ferramenta, você continua procurando praticamente as mesmas coisas: criação de processos, autenticação, conexões de rede, DNS, arquivos, eventos de identidade, logs de proxy, telemetria de endpoint, cloud audit e comportamento do usuário.
Ferramenta é meio. Não deveria ser o fundamento.
MITRE ATT&CK não é álbum de figurinha
O mesmo vale para MITRE ATT&CK.
Conhecer técnicas e sub-técnicas é útil. Saber que PowerShell pode ser mapeado para T1059.001 é útil. Entender Credential Dumping, Valid Accounts, Remote Services e outras técnicas também é importante.
Mas existe uma diferença entre usar MITRE ATT&CK como estrutura de análise e sair colecionando IDs como se o objetivo fosse completar um álbum.
Saber o código da técnica não responde quem executou, de onde veio, qual era o objetivo, quais hosts foram afetados, quais credenciais foram utilizadas ou qual foi o impacto.
Classificar comportamento é útil.
Entender o incidente é obrigatório.
A entrevista pergunta a porta. O incidente pergunta o comportamento
Outro exemplo clássico é DNS.
Em uma entrevista, alguém pode perguntar qual porta o DNS utiliza.
A resposta é 53.
Excelente.
Agora imagine um host realizando centenas de consultas para subdomínios aleatórios em intervalos regulares, com uso incomum de registros TXT.
Nesse momento, saber a porta não resolve praticamente nada.
Você precisa pensar em frequência, volume, entropia, padrão de nomes, tamanho das consultas, tipo de registro, baseline do host, domínio consultado e comportamento histórico.
Pode ser aplicação legítima. Pode ser DGA. Pode ser beaconing. Pode ser DNS tunneling.
É aí que aparece a diferença entre memorizar um protocolo e entender como ele se comporta em um ambiente real.
Certificação ajuda, mas não investiga incidente
Certificações também entram nessa discussão.
Elas podem ser excelentes para organizar estudos, validar conhecimento e abrir portas. O problema começa quando o objetivo deixa de ser aprender e passa a ser apenas passar na prova.
É perfeitamente possível estudar para descobrir qual alternativa a banca considera correta e, ainda assim, travar diante de um conjunto de logs bagunçados.
O ransomware, infelizmente, não pede seu número de certificações antes de começar a criptografar os servidores.
Quando aparece um comportamento estranho, uma execução suspeita, autenticação fora do padrão ou acesso inesperado a credenciais, ninguém quer saber sua nota no simulado.
Querem saber duas coisas: isso é um ataque e o que fazemos agora?
A IA deixou essa discussão ainda mais interessante
A inteligência artificial tornou tudo isso ainda mais evidente.
Hoje qualquer pessoa consegue gerar uma regra Sigma, escrever KQL, SPL ou XQL, pedir uma regex, criar uma query de hunting ou solicitar uma explicação sobre Kerberoasting em segundos.
Isso não elimina a necessidade de conhecimento técnico.
Na verdade, aumenta.
Porque agora o valor não está apenas em produzir uma query. Está em saber se aquela query faz sentido.
Uma detecção de PowerShell suspeito baseada apenas na existência de powershell.exe pode até funcionar tecnicamente.
Também pode transformar seu SOC em uma árvore de Natal.
A equipe de infraestrutura executa PowerShell o tempo todo. Ferramentas administrativas usam PowerShell. Scripts corporativos usam PowerShell.
Logo, uma boa detecção precisa considerar contexto: processo pai, command line, parâmetros codificados, conexões de rede, usuário, host, frequência, assinatura, reputação, horário, baseline e finalidade.
A IA pode gerar a regra.
O profissional precisa saber se a regra é boa.
Talvez estejamos ensinando cibersegurança na ordem errada
Uma parte da formação em cibersegurança começa pelas ferramentas e tenta chegar aos fundamentos depois.
Talvez devesse ser o contrário.
Primeiro sistemas operacionais. Depois redes. Identidade. Aplicações. Arquitetura. Logs. Comportamento normal. Comportamento anômalo. Investigação. E só então as ferramentas entram como aceleradores desse processo.
Porque SIEM sem entendimento de logs é só uma tela cara.
EDR sem conhecimento de processos vira um gerador premium de alertas.
Firewall sem conhecimento de redes vira uma máquina extremamente sofisticada de criar chamados.
E threat intelligence sem contexto pode virar apenas uma coleção gourmet de IPs maliciosos.
O mercado também alimenta esse problema
Também seria injusto colocar toda a responsabilidade em quem está começando.
As próprias vagas ajudam a formar esse comportamento.
Uma vaga júnior pede SIEM, EDR, SOAR, AWS, Azure, GCP, Kubernetes, Python, PowerShell, Linux, Windows, Active Directory, malware analysis, threat hunting, pentest, incident response e inglês fluente.
Como diferencial, cinco anos de experiência.
O candidato olha aquilo e entende a mensagem: precisa colocar o maior número possível de tecnologias no currículo.
E assim nasce o profissional com experiência em 27 ferramentas adquirida durante três laboratórios e um domingo bastante produtivo.
Júnior não precisa saber tudo
Esse ponto é importante.
O problema não é o profissional júnior não saber tudo.
Ele não deveria saber.
Ele está começando.
Um bom júnior não precisa ter resposta para cada incidente. Precisa saber pensar.
Precisa saber fazer perguntas. Procurar evidência. Diferenciar fato de hipótese. Documentar. Escalar quando necessário. Admitir quando ainda não existe informação suficiente.
Aliás, uma das frases mais maduras que alguém pode dizer em segurança é:
“Ainda não tenho evidência suficiente para concluir.”
Isso vale muito mais do que responder com absoluta confiança alguma coisa completamente errada.
Talvez devêssemos mudar as perguntas
Talvez processos seletivos também pudessem mudar um pouco.
Em vez de perguntar apenas qual ferramenta alguém conhece, perguntar como investigaria determinado comportamento.
Em vez de perguntar se conhece MITRE ATT&CK, perguntar quais evidências buscaria para confirmar uma hipótese.
Em vez de perguntar se sabe KQL, perguntar quais fontes de dados seriam necessárias para responder determinada questão.
Sintaxe pode ser consultada.
Ferramenta pode ser aprendida.
Produto muda.
Versão muda.
Interface muda.
Raciocínio técnico continua sendo uma das poucas coisas que ainda não dá para instalar com um simples apt install cybersecurity.
Infelizmente.
Seria bem mais fácil.
Estamos formando profissionais ou candidatos?
Talvez o problema não seja falta de gente interessada em cibersegurança.
Talvez exista uma lacuna entre aprender a conseguir uma vaga e aprender a trabalhar nela.
Cursos deveriam trazer mais investigação e menos decoração. Laboratórios deveriam ser menos perfeitos. Ambientes de treinamento deveriam ter falso positivo, log faltando, sysadmin executando PowerShell legítimo, usuário fazendo coisa estranha, servidor mal configurado e telemetria incompleta.
Ou seja: um ambiente corporativo normal.
Porque o verdadeiro teste de cibersegurança não é conseguir explicar o que significa T1059.001.
É receber cinco fontes de log contraditórias, um alerta às 2h43 da manhã e descobrir se você está diante de um incidente real ou se o pessoal de infraestrutura resolveu fazer manutenção sem avisar ninguém de novo.
E o pior é que as duas hipóteses são perfeitamente plausíveis.
Por Mariana B. S., Sales Cybersecurity Engineer na e-Safer
