Thorsten Delbrouck, Group CSO da Giesecke+Devrient – Série de Entrevistas

Thorsten Delbrouck, Group CSO da Giesecke+Devrient, é um veterano executivo de segurança cibernética com mais de duas décadas de experiência em segurança de infraestrutura empresarial, identidades digitais e sistemas críticos. Desde que se juntou à Giesecke+Devrient (G+D) em 2011 como Corporate Chief Information Security Officer, ele liderou a estratégia de segurança global da empresa em setores altamente regulamentados, incluindo finanças, telecomunicações e infraestrutura governamental. Em 2020, ele expandiu seu papel para Group Vice President, Head of Security and CISO. Delbrouck também serve como Presidente do Information Security Forum (ISF), uma autoridade global líder em segurança cibernética e gestão de riscos, e ocupou cargos de liderança em segurança em Infineon Technologies, COMLINE e TÜV Secure iT.

Giesecke+Devrient (G+D) é uma empresa de SecurityTech global com sede em Munique que evoluiu de uma empresa histórica de impressão de cédulas fundada em 1852 para um grande fornecedor de soluções de segurança digital, tecnologia financeira e infraestrutura de moeda. A empresa opera em três segmentos principais: Segurança Digital, Plataformas Financeiras e Tecnologia de Moeda, entregando tecnologias que seguem a conectividade móvel, identidades digitais, sistemas bancários, plataformas de pagamento e moedas físicas e digitais. A G+D trabalha com governos, bancos centrais, instituições financeiras e empresas em todo o mundo, incluindo soluções para eSIMs, sistemas de autenticação, pagamentos digitais, segurança cibernética e Moedas Digitais do Banco Central (CBDCs). A empresa se posiciona como um fornecedor de infraestrutura confiável para a economia digital, com mais de 14.000 funcionários em todo o mundo e décadas de experiência em segurança de sistemas críticos e ecossistemas financeiros.

Você passou quase três décadas em papéis de liderança em segurança cibernética, abrangendo TÜV Secure iT, Infineon e agora mais de 15 anos na Giesecke+Devrient. Como a paisagem de ameaças evoluiu desde os riscos de segurança tradicionais para os desafios cibernéticos impulsionados por IA de hoje, e o que preocupa você mais sobre a direção atual da indústria?

Acho que a principal mudança ao longo da minha carreira é a velocidade e o impacto. Quando comecei a gestão de segurança no final dos anos 90, um problema de segurança grave significava um firewall mal configurado ou um servidor não patchado, o raio de ação era tipicamente contido. Ao longo das últimas três décadas, vi as consequências de uma única violação crescer de inconveniência operacional para risco sistêmico.

E tudo é mais rápido. Estamos lidando com mais sistemas e maior largura de banda. Hoje, apenas metade de todo o tráfego da internet é gerado por humanos – e, segundo algumas estimativas, cerca de 40% do tráfego total consiste em atividades maliciosas, como varreduras maliciosas, malware e DDoS.

Ao mesmo tempo, a paisagem se tornou fortemente consolidada e concentrada. A filosofia de design original da internet de redundância e descentralização foi perdida. Como resultado, ataques que visam apenas alguns pontos de falha centrais têm consequências muito mais devastadoras do que costumavam ter. Isso deixa virtualmente nenhum espaço para erro na configuração e operação de sistemas de TI modernos. E agora a IA está comprimindo os prazos dos atacantes ainda mais.

Comentários recentes de Dario Amodei reacenderam medos em torno de sistemas de IA avançados que identificam vulnerabilidades de software em escala. Você acredita que as empresas estão subestimando a velocidade com que o desenvolvimento assistido por IA poderia sobrecarregar os processos de segurança existentes?

