Questionando o status quo

00:05 Richard Bird — citação de abertura

“Quanto mais distribuímos, mais descentralizamos, mais fragmentamos. Quanto mais percorremos caminhos como ausência de código, baixo código, mais perdemos o uso sem servidor; estamos apenas criando um ambiente distribuído que é rico em alvos para os malfeitores e um cenário incrivelmente difícil de gerenciar do ponto de vista da segurança.”

00:28 Raghu Nandakumara

Bem-vindo ao The Segment, um podcast de liderança Zero Trust. Sou seu anfitrião, Raghu Nandakumara, chefe de soluções industriais da Illumio, a empresa de segmentação Zero Trust. Hoje, estou acompanhado por Richard Bird, diretor de segurança da Traceable, líder em segurança de API. Com décadas de experiência em segurança cibernética e TI abrangendo os mundos corporativo e de startups. Richard é membro sênior do Zero Trust Institute de teoria cibernética e membro executivo da Cyber Edboard. Ele é conhecido em todo o mundo por suas tatuagens, gravatas-borboleta e ideias de especialistas sobre segurança de APIs, Zero Trust e identidade digital. Hoje, Richard se junta a nós para discutir como ser um tecnólogo não tradicional, abordando a dissonância cognitiva na segurança cibernética e a interseção entre Zero Trust e segurança de API. Então, tivemos o prazer de [ter] o padrinho do Zero Trust neste podcast. Tivemos o próprio Dr. Zero Trust. Tivemos uma coleção completa de outros luminares de segurança cibernética e tecnologia. Mas essa é absolutamente a primeira vez que temos uma estrela do rock em nosso podcast. Então, com isso, é um grande prazer receber o convidado de hoje, Richard Bird, diretor de segurança da Traceable AI. Richard, obrigado por se juntar a nós.

02:01 Richard Bird

Muito animado com a conversa. Obrigado por me receber.

02:04 Raghu Nandakumara

Você não pode estar mais animado do que eu, Richard. Eu estava vendo seu perfil no LinkedIn e notei que temos pelo menos arcos de carreira muito semelhantes. Nós dois passamos de 15 a 20 anos no setor de serviços financeiros antes de nos mudarmos para a “terra dos fornecedores”. Nesse ponto, todas as comparações param. Fico feliz em dizer que existe esse paralelo antes de entrarmos nele: um pouco de conhecimento sobre você e o que o trouxe até aqui e o que está fazendo hoje.

02:31 Richard Bird

Bem, acho que o que me trouxe aqui foi minha associação com alguns dos personagens obscuros que você mencionou, todos amigos meus. E quando falamos sobre Chase Cunningham e John Kindervag, as histórias que compartilharemos ao longo dessa discussão, na verdade, giram em torno de como nos voluntariamos continuamente para fazer parte das trajetórias profissionais específicas de cada um ou controlar domínios de especialização e experiência. E isso resultou em uma grande oportunidade de sinergia de estarmos juntos em vários canais diferentes, ou ouvir de um ou outro que eu deveria me juntar a eles. Então, eu só faço boa companhia, acho que é por isso que estou aqui. Mas você sabe, tem que ser — minha biografia está um pouco confusa depois de alguns anos dizendo as mesmas coisas repetidamente. Mas sim, trabalhei em cargos corporativos por 20, quase 25 anos. E no decorrer desses 25 anos, cerca de 16 ou 17 deles em serviços bancários e financeiros, processamento de pagamentos, primeiros dias da bolha da Internet e pagamentos de pessoa a pessoa e esse tipo de coisa, foram eleitos por amigos e colegas para entrar na segurança da informação nos primórdios da Segurança da Informação Centralizada como um serviço, especificamente no JPMorgan Chase. Eu digo às pessoas que meu número coletivo de anos no Chase foi 11, ou seja, 137 anos da minha vida que nunca mais vou ter. Você definitivamente envelhece em anos de banqueiro de cães. Mas também vi muitas coisas desde o início, muitas coisas que agora estão se concentrando nas organizações e empresas de hoje, que eram problemas que uma organização como a Chase estava enfrentando há uma década ou mais. Mas também que uma organização como a Chase tinha os recursos financeiros e a experiência necessários naquela época. Então, eu sempre gosto de dizer às pessoas que eu não sou um especialista. Acabei de levar muitas surras e acumular hematomas e cicatrizes antes que muitas outras pessoas o fizessem na segurança. E geralmente sou uma postagem que soa melhor sobre o que não fazer do que sobre as melhores práticas, porque fiz muitas coisas erradas em minha carreira e ainda consegui sobreviver e ter a oportunidade de conversar com você hoje.

04:51 Raghu Nandakumara

Acabei de rir, sorrir muito ao ouvir você dizer isso, porque isso ressoa completamente com minha própria experiência. Enfrentando muitos desses desafios, geralmente alguns anos antes que o resto das organizações e outros setores vejam esses mesmos desafios. E, essencialmente, ter as cicatrizes para agora poder se juntar ao outro lado e dizer: “Sim, é assim que você deveria resolver o problema” ou “Esse é o aprendizado que eu tive, e aqui está como você poderia fazer isso melhor”. Então, absolutamente associado a isso. Antes de prosseguirmos, estou muito animado para falar com você sobre o trabalho que você está fazendo na Traceable. Mas gostei de ler sua postagem no LinkedIn sobre esse Joe Strummer e a influência da música em sua carreira. Eu adoraria que você compartilhasse isso com o público antes de prosseguirmos sobre como seu interesse pela música, sua paixão pela música realmente influenciou a forma como você pensa e comunica as principais ideias e os 10 principais desafios atuais.

05:57 Richard Bird

