Dom Richter, Co-Fundador da Mondoo – Série de Entrevistas

Dom Richter, Co-Fundador da Mondoo é um líder de produto experiente com profundo conhecimento em desenvolvimento de software moderno, design de produto e liderança de equipe. Com uma formação que abrange tecnologias de backend, frontend e automação, ele liderou equipes de engenharia de alto desempenho por meio de uma cultura de confiança, experimentação e inovação orientada por propósito. Seu trabalho se cruza com IA, cibersegurança e DevOps, onde ele enfatiza a colaboração, o aprendizado contínuo e a entrega de valor significativo para os usuários finais.

Mondoo é uma plataforma de automação de segurança e conformidade que permite que as organizações avaliem, monitorem e protejam continuamente sua infraestrutura em ambientes de nuvem, locais e híbridos. Ao utilizar política como código e insights impulsionados por aprendizado de máquina, a Mondoo ajuda as equipes a identificar vulnerabilidades, impor padrões de conformidade e fortalecer a postura de segurança sem retardar a inovação. A plataforma se integra perfeitamente aos fluxos de trabalho de DevOps modernos, tornando a conformidade contínua uma realidade alcançável para empresas de todos os tamanhos.

O que o inspirou a co-fundar a Mondoo, e como sua formação como hacker e líder de produto — juntamente com suas experiências no Google (GOOGL ), Chef e startups anteriores — moldou a missão da empresa?

Quando eu estava nas trincheiras, invadindo sistemas como parte do meu trabalho como pentester, encontrei muitas fraquezas facilmente preveníveis. Ao mesmo tempo, a segurança muitas vezes se concentrava tanto em inundar os usuários com alertas que perdia de vista o que realmente importava. Naquela época, pensei: “Deve haver um botão simples que eu possa pressionar para consertar essas coisas”.

Depois, mudei de lado e comecei a defender sistemas. Apreendi a operar coisas em escala, com automação e código. Isso é útil, seja você esteja executando uma pequena rede doméstica ou operando uma grande empresa de tecnologia. As ideias são as mesmas. No final, foi essa combinação de segurança e engenharia de plataforma que me motivou a co-fundar a Mondoo. Queria fazer uma diferença no estado da segurança, não apenas adicionar mais um scanner que gerasse mais alertas. Acho muito motivador ver como nossos clientes conseguem melhorar rapidamente sua postura com a Mondoo, após ficarem presos por anos. Vários clientes nos disseram que a Mondoo reduziu suas vulnerabilidades abertas em 60%, o que é um ótimo resultado. Estamos tentando aumentar esse número para 100% com nosso gerenciamento de vulnerabilidades agêntico.

Você descreveu a remediação — o processo de realmente consertar vulnerabilidades após elas serem descobertas — como um mito. Por que acredita que a indústria continua a investir pesadamente em varreduras e relatórios, enquanto deixa as equipes lutando para realizar os consertos?

Isso é em grande parte o resultado de como as equipes de segurança e plataforma são configuradas, especialmente em organizações maiores. Por muito tempo, tratamos-nas como entidades separadas, cada uma com seus próprios objetivos, ferramentas e prioridades. Mas a lei de Conway prova o que acontece: você envia seu gráfico de organização em vez de resolver o problema. Eu vi ambas as equipes apontarem dedos umas para as outras — muitas vezes por muito bons motivos.

Agora, finalmente, estamos experimentando uma mudança na indústria, onde as empresas percebem que querem mais da segurança. Elas não querem um bloqueador de negócios. Querem um motor. Graças a líderes visionários que agora surgem para impulsionar os limites, finalmente estamos vendo uma mudança na indústria e nas soluções.

Como as organizações podem superar a divisão cultural entre as equipes de segurança e DevOps que frequentemente atrasa a remediação?

DevSecOps é um bom começo; você precisa trazer desenvolvedores e segurança mais próximos. Você pode contratar funções multifuncionais que possam ajudar a pontuar a lacuna, como engenheiros de SegOps ou especialistas em plataforma com formação em segurança. Além disso, trazer fisicamente as equipes juntas ajuda. É crucial que a liderança incentive e participe desse processo. Estabeleça metas e métricas compartilhadas e monitore-as.

Para apoiar suas equipes, você então quer trazer ferramentas e tecnologia juntas. Não estou falando apenas de jogar tickets de segurança em sistemas de ticketing. Você quer estabelecer um modelo compartilhado que dê a ambas as equipes o que elas precisam. Por exemplo, descobri que automatizar consertos de vulnerabilidades, onde damos às equipes de plataforma contexto suficiente e, mais importante, a correção específica que elas precisam aplicar, ajuda-as a executar muito mais rápido as solicitações. Quanto mais você combinar isso com automação e criar solicitações de alteração nos sistemas de automação (como Terraform e Ansible), mais fácil é. Você também quer ter um bom caminho de comunicação de volta, ou seja, tornar fácil para as equipes de plataforma objetar, obter exceções e relatar problemas sistêmicos. Tudo isso incentiva a colaboração e pontua a lacuna.

Em sua visão, qual papel a liderança deve desempenhar na criação de responsabilidade e colaboração em torno da solução de problemas de segurança?

Como líderes, temos dois grandes contribuintes para a capacidade de execução de nossas equipes: o que comunicamos e o que medimos. Se os líderes apenas falam sobre coletar descobertas e apontar para outras equipes como o gargalo, então suas equipes tratarão disso da mesma maneira. Se medimos o número de problemas de segurança e não sua qualidade e ações tomadas, então as equipes otimizarão para isso.

