aclaración del requisito 6.6 sobre revisiones de códigos y firewalls

 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: 2008-04-15
Suplemento informativo: requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones de las Normas de Seguridad de
Datos de la Industria de Tarjetas de Pago (PCI DSS) 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.
El objetivo de este documento es proporcionar información complementaria. La información aquí provista no reemplaza ni sustituye el requisito 6,6 de las
Normas de Seguridad de Datos (DSS) de la Industria de Tarjetas de Pago.
2
Suplemento informativo: requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones de las Normas de Seguridad de
Datos de la Industria de Tarjetas de Pago (PCI DSS) 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
El objetivo de este documento es proporcionar información complementaria. La información aquí provista no reemplaza ni sustituye el requisito 6,6 de las
Normas de Seguridad de Datos (DSS) de la Industria de Tarjetas de Pago.
3
Suplemento informativo: requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones de las Normas de Seguridad de
Datos de la Industria de Tarjetas de Pago (PCI DSS) 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.
El objetivo de este documento es proporcionar información complementaria. La información aquí provista no reemplaza ni sustituye el requisito 6,6 de las
Normas de Seguridad de Datos (DSS) de la Industria de Tarjetas de Pago.
4
Suplemento informativo: requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones de las Normas de Seguridad de
Datos de la Industria de Tarjetas de Pago (PCI DSS) 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).
El objetivo de este documento es proporcionar información complementaria. La información aquí provista no reemplaza ni sustituye el requisito 6,6 de las
Normas de Seguridad de Datos (DSS) de la Industria de Tarjetas de Pago.
5
Suplemento informativo: requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones de las Normas de Seguridad de
Datos de la Industria de Tarjetas de Pago (PCI DSS) 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.
El objetivo de este documento es proporcionar información complementaria. La información aquí provista no reemplaza ni sustituye el requisito 6,6 de las
Normas de Seguridad de Datos (DSS) de la Industria de Tarjetas de Pago.
6
Suplemento informativo: requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones de las Normas de Seguridad de
Datos de la Industria de Tarjetas de Pago (PCI DSS) •
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
El objetivo de este documento es proporcionar información complementaria. La información aquí provista no reemplaza ni sustituye el requisito 6,6 de las
Normas de Seguridad de Datos (DSS) de la Industria de Tarjetas de Pago.
7
Suplemento informativo: requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones de las Normas de Seguridad de
Datos de la Industria de Tarjetas de Pago (PCI DSS) 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.
El objetivo de este documento es proporcionar información complementaria. La información aquí provista no reemplaza ni sustituye el requisito 6,6 de las
Normas de Seguridad de Datos (DSS) de la Industria de Tarjetas de Pago.
8
Suplemento informativo: requisito 6.6 sobre revisiones de códigos y firewalls de aplicaciones de las Normas de Seguridad de
Datos de la Industria de Tarjetas de Pago (PCI DSS) •
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. El objetivo de este documento es proporcionar información complementaria. La información aquí provista no reemplaza ni sustituye el requisito 6,6 de las
Normas de Seguridad de Datos (DSS) de la Industria de Tarjetas de Pago.
9