Sim, acredito que muitas empresas estão subestimando a velocidade dessa mudança. No início, parecia que a IA beneficiaria ambos os lados, atacantes e defensores, aproximadamente igualmente. Mas uma realidade preocupante está surgindo: a IA não inventou categorias inteiramente novas de cibercrime; em vez disso, democratizou capacidades de ataque sofisticadas, permitindo que atores de ameaça automatem a reconhecimento, eliminem as barreiras linguísticas no phishing e descubram vulnerabilidades de software em uma velocidade e escala que os defensores humanos estão lutando para absorver.

O problema é que, enquanto a IA despertou um surto maciço na identificação de vulnerabilidades, ela ainda não está sendo implantada na mesma medida no processo de remediação. Isso cria um desequilíbrio perigoso. A descoberta de vulnerabilidades assistida por IA está simplesmente produzindo mais trabalho do que os defensores podem lidar. Isso pode melhorar em alguns anos, à medida que a remediação por IA pegar, mas agora é um problema crescente.

Além disso, não é sem ironia que as mesmas empresas que apresentam seus últimos modelos como salvação dos riscos cibernéticos estão, ao mesmo tempo, alimentando parte do problema. Ferramentas de codificação assistidas por IA aceleram a produção de software, mas frequentemente produzem código vulnerável e descuidado – expandindo a própria superfície de ataque que seus produtos de segurança prometem reduzir. Do ponto de vista econômico, isso é brilhante. Do ponto de vista de segurança, não é tão bom.

Na G+D, avaliamos casos de uso de IA de forma estruturada por meio de um Conselho de IA e não os escalamos de forma não controlada. O problema não é a IA em si – é a falta de governança em sua implantação. Isso está alinhado com o princípio que a G+D também aplica internamente: a IA requer não apenas inovação, mas também processos de avaliação e aprovação institucionalizados.

Muitas organizações veem a IA principalmente como uma ferramenta de segurança cibernética defensiva. Na sua opinião, onde a IA está criando mais risco do que proteção dentro dos ambientes empresariais?

A maioria das equipes de segurança cibernética já implanta a IA em vários graus para detectar, classificar, avaliar e triar eventos de segurança – e funciona de forma notável.

No entanto, novos riscos estão surgindo ao lado desses benefícios. As vulnerabilidades nativas da arquitetura de IA em si são amplamente discutidas e em grande parte compreendidas. Não estamos mais segurando apenas código estático; estamos segurando sistemas não determinísticos. Isso introduz vetores de ameaça completamente novos, como injeção de prompt (onde dados maliciosos enganam um LLM para ignorar suas barreiras), envenenamento de dados para corromper a lógica de um modelo durante o treinamento e vazamento de dados, onde dados de empresa proprietários são expostos acidentalmente por meio de saídas do modelo. Isso muda fundamentalmente a definição de uma exploração.

Mas nossas defesas tradicionais e bem ensaiadas devem se adaptar também. Para muitas organizações, a Análise de Comportamento de Usuário e Entidade (UEBA) ainda é um conceito relativamente novo. De fato, muitas empresas ainda não adotaram totalmente a abordagem devido a regulamentações rigorosas de privacidade de dados, leis trabalhistas estritas e direitos de codeterminação do conselho de trabalhadores. Agora, a base mudou e é incerto se a UEBA ainda será capaz de distinguir comportamento humano de ataques automatizados, ou dizer um agente de IA benigno de um maligno. Já existem produtos que prometem exatamente isso, mas normalmente leva algum tempo para ir das promessas de marketing para o desempenho real e funcionando na vida real. Vamos precisar de novos conceitos com arquiteturas de segurança modernas para abordar isso.

Como Presidente do Information Security Forum, você se engaja com líderes de segurança em empresas globais. Os CISOs estão se tornando mais preocupados com a qualidade do código gerado por IA, ou o problema maior é a carga operacional de segurança de bases de código exponencialmente maiores?

Ambos os problemas são reais, mas eles aterrissam de forma diferente. A qualidade do código gerado por IA é uma preocupação legítima. O código que a IA produz frequentemente parece limpo, mas pode carregar falhas lógicas sutis, configurações inseguras ou bibliotecas mal utilizadas que são mais difíceis de capturar precisamente porque parecem plausíveis. Os CISOs estão certos em se preocupar com isso.

