normas de seguridad de datos de la industria de tarjetas ... · tarjetas de pago, así como el...

Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI)

Navegación de las PCI DSS

Comprensión del objetivo de los requisitos Versión 2.0

Octubre de 2010

Navegación de las PCI DSS: Comprensión del objetivo de los requisitos, versión 2.0 Octubre de 2010 Copyright 2010, PCI Security Standards Council LLC Página 2

Modificaciones realizadas a los documentos Fecha Versión Descripción

1 de octubre de 2008

1.2 Alinear el contenido con la nueva versión 1.2 de PCI DSS e implementar cambios menores notados desde la versión 1.1 original.

28 de octubre de 2010

2.0 Alinear contenido con la nueva versión 2.0 de las PCI DSS.


Índice

Modificaciones realizadas a los documentos......... ..........................................................................................................2

Prefacio ........................................... .....................................................................................................................................4 Virtualización ........................................................................................................................................................................................................... 5

Elementos de datos de titulares de tarjetas y de da tos confidenciales de autenticación................ ............................6 Ubicación de datos de titulares de tarjetas y de datos confidenciales de autenticación ........................................................................................ 8 Datos de la pista 1 vs. pista 2.................................................................................................................................................................................. 9

Guía relacionada por las Normas de Seguridad de Dat os de la PCI....................................... ......................................10

Guía para los Requisitos 1 y 2: Desarrollar y mante ner una red segura................................. .....................................11 Requisito 1: Instalar y mantener una configuración de firewall para proteger los datos del titular de la tarjeta ................................................... 11 Requisito 2: No usar los valores predeterminados suministrados por el proveedor para las contraseñas del sistema y otros parámetros de seguridad ............................................................................................................................................................................................................... 17

Guía para los Requisitos 3 y 4: Proteja los datos d el titular de la tarjeta ........................... .........................................20 Requisito 3: Proteja los datos del titular de la tarjeta que fueron almacenados ................................................................................................... 20 Requisito 4: Cifrar la transmisión de los datos del titular de la tarjeta en las redes públicas abiertas. ................................................................ 28

Guía para los Requisitos 5 y 6: Mantener un program a de administración de vulnerabilidad .............. ....................30 Requisito 5: Utilice y actualice regularmente el software o los programas antivirus ............................................................................................ 30 Requisito 6: Desarrolle y mantenga sistemas y aplicaciones seguras ................................................................................................................. 32

Guía para los Requisitos 7, 8 y 9: Implemente medid as sólidas de control de acceso.................... ..........................40 Requisito 7: Restrinja el acceso a los datos del titular de la tarjeta según la necesidad de saber que tenga la empresa................................... 40 Requisito 8: Asignar una ID exclusiva a cada persona que tenga acceso por computadora............................................................................... 42 Requisito 9: Restrinja el acceso físico a los datos del titular de la tarjeta............................................................................................................. 47

Guía para los Requisitos 10 y 11: Supervise y evalú e las redes con regularidad........................ ...............................51 Requisito 10: Rastree y supervise todos los accesos a los recursos de red y a los datos de los titulares de las tarjetas................................... 51 Requisito 11: Probar periódicamente los sistemas y procesos de seguridad....................................................................................................... 55

Guía para los Requisitos 12: Mantenga una política de seguridad de información........................ ............................61 Requisito 12: Mantener una política que trate la seguridad de la información para todo el personal .................................................................. 61

Guía para el requisito A.1: Requisitos de las PCI D SS adicionales para proveedores de hosting comparti do .......67

Anexo A: Norma de seguridad de datos de la PCI: Documentos r elacionados ........................................ ..............69


Prefacio

Este documento describe los 12 requisitos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS), al tiempo que proporciona orientación para explicar el objetivo de cada requisito. El objetivo de este documento es ayudar a comerciantes, proveedores de servicios e instituciones financieras que pudieran necesitar comprender más claramente la Norma de Seguridad de Datos de la Industria de Tarjetas de Pago, así como el significado y objetivo específicos de los requisitos detallados para asegurar los componentes de sistemas (servidores, red, aplicaciones, etc.) que respaldan los entornos de datos de los titulares de tarjetas.

NOTA: Navegación de las PCI DSS: La comprensión del objet ivo de los requisitos es sólo para efectos de guía. Cuando se finaliza u na evaluación in situ de las PCI DSS o un Cuestionario de Autoevaluación (SAQ), los Requisitos de las PCI DSS y los Procedimientos de Evaluación de Seguridad y los Cuestionarios de Autoevaluación de las PCI DSS 2.0 son documentos de registro.

Los requisitos de las PCI DSS se aplican a todos los componentes del sistema. En el contexto de las PCI DSS, los "componentes del sistema" se definen como cualquier componente de red, servidor o aplicación que esté incluida en el entorno de los datos del titular de la tarjeta o que esté conectado a éste. Los “componentes del sistema” también incluyen cualesquiera componentes de virtualización tales como máquinas virtuales, switches/routers virtuales, dispositivos virtuales, aplicaciones/escritorios virtuales e hipervisores. El entorno de los datos de los titulares de tarjetas consta de personas, procesos y tecnología que manipulan datos de titulares de tarjetas o datos confidenciales de autenticación.

� Los componentes de la red pueden incluir, a modo de ejemplo, firewalls, switches, routers, puntos de acceso inalámbricos, aplicaciones de la red y otras aplicaciones de seguridad.

� Los tipos de servidores incluyen, a modo de ejemplo: web, aplicación, base de datos, autenticación, correo electrónico, proxy, protocolo de tiempo de red (NTP) y servidor de nombre de dominio (DNS).

� Las aplicaciones incluyen, a modo de ejemplo, todas las aplicaciones compradas y personalizadas, incluidas las aplicaciones internas y externas (como Internet).

El primer paso de una evaluación de las PCI DSS es determinar con exactitud el alcance de la revisión. Por lo menos una vez al año y antes de la evaluación anual, la entidad evaluada debería confirmar la exactitud del alcance de las PCI DSS al identificar todas las ubicaciones y los flujos de datos de titulares de tarjetas y al asegurar que se incluyan en el alcance de las PCI DSS. Para confirmar la exactitud e idoneidad del alcance de las PCI DSS, realice lo siguiente:

� La entidad evaluada identifica y documenta la existencia de todos los datos de los titulares de tarjetas en su entorno, con la finalidad de verificar que no haya datos de titulares de tarjetas fuera del entorno de los datos de los titulares de tarjetas (CDE) actualmente definido.

� Una vez que se hayan identificado y documentado todas las ubicaciones de los datos de los titulares de tarjetas, la entidad utiliza los resultados para verificar que el alcance de las PCI DSS sea apropiado (por ejemplo, los resultados pueden ser un diagrama o un inventario de ubicaciones de datos de titulares de tarjetas).

� La entidad considera que todos los datos de titulares de tarjetas encontrados están dentro del alcance de la evaluación de las PCI DSS y forman parte del CDE, a menos que dichos datos se eliminen o migren/consoliden en el CDE actualmente definido.

� La entidad retiene la documentación que demuestre los resultados y cómo se confirmó el alcance de las PCI DSS para la revisión por parte de los asesores y/o como referencia durante la actividad anual de la siguiente confirmación de alcance de las PCI SCC.


La segmentación de red, o separación (segmentación), del entorno de los datos del titular de la tarjeta del resto de la red corporativa de una entidad no constituye un requisito de las PCI DSS. Sin embargo, constituye un método ampliamente recomendado que puede reducir el alcance del entorno de datos de los titulares de tarjetas. Un Asesor de Seguridad Calificado (QSA) puede ayudar a determinar el alcance dentro del entorno de datos de los titulares de tarjetas de una entidad, además de proporcionar orientación sobre cómo reducir el alcance de una evaluación de las PCI DSS al implementar una segmentación apropiada de la red.

En lo que se refiere a las preguntas sobre si una implementación específica concuerda con la norma o “cumple” con un requisito específico, el PCI SSC recomienda a las compañías consultar a un QSA para validar su implementación de tecnología y procesos, así como el cumplimiento de las Normas de Seguridad de Datos de la PCI. La experiencia que tienen los QSA trabajando en entornos de red complejos ayuda a proporcionar mejores prácticas y orientación al comerciante o proveedor de servicios que intenta lograr el cumplimiento. La lista de Asesores de Seguridad Calificados del PCI SSC está disponible en: https://www.pcisecuritystandards.org.

Virtualización

Si la virtualización está implementada, todos los componentes dentro del entorno virtual se deberán identificar y considerar en el alcance de la revisión, incluidos hosts o dispositivos virtuales individuales, máquinas huésped, aplicaciones, interfaces de administración, consolas de administración centrales, hipervisores, etc. Todas las comunicaciones y flujos de datos dentro del host se deben identificar y documentar, así como todas aquellas entre el componente virtual y otros componentes del sistema.

La implementación de un entorno virtualizado debe cumplir con el objetivo de todos los requisitos, de modo tal que los sistemas virtualizados se puedan concebir efectivamente como una unidad de hardware independiente. Por ejemplo, debe existir una clara segmentación de funciones y segregación de redes con diferentes niveles de seguridad; la segmentación debe impedir compartir los entornos de producción y prueba/desarrollo; la configuración virtual se debe asegurar de modo tal que las vulnerabilidades de una función no puedan afectar la seguridad de otras funciones; y los dispositivos conectados, tales como dispositivos USB/en serie, no deberían ser accesibles por todas las instancias virtuales.

Adicionalmente, todos los protocolos de interfaces de administración virtuales se deben incluir en la documentación del sistema, además, los roles y permisos se deben definir para administrar redes virtuales y componentes de sistemas virtuales. Las plataformas de virtualización deben estar en capacidad de exigir la separación de tareas y menos privilegio para separar la administración de la red virtual de la administración del servidor virtual.

Cuando se implementan controles de autenticación, se debe tener especial cuidado para asegurar que los usuarios se autentiquen ante los componentes virtuales apropiados del sistema y para distinguir entre las VM (máquinas virtuales) huésped y el hipervisor.


Elementos de datos de titulares de tarjetas y de da tos confidenciales de autenticación Las PCI DSS se aplican donde sea que se almacenen, procesen o transmitan datos de cuentas. Los datos de cuentas constan de los datos de los titulares de tarjetas más datos confidenciales de autenticación, como se detalla a continuación:

Los datos de titulares de tarjetas incluyen: Los datos confidenciales de autenticación incluyen:

• Número de cuenta principal (PAN) • Nombre del titular de la tarjeta • Fecha de vencimiento • Código de servicio

• Todos los datos de la banda magnética o datos equivalentes que están en un chip

• CAV2/CVC2/CVV2/CID • PIN/Bloqueos de PIN

El número de cuenta principal es el factor que defi ne la aplicabilidad de los requisitos de las PCI DS S. Los requisitos de las PCI DSS se aplican si se almacena, procesa o transmite un número de cuenta principal (PAN). Si un PAN no se almacena ni procesa ni transmite, no se aplican los requisitos de las PCI DSS.

Si el nombre del titular de la tarjeta, el código de servicio y/o la fecha de vencimiento no se almacenan ni procesan ni transmiten con el PAN, ni están presentes de alguna otra manera en el entorno de datos del titular de la tarjeta, se deben proteger de acuerdo con todos los requisitos de las PCI DSS, a excepción de los Requisitos 3.3 y 3.4, que sólo se aplican al PAN.

Las PCI DSS representan un conjunto mínimo de objetivos de control que puede ser reforzado con leyes y regulaciones locales, regionales y sectoriales. Además, la legislación o las regulaciones pueden requerir protección específica de la información de identificación personal u otros elementos de datos (por ejemplo, el nombre del titular de la tarjeta), o definir las prácticas de divulgación de una entidad en lo que respecta a las información de los consumidores. Entre los ejemplos está la legislación relacionada con la protección de los datos de los consumidores, la privacidad, el robo de identidad o la seguridad de los datos. Las PCI DSS no sustituyen las leyes locales ni regionales, las regulaciones del gobierno ni otros requisitos legales.

La siguiente tabla ilustra los elementos de los datos de titulares de tarjetas y los datos confidenciales de autenticación que habitualmente se utilizan; independientemente de que esté permitido o prohibido el almacenamiento de dichos datos y de que esos datos deban estar protegidos . Esta tabla no pretende ser exhaustiva, pero se proporciona con el fin de ilustrar distintos tipos de requisitos que se le aplican a cada elemento de datos.


Elemento de datos

Almacenamiento permitido

Hace que los datos de la cuenta almacenados no se

puedan leer según el Requisito 3.4

Número de cuenta principal (PAN)

Sí Sí

Nombre del titular de la tarjeta Sí No

Código de servicio Sí No

Datos del titular de la

tarjeta

Fecha de vencimiento Sí No

Datos completos de la banda magnética 2

No No se pueden almacenar

según el Requisito 3.2

CAV2/CVC2/CVV2/CID No No se pueden almacenar

según el Requisito 3.2

Dat

os d

e la

cue

nta

Datos confidenciales

de autenticación

1 PIN/Bloqueo de PIN No

No se pueden almacenar según el Requisito 3.2

Los Requisitos 3.3 y 3.4 de las PCI DSS sólo se aplican al PAN. Si el PAN se almacena con otros elementos de los datos del titular de la tarjeta, únicamente el PAN debe ser ilegible de acuerdo con el Requisito 3.4 de las PCI DSS.

Las PCI DSS sólo se aplican si los PAN se almacenan, procesan y/o transmiten.

1 No se deben almacenar los datos confidenciales de autenticación después de la autorización (incluso si están cifrados). 2 Contenido completo de la pista de banda magnética, datos equivalentes que están en el chip o en cualquier otro dispositivo.


Ubicación de datos de titulares de tarjetas y de da tos confidenciales de autenticación Los datos confidenciales de autenticación constan de los datos de la banda magnética (o pista)3, código o valor de validación de la tarjeta4, y datos del PIN5. ¡Se prohíbe el almacenamiento de datos confidencial es de autenticación! Estos datos son muy valiosos para las personas malintencionadas, ya que les permiten generar tarjetas de pago falsas y crear transacciones fraudulentas. Consulte el Glosario de términos, abreviaturas y acrónimos de las PCI DSS y PA-DSS para obtener la definición completa de “datos confidenciales de autenticación”. Las siguientes fotografías del reverso y el frente de una tarjeta de crédito muestran la ubicación de los datos del titular de la tarjeta y los datos confidenciales de autenticación.

Nota: El chip contiene datos de pista equivalentes, así como también otros datos confidenciales, incluido el valor de verificación de la tarjeta en el chip de circuitos integrados (IC), que también se conoce como Chip CVC, iCVV, CAV3 o iCSC).

3 Datos codificados en la banda magnética utilizada para la autorización durante una transacción con tarjeta presente. Estos datos también se pueden encontrar en un chip, o en

cualquier otra parte de la tarjeta. Es posible que las entidades no retengan todos los datos de banda magnética después de la autorización de la transacción. Los únicos elementos de datos de pistas que se pueden retener son: el número de cuenta principal, el nombre del titular de la tarjeta, la fecha de vencimiento y el código de servicio.

4 El valor de tres o cuatro dígitos impreso sobre o a la derecha del panel de firma, o en el frente de una tarjeta de pago, que se utiliza para verificar las transacciones sin tarjeta presente.

5 El número de identificación personal ingresado por el titular de la tarjeta durante una transacción con tarjeta presente y/o el bloqueo de PIN cifrado presente en el mensaje de la transacción.


Datos de la pista 1 vs. pista 2

Si los datos de la pista completa (ya sea la pista 1 o pista 2, de la banda magnética, la imagen de la banda magnética en un chip o en cualquier otro lugar) se almacenan, es posible que las personas malintencionadas que obtengan los datos, los reproduzcan y vendan tarjetas de pago en todo el mundo. El almacenamiento de todos los datos de la pista también viola las regulaciones operativas de las marcas de pago y puede acarrear multas y sanciones. La ilustración de abajo proporciona información sobre los datos de la Pista 1 y Pista 2 al describir las diferencias y mostrar el diseño de los datos según se almacenan en la banda magnética.

Pista 1 Pista 2

� Contiene todos los campos de la pista 1 y pista 2

� Longitud de hasta 79 caracteres

� Menor tiempo de procesamiento en el caso de transmisiones de dial-up anteriores

� Longitud de hasta 40 caracteres

Nota : El emisor de la tarjeta y/o la marca de la tarjeta de pago definen los campos de Datos discrecionales. Los campos definidos por el agente emisor que contienen datos que el agente emisor/marca de pago considere datos confidenciales de autenticación pudieran estar incluidos en la porción de datos discrecionales de la pista, y pudiera ser posible almacenar estos datos particulares bajo circunstancias y condiciones específicas, tal como lo defina el agente emisor/marca de la tarjeta de pago.

Sin embargo, ningún dato considerado dato confidencial de autenticación se puede almacenar después de la autorización, independientemente de si se encuentran en un campo de datos discrecionales o cualquier otro lugar.


Guía relacionada por las Normas de Seguridad de Dat os de la PCI

Desarrollar y mantener una red segura

Requisito 1: Instalar y mantener una configuración de firewall para proteger los datos del titular de la tarjeta

Requisito 2: No utilizar contraseñas de sistemas y otros parámetros de seguridad provistos por los proveedores

Proteger los datos del titular de la tarjeta

Requisito 3: Proteger los datos del titular de la tarjeta que fueron almacenados

Requisito 4: Cifrar la transmisión de los datos del titular de la tarjeta en las redes públicas abiertas

Mantener un programa de administración de vulnerabi lidad

Requisito 5: Utilizar y actualizar con regularidad los programas o software antivirus

Requisito 6: Desarrollar y mantener sistemas y aplicaciones seguras

Implementar medidas sólidas de control de acceso

Requisito 7: Restringir el acceso a los datos de titulares de tarjetas según la necesidad del negocio

Requisito 8: Asignar una ID exclusiva a cada persona que tenga acceso por computadora

Requisito 9: Restringir el acceso físico a los datos del titular de la tarjeta

Supervisar y evaluar las redes con regularidad

Requisito 10: Rastrear y supervisar todos los accesos a los recursos de red y a los datos de los titulares de tarjetas

Requisito 11: Probar periódicamente los sistemas y procesos de seguridad

Mantener una política de seguridad de información

Requisito 12: Mantener una política que aborde la seguridad de la información para todo el personal


Guía para los Requisitos 1 y 2: Desarrollar y mante ner una red segura

Requisito 1: Instalar y mantener una configuración de firewall para proteger los datos del titular de la tarjeta

Los firewalls son dispositivos que controlan el tráfico computarizado entre las redes (internas) y las redes no confiables (externas) de una entidad, así como el tráfico de entrada y salida a áreas más sensibles dentro de las redes internas confidenciales de una entidad. El entorno del titular de la tarjeta es un ejemplo de un área más confidencial dentro de la red confiable de una entidad.

El firewall examina todo el tráfico de la red y bloquea las transmisiones que no cumplen con los criterios de seguridad especificados.

Todos los sistemas debe estar protegidos contra el acceso no autorizado desde redes no confiables, ya sea que ingresen al sistema a través de Internet como comercio electrónico, del acceso a Internet desde las computadoras de mesa de los empleados, del acceso al correo electrónico de los empleados, de conexiones dedicadas como conexiones entre negocios mediante redes inalámbricas o a través de otras fuentes. Con frecuencia, algunas vías de conexión hacia y desde redes no confiables aparentemente insignificantes pueden proporcionar un acceso sin protección a sistemas clave. Los firewalls son un mecanismo de protección esencial para cualquier red de computadores.

Otros componentes del sistema pueden funcionar como firewall, siempre y cuando reúnan los requisitos mínimos correspondientes a firewalls, según se especifica en el Requisito 1. En las áreas donde se utilizan otros componentes del sistema dentro del entorno de datos de los titulares de tarjetas a fin de proporcionar la funcionalidad de firewall, estos dispositivos se deben incluir dentro del alcance y la evaluación del Requisito 1.

Requisito Guía

1.1 Establezca normas de configuración para firewall y router que incluyan lo siguiente:

Los firewalls y los routers son componentes clave de la arquitectura que controla la entrada a y la salida de la red. Estos dispositivos son unidades de software o hardware que bloquean el acceso no deseado y administran el acceso autorizado hacia dentro y fuera de la red. Sin las políticas ni los procedimientos implementados para documentar la manera como el personal debe configurar los firewalls y los routers, un negocio podría perder fácilmente su primera línea de defensa en la protección de datos. Las políticas y los procedimientos ayudarán a asegurar que la primera línea de defensa de la organización en la protección de sus datos mantenga su solidez.

Los entornos virtuales donde los flujos de datos no transitan una red física se deben evaluar a fin de asegurar que se logró la segmentación de red apropiada.

1.1.1 Un proceso formal para aprobar y probar todos los cambios y las conexiones de red en la configuración de los firewalls y los routers

Una política y un proceso para aprobar y probar todas las conexiones y cambios de los firewalls y los routers ayudarán a prevenir problemas de seguridad causados por una configuración errónea de la red, del router o del firewall.

Los flujos de datos entre máquinas virtuales se deben incluir en la política y el proceso.


Requisito Guía

