Del CVE al CEO: Cómo hacer que la Alta Dirección escuche a los Hackers

Fue lo más técnico que pude ser. Eh, no tenían como tal una cuenta de correo a la cual pudiera yo reportar la buena realidad, así que fue como de soporte. Obviamente me banearon, pero con los años he aprendido que no se trata siempre de reportar vulnerabilidades de la manera más técnica posible. Hay como dos cosas bien importantes para reportar vulnerabilidades y es contar una historia. Es bien importante saber contar una historia, pero también a quién se la vas a contar. No puedes contar la historia de la misma manera para todo el mundo. No puedes contarlo de una manera supertécnica si se lo vas a reportar al director general de la empresa o al director de finanzas.

Por ejemplo, si tú estás trabajando para una empresa y quieres obtener para más herramientas, pues no te vas a ir a reportar super técnico al director de de Füenzas, ¿no? Tienes que reportarlo de otra forma. Y como en un inicio yo cometí el error de hacerlo como muy técnico, la realidad es que lo que yo he visto en estos años es que todos los que nos dedicamos a seguridad informática ofensiva seguimos cometiendo el mismo error y es que prácticamente en todos los reportes que generamos esto que llamamos resumen ejecutivo termina siendo más un resumen decorativo. en los reportes. Si se fijan, todos tienen prácticamente lo mismo, o sea, todos tienen colores de un una gráfica de calor. Hay quienes

ponen cubos, cuadros, ponen un montón de matrices diferentes, pero es exactamente lo mismo. Y de ejecutivo no tiene pues absolutamente nada porque realmente no permite generar accionables para las organizaciones. Lo único que hacen es poner una cantiquita bonita que le va a servir al equipo de GRC para pasar auditorías, siempre y cuando no haya rojos o cuando es más alto de los rojos. va a servir también como para espantar tal vez un poquito a la gente cuando le entiende o medio le entienden, porque si nosotros en el propio resumen ejecutivo metemos toda la teoría de cómo funciona el CBS score, pues qué padre, es a lo mejor alguien que te lo entienda de seguridad, pues está chido. Pero si se lo presentas

a un se level, con el se level tienes 3 minutos de atención. y no te va a hacer caso, no te va a entender de qué estás hablando. [Música] Entonces tenemos mucho que dejar de hablar también de vulnerabilidades propiamente cuando queremos conseguir botados [Música] y me pasó mucho con diferentes clientes que reportábamos vulnerabilidades altas o críticas varias veces, varios años seguidos y a quienes se lo reportaban no solamente estaba el director general, sino tenían ahí al director de tecnología. Y el director de tecnología siempre era como, pero no pasa nada, o sea, tenemos 10 años funcionando con estas tecnologías obsoletas o con estas vulnerabilidades que nos vienen reportando tú y la consultora anterior y otra consultora y no va a pasar nada, o

sea, no hemos mitigado y como pues no importa, o sea, para qué no mitigamos y ahí está y no ha pasado nada. Entonces todas esas constructoras lo han estado presentando de la misma manera, de una manera técnica, con grafiquitas de diferente forma, con los mismos colores, pero no funcionan para nada realmente.

[Música] Entonces, tenemos que entender que no podemos quedarnos solamente con la parte que tenemos en los cursos de ofensiva de offensive security o de easy o que ustedes digan que a final de cuentas se centrar completamente en CDs y en CS solamente. Muy difícil van a poder encontrar el tema de los riesgos en esos cursos. Es importante que hagamos esas traducciones de vulnerabilidades a riesgos. Ah, en esta sesión no puedo hablar, no me alcanza tiempo de hablar de todos estos cuatro frameworks que son como muy importantes para la traducción a los riesgos y para tener o para eh si necesitan a lo mejor en sus equipos una persona, dos personas más poder decir con bases, con sustentos

necesito a otra persona más en equipo. Me voy a centrar en uno, pero es importante mencionar estos cuatro. ISO 31,1 nos va a ayudar a gestionar riesgos. Es una norma internacional que nos va a ayudar a definir los riesgos, a tratarlos y a estarlos evaluando continuamente. Es algo que no podemos estar teniendo riesgos como con aceptación durante para siempre eternamente. Tenemos que estarlos evaluando constantemente. El risingology nos va a ayudar a que ya que determinamos cuál es el riesgo, que no es lo mismo que la criticidad de la vulnerabilidad, el riesgo es completamente distinto, vamos a poder priorizar cuáles merecen más atención o una atención más pronta. En cuanto a DS C maority Model como tal

