Cuestionando el Status Quo

00:05 Richard Bird — cita de apertura

“Cuanto más distribuimos, más descentralizamos, más fragmentamos. Cuanto más vamos por caminos de cosas como sin código, código bajo, más nos quedamos sin servidor; solo estamos creando un entorno distribuido que es un entorno rico en objetivos para los malos actores, y un paisaje increíblemente difícil de administrar para nosotros desde el punto de vista de la seguridad”.

00:28 Raghu Nandakumara

Bienvenido a The Segment, un podcast de liderazgo Zero Trust. Soy su anfitrión, Raghu Nandakumara, jefe de Soluciones Industriales en Illumio, la empresa de segmentación Zero Trust. Hoy, me une Richard Bird, Chief Security Officer de Traceable, líder en seguridad de API. Con décadas de experiencia en ciberseguridad y TI que abarca el mundo corporativo y de las startups. Richard es miembro sénior del Cyber Theory Zero Trust Institute y miembro ejecutivo de Cyber Edboard. Es conocido en todo el mundo por sus tatuajes, pajaritas y conocimientos de expertos sobre seguridad API, Zero Trust e identidad digital. Hoy, Richard se une a nosotros para discutir cómo ser un tecnólogo no tradicional abordando la disonancia cognitiva en ciberseguridad y la intersección entre Zero Trust y la seguridad de API. Entonces, hemos tenido el placer de [tener] al padrino de Zero Trust en este podcast. Hemos tenido el mismo Dr. Zero Trust. Hemos tenido toda una colección de otras luminarias de ciberseguridad y tecnología. Pero esta es absolutamente la primera vez que tenemos una estrella de rock en nuestro podcast. Entonces, con eso, me da un gran placer dar la bienvenida al invitado de hoy, Richard Bird, Chief Security Officer de Traceable AI. Richard, gracias por acompañarnos.

02:01 Ricardo Pájaro

Muy emocionado por la conversación. Gracias por tenerme.

02:04 Raghu Nandakumara

No puedes estar más emocionado que yo, Richard. Estaba mirando tu perfil de LinkedIn, y noté que tenemos al menos arcos de carrera muy similares. Ambos pasamos de 15 a 20 años en la industria de servicios financieros antes de pasar a “tierra de vendedores”. En ese punto, todas las comparaciones se detienen. Solo me alegra decir que existe ese paralelismo antes de que nos metamos en él: un poco de antecedentes sobre ti y lo que te ha traído aquí a lo que estás haciendo hoy.

02:31 Richard Bird

Bueno, creo que lo que me trajo hasta aquí fue mi asociación con algunos de los personajes turbios que mencionaste, todos amigos míos. Y cuando hablamos de Chase Cunningham y John Kindervag, las historias que compartiremos a lo largo de esta discusión, realmente giran en torno a cómo nos hemos ofrecido continuamente como voluntarios para ser parte de las trayectorias profesionales particulares de cada uno o de los dominios de control de experiencia y antecedentes. Y ha resultado en solo una gran oportunidad en sinergia de estar juntos en varios canales diferentes, o ser voluntario por uno u otro, que tengo que unirme a ellos. Entonces, solo mantengo buena compañía, supongo que es por eso que estoy aquí. Pero ya sabes, ha llegado a ser — mi biografía está un poco enhebrada después de unos años diciendo las mismas cosas una y otra vez. Pero sí, hice roles corporativos durante 20, casi 25 años. Y en el transcurso de esos 25 años, alrededor de 16 o 17 de ellos en servicios bancarios y financieros, procesamiento de pagos, primeros días de la burbuja de internet, y pagos de persona a persona y ese tipo de cosas y fueron elegidos por amigos y colegas para entrar en la seguridad de la información allá por los primeros inicios de la Seguridad de la Información Centralizada como un servicio dentro específicamente de JPMorgan Chase. Le digo a la gente que mi número colectivo de años en Chase fueron 11, que son 137 años de mi vida que nunca volveré a volver. Definitivamente envejece en años de banquero de perros. Pero también vi muchas cosas desde el principio muchas cosas que ahora están entrando en el foco para las organizaciones y empresas hoy en día, que eran problemas que una organización como Chase estaba viendo hace una década o más. Pero también que una organización como Chase tenía los recursos financieros y la experiencia para abordar en ese entonces. Entonces, siempre me gusta decirle a la gente que no soy un experto. Acabo de tomar muchas de las palizas y acumulé moretones y cicatrices antes que mucha otra gente lo hacía en seguridad. Y por lo general soy un post que suena mejor para lo que no hacer que para lo que son grandes mejores prácticas porque lo he hecho mal mucho en mi carrera y aun así logré sobrevivir y tener la oportunidad de platicar con ustedes hoy.

04:51 Raghu Nandakumara

Solo he estado riendo, sonriendo tanto escuchándote decir eso porque resuena completamente con mi propia experiencia. Al ver tantos de esos desafíos, a menudo un par de años antes de que el resto de las organizaciones y otras industrias vean esos mismos desafíos. Y esencialmente tener las cicatrices para ahora poder unirte al otro lado y decir: “Sí, así es como deberías estar resolviendo el problema”, o “Estos son los aprendizajes que he tenido, y así es como podrías hacerlo mejor”. Tan absolutamente asociado con eso. Antes de llegar más lejos, me emociona mucho hablar contigo sobre el trabajo que estás haciendo en Traceable. Pero disfruté leyendo tu post de LinkedIn sobre eso Joe Strummer y la influencia de la música en tu carrera. Me encantaría que compartieras eso con el público antes de que vayamos más allá sobre cómo tu interés por la música, tu pasión por la música realmente ha influido en cómo piensas y cómo comunicas ideas clave y 10 desafíos clave en la actualidad.

05:57 Ricardo Pájaro