Bem, estou muito feliz que você tenha revelado isso, porque vai me dar a oportunidade de falar descaradamente sobre algo em que estou trabalhando. Mas também me dá a oportunidade de compartilhar. Há poucas coisas na minha carreira das quais eu tenho muito orgulho. A única coisa da qual eu realmente me orgulho, e não me arrependo de ser uma tecnóloga não tradicional. Eu não tenho experiência em MIS ou CIS, não estou dizendo que, em um negócio de tecnologia, há algo de errado nisso. Mas eu vim de uma trilha totalmente diferente. Eu vim de uma especialização em ciência política com foco na teoria das relações internacionais e especialização em japonês. E eu era gerente de projetos de construção. Depois que saí do exército, aconteceu que foi exatamente o nexo de uma época em que o gerenciamento de projetos era uma habilidade extremamente importante necessária em tecnologia, e alguém viu algo em mim que eu mesmo não via. E eles me contrataram. E essa pessoa ainda é mentora quase 30 anos depois. Compartilho esse histórico porque é a base para mim sobre ser um palestrante apaixonado, um apresentador apaixonado ou um pesquisador apaixonado por questões que estão acontecendo na sociedade, sejam elas técnicas ou não. É essa noção, essa noção artística de musas. O que te inspira é diferente daquilo pelo qual você é apaixonado. O que inspira você e, para mim, minhas inspirações estão fortemente alinhadas às artes. Acontece que a música é uma delas. E como a peça que escrevi parece tocar um pouco o coração e a alma de muitas pessoas. Você sabe, eu cresci nos primórdios da música punk rock. Não tenho vergonha de dizer que provavelmente inspirou um forte pensamento contrário, cínico ou mesmo anti-sistema em mim quando criança, e ainda está lá. Eu o enterrei há mais de 20 anos no mundo corporativo, onde você não tem permissão para dizer coisas em público, você não tem permissão para compartilhar ideias. Você precisa passar por 17 aprovações diferentes para até mesmo estar em um podcast, quanto mais falar publicamente. E eu mantive um limite nisso por um quarto de século. E essa peça veio até mim quando alguém me perguntou: “Como foi que você inventou tantas analogias ou metáforas malucas?” ou “Toda essa abordagem de contar histórias que você adota para as coisas”. Eu disse: “Bem, são duas coisas. Primeiro, eu cresci como filho de capitão de barco de pesca, então obtive um Ph.D. em contar histórias.” E a segunda é que todos esses elementos do meu passado e da minha experiência, crescer ouvindo música, ouvindo letristas e músicos incríveis atacarem questões e problemas da sociedade com suas palavras, se tornaram uma inspiração natural e uma base de motivação para mim pessoalmente.” Quando falo publicamente, um dos meus objetivos é realmente me conectar emocionalmente com as pessoas. E isso é complicado porque você não está se conectando com uma emoção. Assim como a música, você não está se conectando com uma emoção. Alguém pode estar feliz ao ouvir uma música, mas alegria e dança são dois componentes diferentes dessa experiência, não um único. E eu disse uma palavra desavergonhada. Como venho fazendo esse tipo de personalidade, falando e esse tipo de papel nos últimos cinco ou seis anos, percebi que o que vivenciei e o que acho é ensinável. Vou amaldiçoá-lo, mas estou na edição final de um livro chamado Famoso com 12 pessoas. O subtítulo é um guia de carreira sobre como ser um especialista reconhecido internacionalmente em algo com o qual ninguém se importa. E a ideia do livro é que, em minha jornada nos últimos cinco ou seis anos, conheci um grande número de pessoas microfamosas. E a maioria dessas pessoas microfamosas são como eu. Eles são inspirados por coisas que estão muito longe de nossas carreiras e nossa experiência de trabalho. E essas pessoas microfamosas não estão apenas na segurança. Eu sentei ao lado de um cara em um avião, começamos a conversar e ele disse: “Sim, bem, eu sou um coordenador de acrobacias.” Eu desci do avião e descobri que ele é a coordenador de acrobacias. Ele é o cara que ensina todos os outros dublês e dublês de Hollywood. Ele tem milhares de pessoas que o seguem. E pensei que nunca tinha ouvido falar dele antes e provavelmente nunca mais vou ouvir falar dele. Mas que dinâmica interessante para alguém poder ter esse tipo de impacto na vida das pessoas. E foi daí que veio toda essa energia para escrever aquela peça de Joe Strummer. Por exemplo, o que podemos fazer sem sermos estrelas do rock e músicos? O que podemos fazer para inspirar esse mesmo tipo de entusiasmo, motivação e paixão e ser até mesmo uma musa para outras pessoas em nosso próprio campo de especialização? E foi realmente assim que tudo aconteceu.

11:12 Raghu Nandakumara

Eu adoro isso. Muito obrigado por compartilhar isso. E um humilde pedido meu: quando esse livro for publicado, espero que seja um tipo real de formato físico de livro, não apenas como um e-book. Eu adoraria uma cópia autografada de você mesmo.

11:27 Richard Bird

Esse é o plano. Tenho idade suficiente para ainda amar papel.

11:12 Raghu Nandakumara

Minha esposa brinca comigo dizendo que a razão pela qual eu compro livros é apenas para preencher nossa estante. E eu digo: “Sim, absolutamente, descaradamente, é o pano de fundo quando estou em chamadas”. Mas o argumento que você disse sobre contar histórias e realmente encontrar essa inspiração para contar histórias, eu pessoalmente encontro no papel que desempenho hoje, e tenho certeza que você encontra em seu papel, é que é muito importante conectar, mais ou menos, o valor técnico que os produtos que nossas empresas criam, realmente se conectam à essência do comprador e, na verdade, ao resultado que elas estão tentando alcançar. Não se trata de tecnologia; não se trata de como você faz alguma coisa. É sobre como eu vou te ajudar. Por que isso é importante para você? E eu acho que contar histórias é muito importante, você acha isso?

12:15 Richard Bird

Bem, não só acho que acho isso no processo de escrever, o que não é natural para mim. Escrever em formato longo não é natural para mim. No processo de escrever, tive que realmente descobrir por que é que, especificamente na segurança, temos dificuldade em nos comunicar uns com os outros. Temos dificuldade em nos comunicar no que se refere a: aqui está o problema comercial que preciso ajudar você a resolver. Como fornecedor de soluções técnicas, temos dificuldades como tecnólogos com isso, como exigência comercial que eu tenho. E os tecnólogos não entendem. E acho que o que percebi foi que, quando falamos sobre pessoas no mercado, estamos tentando mostrar um caminho para resolver problemas para esses compradores de forma realmente universal, que estão operando na camada abstrata. É uma abstração. Eles reconhecem que há um problema; eles reconhecem que veem algum tipo de violação ou hackeamento nas notícias. Mas comparando isso a todas as diferentes alavancas, peças e oponentes de uma organização que precisam ser puxados, empurrados, torcidos ou ajustados para evitar que algo ruim aconteça. É extremamente difícil. E então, quando o devolvemos aos engenheiros, engenheiros de soluções e arquitetos de segurança. Todos nós vivemos no mundo da especificação. Estamos todos falando sobre essas alavancas, estamos todos falando sobre esses interruptores, e estamos falando sobre... E temos essa grande lacuna de dissonância cognitiva. Isso acontece. E eu acho que contar histórias é um dos principais componentes, uma das principais ferramentas que preenche essa lacuna. Isso cria a possibilidade de alguma camada de tradução universal entre essas partes entre essas diferentes entidades. Porque, no final das contas, estamos todos no mesmo negócio tentando resolver esses problemas. E quando nos perguntamos: por que estamos indo tão devagar e chegando lá? Acho que grande parte disso é exatamente isso: uma fratura substancial na comunicação e na compreensão. Ou seja, estou trabalhando na camada de abstração, estou trabalhando na camada de especificação. E não há nada que junte tudo isso. E eu acho que contar histórias é um componente crítico disso.

14:38 11:12 Raghu Nandakumara