No entanto, em minhas conversas com especialistas em segurança em organizações membros do ISF, o alarme mais alto é operacional: é o volume simples de código que pode carregar vulnerabilidades e, portanto, precisa ser verificado.

O que estou ouvindo consistentemente de pares em várias indústrias é que o problema de dependência se tornou a carga definidora. A dependência pesada de componentes externos e bibliotecas de terceiros significa que cada dependência única deve ser rastreada, gerenciada e continuamente corrigida. No código, mas também na cadeia de ferramentas, potencialmente em diferentes ambientes de nuvem. Isso já era um desafio significativo. O desenvolvimento assistido por IA agora está amplificando isso. Não porque a natureza do problema tenha mudado, mas porque a escala explodiu. Mais código, produzido mais rápido, com mais dependências, em mais repositórios.

Então, se eu tivesse que priorizar: a qualidade do código é um problema de engenharia solucionável – melhor ferramenta, revisões mais rigorosas, guardrails mais apertados no pipeline de desenvolvimento. A carga operacional de segurança de uma base de código exponencialmente crescente e suas cadeias de dependência em expansão é o desafio mais estrutural, mais persistente. É onde a pressão real está, e é o que surge repetidamente em discussões de CISOs seniores.

A Giesecke+Devrient opera em setores altamente sensíveis, incluindo identidade digital, pagamentos, infraestrutura bancária, tecnologia de eSIM e moedas digitais do banco central. Como segurar infraestruturas críticas difere na era da IA em comparação com a proteção de sistemas empresariais tradicionais?

Na G+D, enfrentamos as mesmas responsabilidades centrais que qualquer organização que leva a segurança a sério. No entanto, nossos padrões são excepcionalmente altos, e a margem de erro é muito pequena. Estamos cientes de que um incidente de segurança em nossa infraestrutura carrega implicações muito mais amplas do que uma violação em uma empresa típica – é por isso que nossa tolerância ao risco de segurança cibernética é excepcionalmente baixa.

Onde a IA adiciona uma camada distinta de complexidade para nós é na arquitetura operacional em si. Muitos de nossos componentes de alta segurança, particularmente aqueles vinculados a sistemas de pagamento, identidades digitais ou produtos para bancos centrais, são ativos de alto valor e sujeitos a requisitos de certificação e segurança rigorosos. Esses componentes devem ser desenvolvidos, testados e operados em ambientes separados, variando desde uma separação lógica pura até redes completamente isoladas com nenhuma conectividade externa.

Isso já era desafiador antes da IA, mas agora as organizações em todo o lugar estão integrando ferramentas assistidas por IA em seus fluxos de trabalho de desenvolvimento e operacionais. Ferramentas que normalmente dependem de conectividade de nuvem, acesso a grandes volumes de dados e atualizações contínuas de modelo. Reconciliar isso com ambientes onde mesmo um cabo de rede conectado à porta errada seria uma violação grave de política é um desafio de engenharia e governança muito real.

Isso nos obriga a sermos muito intencionais sobre a integração da IA. Não estamos apenas escolhendo o modelo de IA certo, estamos tomando decisões estratégicas em nível de infraestrutura sobre se essas ferramentas precisam ser implantadas localmente ou podem ser usadas via nuvem.

Estamos vendo uma adoção rápida de copilotos de codificação de IA e agentes de desenvolvimento autônomos. Você espera que as empresas eventualmente exijam que o código gerado por IA passe por processos de validação e certificação separados antes da implantação?

Não acredito que o critério decisivo deva ser se o código foi escrito por um humano ou IA. O critério decisivo é o risco. Mas o código gerado por IA certamente precisará de proveniência, rastreabilidade e revisão mais rigorosa em ambientes regulamentados ou de alta segurança.

