En el pensar de...En muchas ocasiones cuando pensamos en el factor humano nos referimos al eslabón más débil en las organizaciones, para el cual existen programas con un diseño impecable para concientizarlo y hacerlo resiliente, sin embargo, este enfoque cubre una de las aristas respecto al factor humano. En este artículo me gustaría abordar otra arista que he podido observar a lo largo de mis años dedicados a la ciberseguridad.

Existen situaciones o condiciones que no podemos negar, tales como: una sobreaceleración en la transformación digital de las organizaciones, la pronta adopción de tecnologías (en muchos casos emergente) para llegar a objetivos de negocio, etcétera. Como bien se ha mencionado en otros artículos, esto sucede en un contexto VUCA, en el cual la complejidad es uno de los retos sin una receta única.

Lo anterior no es nada nuevo, por ejemplo, en 1999 Bruce Schneider escribió lo que para mí es una de las lecturas fundamentales que todos deberíamos consultar de vez en cuando, A Plea for Simplicity; a fin de simplificar y afrontar mejor la complejidad, muchos practicantes de la ciberseguridad usamos marcos de trabajo o metodologías, por ejemplo:

  • Lean
  • CPS
  • Critical thinking

O nos basamos en mejores prácticas o estándares, sin embargo, en muchas ocasiones caemos en una sobresimplificación, que puede crear condiciones desfavorables para la ciberseguridad, y con esto se logra incrementar la complejidad del entorno. Me gustaría abordar algunos ejemplos sin tratar de cubrir todos los escenarios:

Enfoque en riesgos

Es un muy difícil encontrar una organización que no esté ocupada gestionando sus riesgos, sin embargo, muchas de ellas han llegado a tomar muy literalmente la definición de la ISACA respecto a riesgo:

  • The combination of the likelihood of an event and its impact

Por lo tanto, contar con una lista de amenazas y medir su probabilidad de impacto en algún activo es la base de esa medición y gestión; mientras ese número esté en niveles aceptables, la organización está bien. El problema es qué tan seguido evaluamos esos riesgos y amenazas: cada momento (como recomienda el marco CARTA de Gartner), cada día, cada trimestre etc.

Algunas consideraciones que se deberían incluir podrían ser:

  • Amenazas, además de las tradicionales y bien conocidas, incluir actores de amenazas (interno y externos) considerando motivaciones y capacidades.
  • Definir y redactar los riesgos que estamos afrontando y no solo su impacto. A lo que me refiero es a que un típico riesgo podría ser ransomware o phishing, lo interesante es cuando se contextualiza: un actor de amenaza compromete credenciales de usuarios al enviar correos dirigidos y entregados a cuentas personales, los cuales son leídos en equipos corporativos de cómputo. Tanto la medición como su tratamiento podrían estar enfocados de una manera diferente y más eficiente.
  • Contextualizar los riesgos a Security Blueprints, y sobre todo procesos de negocio.

Certificaciones de la industria

Hoy en día la industria cuenta con múltiples tipos de certificaciones con diversos enfoques y requisitos para obtenerse, algunas son más teóricas y algunas más prácticas, sin embargo, todas ellas se basan en el estado de arte del tema que están certificando; esto puede llegar a crear una condición de sobreestimación del valor de estas para la organización. No estoy diciendo que las certificaciones no sirven o no debemos buscarlas, más bien debemos ponerlas en su correcto peso y contexto.

Cuando estamos buscando talento, la definición de una lista de ellas puede ayudar a los reclutadores a saber cómo y dónde buscar; cada organización debería tener muy claro el perfil de los roles que requiere, y cubrir certificaciones, estudios formales e informales, conocimientos técnicos, años de experiencia, soft-skills, fortalezas y habilidades. Si basamos simplemente nuestra elección para evaluar un rol o definir un path de crecimiento en certificaciones, podríamos llevar a nuestro personal a que cuente con conocimientos teóricos aplicados a condiciones estables o ideales, pero cuando los enfrentamos a la complejidad de la organización muchas veces se ven sobrepasados, y en el mejor de los casos sobrecalificados, pero al final seguimos sin cubrir ese perfil que nos ayude a cumplir los objetivos del negocio.

Automatización y orquestación de las operaciones