no está enfocado en riesgos. es mucho más bien para organizaciones que se dedican al desarrollo interno de aplicaciones o de soluciones de software, etcétera, pero lo que nos va a ayudar es tener trazado un roadmap a través del cual podamos definir en qué momento durante un periodo de tiempo dado, 3 años, 5 años, vamos a necesitar crecer a nuestro equipo de seguridad, de aplicaciones de retín, de seguridad ofensiva de por lo necesitamos. Y el más importante, que es el que vengo a hablarles el día de hoy, es el fair, que es factor analysis of information ris, que lo que nos va a ayudar es a traducir los riesgos, ya que los identificamos a través de ISO 31000

en lana, que es lo que le importa a las empresas, ¿no? No podemos llegar, entonces ya dicho a decirles, tienes una vulnerabilidad crítica, arréglenla porque pues vamos a tener un montón de detractores en en la mesa cuando estemos presentando la vulnerabilidad, pero sí podemos llegar con un esta vulnerabilidad tiene este riesgo que puede pasar tantas veces al año y te puede costar tanta lana al mes o al año, pero además todavía más importante es puedes evitar que te cueste 12 millones de dólar y invirtiendo millón de pesos y ahí va a cambiar mucho el cómo se va a comportar la gente que está reportando la

tema con con Fer en cuanto a la adopción es que nació Estados Unidos por el montón de regulaciones que hay en Estadosos Unidos y como tal, pues obviamente la adopción es muy alta allá, ¿no? Ya no solo se enfocan en la parte del CS SCOR, allá también están obligados a decir cuánto va a costar una vulnerabilidad de ser exportado. Mientras que en Europa pues va poco a poco creciendo también por las regulaciones, por el GDPR, tienen que estar enfocados también un poquito más en cuánto les va a costar si si son vulneradas las empresas y tienen que hacerlo público. Esto sobre todo muy enfocado en sector financiero.

En Asia hay algo de interés, un poquito de interés, pero realmente no hay una adopción masiva de de este de este framework, que de hecho este framework nació un año después de que nació el CBS Score. El civil score nació en 2025 y el FIR nació en 2006. estaban más o menos desarrollándose la P los dos en Estados Unidos, pero pues a final de cuentas la cultura creo que muy global es enfocarse en lo cuantitativo y no en lo cualitativo, no en la [Música] en América Latina, pues apenas empieza a conocer y es un problema o es como un happy problem, digamos, porque sí se puede empezar a adoptar. Ahorita vemos un poquito más adelante lo

de el framework y todo lo que tendríamos que considerar para poder utilizarlo, pero el problema con América Latina es que nos gusta ocultar las cosas o tenemos esa tendencia a ocultar las cosas. Ah, si hay un incidente de seguridad que no se enteren porque lo van a multar. Entonces, ese es el problema latino, ¿no? Por eso no hay una adopción tan grande de este framework, porque no nos gusta pues quedar evidenciados. Esto debería de ser como impulsado desde el gobierno que nos veamos obligados a hacerlo, incluso desde el CEO de las empresas. Pero pues es es, o sea, es un tema cultural por qué no se ha adoptado tanto el nombre en cada tribuna. Y en África, bueno, en África

definitivamente la opción es superbaja, eh es solamente conocido en universidades y pues no, o sea, realmente no tienen como ni los recursos ni la gente necesaria como para poder empezar a impartir el cómo adoptar este framework. Este es el framework como tal. Como pueden ver, tiene un montón de variables que se deben de considerar. Empezamos del riesgo, es lo primero que tenemos que tener. Por eso lo de ISO 31, porque debemos de tener bien identificado cuál es el nivel de riesgo de las habilidades, hacer esta como transformación y a partir de ahí hay un montón de cosas que tenemos que obtener, lamentablemente, como decía en América Latina y no tenemos toda esa información. No vale mucho la pena concentrarnos en

esto. Lo que yo hice fue hacer una modificación a este framework de acuerdo a cosas que sí podemos tener hoy en día, por lo menos en América Latina, para poder adoptar este framework que además está muy enfocado solamente en presentar riesgos críticos y riesgos altos. No es para riesgos bajos, medios ni significados, es para riesgos críticos y altos. Es ahí en donde podemos hacer uso de este framework y conseguir lo que queremos, ¿no? Más dinero para capacitaciones, para personal, más personal etcétera.

Si se fijan, está como mucho más simplificado. Lo que necesitamos es el nivel de riesgo. Necesitamos eh la frecuencia con la que podría existir una pérdida. y la magnitud de esa pérdida. Adicionalmente, necesitamos pues propiamente la amenaza, saber cuál es la amenaza, en este caso, la vulnerabilidad y qué tan expuestos estamos ante esa vulnerabilidad, ante para que nos ataquen. El tiempo de respuesta, pues hoy en día si no tienen un SOC interno, por lo menos tienen contratado un servicio de SOC. Entonces, sabemos ese tiempo de respuesta también ante ataques. Y dos cosas bien importantes que es lo que nos va a dar el tema de la lana, que es el costo operativo. Es decir, siemos

