Como eu passei em uma vaga no maior banco da América Latina, pra trabalhar com Infosec, mesmo sem ter feito faculdade
“Ah, Zeroc00i! Certo que tu vai dizer que estudou de forma independente e teve experiências profissionais prévias que te prepararam para essa vaga.”
Calma aí pô! Hahaha. Deixa eu te falar o que eu aprendi ao longo desse caminho.
Mas já te adianto: Sim, é verdade que eu aprendi tudo sem seguir uma metodologia tradicional e tive uma boa bagagem profissional. Apesar disso, não quero que você leia esse texto como uma aversão à academia – longe disso! Reconheço que ela tem o grande benefício de construir bases sólidas em várias frentes antes da especialização.
O ponto é que, naquela época, esse método simplesmente não era para mim.
No começo, eu era a personificação do Efeito Dunning-Kruger. Sinceramente, eu achava que não tinha muito mais o que aprender em infosec. Sei que soa arrogante, mas prefiro acreditar que era isso: quando você sabe pouco, não faz ideia do quanto ignora, e isso distorce a sua compreensão do que você realmente sabe.
Lembro que, lá pelos meus 12 anos, já conhecia “SQL Injection”. Pra mim, saber disso era saber usar ferramentas como o Havij (e mais uma outra que nem lembro o nome).
E uma vez, em uma conversa com um cara mais velho de uma big tech, comentei sobre esse assunto e ele me olhou surpreso: “Caraca, nessa idade tu já sabe de SQL Injection?”. Meu ego foi nas alturas tão rapidamente quanto caiu, assim que ele continuou: “Então tu sabe como os dados são injetados no banco de dados, que bacana.”
Na hora, eu percebi que não tinha entendido nada do que ele tinha falado e, envergonhado, só concordei. Naquele exato momento, ele se tornou um ídolo pra mim. Uma referência.
NoteTudo isso porque, no meio em que eu estava inserido, eu não tinha os meios necessários para me fazer as perguntas certas e perceber quantas coisas eu ainda não sabia, por isso o efeito Dunning-Kruger.
Eu sentia que só via o mundo gráfico, por exemplo: se a ferramenta só tinha um botão “Explorar”, então SQL Injection era isso, apertar aquele botão. A aplicação web só tinha aquelas 3 páginas com botões/links, então eram só eles que existiam pra testar.
É esse conhecimento limitado de como as coisas funcionam que faz a gente não ter noção das perguntas necessárias para ir mais a fundo. Eu tinha sede de conhecimento, mas eu não conseguia ver O QUE EU NÃO SABIA.
Isso tudo me deixou extremamente frustrado depois de alguns anos. Lembro que, com essa idade (12 anos), eu já sabia que ia trabalhar com algo que envolvesse cibersegurança, ainda não sabia como, mas sabia que era isso.
O problema é que eu, até os 18, fui um “script kiddie”, participando de fóruns de comunidade hacker e muitas vezes compartilhando conteúdo que eu nem fazia ideia do que se tratava. Eu só queria estar ali: na margem da superficialidade de fazer parte de um grupo que ama cibersegurança.
A virada começou quando entrei em uma empresa de tecnologia como analista de suporte, sabendo apenas HTML, mas com um pensamento muito curioso e com conhecimento de “coisas que existiam”.
Nessa empresa em que eu entrei como analista de suporte, tive que aprender primeiramente sobre SSH e, aos poucos, fui aprendendo sobre Linux.
Usava o SSH para me conectar nos servidores compartilhados dos clientes e, muitas vezes, ajudar a resolver alguns erros de integração da programação deles com o nosso ambiente. Isso acontecia porque, muitas vezes, o cliente/programador desenvolvia em seu ambiente local que tinha uma série de configurações no PHP, por exemplo, e quando subia a aplicação pro nosso servidor, tinham muitas outras configurações já definidas.
O que eu quero dizer é que ser analista de suporte de uma empresa de tecnologia me ajudou muito a me preparar para adentrar outros cargos dentro da empresa. Nessa posição é mais fácil compreender cada vez mais o produto e as dores frequentes (como no caso, muitas vezes, eu ter de encaminhar o cliente para o nível 2/o pessoal que administrava esses servidores, tendo permissão root neles).
Mas não foi só isso: desde que entrei, comecei a contribuir com sugestões e achados de falhas de segurança na empresa.
Depois de um tempo, fui para um setor que se chamava analista de chamados. O suporte, que antes era por ligações telefônicas, agora atendia casos que requeriam uma maior análise, através de interação via ticket.
Consegui me especializar em casos que eu me destacava: identificação do motivo da lentidão do site – muitas vezes pela falta de um cache ou pelo site ter sido hackeado. Eu adorava investigar a origem do ataque, buscar qual plugin tinha uma falha recente, refazer os passos e conseguir explicar tudo isso pro cliente. Era quase que uma consultoria especializada nisso sem qualquer custo adicional. Os feedbacks positivos eram constantes e aquilo me empolgava muito.
Tudo isso pra te dizer que: o que muitas às vezes enxergam como “só” uma vaga no suporte, quando bem aproveitada, pode ser o grande pontapé inicial da carreira que você vai construir.
NoteSeguindo nessa história, algum tempo depois eu conheci um cara de desenvolvimento que fez minha mente explodir. Lembro da gente conversando e, em algum momento, eu falei pra ele: “Pô, eu vou ter que clicar várias vezes nesse botão aqui, queria uma forma de fazer isso.” Aí ele disse: “Ah, faz isso por jQuery.” E eu falei: “O quê? Jim Carrey?”. Ele deu risada.
Em alguns segundos, ele me mostrou como pelo console do navegador dava pra simular o comportamento do usuário – ou melhor, interagir com os elementos do HTML através de JavaScript. Em poucos segundos, ele me mostrou como fazer um document.querySelectorAll('#enviar').click() da vida, e isso foi o início da minha paixão por JavaScript.
Depois daquele dia, eu fiquei obcecado em criar JavaScripts que otimizavam meu atendimento. Dessa forma, eu não precisava ser um desenvolvedor para criar meus próprios sistemas; mas eu podia modificar o jeito que eu interagia com a aplicação.
Parece simples, mas esse ponto fez com que eu me destacasse por ter observado um padrão na empresa que me permitiu automatizar o que chamávamos de FollowUp (eu via os tickets que o cliente estava demorando para responder e fazia uma interação questionando se podíamos fechar o atendimento).
Isso ajudava a resolver os casos de uma forma mais rápida, pois os clientes às vezes esqueciam que precisavam retornar um dado para continuar o atendimento e, ao mesmo tempo, me ajudava na metrificação de interações com clientes por dia. Fui chamado para propagar esse script para outros analistas, o que ajudou a esse processo ser automatizado.
Chegou um momento da minha carreira que algumas pessoas da empresa começaram a me falar: “E aí, tu quer ir para o nível 2 (infraestrutura) ou para o desenvolvimento? Qual teu próximo passo?”. Não existia um time de infosec formalizado (nessa época, era comum o time de segurança ser o time de infraestrutura), e sinceramente eu estava muito confuso.
NoteMinha decisão se deu em um momento que eu me dei conta que eu achar falhas e reportar só gerava mais demanda pro time de desenvolvimento. E que, através do desenvolvimento, com um olhar de segurança, eu poderia ajudar a contribuir mais efetivamente para a empresa.
Lembro também que, nesse momento, eu quis construir um sistema com um colega desenvolvedor e combinamos que eu faria o frontend com JS e ele o backend com PHP. Eu lembro que ele me falava: “Pode enviar o dado pra esse endereço que eu te mando de volta.” E aquilo não entrava na minha cabeça; eu realmente não entendia como o backend funcionava. Na minha cabeça, só era possível modificar coisas que já existem.
Indo para o desenvolvimento, eu pude ver como os sistemas funcionam por trás, que a tela não é tudo que podemos fazer com a aplicação. Nessa época, comecei a conhecer o bug bounty também.
Senti que meu conhecimento começou a ficar mais consolidado, pois fui vendo as mitigações que os desenvolvedores geralmente implementam nos dados que transitam nas aplicações, o que os frameworks geralmente já fazem. E isso, com certeza, me ajudou muito a aprimorar a forma com que eu falava cibersegurança.
Essa experiência no desenvolvimento também me fez ter mais entendimento sobre dockerização, banco de dados, etc. Inclusive, essa experiência me ajudou demais nas próximas atuações que tive e que vou listar ainda, pois me permitiu ter um diálogo mais realista com os desenvolvedores, como alguém com pensamento de infosec.
Depois de um curto tempo no desenvolvimento, estava se estruturando um time formalizado de cibersegurança na empresa, e eu fui chamado para integrar ele. Nessa etapa, tive a oportunidade de conhecer também o lado blue team, aprendendo sobre atuações CSIRT.
Esse tipo de experiência, nas redondezas do lado de segurança ofensiva, ajuda a ter um entendimento do todo, tornando-se muito útil, porque sempre se encaixa em algo de infosec. Por exemplo: o que acontece quando você consegue explorar uma aplicação, executar comandos no servidor (Linux, por exemplo), e executa um comando explicitamente considerado malicioso, como um wget que vai baixar algum software de uma VPS sua para a máquina alvo e vulnerável a fim de escalar privilégios?
Certamente, o time de monitoramento de segurança daquele servidor receberá um aviso de uma de suas ferramentas de monitoramento sobre uma atividade suspeita, e eles atuarão nesse provável incidente de segurança. Terão logs sobre seu início, a execução do wget, o isolamento dessa máquina da internet e, então, descobrirão sobre a falha que permitiu a execução remota na máquina, cessando sua conexão com ela.
Após minha atuação de infosec nessa empresa, onde permaneci 7 anos, eu fui para uma consultoria de cibersegurança, atuando como uma pessoa que analisa arquiteturas de aplicações e que vê os resultados dos SASTs sobre os códigos dos clientes.
Lembra daquela atuação que tive investigando vírus em sites? Eu tinha que fazer uma espécie de engenharia reversa nos códigos. Na época eu ainda não tinha noção do quanto eu estava afiado em “code review”, só fui percebendo à medida em que fui me destacando e somando com o pensamento ofensivo a como explicar para os desenvolvedores aquele alerta do SAST: se era um falso positivo, se não era, replicar ele na aplicação.
Essa experiência foi muito massa!
Depois de alguns meses, eu fui então chamado para uma vaga no Itaú e aceitei participar da entrevista!
A experiência da entrevista com o Itaú foi muito da hora. Na primeira etapa, a atuação esperada era muito a de um DevSecOps. Tenho quase certeza que não houve pergunta se eu tinha faculdade ou não, e se teve, não senti nenhuma expectativa por parte deles; isso foi muito interessante.
As perguntas, questionadas por uma pessoa coordenadora do time, estavam muito direcionadas para minhas experiências com DevSecOps, e mesmo não tendo havido diretamente, consegui responder bem porque já tinha tido experiências com SAST. O que eu achei mais massa é que na segunda entrevista técnica, agora com um gerente da área, foi extremamente técnica e focada em code review.
Embora alguma das perguntas, se não me engano, não eram da linguagem que eu estava acostumado, em mais de 5 cenários de code review eu consegui explicar todas as vulnerabilidades que existiam.
E isso só aconteceu porque eu valorizei e aproveitei cada oportunidade em cada área que eu já estive, desde o suporte, podendo assim condensar todas as experiências passadas que eu tive sobre desenvolvimento, code review, segurança ofensiva nas minhas respostas.
NoteIsso foi muito mais do que falar onde eu era formado. Foi o sinal prático e imediato pro meu entrevistador sobre o meu conhecimento e como eu conseguiria preencher as atividades diárias atuando no time.
O Banco então decidiu me contratar, mas ajustando a posição do cargo para o que podemos chamar de Cybersecurity Advocate (eles não botaram esse nome na CLT, mas acredito que isso condensa melhor a minha atuação lá). Eu fiquei responsável por criar apresentações para os desenvolvedores sobre OWASP Top 10. Como a empresa tem MUITOS desenvolvedores, era muito importante pra empresa trazer todos esses conceitos.
E foi assim que consegui o emprego no maior banco da América Latina, sem faculdade.
Se tu leu até aqui, vou condensar tudo isso em um conselho: Não é papo coach, mas valoriza todas as oportunidades que tu tem. Sempre lembre de construir uma base sólida se cercando de pessoas e assuntos inovadores. Nunca apague a chama da curiosidade, isso mostra engajamento e todo dono de empresa gosta de ter um funcionário interessado, que vai atrás, que seja proativo. E quando pesquisar novos assuntos e, por ventura se sentir um ignorante, lembre: Uffa, saí do Efeito Dunning-Kruger e agora enxergo pelo menos as coisas que eu não sei!