O que esse cargo realmente envolve no dia a dia
A maioria das pessoas acha que tecnico em segurança da informação é só configurar firewall e instalar antivírus. Quando você entra numa empresa real, descobre que o trabalho é bem mais sujo e repetitivo do que parece nos currículos. A maior parte do tempo você passa lidando com alerts falsos, revisando logs que ninguém pede para revisar, e justificando por que um controle de segurança impede o time de vendas de fazer seu trabalho normalmente. Eu levei dois anos para parar de tratar cada alert do SIEM como uma emergência real. Hoje leio uma média de 40 a 60 incidentes por turno, e consigo identificar em menos de 30 segundos quais são ruído de fundo. Isso não vem de curso nenhum. Vem de ver o mesmo padrão de log errado acontecer sexta-feira à noite durante seis meses seguidos.
O caminho para chegar a tecnico em segurança da informação
O caminho mais direto no Brasil é fazer uma técnica em informática ou eletroeletrônica e depois se especializar em segurança. Existem também cursos técnicos específicos na área, mas a realidade é que o mercado não exige diploma técnico formal para a maioria das vagas de nível ajudante ou técnico júnior. O que realmente separa quem consegue a vaga de quem fica na porta é conseguir demostrar pelo menos uma certificação de entrada e ter mexido com laboratórios práticos. Se você está começando agora, foque nestes três pilares antes de aplicar para qualquer vaga:
Conhecimento sólido de rede. Você precisa saber o que é um handshake TCP, como funciona o DNS na prática, e conseguir ler um pcap no Wireshark sem travar. Sem isso, vai depender de scripts prontos e nunca vai entender quando o script está errado. Leva cerca de oito a doze semanas de estudo direcionado se você já tiver alguma base. Noções de sistemas operacionais. Linux é obrigatório. Windows é obrigatório também. Você vai passar mais tempo lidando com PowerShell e Group Policy do que com qualquer ferramenta de pentest no primeiro ano. Se o seu foco for infraestrutura, saiba pelo menos como um GPO é aplicado, onde ficam os logs de segurança do Windows (Event ID 4624, 4625, 4672), e como o Sysmon muda completamente a visibilidade dos logs.
Familiaridade com pelo menos uma ferramenta de segurança operacional. SIEM, IDS/IPS, ou algo do tipo. Eu recomendo começar com o Wazuh porque é gratuito, tem documentação em português, e cobre desde coleta de logs até resposta a incidentes básica. Configure um lab com dois servidores Wazuh, um agente em uma VM Windows e outro em uma VM Linux, e dispare ataques reais usando o Atomic Red Team. Leva uns dois dias para sair do zero até ter um monitoramento funcionando. Depois desses três pilares, as certificações de entrada fazem diferença. Security+ da CompTIA é a mais reconhecida no Brasil para cargos técnicos. CEH existe, mas o conteúdo é mais voltado para_ENUMERAÇÃO do que para o trabalho real de segurança defensiva. Se o seu objetivo é operação, eu trocaria CEH por um curso prático de SOC ou por SSCP, que é mais alinhado com o dia a dia de monitoramento e resposta.
Um problema real que eu encontrei e como resolvi
Em 2022, fui chamado para investigar por que um cliente tinha alertas constantes de movimento lateral no Wazuh, mas quando eu abria o caso, não encontrava nada anormal. O SIEM mostrava sessões SMB vindo de workstations para servidores de arquivo em horários alternados, com múltiplos failures de autenticação seguidos de success. O padrão gritava enumeração, mas o time de infraestrutura jurava que era normal porque usavam scripts de mapeamento de rede via GPO. O workaround foi simples, mas demorou para eu perceber. Eu parei de confiar nos logs de autenticação do Windows e comecei a cruzar com os logs de rede do Suricata, que estavam rodando em modo passivo no core switch. A diferença era que o Suricata registrava o fluxo real de pacotes, enquanto o Windows só mostrava o resultado final da autenticação. O que acontecia era isso: os scripts de mapeamento faziam várias tentativas SMB com credenciais diferentes antes de acertar uma válida, e cada tentativa gera um Event ID 4625. O SIEM punia tudo como brute force, mas na verdade era comportamento operacional mal documentado.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Eu criei uma whitelist baseada nos IPs dos servidores de mapeamento, nos horários em que os scripts rodavam, e nos nomes de usuários dos serviços. Reduziu o volume de alertas de cerca de 200 por noite para quatro ou cinco. Ainda assim, fiz questão de documentar tudo e mandar pro time de infraestrutura ajustar os scripts para usar credenciais de serviço com menor número de tentativas. O problema não era a ferramenta de segurança. Era a falta de controle sobre o que rodava nos bastidores.
O que ninguém te conta sobre essa profissão
Você vai passar mais tempo escrevendo relatórios do que analisando incidentes. Isso não é desânimo, é realidade. Um bom tecnico em segurança da informação precisa saber transformar um achado técnico em uma recomendação executável. Se você escrever "houve tentativa de intrusão" num relatório pra diretoria, eles vão pedir para instalar mais um firewall e pronto. Ninguém vai entender o que aconteceu de verdade, e você vai ter que repetir o trabalho mês que vem. Outra coisa que não ensinam: a maior parte das vulnerabilidades que você vai encontrar não vêm de ataques externos. Vêm de configurações antigas, senhas padrão que ninguém trocou, e sistemas legados que o responsável saiu e ninguém documentou. Eu já vi servidor rodando com Windows Server 2008 R2 sem patch de segurança crítico ao lado de um domínio Active Directory produtivo. O problema não era o sistema em si. Era a falta de inventário atualizado.
Há também o desgaste de ser o cara que sempre diz não. Quando você trava um acesso porque a política de segurança exige MFA e o usuário precisa acessar um sistema legado que não suporta MFA, você vira o vilão da história. O caminho profissional mais saudável é entender quando o risco é aceitável e propor uma compensação — um VPN com MFA, segmentação de rede, monitoramento intensificado — em vez de simplesmente bloquear. Isso economiza horas de conflito todo mês e mantém seu relacionamento com os outros departamentos funcionando. Salários variam muito. No Brasil, um técnico júnior começa entre R$ 2.500 e R$ 3.500. Pleno fica entre R$ 4.000 e R$ 6.500. Sênior pode passar de R$ 8.000, mas aí já é mais perto de analista de segurança do que do técnico puro. A diferença salarial grande vem quando você consegue provar que reduziu tempo de resposta a incidentes ou diminuiu o volume de falsos positivos. Números reais valem mais do que qualquer palavra numa entrevista.
O que evitar nos primeiros anos
Não se especialize em pentest. A maioria dos cursos de penetração ensina a usar ferramentas sem explicar como os logs que você gera vão aparecer num SOC real. Se você quer ser tecnico em segurança da informação operacional, comece pela defesa. Pentest é interessante, mas você vai entender muito mais o valor do que faz quando primeiro passará sufoco respondendo a um incidente causado por uma falha que poderia ter sido detectada com monitoramento básico. Também não confie cegamente em dashboards. Um gráfico bonito no Kibana ou no Grafana pode esconder dados desatualizados. Eu já vi um dashboard mostrando " Zero ameaças nas últimas 24 horas" porque o agente de coleta parou de enviar logs há doze horas e ninguém percebeu. Sempre verifique a data do último log recebido antes de confiar em qualquer métrica.
E por fim, não subestime a importância de documentar procedimentos. Se você resolver um problema às três da manhã e não escrever o passo a passo, na próxima vez vai levar duas horas para resolver o mesmo problema de novo. Documentar leva quinze minutos. Perder duas horas repetindo o trabalho é o erro mais caro que um técnico iniciante comete, e é totalmente evitável.