un ataque, cuánto tiempo va a estar abajo nuestra aplicación o nuestro sistema y eso cuánto nos va a costar. Y regulatory finds es las mutas. Quizás ahí podemos entrar en un poquito ese conflicto porque también, o sea, no existe como tal esa transparencia de cuánto es, cuánto nos puede montar. No está como 100% regulado en México ni en toda América Latina. Hay países en los que sí, pero el padre de este framework es que no tiene que ser exacto. Necesitamos que sea bastante acercado a la realidad, pero no tiene que ser exacto. No tenemos la obligación de decir, nos va a costar esta vulnerabilidad o este riesgo 20 millones de pesos. te firmo porque tal y tal y

tal cosa, ¿no? O sea, es un valor aproximado a lo que nos puede llegar a costar, ¿vale? No necesitamos como que sea super preciso. Eso está bueno porque entonces simplemente quizás no tenemos toda la información de manera interna en el desarrol, pero sí tenemos un poquito de información en el medio. Por ejemplo, si trabajamos en sector financiero, tenemos referencias de cuánto le ha costado una multa a otros bancos o a otras instituciones financieras por una vulnerabilidad no necesariamente igual, pero similar. Pues por ahí nos podemos ir dando una idea y poder y bueno, aquí es literal de dónde podemos obtener esos datos. La parte de threads and exposure necesitamos como información necesaria la frecuencia de

los ataques y cuáles son los activos expuestos. El stakeholder, es decir, quién nos va a dar internamente esa información que necesitamos para utilizarla en el framework, puede ser el software, el team, el siso, infraestructura, es decir, todos aquellos dueños de activos de información. Y la unidad recomendada es cuántos incidentes por año podemos tener o hemos tenido ya. response time, los tiempos de contención y de detección. Esto nos lo puede dar el equipo del SOC, que ya decía que puede ser interno, puede ser un servicio subcontratado. A veces ni siquiera tenemos un SOC interno ni subcontratado, pero sí hay alguien internamente como que hace este champ, ¿no? Un equipo que hace este champ. Puede haber equipos de

ciberseguridad que sean topólogos y que terminen teniendo esta información. Entonces, pues ellos les pueden dar esa información. ¿Cuál es la unidad recomendada? Horas. Operational, el valor de procesos críticos y pérdidas por no estar operativos por hora. Eso se como se se trae de response time, ¿no? Por eso es el valor en horas. Entonces, también los procesos críticos, ¿cuánto tiempo eh pueden estar fuera de línea y cuánta lana nos va a costar? Ahí pongo en pesos o en dólares, pero pues bueno, al final de cuentas se puede modificar a la moneda nacional de cada país y regulatory fins que te decía, multas y sanciones por cumplimientos. Aquí puede ser IN, puede ser CB, puede ser GDPR,

puede ser BIC en el caso de México, etcétera, ¿no? Enend país es quien te dice la multa que puede llegar a tener dependiendo del incidente de seguridad e stakeholders GRC, definitivamente ellos tienen que estar super metidos, empapados de esa información. Si ellos no lo tienen, tal vez estás en un pequeño problema, pero puedes también llegar a consultar un individo, ¿no? O sea, te tocaría como aventarte la chamba de leer las leyes, las reuniciones y obtener toda esa información, pero lo tienes que hacer, ¿no? O sea, si quieres obtener algo, pues tienes que obtener esa información. Y la unidad recomendada es monto estimado por evento. Este evento normalmente es por año, o sea, buscamos que sea a lo largo del año. ¿Cuántas

veces puede pasar que ocurra esa vulner? Y acá abajo pongo un ejemplo en el que ponemos una aplicación financiera crítica que se cae por 3 horas. El costo operativo es de 104,000es o dólares. Eh, por hora cuesta tanto. E y la multa regulatoria es de 1,000 ante la Comisión Nacional Bancaria y de en conjunto la magnitud de la pérdida, que es lo que buscamos tener, pues el valor final que buscamos tener, es de 1,512,000 pesos por evento. Ya con eso podemos presentar de otra manera completamente distinta la vulnerabilidad o el riesgo ante pues la junta directiva. [Música] Y bueno, si se preguntan cómo es un recorte utilizando esta parte de fair, realmente no existe como un estándar, no

hay una guía de cómo reportar las manera o los riesgos de esa manera, pero estamos hablando de que se le va a reportar a los directores, a los CB, eh al director general, a gente que no es técnica. Nos queremos saltar a la gente técnica para que no ponga pero esto no se tiene quear y como decía al principio, tenemos por ahí una ventana de tiempo de tr 5 minutos de atención de los directores porque hablan muy montón de cosas lo mejor es ser lo más gráficos posibles, generar un slide, dos máximos y tenemos demasiadas variables críticas o altas y justo presentar la pérdida estatal. ¿Cuánto esperamos para ver si esto sucede? Si nos atacan, si nos