Criamos as condições certas trabalhando com outros líderes através de fronteiras, reconhecendo a natureza compartilhada dessa área e nos concentrando em resultados compartilhados em vez de métricas isoladas. Tempo e tempo novamente, vemos que, quando os líderes abordam o problema compartilhado juntos, eles alcançam mais para suas equipes individuais e mais para os negócios, porque impulsionam os resultados que importam.

Os escores de risco são amplamente utilizados, mas muitas vezes carecem de contexto, e a fadiga de alertas sobrecarrega muitas equipes. Como as organizações devem repensar a priorização para que os problemas certos sejam corrigidos?

Para uma priorização eficaz, você precisa de contexto de negócios e contexto técnico. O contexto de negócios inclui saber quais ativos digitais mantêm as luzes acesas em sua empresa e precisam ser protegidos para manter sua boa reputação. Por exemplo, o banco de dados que contém fotos privadas dos usuários ou os gateways que processam todo o tráfego do site são de maior prioridade do que sistemas de teste que não estão conectados à internet. Quando olhamos para as descobertas de segurança, precisamos saber o contexto de negócios. Se você mostrar “crítico” em uma descoberta de baixa prioridade, suas equipes se desensibilizarão e não levarão isso a sério. Se um problema for realmente crítico, você precisa mostrar claramente por quê.

Em seguida, vem o contexto técnico. Isso significa saber o sistema, sua configuração, localização, tags, aplicativos, pacotes e usuários. Mas isso não é tudo. Você precisa elevar sua visão. Você deve entender como um problema de segurança pode expor seus sistemas críticos, como eles estão conectados e integrados, não apenas olhando para um ou dois sistemas individuais, mas olhando para eles como um cluster. Também precisamos saber como esses sistemas são automatizados e construídos para rapidamente dizer às pessoas onde olhar e como corrigir o problema em sua raiz.

À medida que os atacantes cada vez mais utilizam a IA como arma, como os defensores podem usar a IA de forma responsável para permanecer à frente sem criar novos riscos?

Usar a IA multiplica enormemente sua capacidade de corrigir vulnerabilidades e fazer isso à velocidade da máquina. No entanto, se os sistemas de IA não forem seguros, eles podem potencialmente introduzir novos riscos no ambiente. Ao implantar sistemas impulsionados por IA, é importante garantir que eles usem uma arquitetura segura e transparente e permitam um registro e monitoramento de eventos abrangentes. Ao restringir as permissões do agente apenas ao necessário para concluir as tarefas atribuídas, os riscos podem ser mantidos ao mínimo. Guardrails adicionais, como permitir que os usuários interrompam ou desliguem os sistemas de IA agêntica quando necessário, e realizar auditorias regulares nos agentes e suas ações, também é algo que eu altamente recomendaria.

Quais guardrails você acredita serem essenciais ao conceder à automação a capacidade de remediar em ambientes de produção?

Para cada ação que uma automação pode tomar, você precisa de guardrails no lugar para garantir que ela atue dentro de seu escopo esperado. Se você criar um agente de IA e der a ele acesso livre a toda a sua infraestrutura, ele quebrará coisas mais cedo ou mais tarde.

Felizmente, entendemos bem os guardrails graças ao trabalho incansável na automação de plataforma nas últimas duas décadas. Os sistemas de automação modernos têm restrições em vigor que controlam quais ações podem ser tomadas. Na Mondoo, combinamos remediações impulsionadas por IA com estruturas de política adversárias que verificam suas ações. Qualquer remediação é criada em código, pode ser testada, verificada e, mais importante, restringida quando necessário.

Como você vê a balança entre remediação liderada por humanos e máquinas evoluindo nos próximos cinco anos?

Similar aos carros autodirigíveis, veremos as equipes adotarem a automação impulsionada por máquina em mais e mais áreas, um passo de cada vez. Elas começarão focando em um subconjunto do escopo de segurança, como sistemas de baixa prioridade, e introduzirão a automação agêntica para isso, criando métricas e objetivos, e então expandindo gradualmente. Uma vez que isso esteja automatizado, você expande para outras áreas.

Em última análise, o foco da automação deve ser em áreas que são grandes em escala, com muitas semelhanças. Essas áreas se beneficiam mais da consistência que a automação traz. Acredito que, em cinco anos, todas as principais ações de remediação serão impulsionadas por máquina e os sistemas estarão estreitamente integrados entre segurança e operações de plataforma.

Qual é sua visão de longo prazo para como o gerenciamento de vulnerabilidades deve parecer até o final desta década?

Até o final da década, o gerenciamento de vulnerabilidades terá um foco muito mais forte na automação e remediação. Nosso trabalho como especialistas em segurança será mais focado em evoluir essa automação, trabalhando com equipes de plataforma para garantir a segurança de seus ambientes de TI em evolução. Esses sistemas estarão mais estreitamente integrados, usando automação de plataforma e IA agêntica para tomar ações em escala, enquanto são seguros e previsíveis.

Para equipes de segurança menores com recursos limitados, quais são os primeiros passos práticos que elas podem dar para melhorar a remediação e a resiliência?

Comece com a automação de patches. Introduza a automação cedo — especialmente quando você tem recursos limitados — e integre a segurança nela desde o início. Este é o passo mais simples que já diminui significativamente a exposição às varreduras automatizadas que os atacantes usam.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Mondoo.