1.1.2 Un diagrama actualizado de la red con todas las conexiones que acceden a los datos de los titulares de tarjetas, incluida toda red inalámbrica

Los diagramas de la red permiten que la organización identifique la ubicación de todos sus dispositivos de red. Además, el diagrama de la red también se puede utilizar para relacionar el flujo de datos de titulares de tarjetas con la red y entre dispositivos individuales para entender en su totalidad el alcance del entorno de datos de los titulares de tarjetas. Sin los diagramas actuales de red y flujo de datos, es posible que se omitan los dispositivos que contienen datos de titulares de tarjetas y se excluyan accidentalmente de los controles de seguridad en capas implementados para las PCI DSS y, por lo tanto, se puedan comprometer.

Los diagramas de red y flujo de datos deben incluir componentes de sistemas virtuales y documentar los flujos de datos dentro del host.

1.1.3 Requisitos para tener un firewall en cada conexión a Internet y entre cualquier zona desmilitarizada (DMZ) y la zona de la red interna

El uso de un firewall en cada conexión entrante (y saliente) de la red permite a la organización supervisar y controlar el acceso hacia dentro y fuera, así como minimizar las posibilidades de que una persona malintencionada obtenga acceso a la red interna.

1.1.4 Descripción de grupos, roles y responsabilidades para una administración lógica de los componentes de la red

Esta descripción de los roles y la asignación de responsabilidad garantiza que alguien se responsabilice completamente por la seguridad de todos los componentes y sea consciente de su responsabilidad, y que se administren todos los dispositivos.

1.1.5 Documentación y justificación de negocio para la utilización de todos los servicios, protocolos y puertos permitidos, incluida la documentación de funciones de seguridad implementadas en aquellos protocolos que se consideran inseguros.

Entre los servicios, protocolos o puertos no seguros se incluyen, a modo de ejemplo, FTP, Telnet, POP3, IMAP y SNMP.

Con frecuencia se producen exposiciones debido a que los servicios y puertos no se utilizan o no son seguros, ya que éstos, por lo general, tienen vulnerabilidades conocidas y muchas organizaciones son vulnerables a estos tipos de exposición porque no implementan parches de seguridad para vulnerabilidades de los servicios, protocolos y puertos que no se utilizan (incluso estando presentes las vulnerabilidades). Cada organización debe decidir con claridad cuáles servicios, protocolos y puertos son necesarios para su negocio, documentarlos para sus registros y asegurar que se inhabiliten o eliminen el resto de los servicios, protocolos y puertos. Además, las organizaciones deben considerar bloquear todo el tráfico y sólo volver a abrir esos puertos una vez que se haya determinado o documentado una necesidad.

Adicionalmente, hay numerosos servicios, protocolos o puertos que pudiera necesitar un negocio (o tener habilitados por opción predeterminada) que utilizan habitualmente las personas malintencionadas para comprometer una red. Si estos servicios, protocolos o puertos no seguros son necesarios para el negocio, la organización debe entender y aceptar el riesgo que plantea el uso de estos protocolos, además, se debe justificar el uso del protocolo, así como documentar e implementar las funciones de seguridad que permiten utilizar estos protocolos de manera segura. Si estos servicios, protocolos o puertos no seguros no son necesarios para el negocio, se deben inhabilitar o eliminar.


Requisito Guía

1.1.6 Requisito de la revisión de las normas del firewall y el router, al menos, cada seis meses

Esta revisión brinda a la organización la oportunidad de deshacerse de todas las reglas innecesarias, desactualizadas o incorrectas por lo menos cada seis meses y de asegurar que todos los conjuntos de reglas otorguen permiso sólo a los servicios y puertos autorizados que coincidan con las justificaciones del negocio.

Es recomendable aplicar estas revisiones más frecuentemente; por ejemplo, mensualmente, a fin de asegurar que los conjuntos de reglas estén actualizados y coincidan con las necesidades del negocio sin tener que abrir agujeros de seguridad ni correr riesgos innecesarios.

1.2 Desarrolle configuraciones para firewalls y routers que restrinjan las conexiones entre redes no confiables y todo componente del sistema en el entorno de los datos del titular de la tarjeta.

Nota: Una “red no confiable” es toda red que es externa a las redes que pertenecen a la entidad en evaluación y/o que excede la capacidad de control o administración de la entidad.

Es fundamental instalar protección para la red; es decir, un componente de sistema con (como mínimo) capacidad de firewall de inspección completa, entre la red interna confiable y otra red no confiable que sea externa y/o fuera de la capacidad de control y administración de la entidad. No implementar esta medida correctamente significa que la entidad estará expuesta al acceso no autorizado por parte de personas malintencionadas o un software malintencionado.

Si se instala la funcionalidad de firewall, pero no tiene reglas que controlen o restrinjan el tráfico, es posible que las personas malintencionadas sean capaces de utilizar técnicas de exploit para detectar vulnerabilidades de protocolos y puertos con el fin de atacar su red.

1.2.1 Restrinja el tráfico entrante y saliente a la cantidad que sea necesaria en el entorno de datos del titular de la tarjeta.

Este requisito busca impedir que personas malintencionadas accedan a la red de la organización a través de direcciones IP no autorizadas o que se utilicen servicios, protocolos o puertos sin autorización (por ejemplo, para enviar datos que se hayan obtenido mientras salían de su red hacia un servidor no confiable).

Todos los firmales deben incluir una regla que rechace todo el tráfico entrante y saliente cuya necesidad no se haya especifico. Esto evitará todos los agujeros inadvertidos que garantizarían la entrada y salida de tráfico fortuito y potencialmente peligroso.

1.2.2 Asegure y sincronice los archivos de configuración de routers.

Si bien los archivos de configuración en ejecución por lo general se implementan con parámetros de configuración seguros, los archivos de inicio (los cuales los routers ejecutan sólo al inicio) pueden no implementarse con los mismos parámetros de configuración seguros, debido a que estos archivos sólo se ejecutan ocasionalmente. Cuando un router realiza un reinicio sin los mismos parámetros de configuración seguros que tienen los archivos de configuración en ejecución, pueden producirse reglas más débiles que permitan que personas malintencionadas accedan a la red, debido a que es posible que los archivos de inicio no se hayan implementado con los mismos parámetros de configuración seguros que los archivos de configuración en ejecución.


Requisito Guía

1.2.3 Instale firewalls de perímetro entre las redes inalámbricas y el entorno de datos del titular de la tarjeta y configure estos firewalls para negar o controlar (en caso de que ese tráfico fuera necesario para fines de negocio) todo tráfico desde el entorno inalámbrico hacia el entorno del titular de la tarjeta.

La implementación y explotación conocida (o desconocida) de tecnología inalámbrica dentro de una red constituyen una ruta común para que personas malintencionadas obtengan acceso a la red y a datos de titulares de tarjetas. Si un dispositivo inalámbrico o una red inalámbrica se instala sin el conocimiento de la empresa, una persona malintencionada podría ingresar fácilmente y sin ser vista a la red. Si los firewalls no restringen el acceso al entorno de tarjetas de pago desde las redes inalámbricas, las personas malintencionadas que obtengan acceso no autorizado a la red inalámbrica se pueden conectar fácilmente al entorno de tarjetas de pago y comprometer la información de cuentas.

Se deben instalar firewalls entre las redes inalámbricas y el CDE, independientemente del propósito del entorno al que esté conectado la red inalámbrica. Esto puede incluir, a modo de ejemplo, redes corporativas, comercios, almacenes, etc.

1.3 Prohíba el acceso directo público entre Internet y todo componente del sistema en el entorno de datos de los titulares de tarjetas.

El objetivo de un firewall es administrar y controlar todas las conexiones entre los sistemas públicos y los sistemas internos (especialmente aquellos que almacenan, procesan o transmiten datos de titulares de tarjetas). Si se permite el acceso directo entre sistemas públicos y el CDE, se burlan las protecciones que ofrece el firewall, y se pueden comprometer los componentes del sistema que almacenan datos de titulares de tarjetas.

1.3.1 Implemente un DMZ para limitar el tráfico entrante sólo a aquellos componentes del sistema que proporcionan servicios, protocolos y puertos con acceso público autorizado.

El DMZ se refiere a la porción de la red que administra las conexiones entre Internet (u otras redes no confiables) y los servicios internos que una organización necesita poner a la disposición del público (como un servidor web). Es la primera línea de defensa para aislar y separar el tráfico que necesita comunicarse con la red interna del tráfico que no lo necesita.

El objetivo de esta funcionalidad es impedir que personas malintencionadas accedan a la red de la organización a través de direcciones IP no autorizadas o que se utilicen servicios, protocolos o puertos sin autorización.

1.3.2 Restrinja el tráfico entrante de Internet a las direcciones IP dentro del DMZ.

La terminación de conexiones IP en el DMZ brinda la oportunidad de inspeccionar y limitar la fuente/destino y/o la inspección/bloqueo de contenido, con lo cual se evita el acceso no filtrado entre entornos confiables y no confiables.

1.3.3 No permita ninguna conexión directa de entrada o salida de tráfico entre Internet y el entorno del titular de la tarjeta.

La terminación de conexiones IP tanto entrantes como salientes brinda la oportunidad de inspeccionar y limitar la fuente/destino y/o la inspección/bloqueo de contenido, con lo cual se evita el acceso no filtrado entre entornos confiables y no confiables. Esto ayuda a evitar; por ejemplo, que personas malintencionadas envíen los datos obtenidos mientras salían de su red hacia un servidor externo no confiable en una red no confiable.


Requisito Guía

1.3.4 No permita que las direcciones internas pasen desde Internet al DMZ.

Normalmente, un paquete contiene la dirección IP de la computadora desde la cual se envío. Esto permite que otras computadoras en la red sepan el origen del paquete. En algunos casos, las personas malintencionadas suplantarán la dirección IP que se envía.

Por ejemplo, las personas malintencionadas envían un paquete con una dirección suplantada, de modo que (a menos que su firewall lo prohíba) el paquete pueda ingresar en su red desde Internet haciéndose pasar por su tráfico interno y, por lo tanto, legítimo. Una vez que la persona malintencionada haya ingresado en su red, ésta puede empezar a comprometer su sistema.

El filtrado de ingreso es una técnica que se puede utilizar en el firewall para filtrar paquetes que entran a su red para, entre otras opciones, asegurar que los paquetes no se “suplanten” para que parezcan que provienen de su propia red interna.

Para obtener más detalles sobre el filtrado de paquetes, considere obtener información sobre una técnica corolario llamada “filtrado de egreso”.

1.3.5 No permita que llegue tráfico saliente no autorizado proveniente del entorno de datos del titular de la tarjeta a Internet.

Todo el tráfico saliente desde el entorno de datos de titulares de tarjetas se debe evaluar para asegurar que dicho tráfico sigue las reglas establecidas y autorizadas. Las conexiones se deben inspeccionar a fin de limitar el tráfico sólo a las comunicaciones autorizadas (por ejemplo, al limitar direcciones/puertos de origen/destino y/o bloquear contenido).

Cuando la conectividad entrante de los entornos no está permitida, las conexiones salientes se pueden realizar a través de arquitecturas o componentes de sistemas que interrumpen e inspeccionan la conectividad IP.

1.3.6 Implemente la inspección completa, también conocida como filtrado dinámico de paquetes. (Es decir, sólo se permite la entrada a la red de conexiones “establecidas”).

Un firewall que realiza una inspección de paquete de estado mantiene el "estado" de cada conexión al firewall. Al mantener el "estado", el firewall sabe si lo que parece ser una respuesta a una conexión anterior es realmente una respuesta (ya que "recuerda" la conexión anterior) o si es una persona malintencionada o software malintencionado intentando suplantar o engañar el firewall para que permita la conexión.

1.3.7 Coloque los componentes del sistema que almacenan datos de titulares de tarjetas (como una base de datos) en una zona de red interna, segregada desde un DMZ y otras redes no confiables.

Los datos de los titulares de tarjetas requieren la protección de información de más alto nivel. Si los datos de los titulares de tarjetas se encuentran en el DMZ, el acceso a esta información es más fácil para un atacante externo, ya que hay menos capas que penetrar.

Nota: el objetivo de este requisito no incluye el almacenamiento en una memoria volátil.


Requisito Guía

1.3.8 No divulgue direcciones IP privadas ni información de enrutamiento a partes no autorizadas.

Nota : Entre los métodos para ocultar direcciones IP se pueden incluir, a modo de ejemplo:

� Traducción de Dirección de Red (NAT)

� Ubicar servidores que contengan datos de titulares de tarjetas detrás de servidores proxy/firewalls o cachés de contenido,

� Eliminación o filtrado de anuncios de enrutamiento para redes privadas que emplean direcciones registradas,

� Uso interno del espacio de direcciones RFC1918 en lugar de direcciones registradas.

Restringir la difusión de direcciones IP es esencial para evitar que un hacker adquiera las direcciones IP de la red interna y utilice esa información para acceder a la red.

Los medios efectivos para cumplir con el objetivo de este requisito puede variar dependiendo de la tecnología de red específica utilizada en su entorno. Por ejemplo, los controles utilizados para cumplir con este requisito en el caso de las redes IPv4 difieren de los de las redes IPv6.

Una técnica para evitar que se descubran las direcciones IP en una red IPv4 es implementar la Traducción de Dirección de Red (NAT). NAT, que generalmente administra el firewall, permite que una organización tenga direcciones internas que sólo son visibles dentro de la red y direcciones externas que sólo son visibles fuera de la red. Si un firewall no “oculta” o enmascara las direcciones IP de la red interna, una persona malintencionada podría descubrirlas e intentar acceder a la red con una dirección IP suplantada.

En el caso de las redes IPv4, el espacio de direcciones RFC1918 está reservado para direcciones internas y no se debería poder enrutar en Internet. Por tal motivo, es preferible para las direcciones IP de redes internas. Sin embargo, las organizaciones pueden tener razones para utilizar un espacio de direcciones que no sea RFC1918 en la red interna. En estas circunstancias, la prevención de anuncios de enrutamiento u otras técnicas se deben utilizar para evitar que se difunda el espacio de direcciones internas o se divulgue a partes no autorizadas.

1.4 Instale software de firewall personal en toda computadora móvil o de propiedad de los trabajadores con conectividad directa a Internet (por ejemplo, laptops que usan los trabajadores), mediante las cuales se accede a la red de la organización.

Si una computadora no tiene instalado un firewall o programa antivirus, es posible que se descarguen o instalen inadvertidamente spyware, troyanos, virus, gusanos y rootkits (malware). La computadora es incluso más vulnerable cuando se conecta directamente a Internet y no a través de un firewall corporativo. Los malware que se cargan en una computadora cuando la conexión no se realiza a través del firewall corporativo pueden localizar información de manera mal intencionada dentro de la red cuando la computadora se vuelva a conectar a la red corporativa.

Nota: El objetivo de este requisito se aplica a las computadoras con acceso remoto, independientemente de si pertenecen a los empleados o la empresa. Los sistemas que la política corporativa no puede administrar introducen debilidades en el perímetro y brindan oportunidades que las personas malintencionadas pueden explotar.


Requisito 2: No usar los valores predeterminados su ministrados por el proveedor para las contraseñas d el sistema y otros parámetros de seguridad

Las personas malintencionadas (externas e internas a una entidad), por lo general, utilizan las contraseñas predeterminadas por los proveedores y otros parámetros que el proveedor predetermine para comprometer los sistemas. Estas contraseñas y parámetros son conocidos entre las comunidades de hackers y se establecen fácilmente por medio de información pública.

Requisito Guía

2.1 Siempre cambie los valores predeterminados de los proveedores antes de instalar un sistema en la red, incluidas, a modo de ejemplo, contraseñas, cadenas comunitarias de protocolo simple de administración de red (SNMP) y la eliminación de cuentas innecesarias.

Las personas malintencionadas (externas e internas a la empresa), por lo general, utilizan contraseñas predeterminadas por los proveedores, nombres de cuentas y contraseñas para comprometer sistemas. Estos parámetros de configuración son bien conocidos dentro de las comunidades de hackers y dejan a su sistema sumamente vulnerable a ataques.

2.1.1 En el caso de entornos inalámbricos que están conectados al entorno de datos del titular de la tarjeta o que transmiten datos del titular de la tarjeta, cambie los valores predeterminados proporcionados por los proveedores, incluidas, a modo de ejemplo, claves de cifrado inalámbricas predeterminadas, contraseñas y cadenas comunitarias SNMP.

Muchos usuarios instalan estos dispositivos sin aprobación de la gerencia y no cambian los parámetros predeterminados ni configuran parámetros de seguridad. Si las redes inalámbricas no se implementan con suficientes configuraciones de seguridad (incluido el cambio de los parámetros predeterminados), los sniffers inalámbricos pueden espiar el tráfico, capturar datos y contraseñas de manera sencilla e ingresar en su red y atacarla fácilmente. Además, el protocolo de intercambio de claves de la versión anterior de cifrado 802.11x (WEP) ha sido transgredido y puede inutilizar el cifardo. Verifique que el firmware de los dispositivos esté actualizado para admitir protocolos más seguros (por ejemplo, WPA2).

2.2 Desarrolle normas de configuración para todos los componentes de sistemas. Asegúrese de que estas normas contemplen todas las vulnerabilidades de seguridad conocidas y que concuerden con las normas de alta seguridad de sistema aceptadas en la industria.

Entre las fuentes de normas de alta seguridad aceptadas en la industria, se pueden incluir, a modo de ejemplo:

� Center for Internet Security (CIS)

� International Organization for Standardization (ISO)

� SysAdmin Audit Network Security (SANS)

� National Institute of Standards Technology (NIST)

Existen debilidades conocidas en muchos sistemas operativos, bases de datos y aplicaciones de empresas, así como también existen maneras de configurar estos sistemas a fin de corregir las vulnerabilidades de seguridad. Con la finalidad de ayudar a quienes no son expertos en seguridad, las organizaciones especializadas han establecido recomendaciones para fortalecer los sistemas, las cuales proporcionan consejos para corregir estas debilidades. Si no se eliminan estas debilidades de los sistemas; por ejemplo, una configuración de archivos débil o servicios y protocolos predeterminados (para los servicios o protocolos que generalmente no son necesarios), un atacante estará en capacidad de aplicar técnicas o programas conocidos para atacar servicios y protocolos vulnerables y, de esta manera, obtener acceso a la red de su organización. Entre los sitios web donde puede obtener más información sobre las mejores prácticas de la industria que contribuyen a la implementación de normas de configuración se encuentran: www.nist.gov, www.sans.org, www.cisecurity.org, www.iso.org.

Las normas de configuración de sistemas también se deben mantener actualizadas a fin de asegurar que las debilidades recientemente identificadas se corrijan antes de instalar un sistema en la red.


Requisito Guía

2.2.1 Implemente sólo una función principal por servidor a fin de evitar que coexistan funciones que requieren diferentes niveles de seguridad en el mismo servidor. (Por ejemplo, los servidores web, servidores de base de datos y DNS se deben implementar en servidores separados).

Nota: Cuando se utilicen tecnologías de virtualización, implemente sólo una función principal por componente de sistema virtual.

El objetivo de esto es asegurar las normas de configuración de sistemas y los procesos relacionados de su organización que tratan las funciones de los servidores que necesitan tener diferentes niveles de seguridad, o que pudieran introducir debilidades de seguridad en otras funciones del mismo servidor. Por ejemplo:

1. Una base de datos, que necesite tener medidas de seguridad sólidas implementadas, correría riesgos si comparte un servidor con una aplicación web, que deba permanecer abierta y estar en contacto directo con Internet.

2. Si no se aplica un parche a una función aparentemente insignificante, es posible que se comprometan otras funciones más importantes (como una base de datos) del mismo servidor.

Este requisito se aplica a todos los servidores dentro del entorno de datos de titulares de tarjetas (usualmente basados en Unix, Linux o Windows). Este requisito no se aplica a sistemas que tengan la capacidad de implementar niveles de seguridad de manera nativa en un mismo servidor (por ejemplo, un mainframe).

Donde se utilicen tecnologías de virtualización, cada componente virtual (por ejemplo, una máquina virtual, un switch virtual, un dispositivo de seguridad virtual, etc.) se debe considerar como un límite del “servidor”. Cada hipervisor puede admitir diferentes funciones, pero una máquina virtual individual debe acatar la regla de una “sola función principal”. Según este supuesto, si se compromete el hipervisor, se podrían comprometer todas las funciones del sistema. En consecuencia, también se debe tomar en consideración el nivel de riesgo cuando se colocan múltiples funciones o componentes en un mismo sistema físico.

2.2.2 Habilite sólo los servicios, protocolos, daemons, etc. necesarios y seguros, según lo requiera la función del sistema.

Implemente funciones de seguridad para los servicios, protocolos o daemons requeridos que no se consideren seguros. Por ejemplo, utilice tecnologías aseguradas, tales como SSH, S-FTP, SSL o IPSec VPN, para proteger servicios no seguros como NetBIOS, archivos compartidos, Telnet, FTP, etc.

