Suplemento informativo: aclaración del requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones

Transcripción

1 Norma: Normas de Seguridad de Datos (DSS) Requisito: 6.6 Fecha: febrero de 2008 Suplemento informativo: aclaración del requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones Fecha de publicación:

2 Descripción general El requisito 6.6 de PCI DSS brinda dos opciones que tienen como objetivo abordar las amenazas comunes para los datos de los titulares de tarjetas de crédito y garantizar que la entrada que reciben las aplicaciones web de entornos que no son seguros sea inspeccionada de arriba abajo. Los detalles de cómo cumplir este requisito variarán según la implementación específica de una aplicación en particular. Los análisis forenses sobre los riesgos de los datos de titulares de tarjetas de crédito han demostrado que las aplicaciones web son, con frecuencia, el punto inicial de ataque contra los datos de titulares de tarjetas de crédito, principalmente mediante la inyección SQL. El objetivo del requisito 6.6 es garantizar que las aplicaciones web expuestas a la Internet pública estén protegidas contra los tipos más comunes de entrada maliciosa. Existe una gran cantidad de información pública disponible sobre las vulnerabilidades de las aplicaciones web. Las mínimas vulnerabilidades que deben considerarse están descritas en el requisito 6.5. (Consulte la sección Referencias para obtener otras fuentes de información sobre las pruebas de aplicaciones web). La correcta implementación de ambas opciones proporcionaría la mejor defensa de múltiples capas. Las normas PCI SSC reconocen que el costo y la complejidad operativa que implica la implementación de las dos opciones quizá no sean factibles. Además, tanto una opción como la otra tal vez no sean posibles en algunas situaciones (por ejemplo, si no se puede acceder al código fuente). Sin embargo, debe ser posible aplicar, por lo menos, una de las alternativas descritas en este documento, y la correcta implementación puede satisfacer el objetivo del requisito. Este documento brinda orientación para ayudarlo a determinar cuál es la mejor opción, que puede variar según los productos que se utilicen, cómo una organización adquiere o desarrolla sus aplicaciones web y otros factores en el entorno. Opción 1 del requisito 6.6: revisiones de códigos de aplicaciones La opción de revisión del código de aplicaciones no requiere necesariamente una revisión manual del código fuente. Si se tiene en cuenta que el objetivo del requisito 6.6 es evitar la explotación de vulnerabilidades comunes (como aquellas mencionadas en el requisito 6.5), se podrán considerar varias soluciones posibles. Estas son dinámicas y anticipadas, lo que requiere el inicio específico de un proceso manual o automático. Si se implementan correctamente, una o más de estas cuatro alternativas pueden cumplir el objetivo de la opción 1 y proporcionar el mínimo nivel de protección contra las amenazas típicas para las aplicaciones web: 1. Revisión manual del código fuente de las aplicaciones. 2. Uso correcto de herramientas automatizadas de análisis del código fuente de las aplicaciones (herramientas de escaneo). 3. Evaluación manual de vulnerabilidades de la seguridad de las aplicaciones web. 2

