Visibilidade, escalabilidade e relacionamentos no desenvolvimento seguro: Phil Guimond, da ViacomCBS, conversa sobre o tema

Conversei recentemente com Phil Guimond, arquiteto principal de segurança em nuvem da ViacomCBS. Ele descreve seu cargo como uma forma sofisticada de dizer que gosta de se envolver em tudo. Isso inclui segurança e arquitetura em nuvem, segurança de aplicações, testes de invasão, perícia digital e resposta a incidentes, além de avaliações de fornecedores e gestão de riscos de vez em quando. Ele trabalha em uma equipe bastante multifuncional.

Tivemos uma ótima conversa, e quis compartilhá-la com vocês. Falamos sobre práticas de segurança, como abordar o desenvolvimento seguro moderno e muito mais. Espero que vocês gostem da conversa tanto quanto eu.

Para começar, perguntei a Phil como era sua abordagem geral à segurança e o que ele considera mais importante ao criar um programa de segurança da informação.

Guimond: Minha abordagem à segurança da informação se baseia em visibilidade, escalabilidade e relacionamentos. Desenvolvi esse sistema ao longo dos anos, graças a muitas das pessoas incríveis com quem trabalhei, incluindo Jonathan Keith, CISO de Streaming, que foi um grande mentor para mim. Nos últimos anos, enquanto trabalhava com resposta a incidentes como consultor, percebi que faltavam muitas informações. Não havia logs... nada. Eu praticamente trabalhava às cegas o tempo todo e precisava depender inteiramente de ferramentas padrão de linha de comando para identificar problemas. Minha principal recomendação em cada incidente era implementar um sistema de logging adequado para garantir visibilidade. Não importa quanto você gaste com ferramentas de segurança se não consegue enxergar o que precisa proteger ou o que aconteceu quando algo foi comprometido. Como saber o que proteger se você não consegue ver o que aconteceu?

A visibilidade costuma ser usada como um indicador fundamental para priorizar riscos e obter insights em toda a organização. Eu queria saber como Phil usa dados de visibilidade no dia a dia.

Guimond: A visibilidade nos permite responder a um número impressionante de problemas onde quer que eles surjam, incluindo ameaças antigas, novas e emergentes. Há tantas coisas que você pode fazer com visibilidade que, às vezes, é até surpreendente. É muito empolgante encontrar algo novo e ver as ferramentas de visibilidade mostrarem exatamente o que aconteceu. A visibilidade melhora muito a resposta a incidentes, os testes de invasão, a segurança de aplicações e em nuvem, a gestão de riscos e vulnerabilidades e praticamente tudo mais.

No caso de ataques à cadeia de suprimentos que comprometem bibliotecas de código aberto, ou de vulnerabilidades nessas bibliotecas, você consegue ver quais aplicações as utilizam e removê-las rapidamente dos projetos, atualizá-las ou corrigi-las por conta própria. Quando a infraestrutura de nuvem ou de rede é comprometida, você consegue descobrir rapidamente o responsável, de onde o ataque começou e o que os invasores fizeram com os recursos visados. E, mais importante, qual prática inadequada levou ao comprometimento. Depois, é fácil isolar esses recursos de qualquer infraestrutura e eliminar todas as ações não autorizadas de uma só vez. Ou, se o laptop de um funcionário tiver sido comprometido, você consegue ver o que o invasor fez com as credenciais dele e quais recursos tentou acessar.

Ao criar programas de segurança da informação em grande escala, é importante ter visibilidade do maior número possível de elementos. Você precisa entender quais tecnologias está usando, quais bibliotecas de código aberto fazem parte de cada projeto e conhecer toda a sua infraestrutura de nuvem, incluindo políticas de IAM, buckets, contêineres, infraestrutura como código e outros recursos.

Conseguir enxergar todos, ou a maioria, dos seus problemas faz uma enorme diferença. Você pode ver quais equipes adotam boas práticas que levam a resultados melhores e quais não adotam. Quando encontra equipes que não seguem as práticas recomendadas, essa é a oportunidade perfeita para procurá-las e oferecer ajuda. Quando os engenheiros começam a adotar boas práticas, a grande maioria das vulnerabilidades desaparece de repente. E você ainda tem a vantagem de oferecer treinamento na prática aos engenheiros. É claro que visibilidade por si só não basta: você ainda precisa conseguir corrigir os problemas em escala, senão estará sempre apagando incêndios.