Tal como lo especifica el Requisito 1.1.5, existen numerosos protocolos que un negocio puede necesitar (o tener habilitados por opción predeterminada) que habitualmente utilizan personas malintencionadas para comprometer una red. A fin de asegurar que los servicios y protocolos necesarios estén habilitados y que todos los servicios y protocolos no seguros se aseguren correctamente antes de implementar los nuevos servidores, este requisito debe formar parte de las normas de configuración y procesos relacionados de su organización.

2.2.3 Configure los parámetros de seguridad del sistema para evitar el uso indebido.

El objetivo de esto es asegurar que las normas de configuración de sistemas y los procesos relacionados de su organización traten específicamente los valores de configuración y parámetros de seguridad que tienen implicaciones de seguridad conocidas.


Requisito Guía

2.2.4 Elimine todas las funcionalidades innecesarias, tales como secuencias de comandos, drivers, funciones, subsistemas, sistemas de archivos y servidores web innecesarios.

Las normas para fortalecer servidores deben incluir procesos para tratar una funcionalidad innecesaria con implicaciones de seguridad específicas (como eliminar/inhabilitar FTP o el servidor web si el servidor no realizará estas funciones).

2.3 Cifre todo el acceso administrativo que no sea de consola utilizando un cifrado sólido. Utilice tecnologías como SSH, VPN o SSL/TLS para la administración basada en la web y el acceso administrativo que no sea de consola.

Si la administración remota no se realiza con una autenticación segura y comunicaciones cifradas, la información confidencial a nivel administrativo u operativo (como las contraseñas del administrador) se pueden revelar a un espía. Una persona malintencionada podría utilizar esta información para acceder a la red, hacerse pasar por administrador y hurtar datos.

2.4 Los proveedores de servicio de hosting compartido deben proteger el entorno hospedado y los datos del titular de la tarjeta de la entidad. Estos proveedores deben cumplir requisitos específicos detallados en el Anexo A: Requisitos adicionales de las PCI DSS para los proveedores de servicios de hosting compartido.

Se concibió pensando en los proveedores de servicio de hosting que proporcionan entornos de hosting compartidos para múltiples clientes en el mismo servidor. Cuando todos los datos se encuentran en el mismo servidor y bajo el control de un solo entorno, con frecuencia los parámetros de configuración de estos servidores compartidos no pueden ser administrados por clientes individuales, permiten que los clientes agreguen funciones y secuencias de comandos no seguros que afectan la seguridad de todos los demás entornos; y, en consecuencia, ayudan a que personas malintencionadas comprometan los datos de un cliente y, por lo tanto, obtengan acceso a los datos de los demás clientes. Consulte el Anexo A:


Guía para los Requisitos 3 y 4: Proteja los datos d el titular de la tarjeta

Requisito 3: Proteja los datos del titular de la ta rjeta que fueron almacenados

Los métodos de protección como el cifrado, el truncamiento, el ocultamiento y la función de hash son importantes componentes para proteger los datos de los titulares de tarjetas. Si un intruso viola otros controles de seguridad y obtiene acceso a los datos cifrados, sin las claves de cifrado adecuadas, no podrá leer ni utilizar esos datos. Los otros métodos eficaces para proteger los datos almacenados deberían considerarse oportunidades para mitigar el riesgo posible. Por ejemplo, los métodos para minimizar el riesgo incluyen no almacenar datos de titulares de tarjetas salvo que sea absolutamente necesario, truncar los datos de titulares de tarjetas si no se necesita el PAN completo y no enviar el PAN utilizando tecnologías de mensajería de usuario final, tales como correos electrónicos y mensajería instantánea.

Consulte el Glosario de términos, abreviaturas y acrónimos de las PCI DSS para obtener definiciones de "cifrado sólido" y otros términos de las PCI DSS.

Requisito Guía

3.1 Almacene la menor cantidad posible de datos de titulares de tarjetas implementando políticas, procedimientos y procesos de retención y disposición de datos, como se indica abajo.

3.1.1 Implemente una política de retención y disposición de datos que incluya:

� Limitación del almacenamiento de datos y del tiempo de retención a la cantidad exigida por los requisitos legales, reglamentarios y del negocio

� Procesos para eliminar datos de manera cuando ya no se necesiten

� Requisitos de retención específicos para datos de titulares de tarjetas

� Un proceso automático o manual trimestral para identificar y eliminar de manera segura los datos de titulares de tarjetas almacenados que excedan los requisitos de retención definidos

Una política formal para la retención de datos identifica los datos que se deben retener, así como el lugar donde residen los datos, de modo que se puedan destruir o eliminar de manera segura una vez que ya no sean necesarios. A fin de definir los requisitos de retención apropiados, una entidad primero debe entender las necesidades de su negocio, así como cualesquiera obligaciones legales y regulatorias que se apliquen a su industria, y/o que se apliquen al tipo de dato que se retiene.

Un almacenamiento extenso de datos de titulares de tarjetas que exceda la necesidad del negocio crea un riesgo innecesario. Los únicos datos de titulares de tarjetas que se pueden almacenar después de la autorización son el número de cuenta principal o PAN (el cual debe ser ilegible), la fecha de vencimiento, el nombre del titular de la tarjeta y el código de servicio.

La implementación de métodos de eliminación seguros asegura que los datos no se puedan recuperar cuando ya no sean necesarios.

¡Recuerde, si no los necesita, no los almacene!


Requisito Guía

3.2 No almacene datos confidenciales de autenticación después de recibir la autorización (aun cuando estén cifrados).

Los datos confidenciales de autenticación incluyen los datos mencionados en los requisitos 3.2.1 a 3.2.3, establecidos a continuación:

Nota: Es posible que los emisores de tarjetas de pago y las empresas que respaldan los servicios de emisión almacenen datos confidenciales de autenticación si existe una justificación de negocio y los datos están almacenados de forma segura.

Los datos confidenciales de autenticación constan de los datos de la banda magnética (o pista)6, código o valor de validación de la tarjeta7, y datos del PIN8. ¡Se prohíbe el almacenamiento de datos confidenciales de autentic ación después de la autorización! Estos datos son muy valiosos para las personas malintencionadas, ya que les permiten generar tarjetas de pago falsas y crear transacciones fraudulentas. Consulte el Glosario de términos, abreviaturas y acrónimos de las PCI DSS y PA-DSS para obtener una definición exhaustiva de “datos confidenciales de autenticación”.

Nota: A las compañías que realizan, facilitan o respaldan servicios de emisión se les permite almacenar datos confidenciales de autenticación SÓLO SI tienen una necesidad de negocio legítima de almacenar dichos datos. Cabe señalar que todos los requisitos de las PCI DSS se aplican a los emisores, y que la única excepción para los emisores y procesadores emisores es que pueden retener datos si existe una razón legítima para hacerlo. Una razón legítima es que si es necesario para el desempeño de la función proporcionada por el emisor y no por conveniencia.

Dichos datos se deben almacenar de manera segura y de conformidad con las PCI DSS y los requisitos específicos de las marcas de pago.

6 Datos codificados en la banda magnética utilizada para la autorización durante una transacción con tarjeta presente. Estos datos también se pueden encontrar en un chip, o en

cualquier otra parte de la tarjeta. Las entidades no pueden retener todos los datos de la banda magnética después de la autorización de la transacción. Los únicos elementos de datos de pistas que se pueden retener son: el número de cuenta principal, el nombre del titular de la tarjeta, la fecha de vencimiento y el código de servicio.

7 El valor de tres o cuatro dígitos impreso sobre o a la derecha del panel de firma, o en el frente de una tarjeta de pago, que se utiliza para verificar las transacciones sin tarjeta presente. 8 El número de identificación personal ingresado por el titular de la tarjeta durante una transacción con tarjeta presente y/o el bloque de PIN cifrado presente en el mensaje de la transacción.


Requisito Guía

3.2.1 No almacene contenido completo de ninguna pista de la banda magnética (ubicada en el reverso de la tarjeta, datos equivalentes que están en un chip o en cualquier otro dispositivo). Estos datos se denominan alternativamente datos de pista completa, pista, pista 1, pista 2 y banda magnética.

Nota: En el transcurso normal de los negocios, es posible que se deban retener los siguientes elementos de datos de la banda magnética:

� El nombre del titular de la tarjeta � Número de cuenta principal (PAN) � Fecha de vencimiento � Código de servicio

Para minimizar el riesgo, almacene solamente los elementos de datos que sean necesarios para el negocio.

Si se almacenan datos de pista completa, las personas malintencionadas que obtengan esos datos pueden reproducir y vender tarjetas de pago.

3.2.2 No almacene el valor ni el código de validación de tarjetas (número de tres o cuatro dígitos impreso en el anverso o reverso de una tarjeta de pago) que se utiliza para verificar las transacciones de tarjetas ausentes.

El propósito del código de validación de las tarjetas es proteger las transacciones que se efectúan de manera no presencial, ya sean transacciones por Internet o correo/teléfono (MO/TO), en las que ni el consumidor ni la tarjeta están presentes. Estos tipos de transacción se pueden autenticar como provenientes del propietario de la tarjeta sólo al solicitar el código de validación, ya que el propietario de la tarjeta tiene la tarjeta en la mano y puede leer el valor. Si se almacenan estos datos prohibidos y luego los hurtan, las personas malintencionadas pueden efectuar transacciones por Internet y transacciones MO/TO fraudulentas.

3.2.3 No almacene el número de identificación personal (PIN) ni el bloqueo del PIN cifrado.

Sólo el propietario de la tarjeta o el banco emisor de la tarjeta deben conocer estos valores. Si se almacenan estos datos prohibidos y luego los hurtan, las personas malintencionadas pueden efectuar transacciones de débito basadas en PIN (por ejemplo, retiros de cajeros automáticos).


Requisito Guía

3.3 Oculte el PAN cuando aparezca (los primeros seis y los últimos cuatro dígitos es la cantidad máxima de dígitos que aparecerá).

Notas: � Este requisito no se aplica a trabajadores y a otras partes

que posean una necesidad de negocio legítima de conocer el PAN completo.

� Este requisito no reemplaza los requisitos más estrictos implementados para la presentación de los datos del titular de la tarjeta (por ejemplo, los recibos de puntos de venta [POS]).

La presentación de un PAN completo en pantallas de computadoras, recibos de tarjetas de pago, faxes o informes impresos puede facilitar la obtención y uso fraudulento de estos datos por parte de personas malintencionadas. El PAN se puede exhibir completamente en la “copia del comerciante”; sin embargo, los recibos impresos deben acatar los mismos requisitos de seguridad que las copias electrónicas y seguir las directrices de las Normas de Seguridad de Datos de la PCI, especialmente el Requisito 9, que trata la seguridad física. El PAN también se puede exhibir completamente a quienes tengan una necesidad de negocio legítima de ver el PAN completo.

Este requisito se relaciona con la protección del PAN que se muestra en pantallas, recibos impresos, etc., y no se debe confundir con el Requisito 3.4 para la protección del PAN cuando se almacena en archivos, bases de datos, etc.

3.4Haga que el PAN quede ilegible en cualquier lugar donde se almacene (incluidos los datos que se almacenen en medios digitales portátiles, en medios de copia de seguridad y en registros) utilizando cualquiera de los siguientes métodos:

� Valores hash de una vía basados en cifrado sólido (el hash debe ser de todo el PAN).

� Truncamiento (los valores hash no se pueden usar para reemplazar el segmento truncado del PAN)

� Tokens y ensambladores de índices (los ensambladores se deben almacenar de manera segura).

� Cifrado sólido con procesos y procedimientos de administración de claves relacionadas

Nota: Para una persona malintencionada sería relativamente fácil reconstruir el PAN original si tiene acceso tanto a la versión truncada como a la versión en valores hash de un PAN. Si el entorno de una entidad tiene versiones en valores hash y truncadas del mismo PAN, se deben implementar controles adicionales para asegurar que las versiones en valores hash y truncadas no se puedan correlacionar para reconstruir el PAN original.

La ausencia de protección de los PAN puede permitir que personas malintencionadas vean o descarguen estos datos. Todos los PAN guardados en un almacenamiento principal (bases de datos o archivos planos como archivos de texto y hojas de cálculo) y en almacenamiento secundario (copia de seguridad, registros de auditoría, registros de excepciones o soluciones de problemas) deben estar protegidos. Los daños causados a las cintas de copia de seguridad por robo o pérdida durante el transporte se puede reducir asegurando que los PAN sean ilegibles a través de cifrado, truncamiento o función de hash. Debido a que los registros de auditoría, soluciones de problemas y excepciones se deben retener, se puede prevenir la divulgación de los datos de registros haciendo ilegibles o eliminando los PAN de los registros.

Al correlacionar las versiones en valores hash o truncadas de un PAN determinado, una persona malintencionada puede derivar fácilmente el valor original del PAN. La aplicación de controles que ayuden a prevenir la correlación de estos datos ayudará a asegurar que el PAN original permanezca ilegible.

Consulte el Glosario de términos, abreviaturas y acrónimos de las PCI DSS y PA-DSS para obtener definiciones de “cifrado sólido”.


Requisito Guía

� Valores hash de una vía basados en cifrado sólido (el hash debe ser de todo el PAN).

Las funciones hash de una vía, tal como el Algoritmo de Hash Seguro (SHA) basado en cifrado sólido, se pueden utilizar para hacer que los datos de los titulares de tarjetas sean ilegibles. Las funciones hash son apropiadas cuando no existe necesidad de recuperar el número original (las funciones hash de una vía son irreversibles).

Para complicar la creación de tablas rainbow se recomienda, pero no es un requisito, que se introduzca un valor de sal en la función hash además del PAN.

� Truncamiento (los valores hash no se pueden usar para reemplazar el segmento truncado del PAN)

El objetivo del truncamiento es que sólo se almacene una porción (sin exceder los primeros seis y los últimos cuatro dígitos) del PAN. Esto es diferente en el enmascaramiento, donde todo el PAN se almacena, pero se enmascara cuando se muestra; es decir, sólo una parte del PAN aparece en pantallas, informes, recibos, etc.

Este requisito se relaciona con la protección del PAN cuando se almacena en archivos, bases de datos, etc., y no se debe confundir con el Requisito 3.3 para la protección del PAN cuando se muestra en pantallas, recibos impresos, etc.

� Tokens y ensambladores de índices (los ensambladores se deben almacenar de manera segura).

Los tokens y ensambladores de índices también se pueden utilizar para hacer que los datos de los titulares de tarjetas sean ilegibles. Un token de índice es un token de cifrado que reemplaza el PAN basándose en un índice determinado por un valor impredecible. Un ensamblador único es un sistema en el que una clave privada, la cual se genera aleatoriamente, sólo se utiliza una única vez para cifrar un mensaje que luego se descifra utilizando un ensamblador y una clave únicos que coincidan.

� Cifrado sólido con procesos y procedimientos de gestión de claves relacionadas.

El objetivo de un cifrado sólido (consulte la definición y las longitudes de las claves en el Glosario de términos, abreviaturas y acrónimos de las PCI DSS y PA-DSS) es que el cifrado se base en un algoritmo probado y aceptado por la industria (no un algoritmo de propiedad exclusiva ni desarrollado internamente).

3.4.1 Si se utiliza cifrado de disco (en lugar de un cifrado de base de datos por archivo o columna), se debe administrar un acceso lógico independientemente de los mecanismos de control de acceso del sistema operativo nativo (por ejemplo, no se deben utilizar bases de datos de cuentas de usuarios locales). Las claves de descifrado no deben estar vinculadas a cuentas de usuarios.

El objetivo de este requisito es tratar la aceptabilidad del cifrado de discos para hacer que los datos de los titulares de tarjetas sean ilegibles. El cifrado de discos cifra datos que se encuentran en el almacenamiento masivo de una computadora y descifra la información automáticamente cuando un usuario autorizado la solicita. Los sistemas de cifrado de discos interceptan las operaciones de lectura y escritura del sistema operativo y efectúan las transformaciones de cifrado apropiadas sin que el usuario realice acción especial alguna, salvo suministrar una contraseña al inicio de la sesión. Según estas características de cifrado de discos, a fin de cumplir con este requisito, el método de cifrado de discos no puede tener:

1) Una asociación directa con el sistema operativo, o

2) Claves de descifrado que estén asociadas con cuentas de usuario.


Requisito Guía

3.5 Proteja las claves utilizadas para asegurar los datos de los titulares de tarjeta contra divulgación o uso indebido.

Nota : Este requisito también se aplica a las claves de cifrado de claves utilizadas para proteger las claves de cifrado de datos; tales claves de cifrado de claves deben ser por lo menos tan sólidas como la clave de cifrado de datos.

Las claves de cifrado deben tener una sólida protección debido a que aquellos que obtiene acceso podrán descifrar datos. Las claves de cifrado de claves, si se utilizan, deben ser por lo menos tan sólidas como la clave de cifrado de datos a fin de asegurar la protección adecuada de la clave que cifra los datos así como de los datos cifrados con esa clave.

El requisito de proteger las claves de divulgación y uso indebido se aplica tanto a claves de cifrado de datos como a claves de cifrado de claves. Debido a una clave de cifrado de claves puede otorgar acceso a muchas claves de cifrado de datos, las claves de cifrado de claves requieren medidas de protección sólidas. Los métodos de almacenamiento seguro de claves de cifrado de claves incluyen, pero no se limitan a, módulos de seguridad de hardware (HSM) y alteración de almacenamiento evidente con control dual y conocimiento dividido.

3.5.1 Restrinja el acceso a las claves de cifrado al número mínimo de custodios necesarios.

Muy pocos deben tener acceso a claves de cifrado, usualmente sólo aquellos con responsabilidades de custodios.

3.5.2 Guarde las claves de cifrado de forma segura en la menor cantidad de ubicaciones y formas posibles.

Las claves de cifrado deben estar almacenadas de forma segura, usualmente cifradas con claves de cifrado de claves, y almacenadas en muy pocas ubicaciones. El objetivo no es que se cifren las claves de cifrado de claves; sin embargo, esas claves deben estar protegidas contra divulgación y uso indebido de conformidad con lo definido en el Requisito 3.5. El almacenamiento de claves de cifrado de claves en ubicaciones física y/o lógicamente separadas de las claves de cifrado de datos reduce el riesgo de acceso no autorizado a ambas claves.

3.6 Documente completamente e implemente todos los procesos y los procedimientos de gestión de claves de las claves de cifrado que se utilizan para el cifrado de datos de titulares de tarjetas, incluido lo siguiente:

Nota: Varias normas de la industria relativas a la administración de claves están disponibles en distintos recursos incluido NIST, que puede encontrar en http://csrc.nist.gov.

La manera en la cual se administran las claves de cifrado es una parte crítica de la continuidad de seguridad de la solución de cifrado. Un buen proceso de gestión de claves, bien sea manual o automatizado como parte del producto de cifrado, se basa en normas de la industria y trata todos los elementos clave en 3.6.1 hasta 3.6.8.

3.6.1 Generación de claves de cifrado sólido La solución de cifrado debe generar claves sólidas, de conformidad con lo definido en el Glosario de Términos, Abreviaturas y Acrónimos de las PCI DSS y PA-DSS en "cifrado sólido".

3.6.2 Distribución segura de claves de cifrado La solución de cifrado debe distribuir las claves de forma segura, lo que significa que las claves no se distribuyen en texto claro, y sólo a custodios identificados en 3.5.1.

3.6.3 Almacenamiento seguro de claves de cifrado La solución de cifrado debe almacenar claves de forma segura, lo que significa que las claves no se almacenan en texto claro (cífrelas con una clave de cifrado de claves).


Requisito Guía

3.6.4 La clave de cifrado cambia en el caso de las claves que han llegado al final de su período de cifrado (por ejemplo, después que haya transcurrido un período definido y/o después que cierta cantidad de texto cifrado haya sido producido por una clave dada), según lo defina el proveedor de la aplicación relacionada o el responsable de las claves, y basándose en las mejores prácticas y recomendaciones de la industria (por ejemplo, NIST Special Publication 800-57).

Un período de cifrado es el intervalo de tiempo durante el cual una clave de cifrado particular se puede utilizar para su propósito definido. Las consideraciones para definir el período de cifrado incluyen, pero sin limitarse a, la solidez del algoritmo subyacente, tamaño o longitud de la clave, peligro de riesgo de la clave y la confidencialidad de los datos cifrados.

Es imperativo cambiar periódicamente las claves de cifrado cuando están han llegado al final de su período de cifrado a fin de minimizar el riesgo de que alguien obtenga las claves de cifrado y pueda descifrar los datos.

Si son proporcionadas por un proveedor de la aplicación de cifrado, siga los proceso o recomendaciones de cambio periódico de claves indicados en los documentos del proveedor. El responsable o custodio designado de las claves también puede consultar las mejores prácticas de la industria en algoritmos critográficos y gestión de claves, por ejemplo NIST Special Publication 800-57, para obtener una guía sobre el período de cifrado apropiado para diferentes algoritmos y longitudes de clave.

La intención de este requisito se aplica a claves utilizadas para cifrar datos almacenados de los titulares de tarjetas, y cualquier clave respectiva de cifrado de claves.

3.6.5 Retiro o reemplazo de claves (por ejemplo, mediante archivo, destrucción y/o revocación) según se considere necesario cuando se haya debilitado la integridad de la clave (por ejemplo, salida de la empresa de un empleado con conocimiento de una clave en texto claro, etc.) o cuando se sospeche que las claves están en riesgo.