3 4. Uso correcto de herramientas automatizadas de evaluación de vulnerabilidades de la seguridad de las aplicaciones web (herramientas de escaneo). Todo esto debe estar diseñado para probar la presencia de vulnerabilidades en aplicaciones web, como se indicó anteriormente en Descripción general. Tenga en cuenta que una evaluación de vulnerabilidades simplemente identifica y notifica las vulnerabilidades, mientras que una prueba de penetración intenta explotar las vulnerabilidades para determinar la posibilidad de que ocurra un acceso no autorizado u otra actividad maliciosa. Las evaluaciones o revisiones manuales deben ser llevadas a cabo por un recurso interno calificado o por un tercero calificado. En cualquier caso, el/los individuo/s debe/n contar con las habilidades y la experiencia adecuadas para comprender el código fuente y/o la aplicación web, saber cómo evaluar las vulnerabilidades de cada uno y entender las conclusiones. De igual modo, los individuos que utilicen herramientas automatizadas deben contar con las habilidades y el conocimiento necesarios para configurar correctamente la herramienta y el entorno de prueba, utilizar la herramienta y evaluar los resultados. Si se utilizan recursos internos, deben estar separados, desde el punto de vista organizativo, de la administración de la aplicación que se está evaluando. Por ejemplo, el equipo que escribe el software no debe realizar la revisión o la evaluación finales ni verificar si el código es seguro. Existen varias formas de realizar la revisión de un código o la evaluación de una aplicación que proporcionarían el mismo nivel de protección (o uno mejor) que el proporcionado por el firewall de una aplicación (discutido abajo, en la opción 2). Dos ejemplos que pueden cumplir el objetivo de la primera opción son los siguientes: 1. Una organización que cuente, como parte del ciclo de vida de desarrollo del software (SDLC), con un proceso por medio del cual se le realice una revisión de seguridad independiente al código fuente de una aplicación web. La revisión de seguridad debe consistir en examinar aplicaciones para detectar si cuentan con controles que se ocupen de las típicas vulnerabilidades de las aplicaciones web. Estas revisiones de códigos pueden implementarse como procesos manuales o automáticos. 2. Uso de un proceso manual o de herramientas especializadas para probar la presencia de vulnerabilidades y defectos expuestos en una aplicación web que se está ejecutando. Este enfoque implica la creación de entrada maliciosa o no estándar y el envío de esta a la aplicación para simular un ataque. Las respuestas a esas entradas se examinan para determinar si la aplicación puede ser vulnerable ante ciertos ataques. Las revisiones o evaluaciones deben incorporarse en el SDLC y deben realizarse antes de que la aplicación sea implementada en el entorno de producción. El SDLC debe proteger constantemente la información, de acuerdo con el requisito 6.3. Los procesos de control de cambios deben garantizar que los desarrolladores de software no puedan omitir el paso de evaluación de aplicaciones o revisión de códigos ni implementar nuevo software directamente en el entorno de producción. Los procesos de control de cambios 3

4 también deben exigir la corrección y la reevaluación de las vulnerabilidades antes de la implementación. Si bien la aprobación final de los resultados del análisis o de la revisión debe ser realizada por una organización independiente, se recomienda que las revisiones y los análisis también sean realizados lo antes posible en el proceso de desarrollo. Las herramientas deben ponerse a disposición de los desarrolladores de software y deben integrarse en su paquete de desarrollo de la forma más práctica posible. Los proveedores pueden reunir las capacidades de evaluación de vulnerabilidades o análisis de códigos en productos que tienen otros objetivos, como la validación del cumplimiento de las mejores prácticas de arquitectura relacionadas con un idioma específico. Al evaluar estas herramientas, es importante confirmar la capacidad que tienen para probar las vulnerabilidades habituales de las aplicaciones web antes de suponer que se pueden utilizar para cumplir el objetivo del requisito 6.6. Además, para hacer frente a amenazas nuevas y emergentes, las herramientas deben tener la capacidad de incorporar nuevas normas de análisis. Las personas que llevan a cabo las revisiones o evaluaciones manuales deben estar al tanto de las tendencias del sector, con el fin de garantizar que sus habilidades de prueba o evaluación sigan siendo efectivas para hacer frente a nuevas vulnerabilidades. Opción 2 del requisito 6.6: firewalls de aplicaciones En el contexto del requisito 6.6, un firewall de aplicaciones es un Firewall de Aplicaciones Web (WAF), que es un punto de aplicación de políticas de seguridad colocado entre una aplicación web y el punto final del cliente. Esta funcionalidad se puede implementar en un software o un hardware que se ejecuta en un dispositivo o en un servidor típico que ejecuta un sistema operativo habitual. Puede ser un dispositivo independiente o un dispositivo integrado en otros componentes de la red. Los firewalls de red habituales se implementan en el perímetro de la red o entre segmentos de la red (zonas) y constituyen la primera línea de defensa contra muchos tipos de ataques. Sin embargo, estos deben permitir que los mensajes lleguen a las aplicaciones web que una organización escoge para exponer a la Internet pública. Los firewalls de red, por lo general, no están diseñados para inspeccionar ni evaluar las partes de un mensaje del Protocolo de Internet (IP) (paquete) utilizado por aplicaciones web ni para reaccionar ante ellas; por lo tanto, las aplicaciones públicas reciben con frecuencia entrada que no ha sido inspeccionada. Como resultado, se crea un nuevo perímetro de seguridad lógico, la misma aplicación web, y las mejores prácticas de seguridad exigen que los mensajes sean inspeccionados cuando pasan de un entorno no seguro a un entorno seguro. Existen muchos ataques conocidos contra aplicaciones web y, como todos sabemos, las aplicaciones web no siempre están diseñadas ni escritas para defenderse contra estos ataques. Además, el hecho de que estas aplicaciones estén disponibles para prácticamente cualquier persona que tenga una conexión a Internet intensifica el riesgo. 4

