Craig Riddell, CISO Global de Wallarm – Série de Entrevistas

Craig Riddell, CISO Global da Wallarm, é um executivo de segurança cibernética experiente focado em ajudar empresas a gerenciar os riscos crescentes relacionados a APIs e sistemas impulsionados por IA. Em seu papel atual, ele trabalha em estreita colaboração com CISOs, CIOs e líderes de engenharia para traduzir padrões de ataque e cenários de abuso do mundo real em estratégias de segurança ação, com forte ênfase na observabilidade – entendendo como as APIs e os sistemas de IA se comportam em produção em todo o usuário, aplicações e integrações. Sua carreira abrange papéis de liderança em gerenciamento de identidade e acesso, arquitetura de confiança zero e segurança empresarial em organizações, incluindo Netwrix, Kron e HP, onde ele impulsionou transformações de IAM em grande escala e modernizou estruturas de segurança. A expertise de Riddell centra-se em ameaças emergentes, como ataques de lógica de negócios, abuso de API, deriva de sistema de IA e fraude, com foco consistente em fechar a lacuna entre estratégia de segurança de alto nível e execução operacional.

Wallarm é uma empresa de segurança cibernética especializada em proteger APIs, aplicações e sistemas impulsionados por IA em ambientes de nuvem modernos. Sua plataforma fornece descoberta contínua, teste e proteção em tempo real contra ameaças, como abuso de API, ataques de lógica de negócios e explorações automatizadas, enquanto oferece visibilidade profunda de como os sistemas se comportam em infraestruturas complexas. Projetada para arquiteturas multi-nuvem e nativas em nuvem, a Wallarm se integra aos fluxos de trabalho de DevOps e segurança existentes, permitindo que as organizações detectem e bloqueiem ataques à medida que ocorrem, em vez de após o fato. Ao combinar inventário de API, detecção de ameaças impulsionada por IA e capacidades de resposta automatizada, a plataforma aborda uma realidade crescente em que as APIs e os sistemas de IA se tornaram a principal superfície de ataque para negócios digitais modernos.

Você começou sua carreira trabalhando diretamente com sistemas e infraestrutura e, desde então, mudou para papéis de liderança focados em segurança de identidade, acesso, API e IA. Quais foram as principais mudanças ao longo dessa jornada que o levaram a concluir que o risco real se afastou da periferia e entrou nas APIs e sistemas impulsionados por máquina?

No início da minha carreira, o foco era proteger a borda. Firewalls, segmentação, endurecimento de infraestrutura. Esse modelo funcionou quando os sistemas eram mais estáticos e as fronteiras de confiança eram mais fáceis de definir.

O que mudou foi como as aplicações são construídas e como os sistemas interagem. As APIs se tornaram o tecido conjuntivo de tudo, e a IA acelerou isso ainda mais. Agora, os sistemas estão tomando decisões, chamando outros sistemas e executando ações em uma escala e velocidade que não envolvem humanos no loop.

Nesse ponto, a periferia se torna menos relevante. O risco real se move para onde as decisões são tomadas e as ações são executadas, dentro das APIs e fluxos de trabalho impulsionados por máquina.

Se você não tiver visibilidade e controle lá, você está confiando em um comportamento que você não pode ver completamente. É onde o risco de negócios aparece, desde a exposição financeira até os resultados não intencionais e a interrupção operacional.

Você descreveu o aperto de mão cibernético como quebrado, referindo-se a como os sistemas estabelecem confiança e trocam ações em cadeias de APIs e processos automatizados cada vez mais complexas. Como essa quebra aparece em um ambiente de empresa real hoje?

Na maioria dos ambientes, os sistemas confiam uns nos outros com base em identidade e autenticação. Um token é válido, um pedido é bem-formado e a interação é permitida.

O problema é que isso assume que válido significa seguro. Isso não é mais verdade.

Nós autenticamos a identidade, mas não validamos a intenção. Nós verificamos o acesso, mas não o comportamento em toda a cadeia.

Um serviço pode ser autorizado a chamar outro serviço, que dispara ações downstream em várias APIs. Cada etapa parece legítima em isolamento, mas em toda a cadeia, você começa a ver comportamento não intencional ou abuso de lógica.

Em ambientes impulsionados por IA, isso é amplificado. Os agentes podem encadear ações e executar fluxos de trabalho sem revisão humana.

O aperto de mão ainda acontece, mas ninguém está perguntando se o comportamento faz sentido no contexto. A confiança é estabelecida, mas não validada continuamente.

Por que o risco de IA e API frequentemente cai entre as fronteiras organizacionais em vez de ser claramente possuído?

Porque os sistemas não se alinham com como as organizações são estruturadas.

DevOps possui a entrega. Segurança possui a política. Equipes de negócios possuem os resultados. Equipes de dados possuem os modelos. Cada grupo possui uma peça, mas ninguém possui o sistema como ele se comporta em produção.

As APIs executam a lógica de negócios em sistemas. A IA introduz a tomada de decisão não determinística em cima disso. Juntos, eles cortam todas as fronteiras.

Eles são construídos por uma equipe, protegidos por outra e consumidos por uma terceira, com monitoramento inconsistente em todos eles.

As lacunas que isso cria não são falhas de equipes. São falhas do modelo operacional para refletir como os sistemas modernos realmente funcionam.