Nota : Si es necesario retener las claves de cifrado retiradas o reemplazadas, éstas se deben archivar de forma segura (por ejemplo, utilizando una clave de cifrado de claves). Las claves de cifrado archivadas se deben utilizar sólo con fines de descifrado/verificación.

Las claves antiguas que ya no se utilicen o necesiten se deben retirar y destruir para asegurar que ya no se puedan utilizar. Si es necesario mantener claves antiguas (para respaldar datos cifrados archivado, por ejemplo) deben tener protección sólida. (Consulte 3.6.6 a continuación.) La solución de cifrado también debe permitir y facilitar un proceso para reemplazar claves que se sepa, o se sospeche, estén en riesgo.

3.6.6 Si se utilizan operaciones manuales de gestión de claves de cifrado en texto claro, estas operaciones deben aplicar conocimiento dividido y control doble (por ejemplo, utilizando dos o tres personas, cada una de las cuales conoce su propia parte de la clave, para reconstruir toda la clave).

Nota: Los ejemplos de operaciones manuales de gestión de claves incluyen, entre otros: generación, transmisión, carga, almacenamiento y destrucción de claves.

El conocimiento dividido y control doble de claves se utiliza para eliminar la posibilidad de que una persona tenga acceso a toda la clave. Este control es aplicable para operaciones manuales de gestión de claves, o donde la gestión de claves no haya sido implementada por el producto de cifrado.


Requisito Guía

3.6.7 Prevención de sustitución no autorizada de claves de cifrado.

La solución de cifrado no debe permitir ni aceptar la sustitución de claves por parte de fuentes no autorizadas o procesos inesperados.

3.6.8 Requisito de que los custodios de claves de cifrado declaren formalmente que comprenden y aceptan su responsabilidad como custodios de las claves.

Este proceso asegurará que los individuos que actúan como custodios de las claves se comprometen con el rol de custodio de claves y comprenden las responsabilidades.


Requisito 4: Cifrar la transmisión de los datos del titular de la tarjeta en las redes públicas abiert as.

La información confidencial se debe cifrar durante su transmisión a través de redes a las que delincuentes puedan acceder fácilmente. Las redes inalámbricas mal configuradas y las vulnerabilidades en cifrados herederos y protocolos de autenticación siguen siendo los objetivos de delincuentes que explotan estas vulnerabilidades a los efectos de acceder a los entornos de datos de los titulares de las tarjetas.

Requisito Guía

4.1 Utilice cifrado sólido y protocolos de seguridad (por ejemplo, SSL/TLS, IPSec, SSH, etc.) para proteger datos confidenciales del titular de la tarjeta durante la transmisión por redes públicas abiertas. Ejemplos de redes públicas abiertas que se encuentran dentro del alcance de las PCI DSS incluyen, pero sin limitarse a:

� La Internet

� Tecnologías inalámbricas

� Sistema global para comunicaciones móviles (GSM)

� Servicio de radio paquete general (GPRS)

La información confidencial debe estar cifrada durante la transmisión en redes públicas, porque es fácil y común para una persona malintencionada interceptar y/o desviar datos mientras están en tránsito.

Por ejemplo, el Protocolo de Capa de Conexión Segura (SSL) cifra páginas web y los datos ingresados en ellas. Cuando utilice sitios web asegurados con SSL, asegúrese de que “https” forme parte del URL.

Tenga en cuenta que algunas implementaciones de protocolo (tales como SSL versión 2.0 y SSH versión 1.0) tienen vulnerabilidades documentadas, como desbordamientos de buffer, que un atacante puede utilizar para obtener el control del sistema afectado. Independientemente del protocolo de seguridad utilizado, asegúrese de que esté configurado para utilizar sólo configuraciones y versiones seguras para impedir el uso de una conexión insegura.


Requisito Guía

4.1.1 Asegúrese de que las redes inalámbricas que transmiten datos de los titulares de las tarjetas o que están conectadas al entorno de datos del titular de la tarjeta utilizan las mejores prácticas de la industria (por ejemplo, IEEE 802.11i) a los efectos de implementar cifrados sólidos para la autenticación y transmisión.

Nota : La utilización de WEP como control de seguridad está prohibido a partir del 30 de junio de 2010.

Usuarios maliciosos pueden utilizar herramientas gratis y disponibles a gran escala para espiar comunicaciones inalámbricas. El uso de cifrado sólido puede limitar la divulgación de información confidencial en la red. Muchos de los riesgos conocidos de datos de titulares de tarjetas almacenados sólo en la red de cable se originaron cuando un usuario malicioso expandió el acceso desde una red inalámbrica insegura. Algunos ejemplos de implementaciones inalámbricas que requieren cifrado sólido incluyen, sin limitarse a, GPRS, GSM, WIFI, satélite y Bluetooth.

Se requiere cifrado sólido para autenticación y transmisión de datos del titular de la tarjeta a efectos de impedir que usuarios maliciosos obtengan acceso a la red inalámbrica—los datos en la red—o que utilicen las redes inalámbricas para acceder a otras redes internas u otros datos. Nunca se debe utilizar el cifrado WEP como el único medio de cifrado de datos en un canal inalámbrico ya que no se considera cifrado sólido, es vulnerable debido a vectores de inicialización débiles en el proceso de intercambio de claves WEP, y carece la rotación requerida de clave. Un atacante puede usar herramientas de craqueo de fuerza bruta, a las que se puede acceder de forma gratuita, para penetrar el cifrado WEP.

Los dispositivos inalámbricos actuales se deben actualizar (ejemplo: actualizar el firmware del punto de acceso a WPA2) para respaldar el cifrado sólido. Si los dispositivos actuales no se pueden actualizar, se debe adquirir equipo nuevo o se deben implementar otros controles de compensación para proporcionar cifrado sólido.

4.2 Nunca debe enviar PAN no cifrados por medio de tecnologías de mensajería de usuario final (por ejemplo, el correo electrónico, la mensajería instantánea, el chat, etc.).

El correo electrónico, la mensajería instantánea y el chat se pueden interceptar fácilmente mediante detectores de paquetes durante la exposición completa de la entrega en redes internas y públicas. No utilice estas herramientas de mensajería para enviar PAN a menos que proporcionen cifrado sólido.


Guía para los Requisitos 5 y 6: Mantener un program a de administración de vulnerabilidad

Requisito 5: Utilice y actualice regularmente el so ftware o los programas antivirus

El software malicioso, llamado "malware", incluidos los virus, los gusanos (worm) y los troyanos (Trojan), ingresa a la red durante muchas actividades de negocio aprobadas incluidos los correos electrónicos de los trabajadores y la utilización de Internet, de computadoras portátiles y de dispositivos de almacenamiento y explota las vulnerabilidades del sistema. El software antivirus deberá utilizarse en todos los sistemas que el malware, por lo general, afecta para proteger los sistemas contra las amenazas de software maliciosos actuales o que eventualmente se desarrollen.

Requisito Guía

5.1 Implemente software antivirus en todos los sistemas comúnmente afectados por software malicioso (en especial, computadoras personales y servidores).

Existe un flujo constante de ataques utilizando vulnerabilidades ampliamente publicadas, comúnmente "día 0" (publicado y difundido a través de redes en un plazo de una hora a partir del descubrimiento) contra sistemas de otro modo seguros. Sin un software antivirus que se actualice regularmente, estas nuevas formas de software malicioso pueden atacar e inhabilitar su red.

El software malicioso se puede descarga y/o instalar sin saberlo desde Internet, pero las computadoras también son vulnerables cuando se utilizan dispositivos de almacenamiento extraíbles como CD y DVD, dispositivos de memoria USB y discos locales, cámaras digitales, asistentes digitales personales (PDA) y otros dispositivos periféricos. Sin un software antivirus instalado, estas computadoras pueden convertirse en puntos de acceso en su red, y/o dirigir, de forma maliciosa, información dentro de la red.

Aunque entre los sistemas comúnmente afectados por software malicioso no se suele incluir mainframes ni la mayoría de los sistemas Unix (consulte más detalles a continuación), cada entidad debe tener un proceso de conformidad con el Requisito 6.2 de las PCI DSS a efectos de identificar y tratar nuevas vulnerabilidades de seguridad y actualizar sus normas y procesos de configuración debidamente. Si otro tipo de solución trata las mismas amenazas con una metodología diferente a un enfoque basado en firmas, sigue siendo aún aceptable para cumplir con el requisito.

Las tendencias en software malicioso relacionadas con sistemas operativos que utiliza una entidad deben estar incluidas en la identificación de nuevas vulnerabilidades de seguridad, y los métodos para tratar nuevas tendencias deben estar incorporados en las normas de configuración y los mecanismos de protección de la empresa según sea necesario.

Comúnmente, los siguientes sistemas operativos no suelen ser afectados por software maliciosos: mainframes y ciertos servidores Unix (como AIX, Solaris y HP-Unix). Sin embargo, las tendencias de la industria para software malicioso pueden cambiar rápidamente y cada organización debe cumplir con el Requisito 6.2 para identificar y tratar nuevas vulnerabilidades de seguridad y actualizar sus normas y


Requisito Guía procesos de configuración debidamente.

5.1.1 Asegúrese de que todos los programas antivirus son capaces de detectar y eliminar todos los tipos conocidos de software malicioso y de proteger a los sistemas contra estos.

Es importante proveer protección contra TODOS los tipos y formas de software malicioso.

5.2 Asegúrese de que todos los mecanismos antivirus estén actualizados, estén en funcionamiento y puedan generar registros de auditoría.

El mejor software antivirus es limitado en efectividad si no tiene firmas antivirus actuales o si no está activo en la red o en la computadora de una persona.

Los registros de auditoría proporcionan la capacidad de supervisar actividad de virus y reacciones antivirus. Por lo tanto, es imprescindible que ese software antivirus se configure para generar registros de auditoría y que esos registros se administren de conformidad con el Requisito 10.


Requisito 6: Desarrolle y mantenga sistemas y aplic aciones seguras

Las personas sin escrúpulos utilizan las vulnerabilidades de seguridad para obtener acceso privilegiado a los sistemas. Muchas de estas vulnerabilidades se pueden subsanar mediante parches de seguridad proporcionados por los proveedores. Las entidades que administran los sistemas deben instalar estos parches. Todos los sistemas importantes deben poseer la última versión de los parches adecuados para estar protegidos contra la explotación de los datos de los titulares de las tarjetas y el riesgo que representan los delincuentes y el software malicioso.

Nota: Los parches de software adecuados son aquéllos que se evaluaron y probaron para confirmar que no crean conflicto con las configuraciones de seguridad existentes. En el caso de las aplicaciones desarrolladas internamente por la institución, es posible evitar numerosas vulnerabilidades mediante la utilización de procesos estándares de desarrollo de sistemas y técnicas de codificación segura.

Requisito Guía

6.1 Asegúrese de que todos los componentes de sistemas y software cuenten con los parches de seguridad más recientes proporcionados por los proveedores para protección contra vulnerabilidades conocidas. Instale los parches importantes de seguridad dentro de un plazo de un mes de su lanzamiento.

Nota: Las organizaciones pueden tener en cuenta la aplicación de un enfoque basado en el riesgo a los efectos de priorizar la instalación de parches. Por ejemplo, al priorizar infraestructura de importancia (por ejemplo, dispositivos y sistemas públicos, bases de datos) superiores a los dispositivos internos menos críticos a los efectos de asegurar que los dispositivos y los sistemas de alta prioridad se traten dentro del periodo de un mes y se traten dispositivos y sistemas menos críticos dentro de un periodo de tres meses.

Existe una cantidad considerable de ataques utilizando vulnerabilidades ampliamente publicadas, comúnmente "día 0" (publicado en un plazo de una hora) contra sistemas de otro modo seguros. Si no se implementan los parches más recientes en sistemas críticos tan pronto como sea posible, una persona malintencionada puede utilizar estas vulnerabilidades para atacar e inhabilitar la red. Considere priorizar cambios como que los parches de seguridad importantes en sistemas críticos o en riesgo se puedan instalar en un plazo de 30 días, y que otros cambios menos arriesgados se instalen en un plazo de 2 a 3 meses.


Requisito Guía

6.2 Establezca un proceso para identificar y asignar una clasificación de riesgos para vulnerabilidades de seguridad descubiertas recientemente.

Notas :

Las clasificaciones de riesgo se deben basar en las mejores prácticas de la industria. Por ejemplo, los criterios para clasificar vulnerabilidades de ”Alto” riesgo pueden incluir una puntuación base CVSS de 4.0 o superior, y/o un parche proporcionado por el proveedor clasificado por el mismo como “crítico”, y/o una vulnerabilidad que afecte un componente crítico del sistema.

La clasificación de vulnerabilidades según lo definido en 6.2.a es considerada una buena práctica hasta el 30 de junio de 2012, y a partir de entonces se convierte en un requisito.

El objetivo de este requisito es que las organizaciones se mantengan al tanto de nuevas vulnerabilidades que pueden afectar su entorno.

Si bien es importante supervisar los anuncios del proveedor con respecto a noticias de vulnerabilidades y parches relacionados con sus productos, es igualmente importante supervisar grupos de noticias y listas de correo sobre vulnerabilidades comunes de la industria para informarse sobre vulnerabilidades y posibles soluciones temporales que posiblemente el proveedor aún no conozca o no pueda resolver.

Una vez que una organización identifique una vulnerabilidad que pueda afectar su entorno, el riesgo que esa vulnerabilidad plantea se debe evaluar y clasificar. Esto implica que la organización ha implementado algún método para evaluar vulnerabilidades y asignar clasificaciones de riesgos de forma regular. Aunque es probable que cada organización tenga métodos diferentes para evaluar una vulnerabilidad y asignar una clasificación de riesgos basándose en su CDE único, es posible aprovechar sistemas comunes de clasificación de riesgos aceptados en la industria, por ejemplo CVSS. 2.0, NIST SP 800-30, etc.

La clasificación de los riesgos (por ejemplo, como “alto”, “medio” o “bajo”) permite a las organizaciones identificar y tratar puntos de riesgo de prioridad alta más rápidamente, y reduce la probabilidad de que se exploten las vulnerabilidades que plantean el mayor riesgo.

6.3 Desarrolle aplicaciones de software (acceso interno y externo, e incluso acceso administrativo basado en la web a aplicaciones) de conformidad con las PCI DSS (por ejemplo, autenticación segura y registro), basadas en las mejores prácticas de la industria, e incorpore seguridad de la información en todo el ciclo de vida del desarrollo del software. Estos procesos deben incluir lo siguiente:

Si no se incluye la seguridad durante la definición de requisitos, el diseño, el análisis y las fases de prueba de desarrollo del software, se pueden introducir vulnerabilidades de seguridad en el entorno de producción de forma inadvertida o malintencionada.

6.3.1 Eliminación de las cuentas, los ID de usuario y las contraseñas personalizadas de la aplicación antes de que las aplicaciones se activen o se pongan a disposición de los clientes

Las cuentas, los nombres de usuario y las contraseñas personalizadas de la aplicación se deben eliminar del código de producción antes de que la aplicación se active o se ponga a disposición de los clientes, ya que estos puntos pueden revelar información sobre el funcionamiento de la aplicación. La posesión de esa información podría facilitar que se ponga en riesgo la aplicación y los datos relacionados del titular de la tarjeta.


Requisito Guía

6.3.2 Revisión del código personalizado antes del envío a producción o a los clientes a fin de identificar posibles vulnerabilidades de la codificación.

Nota: Este requisito de revisión de códigos se aplica a todos los códigos personalizados (tanto internos como públicos) como parte del ciclo de vida de desarrollo del sistema. Las revisiones de los códigos pueden ser realizadas por terceros o por personal interno con conocimiento. Las aplicaciones web también están sujetas a controles adicionales, si son públicas, a los efectos de tratar con las amenazas continuas y vulnerabilidades después de la implementación, conforme al Requisito 6.6 de las PCI DSS.

Las vulnerabilidades de personalidad en códigos personalizados suelen ser blanco de personas malintencionadas para obtener acceso a una red y poner en riesgo los datos de titulares de tarjetas.

Las revisiones de códigos se pueden realizar manualmente o con la asistencia de herramientas de revisión automatizada. Las herramientas de revisión automatizada tienen funcionalidades que revisan si los códigos tienen errores y vulnerabilidades comunes. Aunque la revisión automatizada es útil, en general, no se debe depender de ella como único medio de revisión de códigos. Una persona con conocimientos y experiencia debe formar parte del proceso de revisión a fin de identificar problemas de codificación que son difíciles o incluso imposibles de identificar para una herramienta automatizada. Asignar las revisiones de códigos a alguien que no sea el desarrollador del código permite que se realice una revisión independiente y objetiva.

6.4 Siga los procesos y procedimientos de control de todos los cambios en los componentes del sistema. Los procesos deben incluir lo siguiente:

Sin controles de cambio apropiados, las funciones de seguridad se pueden omitir o dejar inoperables inadvertida o deliberadamente, pueden ocurrir irregularidades de procesamiento o se puede introducir código malicioso.

6.4.1 Desarrollo/prueba por separado y entornos de producción

Debido al estado constantemente cambiante de los entornos de desarrollo y prueba, estos tienden a ser menos seguros que el entorno de producción. Sin una adecuada separación entre entornos es posible que el entorno de producción, y los datos del titular de la tarjeta, queden en riesgo debido a vulnerabilidades en un entorno de prueba y desarrollo.

6.4.2 Separación de funciones entre desarrollo/prueba y entornos de producción

Reducir el número de personal con acceso al entorno de producción y a los datos de titulares de tarjeta minimiza el riesgo y ayuda a asegurar que ese acceso se limite a aquellos individuos con una necesidad de conocimiento de la empresa.

El objetivo de este requisito es asegurar que las funciones de desarrollo/prueba estén separadas de las funciones de producción. Por ejemplo, un desarrollador puede utilizar una cuenta a nivel del administrador con privilegios elevados para utilizarlos en el entorno de desarrollo, y tener una cuenta separada con acceso a nivel de usuario al entorno de producción.

En entornos donde una persona desempeña múltiples roles (por ejemplo, desarrollo de aplicaciones e implementación actualizaciones para sistemas de producción), las funciones se deben asignar de tal manera que ninguna persona tenga control completo de un proceso sin un punto de verificación independiente. Por ejemplo, asigne responsabilidades de desarrollo, autorización y supervisión a personas separadas.


Requisito Guía

6.4.3 Los datos de producción (PAN activos) no se utilizan para las pruebas ni para el desarrollo

Los controles de seguridad no suelen ser tan estrictos en el entorno de desarrollo. El uso de datos de producción proporciona a personas malintencionadas la oportunidad de obtener acceso no autorizado a estos datos (datos de los titulares de tarjetas).

Las marcas de tarjetas de pago y muchos adquirientes pueden proporcionar números de cuenta adecuados para realizar pruebas en caso de que necesite que PAN reales realicen pruebas de las funciones del sistema antes del lanzamiento.

6.4.4 Eliminación de datos y cuentas de prueba antes de que se activen los sistemas de producción

Los datos y las cuentas de prueba se deben eliminar del código de producción antes de que la aplicación se active, ya que estos puntos pueden revelar información sobre el funcionamiento de la aplicación. La posesión de esa información podría facilitar que se ponga en riesgo la aplicación y los datos relacionados del titular de la tarjeta.

6.4.5 Procedimientos de control de cambios para la implementación de parches de seguridad y modificaciones del software. Los procedimientos deben incluir lo siguiente:

Sin controles de cambio apropiados, las funciones de seguridad se pueden omitir o dejar inoperables inadvertida o deliberadamente, pueden ocurrir irregularidades de procesamiento o se puede introducir código malicioso. Del mismo modo, un cambio puede afectar negativamente las funciones de seguridad de sistema, lo que hace necesario revertir el cambio.

6.4.5.1 Documentación de incidencia. El impacto del cambio debe documentarse para que todas las partes afectadas puedan programar de manera apropiada cualquier cambio de procesamiento.

6.4.5.2 Aprobación de cambio documentada por las partes autorizadas.

La aprobación de las partes autorizadas indica que el cambio es legítimo y está autorizado por la organización.

6.4.5.3 Verifique que la prueba de funcionalidad se haya realizado para verificar que el cambio no incide de forma adversa en la seguridad del sistema.

Se deben realizar pruebas rigurosas para verificar que la seguridad del entorno no se reduce al implementar un cambio. Las pruebas deben validar que todos los controles de seguridad existentes permanecen implementados, son reemplazados por controles igualmente sólidos, o son reforzados después de cualquier cambio al entorno.

En el caso de cambio de códigos personalizados, las pruebas incluyen verificar que no se han introducido vulnerabilidades de codificación debido al cambio.

6.4.5.4 Procedimientos de desinstalación. Para cada cambio, debe haber procedimientos de desinstalación en caso de que el cambio falle, para permitir que se pueda volver al estado previo.


Requisito Guía

6.5 Desarrolle aplicaciones basadas en directrices de codificación seguras. Evite vulnerabilidades de codificación comunes en los procesos de desarrollo de software, a fin de incluir:

Nota : Las vulnerabilidades que se enumeran desde el punto 6.5.1 hasta el 6.5.9 eran congruentes con las mejores prácticas de la industria cuando se publicó esta versión de las PCI DSS. Sin embargo, debido a que las mejores prácticas de la industria para la gestión de vulnerabilidades se actualizan (por ejemplo, OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), se deben utilizar las mejores prácticas actuales para estos requisitos.

La capa de aplicación es de alto riesgo y puede ser el blanco de amenazas internas y externas. Sin la seguridad apropiada, se pueden exponer los datos de titulares de tarjetas y otra información confidencial de la empresa, lo que puede ocasionar daños a la empresa, a sus clientes y a su reputación.

Al igual que con todos los requisitos de las PCI DSS, los Requisitos 6.5.1 a 6.5.5 y 6.5.7 a 6.5.9 son los controles mínimos que se deben implementar. Esta lista incluye las prácticas de codificación segura aceptadas más seguras para el momento en que se publicó esta versión de las PCI DSS. En la medida en que las prácticas de codificación segura aceptadas por la industria cambian, las prácticas de codificación de las organizaciones deben actualizarse para que coincidan.

Los ejemplos de recursos de codificación segura proporcionados (SANS, CERT y OWASP) son fuentes sugeridas de referencia y se han incluido sólo para propósitos de guía. Una organización debe incorporar las prácticas de codificación segura relevantes que sean aplicables a la tecnología particular de su entorno.

6.5.1 Errores de inyección, en especial, errores de inyección SQL. También considere los errores de inyección de comandos de OS, LDAP y Xpath, así como otros errores de inyección.

Valide la entrada para verificar que los datos de usuario no pueden modificar el significado de los comandos y las consultas. Los errores de inyección, en especial los errores de inyección SQL, son un método comúnmente utilizado para poner aplicaciones en riesgo. La inyección se produce cuando se envían datos suministrados por el usuario a un intérprete como parte de un comando o una consulta. Los datos hostiles del atacante engañan al intérprete para que ejecute comandos accidentales o cambie datos, y le permiten atacar los componentes que hay dentro de la red a través de la aplicación, para iniciar ataques como desbordamientos de buffer o para revelar información confidencial y la funcionalidad de la aplicación del servidor. Ésta también es una forma generalizada de realizar transacciones fraudulentas en sitios web habilitados para el comercio. La información de solicitudes web debe validarse antes de enviarse a la aplicación web; por ejemplo, mediante la verificación de todos los caracteres alfa, la combinación de caracteres numéricos y alfa, etc.

6.5.2 Desbordamiento de buffer Asegúrese de las aplicaciones no son vulnerables a ataques de desbordamiento de buffer. Los desbordamientos de buffer ocurren cuando una aplicación no tiene límites apropiados que verifiquen su espacio de buffer. Para explotar una vulnerabilidad de desbordamiento de buffer, un atacante enviaría a una aplicación una cantidad de información más grande que la que sus buffers en particular pueden manejar. Esto puede ocasionar la información en el buffer se expulse del espacio de memoria del buffer y que entre en el espacio de memoria ejecutable. Cuando esto ocurre, el atacante puede insertar código malicioso al final del buffer y luego introducir ese código en espacio de memoria ejecutable desbordando el buffer. Luego, el código malicioso se ejecuta y suele permitir al atacante acceso remoto a la aplicación y/o sistema infectado.


Requisito Guía

6.5.3 Almacenamiento cifrado inseguro Prevenga errores de cifrado. Las aplicaciones que no utilizan apropiadamente funciones de cifrado sólido para almacenar datos tiene mayor probabilidad de riesgo y de exposición de datos de los titulares de tarjetas. Si un atacante puede explotar procesos de cifrado débil, puede obtener acceso en texto claro a datos cifrados.

6.5.4 Comunicaciones inseguras Cifrar adecuadamente todas las comunicaciones autenticadas y confidenciales. Las aplicaciones que no cifran adecuadamente el tráfico de red utilizando cifrado sólido tiene mayor probabilidad de riesgo y de exposición de datos de los titulares de tarjetas. Si un atacante puede explotar procesos de cifrado débil, puede tener el control de la aplicación o incluso obtener acceso en texto claro a datos cifrados.

6.5.5 Manejo inadecuado de errores No filtre información por medio de mensajes de error u otros medios. Las aplicaciones pueden filtrar información sobre su configuración o trabajos internos sin querer o pueden violar la privacidad a través de una variedad de problemas de aplicaciones. Los atacantes usan esta debilidad para robar datos confidenciales o para realizar ataques más graves. Además, el manejo inadecuado de errores ofrece información que ayuda a las personas malintencionadas a poner en riesgo el sistema. Si una persona malintencionada puede crear errores que una aplicación web no puede manejar correctamente, puede obtener información detallada del sistema, puede crear interrupciones por negación de servicios, puede hacer que la seguridad falle o puede bloquear el servidor. Por ejemplo, el mensaje "la contraseña suministrada es incorrecta” indica a los delincuentes que el ID de usuario suministrado es correcto y que deben concentrar sus esfuerzos sólo en la contraseña. Use mensajes de error más genéricos, como “no se pueden verificar los datos”.

6.5.6 Todas las vulnerabilidades “altas” detectadas en el proceso de identificación de vulnerabilidades (según lo definido en el Requisito 6.2 de las PCI DSS).

Nota : Este requisito se considera una mejor práctica hasta el 30 de junio de 2012, y a partir de entonces se convierte en requisito.

Cualquier vulnerabilidad alta notificada de conformidad con el Requisito 6.2 que podría afectar la aplicación se debe justificar durante la fase de desarrollo. Por ejemplo, una vulnerabilidad identificada en una biblioteca compartida o en el sistema operativo subyacente se debe evaluar y tratar antes de que llegue a producción.

En caso de aplicaciones web e interfaces de aplicaciones (internas o externas), se aplican los siguientes requisitos adicionales:

Las aplicaciones web, (públicas) tanto internas como externas, tienen riesgos de seguridad únicos basados en su arquitectura, así como su facilidad relativa y ocurrencia de riesgo.


Requisito Guía

6.5.7 Lenguaje de comandos entre distintos sitios (XSS) Todos los parámetros deben ser validados antes de su inclusión. Los errores de XSS se producen cuando una aplicación toma datos suministrados por el usuario y los envía a un explorador web sin primero validar o codificar ese contenido. XSS permite a los atacantes ejecutar secuencias en el navegador de la víctima el cual puede apropiarse de las sesiones del usuario, destruir sitios web y posiblemente introducir gusanos, etc.

6.5.8Control de acceso inapropiado (tal como referencias no seguras a objetos directos, no restricción de acceso a URL y exposición completa de los directorios)

No exponga referencias a objetos internos a usuarios. Una referencia a un objeto directo ocurre cuando un desarrollador expone una referencia a un objeto de implementación interna, como un archivo, directorio, registro de base de datos o clave, como un parámetro de URL o formulario. Los atacantes pueden manipular esas referencias para acceder a otros objetos sin autorización.

Refuerce constantemente el control del acceso en la capa de presentación y la lógica de negocios para todas las URL. Frecuentemente, la única manera en que una aplicación protege funciones confidenciales es evitando que se muestren vínculos o URL a usuarios no autorizados. Los atacantes pueden usar esta debilidad para tener acceso y realizar operaciones no autorizadas mediante el acceso a esos URL directamente.

Protéjase contra exposición completa de los directorios. Es posible que un atacante enumere y explorar la estructura del directorio de un sitio web y así obtener acceso a información no autorizada, así como un mayor conocimiento de los trabajos del sitio para posterior explotación.

6.5.9 Falsificación de solicitudes entre distintos sitios (CSRF) No confíe en las credenciales de autorización ni en los tokens que los exploradores presentan automáticamente. Un ataque de CSRF obliga al navegador de la víctima conectada a enviar una solicitud preautenticada a una aplicación web vulnerable, que luego obliga al navegador de la víctima a ejecutar una acción hostil para beneficio del atacante. La CSRF puede ser tan poderosa como la aplicación web que ataca.


Requisito Guía

6.6 En el caso de aplicaciones web públicas, trate las nuevas amenazas y vulnerabilidades continuamente y asegúrese de que estas aplicaciones se protejan contra ataques conocidos de alguno de los siguientes métodos:

� Controlar las aplicaciones web públicas mediante herramientas o métodos de evaluación de seguridad de vulnerabilidad de aplicación automáticas o manuales, por lo menos, anualmente y después de cada cambio

� Instale un firewall de aplicación web enfrente de aplicaciones web públicas

Los ataques en aplicaciones web son comunes y generalmente exitosos, y ocurren como consecuencia de prácticas de codificación deficientes. Este requisito para revisar aplicaciones o instalar firewalls de aplicación web pretende reducir en gran medida la cantidad de riesgos que corren las aplicaciones web públicas que ocasionan fallos en los datos de titulares de tarjetas.

� Para satisfacer este requisito, se pueden utilizar herramientas o métodos de evaluación de seguridad de vulnerabilidad tanto manuales como automáticos y/o escanear las aplicaciones para determinar si existen vulnerabilidades

� Los firewalls de aplicación web filtran y bloquean el tránsito no esencial en la capa de aplicación. Junto con un firewall de red, un firewall de aplicación web correctamente configurado previene ataques a la capa de aplicación si las aplicaciones están codificadas o configuradas incorrectamente.


Guía para los Requisitos 7, 8 y 9: Implemente medid as sólidas de control de acceso

Requisito 7: Restrinja el acceso a los datos del ti tular de la tarjeta según la necesidad de saber que tenga la empresa.

A los efectos de asegurar que el personal autorizado sea el único que pueda acceder a los datos importantes, se deben implementar sistemas y procesos que limiten el acceso conforme a la necesidad de conocer y conforme a la responsabilidad del cargo. "La necesidad de saber" es la situación en que se otorgan derechos a la menor cantidad de datos y privilegios necesarios para realizar una tarea.

Requisito Guía

7.1 Limite el acceso a los componentes del sistema y a los datos del titular de la tarjeta a aquellos individuos cuyas tareas necesitan de ese acceso. Las limitaciones al acceso deben incluir lo siguiente:

7.1.1 Restricciones a los derechos de acceso a ID de usuarios privilegiadas a la menor cantidad de privilegios necesarios para cumplir con las responsabilidades del cargo

7.1.2 La asignación de privilegios se basa en la tarea del personal individual, su clasificación y función

7.1.3 Requisito de una aprobación documentada de partes autorizadas especificando privilegios requeridos.

7.1.4 Implementación de un sistema de control de acceso automático

Mientras más gente tenga acceso a los datos de titulares de tarjetas, más riesgo hay de que una cuenta de usuario se use maliciosamente. Limitar el acceso a quienes tienen una razón de negocios sólida para tener acceso ayuda a su organización a prevenir el mal manejo de los datos de titulares de tarjetas por falta de experiencia o maldad. Cuando se otorgan derechos de acceso a la menor cantidad de datos y privilegios necesarios para realizar una tarea, se denomina “necesidad de conocer” y cuando los privilegios se asignan a individuos en base a la clasificación y la función, se denomina "control de acceso basado en roles" o RBAC. El control de acceso basado en roles no se limita a una capa de aplicación o a cualquier solución de autorización específica. Por ejemplo, la tecnología incluyendo, pero sin limitarse a, servicios de directorio como Active Directory o LDAP, Listas de Control de Acceso (ACL), y TACACS, ofrece soluciones viables siempre y cuando se configuren apropiadamente a fin de hacer cumplir los principios de la menor cantidad de privilegios y necesidad de conocer.

Las organizaciones deben crear una política clara y procesos para el control de acceso a datos en base a la “necesidad de conocer” y mediante el uso del "control de acceso basado en roles" para definir cómo y a quién se le otorga acceso, incluyendo procesos apropiados de autorización de la gerencia.

7.2 Establezca un sistema de control de acceso para los componentes del sistema con usuarios múltiples que restrinja el acceso basado en la necesidad del usuario de conocer y que se configure para “negar todo”, salvo que se permita específicamente.

Este sistema de control de acceso debe incluir lo siguiente:

7.2.1 Cobertura de todos los componentes del sistema

7.2.2 La asignación de privilegios a individuos se basa en la clasificación del trabajo y la función

7.2.3 Ajuste predeterminado "negar todos"

Sin un mecanismo para restringir el acceso en base a la necesidad de conocer que tiene el usuario, es posible que sin saberlo se le otorgue acceso a los datos de titulares de tarjetas a un usuario. El uso de un mecanismo o sistema de control de acceso automático es esencial para administrar varios usuarios. Este sistema debe establecerse de acuerdo con la política y los procesos de control de acceso de su organización (incluida la “necesidad de conocer” y el “control de acceso basado en funciones”), debe administrar el acceso a todos los componentes del sistema y debe tener un ajuste predeterminado de “negar todos” para garantizar que a nadie se le otorgue acceso a menos que se establezca una norma específica que le otorgue dicho acceso.


Requisito Guía Nota: Algunos sistemas de control de acceso se establecen de forma predeterminada para "permitir todos", y así permite acceso salvo que, o hasta que, se escriba una regla que niegue ese acceso en particular.


Requisito 8: Asignar una ID exclusiva a cada person a que tenga acceso por computadora

La asignación de una identificación (ID) única a cada persona que tenga acceso garantiza que cada una de ellas es responsable de sus actos. Cuando se ejerce dicha responsabilidad, las acciones en datos críticos y sistemas las realizan usuarios conocidos y autorizados, y además se pueden realizar seguimientos.

Nota: Estos requisitos se aplican a todas las cuentas, incluidas las cuentas de puntos de venta, con capacidades administrativas y todas las cuentas utilizadas para ver o acceder a datos de titulares de tarjetas o para acceder a sistemas con datos de titulares de tarjetas. Sin embargo, los requisitos 8.1, 8.2 y 8.5.8 al 8.5.15 no se aplican a las cuentas de usuarios dentro de una aplicación de pago de un punto de venta que sólo tengan acceso a un número de tarjeta por vez a fin de facilitar una transacción única (tales como las cuentas en efectivo).

Requisito Guía

8.1 Asigne a todos los usuarios una ID única antes de permitirles tener acceso a componentes del sistema o a datos de titulares de tarjetas.

Si una organización se asegura que cada usuario tiene una identificación única (en vez de usar una misma ID para varios empleados), puede mantener la responsabilidad individual de las acciones y una pista de auditorías efectiva por empleado. Esto ayuda a acelerar la resolución de problemas y la contención cuando se producen malos usos o acciones malintencionadas.

8.2 Además de la asignación de una ID única, emplee al menos uno de los métodos siguientes para autenticar a todos los usuarios:

� Algo que el usuario sepa, como una contraseña o frase de seguridad

� Algo que el usuario tenga, como un dispositivo token o una tarjeta inteligente

� Algo que el usuario sea, como un rasgo biométrico

Estos elementos de autenticación, cuando se usan además de las ID únicas, ayudan a impedir que las ID únicas de los usuarios corran riesgos (ya que quien intenta poner en riesgo las ID necesita saber el ID único y la contraseña u otro elemento de autenticación).

Un certificado digital es una opción válida como una forma del tipo de autenticación “algo que el usuario tenga”, siempre y cuando sea único.


Requisito Guía

8.3 Incorpore la autenticación de dos factores para el acceso remoto (acceso en el nivel de la red que se origina fuera de la red) a la red de empleados, administradores y terceros. (Por ejemplo, autenticación remota y servicio dial-in (RADIUS) con tokens; sistema de control de acceso mediante control del acceso desde terminales (TACACS) con tokens; u otras tecnologías que faciliten la autenticación de dos factores).

Nota : La autenticación de dos factores requiere que dos de los tres métodos de autenticación (consulte el requisito 8.2 para obtener una descripción de los métodos de autenticación) se utilicen para la autenticación. El uso de un mismo factor dos veces (p.ej., utilizar dos contraseñas individuales) no se considera una autenticación de dos factores.

La autenticación de dos factores requiere dos formas de autenticación para los accesos de mayor riesgo, como los que se originan fuera de su red. Para mayor seguridad, su organización también puede considerar usar autenticación de dos factores cuando accede a redes de mayor seguridad desde redes de menor seguridad; por ejemplo, desde escritorios de la empresa (baja seguridad) a bases de datos/servidores de producción con datos de titulares de tarjetas (alta seguridad).

El objetivo de este requisito es aplicarlo a usuarios que tengan acceso remoto a la red, donde dicho acceso remoto podría otorgar acceso al entorno de datos de titulares de tarjetas.

En este contexto, acceso remoto se refiere a acceso en el nivel de la red que se origina fuera de la red de una entidad, bien sea desde Internet o desde una red o sistema “no confiable”, como un tercero o un empleado que accede a la red de la entidad utilizando su computadora portátil. El acceso LAN-to-LAN interno (por ejemplo, entre dos oficinas mediante VPN segura) no se considera acceso remoto para propósitos de este requisito.

Si el acceso remoto a una entidad cuya segmentación de red es apropiada, de modo tal que los usuarios remotos no pueden acceder o afectar el entorno de datos de los titulares de tarjetas, las PCI DSS no exigen una autenticación de dos factores para el acceso remoto a esa red. Sin embargo, la autenticación de dos factores se requiere para cualquier acceso remoto a redes con acceso al entorno de datos de los titulares de tarjetas, y se recomienda para todos los accesos remotos a las redes de una entidad.

8.4 Deje ilegibles todas las contraseñas durante la transmisión y el almacenamiento en todos los componentes del sistema mediante un cifrado sólido.

Muchos de los dispositivos y aplicaciones de la red transmiten el ID de usuario y la contraseña sin cifrar a través de la red y/o también almacenan las contraseñas sin cifrado. Una persona malintencionada puede interceptar fácilmente una ID de usuario o contraseña no cifrada o legible durante la transmisión utilizando un “sniffer,” o acceder directamente a los ID de usuario y contraseñas no cifradas en archivos donde estén almacenadas, y utilizar estos datos almacenados para obtener acceso no autorizado. Durante la transmisión, las credenciales del usuario se pueden cifrar o el túnel se puede cifrar

8.5 Asegúrese de que sean correctas la autenticación del usuario y la administración de contraseñas de usuarios no consumidores y administradores en todos los componentes del sistema de la siguiente manera:

Debido a que uno de los primeros pasos que una persona malintencionada dará para poner en riesgo un sistema es explotar las contraseñas débiles o no existentes, es importante implementar buenos procesos para la autenticación del usuario y la administración de las contraseñas.


Requisito Guía

8.5.1 Controle el agregado, la eliminación y la modificación de las ID de usuario, las credenciales, entre otros objetos de identificación.

Para asegurarse de que los usuarios agregados a sus sistemas son todos usuarios reconocidos y válidos, un pequeño grupo con autoridad específica debe administrar el agregado, la eliminación y la modificación de las ID de usuario. La capacidad de administrar estas ID de usuario sólo debe limitarse a un grupo pequeño.

8.5.2 Verifique la identidad del usuario antes de restablecer contraseñas.

Muchas personas malintencionadas usan la “ingeniería social” (por ejemplo, llaman a una mesa de ayuda y se hacen pasar por usuarios legítimos) para cambiar la contraseña y poder utilizar una ID de usuario. Considere el uso de una “pregunta secreta” que sólo el usuario apropiado pueda responder para ayudar a los administradores a identificar el usuario antes de restablecer las contraseñas. Asegúrese de que las preguntas estén correctamente aseguradas y no se compartan.

8.5.3 Configure la primera contraseña en un valor único para cada usuario y cámbiela de inmediato después del primer uso.

Si se usa la misma contraseña para todas las nuevas configuraciones de usuario, un usuario interno, un ex empleado o una persona malintencionada pueden saber o descubrir fácilmente esta contraseña y usarla para obtener acceso a cuentas.

8.5.4 Cancele de inmediato el acceso para cualquier usuario cesante.

Si un empleado se va de la empresa y aún tiene acceso a la red con su cuenta de usuario, se puede producir un acceso innecesario o malintencionado a los datos de titulares de tarjetas. El autor de este acceso puede ser un ex empleado o un usuario malintencionado que explota una cuenta antigua o que no se usa. Considere implementar un proceso con Recursos Humanos para que se realice una notificación inmediata cuando un empleado queda cesante para que la cuenta de usuario se desactive rápidamente.

8.5.5 Elimine/inhabilite las cuentas de usuario inactivas al menos cada 90 días.

La existencia de cuentas inactivas permite a un usuario no autorizado explotar la cuenta que no se usa para poder acceder a los datos de titulares de tarjetas.

8.5.6 Habilite las cuentas que utilicen los proveedores para el acceso remoto únicamente durante el período necesario. Supervise las cuentas de acceso remoto de proveedores cuando se utilicen.

Si permite que los proveedores (como los proveedores de POS) tengan acceso a su red las 24 horas, todos los días, cuando necesitan realizar el soporte de sus sistemas, aumentarán las posibilidades de acceso no autorizado, ya sea de un usuario del entorno de proveedores o de una persona malintencionada que encuentra y usa este punto siempre listo de acceso externo a la red.

