Parte 3 – Jornadas em cibersegurança: o trabalho por trás do trabalho

O trabalho que não aparece nas telas de cinema

A AWS publicou a terceira parte de sua série Cybersecurity Journeys, que acompanha 11 profissionais de segurança da empresa contando suas histórias reais. Nas partes anteriores — Parte 1: não planejei isso e Parte 2: afinal, o que é esse trabalho? — a série mostrou como essas pessoas chegaram à área e quais funções pouco conhecidas existem dentro dela. Nesta terceira parte, o foco é o cotidiano: o que realmente acontece no dia a dia de quem trabalha em segurança, longe dos cronômetros dramáticos e das cenas de digitação frenética que Hollywood inventou.

Três profissionais compartilham suas rotinas, e o que fica claro é que a maior parte do trabalho real é feita de conversas difíceis, leitura cuidadosa de código e a disciplina de saber quando parar. São habilidades que não rendem cenas de ação, mas são exatamente o que sustenta qualquer operação de segurança de verdade.

Brandon Caldwell: segurança de aplicações é, antes de tudo, gente

Brandon Caldwell, gerente de Engenharia de Segurança na AWS, trabalha com segurança de aplicações — a disciplina de revisar software enquanto ele ainda está sendo construído, para que as falhas nunca cheguem à produção. Se você imagina alguém invadindo sistemas em um terminal escuro, a rotina de Brandon é o oposto disso: ele passa os dias em conversa com os times que desenvolvem produtos, fazendo perguntas até entender o funcionamento de algo fundo o suficiente para enxergar onde ele pode quebrar.

A parte mais difícil do trabalho, segundo ele, não é técnica — é humana. A equipe de segurança precisa chegar para um desenvolvedor e dizer que o produto que ele construiu com cuidado tem problemas. Brandon usa uma frase direta com os profissionais que contrata:

“Nosso trabalho é chegar e dizer que o bebê da pessoa é feio. Uso essa frase porque ela desperta empatia. É a coisa que eles amam e dedicaram tempo, e você aparece no final dizendo que ela é feia. Claro que vão reagir.”

Aprender a entregar esse recado sem destruir a relação com quem está do outro lado da mesa é, na visão dele, o verdadeiro ofício da função. Engenheiros que entraram na área de tecnologia justamente para evitar lidar com pessoas tendem a ter dificuldades em segurança de aplicações.

Além das conversas, há muito texto envolvido: documentar uma descoberta de forma que o desenvolvedor consiga agir, escrever avisos que orientem clientes, redigir políticas que definam o padrão para todos que vierem depois. A capacidade de transformar algo técnico e confuso em poucas frases que o leitor consegue usar de verdade é, segundo Brandon, um dos grandes diferenciais de quem cresce na área.

A trajetória dele começa bem antes da cibersegurança existir como título de emprego: ainda criança, ele editava o código hexadecimal do jogo Doom para ter munição infinita. Depois vieram anos como administrador de TI e resposta a incidentes na Microsoft. O que o fez migrar para o lado da prevenção foi perceber que os mesmos tipos de falha — como injeção de SQL (Linguagem de Consulta Estruturada) e scripts entre sites, duas das formas mais comuns de exploração de sites mal construídos — apareciam repetidamente. Ele preferia ajudar os times a evitar o problema do que chegar depois para consertá-lo.

Para quem quer entrar na área, o conselho de Brandon é prático: pratique fazer perguntas e entrevistar pessoas, passe tempo real com desenvolvedores para entender como software é construído. Na hora de contratar, certificações são o último critério que ele olha — o que ele quer ver são resultados em competições de capture the flag (CTF — competições de hacking onde você resolve puzzles de segurança para acumular pontos) e projetos públicos no GitHub, porque esses provam que a pessoa realmente fez o trabalho.

Kurt Heath: a base antes da glamourização

Kurt Heath, Associado de Suporte de TI na AWS, trabalha com segurança ofensiva: testes de penetração (Pentest — a prática de invadir sistemas legalmente para provar onde eles são vulneráveis) e, eventualmente, red teaming. Mas ele é o primeiro a advertir que o cotidiano de quem está se tornando bom nisso não tem nada de cinematográfico.

São horas de prática em ambientes deliberadamente vulneráveis, leitura de técnicas seguida de tentativas repetidas até que funcionem, e a acumulação lenta das camadas que sustentam o trabalho: sistemas operacionais, redes, desenvolvimento de software e fundamentos de segurança, todos aplicados ao mesmo tempo. Kurt reconhece que testes de penetração são “a parte glamourosa” que aparece nos anúncios de vaga, e avisa que não deveria ser o ponto de partida de ninguém, exatamente porque há muito trabalho silencioso de base por baixo.

Uma parte significativa do seu dia atual envolve decidir como e quanto usar Inteligência Artificial (IA). Ele trata a IA como ferramenta, não como muleta: usa como assistente de código quando precisa trabalhar em uma linguagem que não domina, e para organizar grandes volumes de informação rapidamente. Mas não deixa a IA pensar por ele. Formulários como o questionário desta série, ele preenche à mão. E durante um engajamento de segurança, ele evita deixar a IA executar ações autonomamente — uma ferramenta excessivamente proativa pode agir em uma rede de formas não planejadas, causar danos operacionais ou sair do escopo definido e criar um problema legal.

Na visão de Kurt, segurança é fundamentalmente um problema humano. A automação melhora continuamente nas partes sistemáticas, mas pensar fora da caixa como um atacante real ainda é algo teimosamente humano.