Então você usa o termo dissonância cognitiva e, na verdade, você não vai acreditar nisso, mas eu estava pesquisando sobre isso e ouvindo algumas das outras peças que você publicou, e cito você, você disse: “Dissonância cognitiva, há uma enorme lacuna entre eu sei que tenho um problema e estou fazendo algo a respeito”. Então, vamos agora tentar chegar a esse nível. Você viu isso em sua experiência, e eu vi isso em minhas experiências de que você faz uma avaliação. Digamos que seja um exercício de equipe vermelha. Você identifica suas áreas de vulnerabilidade e diz: “Ah, sim, eu sei que estou vulnerável lá. Eu entendo que preciso fazer algo a respeito.” Seis meses depois, 12 meses depois, repita o exercício, as mesmas vulnerabilidades existem. Preciso fazer algo a respeito: repetir, repetir, repetir. Por que essa lacuna? Por que essa incapacidade de dar o salto e resolver os problemas que precisam ser corrigidos?

15:35 Richard Bird

Sim, há alguns componentes lá. A primeira é que a lacuna representa a lacuna entre conhecimento e ameaça, ou conhecimento e risco ou conhecimento e experiência. Eu mencionei que estava no exército. Tivemos um sargento quando eu estava passando por uma de nossas escolas. E uma jovem tropa entrou e ficou na frente deles reclamando de uma situação que estávamos vivenciando em um determinado exercício. E o sargento olhou para ele e disse: “Estou te ouvindo, mas não consigo te sentir bem”. E eu achei isso brilhante. Eu uso isso há anos. Ele disse: “Eu registro seu problema. No entanto, não há nada que eu possa ou queira fazer sobre isso. E acho que há muito disso no mundo corporativo porque é fácil jogar pedras. Acho que um dos benefícios que tenho é que minhas pedras são jogadas com um pouco menos de força porque já estive daquele lado da parede. Eu estive nesse lado da equação em que você tem tantas prioridades concorrentes. Você tem tantas plataformas de gravação; você tem tantos problemas. Já tive programas inteiros que foram descarrilados para tentar reduzir riscos, de forma tangível, em uma área em que trabalhamos há alguns anos, porque alguns executivos ligaram e disseram: “Ei, eu fui a uma conferência, ouvi isso, vocês precisam começar a trabalhar nisso agora”. Há uma enorme quantidade de distração no mundo corporativo. Então, saber sobre uma coisa não é suficiente. E acho que, repetidamente, continuamos provando que saber sobre algo não gera mudanças comportamentais. No que se refere à mitigação do risco associado a uma coisa, é algo que devemos devolver às negociações de risco. As empresas de risco têm se esforçado ao longo dos anos para criar fórmulas que realmente aprimorassem os custos e as consequências dos riscos. Para classificações de risco, sempre menciono o livro de Nassim Qualy, O Cisne Negro, sempre que falo sobre risco, porque é um livro que confirma o “porquê”. Para responder à sua pergunta, não podemos progredir porque operamos continuamente como executivos e profissionais com a crença de que esses riscos de longo prazo não acontecerão. E, como você sabe, Qualys fala em seu livro que a história prova que esses eventos de cauda longa acontecem com muito mais frequência do que esperávamos. E isso está de volta à dissonância cognitiva. Se eu acredito que um risco está tão distante que não preciso me preocupar com isso. Tenho certeza de que, assim como sua experiência, você já ouviu isso repetidamente: “Sim, acho que isso é um problema muito grande. Mas eu não trabalho no setor bancário, então não estou realmente preocupado com isso.” Você sabe, como isso funcionou para todos que usam ransomware? Certo. Você sabe, existe a expectativa de que haja um gradiente de tipos de ataque que representa a escala de complexidade e maturidade. E isso acabou de surgir em uma conversa ontem, tipo, alguém me perguntou: bem, se alguém está atacando um Chase, um Bank of America ou uma cidade dessa maneira, porque uma empresa muito grande e uma organização muito complicada, empresas pequenas ou médias não precisam se preocupar com o mesmo ataque. E eu disse: “Cara, você acabou de acertar em cheio. Quero dizer, será muito cínico dizer que você acabou de acertar em cheio. Você sabe, as pessoas estão dimensionando seus programas de segurança com base no que elas acham que são os riscos para seu domínio ou vertical específicos. Enquanto isso, os maus atores não estão pensando nisso dessa forma. Se os bandidos estão indo, onde quer que eu possa entrar, tipo, se eu vou usar um ataque sofisticado, tudo bem. Vou usar um ataque não sofisticado. Legal. Se eu conseguir seus dados. Isso é tudo o que realmente importa. E eu acho que essa é realmente toda a confusão da complexidade que temos nesse mercado. Isso mantém a roda da dissonância cognitiva girando e girando de ano para ano no desempenho de segurança.

19:50 Raghu Nandakumara

Como podemos mudar isso?

19:53 Richard Bird

Há a resposta do praticante adulto, e depois há a resposta cínica.

19:58 Raghu Nandakumara

Eu quero os dois.

20:02 Richard Bird

Bem, vou começar com a resposta cínica. E isso reflete uma conversa que eu estava tendo com um mentor outro dia; o mentor me disse: “Talvez devêssemos apenas aconselhar começar a aconselhar os bandidos. Porque eles ouvem, e nossos colegas, nossos amigos e nossos colegas praticantes não.” E acho que é uma afirmação dura, mas não acho que seja totalmente injusta. E acho que isso sugere que a resposta cínica é que, por muito tempo, todos nós, como praticantes, dizemos: bem, só precisamos esperar que a maior, a próxima maior violação, aconteça e as pessoas finalmente mudem. Isso não funcionou. E isso começa a levantar a questão: e se virmos uma reação em cadeia? Um evento catastrófico? E se virmos uma rede nacional de infraestrutura em algum país cair? E se observarmos uma grande interrupção em toda a rede hospitalar? Vimos casos isolados de salas cirúrgicas e salas de emergência sendo fechadas. Sempre acreditei firmemente que o que realmente muda o jogo é quando há alguma forma de vítima em massa associada à ação de um malfeitor no mundo digital. E quando eu disse isso há alguns anos, as pessoas pensaram que eu era a coisa mais sombria que eu poderia dizer, e agora eu digo que as pessoas dizem: “Sim, eu entendo.” Como se isso pudesse acontecer. Então, acho que há uma certa quantidade desse problema refletida na dissonância cognitiva da qual estamos falando, ou seja, ainda não vimos algo grande e ruim o suficiente para finalmente acordar as pessoas. Agora, a resposta profissional para isso é que quando realmente começamos a progredir é quando começamos a ver uma mudança significativa. Acho que em um dos comportamentos mais bizarros que já vi em segurança, ou seja, muitos profissionais de segurança ficam furiosos quando digo isso, mas acredito firmemente que a segurança é a única disciplina no mundo corporativo em que nos recusamos a aprender com a história, os dados e as evidências. Temos evidências claramente à nossa frente. Então, vou dar apenas um exemplo muito específico. Temos evidências claras à nossa frente com 25 a 30 anos de história: quando um malfeitor entra em seu sistema, a primeira coisa que ele faz é acessar seu Active Directory. E indo para o Active Directory, eles estão procurando capacidades e identidades obsoletas, antiquadas, desativadas, mas não excluídas. Eles se envolvem em todos esses direitos e acessam subsídios e autorizações e fazem coisas ruins. E como tudo estava no seu AD, seus sistemas internos de segurança não se atualizam porque parecem que deveriam estar lá. Agora, esse é um padrão que qualquer pessoa que trabalha em segurança sabe que é real; eles sabem que é apoiado por evidências. E eles sabem que esse é o principal caminho para os malfeitores. No entanto, você pode entrar em oito, nove em cada dez empresas hoje e perguntar: “Quando foi a última vez que você limpou seu anúncio?” Seja no Azure, seja no local, você ouvirá grilos. Você ouvirá alguém dizer: “Bem, você sabe, isso foi financiado no ano passado e no ano anterior, mas ficou abaixo do limite e não conseguimos”. E eu acho que, universalmente, sabemos que essa é uma das superfícies de ataque mais capitalizáveis em qualquer empresa. No entanto, todos nos sentamos e dizemos: “Sim, perdi meu financiamento e não vamos trabalhar nisso este ano”. É isso que estou dizendo quando digo que recusamos continuamente. E isso remonta a muitas perguntas que costumavam ser como, bem, você só precisa entender o básico corretamente. Pessoalmente, não acho que essa seja uma declaração útil. Isso volta à segurança fundamental. Você está fazendo a segurança básica corretamente? E você sabe, sem querer liderar a testemunha até aqui, mas foi isso que, eventualmente, depois de resistir por muito tempo ao Zero Trust, foi essencialmente o que me levou ao Zero Trust. Porque acho que há aspectos do Zero Trust que vamos destacar aqui que, na verdade, remontam aos primórdios da computação e são fundamentais. E acho que, embora muitas pessoas pensem que o Zero Trust é, vamos avançar para o futuro; a realidade é que existem aspectos do Zero Trust que são mais ou menos parecidos, vamos voltar aos princípios do passado que sabemos que funcionaram, que são extremamente úteis no ambiente atual, mas que esquecemos e acho que é aí que começamos a ver melhorias quando voltamos e abraçamos nossas raízes. E, secundariamente, quando começamos a prestar atenção ao que os dados claramente publicados e os dados claramente divulgados continuam nos dizendo como nossa fraqueza repetidamente.

