A Data-Driven Approach to Cyber Risk Reduction How Data Powers Modern Security Operations

[Música]

[Música]

[Música]

[Música]

[Música]

Pues vamos a empezar, muchachos. Vamos a hacerlo como Dios manda. Un shot.

Bien, chicos, pues vamos a empezar. Eh, les presento a Lenevski. Vamos a hablarles de cómo podemos hacer que nuestras herramientas que nos entregan logs, cómo meterlas en contexto, que la seguridad sea más inteligente que ruidosa. Entonces, denle la bienvenida a Lenevski, por favor. Salud.

Todo tuyo.

Bueno bueno creo que falta proyectar los slides. Ah excelente. Pues, ah, bienvenidos. Voy a tratar de, tenemos mucho material por cubrir. Voy a tratar de ser breve porque creo que después de esto es la comida, ¿no? Y todos queremos ir a comer. Entonces esta plática va a ser un compendio de todas mis experiencias, lo que he aprendido en los últimos 3 años que me he desempeñado en este rol y ahorita vamos a ver un poco más de eso. Ah, un poco acerca de mí. Mi nombre es Leon Alevski. Yo soy de aquí de México, de Michoacán. Actualmente trabajo como ingeniero de seguridad en Google en California. Eh, soy un contribuidor del Open Source, el software libre. Tengo varios

proyectos, contribuyo con varias organizaciones. He trabajado en el mundo corporativo y en las startups y estoy obsesionado con la ciberseguridad. No, me encanta todo lo que tiene que ver con seguridad digital, me encanta asistir este tipo de eventos. Me gusta ver cómo el evento ha crecido en comparación del año pasado y en mis tiempos libres [Música] como que ya no avanzó. siguiente. Excelente. En mis tiempos libres, como ya digo, contribuyo con eh trato de de contribuir mucho a la comunidad y también impulsar a otras personas para que entren a la comunidad. Y siguiente, por favor. Este, soy parte, soy voluntario de una asociación que se llama Pacific Hackers en California. Nos enfocamos en ayudar a

gente que quiere entrar a a ciberseguridad. Tenemos un miror, si quieres aprender un poco más de eso, tenemos una villa ahí abajo donde puedes, si nunca has soldado nada, puedes ir ahí y aprender cómo soldar. También, como mencioné, trabajo para Google, tenemos un boot ahí abajo donde estamos reclutando varias posiciones de seguridad. Eh, les recomiendo mucho que vayan y platiquen con la gente de ahí para que vean qué tipo de posiciones estamos contratando. Siguiente, por favor. Ahora sí, a lo que lo que venimos, ¿no? La agenda de hoy. Ya hicimos la introducción. Vamos a hablar un poco acerca de qué es lo que hace, cómo es un día en el día a día de un profesional de la

ciberseguridad. Después vamos a hablar del rol de los datos, que es de lo que se trata esta presentación en la seguridad y las organizaciones. Y finalmente una una aplicación práctica de todo esto, ¿no?, que es el manejo de vulnerabilidades. Siguiente, por favor. Entonces, cuando la gente me pregunta, "Oye, Lenin, ¿qué es lo que haces?", ¿no? ¿Qué qué haces en seguridad? Este, ¿qué es lo que hace un hacker? No, generalmente, siguiente, por favor. Ellos, pues lo primero que le viene a la mente a las personas es algo como Mr. Robot, ¿no? Una persona que se viste siempre de la misma forma, de negro, que es un poco retraído. Este, si bien hay algo de cierto ahí,

nuestro trabajo puede llegar a ser muy ah estresante, crear mucha ansiedad. Entonces, el la salud mental es muy importante, pero eso no quiere decir que tiene que ser un prerrequisito, ¿no? Para trabajar en seguridad. La mayoría de las personas que trabajamos aquí son muy amigables, les encanta compartir. Entonces, también es muy común que en las cenas familiares, en los eventos sociales, te te dicen, "¿Qué haces? No, pues trabajo en ciberseguridad, ¿no? Oye, ¿me puedes la clásica? ¿No me puedes hackear el Facebook de tal persona? ¿O es que se me olvidó la contraseña de mi cuenta, no? Aunque ese tipo de seguridad este se ve de cierta forma en la industria, la realidad es que ciberseguridad pues

tiene varios ámbitos, ¿no? Tenemos seguridad ofensiva, tenemos ingeniería de seguridad, arquitectura de seguridad, pero lo que tenemos en común es que trabajamos con datos, ¿no? Y lo que yo hago yo en mi día a día es trabajar con datos, muchísimos datos. Siguiente, por favor. Entonces yo siempre le digo a la gente, en ciberseguridad hay hay una posición para todo mundo, ¿no? Dependiendo muchas veces de cómo es tu personalidad. Si te gusta más la parte ofensiva, pues tienes el red, ¿no? Si eres más metódico, más metodológico, te gusta seguir al pie de la letra, pues tienes el blue team, ¿no? Si si eres muy curioso, te gusta investigar, tienes trend intelligence. Eh, si te gusta divulgar que esta es un

área relativamente nueva, pues que puede ser un creador de contenido de seguridad. Siguiente, por favor. ¿no? Okay. Por el resto de la presentación nos vamos a enfocar en la parte de manejo de vulnerabilidades, ¿no? Que ese es el el ejemplo práctico que traigo para ustedes. Pero antes de eso eh quiero hablar eh en claro de un concepto muy importante. Independientemente de a qué área de la ciberseguridad te enfoques, es muy importante tener bases muy sólidas en lo que se llama la triada del SIA, ¿no? en por sus en inglés significa confidencialidad, integridad y disponibilidad, ¿no? O bailability. No importa qué tipo de ingeniero de seguridad seas, siempre tienes que tener esto en mente porque todo depende de

estos tres factores, ¿no? ¿A qué me refiero con eso? Vamos a hablar, por ejemplo, de la disponibilidad, ¿no? A grandes rasgos, imagínate que tú tienes una aplicación en tu teléfono y cuando abres la aplicación del banco tú esperas que todo funcione bien, ¿no? Entonces, ¿qué pasa cuando ocurre un incidente de seguridad en el banco y no aplica no funciona la aplicación? Como por ejemplo en el caso de un ratware, síguete, por favor, pues eso impacta la disponibilidad, ¿no?, de la aplicación. De de la misma forma tenemos la integridad, que es cuando tú abres la aplicación, tú esperas que ía el número que tú más o menos te acuerdas de cuánto dinero tiene, ¿no? Si abres la aplicación y hay