Bueno, me alegra mucho que hayas sacado ese porque me va a dar una oportunidad para un desvergonzado enchufe sobre algo en lo que estoy trabajando. Pero también me da la oportunidad de compartir. Hay muy pocas cosas en mi carrera de las que simplemente estoy súper orgulloso. La única cosa de la que estoy realmente orgullosa, y en la que no reservo ego por ser un tecnólogo no tradicional. No vengo de antecedentes MIS o CIS, no digo que en un comercio de tecnología, hay algo malo en eso. Pero vengo de una pista totalmente diferente. Vengo de una especialización en ciencias políticas con un enfoque en la teoría de las relaciones internacionales y una menor en lengua japonesa. Y yo era gerente de proyectos de construcción. Después de que salí del ejército, simplemente resultó estar justo en el nexo del tiempo cuando la gestión de proyectos era una habilidad extremadamente crítica necesaria en tecnología, y alguien vio algo en mí que yo no veía a mí mismo. Y me contrataron. Y esa persona sigue siendo mentora casi 30 años después. Comparto ese trasfondo porque las piedras de toque para mí sobre ser un orador apasionado, o ser un presentador apasionado, o ser un investigador apasionado en torno a temas que están sucediendo en la sociedad, ya sean técnicos o de otro tipo. Es esta noción, esta noción artística de musas. Lo que te inspira es diferente a lo que te apasiona. Lo que te inspira y, para mí, mis inspiraciones son, están muy fuertemente alineadas con las artes. La música simplemente resulta ser uno de ellos. Y como la pieza que escribí parece tocar un poco el corazón y el alma de mucha gente. Sabes, crecí en los inicios de la música punk rock. No me avergüenza decir que probablemente sentaba un pensamiento bastante fuerte contrario o cínico, o incluso antiestablishment en mí cuando era niño, y sigue ahí. Lo enterré bajo más de 20 años en el mundo corporativo, donde no se le permite decir cosas en público, no se le permite compartir pensamientos. Tienes que pasar por 17 aprobaciones diferentes para incluso estar en un podcast, y mucho menos ir a hablar públicamente. Y mantuve un tope en eso durante un cuarto de siglo. Y esa pieza me vino cuando alguien me preguntó: “¿Cómo fue que se te ocurrió tantas analogías o metáforas salvajes?” o, “Todo este enfoque narrativo que tomas a las cosas”. Yo dije: “Bueno, son dos cosas. primero, crecí un hijo capitán de barco pesquero, así que obtuve un doctorado en narración de historias”. Y la segunda es que todos estos elementos de mi pasado y mi experiencia, crecer escuchando música, escuchando increíbles letristas y músicos atacan temas y problemas dentro de la sociedad con sus palabras, simplemente se convirtió en una inspiración natural y piedra de toque de motivación para mí personalmente”. Cuando hablo públicamente, uno de mis objetivos es realmente conectar emocionalmente con la gente. Y eso es complicado porque no estás conectando con una emoción. Al igual que la música, no te estás conectando en una emoción. Alguien podría estar jubiloso al escuchar una canción, pero el júbilo y el baile son dos componentes diferentes de esa experiencia, ni uno solo. Y dije tapón desvergonzado, ya que llevo haciendo esto, una especie de personalidad y hablando y ese tipo de rol durante los últimos cinco o seis años, me di cuenta que lo que he vivido y lo que pienso es enseñable. Voy a maldecirla, pero estoy en las ediciones finales de un libro llamado Famoso con 12 personas. El subtítulo es una guía de carrera sobre cómo ser un experto reconocido internacionalmente en algo que a nadie le importa. Y la noción para el libro es que en mi viaje en los últimos cinco o seis años, he conocido a un tremendo número de personas microfamosas. Y la mayoría de esas personas microfamosas son como yo. Están inspirados en cosas que están lejos de nuestras carreras y nuestra experiencia laboral. Y estos micro famosos no solo están en seguridad. Me senté al lado de un tipo en un avión, y nos pusimos a platicar y, y él dice: “Sí, bueno, soy coordinador de acrobacias”. Me bajé del avión y descubrí que él es el coordinador de acrobacias. Él es el tipo que enseña a todos los demás acrobacias y acrobacias de Hollywood. Tiene mil personas que lo siguen. Y pensé que nunca había oído hablar de él antes y probablemente nunca volveré a saber de él. Pero qué dinámica tan interesante para alguien poder tener ese tipo de impacto en la vida de las personas. Y de ahí es realmente de donde vino toda esa energía para escribir esa pieza de Joe Strummer. Al igual que ¿qué podemos hacer como no ser estrellas de rock y músicos? ¿Qué podemos hacer para inspirar ese mismo tipo de emoción, motivación y pasión y ser incluso una musa para otros en nuestro propio campo de especialización? Y así es realmente como surgió todo eso.

11:12 Raghu Nandakumara

Eso me encanta. Muchas gracias por compartir eso. Y una humilde petición de mi parte: Cuando ese libro se publique, espero que sea un tipo real de formato de libro físico, no solo como un ebook. Me encantaría una copia firmada de ti mismo.

11:27 Ricardo Pájaro

Ese es el plan. Tengo edad suficiente como para que todavía me encanta el papel.

11:12 Raghu Nandakumara

Mi esposa bromea conmigo que la razón por la que compro libros es solo para poblar nuestra estantería. Y yo digo: “Sí, absolutamente, descaradamente, es para el telón de fondo cuando estoy en llamadas”. Pero el punto narrativo que hiciste, y realmente encontrar esa inspiración para contar historias, personalmente lo encuentro en el papel que hago hoy, y estoy seguro que encuentras en tu rol, es que es muy importante conectar, especie de, supongo, el valor técnico que los productos que construyen nuestras empresas, realmente conectan con la esencia del comprador, y realmente el resultado que están tratando de lograr. No se trata de la tecnología; no se trata de cómo vas y haces algo. Se trata de cómo te voy a ayudar. ¿Por qué es importante para ti? Y creo que contar historias es tan importante, ¿te parece eso?

12:15 Ricardo Pájaro

Bueno, no sólo encuentro que pienso que en el proceso de escribir, lo cual no me viene natural. La escritura de formato largo no me viene natural. En el proceso de escribir, realmente tuve que averiguar por qué es eso en, seguridad específicamente, que luchamos por comunicarnos entre nosotros. Nos esforzamos por comunicarnos en lo que se refiere a, aquí está el problema del negocio, necesito ayudarte a resolver. Como proveedor de soluciones técnicas, luchamos como tecnólogos con esto, como el requisito de negocio que tengo. Y los tecnólogos no lo consiguen. Y creo que lo que me di cuenta fue cuando hablamos de personas en el mercado, que estamos tratando de mostrar un camino para resolver problemas para esos compradores realmente universalmente, están operando en la capa abstracta. Es una abstracción. Reconocen que hay un problema; reconocen que ven algún tipo de brecha o hackeo en las noticias. Pero equiparando eso a todas las diferentes palancas y piezas y oponentes dentro de una organización que tienen que ser jalados o empujados o retorcidos o afinados para evitar que eso malo suceda. Es extremadamente difícil. Y luego, cuando lo llevamos de vuelta a ingenieros, ingenieros de soluciones y arquitectos de seguridad. Todos vivimos en el mundo de la especificación. Todos estamos hablando de esas palancas, todos estamos hablando de esos interruptores, y estamos hablando de... Y tenemos esta gran brecha de disonancia cognitiva. Eso sucede. Y sí creo que contar historias es uno de los componentes principales, una de las principales herramientas que llena ese vacío. Existe la posibilidad de una capa de traducción universal entre esas partes entre esas diferentes entidades. Porque al final del día, todos estamos en el mismo negocio tratando de resolver estos problemas. Y cuando nos preguntamos, ¿por qué vamos tan despacio y llegamos ahí? Creo que gran parte de ello es solo esto: una fractura sustancial en la comunicación y la comprensión. Es decir, estoy trabajando en la capa de abstracción, estoy trabajando en la capa de especificación. Y no hay nada como atornillarlo todo junto. Y creo que contar historias es un componente crítico de eso.

14:38 11:12 Raghu Nandakumara

Entonces usas el término disonancia cognitiva, y en realidad, no vas a creer esto, pero yo estaba en mi investigación para esto y escuchando algunas de las otras piezas que has sacado, y te cito, dijiste, “disonancia cognitiva, hay una brecha masiva entre sé que tengo un problema, y estoy haciendo algo al respecto”. Entonces, ahora vamos a cavar un poco para llegar a ese nivel. Esto lo has visto en tu experiencia, y lo he visto en mis experiencias que haces una evaluación. Digamos un ejercicio de equipo rojo. Identifica sus áreas de vulnerabilidad y dice: “Oh, sí, sé que soy vulnerable ahí. Entiendo que necesito hacer algo al respecto”. Seis meses más adelante, 12 meses más adelante, repetir el ejercicio, existen las mismas vulnerabilidades. Necesito hacer algo al respecto: repetir, repetir, repetir. ¿Por qué esa brecha? ¿Por qué esa incapacidad para dar el salto y solucionar los problemas que necesitan ser arreglados?

