¿Cómo se monitorean las vulnerabilidades publicadas en un pequeño equipo de desarrollo?

13

Somos una empresa de desarrollo web relativamente pequeña con recursos limitados, pero queremos estar al tanto de cualquier anuncio que pueda afectar la seguridad de nuestros servidores. Después de algunas búsquedas, hemos llegado a la conclusión de que la mayoría de las fuentes de información (por ejemplo, las listas de correo, las API creadas alrededor de CVE) normalmente se dividen en dos categorías principales:

  1. Demasiado amplio y ruidoso para que nuestro pequeño equipo no pueda mantenerse al día.
  2. Demasiado específico, por lo que nos perderíamos información importante.

La única lista que encontramos que es una necesidad absoluta es la lista de ubuntu-security-advertce, dado que ejecutamos versiones de Ubuntu LTS en nuestros servidores. Sin embargo, lo único que falta es (desde nuestra perspectiva) las vulnerabilidades en otras cosas que no sean el software, como los protocolos. El ejemplo clásico es POODLE (CVE-2014-3566), para el cual los archivos no parecen contener nada relacionado con esto ( buscando CVE y explorando archivos en octubre de 2014 ). Sin embargo, seguiremos suscribiéndonos a ubuntu-security-anunciate, porque aparecen errores importantes de software como Heartbleed.

¿La gente conoce las publicaciones / listas de correo centradas en la seguridad web que proporcionan una lista curada de vulnerabilidades recientes para complementar nuestra suscripción a ubuntu-security-advertce?

Algunos buenos ejemplos que hemos encontrado a través de otras preguntas en este sitio de stackexchange son:

  • boletines de us-cert (algo ruidosos, pero bien organizados)
  • archivos de vulnerabilidad de perfsonar (extremadamente curados, y por lo tanto parece bueno enlistar solo los artículos realmente importantes)
  • lista de correo bugtraq (extremadamente ruidosa para un pequeño equipo de desarrolladores de software)
  • cvedetails filtros personalizados (difícil saber qué monitorear para un equipo general de desarrollo web)

Le pido disculpas si esto parece un poco amplio, me complace volver a redactarlo para que sea adecuado, ya que creo que habría muchos otros pequeños equipos de desarrollo que buscan la misma información y les resulta difícil saber cómo mantenerse al tanto de tal diluvio de información de seguridad.

    
pregunta Peter Serwylo 10.08.2016 - 04:11
fuente

3 respuestas

4

A escala, es mejor revisar continuamente su automatización, pero la parte más importante es la automatización

Para RHEL, CentOS, Fedora, y otros hay yum-cron. Incluso puede especificar la gravedad de la seguridad: crítico si solo desea parches críticos.

Para Debian, Ubuntu, etc. hay actualizaciones desatendidas con conceptos similares.

Si crea aplicaciones o instala aplicaciones personalizadas, asegúrese de estar cubierto también allí. Además, hay infraestructura para asegurar parches. Automatizarlo tanto como sea posible. La gente argumentará que esto puede romper cosas. Por eso te recomiendo que automatices tanto como sea posible, pero no tanto que rompas cosas. Si solo está instalando automáticamente parches de seguridad críticos, entonces es mucho menos probable que rompa cosas. Averigua cómo automatizarlo al menos tanto. Incluso si tiene una política para no automatizar directamente sin aprobación humana, automatice la recopilación de toda la información, descargue los parches, y tenga un mecanismo de empujar o tirar, listo para usar el disparador de cabello.

OWASP tiene muchas y excelentes capacidades de integración a través de Dependency Check, incluso con una interfaz web para este proyecto: enlace

Uno puede integrar conceptos similares para crear servidores y proyectos de integración continua / implementación muy fácilmente. Estos entornos están muy equipados para este tipo de automatización. También existen muchas soluciones comerciales, es fácil encontrarlas en línea.

    
respondido por el atdre 12.08.2016 - 18:24
fuente
1

No tengo conocimiento de que exista un servicio de este tipo que pueda adaptarse a las necesidades comunicadas, aunque no estoy seguro de que exista la inteligencia para crear uno que brinde valor sin una atención significativa y permanente por parte del consumidor.

Puedo pensar en 4 conjuntos de fuentes de información a las que prestar atención, que se enumeran a continuación. A menos que las circunstancias específicas de su negocio requieran atención con nosotros, cert, bugtraq o cvedetails, no los incluiría en una lista de fuentes útiles.

Los 4 conjuntos son:

  • sistema operativo
  • proveedor de infraestructura
  • proveedores de software individuales
  • plataforma de desarrollo / bibliotecas