vulneran, si explotan la unidad y cuál es la el porcentaje o el total del que tendríamos que invertir. Por ejemplo, ahí con la pérdida total 38 millones tan solo de cuatro vulnerabilidades, dos críticas y dos. Ya no le va a importar mucho a la persona qué vulnerabilidad es aunque ponga ahí el nombre de la vulnerabilidad, ya no pongo una descripción nada, tres, nombre de la vulnerabilidad, pero pongo más énfasis en la lana que va a costar. Son los 38 millones. Y para invertir, para evitar que esto pasa estamos proponiendo de entre 5% y 20% del ¿Qué va a preferir el director general de la empresa? tener que pagar 38,000ones por venta de esa vulnerabilidad que van a exportar por invertir 5 a 20%

de esos 38 millones probablemente por una razón, ¿no? O quizás si se hace contratos multianuales, este se va diferenciando con pagos así, pero va a ser mucha menos gana la que tiene que desembolsar la empresa en lugar de tener que pagar por cada evento, porque cada evento que teniendo puede ser una vez al mes, puede ser una vez cada tr meses y cada 3 meses pagar 38 millones de pesos [Música]

¿Qué es lo que no funciona al momento de presentar las vulnerabilidades, los riesgos con los ejecutivos? Bueno, lo que no funciona es usar únicamente el lenguaje técnico sin más bien utilizando solamente círculas, SQLI, XSS, eso no importa, eso lo entendemos nosotros que somos técnicos. A les ni siquiera te van a preguntar qué es o cómo los explotas. No se sabe ni siquiera que es una explotación de vulnerabilidad. No sirve de nada presentarlo de esa manera. No sirve decir es una vulnerabilidad crítica. Porque entonces tenemos a estos detractores que decía inicio, que son parte del equipo que trabaja para el CEO y que su trabajo es en ese momento no perder su trabajo, ¿no? Porque al tener

esa vulnerabilidad crítica en los servidores que ellos administran los pueden correr. Entonces, lo primero que van a hacer es decir que no pasa nada, que han pasado años y nunca ha pasado nada porque lo van a no funciona que digamos que es unidad. Necesitamos poner ahí los módulos. Tampoco funciona no indicar una urgencia o una priorización en la mitigación. Por eso es lo que comía inicio sobre diferentes fríulas para poder determinar cuáles son más importantes de mitigar. Quizás tengamos cuatro vulnerabilidades críticas, pero no necesariamente las cuatro vulnerabilidades críticas se tienen que mitigar de manera inmediata. Tenemos que poner foco a las que cuestan más lana en caso de ser recrutadas. omitir el qué pasaría así, porque de

nuevo tenemos a los detractores y podemos decir, bueno, pero es que, ¿qué pasa si te explotan esta vulnerabilidad y te roban la base de datos? Igual y ya pasó. En una de esas ya pasó y ni nos enteramos. O sea, tal vez ya pasó un montón de veces, está en foros, está en leaks públicos y pues la gente que es encargada de esos servidores van a decir, pues no pasa nada, o sea, ponme todos los ejemplos que quieras, no pasa nada, no ha pasado nada en 10 años. Eh, y también lo que no funciona es este que no tenga el C to action. Por eso decía que estos reportes que están divididos todos, y eso lo haemos todos,

los reportes de PTS están divididos en dos partes, resumen ejecutivo y detalle técnico. Todos los reportes de cuenta escriben eso. Ese resumen ejecutivo no tiene un deb. Entonces, eso no funciona si queremos que mitiguen realmente las vulnerabilidades crédicacionales. ¿Qué sí funciona? traducir los hallazgos en impactos al negocio, en dinero, eso es lo que se funciona. Conectar los riesgos con cumplimientos normativos. Sé que esa aburida la parte de cumplimiento normativo para los que somos técnicos, pero algo que me he dado cuenta es que es muy importante que no nos quedemos solamente con la parte técnica ofensiva, sino que nos volvamos multidisciplinarios. No podemos depender de tener en el equipo a una persona completamente técnica que se enfoca en pentes de

móviles, otra persona para fentes de web y otra persona a la que vamos a consultar solamente para hacer el reporte. No tiene ningún sentido. La chiste es aprender un poquito de todo. No nos vamos a los porque no. Pero lo mínimo necesario para poder traducir estos riesgos a los cumplimientos normativos, es decir, que es controles de ISO 27001, por ejemplo, de PCI estamos incumpliendo, eso es muy importante porque entonces nuestro reporte de Pentecest no nada más lo vamos a enfocar a las vulnerabilidades indicadas de manera técnica. Nuestro de Pentex debe de servir a diferentes áreas, debe de servir al Señor, debe de servir al debe de servir al equipo de y si podemos ayudarles un poquito como

