Los requisitos comerciales en conflicto son un problema com\u00fan, y lo encuentra en todos los rincones de una organizaci\u00f3n, incluso en la tecnolog\u00eda de la informaci\u00f3n. Resolver estos conflictos es imprescindible, pero no siempre es f\u00e1cil, aunque a veces hay una soluci\u00f3n novedosa que ayuda.<\/p>\n
En la gesti\u00f3n de TI hay una lucha constante entre los equipos de seguridad y operaciones. S\u00ed, en \u00faltima instancia, ambos equipos quieren tener sistemas seguros que sean m\u00e1s dif\u00edciles de violar. Sin embargo, la seguridad puede venir a expensas de la disponibilidad, y viceversa. En este art\u00edculo, veremos el conflicto entre disponibilidad y seguridad, y una soluci\u00f3n que ayude a resolver ese conflicto.<\/p>\n
El equipo de operaciones se enfoca en la disponibilidad\u2026 los equipos de seguridad se bloquean<\/strong><\/h2>\nLos equipos de operaciones siempre tendr\u00e1n la estabilidad y, por lo tanto, la disponibilidad como m\u00e1xima prioridad. S\u00ed, los equipos de operaciones tambi\u00e9n har\u00e1n de la seguridad una prioridad, pero solo en la medida en que toque la estabilidad o la disponibilidad, nunca como un objetivo absoluto.<\/p>\n
Se desarrolla en el objetivo de tiempo de actividad de “cinco nueves” que establece un requisito incre\u00edblemente alto: que un sistema est\u00e9 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\u00ed al proporcionar redundancias de nivel de servicio o sistema, pero los objetivos de seguridad pueden obstaculizar r\u00e1pidamente el logro de “cinco nueves”.<\/p>\n
Para los equipos de seguridad, el objetivo final es tener los sistemas lo m\u00e1s bloqueados posible, reduciendo la superficie de ataque y los niveles generales de riesgo al m\u00ednimo absoluto. En la pr\u00e1ctica, los equipos de seguridad pueden exigir que un sistema deje de funcionar para la aplicaci\u00f3n de parches ahora mismo y no dentro de dos semanas, lo que reduce la disponibilidad para aplicar los parches de inmediato, sin importar cu\u00e1les sean las consecuencias para los usuarios.<\/p>\n
Es f\u00e1cil ver que este enfoque crear\u00eda un gran dolor de cabeza para los equipos de operaciones. Peor a\u00fan, donde la alta disponibilidad realmente ayud\u00f3 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\u00f3n y monitoreo.<\/p>\n
\u00bfQu\u00e9 mejor pr\u00e1ctica seguir?<\/strong><\/h2>\nCrea un conflicto entre las operaciones y la seguridad, lo que significa que los dos grupos se enfrentan r\u00e1pidamente en temas como mejores pr\u00e1cticas y procesos. Al pensar en aplicar parches, una pol\u00edtica de parches basada en ventanas de mantenimiento causar\u00e1 menos interrupciones y aumentar\u00e1 la disponibilidad porque hay un retraso de varias semanas entre los esfuerzos de parches y el tiempo de inactividad asociado.<\/p>\n
Pero hay una trampa: las ventanas de mantenimiento no se parchean lo suficientemente r\u00e1pido para defenderse adecuadamente contra las amenazas emergentes porque estas amenazas a menudo se explotan activamente a los pocos minutos de la divulgaci\u00f3n (o incluso antes de la divulgaci\u00f3n, por ejemplo, Log4j).<\/p>\n
El problema ocurre en todos los tipos de cargas de trabajo y realmente no importa si est\u00e1 utilizando el \u00faltimo enfoque de DevOps, DevSecOps o cualquier otra operaci\u00f3n como el sabor del d\u00eda. En \u00faltima instancia, parchea m\u00e1s r\u00e1pido para operaciones seguras a expensas de la disponibilidad o el rendimiento, o parchea m\u00e1s lentamente y asume riesgos inaceptables con la seguridad.<\/p>\n
R\u00e1pidamente se vuelve muy complicado<\/strong><\/h2>\nDecidir qu\u00e9 tan r\u00e1pido parchear es solo el comienzo. A veces, parchear no es simple. Podr\u00eda, por ejemplo, estar lidiando con vulnerabilidades en el nivel del lenguaje de programaci\u00f3n, lo que a su vez afecta a las aplicaciones que est\u00e1n escritas en ese lenguaje, por ejemplo, CVE-2022-31626<\/a>una vulnerabilidad de PHP.<\/p>\nCuando 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\u00f3n del idioma en cuesti\u00f3n, que es la parte f\u00e1cil.<\/p>\n
Pero actualizar una versi\u00f3n de idioma trae no solo mejoras de seguridad; tambi\u00e9n 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\u00f3digo de la aplicaci\u00f3n.<\/p>\n
Eso tambi\u00e9n 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\u00f3digo extensas durante el mayor tiempo posible porque implica un trabajo importante que, s\u00ed, garantiza una seguridad m\u00e1s estricta, pero por lo dem\u00e1s deja a los desarrolladores sin nada que mostrar por su tiempo. .<\/p>\n
Puede ver f\u00e1cilmente por qu\u00e9 los procesos actuales de gesti\u00f3n de parches provocan un conflicto de varios niveles entre los equipos. Una pol\u00edtica de arriba hacia abajo puede resolver el problema hasta cierto punto, pero generalmente significa que nadie est\u00e1 realmente contento con el resultado.<\/p>\n
Peor a\u00fan, estas pol\u00edticas a menudo pueden comprometer la seguridad al dejar los sistemas sin parches durante demasiado tiempo. La aplicaci\u00f3n de parches a los sistemas en intervalos semanales o mensuales pensando que el riesgo es aceptable, en el nivel de amenaza actual, conducir\u00e1 tarde o temprano a una seria verificaci\u00f3n de la realidad.<\/p>\n
Hay una ruta para mitigar significativamente, o incluso resolver el conflicto entre la aplicaci\u00f3n de parches inmediata (y la interrupci\u00f3n) y la aplicaci\u00f3n de parches retrasada (y los agujeros de seguridad). La respuesta se encuentra en la aplicaci\u00f3n de parches sin interrupciones y sin fricciones, en todos los niveles o al menos en tantos niveles como sea pr\u00e1ctico.<\/p>\n
La aplicaci\u00f3n de parches sin fricci\u00f3n puede resolver el conflicto<\/strong><\/h2>\nEl parcheo en vivo es la herramienta de parcheo sin fricciones que su equipo de seguridad deber\u00eda estar buscando. Gracias a la aplicaci\u00f3n de parches en vivo, puede aplicar parches mucho m\u00e1s r\u00e1pido de lo que las ventanas de mantenimiento regulares podr\u00edan lograr, y nunca necesitar\u00e1 reiniciar los servicios para aplicar las actualizaciones. Aplicaci\u00f3n de parches r\u00e1pida y segura, junto con poco o ning\u00fan tiempo de inactividad. Una forma sencilla y eficaz de resolver el conflicto entre disponibilidad y seguridad.<\/p>\n
A TuxCare<\/a> proporcionamos parches completos en vivo para componentes cr\u00edticos del sistema Linux y parches para m\u00faltiples lenguajes de programaci\u00f3n y versiones de lenguajes de programaci\u00f3n que se enfocan en problemas de seguridad y no introducen cambios en el nivel del idioma que de otro modo forzar\u00edan la refactorizaci\u00f3n del c\u00f3digo: su c\u00f3digo continuar\u00e1 ejecut\u00e1ndose tal como est\u00e1. solo de forma segura. Incluso si su negocio depende de aplicaciones no compatibles, no tendr\u00e1 que preocuparse por las vulnerabilidades que se filtran en sus sistemas a trav\u00e9s de una falla en el lenguaje de programaci\u00f3n, y tampoco necesita actualizar el c\u00f3digo de la aplicaci\u00f3n.<\/p>\nEntonces, para concluir, en el conflicto entre disponibilidad y seguridad, parcheo en vivo<\/a> es la \u00fanica herramienta que puede reducir significativamente la tensi\u00f3n entre las operaciones y los equipos de seguridad. <\/p>\n<\/p>\n<\/div>\n
Crea un conflicto entre las operaciones y la seguridad, lo que significa que los dos grupos se enfrentan r\u00e1pidamente en temas como mejores pr\u00e1cticas y procesos. Al pensar en aplicar parches, una pol\u00edtica de parches basada en ventanas de mantenimiento causar\u00e1 menos interrupciones y aumentar\u00e1 la disponibilidad porque hay un retraso de varias semanas entre los esfuerzos de parches y el tiempo de inactividad asociado.<\/p>\n
Pero hay una trampa: las ventanas de mantenimiento no se parchean lo suficientemente r\u00e1pido para defenderse adecuadamente contra las amenazas emergentes porque estas amenazas a menudo se explotan activamente a los pocos minutos de la divulgaci\u00f3n (o incluso antes de la divulgaci\u00f3n, por ejemplo, Log4j).<\/p>\n
El problema ocurre en todos los tipos de cargas de trabajo y realmente no importa si est\u00e1 utilizando el \u00faltimo enfoque de DevOps, DevSecOps o cualquier otra operaci\u00f3n como el sabor del d\u00eda. En \u00faltima instancia, parchea m\u00e1s r\u00e1pido para operaciones seguras a expensas de la disponibilidad o el rendimiento, o parchea m\u00e1s lentamente y asume riesgos inaceptables con la seguridad.<\/p>\n
R\u00e1pidamente se vuelve muy complicado<\/strong><\/h2>\nDecidir qu\u00e9 tan r\u00e1pido parchear es solo el comienzo. A veces, parchear no es simple. Podr\u00eda, por ejemplo, estar lidiando con vulnerabilidades en el nivel del lenguaje de programaci\u00f3n, lo que a su vez afecta a las aplicaciones que est\u00e1n escritas en ese lenguaje, por ejemplo, CVE-2022-31626<\/a>una vulnerabilidad de PHP.<\/p>\nCuando 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\u00f3n del idioma en cuesti\u00f3n, que es la parte f\u00e1cil.<\/p>\n
Pero actualizar una versi\u00f3n de idioma trae no solo mejoras de seguridad; tambi\u00e9n 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\u00f3digo de la aplicaci\u00f3n.<\/p>\n
Eso tambi\u00e9n 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\u00f3digo extensas durante el mayor tiempo posible porque implica un trabajo importante que, s\u00ed, garantiza una seguridad m\u00e1s estricta, pero por lo dem\u00e1s deja a los desarrolladores sin nada que mostrar por su tiempo. .<\/p>\n
Puede ver f\u00e1cilmente por qu\u00e9 los procesos actuales de gesti\u00f3n de parches provocan un conflicto de varios niveles entre los equipos. Una pol\u00edtica de arriba hacia abajo puede resolver el problema hasta cierto punto, pero generalmente significa que nadie est\u00e1 realmente contento con el resultado.<\/p>\n
Peor a\u00fan, estas pol\u00edticas a menudo pueden comprometer la seguridad al dejar los sistemas sin parches durante demasiado tiempo. La aplicaci\u00f3n de parches a los sistemas en intervalos semanales o mensuales pensando que el riesgo es aceptable, en el nivel de amenaza actual, conducir\u00e1 tarde o temprano a una seria verificaci\u00f3n de la realidad.<\/p>\n
Hay una ruta para mitigar significativamente, o incluso resolver el conflicto entre la aplicaci\u00f3n de parches inmediata (y la interrupci\u00f3n) y la aplicaci\u00f3n de parches retrasada (y los agujeros de seguridad). La respuesta se encuentra en la aplicaci\u00f3n de parches sin interrupciones y sin fricciones, en todos los niveles o al menos en tantos niveles como sea pr\u00e1ctico.<\/p>\n
La aplicaci\u00f3n de parches sin fricci\u00f3n puede resolver el conflicto<\/strong><\/h2>\nEl parcheo en vivo es la herramienta de parcheo sin fricciones que su equipo de seguridad deber\u00eda estar buscando. Gracias a la aplicaci\u00f3n de parches en vivo, puede aplicar parches mucho m\u00e1s r\u00e1pido de lo que las ventanas de mantenimiento regulares podr\u00edan lograr, y nunca necesitar\u00e1 reiniciar los servicios para aplicar las actualizaciones. Aplicaci\u00f3n de parches r\u00e1pida y segura, junto con poco o ning\u00fan tiempo de inactividad. Una forma sencilla y eficaz de resolver el conflicto entre disponibilidad y seguridad.<\/p>\n
A TuxCare<\/a> proporcionamos parches completos en vivo para componentes cr\u00edticos del sistema Linux y parches para m\u00faltiples lenguajes de programaci\u00f3n y versiones de lenguajes de programaci\u00f3n que se enfocan en problemas de seguridad y no introducen cambios en el nivel del idioma que de otro modo forzar\u00edan la refactorizaci\u00f3n del c\u00f3digo: su c\u00f3digo continuar\u00e1 ejecut\u00e1ndose tal como est\u00e1. solo de forma segura. Incluso si su negocio depende de aplicaciones no compatibles, no tendr\u00e1 que preocuparse por las vulnerabilidades que se filtran en sus sistemas a trav\u00e9s de una falla en el lenguaje de programaci\u00f3n, y tampoco necesita actualizar el c\u00f3digo de la aplicaci\u00f3n.<\/p>\nEntonces, para concluir, en el conflicto entre disponibilidad y seguridad, parcheo en vivo<\/a> es la \u00fanica herramienta que puede reducir significativamente la tensi\u00f3n entre las operaciones y los equipos de seguridad. <\/p>\n<\/p>\n<\/div>\n
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\u00f3n del idioma en cuesti\u00f3n, que es la parte f\u00e1cil.<\/p>\n
Pero actualizar una versi\u00f3n de idioma trae no solo mejoras de seguridad; tambi\u00e9n 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\u00f3digo de la aplicaci\u00f3n.<\/p>\n
Eso tambi\u00e9n 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\u00f3digo extensas durante el mayor tiempo posible porque implica un trabajo importante que, s\u00ed, garantiza una seguridad m\u00e1s estricta, pero por lo dem\u00e1s deja a los desarrolladores sin nada que mostrar por su tiempo. .<\/p>\n
Puede ver f\u00e1cilmente por qu\u00e9 los procesos actuales de gesti\u00f3n de parches provocan un conflicto de varios niveles entre los equipos. Una pol\u00edtica de arriba hacia abajo puede resolver el problema hasta cierto punto, pero generalmente significa que nadie est\u00e1 realmente contento con el resultado.<\/p>\n
Peor a\u00fan, estas pol\u00edticas a menudo pueden comprometer la seguridad al dejar los sistemas sin parches durante demasiado tiempo. La aplicaci\u00f3n de parches a los sistemas en intervalos semanales o mensuales pensando que el riesgo es aceptable, en el nivel de amenaza actual, conducir\u00e1 tarde o temprano a una seria verificaci\u00f3n de la realidad.<\/p>\n
Hay una ruta para mitigar significativamente, o incluso resolver el conflicto entre la aplicaci\u00f3n de parches inmediata (y la interrupci\u00f3n) y la aplicaci\u00f3n de parches retrasada (y los agujeros de seguridad). La respuesta se encuentra en la aplicaci\u00f3n de parches sin interrupciones y sin fricciones, en todos los niveles o al menos en tantos niveles como sea pr\u00e1ctico.<\/p>\n
La aplicaci\u00f3n de parches sin fricci\u00f3n puede resolver el conflicto<\/strong><\/h2>\nEl parcheo en vivo es la herramienta de parcheo sin fricciones que su equipo de seguridad deber\u00eda estar buscando. Gracias a la aplicaci\u00f3n de parches en vivo, puede aplicar parches mucho m\u00e1s r\u00e1pido de lo que las ventanas de mantenimiento regulares podr\u00edan lograr, y nunca necesitar\u00e1 reiniciar los servicios para aplicar las actualizaciones. Aplicaci\u00f3n de parches r\u00e1pida y segura, junto con poco o ning\u00fan tiempo de inactividad. Una forma sencilla y eficaz de resolver el conflicto entre disponibilidad y seguridad.<\/p>\n
A TuxCare<\/a> proporcionamos parches completos en vivo para componentes cr\u00edticos del sistema Linux y parches para m\u00faltiples lenguajes de programaci\u00f3n y versiones de lenguajes de programaci\u00f3n que se enfocan en problemas de seguridad y no introducen cambios en el nivel del idioma que de otro modo forzar\u00edan la refactorizaci\u00f3n del c\u00f3digo: su c\u00f3digo continuar\u00e1 ejecut\u00e1ndose tal como est\u00e1. solo de forma segura. Incluso si su negocio depende de aplicaciones no compatibles, no tendr\u00e1 que preocuparse por las vulnerabilidades que se filtran en sus sistemas a trav\u00e9s de una falla en el lenguaje de programaci\u00f3n, y tampoco necesita actualizar el c\u00f3digo de la aplicaci\u00f3n.<\/p>\nEntonces, para concluir, en el conflicto entre disponibilidad y seguridad, parcheo en vivo<\/a> es la \u00fanica herramienta que puede reducir significativamente la tensi\u00f3n entre las operaciones y los equipos de seguridad. <\/p>\n<\/p>\n<\/div>\n
Entonces, para concluir, en el conflicto entre disponibilidad y seguridad, parcheo en vivo<\/a> es la \u00fanica herramienta que puede reducir significativamente la tensi\u00f3n entre las operaciones y los equipos de seguridad. <\/p>\n <\/p>\n<\/div>\n