15:35 Ricardo Pájaro

Sí, hay un par de componentes ahí. El primero es que la brecha representa la brecha entre conocimiento y amenaza, o conocimiento y riesgo o conocimiento y experiencia. Yo había mencionado que estaba en el ejército. Teníamos un sargento simulacro mientras iba por una de nuestras escuelas. Y una tropa joven entró y estaba parada frente a ellos quejándose de una situación que estábamos viviendo en un ejercicio en particular. Y el sargento simulacro lo miró, y le dijo: “Te escucho, pero no te puedo sentir del todo”. Y me pareció brillante. Eso lo he usado durante años. Dijo: “Yo registro tu problema. No obstante, no hay nada que pueda o vaya a hacer al respecto. Y creo que hay mucho de eso en el mundo corporativo porque es fácil tirar piedras. Creo que es uno de los beneficios que tengo es que mis rocas se tiran un poco menos duras porque he estado de ese lado de la pared. He estado en ese lado de la ecuación que tienes tantas prioridades en competencia. Tienes tantas plataformas en llamas; tienes tantos problemas. He tenido programas completos que se descarrilaron para tratar de reducir el riesgo, tangiblemente, en un área en la que hemos trabajado durante un par de años, porque algunos ejecutivos llamaron y dijeron: “Oye, fui a alguna conferencia, escuché esto, ustedes necesitan ponerse a trabajar en eso ahora”. Simplemente hay una tremenda cantidad de distracción en el mundo corporativo. Entonces, saber de una cosa no es suficiente. Y creo que una y otra vez, seguimos demostrando que saber sobre una cosa no impulsa cambios de comportamiento. En lo que se refiere a mitigar el riesgo asociado a una cosa, es algo que tenemos que volver a poner en las operaciones de riesgo. Las operaciones de riesgo han luchado a lo largo de los años para crear fórmulas que realmente se afinen en los costos y las consecuencias de los riesgos. Para las clasificaciones de riesgo, siempre traigo a colación el libro de Nassim Qualy, El cisne negro, en cualquier momento hablo de riesgo porque es un libro tan confirmando sobre “por qué”. Para responder a su pregunta, no podemos avanzar porque operamos continuamente como ejecutivos y practicantes con la creencia de que estos riesgos de cola larga no van a suceder. Y como saben, Qualys habla en su libro de que la historia demuestra que esos eventos de cola larga ocurren con mucha más frecuencia de lo que podríamos esperar. Y así eso es volver a esa disonancia cognitiva. Si creo que un riesgo está tan lejos que no tengo que preocuparme por ello. Estoy seguro, al igual que tus antecedentes, has escuchado esto una y otra vez: “Sí, supongo que ese es un problema realmente grande. Pero no estoy en la banca, así que no estoy realmente preocupado por eso”. Sabes, ¿cómo fue eso para todos en ransomware? Derecha. Ya sabes, existe la expectativa de que hay un gradiente de tipos de ataque que representan la escala de complejidad y madurez. Y esto acaba de salir en una conversación ayer, como, alguien me preguntó, estaban como, bueno si alguien está atacando una Chase, o Bank of America o ciudad de esta manera, porque realmente una gran empresa y una organización realmente complicada, las pequeñas o medianas empresas no necesitan preocuparse por el mismo ataque. Y yo estaba como, eso, chico, lo acabas de clavar. O sea, va a ser muy cínico sobre que fue como, lo acabas de clavar. Ya sabes, las personas están dimensionando sus programas de seguridad en función de lo que creen que son sus riesgos para su dominio particular o vertical. Mientras tanto, los malos actores no lo están pensando así. Si los malos van, a donde pueda entrar, como, si voy a usar un ataque sofisticado, genial. Voy a usar un ataque no sofisticado. Genial. Si obtengo tus datos. Eso es todo lo que realmente importa. Y creo que eso es realmente toda la confusión de la complejidad que tenemos en este mercado. Eso mantiene esa rueda de disonancia cognitiva girando y girando de año en año en desempeño de seguridad.

19:50 Raghu Nandakumara

¿Cómo cambiamos eso?

19:53 Ricardo Pájaro

Ahí está la respuesta practicante adulta, y luego está la respuesta cínica.

19:58 Raghu Nandakumara

Yo quiero ambos.

20:02 Ricardo Pájaro

Bueno, voy a empezar con la respuesta cínica. Y es reflejo de una conversación que apenas estaba teniendo con un mentor el otro día; el mentor me dijo, como: “A lo mejor deberíamos aconsejar empezar a aconsejar a los malos. Porque ellos escuchan, y nuestros colegas y nuestros amigos y nuestros compañeros practicantes no”. Y creo que es una declaración dura, pero no creo que sea del todo injusta. Y creo que eso plantea que la respuesta cínica a eso es, es que desde hace mucho tiempo, todos nosotros como practicantes decimos, bueno, solo tenemos que esperar a que ocurra lo más grande, la próxima brecha más grande y la gente finalmente cambie. Eso no ha funcionado. Y eso empieza a plantear la pregunta de ¿y si vemos una reacción en cadena? ¿Un evento catastrófico? ¿Y si vemos caer una red nacional de infraestructura en alguna nación? ¿Y si vemos una interrupción masiva para toda una red hospitalaria? Hemos visto casos aislados de salas quirúrgicas y salas de emergencia cerradas. Siempre he sido un firme creyente de que lo que realmente cambia el juego es cuando hay alguna forma de bajas masivas asociadas a la acción de un mal actor en el mundo digital. Y cuando dije eso hace unos años, la gente pensaba que era lo más oscuro que podría decir, y ahora digo que la gente dice: “Sí, lo entiendo”. Como si eso pudiera pasar. Entonces, creo que hay una cierta cantidad de este problema reflejado en esa disonancia cognitiva de la que estamos hablando bien, es decir, todavía no hemos visto algo lo suficientemente grande y malo como para finalmente despertar a la gente. Ahora bien, la respuesta profesional a eso es, que donde realmente empezamos a avanzar es cuando empezamos a ver un cambio significativo. En uno de los comportamientos más bizarros, creo, que he visto en seguridad, que es, y muchos profesionales de la seguridad se enojan cuando digo esto, pero creo firmemente que la seguridad es la única disciplina en el mundo corporativo donde nos negamos a aprender de la historia, los datos y la evidencia. Tenemos pruebas claramente frente a nosotros. Entonces, voy a dar solo un ejemplo muy específico. Tenemos evidencia claramente frente a nosotros con 25 a 30 años de historia: cuando un mal actor se mete a tu sistema, lo primero que hacen es ir a tu Active Directory. Y yendo al Active Directory, buscan capacidades e identidades obsoletas, anticuadas, deshabilitadas, pero no eliminadas. Se envuelven en todos estos derechos y acceden a subvenciones y autorizaciones, van a hacer cosas malas. Y como todo estaba en tu AD, tus sistemas internos de seguridad no se ponen al día porque parece que deberían estar ahí. Ahora bien, ese es un patrón que cualquiera que en seguridad sepa que es real; ellos saben que es evidencia respaldada. Y saben que es el camino primario para los malos actores. Y sin embargo, hoy puedes entrar en ocho, nueve de cada diez empresas y preguntarles: “¿Cuándo fue la última vez que limpiaste tu AD?” Ya sea Azure, ya sea en las instalaciones, escuchará grillos. Escucharán a alguien decir: “Bueno, sabes qué, eso se financió el año pasado y el año anterior, pero fue por debajo del resultado final, y no lo logramos”. Y yo estoy como, tan universalmente, lo sabemos, esta es una de las superficies de ataque más capitalizables en cualquier empresa. Y sin embargo, todos nos sentamos y vamos: “Sí, me desfinanciaron, y no vamos a trabajar en eso este año”. Eso es lo que digo cuando digo que continuamente nos negamos. Y eso vuelve a muchas preguntas antes era como, bueno, solo necesitas acertar lo básico. Personalmente, no creo que sea una declaración útil. Vuelve a la seguridad fundamental. ¿Está haciendo correctamente la seguridad fundamental? Y ya sabes, no para llevar al testigo aquí, pero eso fue lo que eventualmente, después de ser una resistencia desde hace mucho tiempo a Zero Trust, eso es esencialmente lo que me llevó a Zero Trust. Porque hay aspectos de Zero Trust que creo que vamos a diferenciar aquí un poco que en realidad se remontan a los inicios de la computación y son fundamentales. Y creo que si bien mucha gente piensa que Zero Trust es, avancemos hacia el futuro; la realidad es que hay aspectos de Zero Trust que son más o menos de, volvamos a los principios del pasado que sabemos que funcionaron, que son extremadamente útiles en el entorno actual, pero nos hemos olvidado y creo que ahí es donde empezamos a ver mejoras cuando volvemos atrás y abrazamos nuestras raíces. Y en segundo lugar, cuando empezamos a prestar atención a lo que los datos claramente publicados y los datos claramente divulgados nos siguen diciendo como nuestra debilidad una y otra vez.