La regla general es que, en ausencia de una fuente configurable agregada, las fuentes individuales más importantes a las que se debe prestar atención son los proveedores del software y la infraestructura que se utilizan, tanto en un contexto operacional como en un contexto de desarrollo. Para aquellos, siga cualquier lista específica de anuncios de seguridad y lanzamientos, así como su blog técnico general. El blog de Ubuntu es donde se distribuyeron noticias sobre su respuesta a POODLE (por ejemplo, enlace ).

El sistema operativo es una capa en este sándwich. Debajo del sistema operativo, si los servidores están virtualizados en un entorno de nube, esta regla comprende el proveedor de la nube: AWS, Google, Digital Ocean, etc. En términos generales, AWS tiene blogs para cada servicio principal: estos comunicarán información relevante desde un contexto de seguridad. .

Si la virtualización o la plataforma en la nube también incluye contenedores, entonces vale la pena seguir el blog, la seguridad y los anuncios de publicación del proveedor de contenedores ascendente (Docker, linuxcontainers, etc.).

Sobre el sistema operativo hay aplicaciones individuales. Estos pueden ser entregados por el proveedor del sistema operativo pero, sin embargo, son fuentes independientes de noticias e información, porque el filtro de curación del proveedor del sistema operativo va a excluir el contexto importante relacionado con las características y la configuración de estas aplicaciones.

La importancia de atenderlos depende de su función en su infraestructura, y su función puede clasificarse en dos dimensiones:

  • qué tan visibles son para las fuentes de tráfico potencialmente maliciosas
  • qué tan importantes son para asegurar su subsistencia

Es posible que tenga una base de datos importante que no esté expuesta públicamente a tráfico potencialmente malicioso, pero es conveniente consultar sus publicaciones, lista de seguridad y blog técnico, ya que la información de configuración defensiva y arquitectónica importante se comunicará allí y no se comunicará. Ven a través de otras fuentes.

De forma similar, probablemente ejecute servidores web nginx o apache y algún tipo de servidor de aplicaciones. Ubuntu, por supuesto, recopila y procesa información de los lanzamientos, anuncios de seguridad y blogs técnicos de estos proyectos, pero nuevamente su filtro de curación excluirá los problemas específicos de configuración e implementación que estos proyectos informarán a sus usuarios directamente.

Como una tienda de desarrollo web, presumiblemente su equipo trabaja en una o más plataformas (Node, Rails, Spring, React, lo que sea), que consumen los lanzamientos de la plataforma de los principales proveedores y también de los desarrolladores de bibliotecas que operan en ese ecosistema y luego Produciendo software para sus clientes. Es importante seguir los anuncios y el blog de la plataforma y los proveedores de la biblioteca cuyo trabajo consume y mantenerse al día sobre las dependencias. Aquí hay algunos servicios nuevos que se centran en encontrar y curar las vulnerabilidades encontradas mediante el análisis estático de las plataformas de desarrollo y las bibliotecas, y luego integrar esa información en flujos de trabajo de integración / entrega continuos, estos servicios son dignos de consideración para su equipo.

Nuevamente, la regla general es: si consume un servicio o una aplicación como una dependencia en su infraestructura operativa, o si consume una aplicación o biblioteca en su infraestructura de desarrollo, entonces siga los anuncios de esos proveedores de servicios específicos. Estado actual de madurez de la industria importante para la seguridad.

Los proveedores intermedios que empaquetan y distribuyen software desde el origen no suelen resolver los casos de uso de configuración e implementación que son sensibles a la seguridad y en los que los proveedores de software ascendente pasan mucho tiempo pensando.

Finalmente, hay mucho material potencial a seguir, que en sí mismo es un punto importante sobre la superficie de ataque. Debido a que todo el software contiene vulnerabilidades, cuanto más se consume y utiliza, más amplia se vuelve la superficie de ataque. Consumir algún software para su funcionalidad y no atender su flujo ascendente es una forma de deuda técnica fuera de balance.

Espero que sea útil.

    
respondido por el Jonah Benton 11.08.2016 - 12:02
fuente
0

He adoptado un enfoque algo diferente en el pasado.

Dado que los distribuidores de Linux están monitoreando activamente las fuentes ascendentes en busca de nuevas versiones, utilicé el sistema de administración de paquetes (en mi caso, al estar ejecutando SuSe) desde la línea de comandos para listar las actualizaciones necesarias.

No confié ciegamente en esto; en su lugar, muestreado un historial de actualizaciones que comparan la demora entre la publicación del CVE y la actualización de una actualización. La brecha fue en la región de 3 días en promedio. Sin embargo, reconozco que un parche que se lanza rápidamente no está garantizado y que a menudo hay otras mitigaciones disponibles que no sean la espera de una solución del proveedor (algo que muchas grandes compañías de software no parecen reconocer).

No puedo exportar en apt, pero espero que sea posible identificar las actualizaciones necesarias utilizando aptitude .

    
respondido por el symcbean 12.08.2016 - 18:06
fuente

Lea otras preguntas en las etiquetas