Modelagem de ameaças, políticas de codificação segura e a inclusão de ferramentas SAST na cadeia de ferramentas de desenvolvimento já é a prática padrão hoje, e as ferramentas estão naturalmente se tornando aprimoradas por IA. Além disso, as equipes de desenvolvimento devem rastrear meticulosamente quais funcionalidades são críticas para segurança ou pertencem a componentes regulamentados e altamente sensíveis. Além disso, dependências subjacentes devem ser completamente compreendidas e testadas continuamente.

A economia inevitavelmente desempenhará um papel cada vez mais crítico. No momento, o preço de token de grandes fornecedores de IA não é coberto pelo custo. Os principais fornecedores de IA estão absorvendo déficits de infraestrutura e inferência estonteantes para garantir a participação no mercado. Um modelo subsidiado que é economicamente insustentável a longo prazo. Quando os custos comerciais de implantar IA em fluxos de trabalho corporativos forem ajustados para refletir esses verdadeiros gastos de infraestrutura, teremos um problema. Nesse ponto, a indústria terá que mudar para modelos menores, localizados e construídos com propósito. Treinar esses modelos menores para casos de uso específicos se tornará uma estratégia vital para mitigar o aumento severo de custos.

E para categorias com as demandas de segurança mais altas, a supervisão humana permanecerá obrigatória e é exatamente aí que o desafio está: aproveitar a capacidade humana finita da forma mais eficiente possível.

Sistemas de IA podem agora identificar vulnerabilidades muito mais rápido do que analistas humanos, mas a remediação ainda depende fortemente de fluxos de trabalho humanos. As empresas estão se aproximando de um ponto em que a gestão de patches em si deve se tornar autônoma?

Sim, a gestão de patches autônoma não é mais um luxo – é uma necessidade operacional. O volume simples de vulnerabilidades hoje excede a capacidade de triagem humana.

Isso dito, acredito que a implantação real deve seguir uma abordagem pragmática e em camadas. Para ambientes padrão, não críticos, a automação completa deve ser entirely alcançável, desde que as guardrails certas estejam no lugar. A remediação autônoma em sistemas críticos e de alto impacto, embora certamente necessária, provavelmente permanecerá bastante difícil de implementar para o futuro previsível.

É onde os fundamentos realmente importam. A distinção entre essas duas categorias soa direta, mas na prática exige uma quantidade enorme de trabalho de casa detalhado e sustentado para operar um ambiente complexo com abordagens tão divergentes de forma limpa e automatizada. Esse trabalho é fácil de subestimar.

O desafio real, como sempre, não é a execução mecânica do processo em si – é o sistema mais amplo. A tomada de decisão inteligente só é possível quando o sistema todo a suporta. A gestão de patches precisa se tornar significativamente mais inteligente e mais rápida, não apenas mais automatizada.

E, como sempre: em contextos altamente sensíveis, estabilidade controlada e alta velocidade têm que andar de mãos dadas. Essa tensão é a parte difícil – e a parte que a maioria das organizações ainda não está preparada para.

Governos em todo o mundo estão correndo para implementar sistemas de identidade digital, moedas digitais do banco central e infraestruturas conectadas. Quão preocupado você está que ameaças cibernéticas impulsionadas por IA possam superar a preparação regulatória e de segurança nacional?

Quadros regulamentares como o NIS2 e a Lei de Resiliência Cibernética estão impulsionando as coisas na direção certa, mas a regulamentação é, em última análise, apenas uma peça do quebra-cabeça. A regulamentação importa para o sistema como um todo, mas não podemos assumir que emitir uma regra resolve imediatamente o problema. As empresas ainda têm que implementar as diretrizes, manter seus sistemas permanentemente seguros e manter uma compreensão sólida de sua paisagem de ameaças e alvos de proteção, refinando-os continuamente e mantendo-os alinhados.

Estou cautelosamente otimista, desde que as organizações não tratem a conformidade regulatória como um substituto para a segurança real. E a gestão de segurança moderna não espera pela regulamentação. Se algo, deve ser o contrário: a melhor prática do mundo real deve fluir para a regulamentação, não o inverso.