trazándoles la vía para ver qué controles están fallando. [Música] Ah, tenemos que usar ejemplo del sector. Esto les decía como en dos diapositivas. ¿Qué otros eh competidores a lo mejor han sufrido ataques del mismo estilo de las vulnerabilidades que estamos reportando? ¿Y qué es lo que pasó con ellos? Seguramente lo que pasó con ellos es que la regalaron Seguramente lo que pasó con ellos es que tuvieron que pagar unota y trataron por todos los medios de evitar que la gente se entere y no lo lograron al final de cuentas. E otra cosa que sí sirve es dar escenarios comparativos, es decir, que puede pasar si mitigamos, que puede pasar si no mitigamos, ¿no? ¿Cómo nos

puede impactar? Y finalmente proveer recomendaciones concretas con costo estimado. En el slide anterior ponía como la vulnerabilidad, lo que puede costar cada vulnerabilidad, pero también es importante no solo enfocarnos en la parte total de la lana que puede costar, sino cada vulnerabilidad, cuánto le puede costar a la empresa. un SQL injection, por ejemplo, que pueda costarle 500,000 pesos a la empresa si es explotado por evento. ¿Y cuánto puede costarle mitigar? Mitigar siempre va a ser más económico que pagar una multa y pagar dos costos operativos. Aquí hay otro ejemplo de una vulnerabilidad bastante conocida. como un incidente de seguridad bastante conocido de Equipas en el que se robaron datos de 148500 tiene un CE asignado. Eso lo podemos

hacer si queremos en el reporte hacia los ejecutivos, pero tampoco hay como que estar detallando, ¿no?, de qué se trata el CBE. Ponemos ahí entre entre paréntesis cuál es el CB y listo. En términos de FER, por cada dólar invertido en prevención se habría evitado una pérdida de $2800. Así es como se le tendría que presentar a la dirección. Es bastante diferente que si solo ponemos crítico porque el CBS Score nos dice que hay una afectación a disponibilidad, a integridad, etcétera, ¿no? Eso no le va a importar al C. Y pues bueno, ahí viene ya los números en grande, que eso es lo que va a causar algún impacto en la dirección. Y esto es otro de British Airways, un

robo de datos de 500,000 clientes por un JavaScript malicioso. En términos de FA, igual por cada dólar invertido en prevención se habría evitado una pérdida de 300. Cada dólar evitamos pagar 300.

Aquí les pongo algunas consultas, referencias por si quieren tomar fotos eh sobre lo que ponía al inicio, parte de ISO 31000, el Last Risk Rating, DS Mat y algunas otro par de de consultas que puede funcionarles a ustedes para implementar este modelo [Música] Ahora, ¿cuáles son los pros de utilizar el modelo F? Nos va a permitir cuantificar los riesgos, es decir, transformar en dinero cada una de las vulnerabilidades. Nos va a permitir soportar decisiones estratégicas en la organización. Es flexible. lo que decía, no tiene que ser preciso, no tenemos que decir es esta cantidad de lana que vas a perder y no va a ser más, ¿no? O sea, estamos como en un aproximado, ¿no? Porque no

tenemos como en Estados Unidos toda la información necesaria, pero pues nos podemos dar una una idea, por eso es que bastante flexible. e complementa otros frameworks como hizo 27001, NIS, etcétera. No es como único, podemos echar mano de muchos otros frameworks y reduce la subjetividad. Lo que para una empresa es crítico, no necesariamente es crítico para otro, ¿no? Depende mucho de los controles que tengan aplicados, depende de las personas incluso queen las herramientas de seguridad. Entonces evitamos eso. [Música] Y los contras, ah, esto es creo que lo lo peorcito, lo más complicado es que requiere un cambio cultural en las organizaciones muy importante, no solamente en ciberseguridad, sino en toda la organización, con todas las

personas con las que vamos a ir a tocar base para obtener la información necesaria. pues definitivamente requiere un cambio cultural, requiere que la gente entienda que no podemos estar ocultando información. E hay una alta dependencia de todos los stakeholders que mencionaba anteriormente, porque si no esa información no lo vamos a lograr. Hay una cueva de aprendizaje importante porque pues realmente todos utilizamos CBS SC, entonces estoy casi seguro que nadie o muy poquitos de los que estamos aquí conocían este framework y entonces hay mucho que hacer, ¿no? Como mucho trabajo por entender cómo funciona el framework y tratar de empezar a hacer ese ejercicio de reportar de una manera diferente la vulnerabilidad. hay una falta o desconocimiento de