24:40 Raghu Nandakumara

Solo escuchando todo eso y un tipo de tantas cosas en las que podríamos haber ahondado profundamente que sospecho que estarían aquí todo el día y toda la noche, mientras mi tiempo lo permita, no estoy seguro de que el tuyo sí. Entonces, solo un par de cosas. Una de las cosas que tocaste es que este ahora, probablemente esa necesidad de despertar puede ser impulsada por ese evento verdaderamente catastrófico que ha sido desencadenado por un ciberataque. Y siento que estamos llegando algo así a la cúspide de esa realización. Quiero decir, todo el mundo apunta de nuevo a Colonial Pipeline como un posible ejemplo de eso. Y luego cambios que luego han dado lugar, en términos de una especie de regulación a nivel de gobierno o tipo de requisitos específicos de la industria en términos de cómo mejorar la postura de ciberseguridad, tanto de organizaciones individuales, pero también es colectiva. Y luego ha hablado de Zero Trust como una especie de estar casi un poco de vuelta al futuro en términos de cómo podemos mejorar de manera realista la postura de seguridad. Y de la forma en que lo explicaste, Zero Trust no se trata necesariamente de este tipo de estrategia de ciberseguridad con miras al futuro. Pero en realidad, volviendo a lo que siempre estuvo en la esencia de la ciberseguridad. Derecha atrás, más o menos al principio de los tiempos. ¿Dónde olvidamos eso? ¿Y por qué lo olvidamos?

26:01 Richard Bird

Bueno, la mecánica de por qué se olvida es interesante porque los vemos todos los días. El mundo en el espacio digital se ha vuelto cada vez menos seguro a medida que hemos pasado de monolítico descentralizado a distribuido a altamente descentralizado. Cuanto más se fragmenta la arquitectura de TI y más se distribuye y descentraliza, peores se vuelven las brechas y exploits de seguridad porque no tienes el comando y el control que solías tener. Ahora que no digo eso como un “get off my lawn cloud kids”, correcto tipo de declaración. Lo que digo es que esta es la mecánica que ha impulsado la explosión y las malas consecuencias de seguridad. Y eso es algo que muy claramente va a empeorar. Y la razón es porque estamos en esta fase de tecnología donde estamos alcanzando las capacidades actuales definitivas para la virtualización, que es la aplicación a la capa de aplicación siete HTTP, HTTPS. Recuerdo que hace unos años, un banco muy grande con el que estaba trabajando en Europa me dijo que su objetivo en cinco años era ejecutar todas sus aplicaciones en internet público. Y yo estaba como, “Ustedes están chiflados”. Yo estaba como, “Eso es una locura”. Y sin embargo, ese es este mundo. Ahora ese fue un caso en el que yo era miope. Yo estaba como, “Eso no es posible, nunca vamos a llegar ahí”. Y entonces la realidad es que ese es el mundo en el que estamos. Pero ahora, cada vez más de los activos que está utilizando para generar valor para administrar y distribuir transacciones no son sus cosas. Y cuanto más no sean tus cosas, más extendemos los riesgos de la cadena de suministro de que todos en esa cadena hagan cosas sin conversar entre ellos, sin siquiera hablar entre ellos sobre los controles de seguridad de los demás. En algún lugar más abajo de la cadena hay algún tipo que arrancó un par de líneas de código en algún repositorio público en algún lugar, y ya está comprometido. Y ya no tienes ningún control sobre eso. Entonces, ese ha sido el conductor. Cuanto más distribuimos, más descentralizamos, cuanto más fragmentamos, más vamos por caminos de cosas como sin código, código bajo y más que pasamos sin servidor, más estamos creando un entorno distribuido que sea un entorno rico en objetivos para los malos actores, y un paisaje increíblemente difícil de administrar para nosotros desde un punto de vista de seguridad. Entonces ese definitivamente es el factor causal. Y, como dije, no quiero que nadie me mande ningún gramo desagradable; ahí está ese tipo anti-nube otra vez. La computación distribuida existe desde hace mucho tiempo. No pienses que debido a que AWS y Google lograron estacionar algunas VM con balanceadores de carga en su propio data center, que aquellos de nosotros con canas no sabemos cómo se ve descentralizado y distribuido. Pero sí, creo que la pieza fundacional de regreso a Zero Trust obviamente llega al punto de cambio para mí, donde dije que era una resistencia de Zero Trust en los primeros días porque soy un viejo tipo de identidad por práctica, que es Zero Trust se siente como fricción. La fricción es lo que hace que te despidan. Pero estaba completamente equivocado porque atrás de esa fricción está esta realidad y volvemos a los primeros días de cómputo, que el impulsor de estas cosas malas en estos entornos altamente distribuidos es la existencia, lo intencional, el diseño, lo ingeniado, la existencia permitida de confianza implícita y persistente en todo. Y esa existencia de confianza aplicada y persistente es lo que a los malos actores les encanta. Ese ejemplo de AD tengo una vieja cuenta AD con derechos de dios que nadie sacó nunca del directorio, eso está implícito en la confianza persistente ejemplificada. Y he elegido, ya sea ignorándolo o ignorándolo intencionadamente, no arreglarlo. Estoy permitiendo un portal para que sucedan cosas malas. Todo eso se basa en la confianza. Y ese fue realmente el tipo de cambio para mí. Entonces, creo que ya sabes, la vía de mejora, incluso con la distribución masiva de plataformas informáticas e infraestructura, la vía de mejora es reducir en gran medida con el objetivo de eliminar la confianza implícita y persistente en la mayor cantidad posible del patrimonio digital, lo más rápido posible.