24:40 Raghu Nandakumara

Só estou ouvindo tudo isso e tantas coisas que poderíamos ter aprofundado e que eu suspeito que ficariam aqui o dia todo e a noite toda, enquanto meu tempo permite, mas não tenho certeza se o seu. Então, apenas algumas coisas. Uma das coisas que você mencionou é que, neste momento, provavelmente essa necessidade de despertar pode ser motivada por aquele evento verdadeiramente catastrófico que foi desencadeado por um ataque cibernético. E eu sinto que estamos chegando à beira dessa percepção. Quero dizer, todo mundo meio que aponta para o Colonial Pipeline como um possível exemplo disso. E então mudanças que resultaram, em termos de um tipo de regulamentação de requisitos em nível governamental ou específico do setor, em termos de como melhorar a postura de segurança cibernética, tanto de organizações individuais quanto coletivas. E então você falou sobre o Zero Trust como se estivesse quase voltando ao futuro em termos de como podemos melhorar de forma realista a postura de segurança. E do jeito que você explicou, o Zero Trust não é necessariamente sobre esse tipo de estratégia de cibersegurança voltada para o futuro. Mas, na verdade, voltando ao que sempre foi a essência da segurança cibernética. De volta, mais ou menos no início dos tempos. Onde esquecemos isso? E por que esquecemos isso?

26:01 Richard Bird

Bem, a mecânica de por que é esquecido é interessante porque os vemos todos os dias. O mundo no espaço digital ficou cada vez menos seguro à medida que passamos de monolítico descentralizado para distribuído e altamente descentralizado. Quanto mais a arquitetura de TI se torna fragmentada e mais distribuída e descentralizada, piores se tornam as violações e explorações de segurança porque você não tem o comando e o controle que costumava ter. Agora que não digo isso para sair do meu gramado, garotos, o tipo certo de afirmação. O que estou dizendo é que o mecânico causou a explosão e teve consequências ruins para a segurança. E isso é algo que claramente vai piorar. E o motivo é que estamos nessa fase da tecnologia em que estamos alcançando os recursos atuais mais avançados de virtualização, que são HTTP e HTTPS da camada sete de aplicativo para aplicativo. Lembro-me de que, há alguns anos, um banco muito grande com o qual eu trabalhava na Europa me disse que sua meta em cinco anos era executar todos os seus aplicativos na Internet pública. E eu disse: “Vocês são loucos.” Eu disse: “Isso é insano”. E, no entanto, esse é esse mundo. Agora, esse foi um caso em que eu era míope. Eu disse: “Isso não é possível, nunca chegaremos lá”. E então a realidade é que esse é o mundo em que estamos. Mas agora, cada vez mais ativos que você está usando para gerar valor para gerenciar e distribuir transações não são coisas suas. E quanto mais as coisas não são suas, mais ampliamos os riscos da cadeia de suprimentos de todos nessa cadeia fazerem coisas sem nunca conversarem uns com os outros, sem nunca falarem uns com os outros sobre os controles de segurança uns dos outros. Em algum lugar abaixo da cadeia está um cara que digitou algumas linhas de código em algum repositório público em algum lugar, e ele já está comprometido. E você não tem mais controle sobre isso. Então, esse foi o motorista. Quanto mais distribuímos, mais descentralizamos, mais fragmentamos, mais percorremos caminhos como nenhum código, baixo código e quanto mais percorremos sem servidor, mais estamos apenas criando um ambiente distribuído que é rico em alvos para os malfeitores e um cenário incrivelmente difícil de gerenciar do ponto de vista da segurança. Então, esse é definitivamente o fator causal. E, como eu disse, não quero que ninguém me mande nenhuma avó feia; lá está aquele cara anti-nuvem de novo. A computação distribuída existe há muito tempo. Não pense que, como a AWS e o Google conseguiram estacionar algumas VMs com balanceadores de carga em seu próprio data center, aqueles de nós com cabelos grisalhos não sabem como é a aparência descentralizada e distribuída. Mas sim, acho que a peça fundamental de volta ao Zero Trust obviamente muda o jogo para mim, quando eu disse que era um resistor do Zero Trust nos primeiros dias porque, na prática, sou um velho identitário, que é que o Zero Trust parece um atrito. O atrito é o que faz com que você seja demitido. Mas eu estava completamente errado porque, por trás desse atrito, está essa realidade, e voltamos aos primórdios da computação, de que a causa dessas coisas ruins nesses ambientes altamente distribuídos é a existência, a intenção, o design, a engenharia, a existência permitida de confiança implícita e persistente em tudo. E essa existência de confiança aplicada e persistente é o que os malfeitores adoram. Aquele exemplo do AD Eu tenho uma conta antiga do AD com bons direitos que ninguém nunca retirou do diretório, que está implícita no exemplo de confiança persistente. E eu escolhi, ignorando ou deliberadamente ignorando, não corrigir isso. Estou permitindo um portal para que coisas ruins aconteçam. Tudo isso é baseado na confiança. E esse foi realmente o tipo de mudança para mim. Então, acho que você sabe, o caminho de melhoria, mesmo com a distribuição massiva de plataformas e infraestrutura de computação, o caminho de melhoria é reduzir bastante com o objetivo de eliminar a confiança implícita e persistente no máximo possível do espaço digital, o mais rápido possível.