datos. No, desafortunadamente no siempre los stakeholders a los que vamos a ir a preguntarles tienen esa información. Muchas veces vamos a tener que echar mano de lo que encontramos como de manera pública en noticias eh del propio gobierno que luego saca notas de cuánto impuso de multa a una empresa. Entonces se vuelve un poquito complicado, pero no por eso imposible. y poca automatización. Eso probablemente es algo que nos puede llegar a pegar. E a diferencia de CBS Score, pues ya podemos automatizar los reportes de PEN test. Hay muchas herramientas hoy en día scripts que nos permiten automatizar la generación de con Score, pero esto no se puede automatizar de una manera tan fácil. Podríamos si contáramos con toda

la información necesaria como en Estados Unidos, pero como no la tenemos pues tenemos que hacer un montón de chamba como artesanal. Y listo, eso soy yo. Algunos, un par de facts es lo que comentaba al inicio, eso lo iba a final que me habían bañado de PB. Eh, no sé si por eso mismo no podía sacar la visa durante un montón de tiempo. Realmente apenas hace poquito pude sacar la visa. Estaba como en una negra y pues nada, trabajo como como decía al principio, como consultor y como eh application manager enm consultor por fuera eh y he tratado de enfocarme como en ser lo que decía durante la presentación. multidisciplinario, no más temas de seguridad ofensiva, también me

gusta pues todo lo de cumplimiento. He implementado 17,000 satisfactoriamente en un par de empresas y no sé si tengan preguntas. [Aplausos] [Música] [Aplausos] Agradecemos por tan importante información. Creo que una pregunta, justamente vamos a abrir la sesión de preguntas y respuestas para quien tenga alguna pregunta que le quiere hacer, aproveche y pues que puedan compartir más. ¿De qué lado preguntas? Mantén la manita arriba.

Mi pregunta es, bueno, primeramente muchas gracias por la plática, estuvo muy interesante y la pregunta es si esto se puede aplicar en una empresa que como que va comenzando a querer madurar o mejorar su su seguridad o qué recomiendas hacer antes de aplicar Eso siempre y cuando tengas la información que ponían como en el framework simplificado, lo puedes hacer sin importar la la empresa, el tamaño, la el nivel de madurez, inseguridad que tenga la empresa, no se puede hacer. Entonces va a depender mucho de que puedas contar con esa información. Si la tienes, se puede se puede utilizar. Yo justo lo que decía, te recomendaría que de entrada no lo uses, utiliza el framework normal, el CS score y cuando

tengas problemas para que atiendan las vulnerabilidades críticas y altas, cuando se pongan un montón de peros, úsalo para una próxima vez, un test, un pentesta al siguiente, utilízalo porque vas a obtener diferentes resultados. Ah, okay. Muchísimas gracias. Listo. ¿Quién va preguntar acá? ¿Cuál? ¿Qué metodología? Bueno, sí, sé que mencionaste que es difícil, pero ¿qué qué no recomiendas para cuantificar los las vulnerabilidades, los riesgos? Sé que nos mostraste algunos links, pero nos pudieras poner un ejemplo de un caso más real o o que sin decir nombres pues que haya pasado o algo así. ejemplo como tal, ¿no? Pero, o sea, no de una vulnerabilidad en específica, pero si necesitas, por ejemplo, un framework para determinar niveles de riesgo,

decía, hizo 31,000, está bien, nada más que es como como la mayoría de los ISOs tiene su complejidad, se vuelve complejo y no todas las empresas lo quieren utilizar y no siempre es como muy rápido de de calcular el riesgo con ese disgo. El GBM lo que nosotros implementamos es un eh modelo framework como adaptado también por nosotros que tomamos de Mozila que se llama Rapid Tist Assessment, que es prácticamente un cuestionario eh también, o sea, es como muy flexible. tú puedes generar tu propio cuestionario, pero el cuestionario que tenemos creo que tiene como 17 preguntas, por decir así, más o menos, como 17 preguntas. Creo que las primeras cinco o seis son como muy generales, nada más como para

conocer el nombre de la aplicación o del sistema, qué fue desarrollado, etcétera. Pero ya más adelante lo que te permite calcular el nivel de riesgo son seis preguntas. Son solamente seis preguntas. Y con eso determinas el nivel de riesgo de la aplicación o del sistema que se va a desarrollar. A partir de ahí tienes que hacer un Pestas un PDT. Ese nivel de riesgo que te da el Rapid te va a decir si la aplicación o el sistema necesita unos Pentes. Si es un riesgo moderado, alto o crítico, necesitas realizar el Pent. Si es bajo o informativo, no realizas Pentecest. Pero es análisis automatizados, SAS, SSA, revisión de librería, revisión de secretos, etcétera. DAS, por ejemplo,