31:11 Raghu Nandakumara

Para aquellos que no están viendo esto en el video y están consumiendo esto vía audio, mi cabeza está a punto de caerse porque acabo de pasar los últimos dos minutos solo asintiendo vigorosamente a cada palabra que Richard ha pronunciado. Creo que es uno de los enfoques más sucintos pero muy directos y descriptivos para analizar por qué es necesaria la Confianza Cero y la raíz del problema que estamos tratando de abordar. Entonces, Richard, te lo agradezco.

31:45 Richard Bird

Bueno, me llevó mucho tiempo averigarlo. Y no soy el único que hace este ruido. Uno de los problemas con el apodo Zero Trust es que no llegamos a la raíz real de qué confianza es de la que estamos hablando. Siempre pensé que debíamos haber llamado al modelo “tu cuñado inexperto, que podría ser un drogadicto y siempre quiere tomar prestadas tu marco de seguridad de herramientas”. Porque todo el mundo sabe de lo que estamos hablando. Ese es un familiar que no les das en tu casa y el código tu abrepuerta de garaje. Y tenemos muchos de esos; tenemos muchos de esos cuñados inadecuados en nuestros sistemas hoy en día. Y eso solo vuelve a la parte de contar historias, que es, fui reactivo, emocionalmente reactivo al término Zero Trust inicialmente. Y me hizo estar horriblemente, horriblemente equivocado acerca de mis propias suposiciones. Y yo John [Kindervag] ha compartido la historia, comparto la historia todo el tiempo. Recuerdo cuando conocí a John por primera vez en persona, estábamos cenando. Y yo dije: “Amigo, no creía lo que vendías”. Y empezó a platicarme, y lo único que dijo, que simplemente iluminó todo para mí, me dice: “creo que los datos deben tener una identidad”. Y yo estaba como, “Guy, bombea tus frenos, tipo”. Eso es como Star Trek, y todavía estamos en Fred Flintstone. Tan pronto como John comenzó a articularlo de una manera —él también es un gran narrador de historias— cuando empezó a articular de una manera que no era un whitepaper, no fue otra especificación de ingeniería lo que me abrió los ojos. Y como dije, admito plenamente que fui un imbécil cuando se trataba de la noción de Zero Trust porque quiero venir y traerlo de vuelta a lo fundacional. He hecho mucha seguridad de mainframe en mi vida para la identidad. Y trabajó con algunos pioneros increíbles en operaciones bancarias o mainframe. Y obtuve esta revelación en un momento dado cuando estaba haciendo un programa realmente masivo en Chase, Zero Trust ya me había sido explicado por estas personas de operaciones de mainframe. Porque Zero Trust, el control de acceso desde sus inicios hasta que realmente empezamos a enchufar otros dispositivos virtuales para poder entrar en los datos centrales de mainframe siempre ha sido una confianza cero, siempre. Y yo estaba como, Guau, esto se remonta a lo que estoy diciendo. Esos principios funcionaban, otorgaban, sistema centralizado para un sistema centralizado grande, pero esos principios funcionaban en ese entorno. Y no podemos hacer el argumento de que bueno no es como la nube. Porque como me gusta recordarle a la gente, alrededor del 90% de todo el cómputo cada noche ocurre cuando se tira de una palanca gigante de dibujos animados y los mainframes procesan. Aún así, el 90% y un par por ciento de las cargas de trabajo cuando todos en el mundo se van a la nube, podrían seguir gobernando el planeta Internet, la nube después de 30 años de nube comercial y los mainframes. No podemos usar esa racionalización de la complejidad de la nube cuando viene la complejidad del mainframe y el mundo monolítico masivo es fácilmente igual de complejo. Pero sí hacemos esas excusas por conveniencia, creo. Porque solo se reduce a, quiero que mi widget salga más rápido, quiero que mi producto esté en producción más rápido. Yo quiero, quiero, quiero, quiero, quiero, y esos “quiero” rara vez vienen con ellos; también me gustaría que fuera seguro. Ya sabes, esos fueron los conductores que realmente están complicando la tarea de asegurar estas cosas.

35:27 Raghu Nandakumara

Sí, absolutamente. Cuando estás describiendo la necesidad de un Zero Trust, esencialmente, el problema que se ha acumulado, hablabas, esencialmente, de esta acumulación de demasiado acceso implícito, que como que nosotros, está ahí, creemos que hace que nuestros roles sean más fáciles, más productivos. Tan pronto como escuchamos el término Zero Trust, o, dicho de otra manera, la eliminación de tanta confianza implícita como sea posible, de manera que haya mucho menos tipo de acceso freebie para que cualquier tipo de atacante explote. Creo que esa es la joroba. Y creo que describiste como esa es la joroba que tardan tanto en superar muchas organizaciones. Porque ya piensan eso, oh Dios mío. ¿Vas a eliminar ese acceso, vas a romper esta cosa? Y entonces ¿cómo puedo ser productivo? Y, y creo que cuando la gente piensa en esto, y en realidad, creo que en el futuro, si lo piensas, desde esta perspectiva, ¿es más fácil enumerar todas las cosas malas que quieres que dejen de suceder? Correcto, ¿y es esa una lista finita? ¿O es más fácil simplemente definir las cosas muy específicas? ¿Necesitas absolutamente algo que hacer? ¿Y solo manejar eso? ¿Cuál de esos dos es realmente más fácil cuando lo piensas?

36:49 Richard Bird