La supervisión del acceso de los proveedores al entorno de los datos de titulares de tarjetas se aplica de la misma manera que se realiza con respecto a otros usuarios, como el personal de organizaciones. Esto incluye la supervisión y el registro de actividades de conformidad con los Requisitos 10.1 y 10.2 de las PCI DSS, y la verificación de que el uso de cuentas de acceso remoto de proveedores se realiza de conformidad con la política de conformidad con lo definido en los Requisitos 12.3.8 y 12.3.9.


Requisito Guía

8.5.7 Comunique los procedimientos y las políticas de autenticación a todos los usuarios con acceso a datos de titulares de tarjetas.

Comunicar los procedimientos relacionados con las contraseñas y la autenticación a todos los usuarios ayuda a entender y acatar las políticas, así como a estar alerta a personas malintencionadas que puedan intentar explotar las debilidades de sus contraseñas para obtener acceso a los datos de los titulares de tarjetas (por ejemplo, llamar a un empleado y pedirle su contraseña para "resolver un problema").

8.5.8 No utilice cuentas ni contraseñas de grupos, compartidas o genéricas, ni ningún otro método de autenticación.

Si múltiples usuarios comparten las mismas credenciales de autenticación (por ejemplo, cuenta de usuario y contraseña), es imposible asignar responsabilidad por, o llevar un registro efectivo de, las acciones de una persona, debido a que una acción determinada pudo haber sido ejecutada por cualquiera del grupo con conocimiento de las credenciales de autenticación.

Este requisito de ID únicas y contraseñas complejas se cumple frecuentemente dentro de las funciones administrativas utilizando, por ejemplo, sudo o SSH para que el administrador inicie sesión en principio con sus ID y contraseñas únicos y, luego, se conecte a través de sudo o SSH. Con frecuencia, los inicios de sesión de raíz directos se inhabilitan para prevenir el uso de esta cuenta administrativa compartida. De esta manera, se preservan la responsabilidad individual y las pistas de auditoría. Sin embargo, incluso con el uso de herramientas como sudo y SSH, las ID y contraseñas reales del administrador también deben cumplir con los requisitos de las PCI DSS (si dichas cuentas están habilitadas) a fin de evitar que se utilicen de forma indebida.

8.5.9 Cambie las contraseñas de usuario al menos cada 90 días.

8.5.10 Solicite una longitud de contraseña mínima de siete caracteres.

8.5.11 Utilice contraseñas que contengan tanto caracteres numéricos como alfabéticos.

8.5.12 No permita que ninguna persona envíe una contraseña nueva igual a cualquiera de las últimas cuatro contraseñas utilizadas.

Las contraseñas sólidas constituyen la primera línea de defensa de una red, ya que personas malintencionadas con frecuencia intentarán buscar cuentas sin contraseñas o cuyas contraseñas sean débiles. Una persona malintencionada dispone de más tiempo para encontrar estas cuentas débiles y comprometer una red utilizando una ID de usuario válida, si las contraseñas son cortas, fáciles de adivinar o se mantienen vigentes durante largos períodos de tiempo sin cambiarlas. Las contraseñas sólidas se pueden aplicar y mantener, de acuerdo con estos requisitos, habilitando las funciones de seguridad de contraseñas y cuentas que vienen con su sistema operativo (como Windows), redes, bases de datos y otras plataformas.

8.5.13 Limite los intentos de acceso repetidos mediante el bloqueo de la ID de usuario después de más de seis intentos.

Sin la implementación de mecanismos de bloqueo de cuentas, un atacante puede intentar adivinar continuamente una contraseña a través de herramientas manuales o automatizadas (por ejemplo, el craqueo de contraseñas), hasta lograr su objetivo y obtener acceso a la cuenta de un usuario.


Requisito Guía

8.5.14 Establezca la duración del bloqueo en un mínimo de 30 minutos o hasta que el administrador habilite la ID del usuario.

Si se bloquea una cuenta debido a que una persona ha estado intentando adivinar una contraseña de manera insistente, los controles para retrasar la reactivación de estas cuentas bloqueadas evitan que la persona malintencionada siga adivinando la contraseña (tendrá que detenerse durante un mínimo de 30 minutos hasta que se reactive la contraseña). Además, si la reactivación se debe solicitar, el administrador o la mesa de ayuda pueden validar que el propietario de la cuenta es la causa (por errores de escritura) del bloqueo.

8.5.15 Si alguna sesión estuvo inactiva durante más de 15 minutos, solicite al usuario que vuelva a escribir la contraseña para que se active la terminal nuevamente.

Cuando los usuarios dejan sola una máquina abierta con acceso a datos de titulares de tarjetas o red críticos, es posible que otras personas utilicen la máquina en la ausencia del usuario, lo que generaría un acceso a la cuenta no autorizado y/o el uso indebido de la cuenta.

8.5.16 Autentique todos los accesos a cualquier base de datos que contenga datos de titulares de tarjetas. Esto incluye el acceso de aplicaciones, administradores y demás usuarios.

Restrinja el acceso directo a o las consultas en las bases de datos a los administradores de la base de datos.

Sin autenticación de usuario para obtener acceso a bases de datos y aplicaciones, se incrementa el potencial de acceso no autorizado o malintencionado, el cual no se puede registrar porque el usuario no se sometió a un proceso de autenticación y, por lo tanto, el sistema no puede reconocerlo. Además, sólo se debe otorgar acceso a la base de datos a través de métodos programáticos (por ejemplo, a través de procedimientos almacenados), y no a través del acceso directo a la base de datos por parte de usuarios finales (a excepción de los DBA, que pueden tener acceso directo a la base de datos debido a sus tareas administrativas).


Requisito 9: Restrinja el acceso físico a los datos del titular de la tarjeta

Cualquier acceso físico a datos o sistemas que alojen datos de titulares de tarjetas permite el acceso a dispositivos y datos, así como también permite la eliminación de sistemas o copias en papel, y se debe restringir correctamente. A los fines del Requisito 9, “empleados” se refiere a personal de tiempo completo y parcial, personal temporal, y contratistas y consultores que estén físicamente presentes en las instalaciones de la entidad. "Visitante” se define como proveedor, invitado de algún empleado, personal de servicio o cualquier persona que necesite ingresar a las instalaciones durante un tiempo no prolongado, generalmente no más de un día. “Medios” se refiere a todos los medios en papel y electrónicos que contienen datos de titulares de tarjetas.

Requisito Guía

9.1 Utilice controles de entrada a la empresa apropiados para limitar y supervisar el acceso físico a sistemas en el entorno de datos de titulares de tarjetas.

Sin controles de acceso físico, personas no autorizadas podrían obtener acceso al edificio y a la información confidencial, y podrían alterar las configuraciones del sistema, introducir vulnerabilidades en la red o destruir o hurtar equipos.

9.1.1 Utilice cámaras de video y/o mecanismos de control de acceso para supervisar el acceso físico de personas a áreas confidenciales. Revise los datos recopilados y correlaciónelos con otras entradas. Guárdelos durante al menos tres meses, a menos que la ley estipule lo contrario.

Nota: “Áreas confidenciales” hace referencia a cualquier centro de datos, sala de servidores o cualquier área que aloje sistemas que almacenan procesos o transmitan datos de titulares de tarjetas. No se incluyen las áreas en las que se encuentran presentes terminales de punto de venta, tales como el área de cajas en un comercio.

Cuando se investigan violaciones físicas, estos controles pueden ayudar a identificar las personas que acceden físicamente a esas áreas confidenciales donde se almacenan datos de titulares de tarjetas. Entre los ejemplos de áreas confidenciales se incluyen: centro de datos de la base de datos corporativa, centro de datos back-end de un comercio minorista que almacena datos de titulares de tarjetas, y áreas de almacenamiento para grandes cantidades de datos de titulares de tarjetas,

9.1.2 Restrinja el acceso físico a conexiones de red de acceso público. Por ejemplo, las áreas que sean accesibles a los visitantes no deben tener puertos de red habilitados a menos que se autorice explícitamente el acceso a la red.

Restringir el acceso a las conexiones de red impedirá que personas malintencionadas se conecten a los puertos de red disponibles a través de los cuales pueden obtener acceso a los recursos de la red interna. Considere desactivar las conexiones de la red mientras no se estén utilizando y vuelva a activarlas sólo cuando sea necesario. En áreas públicas, como las salas de conferencia, establezca redes privadas para permitir que proveedores y visitantes tengan acceso a Internet, siempre y cuando no puedan acceder a su red interna.


Requisito Guía

9.1.3 Limite el acceso físico a los puntos de acceso inalámbricos, gateways, dispositivos manuales, hardware de redes/comunicaciones y líneas de telecomunicaciones.

Sin mecanismos de seguridad para el acceso a componentes y dispositivos inalámbricos, los usuarios malintencionados podrían utilizar los dispositivos inalámbricos desprovistos de seguridad de su organización para acceder a los recursos de su red o incluso conectar sus propios dispositivos inalámbricos a su red inalámbrica a fin de obtener acceso no autorizado. Adicionalmente, asegurar el hardware de la red y las comunicaciones evita que usuarios malintencionados intercepten el tráfico de la red o que conecten de manera física sus propios dispositivos a los recursos de su red alámbrica.

Considere colocar los puntos de acceso inalámbrico, gateways y hardware de redes/comunicaciones en áreas de almacenamiento seguras, tales como armarios o centros de datos bloqueados. Para las redes inalámbricas, asegúrese de que el cifrado sólido se encuentre habilitado. También considere habilitar un bloqueo automático de dispositivos manuales inalámbricos después de un período considerable de inactividad y establezca sus dispositivos para que soliciten una contraseña cuando se inicien.

9.2 Desarrolle procedimientos para que el personal pueda distinguir con facilidad entre empleados y visitantes, especialmente en las áreas donde se puede acceder fácilmente a datos de titulares de tarjetas.

Sin los sistemas de placas de identificación y sin controles en las puertas, los usuarios no autorizados y malintencionados pueden obtener acceso fácilmente a sus instalaciones para hurtar, inhabilitar, interrumpir o destruir sistemas críticos y datos de titulares de tarjetas. Para un control óptimo, considere implementar un sistema de placas de identificación o tarjetas para entrar a y salir de las áreas de trabajo que contienen datos de titulares de tarjetas.

Identificar a los visitantes autorizados de modo que se puedan distinguir fácilmente del personal interno evita que visitantes no autorizados obtengan acceso a áreas que contienen datos de titulares de tarjetas.

9.3Asegúrese de que todos los visitantes reciban el siguiente trato:

Los controles para visitantes son importantes para reducir la posibilidad de que personas no autorizadas y malintencionadas obtengan acceso a sus instalaciones (y, potencialmente, a datos de titulares de tarjetas).

9.3.1 Autorización previa al ingreso a áreas en las que se procesan o se conservan datos de titulares de tarjetas

9.3.2Token físico otorgado (por ejemplo una placa de identificación o dispositivo de acceso) con vencimiento y que identifique a los visitantes como personas no pertenecientes a la empresa.

9.3.3 Confirme que le sea solicitado entregar el token físico antes de salir de las instalaciones de la empresa o al momento del vencimiento

Los controles para visitantes son importantes para asegurar que los visitantes sólo ingresen a las áreas a las que están autorizados; que se puedan identificar como visitantes, de modo que el personal pueda supervisar sus actividades; y que su acceso se restrinja sólo a la duración de su visita legítima.


Requisito Guía

9.4 Use un registro de visitas para mantener una pista de auditoría física de la actividad de visitas. Documente el nombre del visitante, la empresa a la que representa y el empleado que autoriza el acceso físico en el registro. Conserve este registro durante tres meses como mínimo, a menos que la ley estipule lo contrario.

Un registro de visitas que documente un mínimo de información sobre el visitante es fácil y económico de mantener y ayudará a, durante una investigación de violaciones potenciales de datos, identificar el acceso físico a un edificio o sala, y el acceso potencial a los datos de titulares de tarjetas. Considere implementar registros en la entrada a las instalaciones y especialmente en las zonas donde haya datos de titulares de tarjetas.

9.5Almacene los medios de copias de seguridad en un lugar seguro, preferentemente en un lugar externo a la empresa, como un centro alternativo o para copias de seguridad, o un centro de almacenamiento comercial. Revise la seguridad de dicho lugar una vez al año como mínimo.

Si el almacenamiento se realiza en un lugar no seguro, las copias de seguridad que contienen datos de titulares de tarjetas se pueden perder, hurtar o copiar fácilmente para fines malintencionados. Para un almacenamiento seguro, considere contratar los servicios de una compañía de almacenamiento comercial O, si se trata de una entidad más pequeña, utilizar la caja de seguridad de un banco.

9.6 Proteja físicamente todos los medios.

Los datos de titulares de tarjetas son susceptibles de revisiones, copias o análisis no autorizados si no se protegen mientras están en medios extraíbles o portátiles, si se imprimen o se dejan sobre el escritorio de alguien.

9.7Lleve un control estricto sobre la distribución interna o externa de cualquier tipo de medios que contenga datos de titulares de tarjetas, incluidos:

Los procedimientos y los procesos ayudan a proteger los datos de titulares de tarjetas almacenados en medios que se distribuyen a usuarios internos y/o externos. Sin dichos procedimientos, los datos se pueden perder o hurtar y utilizarse con fines fraudulentos.

9.7.1 Clasifique los medios de manera que se pueda determinar la confidencialidad de los datos.

Es importante que se identifiquen los medios para poder discernir sus estados de clasificación fácilmente. Los medios no identificados como confidenciales no se pueden proteger adecuadamente o se pueden perder o hurtar.

9.7.2 Envíe los medios por correo seguro u otro método de envío que se pueda rastrear con precisión.

Los medios son susceptibles de pérdida o hurto si se envían a través de un método al que no se pueda hacer seguimiento, tal como un correo postal regular. Utilice los servicios de un correo seguro para entregar cualesquiera medios que contengan datos de titulares de tarjetas, de este modo, usted podrá utilizar los servicios de rastreo que ofrecen estos servicios para llevar un inventario y conocer la ubicación de los envío.

9.8 Asegúrese de que la gerencia apruebe todos y cada uno de los medios que contengan datos de titulares de tarjetas que se muevan desde un área segura (especialmente cuando se los distribuye a personas).

Si el retiro de datos de titulares de tarjetas de un área segura no se realiza según un proceso aprobado por la gerencia, se puede producir la pérdida o el hurto de los datos. Sin un proceso firme, no se hace un seguimiento a las ubicaciones de los medios ni existe un proceso para el lugar hacia donde van los datos ni la manera para protegerlos.

9.9 Lleve un control estricto sobre el almacenamiento y accesibilidad de los medios.

Sin métodos de inventario ni controles de almacenamiento rigurosos, el hurto o la pérdida de medios podría pasar desapercibida durante una cantidad indefinida de tiempo.


Requisito Guía

9.9.1 Lleve registros de inventario adecuadamente de todos los medios y realice inventarios de medios anualmente como mínimo.

Si los medios no se incluyen en un inventario, el hurto o pérdida de los mismos pudiera pasar desapercibida durante un largo período de tiempo o para siempre.

9.10 Destruya los medios que contengan datos de titulares de tarjetas cuando ya no sea necesario para el negocio o por motivos legales, de la siguiente manera:

9.10.1 Corte en tiras, incinere o haga pasta los materiales de copias en papel para que no se puedan reconstruir los datos de titulares de tarjetas.

9.10.2 Entregue los datos de titulares de tarjetas en dispositivos electrónicos no recuperables para que dichos datos no se puedan reconstruir.

Si no se realiza un procedimiento para destruir la información contenida en discos duros, unidades portátiles, discos de CD/DVD o que se haya imprimido antes de desecharla, es posible que personas malintencionadas recuperen la información a partir de medios desechados, lo que podría crear una situación de riesgo para los datos. Por ejemplo, personas malintencionadas pueden utilizar una técnica conocida como “recolección urbana”, en la que se registran contenedores de basura y papeleras de reciclaje para buscar información que se pueda utilizar para perpetrar un ataque.

Entre los ejemplos de métodos para destruir medios electrónicos de manera segura, se incluyen borrado seguro, desmagnetización o destrucción física (como desbastar o triturar discos duros).


Guía para los Requisitos 10 y 11: Supervise y evalú e las redes con regularidad

Requisito 10: Rastree y supervise todos los accesos a los recursos de red y a los datos de los titular es de las tarjetas

Los mecanismos de registro y la posibilidad de rastrear las actividades del usuario son críticos para la prevención, detección o minimización del impacto de los riesgos de datos. La presencia de los registros en todos los entornos permite el rastreo, alertas y análisis cuando algo no funciona bien. La determinación de la causa de algún riesgo es muy difícil, casi imposible, sin los registros de la actividad del sistema.

Requisito Guía

10.1 Establezca un proceso para vincular todos los accesos a componentes del sistema (especialmente el acceso con privilegios administrativos, tales como de raíz) a cada usuario en particular.

Es crítico disponer de un proceso o sistema que vincule los accesos de los usuarios con los componentes del sistema a los que han tenido acceso y, en particular, para aquellos usuarios con privilegios administrativos. El sistema genera registros de auditoría y proporciona la capacidad de rastrear actividades sospechosas hasta un usuario específico. Los equipos de investigaciones forenses post-incidente dependen significativamente de estos registros para iniciar la investigación.

10.2 Implemente pistas de auditoría automatizadas para todos los componentes del sistema a fin de reconstruir los siguientes eventos:

La generación de pistas de auditoría de actividades sospechosas alerta al administrador del sistema, envía datos a otros mecanismos de supervisión (como los sistemas de detección de intrusos) y proporciona una pista del historial para hacer seguimiento post-incidente. El registro de los eventos siguientes permite que una organización identifique y rastree actividades potencialmente fraudulentas.

10.2.1 Todo acceso de personas a datos de titulares de tarjetas Los individuos maliciosos podrían obtener conocimiento sobre el uso de una cuenta de usuario con acceso a sistemas del CDE o podrían crear una cuenta nueva, no autorizada, para tener acceso a los datos de los titulares de tarjetas. Un registro de todos los accesos individuales a los datos de los titulares de tarjetas puede identificar las cuentas que están en riesgo o que han sido mal utilizadas.

10.2.2 Todas las acciones realizadas por personas con privilegios de raíz o administrativos

Las cuentas que tienen privilegios aumentados, como la cuenta “administrador” o “raíz”, tienen el potencial de afectar de manera relevante la seguridad o funcionalidad operacional de un sistema. Sin un registro de las actividades realizadas, una organización no puede rastrear ninguno de los problemas que puedan surgir cuando ocurren errores administrativos o usos fraudulentos de privilegios hasta llegar a la acción e individuo específicos.

10.2.3 Acceso a todas las pistas de auditoría Los usuarios maliciosos intentan a menudo modificar los registros de auditoría para ocultar sus acciones y un registro de acceso permite a una organización realizar seguimiento a cualquier inconsistencia o alteración potencial de registros de una cuenta individual,


Requisito Guía

10.2.4Intentos de acceso lógico no válidos

Los individuos maliciosos frecuentemente realizarán múltiples intentos de acceso a los sistemas que sean su objetivo. Múltiples intentos de inicio de sesión no válidos pueden ser una indicación de intentos de un usuario no autorizado de utilizar "fuerza bruta" o adivinar una contraseña.

10.2 5Uso de mecanismos de identificación y autenticación Sin conocer quién tenía una sesión activa al momento de un incidente, es imposible identificar las cuentas que puedan haber sido utilizadas. Adicionalmente, los usuarios maliciosos pueden intentar manipular los los controles de autenticación con el propósito de evitarlos o de suplantar la identidad de una cuenta válida. Las actividades que incluyan, sin estar limitadas a, escalación de privilegios o cambios de permisos de acceso pueden indicar uso no autorizado de los mecanismos de autenticación de un sistema.

10.2.6 Inicialización de los registros de auditoría de la aplicación

Desactivar los registros de auditoría antes de que se realicen actividades ilícitas es un objetivo común de los usuarios maliciosos que desean evitar ser detectados. La inicialización de registros de auditoría podría indicar que la función del registro fue inhabilitada por un usuario para ocultar sus acciones.

10.2.7Creación y eliminación de objetos en el nivel del sistema El software malicioso, tal como el malware, a menudo crea o reemplaza objetos a nivel de sistema en el sistema objetivo para controlar una función u operación particular en ese sistema.

Consulte el Glosario de términos, abreviaturas y acrónimos de las PCI DSS y las PA-DSS para obtener una definición de “objetos de nivel de sistema”.

10.3Registre al menos las siguientes entradas de pistas de auditoría de los componentes del sistema para cada evento:

10.3.1 Identificación de usuarios

10.3.2 Tipo de evento

10.3.3 Fecha y hora

10.3.4 Indicación de éxito o fallo

10.3.5 Origen del evento

10.3.6 Identidad o nombre de los datos, componentes del sistema o recurso afectados

Mediante el registro de estos detalles para los eventos auditables que contiene el punto 10.2, es posible identificar rápidamente un riesgo potencial y, con suficiente detalle conocer quién, qué, dónde, cuándo y cómo.


Requisito Guía

10.4 Utilizando tecnología de sincronización, sincronice todos tiempos y relojes críticos del sistema y asegúrese de que lo siguiente sea implementado para adquirir, distribuir y almacenar tiempos.

