Logotipo de Zephyrnet

Cumplimiento mínimo viable: lo que debería preocuparle y por qué

Fecha:

En el ámbito de la seguridad de TI, tenemos que preocuparnos por todo. Cualquier problema, por pequeño que sea, puede convertirse en el vehículo para la ejecución remota de código o, al menos, en un punto de aterrizaje para que los actores de amenazas vivan de la tierra y utilicen nuestras propias herramientas en nuestra contra. No es sorprendente que el personal de seguridad de TI se enfrente al agotamiento y al estrés. De acuerdo a investigación realizada por Enterprise Strategy Group e ISSA, alrededor de la mitad de los profesionales de seguridad de TI creen que dejarán su trabajo actual en los próximos 12 meses.

Los equipos de seguridad son profesionalmente responsables y ahora, para los directores de seguridad de la información (CISO), personalmente responsable — por la seguridad de sus organizaciones. Sin embargo, en otras áreas de TI y tecnología, existe una mentalidad completamente diferente. Del mantra de Mark Zuckerberg de “Muévete rápido y rompe cosas”hasta Eric Ries' Inicio magra y el modelo de producto mínimo viable (MVP), la idea en estas áreas es avanzar rápidamente pero también entregar lo suficiente para que la organización pueda avanzar y mejorar.

Ahora, los equipos de seguridad de TI no pueden adoptar este modelo. Hay demasiadas regulaciones que considerar. Pero, ¿qué podemos aprender de un ejercicio mental sobre el cumplimiento mínimo viable (MVC) y cómo podemos utilizar esa información para ayudarnos en nuestro enfoque?

¿Qué implicaría MVC?

MVC implica cubrir lo que se necesita para estar efectivamente seguro. Para lograr esto, debe comprender qué tiene implementado y qué es fundamental mantener seguro, y qué reglas o regulaciones debe demostrar que cumple.

Para la gestión de activos, lo ideal es conocer todos los activos que ha instalado. Sin ese nivel de supervisión, ¿cómo puedes considerarte seguro? Para un enfoque MVC, ¿necesitaría un 100% de conocimiento de lo que tiene?

En realidad, los proyectos de gestión de activos, como las bases de datos de gestión de configuración (CMDB), tienen como objetivo proporcionar visibilidad completa de los activos de TI, pero nunca son 100% exactos. En el pasado, la precisión de los activos oscilaba entre el 70% y el 80%, e incluso las mejores implementaciones actuales no pueden lograr una visibilidad completa y mantenerla allí. Entonces, ¿deberíamos gastar nuestro presupuesto de MVC en esta área? Sí, pero no del modo en que podríamos pensar tradicionalmente.

Un CISO adjunto me dijo que comprende el ideal de una cobertura total, pero que no era posible; en cambio, se preocupa por la visibilidad total y continua de la infraestructura crítica de la organización (alrededor del 2.5 % de los activos totales), mientras que las otras cargas de trabajo se rastreaban con la mayor frecuencia posible. Entonces, si bien la visibilidad sigue siendo un elemento necesario para los programas de seguridad de TI, el esfuerzo debe dirigirse a proteger primero los activos de mayor riesgo. Sin embargo, este es un objetivo a corto plazo, ya que está a sólo una divulgación de vulnerabilidad de que un activo de bajo riesgo se convierta en uno de alto riesgo. Mientras realiza este proceso, no confunda el cumplimiento con la seguridad: no son lo mismo. Una empresa que cumple con las normas puede no ser segura.

Planificación de la regulación

Como parte de MVC, tenemos que pensar en las regulaciones y cómo cumplirlas. El desafío para los equipos de seguridad es cómo anticiparse a estas reglas. El enfoque típico es introducir la legislación, luego ver dónde se aplica a nuestras aplicaciones y luego realizar cambios en los sistemas según sea necesario. Sin embargo, este puede ser un enfoque muy intermitente que implica cambios (y, por lo tanto, gastos) cada vez que se introduce una nueva regulación o se produce un cambio significativo.

¿Cómo podemos facilitar este proceso a nuestros equipos? En lugar de analizar cada reglamento por separado, ¿podemos observar lo que es común a los reglamentos aplicables y luego utilizarlo para reducir la cantidad de trabajo requerido para cumplir con todos ellos? En lugar de someter al equipo a enormes ejercicios para que los sistemas cumplan con las normas, ¿qué podemos sacar del alcance o utilizar como servicio para proporcionar la infraestructura de forma segura? De manera similar, ¿podemos utilizar las mejores prácticas comunes, como controles en la nube, para eliminar conjuntos completos de problemas, en lugar de analizar cada problema individualmente?

En el centro de este enfoque, tenemos que reducir los gastos generales relacionados con la seguridad y concentrarnos en lo que representa los mayores riesgos para nuestros negocios. En lugar de pensar en tecnologías específicas, podemos examinar estos problemas como procesos y cuestiones de personas, porque las regulaciones siempre evolucionarán y cambiarán a medida que avanza el mercado. Adoptar esta mentalidad facilita la planificación de la seguridad, porque no se estanca en algunos de los detalles que pueden afectar a nuestros equipos cuando se han creado procesos para analizar CVE y datos de amenazas en lugar de en términos prácticos de riesgo en torno a lo que realmente es un problema.

La idea de hacer lo mínimo necesario para satisfacer las demandas del mercado o aprobar un conjunto de reglas puede resultar atractiva a primera vista. Pero la mentalidad de MVP no se trata sólo de llegar a un nivel específico y luego establecerse allí. Más bien, se trata de llegar a ese estándar mínimo y luego iterarlo lo más rápido posible para mejorar aún más la situación. Para los equipos de seguridad, esta mentalidad de mejora continua y búsqueda de formas de reducir el riesgo puede ser una alternativa útil al modelo tradicional de seguridad de TI. Al centrarse en qué mejoras tendrían el mayor impacto en el riesgo en el menor tiempo posible, puede aumentar su eficacia y reducir el riesgo en general.

punto_img

Información más reciente

punto_img