A trajetória dele é em grande parte autodidática. Depois que um programa de faculdade comunitária não deu certo, ele aprendeu do zero: terminava turnos em uma fábrica de automóveis e passava as noites com YouTube e buscas na internet aprendendo como computadores e redes funcionam. O maior desafio foi a automotivação, e o que o sustentou foi uma combinação de determinação e, eventualmente, comunidade — amigos encontrados em servidores do Discord, podcasts de segurança e canais de interesse que ajudaram a transformar vontade bruta em foco real. Ele chegou a fazer uma tatuagem como lembrete de que não há plano B:

“Não existe outra opção. Não existe ‘e se’. É isso. É a vida agora, e vou descobrir um jeito, de alguma forma, não importa quanto tempo leve.”

Para quem quer seguir o mesmo caminho ofensivo, o conselho de Kurt é resistir à tentação de começar por aí. Construa a fundação primeiro — muitas vezes por meio de uma função em um Centro de Operações de Segurança (SOC) —, entre nas comunidades onde as pessoas aprendem em público, e deixe o trabalho mais chamativo vir depois que a base estiver sólida. O progresso nessa área, na experiência dele, é medido menos pelo cargo que você conquista do que por quanto você cresce e com quem você cresce.

Seth Jeacopello: saber quando parar é o verdadeiro ofício

Seth Jeacopello, Gerente de Engenharia de Segurança na AWS, também trabalha com segurança de aplicações — mas se o dia de Brandon é centrado em pessoas, o de Seth é centrado em código. Os dois juntos mostram como a mesma função pode ter aparências muito diferentes.

Quando Seth trava em um problema difícil, ele não força mais. Ele pega um cadeado. Um cadeado físico, de verdade, com pinos e molas, porque ele é um entusiasta sério de arrombamento de fechaduras. Ao longo dos anos, aprendeu que a melhor resposta quando bate em uma parede é largar o problema e pegar o que ele chama de “cadeado de conforto” — um que ele conhece bem e consegue abrir facilmente. Não é sobre o cadeado; é sobre dar ao cérebro uma pequena vitória para que ele possa voltar ao problema difícil com olhos frescos.

O cadeado de conforto existe porque o cotidiano de Seth é fácil de perder. Em segurança de aplicações, grande parte do trabalho é ler enormes volumes de código alheio em busca da única falha que importa. Como desenvolvedor de longa data, ele genuinamente ama ler código — e é exatamente isso que torna a tarefa uma armadilha. Você se convence de que a vulnerabilidade está logo atrás da próxima função, e da próxima, e de repente dois dias se foram. A habilidade que ele passou décadas afiando não é encontrar coisas, é saber quando “fundo o suficiente” é fundo o suficiente.

Depois de 26 anos na área, a meta-habilidade de gerenciar a própria atenção é tão parte do ofício quanto qualquer coisa técnica. A trajetória de Seth começou por volta de 1999, ainda adolescente, com um estágio em garantia de qualidade de software. Aos 17 anos já havia sido contratado como desenvolvedor, e foi se aproximando do trabalho com viés de segurança naturalmente, passando por ferramentas de segurança de rede, chegando a arquiteto-chefe e diretor de tecnologia ao longo do caminho.

O conselho dele para construir os instintos que o trabalho diário exige é concreto: configure uma máquina de prática deliberadamente vulnerável, invada-a, e então vá ler os logs que ela gerou. Assim você aprende não só como um ataque funciona, mas como ele parece do lado do defensor. Um único exercício que desenvolve tanto o músculo ofensivo quanto o investigativo — e é exatamente o tipo de prática paciente e repetível que a área recompensa.

O fio que conecta tudo

Existe uma versão da cibersegurança feita para televisão — acelerada, cheia de momentos de revelação. Esses momentos existem. Mas os três profissionais apresentados nesta parte da série vivem em uma versão diferente da área: construída sobre paciência, repetição e um cuidado obstinado que não fotografa bem.

Para Brandon, o trabalho real é a conversa humana e difícil de dizer a um desenvolvedor que seu trabalho tem falhas sem torná-lo um inimigo. Para Kurt, são as horas sem glamour de prática e a disciplina de usar IA como ferramenta sem deixar que ela pense por ele. Para Seth, é ler mais uma página de código e saber quando parar, com um cadeado de conforto na mesa para quando não conseguir.

Nada disso rende uma boa sequência de ação. Mas tudo isso é como uma carreira em segurança realmente parece — e a boa notícia para quem está começando é que são hábitos aprendíveis, não talentos inatos. Empatia, paciência, julgamento e autoconhecimento não são prêmio de consolação: são parte do trabalho.

Por onde começar

Para quem quer dar os primeiros passos práticos, os profissionais indicam alguns recursos:

• TryHackMe e Hack The Box permitem criar máquinas deliberadamente vulneráveis, invadi-las e estudar o que você acionou — exatamente o exercício que Seth recomenda.
• O OWASP Top 10 (Projeto Aberto de Segurança em Aplicações Web — lista das dez falhas mais comuns) explica as vulnerabilidades de aplicação mais frequentes, incluindo as que Brandon via se repetir.
• A OWASP Cheat Sheet Series transforma essas falhas em orientações práticas sobre como construir e revisar software com segurança.
• O podcast Darknet Diaries conta as histórias humanas por trás de incidentes reais de segurança — uma boa forma de sentir como o trabalho realmente é.
• Para quem quer desenvolver habilidades específicas em segurança na nuvem, a AWS disponibiliza o AWS Skill Builder, com mais de 1.000 cursos gratuitos em ritmo próprio, incluindo trilhas de aprendizado em segurança, e o AWS Builder Labs, que permite praticar em um console AWS real com laboratórios práticos de segurança.

A quarta e última parte da série trará os conselhos e lições que esses profissionais dariam para quem está começando agora.

Fonte

Part 3 – Cybersecurity journeys: The work behind the work (https://aws.amazon.com/blogs/security/part-3-cybersecurity-journeys-the-work-behind-the-work/)