otro número, digamos que te acaban de pagar y tú sabías que podrías tener 10,000 pes y ves 5,000, pues ahí ya afectuó la integridad, ¿no? Entonces, siguiente, por favor. Este también es un concepto muy importante, ¿no? Y finalmente tenemos la confidencialidad, ¿no? Que la confidencialidad significa que tú estás seguro que solamente personas autorizadas pueden tener acceso a los datos, ¿no? Y aquí otro ejemplo muy claro que va muy de la mano es cuando ocurre, por ejemplo, un una brecha de seguridad o un incidente de seguridad, ¿no? Entonces, e en todo lo que acabo de hablar es es el riesgo, ¿no? las organizaciones y esto grábenselo muy bien porque no importa en qué área de seguridad, de una

u otra forma siempre vas a terminar hablando de riesgo con los altos directivos, ¿no? Y he visto muchísimos ingenieros que son muy son muy buenos, ¿no?, en la parte técnica, pero si no saben cómo comunicar esta parte del riesgo, pues su impacto puede no llegar a a ser visto, ¿no?, por los actos directivos. Entonces, ya hablé un poco de la parte técnica. El primer tipo de riesgo que tenemos es el riesgo de seguridad, ¿no? Básico. Aquí entran el wasto 10 injection y comprimó todo execution, ¿no? Pero existe otro tipo de riesgo, ¿no? Que es, por ejemplo, el riesgo de cumplimiento o el compliance. Muchas veces las este tipo de riesgo es el que motiva las compañías, ¿no? Porque

aquí es donde están las demandas, aquí es donde dependiendo de la industria en la que ellos se desempeñan, tienen que tener ciertos lineamientos, ¿no? Tienen que seguir ciertos protocolos. Entonces, eh muchas veces un riesgo de seguridad puede llegar a ser riesgo de cumplimiento y viceversa, ¿no? Pero al final del día, siguiente, por favor. Al final del día todo es riesgo de reputación, ¿no? Este, a ninguna empresa le gusta que salgen las noticias que que nos hackearon, ¿no? Y eh de todo esto se deriva en que no importa si tú eres un researcher, un P tester, blue team, purple team, lo que sea, al final del día las organizaciones nos contratan para que para reducir riesgo, ¿no? La

forma en que ellos lo ven es cuánto me cuesta proteger esto y cuánto cuánto dinero perdemos y estás comprometido, ¿no? Entonces, ¿cómo reducimos el riesgo? No, ese es nuestro trabajo al final del día. Siguiente, por favor. Hay muchos métodos para calcular ese riesgo, ¿no? Y esta también es una formulita muy sencilla que tienen que grabarse, que es el riesgo es es igual a la probabilidad multiplicado por el impacto, ¿no? Y esta tabla pues está en todos los libros de seguridad que hablan de cumplimiento, de cómo calcular riesgo. Hay muchos esfuerzos de organizaciones de cómo estandarizar esto. Pero les voy a decir un secreto. Al final del día, muchas compañías implementan esto de la mejor forma que

lo entienden y de la mejor forma que lo pueden hacer, ¿no? No hay una forma única unificada para hacerlo, ¿no? Entonces va bien como un un lineamiento, una una guía para seguir, ¿no? Las empresas lo van a hacer de forma diferente, este dependiendo del caso. Oyente. Entonces, bueno, ya hablamos del riesgo del día a día, de los conceptos fundamentales que tenemos que tener. Ahora hablé de los datos, ¿no? Muchas veces, siguiente, por favor. Como ingeniero de seguridad, eh, estamos lidiando todo el tiempo con enormes cantidades de datos, ¿no? Entre más grande la organización, entre más líneas de negocio hay, pues tienes datos no estructurados, tienes como paquetes de red, tienes blogs, tienes video, audio, tienes documentos,

tienes alertas. Entonces, todo eso tienes que siguiente, por favor. Todo eso tienes que analizarlo, ¿no? Tienes que de cierta forma aplicar métodos de ciencias de datos para eh siguiente para y siguiente para tomar decisiones, ¿no? Y al final del día todo esto te genera inteligencia para tú tomar decisiones que ayuden al negocio, ¿no? Y en nuestro contexto pues reducir riesgo. Ahorita vamos a hablar un poco más más a detalle. ¿Quién de aquí reconoce esta captura de pantalla? Sí, ya había algunos ahí que les trajo recuerdos, ¿no? Entonces, vamos a ver un ejemplo un poco clásico, ¿no? Imagínate que trabajas en un soc o en una posición de seguridad, alguien te dice, "Oye, ¿sabes qué? Me salió esta captura de

pantalla, nos cayó nos cayó ransomware, ¿no? ¿Cómo empezamos a a resolver este problema de una forma metodológica, ¿no? ¿Cómo aplicamos un proceso? Siguiente, por favor. En este caso, pues vamos a a utilizar técnicas de análisis de datos en donde primero vamos a tratar de hacer un análisis descriptivo, ¿no? ¿Qué es lo que está ocurriendo? Este, pues ya vimos que hay ransomware, pero ¿cuál es el síntoma? Pues 30% de los points están mostrando un alto uso de CP, ¿no? Entonces, estamos describiendo qué es lo que está ocurriendo. El siguiente, por favor. Después de eso vamos a realizar un diagnóstico. Okay. ¿Cómo es que ocurrió el ransware? ¿Por qué ocurrió? Pues un colaborador, un empleado recibió un email, le dio clic, se descargó el el

ran software, infectó a la máquina, ¿no? Entonces, ya entendemos cómo es que ocurrió, ¿no? Por qué. Siguiente. Eh, con esa información vamos a empezar a hacer una predicción, ¿no? ¿Qué es lo que podría utilizar? Ya entendemos el ransomware. El ransomware, pues se propaga explotando una vulnerabilidad que no está parchada. Eh, ¿cuántos de esos activos de la empresa van a poder ser vulnerables, ¿no? Entonces ahí estamos prediciendo y finalmente para lo que nos pagan, ¿cómo prevenimos que eso ocurra? ¿No? ¿Cómo hacemos un análisis prescriptivo? Este, pues vamos a poner en cuarentena las máquinas y las máquinas que tenemos sospecha, pues también vamos a isolarlas y empezar a analizarlo. Entonces, esto es a grandes rasgos, ¿no? Es más

complicado que eso, pero eh a grandes rasgos es un proceso, ¿no?, de cuatro pasos. Entonces, ahora sí vamos a ver un anális un ejemplo claro, ¿no? Que es vulnerability management, que es el área en la que he trabajado los últimos 3 años en una empresa como Google, que tiene una escala enorme. Siguiente, por favor. ¿Qué es el vulnerability management o el análisis, el manejo de vulnerabilidades? A grandes rasgos, es la disciplina que utiliza técnicas de ciencias de datos o ingeniería de datos. herramientas de seguridad y procesos de seguridad para identificar priorizar remediar vulnerabilidades y ayudar a reducir de forma efectiva el riesgo en una organización. Y sé que esa es la definición del libro. Ahorita vamos a