5 Los WAF están diseñados para inspeccionar el contenido de la capa de aplicación de un paquete IP y el contenido de cualquier otra capa que pueda ser utilizada para atacar a una aplicación web. No obstante, debe observarse que el requisito 6.6 no tiene como finalidad implementar controles redundantes. El contenido del paquete IP inspeccionado adecuadamente (es decir, proporcionando protección equivalente) por firewalls de red, servidores proxy u otros componentes no tiene que volver a ser inspeccionado por un WAF. La estructura de un paquete IP sigue un modelo en capas, donde cada capa contiene información definida que es puesta en práctica por componentes o nodos de red específicos (físicos o basados en software) que permiten el flujo de información a través de Internet o intranet. La capa que contiene el contenido procesado por la aplicación se denomina capa de aplicación. La tecnología WAF se integra cada vez con más frecuencia en soluciones que incluyen otras funciones, como filtrado de paquetes, uso de proxy, terminación SSL, balanceo de carga, captura de objetos, etc. Estos dispositivos se comercializan de diversas maneras como firewalls, puertas de enlace de aplicaciones, sistema de entrega de aplicaciones, proxy de seguridad o con alguna otra descripción. Es importante comprender plenamente las capacidades de inspección de datos de dicho producto a fin de determinar si puede satisfacer el objetivo del requisito 6.6. Tenga en cuenta que el cumplimiento no está garantizado con solo implementar un producto con las capacidades descritas en este documento. La ubicación, la configuración, la administración y la monitorización adecuadas también son aspectos clave de una solución que cumple los requisitos. La implementación de un WAF es una opción para cumplir el requisito 6.6, pero no elimina la necesidad de realizar un proceso seguro de desarrollo de software (requisito 6.3). 5

6 Capacidades recomendadas Un firewall de aplicaciones web debe: Cumplir todos los requisitos aplicables de PCI DSS relacionados con los componentes del sistema en el entorno de datos de titulares de tarjetas de crédito. Reaccionar de forma adecuada (según normas o políticas activas) ante amenazas contra las vulnerabilidades pertinentes identificadas, como mínimo, en el OWASP Top Ten y/o el requisito 6.5 de PCI DSS. Inspeccionar la entrada de aplicaciones web y responder (permitir, bloquear y/o alertar) según normas o políticas activas, y registrar medidas adoptadas. Evitar la fuga de datos, lo que implica tener la capacidad de inspeccionar la salida de aplicaciones web y responder (permitir, bloquear, ocultar y/o alertar) según normas o políticas activas, y registrar medidas adoptadas. Aplicar modelos de seguridad, tanto positivos como negativos. El modelo positivo ( lista blanca ) define comportamientos, entradas, rangos de datos, etc. aceptables y permitidos, y rechaza todo lo demás. El modelo negativo ( lista negra ) define aquello que NO está permitido; los mensajes que coincidan con esas firmas serán bloqueados y el tráfico que no coincida con las firmas (no incluidas en la lista negra ) será permitido. Inspeccionar el contenido de páginas web, como el Lenguaje de Marcado de Hipertexto (HTML), el HTML Dinámico (DHTML) y las Hojas de Estilo en Cascada (CSS), y los protocolos subyacentes que entregan contenido, como el Protocolo de Transferencia de Hipertexto (HTTP) y el Protocolo de Transferencia de Hipertexto sobre SSL (HTTPS). (Además del SSL, el HTTPS incluye el Protocolo de Transferencia de Hipertexto sobre TLS). Inspeccionar los mensajes de servicios web, si estos servicios web están expuestos a la Internet pública. Generalmente, esto incluirá el Protocolo Simple de Acceso a Objetos (SOAP) y el Lenguaje Extensible de Marcas (XML), tanto los modelos orientados a RPC como los orientados a documentos, además del HTTP. Inspeccionar cualquier protocolo (propietario o estándar) o construcción de datos (propietaria o estándar) que se utilice para transferir datos hacia una aplicación web, o desde ella, cuando dichos protocolos o datos no son inspeccionados en otro punto en el flujo del mensaje. Nota: Los protocolos propietarios presentan desafíos para los productos actuales de firewall de aplicaciones, de modo que pueden requerirse cambios personalizados. Si los mensajes de una aplicación no siguen los protocolos ni las construcciones de datos estándares, quizá no sea razonable solicitar que el firewall de una aplicación inspeccione ese flujo específico del mensaje. En estos casos, la implementación de la opción de evaluación de vulnerabilidades y revisión de códigos del requisito 6.6 probablemente sea la mejor alternativa. Brindar protección contra amenazas para el mismo WAF. 6