Em domínios de alta segurança, como infraestrutura de identidade digital e pagamento, a preparação operacional não é dada. A G+D não é apenas um fornecedor aqui, mas também um parceiro de diálogo para bancos centrais e governos em todo o mundo. A G+D também está ativamente engajada na proteção de infraestruturas digitais críticas – por exemplo, por meio da Secunet como parceira de segurança de TI da República Federal da Alemanha.

Alguns especialistas descrevem modelos de IA avançados como “armas cibernéticas”, enquanto outros argumentam que essa descrição é exagerada. Na sua opinião, o que as pessoas estão errando sobre os riscos reais apresentados por sistemas de IA de fronteira?

O que as pessoas estão errando é a suposição de que conflitos cibernéticos seguem a lógica da guerra física. Que uma arma suficientemente poderosa inevitavelmente romperá qualquer defesa. Muito do quadro de “arma cibernética” empresta dessa mentalidade cinética: um canhão maior vence uma parede mais grossa, um míssil mais inteligente vence um avião mais rápido. Mas o ciberespaço não funciona assim.

Um ataque cibernético bem-sucedido quase nunca consegue sucesso por meio da força bruta. Ele consegue sucesso explorando uma lacuna: uma configuração incorreta, uma vulnerabilidade não corrigida, um erro humano, um elo fraco na cadeia de suprimentos. A IA não muda essa dinâmica fundamental. Ela torna a busca por essas lacunas mais rápida e mais barata, e reduz o limiar de habilidade para explorá-las. Isso é um problema sério, mas é um problema muito diferente da narrativa de “arma irresistível”.

O risco real não é que a IA crie uma capacidade ofensiva todo-poderosa que nenhuma defesa possa resistir. O risco real é que a IA acelera e amplia a exploração de fraquezas comuns – as mesmas que estamos lutando para consertar há décadas – a um ritmo que supera nossa capacidade de fechá-las.

Quadros de IA como uma arma cibernética distraem disso. Isso encoraja uma mentalidade de corrida armamentista quando o que realmente é necessário é uma higiene operacional melhor, remediação mais rápida e arquiteturas mais resilientes. A ameaça não é uma nova superarma. São as velhas lacunas, exploradas a um novo ritmo. Sim, enquadrar a IA como uma arma cibernética é uma declaração significativamente exagerada.

Olhando para o futuro, você acredita que a maior ameaça de segurança cibernética da IA virá de ataques sofisticados de nações, exploração autônoma em escala, mau uso interno, vulnerabilidades da cadeia de suprimentos ou algo que a indústria ainda não está prestando atenção suficiente?

Prever o futuro da segurança é sempre particularmente difícil. Ataques de nações, exploração autônoma, mau uso interno, comprometimento da cadeia de suprimentos – todos esses são ameaças reais e crescentes, e não descartaria nenhum deles. Mas argumentaria que todos são consequências, não causas. Eles têm sucesso quando os defensores não podem mais manter o ritmo: uma vulnerabilidade pode não ser ainda publicamente conhecida, um patch não está disponível ou a carga de trabalho é muito alta.

E esse último aspecto é onde vejo o risco principal olhando dois ou três anos à frente: equipes de segurança sendo sobrecarregadas pela carga de trabalho.

Todos os tópicos atuais e emergentes – regulamentação, soberania, infraestruturas de nuvem complexas e tudo o que vem com elas – estão aterrissando em equipes já esticadas por triagem de alertas, resposta a incidentes, análise de phishing, gestão de vulnerabilidades e patches, documentação, auditorias e relatórios. A carga de trabalho adicionada por tudo o que a IA pode ser a palha que quebra o lombo do camelo. Exceto que é muito, muito mais do que apenas uma palha.

E, dado a situação econômica global atual, tudo isso está atingindo as organizações sob uma pressão de custos real, em toda a extensão. Se isso não for gerenciado extremamente bem, eventualmente se tornará demais.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Giesecke+Devrient.