¿no? Ya lo defiendes tú. Ya cuando hagas el pendías, si tú ya conoces a tu cliente o ya conoces y como de manera interna conoces a tu director y sabes que te va a poner un perro para motivar las moderalidades, ahí lo puedes utilizar. Puedes utilizar, te digo, a final de cuentas puede ser que no tengas toda la información precisa, pero sí puedes echar mano de noticias y de pues sí, sobre todo de noticias que haya de vulnerabilidades previamente exuadas y llevarlo que sería deción trabajo, ¿no? Empezar mucho trabajo. Tendrías que hacer como esa conversión es complicado, no es como que haya una fórmula precisa, eh, es buscar en otros lados lo que les ha

costado, ver el tamaño de ese empresaje, compararlo cono y hacer digo, es bastante flexible, entonces no necesita ser super la cantidad de dinero que va a costar, perdón,

Listo. Eh, otra pregunta. Hola, buenas. Eh, en estos reportes se enfoca mucho siempre a parte del que confirmaste, pero hay todo este universo de cientos o miles de calcidades qué importancia. le das ahíes o te enfocas nada más en esto porque es un programa que me he enfrentado donde yo le digo, tengo dos crítica, pero de pronto que dije, no, pero aquí hay 100 eh que salieron del ¿Cómo le das ese enfoque al deporte de Es que no depende de que sea solamente el PEST, o sea, hay empresas que ni siquiera ejecutan Pentex, hay empresas que ejecutan, por ejemplo, el gasto No, automatizados y ahí tienes las vulnerabilidades críticas y altas y te enfrentas a los problemas de que no

quierenar. Puedesar, o sea, no necesitas y no dependes de lo único de lo que dependes es de traducir la criticidad de la vulnerabilidad al nivel. Ya a partir de ahí los indicado y negativo la pregunta. En mi caso, el interés es cómo conviertes esos niveles de riesgo a la parte monetaria. Ahorita mencionabas, por ejemplo, una parte de unas multas o sí algo que tiene que pagar quizás cada que es exportado. ¿Cómo hago eso? ¿De dónde saco esos datos? A ver, el caso de México. Sí. Pon ahí que hay diferentes stakeholders internos. En el caso del dinero, definitivamente tienes que ir con el c de la compañía, lleva las finanzas de la compañía para saber ellos deben de tener

ese dato. Si no lo tienen es un problema mayor entre ellos, ¿no? Pero deben de tener ese dato de su aplicación principal con la que atraen clientes, con la que cobran la lana, con la que están pagando los sueldos. Ellos deben de tener bien identificados cuánto le cuesta que esté abajo una hora, que es la medida que pusimos que debes de tener por hora cuánto te cuesta. Ya de aquí ya tienes el dato, tienes cuánto te cuesta. Eso nada más de la parte operativa, de la parte de multas. Lo que comento, aquí en México y en general en América Latina es difícil primera vez fue como hijo, o sea realmente hijo de de una injection que cuesta tamb,

pero puede buscar noticias empresas a las que hayamos que es muy común lo de lo de es muy común de que te roban la base de datos y puedes encontrar o preguntarle a lo tiene. Si tienes esa información es mucho más sencillo progreso preguntarle cuánto vale un registro de una base de datos que contiene tal tipo de información en el mercado de y con eso pregunta. Este, hablando acerca de la identificación de los activos, eh experiencia, ¿qué tan común es que las empresas eh tengan una adecuada valoración de sus activos de información? ¿Realmente saben lo que valen o es algo que realmente desconocen? No todas. Eh, insisto, es un problema cultural, esto va desde los equipos de GRC.

El equipo de es el encargado en las organizaciones, es decir, los de cumplimiento regulatorio son los encargados de tener los inventarios de activos. Los secretarios de activos se tienen que entender no solamente como la parte técnica, sino incluso como las personas, porque cada persona que trabajamos en una empresa correspondemos a un nivel de riesgo dependiendo del nivel de acceso que tengamos al y de la información a la que tengamos. Entonces, no todos lo tienen. Eh, pero justo eso es lo de ser multidisciplinarios, porque si nosotros como parte de seguridad ofensiva nos quedamos con solo va a ser nuestra parte de seguridad ofensiva, nunca va a suceder que podamos utilizar este tipo de premios que ayudan mucho. Tenemos que

dejar atrás esa mentalidad de eso no me toca a mí, eso le toca al equipo de regreso. Y pues si tú necesitas sacar esa información, obtener esa información de nuestra, pues tú haces el cálculo de riesgo, pones las piedras, te documentas y haces ese cálculo de riesgo. No necesariamente vas a sacar el riesgo de todos los activos de información, pero sí de los que necesitas para poder presentar.