Para mim, os dois últimos pontos são muito importantes. Primeiro, é preciso reconhecer que o objetivo não é apenas encontrar problemas, mas agir com base nessas descobertas. Segundo, é preciso estar preparado para escalar. Usar dados de toda a organização permite identificar a situação e a cobertura das equipes de produto e usar esses dados como parte da avaliação de riscos. Tentar escalar entre equipes antes de estar preparado pode disseminar os problemas em vez das boas práticas. Perguntei a Phil o que escalabilidade significava para ele.

Guimond: Para mim, escalabilidade significa fazer algo uma vez e ter uma solução que resolva tudo. Por exemplo, se várias equipes de projeto precisam de uma funcionalidade específica, a maneira mais fácil de resolver o problema de ter uma dúzia de bases de código que fazem a mesma coisa, cada uma com suas próprias vulnerabilidades e desafios, é desenvolver um projeto central que resolva esse problema e permitir que todas as equipes o utilizem. Basicamente, você quer que suas soluções atendam ao maior número possível de equipes, com o menor número de ações e projetos. Parte disso também é alcançar resultados melhores adotando boas práticas.

Também acredito muito que não há verdadeira escalabilidade sem visibilidade. Se você não consegue ver o que precisa proteger, como vai proteger? Você sabe sequer que aquilo existe? Na maioria dos casos, não saberia, a menos que tivesse muito conhecimento interno, adquirido ao trabalhar na empresa por anos. E se a pessoa com todo esse conhecimento saísse da empresa ou fosse atropelada por um ônibus? De repente, esse conhecimento desapareceria. E você ainda teria pouca visibilidade sobre as vulnerabilidades dos projetos. Essa abordagem não escala de jeito nenhum.

A falta de escalabilidade logo sobrecarrega a equipe de segurança e os engenheiros que trabalham com você. Nem você nem seus desenvolvedores têm tempo para essa abordagem. A escalabilidade também é um grande problema na forma como os testes de invasão são feitos hoje. Criminosos não se importam nem um pouco com o escopo definido ou com as poucas áreas que você testou. Não estou criticando os testes de invasão. Acho que são absolutamente necessários, mas um teste de invasão tradicional é caro e não escala. No ambiente atual, que prioriza a nuvem, você precisa adotar uma abordagem que cubra toda a infraestrutura. E ela precisa ser contínua. 

Como Phil mencionou, escalar rápido demais ou não escalar pode sobrecarregar a equipe de segurança, principalmente se os processos, a documentação e outros recursos não estiverem preparados para esse desafio. Então, perguntei como Phil conseguiu escalar com sucesso.

Guimond: Com uma abordagem que prioriza a visibilidade e consolida as ferramentas em um único painel. Sei que parece clichê, mas funciona mesmo. Você quer facilitar a vida dos engenheiros, não dificultá-la. Obrigar as equipes a usar 25 ferramentas de segurança diferentes para proteger os projetos é um absurdo. É assim que você acaba com resistência interminável, falta de escalabilidade e visibilidade e muito menos interesse das áreas de negócio em trabalhar com as equipes de segurança.

Então, se você encontrar uma maneira de facilitar a vida das equipes, oferecendo o menor número possível de ferramentas capazes de resolver o maior número de problemas de forma escalável, terá resultados melhores. Muito melhores. Isso se traduz em mais visibilidade e, por sua vez, em gestão de vulnerabilidades em grande escala. A gestão tradicional de vulnerabilidades não escala; ela está ultrapassada na era da computação em nuvem. As boas práticas eliminam a maioria dos problemas. Para os que restarem, é importante criar controles compensatórios quando não for possível corrigir as falhas sem uma reformulação significativa da arquitetura.

Perguntei a Phil quais boas práticas ele recomendaria para que outras pessoas obtenham os melhores dados de visibilidade possíveis.

Guimond: Consolide e elimine ferramentas. Você precisa de ferramentas que revelem as práticas inadequadas E ajudem a corrigi-las com o menor número possível de etapas e de soluções. Também precisa eliminar ferramentas que não agreguem valor real à equipe de segurança ou aos desenvolvedores. Se você contrata pessoas só para cuidar de uma ferramenta ou de um conjunto de ferramentas, isso pode criar silos e, muitas vezes, levar a uma abordagem de segurança que não escala.

Você quer que sua equipe seja o mais multifuncional possível. Então, deixe que explore diferentes áreas e assuma outras atividades além daquelas que já apoia. Se os colaboradores individuais passarem o dia todo em reuniões, nada será feito. Trabalhe com fornecedores cujos produtos tenham uma API robusta, capaz de disponibilizar todas as informações que o painel deles oferece.