31:11 Raghu Nandakumara

Para aqueles que não estão assistindo isso no vídeo e estão consumindo isso via áudio, minha cabeça está prestes a cair porque acabei de passar os últimos dois minutos apenas balançando a cabeça vigorosamente para cada palavra que Richard proferiu. Acho que essa é uma das abordagens mais sucintas, mas muito diretas e descritivas, para analisar por que o Zero Trust é necessário e a raiz do problema que estamos tentando resolver. Então, Richard, eu agradeço isso.

31:45 Richard Bird

Bem, demorei muito tempo para eu descobrir isso. E eu não sou o único que faz esse barulho. Um dos problemas com o apelido Zero Trust é que não chegamos à raiz real da confiança de que estamos falando. Sempre achei que deveríamos ter chamado o modelo de “seu cunhado incompleto, que pode ser viciado em drogas e sempre quer emprestar sua estrutura de segurança de ferramentas”. Porque todo mundo sabe do que estamos falando. Esse é um membro da família que você não dá a eles em sua casa e o código do abridor da porta da garagem. E temos muitos desses; temos muitos desses cunhados incompletos em nossos sistemas hoje. E isso remete à parte de contar histórias, ou seja, eu era reativo, emocionalmente reativo ao termo Zero Trust inicialmente. E isso fez com que eu estivesse terrivelmente errado sobre minhas próprias suposições. E eu, John [Kindervag], compartilhei a história, compartilho a história o tempo todo. Lembro-me de quando conheci John pela primeira vez pessoalmente, estávamos jantando. E eu disse: “Cara, eu não acreditei no que você estava vendendo.” E ele começou a falar comigo, e a única coisa que ele disse, que iluminou tudo para mim, ele disse: “Acho que os dados deveriam ter uma identidade”. E eu disse: “Uau, pise seus freios, cara.” É como Star Trek, e ainda estamos em Fred Flintstone. Assim que John começou a articular isso de uma forma — ele também é um ótimo contador de histórias — quando começou a articular de uma forma que não era um whitepaper, não foi outra especificação de engenharia que abriu meus olhos. E, como eu disse, admito plenamente que fui um idiota quando se tratava da noção de Zero Trust porque quero voltar e trazê-la de volta à base. Eu fiz muita segurança de mainframe em minha vida para obter identidade. E trabalhei com alguns pioneiros incríveis em operações bancárias ou de mainframe. E recebi essa revelação em um momento em que estava fazendo um programa muito grande no Chase. O Zero Trust já havia sido explicado para mim por esse pessoal de operações de mainframe. Porque o Zero Trust, o controle de acesso desde o início até começarmos a conectar outros dispositivos virtuais para poder acessar os principais dados do mainframe, sempre foi um Zero Trust, sempre foi um Zero Trust. E eu fiquei tipo, Uau, isso remonta ao que estou dizendo. Esses princípios funcionaram, garantiram, um sistema centralizado para um grande sistema centralizado, mas esses princípios funcionaram nesse ambiente. E não podemos argumentar que, bem, não é como a nuvem. Porque, como gosto de lembrar às pessoas, cerca de 90% de toda a computação acontece todas as noites quando uma alavanca gigante de desenho animado é puxada e o mainframe é processado. Eles ainda assim, cerca de 90% das cargas de trabalho quando todo mundo está usando a nuvem, poderiam usar a Internet, a nuvem após 30 anos de nuvem comercial e os mainframes ainda dominam o planeta. Não podemos usar essa racionalização da complexidade da nuvem quando se trata da complexidade do mainframe, e o enorme mundo monolítico é facilmente igualmente complexo. Mas nós inventamos essas desculpas por conveniência, eu acho. Porque no final das contas, quero que meu widget seja lançado mais rápido, quero que meu produto seja produzido mais rapidamente. Eu quero, eu quero, eu quero, eu quero, eu quero, e esses “eu quero” raramente vêm junto; eu também gostaria que fosse seguro. Você sabe, esses são os drivers que estão realmente complicando a proteção dessas coisas.

35:27 Raghu Nandakumara

Sim, com certeza. Quando você descreve a necessidade de um Zero Trust, essencialmente, o problema que se acumulou, você falou, essencialmente, sobre esse acúmulo de muito acesso implícito, que nós meio que, está lá, acreditamos que torna nossas funções mais fáceis e mais produtivas. Assim que ouvimos o termo Zero Trust, ou, dito de outra forma, a remoção do máximo de confiança implícita possível, para que haja muito menos tipo de acesso gratuito para qualquer tipo de invasor explorar. Acho que essa é a corcunda. E acho que você descreveu como esse é o obstáculo que muitas organizações levam tanto tempo para superar. Porque eles já pensam que, oh meu Deus. Você vai remover esse acesso, você vai quebrar essa coisa? E então, como eu posso ser produtivo? E acho que quando as pessoas pensam sobre isso, e na verdade, acho que daqui para frente, se você pensar sobre isso, dessa perspectiva, é mais fácil listar todas as coisas ruins que você quer que parem de acontecer? Certo, e essa é uma lista finita? Ou é mais fácil definir apenas coisas muito específicas? Você absolutamente precisa de algo para fazer? E apenas gerenciar isso? Qual desses dois é realmente mais fácil quando você pensa sobre isso?

36:49 Richard Bird