ver con ejemplos para que sea un poco más claro. Vulnerability management tiene dos partes, ¿no? La parte de la vulnerabilidad y el manejo, ¿no? ¿Qué significa esto? Primero tenemos que entender a a nivel fundamental qué es una vulnerabilidad, ¿no? Porque sí, o sea, inmediatamente pensamos que es, por ejemplo, lo wasop 10, pqu injection, las clásicas, ¿no? Pero ahorita vamos a ver que hay distintos tipos, ¿no? Siguiente, por favor. Eh, la definición que a mí me gusta decir es una una vulnerabilidad es una una falla en el software, ¿no? Es un este creo que ahí se bloquea algo de ahí. Puede cerrar una ventanita que tiene [Música] la anterior, por favor. Ahí estamos. Sí. Una debilidad en el

software o un proceso, ¿no? Que puede ser explotada por un atacante. ¿Para qué? Para poner en jaque, poner en riesgo una de las tres atributos que vimos en un inicio. Si alguien se acuerda cuáles eran confidencialidad, integridad y disponibilidad, ¿no?, de los sistemas. Entonces, un ejemplo muy claro es, por ejemplo, una armadura, ¿no? La armadura, pues depende qué de qué tanta calidad es el metal, qué tanto te permite maniobrar, pero la armadura es tan fuerte como su parte más débil, ¿no?, que es el ejemplo ahí de la flecha, ¿no? Entonces, esa será una analogía de lo que es la vulnerabilidad. Siguiente, por favor. Entonces, ya mencionaba que hay distintos tipos de vulnerabilidades, ¿no? Y podemos categorizarlas

por el tipo de impacto que pueden llegar a tener. A mí me gusta mucho utilizar, por ejemplo, Stride, que te dice, te ayuda a categorizar el impacto, por ejemplo, el eh pérdida de de identidad. Ahí, por ejemplo, imagínate un usuario que roba sus credenciales, pueden personarlo, ¿no? O también tenemos este una brecha de confidencialidad cuando alguien publica, algún desarrollador publica credenciales un repositorio, ¿no? Tenemos escalación de privilegios, tenemos denegación de servicios, eh tampering y remote code execution, ¿no? Entonces, no todas las vulnerabilidades son son similares, hay diferentes cada uno tiene pues sus diferencias, ¿no? Y la y por eso las tienes que tratar de forma diferente. Siguiente, por favor. Entonces, ¿dónde se encuentran estas vulnerabilidades? ¿No? En primera

instancia, pues están en el código fuente, ¿no? Todo el software que producimos eh lo producen los humanos. Los humanos no somos perfectos, cometemos errores, entonces ahí puede haber vulnerabilidades, ¿no? Hay varios escanners, hay varias metodologías técnicas para revisar eso, pero en primera instancia esta sería la primera parte, ¿no? La siguiente, por favor. Las vulnerablesz también pueden aparecer en las dependencias del software, ¿no? Puede ser que tu aplicación ya pasó por varios procesos, está limpia, pero estás importando ciertas dependencias que tienen vulnerabilidades o debilidades, ¿no? Aquí están los famosos ataques a la cadena de suministros, su attacks. Eh, otro punto donde hay vulnerabilidades puede ser en el ambiente como tal, ¿no? Piensa, por ejemplo, en los contenedores, ¿no? tu

aplicación está corriendo dentro de un contenedor o en una máquina virtual, puede ser que algún componente dentro de ahí es vulnerable, ¿no? Algo que no tiene nada que ver con tu aplicación y pero puede puede ayudar ayudar a un atacante, ¿no?, a afectar confidencialidad, integridad y disponibilidad. siguiente. Eh, las vulnerabilidades también hoy en día se encuentran en la configuración, ¿no? Y esto es muy común, por ejemplo, en escenarios de la nube, en donde tú despejas tu aplicación, está corriendo, pero tienes una configuración que lo hace vulnerable, ¿no? Por ejemplo, que los discos duros de las máquinas virtuales no están no están cifrados, ¿no? O tienes un proxy que da acceso a todo mundo, ¿no? Entonces, eso también

afecta la seguridad de las aplicaciones. Y finalmente las más entretenidas, las más complejas también en la funcionalidad misma de la aplicación, ¿no? Que aquí tiene que ver mucho con la lógica de negocio de la aplicación y es donde por lo general ningún tipo de escáner te va a detectar una vulnerabilidad en la lógica de negocio, ¿no? Esto es muy común porque las empresas como empiezan a crecer tanto y hay varios departamentos trabajando, varios departamentos que están trabajando a la par y si no se comunican, puede ser que haya una forma en que un atacante utilice varios varios eh varios componentes, ¿no?, de esos departamentos y pueda afectar la seguridad de las aplicaciones de las plataformas. Siguiente, por favor.

Eh, esta imagen me gusta bastante porque realmente representa el desarrol el desarrollo de software moderno en donde tenemos ahora sí que todas las compañías produciendo software rápidamente, pero muchas de esas depende eh tienen dependencias en librerías o bibliotecas que están mantenidas de forma muy insegura, ¿no? O muy pobre, o hay un desarrollador que no es muy bien valorado y pues está abajo, ¿no? Entonces, una debilidad en esa librería que es utilizada por millones de personas puede comprometer la seguridad de de toda una industria. Siguiente, por favor. Yo lo veo como una caja de cartas, ¿no? En donde entre más grande es la casa, pues tiene cimientos más débiles, ¿no? Y siguiente. Y obviamente este hay casas de cartas que son

muchísimo más grandes que otras, ¿no? Y todo esto de lo que estoy hablando, eh, siguiente, por favor. No, no, esa es la teoría, ¿no? Generalmente cada tres o cada 4 años ocurre una vulnerabilidad masiva, este, que afecta a toda la industria y salen todos los medios de noticias de seguridad. Estoy hablando de cosas como la más reciente que fue el backdoor de la librería XZ o The Lock for Shell o Harble o ese tipo de vulnerabilidades, ¿no? Que todo es software que todo el mundo usa y nadie realmente está manteniendo, ¿no? O está monitoreando, pero todo el mundo usamos y cuando un atacante encuentra un Zero Day ahí, pues le pega a todo el mundo, ¿no? Entonces,

