Expertos en seguridad blockchain se unen para mejorar la respuesta a las amenazas de la industria

Desde la primavera de este año, Isaac Patka de la firma de seguridad de inteligencia artificial Shield3 y el socio de investigación de Paradigm, Sam, más conocido como Samczsun, han estado trabajando junto con proyectos de blockchain para mejorar la seguridad a raíz de las amenazas cibernéticas que han seguido afectando a la industria.

El dúo lanzó SEAL 911 a principios de agosto, un bot de Telegram diseñado para conectar a los usuarios con expertos en seguridad examinados con el objetivo de mejorar la divulgación de ciberseguridad y prevenir rápidamente ataques de DeFi por valor potencial de cientos de millones de dólares.

Esa iniciativa se estableció con la esperanza de contrarrestar múltiples ataques relacionados con la industria que han tenido lugar este año, incluido el exploit de 70 millones de dólares de Curve Finance en julio.

Ahora la pareja espera subir la apuesta, estableciendo una nueva iniciativa de simulacro de emergencia diseñada para ayudar a los protocolos blockchain en ciernes en su lucha contra piratas informáticos maliciosos y posibles vectores de ataque.

Blockworks se acercó a Patka para tener una mejor idea de su empresa y de las lecciones que han aprendido en los últimos meses.


Bloques: ¿Puede explicarnos el inicio de esta iniciativa de simulacro de emergencia? ¿Cuál fue la fuerza impulsora detrás de esto?

Patka: Conocí a Sam por primera vez a través de nuestra amiga en común Jeanne. Conocí a Jeanne en el campamento DWeb 2022 cuando presentaba algunos de mis proyectos anteriores de código abierto y estándares. Escuché que Sam estaba buscando ayuda para construir una infraestructura de entrenamiento para que los equipos de protocolo practicaran estar en una sala de guerra antes de una emergencia real. 

La idea resonó en mí porque en ese momento estaba trabajando en algunas investigaciones y herramientas relacionadas con identificar y evitar ataques sociales y fallas de dependencia en comunidades descentralizadas. 

Me ofrecí como voluntario para ayudar a poner en marcha una prueba de concepto y, después de una rápida llamada de intercambio de ideas en la primavera, me puse a trabajar en delinear el marco de simulacro para Compound Labs, que fue el primer equipo que se ofreció a participar en un simulacro.

Bloques: Mencionaste el papel del “reconocimiento integral” en tus ejercicios. ¿Cómo este paso inicial prepara el escenario para el resto del ejercicio?

Patka: En la fase de reconocimiento me pongo al día con todas las funciones, contratos inteligentes, documentos e información disponible públicamente sobre el protocolo objetivo. Estoy tratando de descubrir cuál es la "superficie de control" para cualquier usuario [o] administrador privilegiado, cómo interactúa el protocolo con [o] se basa en otros protocolos, cómo monitorean el estado del sistema, qué procesos de riesgo existen, cómo introducen cosas como actualizaciones de protocolos o lanzamientos de nuevas funciones, y si hay inconsistencias en el sistema si se implementa en diferentes redes. 

Este reconocimiento se convierte en la base de los escenarios prácticos en los que hablamos de posibles problemas.

Bloques: El uso de simulaciones de mesa parece un enfoque interesante. ¿Podría explicarnos qué implican estas simulaciones y cómo informan los pasos siguientes?

Patka: Después de la fase de reconocimiento, preparé un guión con algunos escenarios y los analicé con todo el equipo durante una llamada. Estos escenarios nos ayudan a comprender sus procedimientos de respuesta a incidentes, su monitoreo y su estilo social/de comunicaciones. Las preguntas que nos hacemos en este momento son:

  1.  "X" ha sucedido. ¿Cómo fue alertado el equipo? ¿Hubo un seguimiento que detectó esto o alguien de la comunidad se comunicó con el equipo?
  2. ¿Quiénes son las partes interesadas y los expertos en la materia que saben cómo abordar esto?
  3. Si este incidente afecta otros protocolos, ¿quién tiene la información de contacto de ese equipo?
  4. Si esto requiere una respuesta de una firma múltiple, ¿quiénes son los firmantes y cómo se comunica con ellos? ¿Qué tan rápido crees que responderán?

Todo esto nos ayuda a encontrar posibles "puntos calientes" o cosas que queremos probar en un escenario real.

Bloques: ¿Qué criterios utiliza para seleccionar los equipos de protocolo con los que va a perforar? ¿Tiene algún requisito previo?

Patka: En esta fase, estamos tratando de trabajar con equipos donde creemos que podemos ayudarlos brindándoles algo de capacitación, pero también aprender de ellos sobre cómo operan los mejores equipos de protocolo en el espacio y compartir esas prácticas con la comunidad en general. 

Entonces, si bien no tenemos requisitos previos específicos, una buena opción ahora es un equipo que contribuya a un protocolo con una adopción bastante generalizada y que ya haya pasado por algunos incidentes, por lo que podemos aprender sobre una variedad de estilos de equipo.

Sin embargo, a medida que nuestra infraestructura se vuelve más sólida y más fácil de configurar, me gustaría trabajar con algunos equipos al principio de su protocolo para brindar capacitación a personas que nunca antes han estado en una sala de guerra.

Bloques: Su primera prueba fue con el protocolo compuesto. ¿Puedes profundizar en algunos de los desafíos únicos o lecciones aprendidas de esa prueba inicial?