Acho que acreditamos que insistimos na questão dos menos privilegiados, não apenas na Zero Trust. Quero dizer, pelo menos o privilégio tem sido um componente funcional de ambientes de alto risco por muito tempo. Acho que estaríamos nos aproximando da declaração menos privilegiada sem nunca voltar ao que eu acho que você está realmente exagerando, ou seja, que tal menos funcional? Por exemplo, por que de um processo de fluxo transacional? E cara, você fala sobre uma toca de coelho que poderíamos abrir, e por que é tão fácil para os maus atores? Você sabe, depois de obterem alguma forma de entrada, autenticação por pontos, credenciais falsificadas, credenciais de sequestro, seja qual for o caso. Como eles podem atender a uma única chamada de autorização e usar e redirecionar essa chamada de autorização para acessar muitos outros dados para os quais nossa chamada de autorização nunca foi planejada? E funciona conforme o planejado? A ideia de que vou criar controles de camada de autorização com muitos privilégios. Não do ponto de vista da identidade, mas do ponto de vista funcional. Por exemplo, por que diabos eu preciso autorizar o acesso a um aplicativo que não tem absolutamente nada a ver com a experiência desse cliente? Ou aquela experiência dos trabalhadores de tecnologia? Nós fazemos isso o tempo todo. E eu acho que essa propagação, essa discriminação de coisas ruins versus funcionalidade, se tornou uma equação muito difícil. Porque, para trazer isso de volta ao seu ponto de referência, como quando comecei na segurança de identidade, a grande luta foi lutar contra chamadas de autenticação proprietária de desenvolvedores de aplicativos. E você teria pensado que o mundo ia acabar. Foi tipo, não, não, não, recebi minha chamada de autenticação; é meu aplicativo. Vá embora, me deixe em paz. E pensamos: Sim, mas você não precisa de uma chamada de autenticação autenticada para cada aplicativo. Podemos federar e fazer login único padronizado e, a propósito, isso se torna muito mais seguro. A propósito, é serviço; você não precisa mais lidar com essa sobrecarga e todo esse tipo de problema e manter seus próprios registros de controle de acesso e todo esse tipo de coisa. Essa luta foi uma guerra santa. Como se fosse horrível. E a razão pela qual foi horrível é porque, cerca de 15 ou 20 anos antes, o que tínhamos feito era olhar para nossos desenvolvedores de aplicativos e dizer: “Ei, vá criar um aplicativo”. E eles fizeram isso. E eles criaram um aplicativo. Eles disseram: “Bem, precisamos ter um fluxo de autenticação para essa coisa”. Não havia direção, nem securitização, nem nenhuma segurança da informação que estivesse inativa como parte desse plano. Você sabe, voltando à parte funcional, adivinhe? Esse é outro exemplo de segurança. Simplesmente não respeitamos as evidências, os dados da história. O que fizemos com a autorização? Bem, dissemos que os desenvolvedores de aplicativos vão em frente e conquistam. O que fazemos com as APIs? É só um widget. Vá em frente e use-o. Quão ruim poderia ser? Agora está sentado aqui e as pessoas dizem: “Não sei quantas chamadas de autorização; nunca sei quantas APIs tenho”. Eu não sei. E não há nenhum momento na história da segurança em que a resposta seja igual a coisas boas acontecerão do ponto de vista da segurança. Então, permitimos essa propagação massiva. Obviamente, falamos muito sobre a expansão rastreável de APIs. Mas há autorização, expansão, funcionalidade de recursos, expansão, tudo isso, e não estamos nem remotamente perto de aplicar a ideia de pelo menos nada a qualquer uma dessas coisas. E quanto mais vivemos em um mundo onde a expectativa é o máximo de acesso massivo a tudo em todos os momentos, independentemente de usarmos ou não, mais esses problemas continuarão a se acelerar exponencialmente.

40:47 Raghu Nandakumara

Então, vamos falar sobre a segurança da API e o trabalho que você faz para ser rastreável. Então, na primeira pergunta, eu estava examinando meus documentos de referência favoritos do Zero Trust esta semana; esses foram o modelo de maturidade Zero Trust da CISA e o NIST 800 207. E eu os examinei especificamente procurando a seção em que eles falarão sobre Zero Trust e segurança de API. E choque, horror, zero referências, raiz quadrada de zero. O que o Zero Trust tem a ver com a segurança da API? Vamos começar por aí.

41:29 Richard Bird

Bem, você sabe que a resposta mais curta da história é que eu estava sentado no palco com John Kindervag em Miami. Estávamos em um painel de palestras em grupo e ele estava acenando com a mão para a tela. E ele diz: “Quando acertamos o Zero Trust”, ele diz: “toda a segurança passa para a camada sete por política”. E eu pensei, acho que todo o sangue foi drenado do meu corpo. Mas eu puxei John de lado. Eu estava tipo, John, você sabe o quão ruim é a segurança da Internet e da Web? Esse é o estado do Nirvana sobre o qual temos que começar a falar. E isso coincidiu com quando entrei na Traceable. Um dos grandes fatores que contribuíram para ingressar na Traceable foi que fiquei frustrado com o tipo de progresso e inovação no espaço de soluções de identidade. E eu estava falando muito sobre exatamente o exemplo que dei antes sobre autorização, controle de reivindicações e segurança. E não há soluções para isso. Até hoje, algumas pessoas estão meio que experimentando, que fizeram alguns projetos científicos que eram do tipo que estavam acontecendo. Só que o que eu percebi foi que a autenticação de autorização é o combustível para a autorização da API e o nitrogênio absoluto para as APIs do mecanismo. Além disso, percebi que, se você pode securitizar APIs, agora você pode começar a securitizar o plano de autorização, entre uma série de outras coisas. E uma das coisas que eu acho fascinante é exatamente o que você descobriu. Vivemos em um mundo que ainda trata universalmente, ainda trata as APIs como se houvesse algum tipo de widget. Não são; é apenas uma chamada de aplicativo, a chamada do armazenamento de dados de aplicativos representa apenas um microsserviço. Tipo, o quão ruim isso poderia ficar? Bem, estamos descobrindo. Definitivamente, estamos descobrindo o quão ruim isso pode ficar porque o que as APIs representam é um microencapsulamento da versão definitiva da virtualização. Eles fazem uma coisa. E se você é um futurista incrivelmente inteligente e olha para trás na história, você diz: “Oh, espere um minuto, já vimos esse padrão antes”. Já vimos como era o mundo quando nenhum de nossos engenheiros sabia quantas regras de firewall tínhamos. Vemos como é nosso mundo quando nenhum dos líderes do nosso centro de operações sabia quantas máquinas virtuais tínhamos, certo, ou quantos domínios protegidos e autoprotegidos tínhamos versus aqueles que não estavam protegidos. Então, com o surgimento da API, acabamos de ter seis, sete ou oito anos de energia na criação de APIs que explodiram. A proposta de retorno de valor de todos os tipos de armazenamentos de dados que estavam abandonados, ativos e serviços, tem sido ótima. Mas tudo foi feito sem nenhuma segurança. E agora, quando analisamos as coisas que vemos, podemos continuar por horas falando sobre isso, tipo, uma das coisas que eu vejo como um CISO funcional, eu sou o CISO da nossa empresa, além de ser uma voz voltada para o mercado sobre todos esses assuntos. Eu vejo ataques toda semana; agora, isso me surpreende. E eu fico tipo, para onde isso vai se não tivermos segurança? A beleza das APIs e de sua associação com o Zero Trust é que as APIs funcionam com base na confiança implícita e persistente. É aí que tudo isso começa a se encaixar. Se eu analisasse todo o modelo primário de cinco pilares do Zero Trust, se eu observasse os princípios do Zero Trust, o que eu percebo é que o que John disse é absolutamente preciso. Se eu aplicar o Zero Trust de forma eficaz a todos os outros componentes da minha segurança e tecnologia, pilhas ou estratos, camadas ou o que você quiser chamá-los. Mas eu não fiz nada para securitizar APIs; acabei de subotimizar todo trabalho e todo investimento que fiz porque agentes mal-intencionados podem usar as APIs das APIs para servir como proxy para qualquer outro tipo de ataque. Em todas as outras camadas da pilha de segurança. Posso usar as APIs da API para anunciar seu aplicativo; posso usar as APIs da API para criar, adquirir e cadastrar contas fraudulentas. Posso usar as APIs para coletar dados. Já vi situações em que terabytes de dados foram perdidos. E os bandidos nunca entraram nos sistemas principais dessa empresa, todos baseados em API. E essa é a mensagem que venho comunicando. Para você, sobre a SP 800 207, bem como várias outras demandas regulatórias e de conformidade, a ausência do termo específico API é problemática, desafiadora e não durará muito mais. O NIST fez declarações muito claras de que prevê dar orientações específicas sobre APIs, FTC, SEC, OCC e os setores bancários que estão todos trabalhando ou já eliminaram referências específicas da API. Para aqueles que duvidam disso, se você é extremamente nerd e não tem mais nada para fazer, consulte o documento de conformidade de risco do modelo do Office of the Controller of the Currencies. E nesse documento de conformidade, ele diz especificamente: “Se você usa APIs de terceiros para inserir qualquer informação em seus modelos de avaliação corporativa, deve contabilizá-las e garantir que elas estejam seguras e provar que são assim”. Isso não é um indicador de ignorar as APIs pelo resto de nossa vida adulta. Um regulador entra, seus outros reguladores entram em ação, surge uma onda de demandas de controle e o NIST abordará essa ISO. A ISO não pode se dar ao luxo de não abordá-la com coisas como 222, que é uma especificação que eliminará o Swift. E para aqueles que, novamente, não conhecem esse lado bancário, a Swift movimenta apenas todas as transações comerciais internacionais que ocorrem entre grandes países e bancos de investimento, organizações comerciais que negociam em linhas internacionais. E você sabe, a ISO já está ciente do fato de que as APIs estão direcionando todo esse tráfego. Então, estamos à beira de um mundo extremamente diferente no que diz respeito ao reconhecimento da API para o estado atual. Minha primeira chance é que você acerte todo o resto no Zero Trust, não entende a segurança da API, não tem o Zero Trust. Desculpe dar essa má notícia, mas ela definitivamente está ganhando força no mercado.

