Si bien la mitigaci\u00f3n de amenazas es hasta cierto punto una tarea especializada que involucra a expertos en seguridad cibern\u00e9tica, el d\u00eda a d\u00eda de la mitigaci\u00f3n de amenazas a menudo a\u00fan depende de los administradores de sistemas. Sin embargo, para estos administradores de sistemas no es una tarea f\u00e1cil. En TI empresarial, los equipos de administradores de sistemas tienen un amplio mandato pero recursos limitados.<\/p>\n
Para los administradores de sistemas, encontrar el tiempo y los recursos para mitigar una amenaza creciente y en constante movimiento es un desaf\u00edo. En este art\u00edculo, describimos las dificultades que implica la mitigaci\u00f3n de amenazas empresariales y explicamos por qu\u00e9 las herramientas de mitigaci\u00f3n automatizadas y especialmente dise\u00f1adas son el camino a seguir.<\/p>\n
La gesti\u00f3n de amenazas es una tarea abrumadora<\/h2>\n
Hay una variedad de especialistas que trabajan en la gesti\u00f3n de amenazas, pero la implementaci\u00f3n pr\u00e1ctica de las estrategias de gesti\u00f3n de amenazas a menudo se reduce a los administradores de sistemas. Ya sea que se trate de administraci\u00f3n de parches, detecci\u00f3n de intrusiones o reparaci\u00f3n despu\u00e9s de un ataque, los administradores de sistemas suelen llevar la peor parte del trabajo.<\/p>\n
Es una tarea imposible, dada la naturaleza creciente de la amenaza. Solo en 2021, 28,000 vulnerabilidades fueron reveladas<\/a>. Es un n\u00famero tan grande que, de hecho, una gran proporci\u00f3n nunca lleg\u00f3 a recibir un CVE. Esto es especialmente relevante en una industria centrada en el l\u00e1ser en el seguimiento de CVE, probando su presencia en nuestros sistemas e implementando parches que mencionan n\u00fameros de CVE espec\u00edficos. No puedes protegerte contra aquello a lo que no sabes que eres vulnerable<\/em>. Si una vulnerabilidad dada no tiene un CVE adjunto y todas sus herramientas\/mentalidad\/procesos est\u00e1n enfocados en CVE, algo fallar\u00e1. Las razones para no asignar un CVE a una vulnerabilidad son muchos<\/a> y fuera del alcance de este art\u00edculo, pero ninguno de ellos reducir\u00e1 el trabajo que debe realizarse en seguridad.<\/p>\n Incluso si una organizaci\u00f3n tuviera un equipo de administradores de sistemas de tres cifras, ser\u00eda dif\u00edcil hacer un seguimiento de esta lista de vulnerabilidades en constante crecimiento. Ni siquiera estamos hablando de interacciones en las que una vulnerabilidad puede afectar a un sistema secundario que se ejecuta en su infraestructura de una manera que no es tan obvia.<\/p>\n Con el tiempo, simplemente se funde en un “ruido de fondo” de vulnerabilidades. Existe la suposici\u00f3n de que la aplicaci\u00f3n de parches ocurre met\u00f3dicamente, semanalmente o quiz\u00e1s diariamente, pero en realidad, la informaci\u00f3n relevante y detallada dentro de los anuncios de CVE nunca llega a la cima de la mente.<\/p>\n Con las tareas de seguridad, incluida la aplicaci\u00f3n de parches, convirti\u00e9ndose en un ejercicio tan abrumador, no es de extra\u00f1ar que los administradores de sistemas comiencen a tomar algunos atajos. Tal vez un administrador de sistemas se pierda esa interacci\u00f3n entre un nuevo exploit y un sistema secundario, o se olvide de probar correctamente los parches antes de implementar la \u00faltima soluci\u00f3n, cualquiera de los cuales puede fallar en la prevenci\u00f3n de un colapso en toda la red. <\/p>\n Manejadas sin cuidado, las tareas de administraci\u00f3n de seguridad, como la aplicaci\u00f3n de parches, pueden tener consecuencias. Un peque\u00f1o cambio regresar\u00e1 y perseguir\u00e1 a los equipos de seguridad unos d\u00edas, semanas o meses m\u00e1s adelante al romper algo m\u00e1s que no esperaban. <\/p>\n “Cerrar agujeros” es un gran problema dentro de este contexto. Por ejemplo, tome la vulnerabilidad de Log4j, donde cambiar la configuraci\u00f3n predeterminada de Log4j podr\u00eda proporcionar f\u00e1cilmente una mitigaci\u00f3n significativa. Es un paso obvio y sensato, pero la verdadera pregunta es: \u00bftiene el equipo de administradores de sistemas los recursos para completar la tarea? No es que sea dificil de realizar per se<\/em> \u2013 pero es dif\u00edcil rastrear cada uso de log4j en toda la flota del sistema, adem\u00e1s el trabajo necesario es adem\u00e1s<\/em> a todas las dem\u00e1s actividades regulares.<\/p>\n Y nuevamente, apuntando a la aplicaci\u00f3n de parches, los recursos necesarios para hacerlo de manera consistente a menudo no est\u00e1n disponibles. La aplicaci\u00f3n de parches es particularmente dif\u00edcil dado el hecho de que aplicar un parche implica reiniciar el servicio subyacente. Los reinicios consumen mucho tiempo y son disruptivos y, cuando se trata de componentes cr\u00edticos, reiniciar simplemente puede no ser realista. <\/p>\n El resultado neto es que las tareas de seguridad esenciales simplemente no se realizan, lo que deja a los administradores de sistemas con la persistente sensaci\u00f3n de que la seguridad no es lo que deber\u00eda ser. Tambi\u00e9n se aplica al monitoreo de seguridad, incluidas las pruebas de penetraci\u00f3n y el escaneo de vulnerabilidades. S\u00ed, algunas organizaciones pueden tener especialistas para realizar esta tarea, llegando incluso a tener equipos rojos y equipos azules.<\/p>\n Pero, en muchos casos, el monitoreo de la seguridad es otra tarea m\u00e1s para los administradores de sistemas que inevitablemente se sobrecargar\u00e1n y terminar\u00e1n tomando.<\/p>\n Uno podr\u00eda pensar que todo lo que debe suceder es que los administradores de sistemas se adelanten a la carga: reduzcan los m\u00fasculos y simplemente lo hagan. Al trabajar con el trabajo pendiente, tal vez obteniendo ayuda adicional, los administradores de sistemas podr\u00edan administrar la carga de trabajo y hacerlo todo.<\/p>\n Pero hay un peque\u00f1o problema aqu\u00ed. La cantidad de vulnerabilidades est\u00e1 creciendo r\u00e1pidamente: una vez que el equipo se haya ocupado de los problemas conocidos, sin duda enfrentar\u00e1 a\u00fan m\u00e1s. Y el ritmo de las vulnerabilidades se est\u00e1 acelerando, cada a\u00f1o se reportan m\u00e1s y m\u00e1s.<\/p>\n Tratar de mantenerse al d\u00eda significar\u00eda que los equipos aumentan en tama\u00f1o, digamos, un 30% a\u00f1o tras a\u00f1o. Simplemente no es una batalla que un equipo humano con enfoques manuales ganar\u00e1. Claramente, se necesitan alternativas porque una batalla continua de esta naturaleza simplemente no se ganar\u00e1 aumentando el tama\u00f1o de los equipos a\u00f1o tras a\u00f1o de manera casi exponencial.<\/p>\n Lo bueno de la inform\u00e1tica, por supuesto, es que la automatizaci\u00f3n a menudo proporciona una salida a las restricciones de recursos persistentes, y ese es el caso tambi\u00e9n con la gesti\u00f3n de amenazas. De hecho, si desea tener alguna posibilidad de progresar contra el creciente entorno de amenazas, es clave implementar la automatizaci\u00f3n de tareas en la gesti\u00f3n de vulnerabilidades. Desde la supervisi\u00f3n de nuevas vulnerabilidades hasta la aplicaci\u00f3n de parches y la generaci\u00f3n de informes. <\/p>\n Algunas herramientas ayudar\u00e1n con aspectos espec\u00edficos, otras ayudar\u00e1n con todos esos aspectos, pero la eficacia de las herramientas tiende a disminuir a medida que la herramienta se vuelve m\u00e1s integral. Las herramientas m\u00e1s especializadas tienden a ser mejores en su funci\u00f3n espec\u00edfica que las herramientas que pretenden hacer todo de una sola vez. Piense en ello como la filosof\u00eda de las herramientas de Unix: haga una cosa y h\u00e1gala bien, en lugar de tratar de hacer todo a la vez. <\/p>\n Por ejemplo, remendar<\/a> puede y debe ser automatizado. Pero la aplicaci\u00f3n de parches es una de esas tareas de seguridad que necesitan una herramienta dedicada que pueda ayudar a los administradores de sistemas a aplicar parches de manera constante y con una interrupci\u00f3n m\u00ednima. <\/p>\n Un enfoque a medias no funcionar\u00e1 porque la aplicaci\u00f3n de parches a\u00fan se ver\u00eda obstaculizada por la aceptaci\u00f3n de las ventanas de mantenimiento. Eso quitar\u00eda a los equipos de TI la flexibilidad para responder casi en tiempo real a las nuevas amenazas, sin afectar las operaciones comerciales de la organizaci\u00f3n. Un ajuste perfecto para estos requisitos es la aplicaci\u00f3n de parches en vivo a trav\u00e9s de herramientas como Herramienta KernelCare Enterprise de TuxCare<\/a> que ofrece parches autom\u00e1ticos, no disruptivos y en vivo para distribuciones de Linux. <\/p>\n Por supuesto, no es solo la aplicaci\u00f3n de parches lo que debe automatizarse. As\u00ed como los ciberdelincuentes usan la automatizaci\u00f3n para detectar vulnerabilidades, los equipos de tecnolog\u00eda deber\u00edan confiar en el escaneo continuo y automatizado de vulnerabilidades y las pruebas de penetraci\u00f3n. Dentro de esta esfera de automatizaci\u00f3n tambi\u00e9n deber\u00edan incluirse los cortafuegos, la protecci\u00f3n avanzada contra amenazas, la protecci\u00f3n de terminales, etc.<\/p>\n Claramente, el problema de las amenazas est\u00e1 empeorando, y r\u00e1pidamente, mucho m\u00e1s r\u00e1pido de lo que las organizaciones podr\u00edan esperar hacer crecer sus equipos de seguridad si realmente quisieran abordar estos problemas manualmente. Sentarse en un rinc\u00f3n particular en t\u00e9rminos de las soluciones en uso tampoco brinda ning\u00fan consuelo, en parte porque las soluciones ahora est\u00e1n tan integradas con el c\u00f3digo compartido en tantas plataformas que una sola vulnerabilidad puede tener un impacto casi universal.<\/p>\n Adem\u00e1s, como encontr\u00f3 una investigaci\u00f3n reciente, la lista de los diez productos m\u00e1s vulnerables excluy\u00f3 algunos productos notables. Por ejemplo, Microsoft Windows, visto anteriormente como uno de los sistemas operativos m\u00e1s vulnerables, ni siquiera est\u00e1 entre los diez primeros, que en cambio est\u00e1 dominado por los sistemas operativos basados \u200b\u200ben Linux. Confiar en lo que se cree que son alternativas m\u00e1s seguras no es una buena idea.<\/p>\n Subraya c\u00f3mo la \u00fanica seguridad real se encuentra en la automatizaci\u00f3n de la seguridad. Desde el escaneo de vulnerabilidades hasta la aplicaci\u00f3n de parches, la automatizaci\u00f3n es realmente la \u00fanica ruta que puede ayudar a los administradores de sistemas abrumados a obtener cierto grado de control sobre una situaci\u00f3n explosiva; de hecho, es la \u00fanica v\u00eda. manejable<\/em> soluci\u00f3n.<\/p>\n <\/p>\n<\/div>\nLos equipos abrumados toman riesgos<\/h2>\n
Y est\u00e1 empeorando<\/h2>\n
La automatizaci\u00f3n de la gesti\u00f3n de amenazas es clave<\/h2>\n
No hay ning\u00fan lugar seguro para esconderse<\/h2>\n