Patka: El mayor desafío de planificación fue identificar un escenario que no fuera demasiado catastrófico como para resultar frustrante, pero sí lo suficientemente interesante como para resultar atractivo e implicara cierto diagnóstico y coordinación. 

Consideramos una variedad de cosas como fallas de protocolos externos, ataques de gobernanza y problemas de actualización de contratos. Terminamos simulando un error que hizo que el protocolo comenzara a perder fondos lentamente para que pudiéramos ver cómo su monitoreo retomaría el proceso y cómo responderían. 

Una de las mayores lecciones aquí fue en el nivel de coordinación social. Me impresionó la estrecha colaboración entre los desarrolladores del protocolo y los auditores y guardianes del protocolo para diagnosticar el problema.

A nivel técnico, el primer simulacro también implicó una gran cantidad de depuración de infraestructura a altas horas de la noche, obtención de la bifurcación de la red y del explorador de bloques, y monitoreo de la estabilidad de la infraestructura.

Bloques: Hablaste de evitar vulnerabilidades de día cero en tus simulacros. ¿Puede explicar el razonamiento detrás de esta decisión y cómo afecta la integridad del ejercicio?

Patka: La razón por la que evitamos vulnerabilidades de “día cero” u otras catástrofes muy extendidas es para que podamos involucrar al equipo de protocolo en algo a lo que puedan responder razonablemente y algo contenido dentro del ecosistema de su protocolo. Por ejemplo, no hemos realizado exploraciones sobre aspectos como errores del compilador o fallas en la capa de consenso. 

Sin embargo, creo que sería interesante simular estos problemas generalizados en simulacros entre protocolos en los que podríamos hacer que varios equipos y quizás todos los usuarios de los protocolos interactúen con un forknet donde algo salió mal para hacerlo realista y generar resiliencia social.

Bloques: Mencionaste las “tarjetas de procedimientos de emergencia” de Yearn durante tu prueba con ellos. ¿Qué tan común es esta práctica en otros protocolos? ¿La recomendaría como estándar?

Patka: Todavía no he visto otros protocolos que implementen tarjetas de procedimientos de emergencia como Yearn, pero lo recomiendo ampliamente. En muchos protocolos, pero especialmente con Yearn, hay muchas integraciones externas que requieren un contexto específico y experiencia en la materia. 

Cuando ocurre algún incidente, no querrás perder tiempo releyendo tus propios documentos y contratos en lugar de tomar medidas. Tener procedimientos de emergencia para escenarios específicos ayuda a los equipos a tomar decisiones con mayor rapidez y confianza. Escribir estos procedimientos de emergencia es un paso obligatorio del proceso de riesgo [y] diligencia de implementar las estrategias de Yearn. 

Recomendaría agregar procedimientos de emergencia a los procesos de riesgo/diligencia para otros protocolos, por ejemplo, al decidir si integrar o no varios activos como fuentes de garantía o agregarlos a los mercados.

Bloques: ¿Cuáles son algunos indicadores clave de desempeño que observa durante y después de un simulacro para medir su efectividad?

Patka: Busco algunos indicadores tanto de nuestro desempeño como organizadores del simulacro como de qué tan bien lo hizo el equipo. Por nuestra parte, estoy observando la estabilidad de nuestra infraestructura y qué tan bien se adapta el equipo al entorno simulado. 

En lo que respecta al proyecto, mantengo un cronograma de en qué momento se descubren los emisores, cuánto tiempo hasta que haya un diagnóstico y cuánto tiempo hasta que haya algún consenso sobre las medidas a tomar.

También enviamos una encuesta post mortem a los equipos para descubrir qué aprendieron, qué planean mejorar en sus procesos y cómo podemos mejorar nuestras simulaciones.

Bloques: ¿Puede compartir algunas tendencias generales o brechas comunes que haya notado en la seguridad de los protocolos como resultado de estos simulacros?

Patka: No estoy seguro de si se trata de una brecha, pero parece haber menos sistema formal de “de guardia” en varios protocolos de lo que esperaba. Existe un aspecto de "siempre en línea" de la cultura criptográfica en el que la gente parece simplemente asumir que el desarrollador o firmante multifirma adecuado estará disponible cuando sea necesario. 

En general, esto parece funcionar, pero tengo curiosidad por explorar si sería útil una mayor formalización de roles y horarios. También he notado que el monitoreo y la gobernanza varían para los protocolos en diferentes [capas 1/capas 2] donde tienen código implementado. Creo que hay margen de mejora en toda la industria en cuanto a cómo los protocolos que abarcan múltiples redes gestionan sus contratos.

Bloques: De cara al futuro, ¿hay planes para ampliar estos simulacros para incluir más protocolos o incluso diferentes tipos de pruebas?

Patka: Sin duda, estamos buscando ampliar los simulacros para incluir diferentes tipos de protocolos, o quizás múltiples protocolos al mismo tiempo. También queremos llegar al punto en que sean lo suficientemente fáciles de ejecutar como para que los equipos puedan realizar capacitaciones periódicas para que los contribuyentes de la comunidad desarrollen su experiencia en respuesta a incidentes. También me encantaría colaborar con nuevos ingenieros de seguridad que quieran aprender sobre seguridad diseñando escenarios y configurando simulaciones.

Esta entrevista ha sido editada por brevedad y claridad.


No se pierda la próxima gran historia: únase a nuestro boletín diario gratuito.

Siga el juicio de Sam Bankman-Fried con las últimas noticias desde la sala del tribunal. 

Fuente: https://blockworks.co/news/blockchain-security-experts-team