7 Admitir la terminación SSL y/o TLS, o ubicarse de tal modo que las transmisiones cifradas sean descifradas antes de que el WAF las inspeccione. Los flujos de datos cifrados no pueden inspeccionarse, salvo que el SSL sea terminado antes que el motor de inspección. Capacidades adicionales recomendadas para determinados entornos Evitar y/o detectar la alteración de los tokens de sesiones, por ejemplo, al cifrar cookies de sesiones, campos ocultos de formularios u otros elementos de datos utilizados para el mantenimiento del estado de sesiones. Recibir y aplicar automáticamente actualizaciones dinámicas de firmas de un proveedor u otra fuente. Ante la ausencia de esta capacidad, se debe contar con procedimientos para garantizar la actualización frecuente de las firmas u otros parámetros de configuración del WAF. Apertura en caso de error (un dispositivo que ha fallado permite el ingreso de tráfico sin inspección) o Cierre en caso de error (un dispositivo que ha fallado bloquea todo el tráfico), según la política activa. Nota: La decisión de permitir que un WAF quede abierto en caso de error debe evaluarse cuidadosamente en cuanto al riesgo que implica la exposición de aplicaciones web sin protección a la Internet pública. El modo Omisión, en el cual no se realiza ningún tipo de modificación al tráfico que lo atraviesa, puede ser aplicable en algunas circunstancias. (Incluso en el modo Apertura en caso de error, algunos WAF agregan encabezados de seguimiento, limpian los HTML de los cuales consideran que no cumplen las normas o realizan otras acciones. Esto puede tener una consecuencia negativa cuando se intente solucionar problemas). En determinados entornos, el WAF debe admitir los certificados SSL del cliente y realizar la autenticación del cliente mediante certificados utilizando un proxy. Muchas aplicaciones web modernas utilizan certificados SSL de clientes para identificar usuarios finales. Sin esta capacidad, estas aplicaciones no pueden alojarse detrás del firewall de una aplicación. Muchos firewalls modernos de aplicaciones se integrarán con el Protocolo Ligero de Acceso a Directorios (LDAP) o con directorios de otros usuarios, e incluso podrán realizar la autenticación inicial en nombre de la aplicación subyacente. Algunas aplicaciones de comercio electrónico pueden requerir el uso de un depósito de claves de hardware FIPS. Si esto se aplica a su entorno, asegúrese de que el proveedor del WAF cuente con este requisito en uno de sus sistemas, y tenga en cuenta que esta característica puede aumentar significativamente el costo de la solución. Consideraciones adicionales Si bien los WAF pueden brindar protección contra muchas amenazas de seguridad, también pueden exponer problemas técnicos dentro de una infraestructura. Asegúrese 7