eh a grandes rasgos y para cerrar esta parte de vulnerabilidades, esto es lo que quiero que se quede, ¿no? Las vulnerabilidades se encuentran en todas las capas del del software y son de hay de distintos sabores, ¿no? Y colores y todas tienen que tener remediaciones distintas. Entonces ahorita vamos a hablar siguiente, por favor, eh del manejo, ¿no? O el management. Ya ya entendimos lo que son las vulnerabilidades. Ahora, ¿qué es el management? ¿No? en en su descripción más pura, el manejo es el arte de manejar recursos, herramientas para llegar a un fin último, ¿no? Entonces, tú puedes imaginarte como si el otro era un un soldado en armadura, pues aquí eres un general, ¿no?, que tienes a tu

disposición un ejército. Entonces, tu objetivo es cómo manejar de forma más eficiente esos recursos para lograr tus objetivos, ¿no? Y en nuestro caso, pues el objetivo es reducir riesgo. Entonces, siguiente, por favor. [Música] Eh, aquí ya empieza como tal formalmente el proceso de de vulnerability management, ¿no? Donde el paso uno va a ser, ¿cómo descubro dónde está el riesgo, no? Descubrir el riesgo tiene varios prerrequisitos. Uno de eso es identificar qué es lo que lo que le importa a la empresa y lo que me importa a mí, ¿no? Entonces va a haber varias varias formas de hacer eso, ¿no? Tenemos escanners, tenemos inteligencia de amenazas, tenemos incluso algunas guías, ¿no? Este, que nos dan algunos

lineamientos, algunas certificaciones que nos dicen, "Mira, esto es lo que te si tú trabajas en salud tienes que revisar esto, esto y esto, ¿no? si estás en industria de de finanzas es esto, ¿no? Después de eso vamos a esto nos va a dar muchísimos hallazgos, ¿no? Ahora, ¿cómo vamos a priorizar? ¿Cómo vamos a hacer la parte del manejo de los recursos? ¿No? Pues aquí vamos a tener que enfocarnos en lo que más nos interesa y vamos a tener que calcular nuestros propios factores de riesgo, ¿no? Que es la parte que les decía al inicio, que cada empresa lo hace como como más lo entiende, ¿no? Como más le conviene. Y finalmente, eh donde he visto personalmente que

muchas empresas eh se quedan cortas, por no decir que fallan, es la parte de la remediación, ¿no? Porque de nada te sirve que tú tienes estos 10 o 100 hallazgos o 1000 si no tienes una forma efectiva de cómo rearlos. Y ahorita vamos a hablar un poco más a detalle de cada uno. Entonces, paso uno, ¿no? Descubrir el riesgo. Lo primero que necesitamos es un inventario, ¿no? No podemos eh asegurar lo que no conocemos que que está en nuestra compañía, ¿no? Hay varias formas de construir este inventario. Una forma es manualmente, literalmente preguntar con los diferentes departamentos, oye, ¿qué estás corriendo? ¿Qué repositorios tienes? Eh, hay formas automáticas como los scanners también. Si estás en la nube,

si despliegas tu infraestructura en la nube es un poco más sencillo porque hay APIs para inventare las cosas, pero si estás en un escenario donde tienes una infraestructura homogénea, es decir, que está desplegado en distintos ambientes, pues va a ser un poco más complicado, pero no es imposible. ¿Qué es lo que vas a querer incluir en ese inventario? No, pues de entrada eh, ¿qué tipo de infraestructura tienen, no? Si son máquinas virtuales, si son firews, si son ah la anterior, por favor, este, si son redes, qué tipo de credenciales hay, este, te tienes que poner muy creativo, ¿no? Entre más información tengas para tu inventario, te va a ayudar más en un futuro. Siguiente, por favor.

Anterior, eh, hablé un poco acerca de los escanners. que nos van a ayudar también para la parte de descubrir el riesgo, ¿no? Como ya decía, básicamente podemos escanear todo hoy en día, ¿no? Y qué es lo que nos va a interesar más, pues escanear los activos de la empresa, como por ejemplo los teléfonos, las computadoras, servidores, eh los end points. También vamos, yo recomiendo escanear secretos, que también es un vector de ataque muy popular para los atacantes. Puedes este tratar de donde sea que hay un repositorio de código, poner un escáner ahí, ¿no? Eh, ahí la inteligencia de de amenazas te va a ayudar bastante. También tenemos escáneres de red para tratar de detectar vulnerabilidades muy

tradicionales de de red eh de dependencias y código. Ya mencioné, ahí es donde está la mayoría de las vulnerabilidades. configuración y hoy en día con todo este auge de la inteligencia artificial, pues también ya tenemos escáners especializados, ¿no?, en en verificar cuál es la postura de seguridad de una aplicación que se integra con un LLM, ¿no? Eso es relativamente nuevo, hay mucho desarrollo y todavía como que la infraestructura se está se está alineando, ¿no?, en cómo debe de funcionar ese esa última categoría, ¿no? Primero siguiente eh, para poner un diagrama más o menos de cómo se ve una infraestructura de una empresa que tiene un eh un pipeline central en donde están arrojando todos sus logs y están

analizando y están eh derivando inteligencia. Como les decía, el paso uno es inventario, ¿no? Tienes todo tu software ahí que está inventariando, que estás en tiempo realestando datos de qué tipo de infraestructura estás manejando. Una vez que tienes tu inventario, entonces arrojas todos tus scanners y esos escanners te van a ayudar a encontrar vulnerabilidades que después vas a hacer triasco, pero generalmente te van a ayudar a construir toda la parte del del descubrimiento de riesgo, ¿no? Y aquí tengo varias openour, ¿no? Hay puedes pued hacer una combinación entre eh herramientas comerciales y herramientas open source. Eh, aquí también entra mucho la parte del red teaming y el testing, ¿no? Que no es una parte que se pueda automatizar

y en mi opinión no debería de ser automatizable. deberían de utilizar herramientas hasta cierto punto, pero toda la inteligencia que el Red Team y los canales de inteligencia deri también puede ser integrado en el pipeline, ¿no? Y finalmente está una de las partes más importantes que es el el enriquecimiento de datos, ¿no? donde aquí vamos a tomar todos estos datos crudos y vamos a tratar de procesarlos para derivar o ponerlos en un en un formato estándar que pueda ayudarnos a construir todas estas vistas de riesgo, ¿no? Entonces, siguiente, por favor. Vamos a hablar un poco más a detalle del enriquecimiento de datos, que es una de las partes más importantes. Ya hablé acerca de que los ingenieros de

seguridad trabajamos con enormes cantidades de datos, no no estructurados, pero utilizando todas estas técnicas de ciencia de datos, de ingeniería de datos, de seguridad, lo que vamos a tratar de crear va a ser una vista única que tenga, por ejemplo, primero tenemos que saber de qué tipo de asset estamos trabajando, ¿no? Es una máquina virtual, es un contenedor, es una cubeta, es una credencial, un usuario. Tenemos que saber de qué estamos hablando, ¿no? Después de eso también es útil saber qué tipo de despliegue es. No está desplegado en ver metal, en la nube, en un ambiente de producción, staging, lo que sea. El tipo de de exposure, ¿no? Es muy importante. ¿Está expuesto a internet? A internet,