Creo que creemos belabor el punto sobre los menos privilegiados, no sólo en Zero Trust. Es decir, al menos el privilegio ha sido un componente funcional de los entornos de alto riesgo durante mucho tiempo. Creo que seríamos trabajadores cerca de la declaración menos privilegiada sin volver nunca a lo que creo que realmente estás empujando los bordes, que es, ¿qué tal menos funcional? Como, ¿por qué a partir de un proceso de flujo transaccional? Y chico, hablas de un agujero de conejo que podríamos bajar, y ¿por qué es tan fácil para los malos actores? Ya sabes, después de haber obtenido alguna forma de entrada, autenticación de puntos, credenciales falsificadas, credenciales de secuestrado, cualquiera que sea el caso. ¿Cómo es que pueden tomar una sola llamada de autorización y usar y reutilizar esa llamada de autorización para meterse en toneladas de otros datos para los que nuestra llamada de autorización nunca fue destinada? ¿Y funciona según lo diseñado? La idea de que voy a crear controles de capa de autorización que son demasiado privilegiados. No desde un punto de vista identitario sino desde un punto de vista funcional. Como, ¿por qué diablos necesito poder autorizar el acceso a una aplicación que no tiene absolutamente nada que ver con la experiencia de ese cliente? ¿O esa experiencia de los trabajadores tecnológicos? Lo hacemos todo el tiempo. Y creo que esa propagación que la itemización de cosas malas versus funcionalidad se ha convertido en una ecuación tan difícil. Porque para traerlo de vuelta a su punto de referencia, como cuando comencé en seguridad de identidad, la gran pelea fue librar llamadas de autenticación propietarias de los desarrolladores de aplicaciones. Y habrías pensado que el mundo se iba a acabar. Era como, no, no, no, recibí mi llamada de autenticación; es mi aplicación. Vete, déjame en paz. Y nosotros estamos como, Sí, pero no necesita una llamada de autenticación autenticada para cada aplicación. Podemos federarnos y hacer el inicio de sesión único estandarizado y, por cierto, se vuelve mucho más seguro. Por cierto, es servicio; ya no tiene que lidiar con ese overhead y todo ese tipo de problemas y mantener sus propios registros de control de acceso, y todo este tipo de cosas. Esa lucha fue una guerra santa. Como si fuera horrible. Y la razón por la que fue horrible es porque los aproximadamente 15 años, o 20 años antes, lo que habíamos hecho era mirar a nuestros desarrolladores de aplicaciones, y dijimos: “Oye, ve a construir una aplicación”. Y lo hicieron. Y construyeron una aplicación. Ellos estaban como: “Bueno, necesitamos tener un flujo de autenticación para esta cosa”. No había dirección ni securitización, o ninguna seguridad de la información que estaba a la baja como parte de ese plan. Ya sabes, volviendo a la pieza de funcionalidad, ¿adivina qué? Este es otro ejemplo de seguridad. Simplemente no tenemos respeto por la evidencia, los datos en la historia. ¿Qué hicimos con la autorización? Bueno, dijimos que los desarrolladores de aplicaciones salen y conquistan. ¿Qué hacemos con las API's? Es solo un widget. Solo sigue adelante y úsalo. ¿Qué tan malo podría ser? Justo y ahora tiene sentado aquí y, la gente va, “no sé cuántas llamadas de autorización; nunca sé cuántas API tengo”. No lo sé. Y no hay un momento en el historial de seguridad donde la respuesta sea igual a cosas buenas van a pasar desde el punto de vista de la seguridad. Entonces, hemos dejado esta propagación masiva. Obviamente, hablamos mucho de la proliferación de API rastreable. Pero hay autorización, extensión, funcionalidad de características, extensión, todo esto, y ni siquiera estamos remotamente cerca de aplicar la idea de lo menos a cualquiera de esas cosas. Y cuanto más vivamos en un mundo donde la expectativa es el máximo acceso masivo a todo en todo momento, lo usemos o no, más van a seguir acelerándose exponencialmente estos problemas.

40:47 Raghu Nandakumara

Así que hablemos sobre la seguridad de las API y el trabajo que haces para obtener Traceable. Entonces, la primera pregunta, estaba revisando mis documentos de referencia de Zero Trust favoritos esta semana; esos han sido el Modelo de madurez Cero Trust de CISA y NIST 800 207. Y pasé por estos buscando específicamente la sección donde van a hablar de Zero Trust y seguridad de API. Y choque, horror, cero referencias, raíz cuadrada de cero. ¿Qué tiene que ver Zero Trust con la seguridad de las API? Empecemos por ahí.

41:29 Richard Bird

Bueno, ya sabes que la respuesta de historia más corta es que estaba sentado en el escenario con John Kindervag allá en Miami. Estábamos en un panel de conversación grupal, y él está agitando su mano en la pantalla. Y él dice: “Cuando acertamos a Zero Trust”, dice, “toda la seguridad se mueve a la capa siete por política”. Y yo estaba como, creo que toda la sangre se drenó de mi cuerpo. Pero saqué a John a un lado. Yo estaba como, John, ¿sabes qué mal tener seguridad e internet y seguridad web todo eso es como, ese es el estado Nirvana del que tenemos que empezar a hablar. Y sucedió que coincidió con cuando me uní a Traceable. Uno de los principales factores que contribuyeron a unirme a Traceable fue que me frustré con el tipo de progreso e innovación en el espacio de soluciones de identidad. Y estaba hablando mucho sobre exactamente el ejemplo que di antes sobre autorización, control de reclamos y seguridad. Y no hay soluciones para ello. Incluso hasta el día de hoy, hay un par de personas que están experimentando, que consiguieron algunos proyectos científicos que eran cosas tipo en marcha. Excepto que lo que me di cuenta fue que la autenticación de autorización es el combustible para que la autorización de API es la nitrosa absoluta para las API del motor. Y también, me di cuenta que estaba como, bueno, si puedes securitizar APIs, ahora puedes empezar a securitizar el plano de autorización, entre un sinfín de otras cosas. Y una de las cosas que me parece fascinante es justo lo que descubriste. Vivimos en un mundo que todavía trata universalmente, todavía tratamos a las API como si hubiera algún tipo de widget. No lo son; es solo una llamada a una aplicación, la llamada al data store de aplicaciones solo representa un microservicio. Como, ¿qué tan malo podría ponerse? Bueno, nos estamos enterando. Definitivamente estamos descubriendo qué tan malo podría llegar a ser porque lo que representan las API es una microencapsulación de la versión definitiva de virtualización. Ellos hacen una cosa. Y si eres un futurista increíblemente inteligente, y miras hacia atrás a la historia, vas: “Oh, espera un minuto, ya hemos visto este patrón antes”. hemos visto cómo era el mundo cuando ninguno de nuestros ingenieros sabía cuántas reglas de firewall teníamos. Vemos cómo se ve nuestro mundo, cuando ninguno de nuestros líderes de centros de operaciones sabía cuántas máquinas virtuales teníamos, correcto, o cuántos dominios autoprotegidos protegidos teníamos frente a los que no estaban protegidos. Y así, el auge de las API, acabamos de tener seis u siete u ocho años de energía en la creación de API's que explotaron. La propuesta de retorno de valor de todo tipo de cosas, data stores que estaban varados y activos y servicios, y ha sido genial. Pero todo se hizo sin ninguna seguridad. Y ahora, cuando lo miramos las cosas que vemos, yo simplemente, podemos continuar durante horas en esto, como, una de las cosas que veo como un CISO funcional, soy el CISO para nuestra empresa, además de ser una voz de cara al mercado sobre todos estos temas. Veo ataques todas las semanas; ahora, eso me deja boquizado. Y yo digo, ¿a dónde va esto si no conseguimos seguridad a su alrededor? Lo hermoso de las API y su asociación con Zero Trust es que las API se ejecutan con confianza implícita y persistente. Que es donde todo esto comienza a juntarse. Si miré todo el modelo primario de cinco pilares de Zero Trust, si miro los principios de Zero Trust, lo que me doy cuenta es que lo que dijo John es absolutamente exacto. Si aplico Zero Trust de manera efectiva a todos los demás componentes de mi seguridad y tecnología, pilas o estratos, o capas o como quieras llamarlos. Pero no he hecho nada sobre la securización de las API; acabo de suboptimizar cada parte del trabajo y cada parte de inversión que he realizado porque los malos actores pueden usar las API de API para servir como proxy para cualquier otro tipo de ataque. En cada otra capa de la pila de seguridad. Puedo usar las API de API para dar su aplicación; Puedo usar las API de API para crear cuentas fraudulentas, tomar posesión, registrarme, puedo usar API para hacer raspado de carga útil de datos. He visto situaciones en las que se han perdido terabytes de datos. Y los malos nunca han entrado en los sistemas centrales para esa compañía, todos impulsados por API. Y ese es el mensaje que he estado comunicando. A su punto sobre SP 800 207, así como una serie de otras demandas tanto regulatorias como de cumplimiento, la ausencia del término específico API es problemática y es desafiante, y no va a durar mucho más tiempo. El NIST ha hecho declaraciones muy claras de que anticipan dar una dirección específica en torno a las API, la FTC, la SEC, la OCC y las industrias bancarias están trabajando o ya han dejado de lado las referencias específicas de API. Para aquellos que dudarían de esto, si eres extremadamente nerd y no tienes nada más que hacer, ve a buscar el documento de Cumplimiento de Riesgos de la Oficina del Contralor del Modelo de Divisas. Y en ese documento de cumplimiento, dice específicamente: “Si utiliza API de terceros para impulsar cualquier información a sus modelos de valoración corporativa, debe contabilizarlos y asegurarse de que sean seguros y demostrar que es así”. Eso no es un indicador de ignorar las API para el resto de nuestra vida adulta. Un regulador hace que sus otros reguladores vayan a saltar, va a haber una ola de demandas de control que van a entrar, y NIST va a abordar esta ISO, ISO no puede darse el lujo de no abordarlo con cosas como 222, que es una especificación que va a sacar a Swift. Y para aquellos que de nuevo, no conocen ese lado bancario, Swift solo mueve todas las transacciones comerciales internacionales que se realizan entre grandes países y bancos de inversión, organizaciones comerciales que comercian a través de líneas internacionales. Y ya sabes, ISO ya es consciente del hecho de que las API están impulsando todo ese tráfico. Entonces, estamos en la cúspide de un mundo extremadamente diferente ya que se relaciona con el reconocimiento de API para el estado actual, mi oportunidad de apertura es que obtienes todo lo demás bien en Zero Trust, no obtienes la seguridad API correcta, no tienes Zero Trust. Perdón por dar esa mala noticia, pero definitivamente está ganando tracción en el mercado.

