LinuxParty
Esta guía lo ayudará a comprender las preguntas que debe hacer y lo ayudará a encontrar las respuestas adecuadas para usted.
¿Con qué frecuencia se deben ejecutar los análisis de vulnerabilidades?
Muchos de los consejos a continuación dependen de lo que esté escaneando exactamente. Si aún no está seguro, consulte esta guía completa de análisis de vulnerabilidades .
Una vez que haya decidido qué sistemas deben estar dentro del alcance y qué tipo de escáner necesita, estará listo para comenzar a escanear. Entonces, ¿con qué frecuencia debería realizar, idealmente, análisis de vulnerabilidades?
Aquí hay cinco estrategias a considerar, y discutiremos en qué escenarios funcionan mejor:
- Basado en cambios
- A base de higiene
- Basado en cumplimiento
- Basado en recursos
- Basado en amenazas emergentes
Basado en cambios
Las empresas de tecnología de rápido movimiento a menudo implementan cambios de código o infraestructura varias veces al día, mientras que otras organizaciones pueden tener una configuración relativamente estática y es posible que no realicen cambios regulares en ninguno de sus sistemas.
La complejidad de la tecnología que utilizamos significa que cada cambio puede traer consigo un error de configuración catastrófico o la introducción accidental de un componente con vulnerabilidades conocidas. Por esta razón, ejecutar un análisis de vulnerabilidades después de que se hayan aplicado incluso cambios menores a sus sistemas es un enfoque sensato.
Debido a que se basa en cambios, este enfoque es más adecuado para activos que cambian rápidamente, como aplicaciones web o infraestructura en la nube como AWS, Azure y GCP, donde los nuevos activos se pueden implementar y destruir minuto a minuto. También vale la pena hacerlo en los casos en que estos sistemas están expuestos a la Internet pública.
Por esta razón, muchas empresas optan por integrar herramientas de prueba en sus canales de implementación automáticamente a través de una API con la herramienta de escaneo elegida.
También vale la pena considerar lo complejo que es el cambio que está realizando.
Si bien las herramientas automatizadas son excelentes para las pruebas regulares, cuanto más grande o más dramático sea el cambio que está realizando, más debe considerar la posibilidad de realizar una prueba de penetración para verificar que no se hayan introducido problemas.
Buenos ejemplos de esto podrían ser realizar grandes cambios estructurales en la arquitectura de las aplicaciones web, cualquier cambio radical de autenticación o autorización, o grandes características nuevas que introducen mucha complejidad. En el lado de la infraestructura, el equivalente podría ser una gran migración a la nube o pasar de un proveedor de nube a otro.
A base de higiene
Incluso si no realiza cambios regulares en sus sistemas, todavía existe una razón increíblemente importante para escanear sus sistemas de manera regular, y una que a menudo es pasada por alto por las organizaciones nuevas en el escaneo de vulnerabilidades.
Los investigadores de seguridad encuentran regularmente nuevas vulnerabilidades en el software de todo tipo y el código de explotación pública que hace que explotarlas sea muy fácil se puede divulgar públicamente en cualquier momento. Esta es la causa de algunos de los hacks más impactantes en la historia reciente, desde la violación de Equifax hasta el ransomware Wannacry, ambos fueron causados por nuevas fallas descubiertas en software común y los criminales rápidamente armando exploits para sus propios fines.
Ningún software está exento de esta regla general. Ya sea su servidor web, sistemas operativos, un marco de desarrollo particular que usa, su VPN de trabajo remoto o firewall. El resultado final es que incluso si ayer tuvo un escaneo que dijo que estaba seguro, eso no será necesariamente cierto mañana.
Todos los días se descubren nuevas vulnerabilidades, por lo que incluso si no se implementan cambios en sus sistemas, podrían volverse vulnerables de la noche a la mañana.
Sin embargo, ¿eso significa que simplemente debería ejecutar escaneos de vulnerabilidades sin parar? No necesariamente, ya que eso podría generar problemas por exceso de tráfico o enmascarar cualquier problema que ocurra.
Como criterio, el ciberataque WannaCry notorio nos muestra que los plazos en tales situaciones son ajustados, y las organizaciones que no reaccionan en un tiempo razonable para descubrir y remediar sus problemas de seguridad se ponen en riesgo. Microsoft lanzó un parche para la vulnerabilidad que WannaCry solía propagarse solo 59 días antes de que ocurrieran los ataques. Además, los atacantes pudieron producir un exploit y empezar a comprometer las máquinas solo 28 días después de que se filtró un exploit público.
Al observar las líneas de tiempo solo en este caso, está claro que si no se ejecutan análisis de vulnerabilidades y se solucionan los problemas en un período de 30 a 60 días, se corre un gran riesgo, y no olvide que incluso después de haber descubierto el problema, es posible que Tómate un tiempo para arreglarlo.
Nuestra recomendación para una buena higiene cibernética para la mayoría de las empresas es utilizar un escáner de vulnerabilidades en su infraestructura externa al menos una vez al mes, para que pueda mantenerse un paso por delante de estas desagradables sorpresas. Para las organizaciones con una mayor sensibilidad a la seguridad cibernética, los análisis semanales o incluso diarios pueden tener más sentido. Del mismo modo, los análisis de la infraestructura interna una vez al mes ayudan a mantener una buena higiene cibernética.
Para las aplicaciones web, escanear su marco y los componentes de la infraestructura de forma regular tiene el mismo sentido, pero si está buscando errores en su propio código con escaneos autenticados, un enfoque basado en cambios tiene mucho más sentido.
Basado en cumplimiento
Si está ejecutando análisis de vulnerabilidades por motivos de cumplimiento, las regulaciones específicas a menudo establecen explícitamente la frecuencia con la que se deben realizar los análisis de vulnerabilidades. Por ejemplo, PCI DSS requiere que se realicen escaneos externos trimestrales en los sistemas dentro de su alcance.
Sin embargo, debe pensar detenidamente sobre su estrategia de escaneo, ya que las reglas regulatorias están pensadas como una guía única para todos que puede no ser apropiada para su negocio.
La simple comparación de esta regulación de 90 días con las líneas de tiempo que se ven en el ejemplo de WannaCry anterior nos muestra que tales pautas no siempre cortan la mostaza. Si realmente desea mantenerse seguro en lugar de simplemente marcar una casilla, a menudo tiene sentido ir más allá de estas regulaciones, de la manera descrita anteriormente.
Basado en recursos
Los escáneres de vulnerabilidades pueden producir una gran cantidad de información y revelar muchas fallas, algunas de las cuales serán mayores riesgos que otras. Al considerar la cantidad de información que debe procesarse y la cantidad de trabajo que debe realizarse para rectificar estas fallas, puede ser tentador pensar que solo tiene sentido escanear con tanta frecuencia como pueda manejar toda la salida, como una vez. un cuarto.
Si bien esa sería una buena manera de hacer las cosas, desafortunadamente, se están descubriendo nuevas vulnerabilidades de manera mucho más regular que eso, por lo que en lugar de limitar sus escaneos a la frecuencia con la que puede lidiar con la salida, es mucho más sensato buscar crear un escáner que genere menos ruido en primer lugar y le ayude a concentrarse primero en los problemas más importantes; y le brinda orientación sobre qué tipo de escalas de tiempo deben abordarse los demás.
Intruder es un ejemplo de este tipo de escáner. Fue diseñado para priorizar automáticamente los problemas que tienen un impacto real en su seguridad, filtrando el ruido informativo de los resultados del análisis. Los resultados del escaneo de intrusos están diseñados para los sistemas conectados a Internet, lo que significa que pueden ayudarlo a monitorear y reducir la superficie de ataque.
También es el caso de que, como humanos, comenzamos a ignorar las cosas si se vuelven demasiado ruidosas. La fatiga de las alertas es una preocupación genuina en la seguridad cibernética, por lo que debe asegurarse de estar trabajando con una herramienta que no le envíe spam con información las 24 horas del día, los 7 días de la semana, ya que esto puede hacer que deje de prestar atención y sea más probable que se pierda los problemas importantes. cuando suceden. Asegúrese de tener esto en cuenta al elegir un escáner, ya que es un error común pensar que el que le brinda el mayor rendimiento es el mejor.
Basado en amenazas emergentes
Entonces, ahora que ha decidido el programa para ejecutar sus escaneos, vale la pena considerar lo que sucede en los huecos cuando no está ejecutando escaneos.
Por ejemplo, supongamos que decide que un escaneo mensual tiene sentido para que pueda detectar cualquier cambio que realice de forma semi-regular. Eso es genial, pero como muestran los plazos para la violación de Equifax, es posible que tenga un problema incluso en un espacio tan corto como 30 días, si se descubre una vulnerabilidad el día después de su último escaneo. Sin embargo, combinando nuestros pensamientos sobre la fatiga de alerta anterior, programar un escaneo diario puede no ser la mejor manera de evitar esto.
Para abordar este problema, algunos escáneres de vulnerabilidades brindan formas de cubrir estas brechas; algunos lo hacen almacenando la información recuperada en el último escaneo y alertándole si esa información es relevante para cualquier nueva vulnerabilidad a medida que se publica.
En el caso de Intruder, que también ofrece un concepto similar, llamado "Análisis de amenazas emergentes", su software analiza de forma proactiva a los clientes cada vez que surge una nueva vulnerabilidad. Esto permite garantizar que toda la información esté actualizada y que no se generen falsas alertas basadas en información antigua.
Tan pronto como se descubren nuevas vulnerabilidades, Intruder escanea proactivamente sus sistemas y le alerta automáticamente. |
Para resumir
Como ocurre con muchas cosas en el ámbito de la seguridad cibernética, no existe un enfoque que se adapte a todos para determinar su frecuencia de escaneo ideal. Según el tipo de activos que esté protegiendo o la industria en particular en la que esté operando, la respuesta será diferente. Esperamos que este artículo le haya ayudado a tomar una decisión informada sobre la frecuencia correcta de análisis de vulnerabilidades para su propia organización.
La plataforma de evaluación de vulnerabilidades de intrusos
Puede contratar "services.extrehost.com" de ExtreHost, (web todavía en desarrollo) para la evaluación y detección de vulnerabilidades y verificar su infraestructura en busca de más de 10,000 debilidades conocidas. Está diseñado para ahorrarle tiempo al ejecutar de forma proactiva análisis de seguridad, monitorear cambios en la red, sincronizar sistemas en la nube y más.
-
Seguridad
- Drones, vigilancia y reconocimiento facial: una startup llamada 'Sauron' presenta un sistema de seguridad para el hogar de estilo militar
- Conexión Segura NFS en Linux, Tunelizar NFS sobre SSH y Configuración de NFS sobre SSH para Mayor Seguridad
- ¿Olvidó su contraseña? Cinco razones por las que necesita un administrador de contraseñas
- Cómo limitar las conexiones SSH (puerto TCP 22) con ufw en Ubuntu Linux
- Utilizar ssh sin contraseña con ssh-keygen y ssh-copy-id
- Millones de teléfonos móviles podrían ser vulnerables a la vigilancia del gobierno chino
- Cómo limitar las conexiones SSH a la red local en Linux
- Los televisores inteligentes son como un «caballo de Troya digital» en los hogares
- Snort para Windows, detección de Intrusos y seguridad.
- Detección de Intrusiones con las herramientas: BASE y Snort.
- El Sistema de Detección de Intrusos: Snort. ( Windows y Linux )
- Configuración con Ejemplos de Snort para Windows, detección de intrusiones
- ¿El gobierno de EE. UU. ignoró la oportunidad de hacer que TikTok fuera más seguro?
- ¿Qué es SSH y cómo se utiliza? Los conceptos básicos de Secure Shell que necesitas saber
- Asegurar memcached del servidor, para evitar amplificar ataques DDoS