Nota : Un ejemplo de tecnología de sincronización es el Network Time Protocol (NTP).

10.4.1 Los sistemas críticos tienen la hora correcta y uniforme

10.4.2Los datos de tiempo están protegidos

10.4.3 La configuración de tiempo son recibidos desde fuentes de tiempo aceptadas por la industria

La tecnología de sincronización de tiempo se utiliza para sincronizar los relojes de múltiples sistemas. Cuando se implementa correctamente, esta tecnología puede sincronizar relojes de una gran cantidad sistemas a hasta dentro de una fracción de segundo entre sí. Algunos de los problemas que pueden ocurrir cuando los relojes no están sincronizados correctamente incluyen sin limitarse a los siguientes: hacen muy difícil si no imposible comparar archivos de registro de diferentes sistemas y establecer una secuencia de eventos exacta (esto es crucial para el análisis forense en el caso de una falla de seguridad) y evitan que protocolos de cifrado como el SSH que dependen de una base de tiempo absoluta no funcionen correctamente. Para los equipos de investigación forense post-incidentes, la exactitud y la uniformidad de del tiempo en todos los sistemas y el tiempo de cada actividad es crítico para determinar el grado en el que los sistemas estuvieron en riesgo.

Para asegurar un tiempo uniforme, de manera ideal solo debería haber unos pocos servidores de hora internos (centrales) dentro de una entidad. Estos servidores reciben datos UTC (Coordinated Universal Time) directamente desde servidores de hora conocidos y confiables, a través de radios especiales, satélites GPS o desde otras fuentes de redes externas y se comunican con otros servidores del mismo nivel para asegurarse de que mantengan un tiempo exacto. Liego, otros sistemas reciben el tiempo desde estos servidores.

Si un individuo malicioso ha ingresado en la red, a menudo intentará cambiar las marcas de tiempo de sus acciones dentro de los registros de auditoría para evitar la detección de sus actividades. Un individuo malintencionado puede también intentar cambiar el reloj de un componente del sistema para ocultar su presencia - por ejemplo, cambiar el reloj de un sistema a una hora más temprana. Por estas razones, es importante que la hora sea exacta en todos los sistemas y que los datos relacionados con la hora estén protegidos contra el acceso y los cambios no autorizados. Los datos relacionados con la hora incluyen los parámetros y los métodos que se utilizan para establecer el reloj de cada sistema.

Para más información acerca de NTP, visite www.ntp.org, esta información incluye información sobre la hora, normas relacionadas con la hora y servidores de hora.

10.5Resguarde las pistas de auditoría para evitar que se modifiquen.

A menudo, los individuos malintencionados que han ingresado a la red intentarán editar los registros de auditoría para ocultar su actividad. Sin la protección adecuada de los registros de auditoría, su integridad y exactitud no se pueden garantizar y los registros de auditoría se pueden considerar inútiles como herramienta de investigación después de una situación de riesgo.


Requisito Guía

10.5.1Limite la visualización de pistas de auditoría a quienes lo necesiten por motivos de trabajo.

10.5.2 Proteja los archivos de las pistas de auditoría contra las modificaciones no autorizadas.

10.5.3 Realice copias de seguridad de los archivos de las pistas de auditoría de inmediato en un servidor de registros central o medios que resulten difíciles de modificar.

10.5.4Escriba registros para tecnologías externas en un servidor de registros en la LAN interna.

Protección adecuada de los registros de auditoría incluye control de acceso sólido (limitar el acceso a los registros sólo a quienes "necesitan saber") y uso de segregación interna (para hacer que sea más difícil encontrar y modificar el registro). Mediante la escritura de registros correspondientes a tecnologías externas, como tecnologías inalámbricas, firewalls, DNS y servidores de correo, el riesgo de que esos registros se pierdan o sean modificados se reduce, debido a que están más seguras dentro de la red interna.

10.5.5Utilice el software de supervisión de integridad de archivos o de detección de cambios en registros para asegurarse de que los datos de los registros existentes no se puedan cambiar sin que se generen alertas (aunque el hecho de agregar nuevos datos no deba generar una alerta).

Los sistemas de supervisión de la integridad de archivos verifican los cambios de los archivos críticos y notifican cuando tales cambios se detectan. Para efectos de supervisión de la integridad de archivos, una entidad generalmente supervisa los archivos que no cambian regularmente pero cuando cambian indican un riesgo potencial. Para los archivos de registros (que no cambian frecuentemente) los que se deben supervisar son, por ejemplo, eventos como la eliminación de un archivo de registro, cuando un archivo de registro crece o se reduce de manera significativa y cualquier otro indicador de que personas malintencionadas han alterado un archivo de registro. Hay herramientas listas para ser utilizadas (off-the-shelf) y de fuente abierta disponibles para la supervisión de integridad de archivos.

10.6 Revise los registros de todos los componentes del sistema al menos una vez al día. Las revisiones de registros incluyen a los servidores que realizan funciones de seguridad, tales como sistema de detección de intrusiones (IDS) y servidores de protocolos de autenticación, autorización y contabilidad (AAA) (por ejemplo, RADIUS).

Nota: Las herramientas de recolección, análisis y alerta de registros pueden ser utilizadas para cumplir con el requisito 10.6

Muchas violaciones a la seguridad ocurren varios días o meses antes de ser detectadas. La verificación de los registros diariamente minimiza la cantidad de tiempo y exposición a una violación potencial de seguridad. El proceso de revisión del registro no tiene porque ser manual. Especialmente para aquellas entidades que tienen un gran número de servidores, considere el uso de las herramientas de recolección, análisis y alerta de registros.

10.7 Conserve el historial de pista de auditorías durante al menos un año, con un mínimo de tres meses inmediatamente disponible para el análisis (por ejemplo, en línea, archivado o recuperable para la realización de copias de seguridad).

La retención de registros por por lo menos un año permite conservar información importante si se tiene en cuenta que a menudo toma cierto tiempo detectar que ha ocurrido una situación de riesgo y permite a los investigadores disponer de historial de registro suficiente para determinar mejor la duración de una violación potencial a la seguridad y los sistemas que hayan sido potencialmente afectados. Al tener tres meses de registros disponibles de manera inmediata, una entidad puede identificar y minimizar rápidamente el impacto de una violación de seguridad de los datos. El almacenamiento de las cintas que contienen las copias de seguridad en un lugar externo a la empresa, puede resultar en tiempos más largos para restaurar los datos, realizar los análisis e identificar los sistemas o datos afectados.


Requisito 11: Probar periódicamente los sistemas y procesos de seguridad

Las vulnerabilidades son descubiertas continuamente por personas malintencionadas e investigadores y son introducidas mediante software nuevo. Los componentes, procesos y software personalizado del sistema se deben probar con frecuencia para garantizar que los controles de seguridad continúen reflejando un entorno dinámico.

Requisito Guía

11.1 Realice pruebas para determinar la presencia de puntos de acceso inalámbrico y detectar puntos de acceso inalámbrico no autorizados trimestralmente.

Nota: Los métodos que se pueden utilizar en el proceso incluyen, pero no se limitan a, barridos de redes inalámbricas, inspecciones físicas/lógicas de componentes del sistema e infraestructura, control de acceso a la red (NAC) o IDS/IPS inalámbrico.

Independientemente de los métodos que se utilicen, éstos deben ser suficientes para detectar e identificar cualquier dispositivo no autorizado.

La implementación y/o explotación de tecnología inalámbrica dentro de una red constituyen una de las rutas más comunes para que personas malintencionadas obtengan acceso a la red y a datos de titulares de tarjetas. Si un dispositivo inalámbrico o una red inalámbrica se instala sin el conocimiento de la empresa, un atacante podría ingresar fácilmente y sin ser vista a la red.

Los dispositivos de acceso no autorizado se pueden estar ocultos en una computadora o en otro componente del sistema o conectados a estos, o pueden estar conectados directamente a un puerto o dispositivo de red, como un interruptor o router. Cualquier dispositivo no autorizado podría generar un punto de acceso no autorizado en el entorno.

Debido a la facilidad con la que un punto de acceso inalámbrico puede conectarse a una red, la dificultad para detectar su presencia y el gran riesgo que presentan los dispositivos inalámbricos no autorizados, estos análisis deben realizarse incluso cuando existe una política que prohíbe el uso de tecnología inalámbrica.

El tamaño y la complejidad de un entorno particular determinará las herramientas y los procesos apropiados que se utilizarán para proporcionar suficiente seguridad de que no se ha instalado un punto de acceso inalámbrico peligroso en el entorno.

Por ejemplo: En caso de un quiosco minorista independiente en un centro comercial, donde todos los componentes de comunicación se encuentran en envolturas a prueba de manipulaciones, realizar una inspección física detallada del quiosco en sí puede bastar para asegurarse de que no se haya conectado o instalado un punto de acceso inalámbrico peligroso. Sin embargo, en un entorno con múltiples nodos (como una gran tienda minorista, un centro de llamadas, una sala de servidores o un centro de datos), se hace más difícil realizar una inspección física detallada debido a la cantidad de componentes del sistema y puntos de red donde donde se podría instalar u ocultar un dispositivo de acceso inalámbrico peligroso. En este caso, se pueden combinar múltiples métodos para cumplir con el requisito, como realizar inspecciones del sistema físico en conjunto con los resultados de un analizado inalámbrico.

Las soluciones de control de acceso a la red (NAC) pueden realizar administración de autenticación y configuración de dispositivos para impedir que sistemas no autorizados se conecten a la red, o que dispositivos no autorizados se conecten a sistemas autorizados en la red.

Una organización debe tener, como parte de su plan de respuesta a incidentes, procedimientos documentados para seguir en caso de que se detecte un punto de acceso inalámbrico no autorizado. Se debe configurar un IDS/IPS inalámbrico para que automáticamente genere una alerta, pero el plan también debe documentar procedimientos de respuesta si se detecta un dispositivo no autorizado


Requisito Guía durante un análisis inalámbrico manual.

11.2 Realice análisis internos y externos de vulnerabilidades de red al menos trimestralmente y después de cada cambio significativo en la red (tales como instalaciones de componentes del sistema, cambios en la topología de red, modificaciones en las normas de firewall, actualizaciones de productos).

Nota: no se requiere que se completen cuatro análisis trimestrales aprobados para el cumplimiento inicial de PCI DSS si el asesor verifica que 1) el resultado del último análisis fue un análisis aprobado, 2) la entidad ha documentado políticas y procedimientos que exigen análisis trimestrales y 3) las vulnerabilidades detectadas en los resultados del análisis se han corregido tal como se muestra en el nuevo análisis. Durante los años posteriores a la revisión inicial de las PCI DSS, se deben haber realizado análisis trimestrales aprobados.

Un análisis de vulnerabilidades es una herramienta automática que se utiliza en servidores y dispositivos de red internos y externos, y está diseñada para exponer posibles vulnerabilidades e identificar puertos en redes que personas malintencionadas pueden hallar y explotar. Una vez que estas debilidades son identificadas, la entidad las corrige y repite el análisis para verificar que las vulnerabilidades se hayan corregido.

En el momento de una evaluación inicial de las PCI DSS en una entidad, es posible que aún no se hayan realizado cuatro análisis trimestrales. Si el resultado del análisis más reciente cumple con los criterios de un análisis aprobado y se han implementado políticas y procedimientos para futuros análisis trimestrales, el objetivo de este requisito se ha logrado. No es necesario demorar una evaluación “implementada” para este requisito por la falta de cuatro análisis si se cumplen estas condiciones.

11.2.1 Realice análisis interno de vulnerabilidades trimestralmente.

Un proceso establecido de identificación de vulnerabilidades en sistemas internos en el CDE requiere que se realicen análisis de vulnerabilidades trimestralmente. La identificación y el tratamiento de vulnerabilidades oportunamente reduce la probabilidad de explotación de una vulnerabilidad y la posible exposición a riesgo de un componente del sistema o de datos de titulares de tarjetas.

Las vulnerabilidades que plantean el mayor riesgo para el entorno (por ejemplo, clasificadas como “Altas” según el Requisito 6.2) se deben resolver con la máxima prioridad.

Debido a que las redes internas pueden cambiar constantemente durante el año, es posible que una entidad no tenga análisis internos de vulnerabilidades constantemente limpios. El objetivo es que una entidad tenga implementado un programa de administración de vulnerabilidades sólido para resolver vulnerabilidades observadas en un plazo razonable. Como mínimo, las vulnerabilidades “Altas” se deben tratar oportunamente.

Los análisis internos de vulnerabilidades pueden ser realizados por personal interno calificado que sea razonablemente independiente de los componentes del sistema analizados (por ejemplo, un un administrador de firewall no debe ser responsable de analizar el firewall), o una entidad puede elegir que análisis internos de vulnerabilidades sean realizados por un Proveedor aprobado de análisis (ASV) de las PCI SSC, u otra firma especializada en análisis.


Requisito Guía

11.2.2 Los análisis externos de vulnerabilidades trimestrales debe realizarlos un Proveedor aprobado de análisis (ASV) certificado por el Consejo de Normas de Seguridad de la Industria de Tarjetas de Pago (PCI SSC).

Nota: los análisis trimestrales de vulnerabilidades externas debe realizarlos un Proveedor aprobado de análisis (ASV) certificado por el Consejo de Normas de Seguridad de la Industria de Tarjetas de Pago (PCI SSC). Los análisis realizados después de cambios en la red puede realizarlos el personal interno.

Debido a que las redes externas son la mayor probabilidad de riesgo, el análisis externo de vulnerabilidades trimestral debe ser realizado por un Proveedor aprobado de análisis (ASV) de las PCI SSC.

Los ASV deben seguir un conjunto de criterios de análisis y elaboración de informes establecidos por las PCI SSC en la Guía del programa de Proveedores aprobados de análisis.

11.2.3 Realice análisis internos y externos después de cualquier cambio significativo.

Nota: Los análisis realizados después de cambios puede realizarlos el personal interno.

Analizar un entorno después de realizar cambios significativos asegura que esos cambios se realizaron apropiadamente de tal manera que la seguridad del entorno no se haya puesto en riesgo como resultado del cambio. Es posible que no sea necesario analizar todo el entorno después de un cambio. Sin embargo, todos los componentes del sistema afectados por el cambio deberán analizarse.


Requisito Guía

11.3 Realice pruebas de penetración externas e internas al menos una vez al año y después de cualquier actualización o modificación significativa de infraestructuras o aplicaciones (como por ejemplo la actualización del sistema operativo, la adición de una subred al entorno, o la adición de un servidor web al entorno). Estas pruebas de penetración deben incluir lo siguiente:

11.3.1 Pruebas de penetración de la capa de red

11.3.2 Pruebas de penetración de la capa de aplicación

El objetivo de una prueba de penetración es simular una situación de ataque real con la meta de identificar qué tan lejos podría penetrar un atacante en un entorno. Esto le permite a una entidad comprender mejor su posible exposición y desarrollar una estrategia para defenderse contra atacantes.

Una prueba de penetración difiere de un análisis de vulnerabilidades, ya que una prueba de penetración es un proceso activo que puede incluir la explotación de vulnerabilidades identificadas. Generalmente, un análisis de vulnerabilidades es uno de los primeros pasos que realizará el encargado de la prueba de penetración a fin de componer una estrategia de ataque, aunque no es el único paso. Incluso si un análisis de vulnerabilidades no detecta ninguna conocida, el encargado de la prueba de penetración suele adquirir suficientes conocimientos sobre el sistema para identificar posibles deficiencias de seguridad.

La prueba de penetración suele ser un proceso sumamente manual. Si bien se pueden utilizar algunas herramientas automatizadas, el encargado de la prueba de penetración debe utilizar su conocimiento del sistemas para penetrar en un entorno. Comúnmente, el encargado de la prueba encadena varios tipos de ataques con el objetivo de penetrar a través de capas de defensas. Por ejemplo, si el encargado de la prueba encuentra un medio para obtener acceso a un servidor de aplicaciones, entonces usarán el servidor en riesgo como punto para escenificar un nuevo ataque basándose en los recursos a los que el servidor tiene acceso. De esta manera, el encargado de una prueba puede simular los métodos realizados por un atacante a fin de identificar cualquier área de posible debilidad en el entorno que se debe tratar.


Requisito Guía

Utilice los sistemas de detección y/o prevención de intrusiones para supervisar el tráfico en el entorno de datos de titulares de tarjetas, así como puntos críticos dentro del entorno, y alerte al personal ante la sospecha de riesgos.

Mantenga actualizados todos los motores de detección y prevención de intrusiones, bases y firmas.

Los sistemas de detección y/o prevención de intrusiones (IDS/IPS) comparan el tráfico que proviene de la red con “firmas” y/o conductas conocidas de miles de tipos de exposiciones (herramientas de hacker, troyanos (Trojans) y otro software malicioso), y envía alertas y/o detiene el intento cuando ocurre. Sin un enfoque proactivo para la detección de actividades no autorizadas a través de estas herramientas, los ataques a recursos informáticos (o su mal uso) pueden pasar inadvertidos en tiempo real. Las alertas de seguridad que generan estas herramientas se pueden supervisar para que los intentos de intrusiones puedan detenerse.

Se deben implementar dispositivos de IDS/IPS de manera que supervisen en tráfico entrante y saliente en el perímetro del CDE, así como puntos críticos dentro del CDE. Los puntos críticos dentro del CDE pueden incluir servidores de bases de datos que almacenan datos de titulares de tarjetas, ubicaciones de almacenamiento de claves de cifrado, procesamiento de redes, u otros componentes confidenciales del sistema, según lo determinado por el entorno de una entidad y según lo documentado en su evaluación de riesgos.

Si bien, en la actualidad, muchos dispositivos de IDS/IPS pueden supervisar múltiples puntos dentro del CDE mediante un dispositivo, es importante recordar la mayor exposición que puede ocurrir como resultado de un fallo en ese dispositivo. Por lo tanto, es importante incorporar la debida redundancia en la infraestructura de IDS/IPS.

Existen miles de tipos de riesgos y, a diario, se descubren muchos más. Las versiones obsoletas de estas firmas y motores de análisis no identificarán nuevas vulnerabilidades que pueden provocar un fallo no detectado. Los proveedores de estos productos suministran actualizaciones con frecuencia o, incluso, diariamente, que se deben evaluar y aplicar regularmente.


Requisito Guía

11.5 Implemente herramientas de supervisión de integridad de archivos para alertar al personal ante modificaciones no autorizadas de archivos críticos del sistema, archivos de configuración o archivos de contenido; asimismo configure el software para realizar comparaciones de archivos críticos al menos semanalmente.

Nota: a los fines de la supervisión de integridad de archivos, los archivos críticos generalmente son los que no se modifican con regularidad, pero cuya modificación podría indicar un riesgo o peligro para el sistema. Los productos para la supervisión de integridad de archivos generalmente vienen preconfigurados con archivos críticos para el sistema operativo relacionado. La entidad (es decir el comerciante o el proveedor de servicios) debe evaluar y definir otros archivos críticos, tales como los archivos para aplicaciones personalizadas.

Las herramientas de supervisión de la integridad de archivos (FIM) verifican los cambios de los archivos críticos y notifican cuando tales cambios se detectan. Existen herramientas de forma estándar y de código abierto disponibles para la supervisión de integridad de archivos. Si la FIM no se implementa correctamente y no se supervisa su resultado, una persona malintencionada puede alterar el contenido de los archivos de configuración, los programas de los sistemas operativos o los ejecutables de aplicaciones Si no se detectan estos cambios no autorizados, los controles de seguridad existentes pueden ser ineficientes o es posible que se roben los datos de titulares de tarjetas sin un impacto perceptible en el procesamiento normal.


Guía para los Requisitos 12: Mantenga una política de seguridad de información

Requisito 12: Mantener una política que trate la se guridad de la información para todo el personal

Una política de seguridad sólida establece el grado de seguridad para toda la entidad e informa al personal lo que se espera de ellos. Todo el personal debe estar al tanto de la confidencialidad de los datos y de su responsabilidad para protegerlos. A los fines del Requisito 12, “personal” se refiere a empleados de tiempo completo y parcial, empleados temporales, y contratistas y consultores que “residan” en las instalaciones de la entidad o que de alguna otra forma tengan acceso al entorno de datos de titulares de tarjetas.

Requisito Guía

12.1 Establezca, publique, mantenga y distribuya una política de seguridad que logre lo siguiente:

12.1.1 Trate todos los requisitos de PCI DSS.

La política de seguridad de la información de una empresa crea un plan de acción para implementar medidas de seguridad para proteger su activo más valioso. Una política de seguridad sólida establece el grado de seguridad para toda la empresa e informa al personal lo que se espera de ellos. Todo el personal debe estar al tanto de la confidencialidad de los datos y de su responsabilidad para protegerlos.

12.1.2 Incluye un proceso anual que identifique las amenazas, y vulnerabilidades, y los resultados en una evaluación formal de riesgos. (Ejemplos de metodologías de evaluación de riesgos incluyen, pero no están limitados a: OCTAVE, ISO 27005 y NIST SP 800-30).

Una evaluación de riesgos le permite a una organización identificar amenazas y las vulnerabilidades asociadas que pueden tener un impacto negativo en su negocio. Los recursos se pueden asignar de forma efectiva a fin de implementar controles que reduzcan la probabilidad y/o posible impacto de la amenaza percibida.