48:18 Raghu Nandakumara

Então, antes, o que eu gostaria de perguntar a você, e vamos lá em um segundo, é: então, qual é a aparência do Zero Trust para segurança de API? Mas antes de chegarmos lá, eu gostaria, eu sei que [at] Traceable, você publicou, eu diria, no ano passado, o que eu acredito ser esse primeiro estado da Pesquisa de Segurança de API em colaboração com o Instituto Ponemon. Do seu ponto de vista, qual é a conclusão mais essencial desse relatório? Por exemplo, se há uma coisa que os líderes de segurança dos executivos deveriam tirar dela, o que é?

48:53 Richard Bird

Sim, coloque sua cabeça na areia. Eu não sei Não sei se eu poderia estar mais delicada. Mas quero dizer, essa é a verdade. São as porcentagens, os números, as respostas que saíram daquele relatório com Larry Ponemon que foram alucinantes para mim, preocupantes para mim. É uma prova matemática do que falamos anteriormente, ou seja, sei que tenho um problema, não estou fazendo nada a respeito. Dois anos atrás, as pessoas diriam que eu não tenho um problema de segurança de API. Eu ri e fui uma porta de entrada. Isso não era dissonância cognitiva. Isso foi ignorância intencional. Agora estamos nessa fase de dissonância cognitiva em que é muito raro eu falar com alguém no mercado e eles dizem: “Sim, não me preocupo com APIs. Tenho tudo sob controle.” No entanto, a grande maioria das pessoas que me reconhecem também diz: “Sim, mas ainda estamos pensando nisso”, “Não estamos fazendo nada a respeito” ou “Não sabemos o que fazer”. Obviamente, isso mudará nos próximos 12 a 18 meses, sejam demandas regulatórias ou mais violações ou qualquer outra coisa. Mas é certamente aí que estamos hoje. E os números nesse estado de segurança de APIs são incrivelmente positivos: cerca de 64% dos entrevistados disseram: “Sim, definitivamente tive uma violação ou exploração relacionada à API bem-sucedida”. E desses 64%, 75% disseram basicamente: “E isso aconteceu três vezes, pelo menos”. Sou péssimo em matemática, então não sei 74%, mais de 75% de 64% estão na população total de 1.800 empresas. Mas é um grande número e, mais importante, é um grande número e um mundo altamente descentralizado, distribuído e incrivelmente superconectado.

50:40 Raghu Nandakumara

Não tenho certeza se você pode ver minha tela porque a estatística que você citou “60% de experiência e violação relacionada à API e 75% tiveram pelo menos três” é literalmente a que estou vendo no momento. Então, isso me leva à pergunta: Zero Trust e segurança de API. Quando você está aplicando os princípios do Zero Trust à segurança da API, o que isso significa?

51:04 Richard Bird