Em sua experiência, quais equipes normalmente assumem que possuem o risco de IA, e onde estão os principais pontos cegos entre segurança, DevOps e unidades de negócios?

As equipes de segurança tendem a possuir o risco de IA do ponto de vista de governança e conformidade. DevOps possui a implantação e a confiabilidade. As unidades de negócios se concentram nos resultados.

Os pontos cegos aparecem entre essas áreas.

A segurança define o que deve acontecer. DevOps garante que o sistema funcione. O negócio se concentra nos resultados. Mas poucas equipes estão olhando consistentemente para o que o sistema está realmente fazendo em tempo real.

Essa lacuna é onde o risco vive, especialmente quando o comportamento é tecnicamente válido, mas contextualmente errado.

Muitos ataques modernos aparecem como comportamento válido e autenticado, em vez de intrusões óbvias. Como as organizações devem repensar a detecção nessa nova realidade?

Precisamos ir além da identificação de pedidos “ruins”.

Em muitos casos, o pedido é válido. As credenciais são legítimas. A chamada de API é esperada. O que não é esperado é a sequência de ações, o volume ou o resultado.

A detecção deve se tornar comportamental e contextual. É menos sobre bloquear um pedido único e mais sobre entender como os sistemas interagem ao longo do tempo.

As abordagens que realmente funcionam em escala vão além da correspondência de padrões. Elas decompoem os pedidos estruturalmente, tratando cada interação como um conjunto de tokens comportamentais, em vez de tentar corresponder a padrões conhecidos.

Isso permite entender como o comportamento evolui e onde ele se desvia, mesmo quando tudo parece válido na superfície.

Se você confiar em regras estáticas ou assinaturas, você perderá a maioria do que importa.

Você enfatizou a importância da observabilidade para o comportamento do mundo real. O que a observabilidade significativa parece para APIs e sistemas de IA em produção?

Observabilidade significativa não é apenas logs e métricas. É entender o comportamento no contexto.

Para APIs, isso significa visibilidade completa de solicitação e resposta, como os pontos de extremidade são usados e como as interações evoluem ao longo do tempo.

Para sistemas de IA, isso significa entender entradas, decisões e ações resultantes.

O mais importante é conectar esses sistemas em fluxos de trabalho completos, não eventos isolados.

Sem isso, você está operando com base em suposições sobre o comportamento do sistema, em vez da realidade.

Por que os modelos de revisão e aprovação humanos tradicionais estão se tornando menos eficazes em ambientes impulsionados por máquina?

Porque a velocidade e a escala mudaram.

Os sistemas estão fazendo milhares ou milhões de chamadas por minuto, e ataques ou comportamentos não intencionais podem se desenrolar em minutos ou segundos. Você não pode realisticamente colocar um humano no loop para cada decisão sem quebrar o desempenho.

Os sistemas de IA também não são sempre determinísticos, o que torna os modelos de pré-aprovação menos eficazes.

A supervisão humana ainda importa, mas precisa mudar de aprovar ações individuais para definir limites e monitorar resultados.

Quais são as lacunas operacionais mais comuns que você vê quando as empresas tentam proteger sistemas de IA usando estruturas de segurança herdadas?

A maior lacuna é a dependência excessiva de controles de design-time.

As organizações se concentram em proteger modelos, revisar código e definir políticas antes da implantação. Isso é importante, mas assume que os sistemas se comportarão como esperado uma vez que estejam ao vivo.

Na realidade, os sistemas evoluem. As APIs mudam. Os modelos de IA interagem com novos dados e fluxos de trabalho. O comportamento muda ao longo do tempo.

Sem a validação contínua do comportamento em produção, as organizações estão efetivamente cegas após a implantação.

O que um modelo operacional prático parece quando vários stakeholders compartilham a responsabilidade pelo risco de IA e API?

Ele começa com o reconhecimento de que nenhuma equipe pode possuir isso de ponta a ponta.

Um modelo prático define a responsabilidade compartilhada, ancorada em uma fonte de verdade comum: o comportamento em tempo de execução.

A segurança define o risco e a política. A engenharia constrói e opera os sistemas. O negócio define os resultados aceitáveis.

As equipes que estão à frente disso operam em um loop fechado. Descoberta contínua, aplicação e refinamento impulsionados pelo que os sistemas estão realmente fazendo em produção, e não pelo que foi assumido no design-time.

Todos os stakeholders precisam ter visibilidade de como os sistemas operam em produção. A partir daí, as equipes podem se alinhar sobre o que “bom” parece, detectar desvios e responder.

A mudança é da propriedade isolada para a responsabilidade coordenada, fundamentada em insights de tempo de execução.

Olhando para o futuro, você espera que a responsabilidade de segurança se torne mais centralizada novamente, ou continuará a se fragmentar à medida que os sistemas se tornam mais autônomos?

A responsabilidade permanecerá distribuída porque isso reflete como os sistemas são construídos.

O que mudará é como essa responsabilidade é coordenada.

Veremos mais modelos de governança unificados, onde as equipes possuem seus domínios, mas operam com visibilidade e contexto compartilhados.

As organizações que terão sucesso não serão aquelas que tentam centralizar tudo. Serão aquelas que alinham os stakeholders em torno de como os sistemas realmente se comportam no mundo real.

Porque, se ninguém entender o comportamento em tempo de execução, ninguém realmente possui o risco.

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