Realizar evaluaciones de riesgos, por lo menos anualmente, permite a la organización mantenerse al día con respecto a los cambios organizativos y amenazas en evolución, tendencias y tecnologías,

12.1.3 Incluye una revisión al menos una vez al año y actualizaciones al modificarse el entorno.

Las amenazas de seguridad y los métodos de protección evolucionan rápidamente durante el año. Si la política de seguridad no se actualiza para reflejar estos cambios, no se implementarán nuevas medidas de protección para luchar contra estas amenazas.

12.2 Desarrolle procedimientos diarios de seguridad operativa coherentes con los requisitos de esta especificación (por ejemplo, procedimientos de mantenimiento de cuentas de usuarios y procedimientos de revisión de registros).

Los procedimientos diarios de seguridad operativa funcionan como “instructivos” que el personal debe utilizar en sus actividades administrativas y de mantenimiento diarias. Los procedimientos de seguridad operativa no documentados tendrán como resultado un personal no consciente del alcance total de sus tareas, procesos que los nuevos empleados no pueden repetir fácilmente y potenciales brechas en estos procedimientos que pueden permitir que una persona malintencionada obtenga acceso a sistemas y recursos críticos.


Requisito Guía

12.3 Desarrolle políticas de utilización para tecnologías críticas (por ejemplo, tecnologías de acceso remoto, tecnologías inalámbricas, dispositivos electrónicos extraíbles, computadoras portátiles, asistentes digitales/para datos personales [PDA], utilización del correo electrónico e Internet) y defina el uso adecuado de dichas tecnologías. Asegúrese de que estas políticas de uso requieran lo siguiente:

Las políticas de uso por parte del personal pueden prohibir el uso de ciertos dispositivos y otras tecnologías si es la política de la empresa, o proporcionar una guía para el personal a propósito de la utilización e implementación correctas. Si las políticas de uso no están implementadas, el personal puede utilizar las tecnologías para transgredir la política de la empresa, lo que permitiría que personas malintencionadas obtengan acceso a sistemas y datos de titulares de sistemas críticos. Un ejemplo puede ser cuando inconscientemente se configuran redes inalámbricas sin seguridad. Para asegurar que se cumplen las normas de la empresa, y que sólo se implementan las tecnologías aprobadas, considere confinar la implementación sólo a los equipos de operaciones y no permitir que personal no especializado/general instale estas tecnologías.

12.3.1 Aprobación explícita de las partes autorizadas

Sin una solicitud de aprobación apropiada para la implementación de estas tecnologías, un miembro del personal puede inocentemente implementar una solución a una necesidad de negocio percibida, pero al mismo tiempo abrir un enorme agujero que exponga los sistemas y datos críticos a personas malintencionadas.

12.3.2 Autenticación para el uso de la tecnología Si se implementan tecnologías sin la debida autenticación (ID de usuarios y contraseñas, tokens, VPN, etc.), personas malintencionadas pueden fácilmente utilizar estas tecnologías desprotegidas para acceder a sistemas críticos y datos de titulares de tarjetas.

12.3.3 Lista de todos los dispositivos y el personal que tenga acceso

12.3.4 Etiquetado de dispositivos para determinar propietario, información de contacto y objetivo

Las personas mal intencionadas pueden violar la seguridad física y colocar sus propios dispositivos en la red como una “puerta trasera”. El personal también puede evadir procedimientos e instalar dispositivos. Un inventario fiable con el debido etiquetado de dispositivos permite identificar rápidamente las instalaciones no aprobadas. Considere establecer una convención de nombres oficial para los dispositivos, y etiquete y registre todos los dispositivos de conformidad con los controles de inventario establecidos. Adicionalmente, se debe emplear un etiquetado lógico que contenga información como códigos que correlacionen el dispositivo con su propietario, información de contrato y objetivo.

12.3.5 Usos aceptables de la tecnología

12.3.6 Ubicaciones aceptables de las tecnologías en la red

12.3.7 Lista de productos aprobados por la empresa

Al definir el uso dentro del negocio y la ubicación aceptables de los dispositivos y la tecnología aprobados por la empresa, ésta se encuentra en mejor posición para administrar y controlar brechas de configuraciones y controles operativos, a fin de asegurar que no se abra una “puerta trasera” para que una persona malintencionada obtenga acceso a sistemas críticos y datos de titulares de tarjetas.

12.3.8 Desconexión automática de sesiones para tecnologías de acceso remoto después de un período específico de inactividad

Las tecnologías de acceso remoto son "puertas traseras" frecuentes para recursos críticos y datos de titulares de tarjetas. La desconexión de las tecnologías de acceso remoto cuando no se utilizan (por ejemplo, aquellas utilizadas para


Requisito Guía

12.3.9 Activación de las tecnologías de acceso remoto para proveedores y socios de negocio sólo cuando sea necesario, con desactivación inmediata después de su uso

respaldar sus sistemas por su proveedor de punto de venta, otros proveedores o socio de negocio), minimizan el acceso a la red y los riesgos. Considere utilizar controles para desconectar dispositivos después de 15 minutos de inactividad. Consulte también el Requisito 8.5.6 para obtener más información sobre este tema.

12.3.10 En el caso del personal con acceso a datos de titulares de tarjetas mediante tecnologías de acceso remoto, prohíba copiar, mover y almacenar los datos de titulares de tarjetas en unidades de disco locales y dispositivos electrónicos extraíbles, a menos que una necesidad de negocio definida los autorice de manera explícita.

Para asegurar que todo el personal sea consciente de sus responsabilidades de no almacenar ni copiar datos de titulares de tarjetas en sus computadoras personales locales ni otros medios, su política debe prohibir dichas actividades de manera clara, a excepción del personal autorizado explícitamente para hacerlo. Cualquiera de dicho personal autorizado es responsable de asegurar que los datos de los titulares de tarjetas que tengan en su poder se manipulen de conformidad con todos los requisitos de las PCI DSS, ya que el entorno del personal remoto ahora se considera parte del entorno de datos de los titulares de tarjetas de la organización.

12.4 Asegúrese de que la política y los procedimientos de seguridad definan claramente las responsabilidades de seguridad de la información de todo el personal

Sin la asignación de roles de seguridad ni responsabilidades claramente definidas, podría haber una interacción que no concuerde con el grupo de seguridad, lo que podría tener como resultado la implementación no segura de tecnologías o el uso desactualizado o no seguro de tecnologías.

12.5 Asigne las siguientes responsabilidades de administración de seguridad de la información a una persona o equipo:

12.5.1 Establezca, documente y distribuya políticas y procedimientos de seguridad.

12.5.2 Supervise y analice las alertas e información de seguridad, y distribúyalas entre el personal correspondiente.

12.5.3 Establezca, documente y distribuya los procedimientos de respuesta ante incidentes de seguridad y escalación para garantizar un manejo oportuno y efectivo de todas las situaciones.

12.5.4 Administre las cuentas de usuario, incluidas las adiciones, eliminaciones y modificaciones

12.5.5 Supervise y controle todo acceso a datos.

Cada persona o equipo con responsabilidades sobre la administración de seguridad de la información debe ser claramente consciente de sus responsabilidades y tareas relacionadas a través de una política específica. Sin esta responsabilidad, las brechas de los procesos pueden abrir accesos a recursos críticos y a los datos de los titulares de tarjetas.

12.6 Implemente un programa formal de concienciación sobre seguridad para que todo el personal tome conciencia de la importancia de la seguridad de los datos de los titulares de tarjetas.

Si el personal no conoce sus responsabilidades de seguridad, las defensas y los procesos de seguridad que se han implementado pueden volverse ineficaces a causa de errores o acciones intencionales.


Requisito Guía

12.6.1 Eduque al personal inmediatamente después de la contratación y por lo menos una vez al año.

Nota: Los métodos pueden variar según el rol del personal y su nivel de acceso a los datos de titulares de tarjetas.

Si el programa de concienciación sobre seguridad no incluye sesiones de repaso periódicas, se pueden evadir los procesos y procedimientos clave de seguridad, lo que podría exponer recursos críticos y datos de titulares de tarjetas. El centro y la profundidad de las capacitaciones inicial y de repaso pueden variar según el rol del personal, y se deben adaptar según la audiencia particular. Por ejemplo, las sesiones para los administradores de la base de datos se pueden centrar en controles y procesos técnicos específicos, mientras que la capacitación para los cajeros de comercios se debe centrar en procedimientos para transacciones seguras

Considere incluir constantes actualizaciones de la concienciación a fin de mantener a los empleados al día con las políticas y los procedimientos actuales. El método de entrega también puede variar para adaptarse a la audiencia particular o la capacitación que se está impartiendo. Por ejemplo, las capacitaciones inicial y anual se pueden impartir a través de una sesión de capacitación formal de participación activa o por computadora, mientras las actualizaciones constantes periódicas se pueden impartir a través correos electrónicos, pósters, cartas, etc.

12.6.2 Exija al personal que reconozca al menos una vez al año haber leído y entendido la política y los procedimientos de seguridad de la empresa.

Requerir un reconocimiento de los empleados por escrito o electrónico ayuda a asegurar que han leído y comprendido las políticas y los procesos de seguridad, y que están y estarán comprometidos con el cumplimiento de dichas políticas.

12.7 Examine al personal potencial antes de contratarlo a fin de minimizar el riesgo de ataques desde fuentes internas. (Entre los ejemplos de verificaciones de antecedentes se incluyen el historial de empleo, registro de antecedentes penales, historial crediticio y verificación de referencias).

Nota : En el caso del personal potencial que se va a contratar como cajeros de un comercio, que sólo tienen acceso a un número de tarjeta a la vez al realizarse una transacción, este requisito constituye sólo una recomendación.

La realización de investigaciones exhaustivas de antecedentes antes de contratar al personal potencial, a quienes se otorgará acceso a los datos de titulares de tarjetas, reduce el riesgo de uso no autorizado de los PAN y otros datos de titulares de tarjetas por parte de personas con antecedentes cuestionables o criminales. Se espera que una empresa tenga una política y un proceso para realizar verificaciones de antecedentes, incluido su propio proceso de decisiones para el cual los resultados de las verificaciones de antecedentes tendrían un impacto sobre sus decisiones de contratación (y cuál sería el impacto).

Para que sea efectivo, el nivel de verificación de antecedentes debe ser apropiado para la posición particular. Por ejemplo, las posiciones que requieran mayor responsabilidad o que tengan acceso a datos o sistemas críticos pueden exigir verificaciones de antecedentes más detalladas que las posiciones de menor responsabilidad y acceso. También puede ser apropiado para el proceso cubrir transferencias internas, en las que el personal en posiciones de menor riesgo, y que no ha sido sometido a una verificación de antecedentes detallada, recibe ascensos o es transferido a posiciones de mayor responsabilidad o acceso.


Requisito Guía

12.8 Si los datos de titulares de tarjeta se comparten con proveedores de servicios, mantenga e implemente políticas y procedimientos a los fines de que los proveedores de servicio incluyan lo siguiente:

Si un comerciante o proveedor de servicios comparte datos de titulares de tarjetas con un proveedor de servicios, entonces se aplican ciertos requisitos para asegurar que dichos proveedores de servicios implementen una protección continua de dichos datos.

12.8.1 Mantenga una lista de proveedores de servicios. Rastrear a todos los proveedores de servicios identifica dónde se extiende el riesgo potencial hacia fuera de la organización.

12.8.2 Mantenga un acuerdo escrito que incluya una mención de que los proveedores de servicios son responsables de la seguridad de los datos de titulares de tarjetas que ellos tienen en su poder.

El reconocimiento de los proveedores de servicios no sólo evidencia su compromiso por mantener la debida seguridad de los datos de titulares de tarjetas obtenidos a partir de clientes, sino que también les hace responsables.

12.8.3 Asegúrese de que exista un proceso establecido para comprometer a los proveedores de servicios que incluya una auditoría de compra adecuada previa al compromiso.

El proceso asegura que una organización examine de manera exhaustiva e interna cualquier contratación de un proveedor de servicios. Dicho proceso debe incluir un análisis de riesgos previo al establecimiento de una relación formal con el proveedor de servicios.

12.8.4 Mantenga un programa para supervisar el estado de cumplimiento con las PCI DSS del proveedor de servicios.

Conocer el estado de cumplimiento de las PCI DSS del proveedor de servicios garantiza que éste cumple con los mismos requisitos a los que está sujeta su organización.

Si el proveedor de servicios ofrece diversos servicios, este requisito se aplica sólo a los servicios que en realidad se entregan al cliente, y sólo a aquellos servicios dentro del alcance de la evaluación de las PCI DSS del cliente. Por ejemplo, si un proveedor ofrece servicios de firewall/IDS y ISP, un cliente que sólo utilice el servicio de firewall/IDS incluiría únicamente ese servicio dentro del alcance de su evaluación de las PCI DSS.

12.9 Implemente un plan de respuesta a incidentes. Prepárese para responder de inmediato ante un fallo en el sistema.

Sin un riguroso plan de respuesta a incidentes de seguridad debidamente diseminado, leído y comprendido por las partes responsables, la confusión y la falta de una respuesta unificada podrían crear períodos de inactividad más prolongados para el negocio, la exposición innecesaria de medios al público y nuevas responsabilidades legales.


Requisito Guía

12.9.1 Cree el plan de respuesta a incidentes que se va a implementar en caso de fallos en el sistema. Asegúrese de que el plan aborde, como mínimo, lo siguiente:

� Roles, responsabilidades y estrategias de comunicación y contacto en caso de un riesgo que incluya, como mínimo, la notificación de las marcas de pago.

� Procedimientos específicos de respuesta a incidentes.

� Procedimientos de recuperación y continuidad comercial.

� procesos de realización de copia de seguridad de datos;

� Análisis de los requisitos legales para el informe de riesgos.

� Cobertura y respuestas de todos los componentes críticos del sistema.

� referencia o inclusión de procedimientos de respuesta a incidentes de las marcas de pago.

El plan de respuesta a incidentes debe ser exhaustivo y contener todos los elementos clave para permitir que su empresa responda de manera efectiva en caso de un fallo en el sistema que pueda afectar los datos de titulares de tarjetas.

12.9.2 Pruebe el plan al menos una vez al año. Sin las pruebas apropiadas, es posible descuidar los pasos clave, lo que podría generar una mayor exposición durante un incidente.

Si durante el último año, se activó el plan de respuesta a incidentes en su totalidad, cubrir todos los componentes del plan, revisar en detalle el incidente real y su respuesta podría ser suficiente para proporcionar una prueba adecuada. Si sólo se activaron algunos de los componentes del plan recientemente, se debe probar el resto de los componentes. Si, durante los últimos doce meses, no se activó ninguno de los componentes del plan, la prueba anual debe incluir todos los componentes del plan.

12.9.3 Designe personal especializado que se encuentre disponible permanentemente para responder a las alertas.

12.9.4 Proporcione capacitación adecuada al personal sobre las responsabilidades de respuesta ante fallos de seguridad.

Sin un equipo de respuesta a incidentes capacitado y fácilmente disponible, podría producirse mayor daño para la red, además, los datos y sistemas críticos se pueden “contaminar” si los sistemas objetivo se manipulan indebidamente. Esto puede entorpecer el éxito de una investigación posterior al incidente. Si no están disponibles los recursos internos, considere contratar a un proveedor que proporcione estos servicios.

12.9.5 Incluya alertas de sistemas de detección y prevención de intrusiones, y de supervisión de integridad de archivos.

Estos sistemas de supervisión están diseñados para centrarse en el riesgo potencial para los datos, son críticos a la hora de ejecutar una acción para prevenir un fallo y se deben incluir en los procesos de respuesta a incidentes.

12.9.6 Elabore un proceso para modificar y desarrollar el plan de respuesta a incidentes según las lecciones aprendidas, e incorporar los desarrollos de la industria.

Incorporar las “lecciones aprendidas” en el plan de respuesta a incidentes ayuda a mantener el plan actualizado y a ser capaz de reaccionar ante las amenazas emergentes y las tendencias de seguridad.


Guía para el requisito A.1: Requisitos de las PCI D SS adicionales para proveedores de hosting compartido

Requisito A.1: Los proveedores de hosting compartid o protegen el entorno de daros de los titulares de tarjetas

Tal como se menciona en el Requisito 12.8, todos los proveedores de servicios con acceso a datos de titulares de tarjetas (incluidos los proveedores de hosting compartido) deben adherirse a las PCI DSS. Además, el requisito 2.4 establece que los proveedores de hosting compartido deben proteger el entorno y los datos que aloja cada entidad. Por lo tanto, los proveedores de hosting compartido deben cumplir además con los requisitos de este Anexo.

Requisito Guía

A.1 Proteger el entorno y los datos alojados de cada entidad (es decir comerciante, proveedor de servicio u otra entidad), según A.1.1 a A.1.4:

Un proveedor de hosting debe cumplir con estos requisitos, así como también con las demás secciones correspondientes de PCI DSS.

Nota: Aunque posiblemente el proveedor de hosting cumpla con estos requisitos, no se garantiza el cumplimiento de la entidad que utiliza al proveedor de hosting. Cada entidad debe cumplir con las PCI DSS y validar el cumplimiento según corresponda.

Anexo A de las PCI DSS está dirigido a proveedores de hosting compartido que deseen proporcionar a sus clientes comerciantes o proveedores de servicio un entorno de hosting que cumpla con las PCI DSS. Estos pasos deben cumplirse, además de todos los otros requisitos relevantes de las PCI DSS.

A.1.1 Asegúrese de que cada entidad sólo lleve a cabo procesos con acceso al entorno de datos de titulares de tarjetas de la entidad.

Si se permite a un comerciante o proveedor de servicios ejecutar sus propias aplicaciones en el servidor compartido, éstas se deben ejecutar con el ID de usuario del comerciante o proveedor de servicios y no como un usuario con privilegios. Un usuario privilegiado tendría acceso a todos los entornos de datos de titulares de tarjetas de todos los otros comerciantes y proveedores de servicio.

A.1.2 Restrinja el acceso y los privilegios de cada entidad para que sólo contengan el entorno de datos de titulares de tarjetas.

Para asegurar que los privilegios y accesos sean restringidos de manera tal que cada comerciante o proveedor de servicios tenga acceso sólo a su propio entorno de datos de titular de tarjeta, considere lo siguiente: (1) privilegios del ID de usuario del servidor web del comerciante o proveedor de servicio; (2) los permisos de lectura, escritura y ejecución otorgados; (3) los permisos de escritura en binarios del sistema; (4) permisos otorgados a archivos de registro del comerciante y del proveedor de servicios; y (5) controles para asegurar que un comerciante o un proveedor de servicios no monopolicen los recursos del sistema.

A.1.3 Asegúrese de que los registros y las pistas de auditoría estén habilitados y sean exclusivos para el entorno de datos de titulares de tarjetas de cada entidad, así como también que cumplan con el

Los registros deben estar disponibles en un entorno de hosting compartido, de manera que los comerciantes y proveedores de servicio tengan acceso y puedan revisar registros específicos de su entorno de datos de titulares de tarjetas.


Requisito Guía Requisito 10 de las PCI DSS.

A.1.4 Habilite los procesos para proporcionar una investigación forense oportuna en caso de riesgos para un comerciante o proveedor de servicios alojado.

Los proveedores de alojamiento compartido deben tener procesos que proporcionen respuestas rápidas y sencillas en caso de que sea necesaria una investigación la existencia de riesgos, hasta el nivel de detalle que sea necesario de manera que los detalles de un proveedor de servicios o de un comerciante individual.


Anexo A: Norma de seguridad de datos de la PCI: Doc umentos relacionados Los documentos siguientes fueron creados para asistir a los comerciantes y a los proveedores de servicio en la compresión de la Norma de seguridad de datos de la PCI y requisitos y responsabilidades de cumplimiento.

Documento Audiencia

Requisitos de la norma de seguridad de datos de la PCI y procedimientos de evaluación de seguridad

Todos los comerciantes y proveedores de servicio

Navegación de las PCI DSS: Comprensión del objetivo de los requisitos


Norma de seguridad de datos de la PCI: Instrucciones y directrices para el cuestionario de autoevaluación


Norma de seguridad de datos de la PCI: Cuestionario A de autoevaluación y declaración

Comerciantes elegibles9

Norma de seguridad de datos de la PCI: Cuestionario B de autoevaluación y declaración


Norma de seguridad de datos de la PCI: Cuestionario C-VT de autoevaluación y declaración


Norma de seguridad de datos de la PCI: Cuestionario C de autoevaluación y declaración


Norma de seguridad de datos de la PCI: Cuestionario D de autoevaluación y declaración

Los comerciantes y proveedores de servicio elegibles9

Glosario de términos, abreviaturas y acrónimos de las PCI DSS y PA-DSS


9 Para determinar el Cuestionario de autoevaluación correcto, véase Norma de seguridad de datos de la PCI: Instrucciones y directrices para contestar el cuestionario de

autoevaluación, “Selección de las SAQ y Declaración de que se aplica mejor a su organización”.

normas de seguridad de datos de la industria de tarjetas ... · tarjetas de pago, así como el...

Documents