Deixe-me primeiro dizer o que muitas pessoas pensam erroneamente que isso significa. Bem, muitas pessoas pensam erroneamente que isso significa que você precisa ter APIs criptografadas. Preciso ter alguma forma de autenticação, criptografia e alguma forma de criptografia de autorização. E a razão pela qual eles dizem que essa é uma suposição equivocada é, novamente, vamos dar uma olhada em 30 anos de história. Como o controle de autenticação e autorização funcionou para nós até agora? É tão fácil falsificar e/ou roubar credenciais de autenticação para uma API, possivelmente mais fácil, quanto para uma determinada conta e identidade. Uma das primeiras coisas que me lembro de dizer aos nossos cofundadores quando entrei quando eles me perguntaram qual era minha percepção da segurança da API, eu disse: “Já vi isso antes”. E eles dizem: “O que você veria?” E eu disse: “Bem, não sei o nome da empresa, um banco muito grande estava sentado no centro de comando com vários membros de diferentes agências policiais e de inteligência, porque uma certa nação mal-intencionada havia invadido nossos sistemas. E o que eles descobriram foi que as chaves SSH eram destinadas a aplicativos, servidores de aplicativos a dispositivos, dispositivos e comunicações. Mas se você os pegar, usá-los como seres humanos e usá-los para fazer o tráfego lateral leste-oeste, poderá causar uma grande quantidade de danos a um banco muito grande.” Tudo bem. E o sequestro de chaves SSH, embora não seja exatamente comparável à segurança da API, é transacional, um comparativo muito forte, certo, ou seja, eu posso aproveitar uma API para entrar, eu aproveito uma API para fazer coisas. E se a única coisa que está me impedindo de fazer isso é a criptografia de autenticação em um JSON ou JOT, na autorização, eu adoro isso como bandido. Então, em primeiro lugar, a criptografia não vai fazer isso por você, o que significa que, quando a criptografia não é mais à prova de falhas, você precisa estar no negócio de monitoramento contínuo e inteligência de ameaças sobre o comportamento de uma API. Na verdade, o Google lançou recentemente uma pesquisa sobre uma API que era explorável. E o Google realmente disse: “Bem, essa API funciona conforme projetado”. E minha resposta foi que um martelo funciona para a grande porcentagem do tempo em que é usado, cravando pregos e arrancando pregos das tábuas. Mas aquela vez em que é usado como arma do crime, também é muito eficaz. Não foi projetado para ser uma arma do crime. Nenhum cara que estava sentado lá fazendo seu primeiro martelo diz: “Bem, eu quero pregar pregos, e acho que podemos usar isso para matar alguém”. E essa é a natureza das APIs. As APIs são projetadas para fazer alguma coisa. Mas as APIs podem ser usadas para fazer muitas outras coisas, incluindo muitas coisas ruins. E se você não reconhece esse princípio, Zero Trust não é uma possibilidade em seu ambiente. Porque você criará APIs mais privilegiadas do que confiáveis que circulam em seu ambiente. E, a propósito, você não pode fazer mais nada para se proteger deles, porque eles parecem estar fazendo o que deveriam estar fazendo. Há muitas pessoas no mundo da tecnologia que querem mais carne com osso; eu entendo. Eles querem abordar as especificações de design e engenharia e me mostrar como fazer isso e, e eu não discordo de que isso seja necessário, e há muito disso. Mas o verdadeiro problema aqui é que não chegamos ao acordo fundamental de alto nível de que isso é um problema. Eu posso te dizer como securitizar suas APIs o dia todo. Se você não está pronto para fazer isso, não importa. Se não for operacionalizado, não existe. E acho que grande parte da discussão de hoje está mais uma vez convencendo as pessoas de que elas não têm apenas um problema. Mas esse problema é existencial. Esse problema vai criar consequências catastróficas. E se você quiser argumentar que estou apenas vendendo medo, incerteza e dúvida, e você não está prestando atenção porque, da última vez que verifiquei, todos devemos ter medo. Se você observar os resultados que ocorreram nas falhas de segurança atuais, todos devemos ter medo. E isso precisa ser o que está nos levando a ser mais curiosos intelectualmente. Além disso, para seguir estratégias de segurança como Zero Trust, vou meio que apertar o cinto de segurança de tudo isso. Como quando as pessoas discutem comigo sobre Zero Trust. E é demais e é muito complicado, ou qualquer que seja o argumento. Minha resposta é sempre a mesma: “Como a confiança implícita e persistente está funcionando para você?” Certo, porque a menos que você tenha uma alternativa ao status quo, não discuta comigo sobre o quão difícil é o Zero Trust, porque você nem vai saber como é isso até começar essa jornada. Caso contrário, você está apenas teorizando. E eu sei no que você está trabalhando, qual é sua suposição básica agora que está trabalhando; Não está funcionando.

56:07 Raghu Nandakumara

Acho que só para resumir o que você disse sobre o tipo de segurança da API, é como aquela divisão entre o que ela foi projetada para fazer e o que você pode, o que realmente está sendo feito com ela. E isso leva você de volta a um paralelo que John Kindervag costuma citar sobre tipos de regras de firewall. Coisas ruins acontecem dentro do permitido porque é isso que os atacantes estão explorando. Então, antes de concluirmos, como é o futuro do Zero Trust e da segurança de API do seu ponto de vista?

56:52 Richard Bird

Bem, acho que é o futuro, e há um argumento a ser feito de que estou excessivamente otimista sobre o que estou pronto para compartilhar. Mas eu acredito fervorosamente, ou seja, acredito que existe o potencial de um futuro com o Zero Trust, ou seja, o estado utópico, ou seja, se você pudesse aplicar o Zero Trust à maior porcentagem de sua propriedade digital, a cada camada, qualquer que seja sua arquitetura híbrida, ou se você ainda estiver no local, isso não importa. Você pode aplicar esses princípios de Zero Trust a cada peça do componente. E você direciona tudo para a camada virtual definitiva, o espaço da camada sete. Acho que podemos realmente ter sucesso e a securitização da camada sete, que está na segurança de APIs, terá um papel muito importante a desempenhar nisso. Acho que o controle avançado de identidade da próxima geração terá um grande papel a desempenhar nisso. Acho que há outras peças que entrarão em foco na camada sete. Mas se chegássemos a um estado em que esses componentes principais estavam totalmente bloqueados em uma estrutura de Zero Trust, poderíamos colocar todos os nossos recursos e nos concentrar fortemente nessa camada sete. E acho que, então, estamos em um espaço em que estamos em pé de igualdade com os malfeitores do que apenas mais uma notícia sobre outro grupo de servidores sendo bloqueados por causa do ransomware.

58:30 Raghu Nandakumara

Eu adoro isso. E acho que foi o que você disse. Atualmente, os atacantes de ransomware nem precisam ser tão bons para serem bem-sucedidos. Então, vamos realmente fazê-los trabalhar muito mais. Então, se eles querem ter sucesso, é melhor que sejam muito, muito bons.

58:49 Richard Bird

Outro tópico para outro dia, mas uma grande novidade sobre: vamos analisar os padrões físicos e a segurança e depois analisá-los no digital. Por exemplo, as pessoas podem discutir o quanto quiserem, mas se você dificultar as coisas para os malfeitores, você melhora a segurança e reduz os riscos. Sim, se você discorda disso, pergunte-me quantos tribunais você já visitou que não têm grandes barreiras de cimento e postes e todos os tipos de outros dispositivos de segurança física que agora os bloqueiam. É porque aprendemos nossa lição de que precisamos desacelerar as pessoas antes que elas façam coisas ruins naquele prédio. Precisamos aplicar esses mesmos tipos de padrões. E eu realmente amo o jeito que você expressou. Torne as coisas mais difíceis para os bandidos. Leve-os para espaços onde você tenha uma chance de lutar contra eles do ponto de vista da segurança, mas não lhes dê um terreno fácil. E acho que é isso que o Zero Trust faz. Acho que o Zero Trust elimina o terreno fácil.

59:42 Raghu Nandakumara

Eu adoro isso. Eu ia pedir que você compartilhasse sua analogia favorita do Zero Trust, mas acho que essa é uma declaração muito poderosa para terminar. Eu deveria dizer muito obrigado, Richard. Foi um prazer falar com você, e acho que o tempo que estamos conversando é quase insuficiente. Então, obrigado novamente, Richard Berg, diretor de segurança da Traceable AI. Eu encorajo todos a conferirem o relatório The State of API Security, que está disponível no site da Traceable AI, e realmente se aprofundarem no estado da segurança da API e em como o Zero Trust e a aplicação do Zero Trust podem ajudar a melhorar isso. Richard, obrigado.

1:00:25 Richard Bird

Obrigado, você realmente gostou.

1:00:27 Raghu Nandakumara

Obrigado por assistir ao episódio desta semana do segmento. Voltaremos com nosso próximo episódio em duas semanas. Enquanto isso, para obter mais recursos do Zero Trust, não deixe de visitar nosso site, www.illumio.com, e nos encontre no LinkedIn e no X usando os links em nossas notas do programa. Isso é tudo por hoje. Sou seu anfitrião Raghu Nandakumara e voltaremos com mais em breve.

‍