48:18 Raghu Nandakumara

Entonces, antes, lo que me gustaría preguntarte, y vamos a ir allí en un segundo, ¿es así cómo es Zero Trust for API security? Pero antes de que lleguemos ahí, me gustaría, sé que [at] Traceable, has publicado yo diría en el último año, lo que creo es este primer estado de la Investigación de Seguridad API en colaboración con el Instituto Ponemon. Desde su perspectiva, ¿cuál es el punto de vista más esencial de ese informe? Como si hay una cosa que los líderes de seguridad de los ejecutivos deberían quitarle, ¿qué es?

48:53 Richard Bird

Sí, mete la cabeza en la arena. No lo sé. No sé si podría estar más en delicada. Pero quiero decir, esa es la verdad. Es los porcentajes, los números, las respuestas que salieron de ese reporte con Larry Ponemon fue alucinante para mí, preocupante para mí. Es una prueba matemática de lo que hemos hablado antes, que es, sé que tengo un problema, no estoy haciendo nada al respecto. Hace dos años, la gente decía que no tengo un problema de seguridad de API. Tengo una risa y una puerta de entrada. Eso no fue disonancia cognitiva. Eso fue ignorancia deliberada. Ahora estamos en esta fase de disonancia cognitiva donde es muy raro para mí hablar con alguien en el mercado, y ellos dicen: “Sí, no me preocupan las API. Lo tengo bajo control”. No obstante, la gran mayoría de las personas que me dan ese reconocimiento también dicen: “Sí, pero seguimos pensando en ello”, “No estamos haciendo nada al respecto”, o “No sabemos qué hacer”. Eso cambiará, obviamente, en los próximos 12-18 meses, ya sean demandas regulatorias o más brechas o lo que sea. Pero eso es sin duda donde estamos con eso hoy. Y los números en ese estado de seguridad de API, simplemente haciendo copias de seguridad increíblemente como, hubo un 64% de los encuestados que dijeron: “Sí, definitivamente he tenido una brecha relacionada con API o un exploit exitoso”. Y de esos 64%, 75% básicamente ha dicho: “Y ha pasado tres veces, al menos”. Soy súper malo en matemáticas, así que no sé 74%, más del 75% del 64% es de la población total de 1,800 empresas. Pero es un número grande, y lo que es más importante, es un gran número y un mundo altamente descentralizado, distribuido e increíblemente sobreconectado.

50:40 Raghu Nandakumara

No estoy seguro de que puedas ver mi pantalla porque la estadística que cotizaste "60% experiencia y violación relacionada con API y 75% experimentó al menos tres” es literalmente la que estoy viendo, en este momento. Entonces eso me lleva a la pregunta: Zero Trust y seguridad API. Cuando aplica los principios de Zero Trust a la seguridad de las API, ¿qué significa eso?

51:04 Richard Bird