No este y y es difícil incluso para GRS a veces porque, o sea, tu equipo de Team o blue team no quiere sobre todo blu, no no quiere eh las vulnerabilidades pues justamente conocen estas herramientas. Ahora para presentar a alta dirección como mencionabas con temas de dinero y otro eh por ejemplo cuando tienes que se hace tu mismo director, o sea, este vas saltando personas, vas escalándolo tal cual o tienes como alguna estrategia para noamente luego quedar en malos términos con tu director con tu jefe puede llevar a a otras repercusiones. ¿Alguien tiene alguna sugerencia qué hacer? Si tú quieres presentar esto, sabes que sabes que el impacto la organización, pero muchas a veces no tu

propio jefe, de tu director, etcétera, ¿no? Obviamente está entonces ahí o cómo lo manejas y no necesariamente saltarlo como primer paso. Eh, algo que aprendí el dio e que es el director que tienes que agotar todas las estancias que tú tienes para poder convencer a la otra persona de que no se están haciendo o de que no se están haciendo las Siotaste todas las instancias con jefe, por ejemplo, directamente y ya te batió un montón de veces, más que saltarlo, tienes que aprovechar los foros que seguramente Seguramente tienes, o sea, seguramente tienes alguna reunión semanal, alguna reunión audiovisual en donde haya gente tomadora de decisiones más allá de Entonces en esos foros los puedes aprovechar para presentar esto

así. Por eso es que esto justamente está pensado para 3 5 minutos porque no les va a quedar muchos o es literal 3 minutos posición les quiero presentar algo y lo presento. Seguramente va a un tema seguro, pero como lo habrá presentado es como que te puedan correr el corazón y la otra que creo que es todavía más si te corren por presentar algo que tú sabes que se tiene que presentar y que no parece [Música] lugar en el que tenías que estar trabajando. Gracias. Tengo una pregunta, este, ¿qué quieres hacer cuando el hallazgo entra dentro del apetito del riesgo del negocio en donde la remediación es igual a la multa que va a sufrir la compañía?

Bueno, creo que es bastante complejo que la primeración cueste lo mismo que compañía, pero en ese supuesto al final de cuentas arreglando a 31,000 para la gestión de riesgos está bien, o sea, si entra dentro delito de riesgo de haber una carta de aceptación de riesgo y como decía esa carta la aceptación de riesgo no puede ser permanente, tiene que ser evaluada de entre 9 meses al máximo 12 meses y y ver, o sea, qué es lo que pasa y Y en ese tiempo, si tú eres de seguridad labores del equipo de GRC por como equipo de GRC te puedes apoyar con el equipo de testing durante esos 9 12 meses a buscar la manera de más

fácilmente esa vulnerabilidad para hacer que el siguiente año cambien las cosas y no se vuelva a hacer una aceptación de riesgo. O sea, yo veo como que es muy reis, muy que se mantenga el mismo riesgo por 2 años seguidos, siendo un riesgo alto, auténtico, a pesar de que estudo de riesgo, una debería hacer. Entonces, ni modo, o sea, hay que buscar la manera de de cambiar las cosas, de a quien tengas que y pues como que no sobrevas.

Muy bien. ¿Alguna pregunta, chicos? Es fácil para una una eh Gracias. No es pregunta, más bien quiero compartir estos retos que estás comentando. Me ha pasado otra también el tema de los cyber seguros. O sea, ya ni siquiera cae elito de pides el inventario de activo, sale, pero no hay día. Entonces, entonces cuánto cuesta el tema de la afectación por hora, las áreas financieras, las apegadas de la operación, todo lo que comentan. Y la triste historia mía que te comparto es ahorrarlo nuevo. Bueno, pero el costo, ¿cuánto costó el ciberseguro? ¿Qué dic? Entonces cada vez más reto nosotros como comunidad ser claros en el lenguaje, la estrategia y y cómo le dijiste tú, retractores propios de negocio. Estoy un reto, la

especialidad, la información de negocio y ahora el tema de los ciberseguros. A mí en lo personal ha sido todo un tema, ¿no? Solo te quería compartir este otro aspecto además de lo que has dicho y agradecerte que te atrevas a ser así rutivo y hables estrategiaos modos. Gracias, Rafa. Gracias. Sí, pues es que justo, o sea, nos eso. Hay dos cosas ahora que resolver como se vuelve muy fácil para las empresas decir, no motivo compro el seguro o noivo acepto el riesgo y eso lo voy a hacer año tras año tras año. vanando los riesgos, las vulnerabilidades y en algún momento seguro no te va a cubrir las cantidad de vulnerabilidades que que te pueden

llevar a

[Aplausos]