tiene una API pública o necesitas una autenticación, ¿qué tipo de protocolo? Eh, muy importante, los escáners te van a dar algunos, por ejemplo, un CB como Gulbate Exposure con un número y un un score, una calificación, ¿no? Eso te va a servir para priorizar. Eh, siguiente, también vas a querer registrar si hay algunos controles desplegados, por ejemplo, si hay algún antivirus instalado, si hay EDRs, si hay algunas protecciones que ya están corriendo en ese asset. Eh, muy importante quién es dueño de SEACE, ¿no? Porque si no hay un dueño va a ser muy difícil que alguien lo pueda lo pueda remediar, ¿no? Y eh finalmente esta es una parte muy importante que me gusta a mí mencionar que es qué tan

crítico es este ases para el negocio, ¿no? Eh, tuve una conversación hace unos minutos con alguien que me dijo que hizo un análisis de riesgo y les dijo, o sea, a nivel de de segundo, ¿no? Si este si esta máquina es comprometida, cada segundo perdemos tanto dinero, ¿no? Entonces, si puedes hacer ese análisis de riesgo, mucho mejor. Entonces, siguiente, por favor. Una vez que ya tenemos toda esta infraestructura construida, va a ser muchísimo más fácil cómo descubrir el riesgo, ¿no? Va a ser tan fácil como, por ejemplo, hacer queries contra tu infraestructura. Y en este ejemplo tenemos algo como dame todas las las aplicaciones que están expuestas a internet y son vulnerables al CB 2021

44228. No, ¿alguien sabe qué CB es este? Es este. Si alguien sabe me dice al final y se un sticker. Este, pero siguiente, por favor. Sí, o sea, lo que quiero esta parte código no es importante, ¿no? Este es un código de ejemplo que me dio CH GPT, ¿no? Pero lo que quiero comunicar es una vez que tienes todos los datos, es muchísimo más fácil encontrar el riesgo y empezar a ver por dónde empezar a a remediar, ¿no? Tenemos otros ejemplos también. siguiente, por favor. como los grafos, ¿no? Los grafos te van a ayudar para de una forma más visual entender las relaciones entre ciertos nodos, ¿no? Y como por en este ejemplo, por eh si yo tengo una

aplicación que está expuesta a internet, desplegarme un servidor, puedo saber qué tipo de librerías vulnerables están corriendo en esa página web, por ejemplo, ¿no? Entonces, lo que quiero que entiendan es el poder de los datos, ¿no? Una vez que tienes todo correlacionado, es muy fácil hacer ese proceso, ¿no?, de rediscovering. Ah, ahora, ¿cómo hacemos la priorización? Que es el segundo paso, ¿no? Ya entendemos la identificación. Ahora, la priorización, pues de misma forma, ¿no? Nos va a ayudar a saber cómo asignar estas prioridades, los famosos P0, P1, Púo 2, P3, ¿no? Entonces, eh para la probabilidad pues vas a utilizar cosas como el exposure, ¿no? Este está expuesto a internet, se necesita unas credenciales para acceder a él, qué tipo

de protocolo está utilizando, ¿no? la severidad del CBE, qué tan trivial o o difícil es explotar la vulnerabilidad para el impacto. Aquí viene la parte de eh si un atacante logra comprometer este asset, a qué tipo de de información puede puede llegar a tener acceso, ¿no? Ahí es lo que les decía de si tú puedes taguear tus datos, tus bases de datos y decir esta base de datos tiene información personal o esta base de datos tiene información financiera, te va a ayudar a tomar esta decisión. Eh, hay más cosas, ¿no? Como el ambiente en el que está desplegado, por ejemplo, si es un ambiente de staging, pues no es lo mismo si es un ambiente productivo,

¿no? Y finalmente con todo esto, pues tú puedes asignar a tu criterio de seguridad, pues si esto es un P0, ¿no? O un P1, un P2 o P3. Siguiente, por favor. Y finalmente tenemos la parte de la remediación, ¿no? Que aquí es donde he visto que muchos equipos hacen las primeras dos partes bien, pero en donde se quedan un poco cortos es en la tercera. Y ahorita vamos a hablar un poco más de el por qué no. eh dependiendo la la vulnerabilidad, la naturaleza, este van a ser la remediación que vas a hacer va a ser distinta, ¿no? Si es, por ejemplo, actualizar una dependencia, si es una dependencia vulnerable, pues eh la remediación es actualizar o parchar,

¿no? Un servidor, una aplicación, lo que sea. Eh quizás lo único que tienes que hacer para el segundo escenario es cambiar una configuración, ¿no? Si alguien te dijo, "¿Sabes que estas máquinas virtuales no tienen los discos duros encriptados?" Pues nada más le aprietas a un botón, ¿no? Encriptar. Eh, también la remediación puede ser implementar un un control adicional, ¿no? Si es una aplicación legacy que no puedes modificar porque no tienes el código fuente, pues quizás puedes poner un firewall enfrente, ¿no? Y finalmente, si es una vulnerabilidad en donde tú tienes el código fuente y los desarrolladores pueden hacer el trabajo, pues pueden ahí aplicar el parche, ¿no? A nivel de código fuente. Siguiente, por favor. Pero al final del día, cuando tú

ya determinas cómo hacer la remediación, la forma en que tú lo vas a comunicar con los equipos es creando box, ¿no? Todos tenemos acceso a este tipo de sistemas de tickets y eh en mi opinión la forma más efectiva para que te te hagan caso es creando un bot con la mayor cantidad de información. tratar de educar al usuario, tratar de decirle, "Mira, esto es lo que encontramos, esto es el impacto en un lenguaje que que entiendan. Eh, los pasos a seguir para la remediación son estos. Y si puede ser que la remediación sea automatizada, ¿qué mejor? ¿No? Porque también estaba platicando con alguien y le decía, "Mira, es que los desarrolladores están muy ocupados, ¿no?

Ellos están produciendo software, están ocupados. Nosotros como gente de seguridad les estamos dando más trabajo. Entonces, ellos tienen que hacer su propio proceso de priorización entre sus metas y lo que nosotros le estamos dando. Entonces, si tú como equipo de seguridad les puedes dar casi casi un casi casi un un PR, ¿no? Un pull request que ya tiene el fix para que ellos nada más lo analicen y le den merch, muchísimo mejor, ¿no? Entonces, eh sí, lo que quiero que entiendan es entre más completo es el Bog, ¿no?, que ellos apliquen esas esas remediaciones, ¿no? Si entra y eh alguna de las lecciones que he aprendido en este rol en los últimos 3 años es de