Permítanme decir primero lo que mucha gente piensa erróneamente que significa. Bueno, mucha gente piensa erróneamente que significa que necesitas tener APIs encriptadas. Necesito tener algún tipo de autenticación, cifrado y algún tipo de cifrado de autorización. Y la razón por la que dicen que es una suposición equivocada es, de nuevo, echemos un vistazo a 30 años de historia. ¿Cómo nos ha funcionado hasta ahora el control de autenticación y autorización? Es igual de fácil falsificar y/o robar credenciales de autenticación para una API, posiblemente más fácil, como lo es para una cuenta e identidad determinada. Una de las primeras cosas que recuerdo haberles dicho a nuestros cofundadores cuando me uní cuando me preguntaron cuál era mi percepción de la seguridad de las API, dije: “He visto esto antes”. Y ellos dicen: “¿Qué verías?” Y yo dije: “Bueno, no puedo nombrar a la empresa, un banco muy grande estaba sentado en el centro de mando con varios números de miembros de diferentes agencias de aplicación e inteligencia, porque cierta nación mal actor se había metido en nuestros sistemas. Y lo que se dieron cuenta fue, es que las claves SSH estaban pensadas para aplicaciones, servidor de aplicaciones a dispositivo de servidor, dispositivo, comunicaciones. Pero si te haces con ellos, y los usas como ser humano, y los usas para hacer tráfico lateral este-oeste, puedes hacer una cantidad masiva de daño a un banco muy grande”. Muy bien. Y el secuestro de claves SSH, aunque no es exactamente comparable a la seguridad de API, es sobre una base transaccional, un comparativo muy fuerte, correcto, es decir, puedo aprovechar una API para entrar, aproveche una API para hacer cosas. Y si lo único que me está impido hacerlo es el cifrado de autenticación en un JSON o en un JOT, en la autorización, eso me encanta como un tipo malo. Entonces, en primer lugar, el cifrado no lo va a hacer por usted, lo que significa que cuando el cifrado ya no es su seguridad contra fallas, entonces tiene que estar en el negocio de monitoreo continuo e inteligencia de amenazas sobre el comportamiento de una API. De hecho, Google salió recientemente con una investigación sobre una API que era explotable. Y Google en realidad dijo: “Bueno, esa API funciona según lo diseñado”. Y mi respuesta fue, una garra martillo works está diseñada para el gran porcentaje del tiempo que se usa, clavando clavos y sacando clavos de tablas. Pero esa vez que se usa para un arma homicida, también es realmente efectivo. No fue diseñado para ser un arma homicida. Ningún tipo que estaba sentado ahí haciendo su primer martillo de garra dice: “Bueno, quiero clavar clavos, y creo que podemos usar esto para matar a alguien”. Y esta es la naturaleza de las APIs. Las API están diseñadas para hacer algo. Pero las API se pueden aprovechar para hacer muchas otras cosas, incluyendo muchas cosas malas. Y si no reconoce ese principio, la confianza cero no es una posibilidad dentro de su entorno. Porque va a diseñar con privilegios privilegiados, con derecho, sobre las API confiables que están dando vueltas en su entorno. Y por cierto, no puedes hacer nada más para securitizarte de ellos porque parece que están haciendo lo que se supone que deben estar haciendo. Hay mucha gente en el mundo de la tecnología que quiere más carne en el hueso; eso lo sé. Quieren ponerse manos a las especificaciones de diseño y las especificaciones de ingeniería y mostrarme cómo hacer esto y, y no estoy en desacuerdo en que se necesita, y hay mucho de eso. Pero el verdadero problema aquí es que no hemos llegado al acuerdo fundacional de alto nivel de que esto es un problema. Puedo decirte cómo securitizar tus APIs durante todo el día. Si no estás listo para hacerlo, no importa. Si no está operacionalizado, no existe. Y creo que gran parte de la discusión de hoy es una vez más convencer a la gente de que no solo tienen un problema. Pero este problema es existencial. Este problema va a crear consecuencias catastróficas. Y si quieres argumentar que solo estoy vendiendo miedo, incertidumbre, y la duda, y no has estado prestando atención porque lo último que comprobé, todos deberíamos estar asustados. Si nos fijamos en los resultados que han ocurrido en las fallas de seguridad en la actualidad, todos deberíamos estar asustados. Y eso tiene que ser lo que nos está impulsando a ser más intelectualmente curiosos. Y también, para perseguir estrategias de seguridad como Zero Trust, como que abrocharé todo esto. Como cuando la gente discute conmigo sobre Zero Trust. Y es simplemente demasiado y es muy complicado, o cualquiera que sea el argumento. Mi respuesta es siempre la misma, “¿cómo te está funcionando la confianza implícita y persistente?” Bien, porque a menos que tengas una alternativa al status quo, entonces no discutas conmigo sobre lo difícil que es Zero Trust, porque ni siquiera vas a saber cómo se ve eso hasta que empieces ese viaje. De lo contrario, solo estás teorizando. Y sé en lo que estás trabajando, cuál es tu suposición base ahora que estás trabajando; no está funcionando.

56:07 Raghu Nandakumara

Creo que solo para resumir lo que dijo sobre el tipo de seguridad de API, y es como esa división entre lo que está diseñado para hacer y lo que puede, lo que realmente se está haciendo sobre él. Y te trae de vuelta a un paralelo que John Kindervag cita a menudo en torno a una especie de reglas de firewall. Suceden cosas malas dentro de los permitidos porque eso es lo que los atacantes están explotando. Entonces, antes de terminar, ¿cómo es el futuro de la confianza cero y la seguridad de las API desde su perspectiva?

56:52 Richard Bird

Bueno, creo que el futuro, y hay que argumentar que soy demasiado optimista sobre lo que estoy dispuesto a compartir. Pero yo, yo lo creo fervientemente, que es, sí creo que existe el potencial de un futuro con Zero Trust, ese es el estado utópico que es, si pudieras aplicar Zero Trust al mayor porcentaje de tu patrimonio digital, a cada capa, sea cual sea tu arquitectura híbrida, o si todavía estás on-premise, no importa. Puede aplicar esos principios de confianza cero a cada parte de los componentes. Y usted conduce todo a la capa virtual definitiva, el espacio de capa siete. Creo que de hecho podemos tener éxito y la securización de la capa siete, que es en seguridad de API, tendrá un papel muy sustancial que desempeñar en eso. Creo que el control avanzado de identidad de próxima generación tendrá un papel importante que desempeñar en eso. Creo que hay otras piezas que entrarán en foco para la capa siete. Pero si llegamos a un estado donde esas piezas principales de componentes estuvieran completamente bloqueadas en un marco Zero Trust, entonces podríamos poner todos nuestros recursos y centrarnos fuertemente en esa capa siete. Y creo que entonces, estamos en un espacio donde estamos en una posición más igualitaria con los malos actores que solo otra noticia sobre otro grupo de servidores bloqueados debido al ransomware.

58:30 Raghu Nandakumara

Eso me encanta. Y creo que es lo que dijiste. Hoy en día, los atacantes de ransomware ni siquiera necesitan ser tan buenos para tener éxito. Entonces, hagamos que trabajen significativamente más duro. Para que si van a tener éxito, mejor que sean muy, muy buenos.

58:49 Ricard Pájaro

Otro tema para otro día, pero una gran cosa sobre echemos un vistazo a los patrones físicos y de seguridad para luego mirarlos en lo digital. Por ejemplo, la gente puede discutir todo lo que quiera, pero si lo haces más difícil para los malos actores, mejoras la seguridad y disminuías el riesgo. Sí, si no estás de acuerdo con eso, pregúntame por cuántos juzgados has pasado que no tengan grandes barreras de cemento y pilones y todo tipo de otros dispositivos de seguridad física que ahora los bloqueen. Es porque aprendimos nuestra lección que necesitamos frenar a la gente antes de que hagan cosas malas en ese edificio. Necesitamos aplicar ese mismo tipo de patrones. Y realmente me encanta la forma en que lo has expresado. Hagan que sea más difícil para los malos. Conmuécelos a espacios donde luego tengas una oportunidad de luchar contra ellos desde el punto de vista de la seguridad, pero no les des terreno fácil. Y creo que eso es lo que hace Zero Trust. Creo que Zero Trust elimina el terreno fácil.

59:42 Raghu Nandakumara

Eso me encanta. Te iba a pedir que compartieras tu analogía favorita de Zero Trust, pero creo que es una declaración tan poderosa para terminar. Debería decir muchas gracias, Richard. Ha sido un gran placer hablar con usted, y siento que por mucho tiempo que hayamos estado conversando casi no es suficiente. Entonces, gracias de nuevo, Richard Berg, Chief Security Officer de Traceable AI. Animo a todos a que vayan y revisen The State of API Security Report que está disponible en el sitio web Traceable AI y realmente ahonden en el estado de la seguridad de las API y cómo Zero Trust y la aplicación de Zero Trust pueden ayudar a mejorar eso. Richard, gracias.

1:00:25 Richard Bird

Gracias, realmente lo disfruté.

1:00:27 Raghu Nandakumara

Gracias por sintonizar el episodio de esta semana del segmento. Volveremos con nuestro próximo episodio en dos semanas. Mientras tanto, para obtener más recursos de Zero Trust, asegúrese de visitar nuestro sitio web, www.illumio.com y encuéntranos en LinkedIn y X usando los enlaces de nuestras notas de programa. Eso es todo por hoy. Soy tu anfitrión Raghu Nandakumara y pronto volveremos con más.

‍