No podemos negar que la falta de personas capacitadas es un gran reto que enfrentamos, si a eso le sumamos que muchas de las operaciones de ciberseguridad se basan en actividades manuales o repetitivas en las que el backlog de eventos a analizar es muy grande, y además los equipos mantienen un nivel de estrés alto, entonces en muchas ocasiones se obtiene poca eficiencia operativa.

A fin de afrontar estos problemas podemos sobresimplificar al pensar que una plataforma de orquestación y automatización ayudará a lograr una transformación de la operación, sin embargo, en Latinoamérica venimos arrastrando desde hace varios años una cultura en la cual nuestros becarios y recién egresados, dada la falta de experiencia, son entrenados o asignados a proyectos en los que la tecnología de un fabricante, sea una hoja cálculo, un GRC, controles tecnológicos , etc., son la base de la ciberseguridad. Esto ha ocasionado que tengamos verdaderos expertos en tecnología y productos quienes poco a poco han apagado su pensamiento/mindset de ingeniería para resolver y afrontar problemas.

Automatizar y orquestar la ciberseguridad va más allá de conectar API y transferir tareas a una herramienta; hay algunos factores que no podemos dejar a un lado, como son Security Blueprints, casos de uso, casos de prueba de la calidad de la operación, runbooks, playbooks, además de la oportunidad de que nuestros ingenieros construyan plataformas/marcos de trabajo alrededor de la tecnología. Una interesante lectura para ir conocer más acerca de esto  podría ser Stealing More SRE Ideas for Your SOC.

Inteligencia de amenazas (CTI)

Uno de los temas que más me apasiona son las sobresimplificaciones, y he visto fallar por ello de diversas maneras; he aquí un par de ejemplos:

  • Considerar que mi equipo operativo puede obtener mejor inteligencia de amenazas de fuentes públicas que de los fabricantes de la tecnología que uso, y por lo tanto alimentar indiscriminadamente mis controles con esa inteligencia, comúnmente como indicadores de compromiso, pensando que estaré mejor protegido por bloquear un hash o dirección IP. Evitar una competencia sobre quién colecta más inteligencia puede evitarnos sobrecarga operativa, pero la verdadera CTI va más allá de encontrar IOC en la Internet y agregarlos a listas de bloqueo o de monitoreo.
  • Usar el ciclo tradicional de inteligencia, el cual fue creado y es usado por un grupo de inteligencia con gente solo dedicada a eso con muchísima experiencia, lo que conduce a no saber de manera clara cuáles son mis requerimientos de inteligencia y cómo puedo usarla. Salir al ciberespacio y colectar datos que luego no podemos procesar y, por lo tanto, no serán transformados en acciones, es una de las sobresimplificaciones que más veo. En su lugar, podríamos decidir usar la pirámide DIKW con su agregación de hechos y mediciones, como lo propone Valentina Palacín en su libro Practical Threat Intelligence and Data-Driven Threat Hunting, lo cual nos lleva a definir esos hechos (facts) y a convertirlos en requerimientos de ciberinteligencia, que podemos usar en nuestros casos de uso o Security Blueprints.

La suma de pequeñas sobresimplificaciones puede generar casos tan poco comunes como el de un centro de operaciones de seguridad con una gran cantidad de alertas para investigar, ya que no es posible priorizarlas de una manera simple dado que los riesgos que están tratando de afrontar siempre se localizan en niveles en los que se espera poco impacto. A fin de solucionar esto, contratan a un especialistas con cinco certificaciones de la industria, entre ellas la de experto en la mejor plataforma de automatización que van a comprar. Después de varios meses han logrado integrar 50% de sus plataformas y han creado los 10 playbooks más críticos de automatización y orquestación, sin embargo, la complejidad en ese momento es mayor que al inicio del proyecto; el impacto al negocio y valor son difíciles de demostrar.

Posiblemente hay otros ejemplo más claros e impactantes de sobresimplificación, pero lo importante es recordar no perder el foco en el factor humano; tratemos de entender mejor el negocio y sus requerimientos pues con base en ello podremos crear una visión más acertada de lo que esperamos. Si a lo anterior adicionamos una cultura basada en la confianza, diligencia, ownership,  mentalidad de ingeniero, con foco en riesgos, el factor humano puede sumar a nuestra estrategia de ciberseguridad en lugar de hacerla más compleja.

 [email protected]