Los requisitos comerciales en conflicto son un problema común, y lo encuentra en todos los rincones de una organización, incluso en la tecnología de la información. Resolver estos conflictos es imprescindible, pero no siempre es fácil, aunque a veces hay una solución novedosa que ayuda.
En la gestión de TI hay una lucha constante entre los equipos de seguridad y operaciones. Sí, en última instancia, ambos equipos quieren tener sistemas seguros que sean más difíciles de violar. Sin embargo, la seguridad puede venir a expensas de la disponibilidad, y viceversa. En este artículo, veremos el conflicto entre disponibilidad y seguridad, y una solución que ayude a resolver ese conflicto.
El equipo de operaciones se enfoca en la disponibilidad… los equipos de seguridad se bloquean
Los equipos de operaciones siempre tendrán la estabilidad y, por lo tanto, la disponibilidad como máxima prioridad. Sí, los equipos de operaciones también harán de la seguridad una prioridad, pero solo en la medida en que toque la estabilidad o la disponibilidad, nunca como un objetivo absoluto.
Se desarrolla en el objetivo de tiempo de actividad de «cinco nueves» que establece un requisito increíblemente alto: que un sistema esté funcionando y disponible para atender las solicitudes el 99,999 % del tiempo. Es un objetivo encomiable que mantiene felices a las partes interesadas. Las herramientas como la alta disponibilidad ayudan aquí al proporcionar redundancias de nivel de servicio o sistema, pero los objetivos de seguridad pueden obstaculizar rápidamente el logro de «cinco nueves».
Para los equipos de seguridad, el objetivo final es tener los sistemas lo más bloqueados posible, reduciendo la superficie de ataque y los niveles generales de riesgo al mínimo absoluto. En la práctica, los equipos de seguridad pueden exigir que un sistema deje de funcionar para la aplicación de parches ahora mismo y no dentro de dos semanas, lo que reduce la disponibilidad para aplicar los parches de inmediato, sin importar cuáles sean las consecuencias para los usuarios.
Es fácil ver que este enfoque crearía un gran dolor de cabeza para los equipos de operaciones. Peor aún, donde la alta disponibilidad realmente ayudó a los equipos de operaciones a lograr sus objetivos de disponibilidad y estabilidad, de hecho puede empeorar las cosas para los equipos de seguridad que ahora deben cuidar una cantidad exponencialmente mayor de servidores o servicios, todos los cuales requieren protección y monitoreo.
¿Qué mejor práctica seguir?
Crea un conflicto entre las operaciones y la seguridad, lo que significa que los dos grupos se enfrentan rápidamente en temas como mejores prácticas y procesos. Al pensar en aplicar parches, una política de parches basada en ventanas de mantenimiento causará menos interrupciones y aumentará la disponibilidad porque hay un retraso de varias semanas entre los esfuerzos de parches y el tiempo de inactividad asociado.
Pero hay una trampa: las ventanas de mantenimiento no se parchean lo suficientemente rápido para defenderse adecuadamente contra las amenazas emergentes porque estas amenazas a menudo se explotan activamente a los pocos minutos de la divulgación (o incluso antes de la divulgación, por ejemplo, Log4j).
El problema ocurre en todos los tipos de cargas de trabajo y realmente no importa si está utilizando el último enfoque de DevOps, DevSecOps o cualquier otra operación como el sabor del día. En última instancia, parchea más rápido para operaciones seguras a expensas de la disponibilidad o el rendimiento, o parchea más lentamente y asume riesgos inaceptables con la seguridad.
Rápidamente se vuelve muy complicado
Decidir qué tan rápido parchear es solo el comienzo. A veces, parchear no es simple. Podría, por ejemplo, estar lidiando con vulnerabilidades en el nivel del lenguaje de programación, lo que a su vez afecta a las aplicaciones que están escritas en ese lenguaje, por ejemplo, CVE-2022-31626una vulnerabilidad de PHP.
Cuando esto sucede, hay otro grupo que participa en el conflicto entre disponibilidad y seguridad: los desarrolladores que necesitan lidiar con una vulnerabilidad a nivel de idioma en dos pasos. Primero, actualizando la versión del idioma en cuestión, que es la parte fácil.
Pero actualizar una versión de idioma trae no solo mejoras de seguridad; también trae otros cambios fundamentales. Es por eso que los desarrolladores deben pasar por un segundo paso: compensar los cambios en el nivel del idioma que trae la reescritura del código de la aplicación.
Eso también significa volver a probar e incluso volver a certificar en algunos casos. Al igual que los equipos de operaciones que quieren evitar el tiempo de inactividad relacionado con el reinicio, los desarrolladores realmente quieren evitar las ediciones de código extensas durante el mayor tiempo posible porque implica un trabajo importante que, sí, garantiza una seguridad más estricta, pero por lo demás deja a los desarrolladores sin nada que mostrar por su tiempo. .
Puede ver fácilmente por qué los procesos actuales de gestión de parches provocan un conflicto de varios niveles entre los equipos. Una política de arriba hacia abajo puede resolver el problema hasta cierto punto, pero generalmente significa que nadie está realmente contento con el resultado.
Peor aún, estas políticas a menudo pueden comprometer la seguridad al dejar los sistemas sin parches durante demasiado tiempo. La aplicación de parches a los sistemas en intervalos semanales o mensuales pensando que el riesgo es aceptable, en el nivel de amenaza actual, conducirá tarde o temprano a una seria verificación de la realidad.
Hay una ruta para mitigar significativamente, o incluso resolver el conflicto entre la aplicación de parches inmediata (y la interrupción) y la aplicación de parches retrasada (y los agujeros de seguridad). La respuesta se encuentra en la aplicación de parches sin interrupciones y sin fricciones, en todos los niveles o al menos en tantos niveles como sea práctico.
La aplicación de parches sin fricción puede resolver el conflicto
El parcheo en vivo es la herramienta de parcheo sin fricciones que su equipo de seguridad debería estar buscando. Gracias a la aplicación de parches en vivo, puede aplicar parches mucho más rápido de lo que las ventanas de mantenimiento regulares podrían lograr, y nunca necesitará reiniciar los servicios para aplicar las actualizaciones. Aplicación de parches rápida y segura, junto con poco o ningún tiempo de inactividad. Una forma sencilla y eficaz de resolver el conflicto entre disponibilidad y seguridad.
A TuxCare proporcionamos parches completos en vivo para componentes críticos del sistema Linux y parches para múltiples lenguajes de programación y versiones de lenguajes de programación que se enfocan en problemas de seguridad y no introducen cambios en el nivel del idioma que de otro modo forzarían la refactorización del código: su código continuará ejecutándose tal como está. solo de forma segura. Incluso si su negocio depende de aplicaciones no compatibles, no tendrá que preocuparse por las vulnerabilidades que se filtran en sus sistemas a través de una falla en el lenguaje de programación, y tampoco necesita actualizar el código de la aplicación.
Entonces, para concluir, en el conflicto entre disponibilidad y seguridad, parcheo en vivo es la única herramienta que puede reducir significativamente la tensión entre las operaciones y los equipos de seguridad.