eh pues sí, lo más importante al final del día son los datos, ¿no? No me canso de decir eso porque puedes tener muchísimos escáners comerciales muy buenos, muy caros, pero si al final del día no tienes buenos datos, no tienes un buen inventario que te va a ayudar a ver qué es lo que realmente importa en tu compañía, eh te va te va a servir muy muy de muy poco, ¿no? Esa tecnología tan tan cara que tienes. Eh, el segundo punto es que no todo puede ser escaneado, ¿no? No todo debería de ser escaneado. Existen varios ambientes que generalmente son muy críticos, como los ambientes de OT, en donde si tú le avientas un escáner a algo, vas a vas a

brinquear un dispositivo, ¿no? Y ha pasado, ¿no? Conozco casos de gente que dijeron, "Okay, vamos a ver si hay vulnerabilidades en en los lectores de tarjetas, ¿no? De las de las puertas." Entonces aventaron escanners y a los 10 minutos les hablaron, "Oye, es que la gente está atrapada en el edificio, no puede salir, ¿no? Porque los escáners pues estaban haciendo una denegación de servicio, ¿no? Entonces tenemos sistemas de Airgap que están están isolados del internet, entonces no podemos llegar a escanearlos. Eh, tenemos sistemas que tienen muy pocos recursos en donde no pueden correr una gente dentro, no pueden ser escaneados o simplemente hay equipos que dicen, "¿Sabes qué? Eh, yo no quiero malamente yo no quiero lidiar con con

seguridad y a mí sácame de tu programa, ¿no? Entonces, ya se vuelve un tema más más político. Eh, el tercer punto es que no todas las vulnerabilidades son iguales, ¿no? Como mencionaba, va a depender mucho del contexto de la vulnerabilidad. Eh, algo que yo he aprendido eh platicando con más gente de la industria eh del book bound incluso es que mandan vulnerabilidades muy complejas, muy sofisticadas. Eh, ocurrió un caso muy sonado hace unos meses de un bounty hunter muy famoso en Hanamsec, donde él envió un una vulnerabilidad del remote de execution, pero no se la pagaron, ¿no? Y no se la pagaron. ¿Por qué? porque el aset contra el que la explotó pues no tenía

realmente un impacto, ¿no? Y eso no quiere decir que la vulnerabilidad no exista, ¿no? Pero las compañías operan con recursos limitados y no van a parchar una vulnerabilidad solamente porque existe, ¿no? Sino si no existe un impacto tangible para el negocio. Y finalmente, pues de esos tres procesos, en mi opinión, el que es, digamos más que tiene mayor dificultad puede ser la remediación y el que y del que depende todo nuestro trabajo, ¿no? Porque de nuevo las empresas hacen el paso uno y dos bien, pero si se quedan cortos en el paso tres, ¿no? remediación eh significa y donde he visto también un poco más de fricción es ya encuentras activos vulnerables, vas con los equipos y le

dices, "Oye, ¿sabes qué? Tienes este servidor que es vulnerable." Pero luego es esa ese equipo te dice, "Oye, pero es que sí sí sí corre infraestructura, pero yo no soy dueño de ese servidor, ¿no? Ese servidor es desplegado por un tercero, ¿no? Y le digo, "Vas con ese equipo y ellos dicen, es que pues sí, nosotros lo desplegamos, pero nosotros consumimos un servicio de un tercero, que es el que hace todo el despliegue por medio de nosotros, ¿no? Entonces, hay muchos hay muchos casos y muchos este casos específicos ahí en la revenución, ¿no? Entonces, no se van a aburrir, se los prometo, de trabajar en esta área. Siguiente, por favor. Entonces, todo lo que los hablé de lo

que les hablé está documentado de forma eh formal, formalmente en literatura. por ejemplo, de NIS, ellos tienen publicaciones acerca de cómo construir este software de de monitoreo de vulnerabilidades paso a paso. Si quieren aprender un poco más, les dejo estas publicaciones que son, en mi opinión, están muy bien detalladas y hay muchísimos software open source que ustedes también pueden descargar, incluso correr localmente en sus máquinas, pueden empezar a construir sus propios inventarios localmente. Y eh el tercer punto que traigo para hablar de la presentación es la visualización de datos, ¿no? que va a ser la parte de cómo vamos a como ingenieros de seguridad, cómo vamos a transmitir esto a los altos directivos, ¿no? ¿Cómo vamos a hacer que

ellos entiendan el trabajo que estamos haciendo? Y básicamente es dándole los famosos eh KP, ¿no? Kefumers indiqueo, donde generalmente tú puedes tratar de agrupar las vulnerabilidades por tipo, por impacto, por cuál fue el tiempo medio de remediación. Hay varios software que te ayuda a hacer esto. Por ejemplo, ahí tenía una una pantalla de grafano. Este de acá es un cliente, por favor, es este es Guazu. Eh, y te va a ayudar a a mostrar de de una forma muy visual, ¿no? Cómo se ve la vulnerablez y el riesgo, ¿no? Entonces, eso es para para cuando haces reportes. Pero, por ejemplo, si tienes equipos que van a hacer integraciones con estos datos, quizás les tienes que dar algo

diferente, como simplemente acceso a una tabla, una base de datos, una app, un emp para que ellos hagan sus propios programas y entonces de ahí empiecen a hacer el análisis, el análisis de datos. Siguiente, por favor. Entonces, este punto de lo que quiero hablar es que tienes que conocer tu audiencia, ¿no? No es lo mismo tener una conversación de seguridad con un siso o alguien de la mesa directiva donde ellos eh a ellos lo que les interesa es qué estamos haciendo y por qué lo estamos haciendo y ellos se van a manejar siguiendo mucho eh lo que les hablé acerca de los QPS, ¿no? que cuando ya tienes una conversación con los equipos de ingeniería, con los equipos de de

Depsops, en donde ahí nos interesa más cómo lo vamos a hacer, ¿no? Ya los de arriba nos dijeron qué es lo que quieren y por qué. Entonces, ahora nosotros vamos a hacer la parte táctica, ¿no?, de cómo lo vamos aar, ¿no? Cómo vamos a lograr esos objetivos. Entonces, teniendo esto en cuenta, te va a ayudar a comunicar mejor cómo es el trabajo que estás haciendo, ¿no? Siete, por favor. Y ya nada más para cerrar, pues hoy hablamos acerca de más o menos cómo es el día a día, ¿no?, de un ingeniero de seguridad, los conceptos fundamentales que tenemos que hacer. Hablamos de ciencia de datos, de los diferentes metodologías, hablamos del proceso de vulnerability management y la

importancia de cómo comunicarnos con las diferentes audiencias, ¿no? Eh, tienen aquí mis datos en caso de que quieran hacer más preguntas. Este, y eh eso es todo lo que tengo para hablar hoy. Si alguien tiene preguntas adicionales, creo que ahora es el momento. A los que hagan preguntas, traigo algunos stickers para regalar. Entonces, son stickers, amigos. Entonces, véense. Abrimos sesión de preguntas y respuestas. Un aplauso para Lenin.

Y bueno, tenemos un espacio. Entonces, levanten la mano y yo les llevo el micrófono ¿vale? [Música] Acá en mi frente voy a pasar pasillo. Hola. ah, mencionaste en un momento que cuando uno viene con los equipos de destroyo y les dice, "Tienen que arreglar tal cosa, eh, les estamos dando más trabajo, ¿no?" Y eso resonó mucho conmigo. Pero mi quería preguntar al respecto de eso. ¿Tú crees realmente que es un problema eso de darles más trabajo que viene de la del hecho natural de que ellos tengan cosas que hacer y nosotros nuestro nuestra profesión o viene de alguien más? Es una buena pregunta. En mi opinión es ellos su prioridad no es la seguridad, ¿no? Ellos están

desarrollando software, soportando el negocio con nuevas funcionalidades y nuestro trabajo es reducir riesgo, ¿no? Entonces lo que lo que he aprendido a lo largo de los años es encontrar ese fino arte, ¿no? agregar la el suficiente nivel de fricción a los equipos de desarrollos para mantenerlos seguros, pero también para permitirles hacer su trabajo. Entonces, es encontrar ese como switch spot, ¿no? En donde todo mundo pues está feliz de cierta forma, ¿no? En donde pues sí lo remediaste, no estoy 100% feliz con cómo lo hiciste, estoy 80% 90% de cómo lo hiciste. Y ellos dijeron también, "Okay, este nos retrasó una semana, dos semanas, ¿no? En hacerlo, pero es al final del día ya es como una

parte más política, ¿no? Y también creo que vale la pena mencionar que entre más trabajo hagamos educando a los equipos de por qué es importante la seguridad, pues ellos también van a entender que no les estamos dando más trabajo simplemente porque somos como malos, ¿no? No, no queremos poderlo, ¿no? Sino es porque te estamos protegiendo, ¿no? Te estamos ayudando a que no si hay un incidente de seguridad pues no van a venir y te van a gritar, ¿no? Entonces esa sería mi respuesta.

[Música] Bueno, este, comentaste que para comunicar el riesgo a la alta dirección, este, por ejemplo, que te decía, pierdes tanto por segundo, ¿no? Ya, ya temas este cuantitativos, pero si no llegamos a ese nivel de de decir financieramente per tanto, ¿cómo podemos este hacerles, no, ver este que es un alto impacto, ¿no? Para para ellos. Sí. Eh, va a depender mucho también de qué tan de nuevo qué tan educados estén los directivos en temas de seguridad, ¿no? Porque para bien o para mal, algo que he aprendido es que a partir de cierto nivel todas las todas las conversaciones son acerca de dinero. Entonces, ¿cuánto dinero ellos están poniendo en la mesa? cuánto esperan obtener de regreso, ¿no?

Y cuánto dinero les está costando eh proteger una cosa, ¿no? Entonces, sí, hacer darle una darles una respuesta que haga sentido en su en sus propios términos, ¿no? En su propio lenguaje, quizás no puede hacer un análisis de riesgo tan así tan granular, ¿no? Es decir, cada segundo, ¿no? Pero puedes hacer un análisis de, oye, ¿sabes qué? Este, si nos vulneran de esta forma, eh, hay una regla de cumplimiento que puede derivar en una demanda, ¿no? Puede derivar en en alguna penalidad, ¿no? Penalización. Entonces ahí más bien el trabajo es no no es no es no es táctico, no es técnico, sino es de soft skills, ¿no? De cómo hacerles entender teniendo juntas, teniendo llamadas, hacerles entender por qué por

qué es importante, ¿no?, el trabajo de seguridad, ¿no? Porque también es cierto que muchas, sobre todo cuando la empresa no tiene esa parte muy clara en que seguridad pues es una es una inversión, ¿no? Y tienen que entender en qué están invirtiendo su dinero. Entonces tienes que hacerlos entender.

[Música] Bueno, listo. Eh, aparte de la comunicación, ¿qué otros tres soft skills crees que es importante desarrollar en tus actividades? Eh, buena pregunta. Eh, comunicación, ya dijimos una, la otra es influencia y esto pues ya se ven en las organizaciones grandes, ¿no? Donde hay diferentes equipos que tienen diferentes motivaciones, tienes que hacer pues dialogar y y alinear a las personas. Entonces, la influencia es un skill muy muy bueno. Eh, el tercer skill también sería un poco como empatía, ¿no?, con los usuarios, porque al final del día depende el tipo de compañía que estés y el tipo de dinámica. Todo el mundo quiere todo para ayer, ¿no? Entonces, si a ti te están presionando mucho y eso hace que tú

presiones a los demás, pues esa es una cadena, ¿no? Donde todo el mundo nos vamos a estresar, nos vamos a presionar. Entonces, eh pues sí, la la empatía, ponerse en los zapatos de la otra persona, hacer alianzas, entender cómo podemos trabajar juntos, no para meternos en pie, pero sino para trabajar más rápidamente, ¿no? Para incrementar velocidad. Entonces, hay muchísimo más soft skills que que he aprendido a lo largo de los años, pero como esos tres han sido los que más me han me han ayudado [Música]

acá este lado. Eh, bueno, mi pregunta va más orientada al tema de cómo automatizar la priorización de vulnerabilidades críticas, porque digamos una vez que se define que la unidad es crítica, digamos, el el láser está expuesto a internet, existe una prueba de concepto donde se puede explotar esa vulnerabilidad, incluso pues v inteligencia te puede decir que está siendo explotada activamente pues en internet, ¿no? Pero pues ya cuando tienes 100 vulnerabilidades críticas, o sea, ¿cómo automatizas eso? Excelente. O sea, cuando todo es crítico, nada es crítico, ¿no? Sí, sí, sí. me créeme que me ha pasado y y ya hemos hecho ejercicios donde o sea, ya definimos lo que es un pescero, ¿no? Oye, pero tenemos 1000 pesceros, ¿no?

