[16/12/2021] La seguridad y la confiabilidad del software se han comparado y contrastado durante varios años, con el punto principal siendo que ambos tienen el objetivo de proteger a los clientes y consumidores. Sin embargo, con la continua adopción y maduración de los movimientos de ingeniería de confiabilidad del sitio (SER, por sus siglas en inglés) y DevSecOps, existe una superposición creciente entre los dos. Cuando se lleva a cabo de manera adecuada, esto maximiza el valor para las partes interesadas.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Cualquiera que haya trabajado en ciberseguridad durante algún tiempo está familiarizado con la tríada de la CIA, que significa confidencialidad, integridad y disponibilidad. Las métricas relacionadas con la disponibilidad son una parte fundamental del movimiento DevOps (y, posteriormente, DevSecOps). Estos vienen en forma de investigación y evaluaciones de DevOps (DORA). Estas métricas incluyen el tiempo intermedio para recuperarse (MTTR, por sus siglas en inglés) y cambiar la tasa de fallas (CFR, por sus siglas en inglés). Si los cambios propuestos fallan e impiden la disponibilidad, y la recuperación lleva un tiempo inaceptable, ahora ha comprometido tanto la seguridad como la confiabilidad.
Estamos viendo un impulso para que las organizaciones adopten prácticas seguras de DevOps, con estudios como el State of DevOps Report que muestra que el alto rendimiento no sacrifica la velocidad por la estabilidad (disponibilidad). Un número creciente de organizaciones está adoptando los principios de SER con el objetivo de aprender de los cortes de energía y convertir los sistemas frágiles en sistemas confiables y antifragilidad.
La reducción en el tiempo de elaboración de los cambios aumenta la seguridad
A pesar de la relación obvia entre MTTR y CFR, otra métrica de DORA también tiene un fuerte impacto potencial desde la perspectiva de la seguridad. Este sería el tiempo de elaboración de los cambios. Esta métrica a menudo se asocia con el tiempo que lleva pasar del código comprometido al código que se ejecuta correctamente en producción. Generalmente se discute en el contexto de poder ofrecer valor rápidamente a los clientes o usuarios finales.
La capacidad de implementar rápidamente actualizaciones relevantes para la seguridad en sus sistemas también es un ejemplo de entrega de valor. Si puede identificar componentes inseguros o vulnerabilidades en sus sistemas de producción, ¿con qué rapidez puede abordar esas deficiencias sin comprometer la disponibilidad de su sistema? Si necesita comprometer la disponibilidad del sistema con el fin de entregar actualizaciones relevantes para la seguridad -al interrumpir la disponibilidad y aumentar la ventana de que exista una vulnerabilidad para ser explotada por un actor malintencionado- ahora ha impedido tanto la estabilidad como la seguridad.
La confiabilidad del software como métrica de seguridad
El 2021 State of DevOps Report también agregó la confiabilidad como métrica en respuesta a un cambio en la disponibilidad. La lógica detrás del cambio fue expandirse más allá de la disponibilidad y considerar la latencia, el rendimiento y la adaptación de escala. Esto parece lógico, dado que un sistema que está disponible o se puede alcanzar, pero con una degradación del rendimiento o una incapacidad para escalar tan grave que no cumple con los requerimientos del negocio, no está disponible en relación con su verdadera necesidad. Dicho esto, muchos en la comunidad de seguridad pueden argumentar que la disponibilidad incluye estos factores adicionales. NIST, por ejemplo, define la disponibilidad como datos o información accesibles y utilizables según sea necesario.
El informe también señala que los equipos que superan sus objetivos de confiabilidad tenían el doble de probabilidades de tener la seguridad integrada en el ciclo de vida de desarrollo de sus sistemas (SDLC, por sus siglas en inglés). La confiabilidad a menudo se considera una métrica crítica, ya que es importante para el cliente y clave para evitar la pérdida de participación de mercado e ingresos. La integración de la seguridad en el SDLC garantiza que los problemas se identifiquen y resuelvan antes, cuando son más baratos y más fáciles de solucionar, sin causar interrupciones significativas en la confiabilidad en el contexto del informe.
Dado que los que tienen un desempeño de alta confiabilidad tienen los tiempos de entrega más bajos, CFR y MTTR, esto significa que también son los más capaces de aplicar correcciones de seguridad críticas rápidamente sin comprometer la confiabilidad del sistema. Esto reduce la ventana de explotación para los adversarios y el riesgo de seguridad general para los sistemas y el software. El 2021 State of DevOps Report encontró que la élite, en términos de rendimiento, tenía un tiempo 6.570 veces más rápido para recuperarse de los incidentes. Cuando la confiabilidad es la métrica más crítica para los clientes y está estrechamente ligada a retener la participación de mercado y generar ingresos, esto es muy poderoso. También es un ojo morado desde la perspectiva de la disponibilidad para las organizaciones con un rendimiento deficiente en las frecuencias de implementación de código, los tiempos de entrega y las tasas de fallas de cambios. Esto parece algo intuitivo, dado que cuanto más se practica algo, mejor se hace.
Por lo tanto, las organizaciones que se obsesionan con la estabilidad al ser reacias al cambio son en realidad las más vulnerables cuando se trata de la incapacidad de recuperarse de los incidentes, incluidos los relacionados con la seguridad. Esto es importante, dado que los incidentes son inevitables.
El valor de combinar las prácticas de SRE y DevSecOps
También existe una relación superpuesta entre SRE y DevSecOps. SRE es esencialmente un enfoque que busca utilizar software para administrar sistemas, abordar desafíos y automatizar tareas. Hace todo esto en la búsqueda de cumplir las promesas a sus usuarios y, a menudo, está vinculado a métricas como indicadores de nivel de servicio/objetivos de nivel de servicio (SLIs/SLOs, por sus siglas en inglés).
Las organizaciones que combinaron las prácticas de la SRE con metodologías DevOpsOps también tienen más probabilidades de alcanzar sus objetivos comunes y resultados clave (OKRs, por sus siglas en inglés) y lograr resultados deseados de negocio. Las organizaciones que se centran en la mejora de la estabilidad o la fiabilidad de su software también son mucho menos propensas a emplear tiempo para resolver problemas de seguridad. El argumento a favor de la integración de las dos prácticas de la SRE y DevSecOps es apoyado por líderes de la industria tales como Adrian Cockcroft, que proponen dichas prácticas que en apoyo a la idea de una resiliencia continua.
Los estudios y encuestas continúan mostrando que las organizaciones que se enfocan tanto en mejorar la confiabilidad de su software, como en implementar prácticas de desarrollo, obtienen como beneficio la mejora en la confiabilidad y la seguridad. Esto tiene sentido, dado el enfoque que busca cambiar la seguridad que queda en el SDLC, disminuir la deuda de tecnología de seguridad y adoptar la automatización, al mismo tiempo que se busca maximizar la confiabilidad y la satisfacción del cliente.
Muchos han argumentado que la fiabilidad es un requisito previo para la seguridad del software. Un sistema poco fiable no es seguro, pero un sistema ciertamente puede estar disponible en un estado inseguro. Otras áreas comparables de superposición incluyen la realidad de que ningún sistema puede ser completamente invulnerable a cualquier posible amenaza o riesgo. Seguridad es la gestión de riesgo esencialmente dentro de un determinado nivel de tolerancia al riesgo, con la frecuencia definida por las partes interesadas primarias. Del mismo modo, ningún software o sistema pueden ser considerados totalmente inmunes a todas las posibles preocupaciones de fiabilidad y disponibilidad. Dicho esto, el software y los sistemas pueden ser confiables como se define en los SLOs y SLIs, como se indicó anteriormente.
Al acoplar el mayor rendimiento de élite de la SRE y DevOps, eficaces en cuanto a CFR, MTTR y fiabilidad, junto con los últimos avances en el robo de datos del 2021 Cost of a Data Breach Report, de IBM, las implicaciones son claras. El costo total promedio global de una irrupción de datos es ahora de 4,24 millones de dólares. Además, hasta septiembre del 2021, el número total de robos de datos supera todo el 2020. La frecuencia de los robos de datos se está acelerando. Es más crítico que nunca contar con organizaciones que enfrenten esta creciente tasa de ataque y riesgo, capaces de implementar rápidamente actualizaciones de seguridad, recuperarse de incidentes y garantizar la confiabilidad para los clientes.
Basado en el artículo de Chris Hughes (CSO) y editado por CIO Perú
Puede ver también: