Seguimos con las 20 vulnerabilidades criticas y es hora de la 6.0
Application Security Software
¿Cómo atacantes aprovechan de la ausencia de este control?
Los ataques contra las vulnerabilidades en el software de aplicación basada en la web y otros han sido una prioridad para las organizaciones criminales en los últimos años. El software de aplicación que no comprueba correctamente el tamaño de la entrada del usuario, no para sanear la entrada del usuario mediante el filtrado de secuencias de caracteres que no sean necesarios, pero potencialmente malicioso o no inicializar las variables claras y bien podría ser vulnerable a comprometer a distancia. Los atacantes pueden inyectar exploits específicos, como desbordamientos de búfer, ataques de inyección SQL, cross-site scripting, cross-site solicitud falsificación y click-jacking de código para obtener el control de las máquinas vulnerables. En un ataque, más de 1 millón de servidores web se explotaron y se convirtieron en los motores de infección para los visitantes a los sitios que utilizan la inyección SQL. Durante el ataque, los sitios web de confianza de los gobiernos estatales y otras organizaciones comprometidas por atacantes para infectar a cientos de miles de navegadores que accedieron esos sitios web. Muchos más web y no web vulnerabilidades de las aplicaciones se descubren en una base regular.
Para evitar este tipo de ataques, tanto de software de aplicaciones desarrolladas internamente y de terceros deben ser cuidadosamente probados para encontrar fallas de seguridad. Para el software de aplicaciones de terceros, las empresas deben verificar que los proveedores han llevado a cabo pruebas de seguridad detallada de sus productos. Para obtener in-house desarrollado aplicaciones, las empresas deben llevar a cabo dichas pruebas sí mismos o contratar a una empresa externa para su realización.
Cómo implementar, automatizar y medir la efectividad de este control
1. Ganancias rápidas: Proteger las aplicaciones web mediante la implementación de firewalls de aplicaciones web (WAF) que inspeccionan todo el tráfico que fluye a la aplicación web para ataques comunes de aplicaciones web, incluyendo pero no limitado a cross-site scripting, inyección SQL, inyección de comandos y ataques de directorio transversal. Para las aplicaciones que no están basado en la web, firewalls de aplicaciones específicas deben ser desplegados si estas herramientas están disponibles para el tipo de aplicación. Si el tráfico está cifrado, el dispositivo o bien debe sentarse detrás de la encriptación o ser capaz de descifrar el tráfico antes del análisis. Si ninguna de estas opciones es adecuada, un firewall basado en host web aplicación debe ser desplegado.
2. Visibilidad / Reconocimiento: En un control mínimo, el error se debe hacer explícito para todas las entradas. Cada vez que se crea una variable en el código fuente, el tamaño y el tipo debe ser determinada. Cuando la entrada es proporcionada por el usuario se debe verificar que no exceda el tamaño o el tipo de datos de la ubicación de memoria en la que se almacena o se mueve en el futuro.
3. Visibilidad / Reconocimiento: Test in-house desarrollado y de terceros, adquiridos aplicaciones web para las debilidades comunes de seguridad automatizadas utilizando escáneres remotos de aplicaciones Web antes del despliegue, cuando se realizan actualizaciones de la aplicación y de manera recurrente regular. Las organizaciones deben entender cómo sus aplicaciones se comportan bajo ataques de denegación de servicio o el agotamiento de los recursos.
4. Visibilidad / Reconocimiento: Los mensajes de error del sistema no debe mostrarse a los usuarios finales (desinfección de salida).
5. Visibilidad / Reconocimiento: Mantener ambientes separados para los sistemas de producción y no producción. Los desarrolladores normalmente no deberían tener acceso sin control a los entornos de producción.
6. Configuración / Higiene: Test in-house desarrollado y de terceros, adquiridos web y otras aplicaciones de software para la codificación de errores y la inserción de malware, incluyendo puertas traseras, antes de la implementación mediante software automatizado de análisis de código estático. Si el código fuente no está disponible, estas organizaciones deberían probar el código compilado utilizando herramientas de análisis estático binarios. En particular, la validación de entrada y salida de las rutinas de codificación de software de aplicación debe ser cuidadosamente revisado y probado.
7. Configuración / Higiene: Para las aplicaciones que se basan en una base de datos, las organizaciones deben llevar a cabo una revisión de la configuración tanto de la carcasa del sistema operativo de la base de datos y el software de base de datos en sí, comprobando la configuración para asegurarse de que el sistema de base de datos se ha endurecido mediante plantillas estándar de endurecimiento. Todos los sistemas que forman parte de los procesos críticos de negocio también debe ser probado.
8. Configuración / higiene: Asegúrese de que todo el personal de desarrollo de software reciben capacitación en la escritura de código seguro para su entorno de desarrollo específico.
9. Configuración / Higiene: Los scripts de ejemplo, las bibliotecas, los componentes, compiladores, o cualquier otro código innecesario que no está siendo utilizada por una aplicación debe ser desinstalado o eliminado del sistema.
Associated NIST Special Publication 800-53, Revisión 3, Prioridad 1 Controles
CM-7, RA-5 (a, 1), SA-3, SA-4 (3), SA-8, SI-3, SI-10
Asociadas NSA manejables Hitos Red Plan y tareas de seguridad de red
Hito 3: Arquitectura de red
Hito 7: Gestión de Base
Security Gateways, Proxies y Firewalls
Procedimientos y herramientas para implementar y automatizar este control
Fuente herramientas de pruebas de código, herramientas de seguridad de aplicaciones web y herramientas de análisis de código objeto de prueba han demostrado su utilidad en la obtención de software de aplicación, junto con las pruebas de penetración manual de seguridad de la aplicación por los probadores que tienen conocimientos de programación extensa y la experiencia de aplicación de pruebas de penetración. La Enumeración Común Debilidad (CWE) iniciativa es utilizado por muchas herramientas para identificar las debilidades que encuentran. Las organizaciones también pueden utilizar CWE para determinar qué tipos de debilidades que están más interesados en el tratamiento y la eliminación. Al evaluar la eficacia de las pruebas de estas debilidades, común MITRE Enumeración Attack Pattern y clasificación se puede utilizar para organizar y registrar la amplitud de las pruebas de los CWES y permitir a los probadores a pensar como agresores en su desarrollo de casos de prueba.
Control 6 Metric:
El sistema debe ser capaz de detectar y bloquear un ataque de software a nivel de aplicación, y debe generar una alerta o enviar un correo electrónico a la iniciativa personal administrativo dentro de las 24 horas de la detección y bloqueo.
Todas las aplicaciones web con acceso a Internet deben ser escaneados de forma semanal o diaria, aviso o enviando un correo electrónico al personal administrativo dentro de las 24 horas de haber completado un análisis. Si el análisis no puede ser completado con éxito, el sistema debe alertar o enviar un correo electrónico al personal administrativo dentro de la hora que indica que la exploración no ha tenido éxito. Cada 24 horas después de ese punto, el sistema debe alertar o enviar un correo electrónico sobre el estado de las exploraciones incompletas, hasta que se reanude exploración normal.
Además, todas las vulnerabilidades de alto riesgo en las aplicaciones web pueda acceder desde Internet identificados por los escáneres de vulnerabilidades de las aplicaciones web, herramientas de análisis estático, y automatizado las herramientas de configuración de base de datos de revisión deben ser mitigados (por cualquiera de fijación de la falla o la aplicación de un control de compensación) dentro de los 15 días del descubrimiento de la falla.
Si bien los plazos de 24 horas y una hora-representan la métrica actual para ayudar a las organizaciones a mejorar su estado de seguridad, en las futuras organizaciones deben esforzarse para aún más rápido de alerta, con notificación acerca de un intento de ataque solicitud enviada a los dos minutos.
Control 6 Test:
Para evaluar la aplicación de control 6 sobre una base mensual, un equipo de evaluación debe utilizar una aplicación Web Vulnerability Scanner para detectar cada tipo de falla identificada en la lista actualizada de los "25 errores de programación más peligrosos" por Mitre y el Instituto SANS . El escáner debe estar configurado para evaluar todas las aplicaciones web de la organización pueda acceder desde Internet a identificar dichos errores. El equipo de evaluación debe verificar que la exploración se detecta dentro de 24 horas y que se genera una alerta.
Además del escáner de vulnerabilidades de aplicaciones web, el equipo de evaluación también debe ejecutar las herramientas de análisis estático de código y herramientas de base de datos de configuración de revisión en contra de Internet con acceso para aplicaciones para identificar fallas de seguridad en una base mensual.
El equipo de evaluación debe verificar que todas las vulnerabilidades de alto riesgo identificados por la vulnerabilidad de escaneo automático de herramientas o herramientas de análisis estático de código han sido remediada o abordarse a través de un control de compensación (como un firewall de aplicaciones web) dentro de los 15 días del descubrimiento.
El equipo de evaluación debe verificar que la aplicación de herramientas de escaneo de vulnerabilidad han completado con éxito sus exámenes regulares de los últimos 30 ciclos de barrido mediante la revisión de las alertas y los informes archivados para asegurar que la exploración se ha completado. Si el análisis no se completó con éxito, el sistema debe alertar o enviar un correo electrónico a la iniciativa personal administrativo que indican lo que pasó. Si el análisis no se pudo completar en ese período de tiempo, el equipo evaluador debe verificar que una alerta por correo electrónico o se ha generado lo que indica que la exploración no terminó.
Entidad de Control 6 Sistema Diagrama de relaciones (ERD):
Organizaciones encontrará que la diagramación de las entidades necesarias para cumplir plenamente los objetivos definidos en este control, será más fácil identificar la manera de implementar, probar los controles, e identificar dónde los posibles fallos en el sistema pueden ocurrir.
Un sistema de control es un dispositivo o conjunto de dispositivos se utilizan para administrar, comando, dirigir o regular el comportamiento de otros dispositivos o sistemas. En este caso, estamos examinando el proceso de aplicaciones de monitoreo y el uso de herramientas que hacen cumplir un estilo de seguridad en el desarrollo de aplicaciones.
La siguiente lista de los pasos en el diagrama de arriba muestra cómo las entidades trabajan juntos para alcanzar el objetivo de negocio definida en este control. La lista también ayuda a identificar qué cada uno de los pasos del proceso con el fin de ayudar a identificar los puntos potenciales de fallo en el control general.
Paso 1: firewalls de aplicación web proteger las conexiones a las aplicaciones web internas
Paso 2: Las aplicaciones de software conectarse de forma segura a los sistemas de bases de datos
Paso 3: Análisis de código y herramientas de escaneo de vulnerabilidad de análisis de sistemas de aplicaciones y sistemas de bases de datos.
Fuente:http://www.sans.org/critical-security-controls/control.php?id=6
Traduccion:Dellcom1@.
Saludos Mundo Libre.
No hay comentarios:
Publicar un comentario