Para consolidar essas ferramentas, você pode trabalhar com fornecedores cujos produtos protejam grandes partes da sua infraestrutura em uma única solução. Por exemplo, bibliotecas de código aberto, contêineres, SAST [static application security testing], infraestrutura como código, inventário da nuvem e outros recursos. Depois, você reúne todos esses dados em um painel que os exiba em uma única tela, ou no menor número possível de telas. Você precisa conseguir detalhar os problemas por categoria: aplicação, rede, infraestrutura ou até mesmo projeto.

É fundamental obter o apoio de quem pode ajudar ou fazer valer as decisões, ou de quem realmente pode realizar o trabalho e fazer as coisas acontecerem. Perguntei a Phil de quem as pessoas precisam obter apoio antes de começar a buscar visibilidade em todas as equipes.

Guimond: Se você está formando uma equipe de segurança da informação que apoie as demais áreas, primeiro precisa criar relacionamentos com as equipes ou unidades de negócio que atende. Procure essas pessoas, marque uma reunião, mande uma mensagem no Slack — o que funcionar melhor para você — e converse para entender os desafios delas. Quando compreender esses desafios, ficará mais fácil perceber como pode ajudar. Se você sabe que uma equipe já enfrentou problemas específicos de segurança, é importante criar uma solução para ajudá-la a resolver esses problemas. Os desenvolvedores escutam quando você faz isso.

É muito importante ouvir os diretores, gerentes, desenvolvedores e engenheiros da equipe e entender o ponto de vista deles, especialmente quando for diferente do seu. Se você não aceita outras perspectivas e insiste que tudo seja "do meu jeito ou nada feito", ninguém vai querer trabalhar com você, e os resultados do seu programa de segurança da informação serão piores. Mas, depois que esses relacionamentos são construídos, muitas vezes é fácil obter o apoio necessário. As pessoas sabem que você está aberto ao diálogo e não vai ficar no pé delas. Aí, você pode orientá-las sobre boas práticas e conjuntos de ferramentas.

Por fim, perguntei a Phil que conselho geral daria a alguém que quisesse criar sua própria equipe e programa de segurança em uma organização.

Guimond: Contrate uma equipe diversa e multidisciplinar. Pessoas com experiências diferentes das suas vão enxergar as coisas de outra forma. Compreender outras perspectivas ajuda todos a crescer profissionalmente e mantém as equipes inovando. Por exemplo, conversei com uma equipe que tinha 20 projetos diferentes, todos resolvendo exatamente a mesma necessidade. Cada equipe usava sua própria base de código, e cada uma tinha suas próprias vulnerabilidades. Então, elas continuavam tentando corrigir esses problemas um por um. Minha abordagem foi mostrar exatamente como eu corrigiria as vulnerabilidades comuns associadas a esse projeto, mas elas disseram algo que me surpreendeu: além de fazer isso, também criaram um único projeto para atender à mesma necessidade e permitiram que cada equipe o usasse. Isso resolveu o problema de ficar alternando entre todas essas bases de código e eliminou a necessidade de fazer testes de invasão em 20 projetos diferentes. Agora, só precisam testar um. Parece familiar? É o exemplo que usei antes!

Por isso, é importante manter a mente aberta, ouvir as abordagens de outras pessoas e não esperar fazer a mesma coisa em todas as empresas. Cada empresa e equipe é única.

Quanto à importância de uma equipe multidisciplinar, o que acontece quando você elimina várias ferramentas cujo valor já não justifica o custo? As equipes que davam suporte a essas ferramentas talvez precisem assumir outra função. Se já tiverem desenvolvido outras habilidades, vão se adaptar às mudanças muito mais rápido. E a segurança da informação está sempre mudando. Assim, elas podem continuar crescendo na carreira sem precisar buscar oportunidades em outro lugar, e sua equipe de segurança fica mais adaptável.

Não estou dizendo que todo mundo precisa saber fazer de tudo, mas ajuda muito quando vários membros da equipe podem desempenhar várias funções e, ao mesmo tempo, se especializar em sua responsabilidade principal. Essa é a oportunidade perfeita para incentivar sua equipe a desenvolver novas habilidades e oferecer treinamento. Isso também ajuda a atrair candidatos mais diversos, já que a equipe tem a oportunidade de aprender outras coisas e crescer profissionalmente.

Você não quer que sua equipe se concentre totalmente em uma única coisa, pois isso prejudica o desenvolvimento profissional de seus integrantes e limita seu programa de segurança da informação. E, como gestor, se você deixar isso acontecer, estará falhando com sua equipe e sua empresa. Você terá limitado as oportunidades de carreira dessas pessoas ao criar um silo, e agora seu programa de segurança da informação está preso aos limites que você definiu. Com o tempo, a dívida técnica levará a mais pontos cegos, menos escalabilidade e muito mais vulnerabilidades.