Entonces eso a mí me da a entender que necesitamos agregar un filtro extra, ¿no? O hay algo en el proceso que no está no está funcionando bien o hay algo que se nos está pasando, ¿no? tenemos que ir un paso atrás para decir, "Oye, si todo lo que nos estamos mandando, todo lo que estamos detectando es crítico, pues en realidad lo es. Entonces es un proceso iterativo, ¿no? En donde tienes que estar ajustando constantemente qué es lo que significa crítico, medio, alto y aunque aunque la dirección te diga, es que todo es importante, o sea, la verdad es que no, o sea, hay cosas del negocio, hay aspectos del negocio que son más importantes que otros, ¿no? Entonces

respuesta ahí es volver a revisar, ¿no? Ese proceso que estás, ¿por qué estás diciendo que tú eres crítico? Perfecto. Muchas gracias.

Hola, buen día. Yo tengo por acá una pregunta. Eh, pensando en pues ya una uno lo que mencionabas, los desarrolladores tienen toda esta carga de trabajo, pues ciberseguridad también tenemos un montón de cargas de trabajo y sí es importante el darles como el mayor detalle, ¿no? por ejemplo, en el blog, en la descripción, en lo que tienen que hacer, ¿ves herramientas que ahora apoyan a los desarrolladores como tipo Jitop Copilot ya estén en un nivel en el que les puedan ayudar incluso en remediación o todavía no estamos tan ahí para que eso sí incremente la velocidad en que están remediando cosas? Gracias por la pregunta. Sí, tenía pendiente que nadie me fuera a preguntar algo de inteligencia artificial porque

todo el mundo lo estamos usando, ¿no? Eh, personalmente he visto que todas las herramientas, los agentes eh si continúan alucinando, pero entre más contexto le des de el problema que estás tratando de resolver, te van a los puedes apuntar, los puedes alinear de tal forma que te pueden dar una solución un poco más cercana a lo que quieres lograr, ¿no? Si por ejemplo estás tratando de utilizar LLMs para generar el parche de un de un código, ¿no? Entonces si solamente le dices al LLM, oye, esta versión que tenemos aquí es vulnerable en general, el nuevo manifiesto que tenga la nueva versión más actualizada, pero tú no sabes si esa nueva versión ya existe o si esa versión

es compatible, eh pues es muy seguro, muy probable que vaya a alucinar, ¿no? Pero si tú puedes obtener esos datos de alguna forma, de nuevo utilizando automatización, scanners, agregando esa información a tu pipeline de descubrimiento de riesgo y tú le puedes decir exactamente, crea este nuevo parche con esta nueva versión que remedía la vulnerabilidad, este es muy seguro que vas a tener mejores resultados. Entonces, he probado los LLMs de forma en mi trabajo del día a día, también de forma personal y eso es lo que he descubierto hasta el momento, ¿no? Entre más contexto le des, este, entre más lo alínees y todo eso lo puedes automatizar, ¿no? No tienes que estar escribiendo el mismo Chrome una y otra

vez, sino puedes integrarte con las API de Yemini, eh, de todos los demás, este, te van a va a ser mejor al generar los parches, ¿no? Pero aún así de todo, recomiendo que haya un humano que revise ya, o sea, el humano quizás ya no necesita revisar en cada paso del de la remediación o del descurgento de riesgo, sino simplemente en el último paso, ¿no? Antes de leer el bog, el humano puede este verificar que todo se vea bien, que no haya alucinado y este darle sí, ¿no? Mandar mandar baj. Entonces, esa es una forma que lo puedes hacer. Gracias.

En este lado, este, bueno, mi preguntará como qué riesgos consideras que son los más subestimados actualmente por muchas empresas. Bueno, porque sí me ha tocado como que lo personal a veces com mencionado hace rato que luego no dan mucha prioridad a ciertas cosas, pero ¿por qué consideran que no es importante o que no tiene como un impacto relevante si les llega a pasar algo? Uy, qué muy buena pregunta. Eh, en mi opinión, bueno, depende mucho de de cuál es el nivel de amenaza, ¿no? Para el que estás expuesto, pero el el insider thread, ¿no? Porque son los mismos empleados que tienen credenciales con permisos elevados, que no importa si tú tienes un montón de una

infraestructura muy fuerte de monitoreo, de escaneo, tienes antivirus. Si tienes un empleado que puede hacer cambios unilaterales en una infraestructura, puede desplegar cualquier código que nadie revise, puede factorizar repositorios, máquinas virtuales, o sea, un empleado por sí mismo puede destruir una compañía, ¿no? Si no tienes los controles adecuados. Eh, lo que he visto en la opinión personal, no hablando a nombre de la empresa, es eh ese tipo de riesgo de seguridad ya, digamos es tomada en consideración ya cuando las empresas tienen una cintaz, ¿no? porque requiere inversión en controles de seguridad, requiere rearquitectar incluso varios procesos de la compañía para que todo lo que un empleado haga, pues digamos que todo el código que un ingeniero mande a

un repositorio pues pueda ser revisado, ¿no? Y verificado. y requieres personas en varios usos horarios y requieres cosas de ese estilo, pero el riesgo de Insider Trade es uno de los más de los más relevantes. Muchas gracias.

¿Alguna otra pregunta? ¿Tenemos espacio para una más?

Ah, bueno, mi pregunta es de que muchas veces o incluso se comenta de que cuando se hace un management, pues que te dirijas con

personas y no se tienen claro muchas cosas. En ese caso, ¿cómo recomendarías empezar a hacer este tipo de management y quizás qué frameworks o qué framework verías más adecuado? Eh, sí, esta esta pregunta está va muy relacionada con y hay libros sobre esto, ¿no? De cuál es tu primer h, cuál es tu primera contratación de seguridad en un startup, ¿no? Y generalmente tiene que ser un rol, un unicornio, ¿no? sabe tanto de la parte técnica como de la parte del negocio, que puede moverse entre todos los niveles y puede eh implementar de forma básica esos controles técnicos y también crear los procesos porque no van a haber procesos en la compañía, ¿no? Él tiene que ir

investigar, sacarlos del del NIS, sacarlos de varias otras publicaciones y tratar de traerlos a la compañía y tratar de educar a toda la gente de ahí, ¿no? Entonces ahí sería mi respuesta sería el problema, ¿no? De la primera contratación de seguridad de la empresa, ¿no? Este, y si hay unicornios, pero están caros, ¿no? Entonces sí, esa sería mi respuesta. Muchas gracias. Listo, chicos. Pues agradecemos mucho a Lenin y vamos a darle un fuerte aplauso por compartirnos toda su experiencia. [Música] Y vamos a dar una breve pausa porque ya es la hora de la comida, entonces pueden bajar, pueden hacer networking, no lo olviden. mucha [Música]