8 de tener cuidado con los siguientes problemas que pueden dificultar la implementación satisfactoria: Los sitios que dependen de encabezados, URL o cookies atípicos pueden requerir un ajuste especial. Los WAF, con frecuencia, aplican ajustes máximos para estos componentes. Además, las firmas que buscan pueden filtrar cadenas específicas consideradas como puntos vulnerables que, en realidad, pueden ser perfectamente válidas para una aplicación específica. El contenido que no cumple los RFC del HTML/HTTP o es atípico también puede ser bloqueado si no se ajustan los filtros predeterminados. Esto puede incluir cualquier cosa, desde cargas de archivos demasiado grandes hasta contenido enviado en lenguajes o conjuntos de caracteres externos. DHTML, JavaScript Asíncrono y XML (AJAX), y otras tecnologías dinámicas pueden requerir consideración, pruebas y ajustes especiales. Algunas veces, estas aplicaciones suponen que tienen acceso a un sitio web que es percibido como malicioso por un WAF. Las aplicaciones que requieren información sobre la sesión de red subyacente, como la dirección IP del cliente, pueden requerir modificación si el WAF actúa como un proxy inverso. Generalmente, estos WAF colocarán la información del cliente en un encabezado HTTP tal vez no esperado por las aplicaciones existentes. Consideraciones importantes Las revisiones de códigos y las evaluaciones de vulnerabilidades de las aplicaciones descritas en este documento deben realizarse antes de que la aplicación sea implementada en el entorno de producción. Si se considera el uso de un WAF en modo Apertura en caso de error o modo Omisión, se deben establecer procedimientos y criterios específicos que definan el uso de estos modos de mayor riesgo antes de la implementación. Las aplicaciones web no están protegidas mientras estos modos están activos, por lo que no se recomienda su uso por períodos largos. Se debe evaluar el impacto de los cambios en el firewall de aplicaciones web para determinar el posible impacto en aplicaciones web relevantes, y viceversa. Se deben comunicar el tiempo y el alcance de los cambios de producción en el firewall de las aplicaciones web a todas las partes afectadas de la organización. Es necesario adherirse a todas las políticas y todos los procedimientos, incluidos el control de cambios, la continuidad de la actividad empresarial y la recuperación después de un desastre. Los cambios en el entorno de producción deben realizarse durante el período de mantenimiento monitorizado. Fuentes adicionales de información Esta lista se proporciona como punto de partida para obtener más información sobre la seguridad de las aplicaciones web. 8

9 OWASP Top Ten Referencia de medidas preventivas de OWASP Preguntas más frecuentes sobre la seguridad de aplicaciones de OWASP Build Security In (Departamento de Seguridad Nacional, División Nacional de Seguridad Cibernética [NCSD]) Analizadores de vulnerabilidades de aplicaciones web (Instituto Nacional de Estándares y Tecnología [NIST]) Criterios de evaluación de firewalls de aplicaciones web (Consorcio de Seguridad de Aplicaciones Web [WASC]) Acerca del PCI Security Standards Council (Consejo sobre Normas de Seguridad de la Industria de Tarjetas de Pago) El objetivo del PCI Security Standards Council es mejorar la seguridad de las cuentas de pago impulsando la educación y la concienciación sobre las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago y otras normas que aumentan la seguridad de los datos de pago. El PCI Security Standards Council fue creado por las principales marcas de tarjetas de pago, American Express, Discover Financial Services, JCB International, MasterCard Worldwide y Visa Inc., con el fin de proporcionar un foro transparente en el cual todas las partes interesadas pudieran proporcionar información sobre el desarrollo, la mejora y la difusión continuos de las Normas de Seguridad de Datos de la Industria de las Tarjetas de Pago (PCI DSS), los requisitos de seguridad para los Dispositivos de Entrada de PIN (PED) y las Normas de Seguridad de Datos para las Aplicaciones de Pago (PA-DSS). Los comerciantes, los bancos, los procesadores y los proveedores de puntos de venta son alentados a asociarse como organizaciones participantes. 9