Industria de Tarjetas de Pago (PCI) Normas de Seguridad de ...€¦ · de la red que posee los...

Industria de Tarjetas de Pago (PCI) Normas de Seguridad de Datos Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago

Entendiendo la Intención de los Requisitos Versión 1.1 Febrero 2008

Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Febrero 2008 Entendiendo la Intención de los Requisitos Página i Copyright 2008 PCI Security Standards Council LLC

Contenido

Datos de Tarjetahabientes y Elementos de Datos Confidenciales de Autenticación .................................................. iii Ubicación de los Datos de los Tarjetahabientes y Datos Confidenciales de Autenticación ................................................................................... v Datos de la Pista 1 y Datos de la Pista 2 ................................................................................................................................................................ vi

Orientaciones Relacionadas con las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago ........ Error! Bookmark not defined.

Orientaciones para los Requisitos 1 y 2: Desarrollar y Mantener una Red Segura ................................................................... 3 Requisito 1: Instalar y mantener una configuración de cortafuegos para proteger los datos de los tarjetahabientes .......................................... 3 Requisito 2: No usar contraseñas del sistema y otros parámetros de seguridad provistos por los suplidores ...................................................... 9

Orientaciones para los Requisitos 3 y 4: Proteger los Datos de los Tarjetahabientes ............................................................. 12 Requisito 3: Proteger los datos de los tarjetahabientes que estén almacenados ................................................................................................ 12 Requisito 4: Encriptar los datos de los tarjetahabientes e información confidencial transmitida a través de redes públicas abiertas ................ 18

Orientaciones para los Requisitos 5 and 6: Mantener un Programa de Manejo de Vulnerabilidad .................................... 20 Requisito 5: Usar y mantener regularmente el software o programas antivirus ................................................................................................... 20 Requisito 6: Desarrollar y mantener sistemas y aplicaciones seguros ................................................................... Error! Bookmark not defined.

Orientaciones para los Requisitos 7, 8 y 9: Implementar Medidas Sólidas de Control de Acceso .................................... 26 Requisito 7: Restringir el acceso a los datos de los tarjetahabientes tomando como base la necesidad del funcionario de conocer la información ............................................................................................................................................................................................................ 26 Requisito 8: Asignar una identificación única a cada persona que tenga acceso a un computador .................................................................... 27 Requisito 9: Restringir el acceso físico a los datos de los tarjetahabientes.......................................................................................................... 32

Orientaciones para los Requisitos 10 y 11: Monitorear y Probar Regularmente las Redes ................................................ 36 Requisito 10: Rastrear y monitorear todo el acceso a los recursos de la red y datos de los tarjetahabientes ..................................................... 36 Requisito 11: Probar regularmente los sistemas y procesos de seguridad .......................................................................................................... 40

Orientaciones para el Requisito 12: Mantener una Política de Seguridad de la Información ......................................... 43 Requisito 12: Mantener una política que contemple la seguridad de la información para los empleados y contratistas ..................................... 43

Orientaciones para el Requisito A.1: Aplicabilidad de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago para Proveedores de Servicio de Hospedaje Web .................................. 50

Apéndice A: Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Documentos Relacionados ... 52

Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Febrero 2008 Entendiendo la Intención de los Requisitos Página ii Copyright 2008 PCI Security Standards Council LLC

Prefacio Este documento describe los doce requisitos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) y ofrece orientaciones que explican la intención de cada requisito. La intención de este documento es asistir a los comercios, proveedores de servicio e instituciones financieras que deseen llegar a un entendimiento más claro de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago, el significado y la intención específica que hay detrás de cada requisito detallado para garantizar la seguridad de los componentes de sistemas (servidores, redes, aplicaciones, etc.), que brindan soporte a los ambientes de datos de tarjetahabientes. NOTA: Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Entendiendo la Intención de los Requisitos es un documento que sólo se deberá usar para fines de orientación. Al realizar auditorías in situ o completar el Cuestionario de Autoevaluación (SAQ), los documentos oficiales a utilizar son las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS), versión 1.1, los Procedimientos de Auditoría de Seguridad de Normas de Seguridad de Datos de la Industria de Tarjetas de Pago, y los Cuestionarios de Autoevaluación, versión 1.1. Los requisitos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago se aplican a todos los componentes de sistemas que están incluidos en el ambiente de datos de los tarjetahabientes o conectados al mismo. El ambiente de datos de los tarjetahabientes es la parte de la red que posee los datos de los tarjetahabientes o los datos confidenciales de autenticación, incluyendo los componentes de red, los servidores y las aplicaciones.

Los componentes de red pueden incluir, sin limitación, cortafuegos, switches, ruteadores, puntos de acceso inalámbrico, aparatos conectados a la red y otros aparatos y dispositivos de seguridad.

Los tipos de servidores incluyen, sin limitación, los siguientes: Web, base de datos, autenticación, correo, proxy, Network Time Protocol (NTP) y servidores de nombre de dominio (DNS).

Las aplicaciones incluyen, sin limitación, todas las aplicaciones adquiridas comercialmente o individualmente desarrolladas, incluyendo aplicaciones internas y externas (Internet).

Una segmentación adecuada de la red, que aísla los sistemas que guardan, procesan o transmiten datos de los tarjetahabientes de aquellos que no realizan estas funciones, podría reducir el alcance del ambiente de datos de los tarjetahabientes. Un Evaluador de Seguridad Calificado (QSA) puede asistir en la tarea de determinar el alcance dentro del ambiente de datos de tarjetahabientes de una entidad y brindar orientación sobre la forma en que se puede reducir el alcance de la evaluación relacionada con las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago implementando una segmentación apropiada de la red. Para cualquier pregunta sobre si una implementación específica es congruente con las normas o si la misma “cumple” con un requisito específico, el PCI Security Standards Council recomienda que las empresas consulten con un Evaluador de Seguridad Calificado a fin de validar su implementación de tecnologías y procesos y el cumplimiento con las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago. Los conocimientos especializados y la experiencia de los evaluadores de seguridad calificados que ya han trabajado con complejos ambientes de redes se prestan bien para brindar orientación sobre las mejores prácticas y a proporcionarle al comercio o proveedor de servicio la guía que necesita para cumplir con los requisitos. La lista de Evaluadores de Seguridad Calificados (QSA o Qualified Security Assessors) del PCI Security Standards Council se puede consultar en: https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf

Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Febrero 2008 Entendiendo la Intención de los Requisitos Página iii Copyright 2008 PCI Security Standards Council LLC

Datos de Tarjetahabientes y Elementos de Datos Confidenciales de Autenticación La tabla que aparece a continuación ilustra los elementos de datos confidenciales de los tarjetahabientes y de autenticación que normalmente se usan, e indica si se permite o se prohíbe guardar cada elemento de datos y si se requiere proteger cada elemento de datos. Esta tabla no es exhaustiva, pero se presenta únicamente con el fin de ilustrar los distintos tipos de requisitos que se aplican a cada elemento de datos. Los datos de los tarjetahabientes se definen como el número de cuenta primario (“PAN” o número de la tarjeta de crédito) y otros datos que se obtienen al realizar una transacción de pago, incluyendo los siguientes elementos de datos (vea la tabla que sigue para más detalles):

PAN o Número de Cuenta Primario Nombre del Tarjetahabiente Fecha de Vencimiento Código de Servicio Datos Confidenciales de Autenticación (1) todos los datos de la banda magnética, 2) CAV2/CVC2/CVV2/CID, y 3) PINes/bloques de PIN)

El Número de Cuenta Primario (PAN) es el factor que define la aplicabilidad de los requisitos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) y PA-DSS. Si no se guarda, procesa o transmite el Número de Cuenta Primario, estas normas no aplican.

Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Febrero 2008 Entendiendo la Intención de los Requisitos Página iv Copyright 2008 PCI Security Standards Council LLC

Elemento de Datos

Se Permite Guardar

Protección Requerida

PCI DSS Req. 3, 4

Datos de los Tarjetahabientes

Número de Cuenta Primario Sí Sí Sí

Nombre del Tarjetahabiente1 Sí Sí 1 No

Código de Servicio1 Sí Sí 1 No

Fecha de Vencimiento1 Sí Sí 1 No

Datos Confidenciales de Autenticación 2

Contenido de la Banda Magnética1 No N/A N/A

CAV2/CVC2/CVV2/CID No N/A N/A

PIN/Bloque de PIN No N/A N/A

1 Se requiere proteger estos elementos de datos si se guardan junto con el Número de Cuenta Primario (PAN). Esta protección debe cumplir con los requisitos

establecidos en las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) para la protección general del ambiente de tarjetahabientes. Además, otras leyes (por ejemplo, las relacionadas con la protección de los datos personales de los consumidores, la privacidad, el robo de identidad y la seguridad de datos) pueden requerir protecciones específicas para estos datos o la divulgación apropiada de las prácticas de privacidad de la empresa si se recopilan datos personales de los consumidores como parte de las actividades del negocio. Sin embargo, las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) no aplican si no se guardan, procesan o transmiten números de cuenta primarios (PAN).

2 No guarde datos confidenciales de autenticación, que tienen alta sensitividad, después de la autorización (aunque estén encriptados).

Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Febrero 2008 Entendiendo la Intención de los Requisitos Página v Copyright 2008 PCI Security Standards Council LLC

Ubicación de los Datos de los Tarjetahabientes y Datos Confidenciales de Autenticación Los datos confidenciales de autenticación son los datos de la banda magnética (o datos de la pista)3, el código o valor de validación de la tarjeta4, y los datos del PIN5. Está prohibido guardar datos confidenciales de autenticación. Estos datos son muy valiosos para los delincuentes que roban datos de los computadores—los llamados “hackers” o delincuentes cibernéticos—porque les permiten generar tarjetas de pago falsas y realizar transacciones fraudulentas. Vea el documento titulado Glosario, Abreviaturas y Acrónimos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago para obtener la definición completa de los datos de autenticación. Las siguientes ilustraciones del reverso y anverso de una tarjeta de crédito muestran dónde aparecen los datos del tarjetahabiente y los datos confidenciales de autenticación en el plástico.

3 Los datos codificados en la banda magnética se usan para fines de autorización durante una transacción con tarjeta presente. Las entidades no pueden retener

los datos completos de la banda magnética después de autorizada la transacción. Los únicos elementos de datos de la pista que se pueden retener son el número de cuenta, la fecha de vencimiento y el nombre.

4 El valor de tres o cuatro dígitos impreso sobre el panel de firma, a la derecha del mismo o en el anverso de una tarjeta de pago que se usa para verificar las transacciones con tarjeta ausente.

5 El Número de Identificación Personal (PIN) o clave que marca el tarjetahabiente durante una transacción con tarjeta presente y/o el bloque de PIN encriptado presente en el mensaje de transacción.

Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Febrero 2008 Entendiendo la Intención de los Requisitos Página vi Copyright 2008 PCI Security Standards Council LLC

Datos de la Pista 1 y Pista 2 Si se guardan los datos completos de la pista (de la Pista 1 o de la Pista 2) los delincuentes cibernéticos que obtengan esos datos podrán reproducir y vender tarjetas de pago en el mundo entero. El almacenaje de los datos completos de la pista también constituye una violación de los reglamentos operativos de las marcas de pago y puede dar lugar a multas y penalidades. La ilustración que aparece a continuación brinda información sobre los datos de la Pista 1 y la Pista 2, describiendo las diferencias y mostrando el formato de los datos contenidos en la banda magnética.

Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Febrero 2008 Entendiendo la Intención de los Requisitos Página vii Copyright 2008 PCI Security Standards Council LLC

Pista 1 Pista 2

Contiene todos los campos de las pistas 1 y 2 Longitud de hasta 79 caracteres

Tiempo de procesamiento más corto para las transmisiones con equipos de discado más antiguos

Longitud de hasta 40 caracteres

Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Febrero 2008 Entendiendo la Intención de los Requisitos Página 2 Copyright 2008 PCI Security Standards Council LLC

Orientaciones Relacionadas con las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago

Desarrollar y Mantener una Red Segura

Requisito 1: Instalar y mantener una configuración de cortafuegos para proteger los datos de los tarjetahabientes. Requisito 2: No usar contraseñas del sistema y otros parámetros de seguridad provistos por los suplidores.

Proteger los Datos de los Tarjetahabientes

Requisito 3: Proteger los datos de los tarjetahabientes que estén almacenados. Requisito 4: Encriptar los datos de los tarjetahabientes e información confidencial transmitida a través de redes públicas

abiertas.

Mantener un Programa de Manejo de Vulnerabilidad

Requisito 5: Usar y actualizar regularmente el software o programas antivirus. Requisito 6: Desarrollar y mantener sistemas y aplicaciones seguros.

Implementar Medidas Sólidas de Control de Acceso

Requisito 7: Restringir el acceso a los datos tomando como base la necesidad del funcionario de conocer la información. Requisito 8: Asignar una Identificación única a cada persona que tenga acceso a un computador. Requisito 9: Restringir el acceso físico a los datos de los tarjetahabientes.

Monitorear y Probar Regularmente las Redes

Requisito 10: Rastrear y monitorear todo el acceso a los recursos de la red y datos de los tarjetahabientes. Requisito 11: Probar regularmente los sistemas y procesos de seguridad.

Mantener una Política de Seguridad de la Información

Requisito 12: Mantener una política que contemple la seguridad de la información.


Orientaciones para los Requisitos 1 y 2: Desarrollar y Mantener una Red Segura

Requisito 1: Instalar y mantener una configuración de cortafuegos para proteger los datos de los tarjetahabientes. Los cortafuegos son dispositivos computarizados que controlan el tráfico permitido a y desde una red de computadores de una compañía, así como el tráfico a áreas vulnerables de la red interna de una compañía. El cortafuego examina todo el tráfico de la red y bloquea las transmisiones que no cumplen con los criterios de seguridad especificados.

Es necesario proteger todos los sistemas contra el acceso no autorizado desde Internet, sea para fines de comercio electrónico, acceso a Internet de los empleados a través de los navegadores de los computadores de escritorio o acceso al correo electrónico de los empleados. Con frecuencia algunas vías de conexión hacia y desde Internet aparentemente insignificantes pueden proporcionar un acceso sin protección a sistemas clave. Los cortafuegos son un mecanismo de protección esencial para cualquier red de computadores.

Requisito Orientación

1.1 Establecer normas de configuración de cortafuegos que incluyan lo siguiente:

Los cortafuegos son software o dispositivos de hardware que bloquean la entrada a la red cuando no se desea que alguien entre. Sin políticas y procedimientos establecidos para documentar la forma en que el personal debe configurar los cortafuegos, una compañía podría fácilmente perder su primera línea de defensa para la protección de sus datos.

1.1.1 Un proceso formal para aprobar y probar todas las conexiones externas de la red y los cambios a la configuración de cortafuegos.

Una política y un proceso para aprobar y probar todas las conexiones y cambios al cortafuego ayudará a prevenir problemas de seguridad a causa de una configuración errónea de la red o del cortafuego.

1.1.2 Un diagrama actualizado de la red con todas las conexiones que acceden a los datos de los tarjetahabientes, incluyendo cualquier red inalámbrica.

Los diagramas de la red permiten a la organización identificar la ubicación de todos los dispositivos en su red. Sin un diagrama de red es posible que se pase por alto algún dispositivo, y también podrían quedar sin protección algunos dispositivos sin que nadie se dé cuenta, lo cual los haría vulnerables a un compromiso de la seguridad.

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

Utilizar un cortafuego en cada conexión hacia y desde la red permite a la organización monitorear y controlar el acceso hacia dentro y hacia fuera de la red y minimizar las probabilidades de que un delincuente cibernético 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.

La descripción de los roles y la asignación de responsabilidades aseguran que alguien sea claramente responsable por la seguridad de todos los componentes y esté consciente de los mismos, y que ningún dispositivo quede sin administrar.



1.1.5 Lista documentada de los servicios y puertos necesarios para las actividades del negocio.

Los compromisos de la seguridad frecuentemente ocurren debido a servicios y puertos que no se usan o no tienen seguridad, ya que estos a menudo tienen vulnerabilidades conocidas y muchas organizaciones no instalan los parches de seguridad en el caso de los servicios y puertos que no usan (aunque las vulnerabilidades estén presentes). Cada organización debe decidir claramente cuáles servicios y puertos son necesarios para operar su negocio, documentarlos para que quede un registro de los mismos, y asegurar que todos los demás servicios y puertos se desactiven o eliminen. Igualmente, las organizaciones deben considerar un bloqueo de todo el tráfico y solamente volver a abrir esos puertos cuando se haya determinado y documentado la necesidad de utilizar los mismos.

1.1.6 Justificación y documentación de cualquier protocolo disponible aparte de Hypertext Transfer Protocol (HTTP) y Secure Sockets Layer (SSL,) Secure Shell (SSH,) y Virtual Private Network (VPN).

1.1.7 Justificación y documentación de cualquier protocolo riesgoso permitido (por ejemplo, File Transfer Protocol o FTP), que incluya la razón para usar el protocolo y las funciones de seguridad implementadas.

Existen muchos protocolos que una empresa podría necesitar (o que están activados por defecto) y que los delincuentes cibernéticos normalmente utilizan para comprometer la seguridad de una red. Además de la explicación sobre el 1.1.5, si es necesario utilizar protocolos riesgosos para el negocio, la organización debe entender claramente y aceptar el riesgo que esos protocolos significan para la empresa, el uso del protocolo debe estar justificado y las características de seguridad que permiten usar estos protocolos en forma segura deben estar documentadas e implementadas.

1.1.8 Revisión trimestral de los conjuntos de reglas de cortafuegos y ruteadores.

Esta revisión da a la organización una oportunidad trimestral para eliminar cualquier regla que no sea necesaria, esté obsoleta o incorrecta, y asegura que todos los reglamentos permitan solamente el uso de los servicios y puertos que la empresa justificadamente necesita emplear.

1.1.9 Normas de configuración de ruteadores. Junto con los cortafuegos, estos dispositivos forman parte de la arquitectura que controla los puntos de entrada a la red. Una política documentada ayuda al personal de la empresa a configurar y asegurar los ruteadores y garantiza que la primera línea de defensa de la organización en la protección de sus datos siga siendo sólida.

1.2 Desarrollar una configuración de cortafuegos que bloquee todo el tráfico de redes y hosts “no confiables”, excepto los protocolos necesarios para el ambiente de datos de los tarjetahabientes.

Si se instala un cortafuego pero no se establecen reglas que controlen o limiten ciertos tipos de tráfico, los usuarios maliciosos podrían explotar los protocolos y puertos vulnerables para lanzar ataques contra la red de la empresa.

1.3 Desarrollar una configuración de cortafuegos que restrinja las conexiones entre los servidores


Requisito Orientación públicamente accesibles y cualquier componente de sistemas que guarde datos de los tarjetahabientes, incluyendo cualquier conexión de redes inalámbricas. Esta configuración de cortafuegos debe incluir lo siguiente:

1.3.1 Restringir el tráfico entrante de Internet a las direcciones IP (Internet Protocol) dentro del DMZ (filtros de ingreso).

Normalmente un paquete contiene la dirección IP del computador que originalmente lo envió. Esto permite que otros computadores de la red sepan de dónde vino. En ciertos casos los delincuentes cibernéticos falsifican esta dirección IP remitente. Por ejemplo, el delincuente envía un paquete con una dirección falsa para que (a menos que su cortafuego lo prohíba) el paquete pueda entrar a la red de la empresa desde Internet como si fuera tráfico interno, y, por lo tanto, legítimo. Una vez que el delincuente ha penetrado la red puede comenzar a comprometer la seguridad de los sistemas de la empresa. Los filtros de ingreso son una técnica que puede usar en su cortafuego para filtrar los paquetes que entran a su red y, entre otras cosas, asegurar que los paquetes no se hayan falsificado para fingir que vienen de su propia red interna. Para obtener más información sobre los filtros de paquetes, considere obtener información sobre una técnica complementaria llamada “filtros de egreso”.

1.3.2 No permitir que las direcciones internas pasen de Internet al DMZ.

1.3.3 Implementar la inspección completa, también conocida como filtrado dinámico de paquetes (es decir, solamente se permite la entrada a la red a través de las conexiones “establecidas”).

Un cortafuego que realiza una inspección completa mantiene el “estado” (o “status”) de cada conexión al cortafuego. Al mantenerse el estado, el cortafuego sabe si lo que parece ser la respuesta a una conexión previa es realmente una respuesta (ya que “recuerda” la conexión previa), o si se trata de alguien que está tratando de lograr con algún truco que el cortafuego permita la conexión.

1.3.4 Colocar la base de datos en una zona interna de la red, segregada del DMZ.

La información de cuenta de la tarjeta de pago requiere el más alto nivel de protección. Si la información de la cuenta está localizada dentro del DMZ, el acceso a esta información por parte de un atacante externo es más fácil, ya que hay menos capas que penetrar. Sin un cortafuego que proteja la información de las cuentas los datos están vulnerables a cualquier usuario malicioso que intente acceder a los mismos desde una red plana, y a cualquier delincuente que logre penetrar la red desde fuera.

1.3.5 Restringir el tráfico entrante y saliente a aquel que sea necesario para el ambiente de datos

La intención de este requisito es impedir a los delincuentes cibernéticos que accedan a la red de la organización por medio de una dirección IP no


Requisito Orientación de tarjetahabientes. autorizada o que usen servicios, protocolos y puertos en forma no autorizada

(por ejemplo, para enviar datos que hayan obtenido dentro de su red a un servidor externo).

1.3.6 Asegurar y sincronizar los archivos de configuración de ruteador. Por ejemplo, los archivos de configuración (para el funcionamiento normal de los ruteadores) y los archivos de configuración de inicio de operaciones (cuando se hace un re-booting de las máquinas), deben tener la misma configuración segura.

Aunque los archivos de configuración activos normalmente se implementan con parámetros de seguridad, los archivos de inicio (los ruteadores sólo ejecutan estos archivos al reinicio) podrían no estar implementados con los mismos parámetros seguros porque solamente se ejecutan ocasionalmente. Cuando un ruteador se reinicia sin los mismos parámetros de seguridad que tienen los archivos de configuración, ello podría traer como resultado un debilitamiento de las reglas que permitiría a un delincuente cibernético penetrar la red.



1.3.7 Rechazar todo el tráfico entrante y saliente de Internet que no esté específicamente permitido.

Todos los cortafuegos deben incluir una regla que bloquee todo el tráfico entrante y saliente que no sea específicamente necesario. Ello prevendrá brechas inadvertidas que podrían permitir que un tráfico indeseable y potencialmente dañino entre o salga de la red.

1.3.8 Instalar cortafuegos perimétricos entre cualquier red inalámbrica y el ambiente de datos de los tarjetahabientes y configurar estos cortafuegos para rechazar cualquier tráfico del ambiente inalámbrico o controlar (si dicho tráfico es necesario para los fines del negocio) todo el tráfico desde el ambiente inalámbrico.

La implementación y explotación (a sabiendas o no) de la tecnología inalámbrica dentro de una red es una vía común para que los usuarios maliciosos obtengan acceso a la red y a los datos de los tarjetahabientes. Si se instala un dispositivo o red inalámbrica sin conocimiento de la compañía, un delincuente podría fácil e “invisiblemente” entrar a la red. Si los cortafuegos no restringen el acceso desde redes inalámbricas al ambiente de tarjetas de pago, los delincuentes que obtengan acceso no autorizado a la red inalámbrica podrían fácilmente conectarse con el ambiente de tarjetas de pago y comprometer la seguridad de la información de las cuentas.

1.3.9 Instalar software de cortafuego personal en cualquier computador móvil o de propiedad de los empleados con conectividad directa a Internet (por ejemplo, laptops que usan los empleados), mediante el cual se acceda a la red de la organización.

Si un computador no tiene instalado un cortafuego o programa antivirus, es posible descargar sin saberlo algún tipo de spyware, troyano, virus o gusano (malware). El computador está aún más vulnerable cuando está conectado directamente a Internet y no está detrás del cortafuego corporativo. Los programas dañinos que se cargan a un computador que no está protegido por el cortafuego corporativo podrían entonces dirigirse maliciosamente a la información que se encuentra dentro de la red cuando el computador se reconecta a la red corporativa.

1.4 Prohibir el acceso público directo entre redes externas y cualquier componente de sistema que guarde datos de los tarjetahabientes (por ejemplo, bases de datos).

La intención del cortafuego es administrar y controlar todas las conexiones entre los sistemas públicos y los sistemas internos (especialmente aquellos sistemas que guardan datos de los tarjetahabientes). Si se permite un acceso directo entre los sistemas públicos y los que almacenan datos de los tarjetahabientes, las protecciones que ofrece el cortafuego se pasan por alto y la seguridad de los componentes de sistemas que guardan datos de los tarjetahabientes podría verse comprometida.

1.4.1 Implementar un DMZ para filtrar y controlar todo el tráfico y prohibir las rutas directas para el tráfico entrante y saliente de Internet.

El DMZ es la parte del cortafuego que queda frente a la red pública, Internet, y administra las conexiones entre Internet y los servicios internos que una organización necesita tener a disposición del público (como, por ejemplo, un servidor de 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 necesita esta comunicación.



1.4.2 Restringir el tráfico saliente desde las aplicaciones de tarjetas de pago a las direcciones de Internet (IP) dentro del DMZ.

El DMZ también debe evaluar todo el tráfico saliente de la red para asegurar que todo ese tráfico saliente siga las reglas establecidas. Para que el DMZ pueda realizar eficazmente esta función las conexiones desde dentro de la red a cualquier dirección fuera de la red no deben permitirse, a menos que pasen por el DMZ y sean evaluadas allí para garantizar su legitimidad.

1.5 Implementar máscaras de IP para prevenir que las direcciones internas se traduzcan y revelen en Internet. Usar tecnologías que implementan el espacio de dirección RFC 1918 tales como Port Address Translation (PAT) o Network Address Translation (NAT).

La implementación de máscaras de IP, que son administradas por el cortafuego, permite a la organización tener direcciones internas que solamente son visibles dentro de la red y direcciones externas que sólo son visibles externamente. Si un cortafuego no “oculta” o enmascara las direcciones de IP de la red interna, es posible que un delincuente cibernético descubra las direcciones de IP de la red interna e intente acceder a la red con una dirección de IP falsa.


Requisito 2: No usar contraseñas de sistemas y otros parámetros de seguridad provistos por los proveedores. Los delincuentes que roban datos de computadores—comúnmente llamados “hackers” o delincuentes cibernéticos, y que pueden ser externos o internos en una compañía—a menudo usan las contraseñas y otras opciones automáticamente programadas por los proveedores para comprometer la seguridad de los sistemas. Estas contraseñas y opciones son bien conocidas entre los delincuentes y fácilmente se determinan por medio de información pública.


2.1 Cambiar siempre los valores por defecto de los proveedores antes de instalar un sistema en la red (por ejemplo, incluir contraseñas, cadenas comunitarias SNMP (Simple Network Management Protocol), y eliminar cuentas innecesarias).

Los delincuentes cibernéticos (externos e internos en una compañía) frecuentemente utilizan los valores, nombres de cuenta y contraseñas por defecto de los proveedores para comprometer la seguridad de los sistemas. Estos valores por defecto son bien conocidos por los delincuentes y hacen que el sistema de su organización sea altamente vulnerable a un ataque.

2.1.1 En los ambientes inalámbricos, cambiar los valores por defecto programados por los vendedores del equipo inalámbrico, incluyendo, sin limitación, claves Wireless Equivalent Privacy (WEP), Service Set Identifier (SSID) de selección automática, contraseñas y cadenas comunitarias SNMP. Deshabilitar transmisores SSID. Habilitar la tecnología Wi-Fi Protected Access (WPA y WPA2) para la encriptación y la autenticación cuando exista capacidad WPA.

Muchos usuarios instalan estos dispositivos sin aprobación de la administración y no cambian los valores por defecto ni configuran los parámetros de seguridad. Si no se implementan las redes inalámbricas con suficientes configuraciones de seguridad (inluyendo el cambio de valores por defecto) los “sniffers” que espían las redes inalámbricas podrían espiar el tráfico, fácilmente capturar datos y contraseñas y penetrar y atacar su red. Además, el protocolo de cambio de claves de la versión 802.11x Encryption (WEP) más antigua ha sido descifrado y puede inutilizar la encriptación.

2.2 Desarrollar normas de configuración para todos los componentes de sistemas. Asegurar que estas normas contemplen todas las vulnerabilidades de seguridad conocidas y sean congruentes con las normas de alta seguridad aceptadas en la industria, por ejemplo, por SysAdmin Audit Network Security Networks (SANS), el National Institute of Standards Technology (NIST) y el Center for Internet Security (CIS).

Existen debilidades conocidas en muchos sistemas operativos, bases de datos y aplicaciones empresariales y también existen formas conocidas de configurar estos sistemas para subsanar las vulnerabilidades de seguridad. A fin de ayudar a los que no son expertos en seguridad, las firmas especializadas en seguridad han establecido recomendaciones para aumentar la seguridad de los sistemas, las cuales sirven de asesoría para corregir estas debilidades. Si estas debilidades de los sistemas no se subsanan—por ejemplo, parámetros débiles de archivos o servicios y protocolos por defecto (para los servicios y protocolos que no se usan a menudo)—un atacante podrá usar muchas de estas debilidades conocidas para atacar los servicios y protocolos vulnerables y obtener así acceso a la red de su organización.



2.2.1 Implementar solamente una función primaria por cada servidor (por ejemplo, los servidores de Web, servidores de base de datos y DNS se deben implementar en servidores separados).

La intención en este caso es asegurar que las normas de configuración de sistemas de su organización y los procesos relacionados contemplen las funciones de servidor que necesitan tener diferentes niveles de seguridad o que pueden introducir debilidades de seguridad a otras funciones en el mismo servidor. Por ejemplo: 1. Una base de datos que necesita tener medidas de alta seguridad

establecidas estaría en riesgo si comparte un servidor con una aplicación de Web que necesita ser abierta y conectar directamente hacia Internet.

2. No aplicar un parche de seguridad a una función aparentemente de menor importancia podría traer como resultado un compromiso de la seguridad que tenga un impacto en otras funciones más importantes (como la de una base de datos) en el mismo servidor.

La intención de este requisito es aplicarlo a los servidores (normalmente Unix, Linux, o basado en Windows), pero no a los sistemas mainframe.

2.2.2 Deshabilitar todos los servicios y protocolos innecesarios (servicios y protocolos que no sean directamente necesarios para realizar la función especificada de los dispositivos).

Como se indica en el 1.1.7, muchos protocolos que una empresa podría necesitar (o tener activados por defecto) son comúnmente utilizados por los delincuentes cibernéticos para comprometer la seguridad de una red. Para asegurar que estos servicios y protocolos estén deshabilitados cuando se instalen nuevos servidores, este requisito debe ser parte de las normas de configuración de su organización y los procesos relacionados.

2.2.3 Configurar los parámetros de seguridad del sistema para prevenir el uso indebido.

La intención de este requisito es garantizar que las normas de configuración de sistemas de su organización y los procesos relacionados contemplen específicamente las programaciones y parámetros de seguridad que tienen implicaciones conocidas para la seguridad.

2.2.4 Eliminar todas las funcionalidades innecesarias, tales como archivos de comandos (scripts), accionadores, funciones, subsistemas, sistemas de archivos y servidores de Web innecesarios.

Las normas para aumentar la seguridad de los servidores deben incluir procesos que contemplen las funcionalidades innecesarias que tengan implicaciones específicas para la seguridad (como eliminar/deshabilitar los protocolos de transferencia de archivo o el servidor de Web si el servidor no va a realizar esas funciones).

2.3 Encriptar todo el acceso administrativo que no sea de consola. Usar tecnologías como SSH, VPN o SSL/TLS (Transport Layer Security) para la administración basada en Web y otros tipos de acceso administrativo sin consola.

Si la administración remota no se realiza con autenticación segura y mediante comunicaciones encriptadas, la información confidencial a nivel administrativo u operativo (como las contraseñas de los administradores) podría ser revelada a un espía. Un delincuente cibernético podría utilizar esta información para acceder a la red, hacerse pasar por un administrador del sistema y robar datos.



2.4 Los proveedores de servicio de hospedaje Web deben proteger el ambiente hospedado y los datos de cada entidad. Estos proveedores deben cumplir con requisitos específicos detallados en las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago. Consulte el “Apéndice A: “Aplicabilidad de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago para los Proveedores de Servicios de Hospedaje Web.”

Este requisito se aplica a los proveedores de servicio de hospedaje Web que mantienen ambientes de hospedaje compartidos por múltiples clientes en el mismo servidor. Cuando todos los datos se encuentran en el mismo servidor y bajo el control de un solo ambiente, a menudo los valores de programación de estos servidores compartidos no pueden ser administrados por los clientes individuales, y los clientes pueden agregar funciones no seguras y archivos de comandos que afectan la seguridad de los ambientes de todos los demás clientes, facilitándole a un delincuente el poder comprometer la seguridad de los datos de un cliente y obtener así acceso a los datos de todos los demás clientes. Vea también en este documento la sección “Orientaciones para el Requisito A.1”.


Orientaciones para los Requisitos 3 y 4: Proteger los Datos de los Tarjetahabientes

Requisito 3: Proteger los datos de los tarjetahabientes que están almacenados. La encriptación es un componente crítico para la protección de los datos de los tarjetahabientes. Si un intruso subvierte otros controles de seguridad de red y obtiene acceso a los datos encriptados, sin las claves criptográficas no podrá leer ni utilizar esos datos. Otros métodos eficaces para proteger los datos almacenados deberían considerarse como oportunidades potenciales para mitigar el riesgo. Por ejemplo, los métodos para minimizar el riesgo incluyen no guardar datos de los tarjetahabientes a menos que sea absolutamente necesario, truncar los datos de los tarjetahabientes si no se necesita el Número de Cuenta Primario (PAN) completo y no enviar el Número de Cuenta Primario en correos electrónicos no encriptados.


3.1 Mantener un mínimo de datos de tarjetahabientes almacenados. Desarrollar una política de retención de datos y una política para disponer de los datos. Limitar la cantidad de datos almacenados y el tiempo de retención a los que se requieren para fines comerciales, legales y/o regulatorios, según se haya documentado en la política de retención de datos.

El almacenaje de los datos de los tarjetahabientes más allá del tiempo necesario para fines del negocio crea un riesgo innecesario. Los únicos datos de los tarjetahabientes que se pueden guardar son el número de cuenta primario o PAN (en forma ilegible), la fecha de vencimiento, el nombre y código de servicio. Recuerde: si no lo necesita, ¡no lo guarde!

3.2 No almacenar datos de autenticación confidenciales después de la autorización (ni siquiera en forma encriptada).

Los datos confidenciales de autenticación incluyen los datos citados en los Requisitos 3.2.1 a 3.2.3:

Los datos confidenciales de autenticación son los datos de la banda magnética (o pista)6, el código de validación o valor de la tarjeta7, y los datos del PIN8. Está prohibido guardar los datos confidenciales de autenticación. Estos datos son muy valiosos para los delincuentes, ya que les permite fabricar tarjetas de pago falsas y generar transacciones fraudulentas. Vea el documento titulado Glosario, Abreviaturas y Acrónimos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago para obtener la definición completa de los “datos confidenciales de autenticación”.

6 Los datos codificados en la banda magnética se usan para procesar la autorización durante una transacción con tarjeta presente. Las entidades no pueden retener los datos

completos de la banda magnética después que la transacción se autoriza. Los únicos elementos de datos de la pista que se pueden retener son el número de cuenta, la fecha de vencimiento y el nombre.

7 El valor de tres o cuatro dígitos impreso en el panel de firma o a la derecha del mismo o en el anverso de una tarjeta de pago, el cual se utiliza para verificar las transacciones con tarjeta ausente. 8 El número de identificación personal (PIN) que marca el tarjetahabiente durante una transacción con tarjeta presente y/o el bloque de PIN encriptado presente dentro del mensaje de transacción.



3.2.1 No guardar el contenido íntegro de ninguna pista de banda magnética (en el reverso de una tarjeta, en un chip, o en cualquier otro lugar). Estos datos alternativamente se conocen como pista completa, pista 1, pista, pista 2 y datos de la banda magnética. En el curso normal de los negocios es posible que sea necesario retener los siguientes elementos de datos de la banda magnética: el nombre del titular de la cuenta, el número de cuenta primario o PAN, la fecha de vencimiento y el código de servicio. A fin de minimizar el riesgo, guarde solamente aquellos elementos de datos que se necesiten por razones de negocio. NUNCA guarde el código de verificación de tarjeta o elementos de verificación de PIN. Nota: Vea el documento titulado “Glosario, Abreviaturas y Acrónimos” de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago para obtener información adicional.

Si se guarda el contenido íntegro de la pista los delincuentes cibernéticos que obtengan esos datos pueden reproducir y vender tarjetas de pago alrededor del globo. El almacenaje de los datos de la pista también viola los reglamentos operativos de las marcas de pago y puede conducir a multas y penalidades.

3.2.2 No guardar el valor o código de validación de tarjeta (número de tres o cuatro dígitos impreso en el anverso o reverso de una tarjeta de pago) utilizado para verificar las transacciones con tarjeta ausente. Nota: Vea el documento titulado “Glosario, Abreviaturas y Acrónimos” de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago para obtener información adicional.

La finalidad del código de validación de tarjeta es proteger las transacciones con tarjeta ausente (Internet y órdenes por correo y teléfono), donde ni el consumidor ni la tarjeta están presentes en el momento de realizarse la transacción. Estos tipos de transacciones se pueden autenticar como realizadas por el titular de la tarjeta solamente solicitando este código de validación de tarjeta, ya que el titular de la tarjeta tiene el plástico en su posesión y puede leer el valor. Si este dato se almacena y después es robado los delincuentes pueden llevar a cabo transacciones fraudulentas por Internet y por correo y teléfono. Por eso está prohibido guardar este valor. El almacenaje de este valor también viola los reglamentos de las marcas de pago y puede conducir a multas y penalidades.

3.2.3 No guardar el Número de Identificación Personal (PIN) o el bloque de PIN encriptado.

Estos valores deben ser conocidos solamente por el titular de la tarjeta o el banco que emitió la misma. Si se almacenan estos datos y después son robados los delincuentes pueden llevar a cabo transacciones fraudulentas de


Requisito Orientación débito que requieren el uso del PIN (por ejemplo, retiros de efectivo en cajeros automáticos). Por eso está prohibido almacenarlos. El almacenaje de estos datos también viola los reglamentos de las marcas de pago y puede conducir a multas y penalidades.

3.3 Enmascarar los números de cuenta cuando se desplieguen (los primeros seis y los últimos cuatro dígitos son el número máximo de dígitos que se puede desplegar). (Nota: Este requisito no se aplica a empleados y otras entidades que tienen específicamente necesidad de ver el Número de Cuenta Primario, ni supersede los requisitos más estrictos establecidos para el despliegue de datos de los tarjetahabientes (por ejemplo, en recibos de terminales de punto de venta [POS]).

El despliegue del número de cuenta primario o PAN completo en pantallas de computadores, recibos de tarjeta de pago, telefacsímiles o reportes en papel puede traer como resultado que personas no autorizadas obtengan y utilicen fraudulentamente el número de cuenta. Tenga presente que este dato se puede desplegar completo en la “copia del comercio” de los recibos o en los casos en que específicamente se necesite ver el número de cuenta primario completo.

3.4 Asegurar que el Número de Cuenta Primario (PAN), como mínimo, sea ilegible en cualquier lugar donde esté guardado (incluyendo datos en medios digitales portátiles, medios de respaldo, registros o bitácoras, y datos recibidos de redes inalámbricas o guardados en las mismas) utilizando los siguientes métodos:

No proteger los números de cuenta primarios podría permitir que usuarios internos no autorizados e intrusos vean o descarguen estos datos. Los números de cuenta primarios guardados en un almacenaje primario (base de datos o archivo plano como los archivos de texto y hojas de cálculo) así como en un almacenaje no primario (copias de respaldo, bitácoras de auditoría, archivo de excepción o bitácoras de rastreo de problemas técnicos) deben estar protegidos. El daño que puede causar el robo o pérdida de cintas de respaldo durante su transporte se puede reducir asegurando por medio de la encriptación, el uso de números truncados o valores hash que los números de cuenta primarios no se puedan leer. Puesto que es necesario retener las bitácoras para fines de auditoría, rastreo de problemas técnicos y archivos de excepción, puede evitar la divulgación de los datos en dichas bitácoras haciendo que los números de cuenta primarios sean ilegibles (eliminándolos o enmascarándolos) en las bitácoras.

• Funciones hash de una sola vía (hashed indexes) Las funciones hash de una sola vía como SHA-1 se pueden utilizar para lograr que los datos de los tarjetahabientes queden ilegibles. Las funciones hash resultan apropiadas cuando no hay necesidad de recuperar más tarde el número original (las funciones hash de una sola vía son irreversibles).


Requisito Orientación • Números truncados

La intención del requisito de truncar el número de cuenta es guardar solamente una parte del número de cuenta primario (que no debe ser más que los primeros seis y cuatro dígitos). Es diferente a la máscara, donde el número de cuenta primario completo se guarda pero se enmascara al desplegarse (es decir, solamente se despliega una parte del número de cuenta primario en pantallas, reportes, recibos, etc.).

• Tokens de índice y pads (los pads deben ser guardado bajo seguridad)

Los tokens de índice y pads también se pueden usar para hacer ilegibles los datos de los tarjetahabientes. Un token de índice es un token criptográfico que reemplaza el número de cuenta primario basándose en un determinado índice para un valor impredecible. Un pad de un solo uso es un sistema en el cual una clave privada generada en forma aleatoria se utiliza una sola vez para encriptar un mensaje que luego se decripta utilizando un pad y clave de un solo uso equivalente.

• Criptografía de alta seguridad como el estándar Triple-DES de 128 bits o el AES de 256 bits con procesos y procedimientos asociados de administración de claves

La intención de la criptografía de alta seguridad (vea la definición y longitudes de las claves en el Glosario, Abreviaturas y Acrónimos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago) es basar la encriptación en un algoritmo probado y aceptado en la industria (no en un algoritmo propietario o desarrollado internamente).

La información MÍNIMA sobre las cuentas que necesita estar en forma ilegible es el número de cuenta de la tarjeta de pago. Si por alguna razón una compañía no puede encriptar los datos de los tarjetahabientes, consulte el Apéndice B: “Controles Compensatorios” en las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago.

3.4.1 Si se usa la encriptación de disco (en lugar de la encriptación a nivel de archivo o columna de base de datos), el acceso lógico deberá administrarse independientemente de los mecanismos de control de acceso de los sistemas operativos nativos (por ejemplo, no usar las cuentas del sistema o Directorio Activo local). Las claves de decriptación no deberán estar vinculadas a las cuentas de los usuarios.

La intención de este requisito es contemplar si la encriptación de disco es aceptable para lograr que los datos de los tarjetahabientes queden ilegibles. La encriptación de disco encripta los datos guardados en almacenaje masivo en un computador y automáticamente decripta la información cuando un usuario autorizado lo solicita. Los sistemas de encriptación de disco interceptan las operaciones de lectura y escritura del sistema operativo y llevan a cabo las transformaciones criptográficas apropiadas sin ninguna acción específica o especial del usuario, con la excepción de proporcionar una contraseña o frase en clave al comenzar la sesión. Dadas estas características de la encriptación de disco, para cumplir con este requisito el


Requisito Orientación método de encriptación de disco no puede tener: 1) Una asociación directa con el sistema operativo, ni 2) Claves de decriptación que estén asociadas con las cuentas de los usuarios.

3.5 Proteger las claves (o llaves) de encriptación contra la divulgación y el uso indebido.

Las claves (o llaves) de encriptación deben estar sólidamente protegidas porque cualquier persona que obtenga acceso a las mismas podrá decriptar los datos.

3.5.1 Restringir el acceso a las claves y llaves al número mínimo de custodios necesarios.

Sólo muy pocas personas deben tener acceso a las claves de encriptación, por lo general solamente las personas que tengan responsabilidades de custodia.

3.5.2 Guardar las claves en forma segura en el mínimo número de ubicaciones y formatos posibles.

Las claves de encriptación se deben guardar en forma segura, normalmente con las claves de encriptación de clave, y en muy pocos lugares.

3.6 Documentar e implementar totalmente todos los procesos y procedimientos de administración de claves, incluyendo los siguientes:

La forma en que se administran las claves de encriptación es crítica para la continua seguridad de la solución de encriptación. Un buen proceso de administración de claves, sea manual o automatizado como parte del producto de encriptación, contempla todos los elementos clave de los requisitos 3.6.1 a 3.6.10.

3.6.1 Generación de claves de alta seguridad La solución de encriptación debe generar claves de alta seguridad, según lo definido en el Glosario, Abreviaturas y Acrónimos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago bajo “criptografía de alta seguridad”.

3.6.2 Distribución segura de claves La solución de encriptación debe distribuir las claves en forma segura, lo cual significa que las claves no se pueden distribuir en formato de texto en claro y se deben distribuir solamente a los custodios identificados en el requisito 3.5.1.

3.6.3 Almacenamiento seguro de claves La solución de encriptación debe guardar las claves en forma segura, lo cual significa que las claves no se guardarán en formato de texto en claro (use una clave de encriptación de claves para encriptarlas).



3.6.4 Cambio periódico de claves • Según se considere necesario y lo

recomiende la aplicación asociada (por ejemplo volver a digitar las claves), preferiblemente en forma automática

• Al menos anualmente.

Si el proveedor de la aplicación de encriptación los ha proporcionado, siga sus procesos y recomendaciones para cambiar periódicamente las claves. Es esencial cambiar anualmente las claves de encriptación para minimizar el riesgo de que alguien las obtenga y pueda decriptar los datos.

3.6.5 Destrucción de las claves viejas Las claves viejas que ya no se utilicen o necesiten deben ser destruidas. Si es necesario guardarlas (para soporte de datos archivados o encriptados, por ejemplo), deben estar protegidas con medidas de alta seguridad. (Vea el 3.6.6 a continuación.)

3.6.6 Establecer el conocimiento no compartido y el control dual de las claves (de forma que se requiera a 2 o 3 personas, cada una de las cuales conozca solamente una parte de la clave, para reconstruir la clave completa).

El conocimiento no compartido y el control dual se usan para eliminar la posibilidad de que una persona tenga acceso a la clave completa. Este control normalmente se aplica en el caso de los sistemas de encriptación manual de claves o donde el producto de encriptación no implementa la administración de claves. Este tipo de control normalmente se implementa dentro de módulos de seguridad de hardware.

3.6.7 Prevención de la sustitución no autorizada de las claves

La solución de encriptación no debe permitir o aceptar la sustitución de claves procedente de fuentes no autorizadas o procesos inesperados.

3.6.8 Reemplazo de claves cuando se sepa o sospeche que su seguridad ha sido comprometida.

La solución de encriptación debe permitir y facilitar un proceso para reemplazar las claves cuya seguridad se sabe o sospecha ha sido comprometida.

3.6.9 Revocación de las claves viejas o inválidas Esto asegurará que ya no se puedan usar las claves.

3.6.10 Requisito de que los custodios de claves firmen un formulario especificando que comprenden y aceptan su responsabilidad como custodios de las claves.

Este proceso asegurará que la persona se comprometa con su papel de custodio de las claves y comprenda sus responsabilidades.


Requisito 4: Encriptar los datos e información confidencial de los tarjetahabientes transmitida a través de redes públicas abiertas. La información confidencial debe encriptarse durante su transmisión a través de redes, ya que es fácil y común que un delincuente intercepte y/o redirija los datos mientras se encuentran en tránsito.


4.1 Usar criptografía y protocolos de alta seguridad como Secure Sockets Layer (SSL)/Transport Layer Security (TLS) e Internet Protocol Security (IPSEC) para salvaguardar los datos confidenciales de los tarjetahabientes durante su transmisión a través de redes públicas abiertas. Ejemplos de redes públicas abiertas que caen dentro del alcance de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago son Internet, WiFi (IEEE 802.11x), Global System for Mobile Communications (GSM), y General Packet Radio Service (GPRS).

La información confidencial se debe encriptar durante su transmisión a través de redes públicas, ya que es fácil y común que un delincuente cibernético intercepte y/o desvíe los datos mientras se encuentran en tránsito. Tenga presente que las versiones SSL anteriores a la versión 3.0 contienen vulnerabilidades documentadas como, por ejemplo, buffer overflows, que un atacante puede utilizar para obtener el control del sistema afectado.



4.1.1 En el caso de las redes inalámbricas que transmitan datos de los tarjetahabientes, encriptar las transmisiones usando la tecnología Wi-Fi Protected Access (WPA o WPA2), IPSEC VPN, o SSL/TLS. Nunca depender exclusivamente de Wired Equivalent Privacy (WEP) para proteger el carácter confidencial y el acceso a una red de acceso local (LAN) inalámbrica:

• Usar con una clave de encriptación de un mínimo de 104 bits y valor de inicialización de 24 bits.

• Usar SOLAMENTE en conjunción con la tecnología WiFi Protected Access (WPA o WPA2), VPN, o SSL/TLS.

• Rotar trimestralmente (o automáticamente si la tecnología lo permite) las claves WEP compartidas.

• Rotar las claves WEP compartidas siempre que haya cambios en el personal que tiene acceso a las claves.

• Restringir el acceso basándose en la dirección de código de acceso a medios (MAC).

Los delincuentes cibernéticos utilizan herramientas que se obtienen en forma gratuita y están fácilmente disponibles para espiar las comunicaciones inalámbricas. El uso apropiado de la encriptación puede evitar este tipo de espionaje y la divulgación de la información confidencial a través de la red. En muchas ocasiones en que solamente la seguridad de los datos de los tarjetahabientes almacenados en la red alámbrica se ha visto comprometida el origen del compromiso de la seguridad fue que el delincuente logró el acceso desde una red inalámbrica. No se debe usar nunca la encriptación con WEP por sí sola, ya que es vulnerable debido a vectores iniciales débiles (IV) en el proceso de intercambio de claves WEP, y carece de la rotación requerida de claves. Un atacante podría utilizar libremente herramientas de penetración con fuerza bruta para penetrar la encriptación WEP.

4.2 No enviar nunca información del tarjetahabiente por correo electrónico sin encriptar.

El correo electrónico se puede interceptar fácilmente espiando los paquetes durante el tránsito por redes internas y públicas.


Orientaciones para los Requisitos 5 y 6: Mantener un Programa de Manejo de Vulnerabilidad

Requisito 5: Usar y actualizar regularmente el software o programas antivirus. Muchas vulnerabilidades y virus maliciosos y destructivos entran a la red a través de la actividad de correo electrónico de los empleados. El software antivirus deberá utilizarse en todos los sistemas de correo electrónico y computadores de escritorio para proteger los sistemas de cualquier programación destructiva.


5.1 Implementar software antivirus en todos los sistemas comúnmente afectados por virus (particularmente computadores personales y servidores). Nota: Los sistemas comúnmente afectados por virus típicamente no incluyen los sistemas operativos basados en UNIX o mainframes.

Constantemente se lanzan ataques contra sistemas que en lo demás son seguros utilizando debilidades ampliamente divulgadas, a menudo con “0 días” (porque se publicaron y divulgaron a través de las redes en menos de una hora a partir de su descubrimiento). Sin un software antivirus que se actualice regularmente, estos nuevos virus pueden atacar y desactivar su red.

5.1.1 Asegurar que todos los programas antivirus sean capaces de detectar, eliminar y proteger contra otros tipos de software malicioso y destructivo, incluyendo spyware y adware.

Es importante contar con protección contra TODO tipo y formato de software malicioso.

5.2 Asegurar que todos los mecanismos antivirus estén actualizados, estén funcionando activamente y sean capaces de generar registros y bitácoras de auditoría.

El mejor software antivirus está limitado en su eficacia si no cuenta con firmas antivirus actualizadas o si no está activo en la red o en el computador de un empleado. Las bitácoras de auditoría proporcionan la habilidad de monitorear la actividad de virus y las reacciones antivirus.


Requisito 6: Desarrollar y mantener sistemas y aplicaciones seguros. Las personas sin escrúpulos utilizan las vulnerabilidades en la seguridad para obtener acceso privilegiado a los sistemas. Muchas de estas vulnerabilidades se pueden subsanar mediante parches de seguridad desarrollados por los proveedores. Todos los sistemas deben contar con los parches de software apropiados y más recientes para estar protegidos contra la explotación por parte de empleados, delincuentes externos y virus. Nota: Los parches de software apropiados son aquellos que han sido suficientemente evaluados y probados para determinar 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 utilizando los procesos normales de desarrollo de sistemas y técnicas de codificación seguras.


6.1 Asegurar que todos los componentes de sistemas y software cuenten con los parches de seguridad más recientes proporcionados por los proveedores. Instalar los parches de seguridad relevantes dentro de un plazo de de un mes de publicados.

Hay un considerable número de ataques utilizando debilidades ampliamente divulgadas y publicadas, a menudo “0 días” (es decir, con menos de una hora de publicadas) contra sistemas que en lo demás son seguros. Si no se implementan los parches más recientes en los sistemas lo más pronto posible, un delincuente puede aprovechar esas debilidades para lanzar un ataque y deshabilitar la red. Considere asignar prioridad a los cambios, de forma que los parches de seguridad en los sistemas críticos o en riesgo se instalen dentro de un plazo de 30 días y otros cambios en sistemas menos riesgosos tengan menos prioridad.

6.2 Establecer un proceso para identificar las vulnerabilidades de seguridad recientemente descubiertas (por ejemplo, suscribirse a los servicios de alerta disponibles en forma gratuita a través de Internet). Actualizar sus normas para subsanar cualquier nuevo problema de vulnerabilidad que pudiera surgir.

La intención de este requisito es mantener a las organizaciones al día con respecto a las nuevas vulnerabilidades, a fin de que puedan proteger su red en forma apropiada e incorporar vulnerabilidades recientemente descubiertas y relevantes a sus normas de configuración.

6.3 Desarrollar aplicaciones de software basadas en las mejores prácticas de la industria e incorporar la seguridad de la información a través de todo el ciclo de desarrollo de software.

Si no se incluye la seguridad durante las etapas de definición, diseño, análisis y prueba del desarrollo de software, se podrían introducir inadvertida o maliciosamente vulnerabilidades de seguridad en el ambiente de producción.

6.3.1 Hacer pruebas de todos los parches de seguridad y cambios de configuración de sistema antes de implementarlos.

Eso asegura que todas las instalaciones y cambios funcionen de la forma esperada y que no tengan ninguna función inesperada, indeseable o dañina.



6.3.2 Separar los ambientes de desarrollo, prueba y producción.

A menudo los ambientes de desarrollo y prueba son menos seguros que el ambiente de producción. Sin una separación adecuada el ambiente de producción y los datos de los tarjetahabientes podrían estar en riesgo debido a vulnerabilidades o procesos internos débiles.

6.3.3 Separar las responsabilidades entre los ambientes de desarrollo, prueba y producción.

Esto minimiza el número de empleados que tienen acceso al ambiente de producción y ayuda a asegurar que el acceso esté limitado a aquellos que verdaderamente necesiten ese acceso.

6.3.4 Los datos de producción (números reales de cuentas de tarjetas) no se usan para fines de prueba y desarrollo.

Los controles de seguridad normalmente no son tan estrictos en el ambiente de desarrollo. El uso de datos de producción da a los delincuentes cibernéticos, así como a los que desarrollan software, la oportunidad de obtener acceso no autorizado a la información de producción.

6.3.5 Eliminar todos los datos y cuentas de prueba antes de activar los sistemas de producción.

Los datos y cuentas de prueba deben eliminarse del código de producción antes que se active la aplicación, ya que los mismos pueden dar a conocer información acerca del funcionamiento de la aplicación. La posesión de esa información podría facilitar el compromiso de la seguridad de la aplicación y los datos de los tarjetahabientes relacionados.

6.3.6 Eliminar las cuentas, nombres de usuarios y contraseñas de las aplicaciones individuales antes que las aplicaciones se activen o se pongan a disposición de los clientes.

Las cuentas, nombres de usuarios y contraseñas de las aplicaciones individuales deben eliminarse del código de producción antes que la aplicación se active o ponga a disposición de los clientes, ya que estos datos pueden dar a conocer información referente al funcionamiento de la aplicación. La posesión de esa información podría facilitar el compromiso de la seguridad de la aplicación y los datos de los tarjetahabientes relacionados.

6.3.7 Revisar los códigos individuales antes de ponerlos en producción o a disposición de los clientes, a fin de identificar cualquier vulnerabilidad relacionada con la codificación.

Los delincuentes comúnmente explotan las vulnerabilidades de seguridad en los códigos individuales para obtener acceso a una red y comprometer la seguridad de los datos de los tarjetahabientes. Los que tengan conocimiento de las técnicas de codificación segura deben revisar los códigos para identificar cualquier vulnerabilidad.



6.4 Seguir los procedimientos de control de cambios para todas las modificaciones de configuración de sistemas y software. Los procedimientos deben incluir lo siguiente:

Sin controles apropiados de cambio de sistemas las funciones de seguridad podrían inadvertida o deliberadamente omitirse o deshabilitarse de manera que queden inoperables, podrían ocurrir irregularidades de procesamiento o se podrían introducir códigos maliciosos. Si las políticas de personal para requerir verificación de antecedentes y controles de acceso de sistema no son adecuadas, existe el riesgo de que personas no confiables o no capacitadas puedan tener acceso irrestricto al código de software y de que los empleados que han cesado en sus funciones puedan comprometer la seguridad de los sistemas, sin que se detecten las acciones no autorizadas.

6.4.1 Documentación del impacto El impacto del cambio debe estar documentado para que todas las partes afectadas por el mismo puedan planificar en forma apropiada cualquier tipo de cambio de procesamiento.

6.4.2 Aprobación final por escrito (con firma) de los funcionarios apropiados

La aprobación de la administración significa que el cambio es legítimo y está autorizado por la organización.

6.4.3 Pruebas de funcionalidad operativa Se deben realizar pruebas exhaustivas para verificar que todas las acciones son las esperadas, que los reportes son exactos, que todas las posibles condiciones de error reaccionan de la manera apropiada, etc.

6.4.4 Procedimientos de cancelación Debe haber procedimientos de cancelación para cada cambio en caso de que el mismo falle, a fin de que se pueda restaurar el sistema al estado previo.

6.5 Desarrollar todas las aplicaciones de Web tomando como base las directrices de codificación segura como Open Web Application Security Project Guidelines. Revisar el código de aplicación individual para identificar vulnerabilidades de codificación. Contemplar la prevención de vulnerabilidades comunes de codificación en los procesos de desarrollo de software, que incluyen las siguientes:

La capa de aplicaciones es de alto riesgo y puede ser objeto de ataques de procedencia tanto interna como externa. Sin una seguridad apropiada los datos de los tarjetahabientes y otros tipos de información confidencial de la empresa podrían verse expuestos, lo que podría traer como resultado un daño para la compañía, sus clientes y su reputación.

6.5.1 Ingreso de datos sin validar La información de las solicitudes que lleguen desde la Web debe validarse antes de enviarla a la aplicación de Web—por ejemplo, se deben realizar verificaciones para asegurar que todos los caracteres sean alfabéticos, que haya una combinación de caracteres alfabéticos y numéricos, etc. Sin estas verificaciones los delincuentes cibernéticos pueden pasar información inválida a una aplicación y atacar los componentes que se encuentran dentro de la red a través de la aplicación.



6.5.2 Control de acceso interrumpido (por ejemplo, uso malicioso de las identificaciones de usuarios)

Los usuarios maliciosos a menudo intentan escanear y enumerar las cuentas de usuarios existentes en las aplicaciones para encontrar un punto de entrada para el ataque. Una vez que encuentra una cuenta existente, un atacante tratará de usar contraseñas por defecto o fuerza bruta para acceder a esa aplicación.

6.5.3 Interrupción de la autenticación o administración de sesiones (uso de credenciales de cuenta y cookies de sesión)

Las credenciales de las cuentas y tokens de sesiones deben estar protegidos en forma apropiada. Los ataques contra las contraseñas, claves, cookies de sesión y otros tokens pueden penetrar las restricciones de autenticación y permitir a un delincuente que asuma la identidad de otros usuarios. Además, las cookies pueden almacenar información de los tarjetahabientes y por defecto se guardan en formato de texto en claro.

6.5.4 Ataques con inyección de códigos en ventanas pertenecientes a diferentes dominios (el llamado Cross-Site Scripting o XSS).

En el caso de estos ataques se usa la aplicación de Web para enviar un ataque al explorador de red de un usuario final, lo cual puede traer como resultado la divulgación del token de sesión del usuario, un ataque contra la máquina del usuario final y el envío de contenido falso, pero que parece legítimo, por parte del delincuente, con la finalidad de engañar al usuario.

6.5.5 Ataques de buffer overflow Los delincuentes cibernéticos pueden deshabilitar los componentes de aplicaciones de Web que no validen en forma apropiada los datos entrantes (vea también el 6.5.1 anteriormente), y podrían asumir el control de los procesos en el servidor relacionado.

6.5.6 Defectos de inyección (por ejemplo, inyección de Structured Query Language, SQL)

Para agilizar la conectividad y reducir el desempeño en el servidor, con frecuencia se requiere la validación y manipulación de los datos entrantes y otros datos del lado del cliente. Para los delincuentes es a menudo un ejercicio relativamente trivial pasar por alto estas verificaciones y utilizar la aplicación de Web para enviar comandos maliciosos al servidor con el fin de iniciar ataques como los de buffer overflow, o revelar tanto información confidencial como la funcionalidad de la aplicación de servidor. Este es un método popular para llevar a cabo transacciones fraudulentas en los sitios que cuentan con la funcionalidad de comercio electrónico.



6.5.7 Manejo inapropiado de errores Frecuentemente el manejo incorrecto de los errores proporciona información que ayuda a un delincuente cibernético a comprometer la seguridad del sistema. Si el delincuente puede crear errores que la aplicación de Web no maneja correctamente, puede obtener información detallada sobre el sistema, crear interrupciones por negación de servicio, causar fallos en las medidas de seguridad o hacer que el servidor quede inoperable. Por ejemplo, el mensaje “contraseña incorrecta” le dice al delincuente que el nombre de usuario proporcionado es el correcto y que debe concentrar sus esfuerzos solamente en descubrir la contraseña. Use mensajes de error más genéricos, como "no fue posible verificar los datos”.

6.5.8 Almacenaje sin la debida seguridad Esto se relaciona con el uso no seguro de la criptografía. Puesto que las aplicaciones criptográficas son difíciles de codificar, ello frecuentemente trae como resultado una protección débil de los datos almacenados y el uso de criptografía que es fácil de penetrar.

6.5.9 Negación de servicio Los delincuentes pueden agotar los recursos de la aplicación de Web hasta el punto que los usuarios ya no puedan utilizarla. También pueden bloquear completamente el acceso de los usuarios a sus cuentas o causar que la aplicación falle.

6.5.10 Administración no segura de configuraciones Contar con una norma de configuración de servidores de alta seguridad es esencial para tener aplicaciones de Web seguras. Los servidores tienen muchas opciones de configuración para controlar la seguridad y no son seguros como vienen configurados del fabricante.

6.6 Asegurar que todas las aplicaciones hacia la Web estén protegidas contra ataques conocidos mediante cualquiera de los siguientes métodos:

Los ataques en las aplicaciones hacia la Web son comunes y a menudo exitosos y las prácticas de codificación deficientes son las que permiten que estos ataques ocurran. La intención de este requisito de revisar los códigos de las aplicaciones o contrafuegos de capa de aplicación es reducir el número de compromisos de la seguridad en las aplicaciones hacia la Web que traen como resultado una violación de la seguridad de los datos de los tarjetahabientes.

• Haciendo que una organización especializada en seguridad de aplicaciones revise todos los códigos individuales de aplicación para eliminar vulnerabilidades comunes.

También se debe usar para satisfacer este requisito una herramienta que realice revisiones de codificación y/o escanee para detectar vulnerabilidades en las aplicaciones.



• Instalando un cortafuego a nivel de capa de aplicación frente a las aplicaciones conectadas a la Web.

Nota: El requisito 6.6 está considerado una mejor práctica hasta el 30 de junio de 2008, y después de esta fecha se convierte en requisito.

Los cortafuegos de aplicaciones se utilizan para filtrar y bloquear todo el tráfico que no sea esencial en la capa de aplicación. Utilizado en conjunción con un cortafuego de red, un cortafuego de capa de aplicación correctamente configurado evita ataques dirigidos a la capa de aplicación si las aplicaciones no están codificadas o configuradas de la manera apropiada.

Orientaciones para los Requisitos 7, 8 y 9: Implementar Medidas Sólidas de Control de Acceso

Requisito 7: Restringir el acceso a los datos de los tarjetahabientes tomando como base la necesidad del funcionario de conocer la información. Este requisito asegura que sólo el personal autorizado tenga acceso a los datos críticos.


7.1 1 Limitar el acceso a los recursos de computación y a la información de los tarjetahabientes exclusivamente a aquellas personas que por necesidad de su trabajo requieran dicho acceso.

Mientras más personas tengan acceso a los datos de los tarjetahabientes, más riesgo habrá de que la cuenta de un usuario se utilice en forma maliciosa. Limitar el acceso a aquellas personas que por razones de su trabajo tengan necesidad de ese acceso ayuda a la organización a prevenir el manejo inadecuado de los datos de los tarjetahabientes por inexperiencia o malicia. Su organización debe crear una política clara de control de acceso a los datos a fin de definir cómo y a quién se da acceso a los mismos.

7.2 Establecer un mecanismo para los sistemas de múltiples usuarios que restrinja el acceso tomando como base la necesidad del usuario de conocer la información y esté programado para negar el acceso a todo el mundo, a menos que esté permitido específicamente.

Sin un mecanismo que restrinja el acceso basándose en la necesidad del usuario de conocer la información, un usuario podría inadvertidamente obtener acceso a los datos de los tarjetahabientes.


Requisito 8: Asignar una identificación única a cada persona que tenga acceso a un computador. Asignar una identificación (ID) única a cada persona que tenga acceso asegura que las acciones implementadas en relación con los datos y sistemas críticos sean realizadas por usuarios conocidos y autorizados y que las mismas puedan ser rastreadas.


8.1 Identificar a todos los usuarios mediante un nombre de usuario único antes de permitirles el acceso a los componentes de sistemas y datos de los tarjetahabientes.

Asegurando que se identifique en forma única a cada usuario—en lugar de usar un ID para varios empleados—una organización puede mantener la responsabilidad individual por las acciones y una pista de auditoría eficaz por cada empleado. Esto ayuda a agilizar la solución de cualquier problema y sirve como medida de contención cuando se usan los datos en forma no autorizada o maliciosa.

8.2 Además de asignar un ID de usuario único, emplear al menos uno de los métodos enumerados a continuación para autenticar a todos los usuarios: • Contraseña • Dispositivos de token (por ejemplo, SecureID,

certificados o clave pública) • Biométrica

Cuando se utilizan junto con un ID único, estos elementos de autenticación ayudan a proteger el ID único del usuario para que no se vea comprometida su seguridad (ya que el que intenta comprometer esa seguridad necesita conocer el ID único del usuario y, además, la contraseña u otro elemento de autenticación).

8.3 Implementar la autenticación de 2 factores para el acceso remoto a la red por parte de los empleados, administradores y terceros. Usar tecnologías como Remote Authentication and Dial-In Service (RADIUS) o Terminal Access Controller Access Control System (TACACS) con tokens, o VPN (basado en SSL/TLS o IPSEC) con certificados individuales.

Las tecnologías de autenticación de dos factores brindan una contraseña para un solo uso, la cual se utiliza cuando se necesita otro elemento de autenticación adicional para accesos de más alto riesgo, por ejemplo, desde fuera de su red. Para contar con seguridad adicional su organización podría también considerar el uso de la autenticación de dos factores para acceder de una red de menor seguridad a una red de mayor seguridad (por ejemplo, desde un computador corporativo [menor seguridad] a los servidores de producción o bases de datos que contienen datos de los tarjetahabientes [alta seguridad].

8.4 Encriptar todas las contraseñas durante la transmisión y el almacenaje, en todos los componentes de sistemas.

Muchos dispositivos de red y aplicaciones transmiten el ID del usuario y la contraseña a través de la red sin encriptarla y/o guardan la contraseña sin encriptarla. Un delincuente puede fácilmente interceptar el ID de usuario y la contraseña durante la transmisión mediante el uso de un dispositivo de espionaje o “sniffer,” u obtener acceso directamente a los ID de usuarios y contraseñas sin encriptar en los archivos donde están guardados estos datos, para después utilizar esos datos robados con el fin de obtener acceso no autorizado.



8.5 Asegurar la autenticación apropiada de los usuarios y la administración correcta de las contraseñas de los usuarios y administradores en todos los componentes de sistemas de la manera siguiente:

Puesto que uno de los primeros pasos de un delincuente cibernético para comprometer la seguridad de un sistema es explotar las contraseñas débiles o el hecho de que no existan contraseñas, es importante implementar buenos procesos de autenticación de usuarios y administración de contraseñas.

8.5.1 Controlar la adición, eliminación y modificación de las identificaciones de usuarios, credenciales y otros objetos de identificación.

Para asegurar que los usuarios añadidos a su sistema sean todos usuarios válidos y reconocidos, un pequeño grupo de empleados con autoridad específica debe administrar y controlar la adición, eliminación y modificación de cada ID de usuario. La autoridad y habilidad para administrar estos ID de usuario debe estar limitada exclusivamente a ese grupo.

8.5.2 Verificar la identidad del usuario antes de reprogramar (reset) las contraseñas.

Muchos delincuentes cibernéticos utilizan la “ingeniería social”—por ejemplo, llamar a un escritorio de soporte y hacerse pasar por un usuario legítimo—para cambiar una contraseña y poder utilizar un ID de usuario. Considere el uso de una “pregunta secreta” que solamente el usuario legítimo pueda contestar para ayudar a los administradores a identificar al usuario antes de cambiar la contraseña. Asegure que las preguntas cuenten con la debida seguridad y no sean compartidas.

8.5.3 Programar la primera contraseña de un usuario a un valor único para dicho usuario y cambiarla inmediatamente después del primer uso.

Si se usa la misma contraseña para cada nuevo usuario que se establece, un usuario interno, antiguo empleado o delincuente cibernético puede conocer o fácilmente descubrir esta contraseña y utilizarla para obtener acceso a las cuentas.

8.5.4 Revocar inmediatamente el acceso de todo usuario que ya no sea un empleado o no lo requiera.

Si un empleado ha cesado en sus funciones con la empresa y aún tiene acceso a la red a través de su cuenta de usuario, podría ocurrir un acceso innecesario o malicioso a los datos de los tarjetahabientes. Este acceso podría ser obra del antiguo empleado o de un usuario malicioso que explote las cuentas más antiguas y/o que ya no se usan. Considere implementar un proceso de notificación inmediata a Recursos Humanos cuando un empleado cese en sus funciones para que se revoque rápidamente la cuenta de usuario.

8.5.5 Eliminar las cuentas de usuarios inactivos al menos cada 90 días.

La existencia de cuentas inactivas permite a un usuario no autorizado explotar la cuenta que no se utiliza para posiblemente acceder a los datos de los tarjetahabientes.



8.5.6 Habilitar las cuentas que usan los proveedores para mantenimiento remoto solamente durante el tiempo necesario.

Permitir a los proveedores (por ejemplo, de equipos de punto de venta) que tengan acceso a su red las 24 horas del día, los 7 días de la semana, en caso que necesiten proporcionar soporte a sus sistemas aumenta las probabilidades de un acceso no autorizado, sea por parte de un usuario en el ambiente del proveedor o de un delincuente cibernético que encuentre y utilice este punto de entrada externo a su red, que siempre está abierto. Vea también los requisitos 12.3.8 y 12.3.9 para más detalles sobre este tema.

8.5.7 Comunicar los procedimientos y las políticas relacionadas con las contraseñas a todos los usuarios que tengan acceso a los datos de los tarjetahabientes.

Comunicar a todos los usuarios los procedimientos relacionados con las contraseñas ayuda a esos usuarios a entender y acatar las políticas y a estar alerta para detectar a cualquier usuario malicioso que intente explotar su contraseña con la intención de obtener acceso a los datos de los tarjetahabientes (por ejemplo, llamar a un empleado y pedirle su contraseña para que el que llama pueda “arreglar un problema técnico”).

8.5.8 No usar cuentas o contraseñas grupales, compartidas o genéricas.

Si múltiples usuarios comparten la misma cuenta y contraseña, será imposible asignar responsabilidad o mantener un registro eficaz de las acciones de un determinado individuo, ya que una acción podría haber sido realizada por cualquier miembro del grupo que comparte la cuenta y la contraseña.



8.5.9 Cambiar la contraseña de los usuarios al menos cada 90 días.

Las contraseñas de alta seguridad son la primera línea de defensa para bloquear el acceso a una red, ya que un delincuente cibernético a menudo tratará primero de encontrar cuentas con contraseñas débiles o cuentas que no estén protegidas por una contraseña. Hay más tiempo para que un atacante localice estas cuentas débiles y comprometa la seguridad de la red bajo el disfraz de un ID de usuario válido si las contraseñas son breves y fáciles de adivinar, o han sido válidas durante mucho tiempo sin haberse cambiado. Las contraseñas de alta seguridad se pueden hacer cumplir y mantener de acuerdo con estos requisitos habilitando las funciones de seguridad de contraseña y cuenta que vienen con su sistema operativo (por ejemplo Windows), las redes, bases de datos y otras plataformas.

8.5.10 Requerir una longitud mínima de contraseña de al menos siete caracteres.

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

8.5.12 No permitir a ninguna persona que presente una nueva contraseña que sea igual que cualquiera de las últimas cuatro que ha utilizado.

8.5.13 Limitar los intentos repetidos de lograr acceso bloqueando la ID del usuario después de un máximo de seis intentos.

Sin mecanismos establecidos para bloquear los intentos de acceso a las cuentas un atacante puede continuamente tratar de adivinar una contraseña mediante métodos manuales o herramientas automatizadas (para descifrar contraseñas), hasta que logre el éxito y obtenga acceso a una cuenta de usuario.

8.5.14 Programar la duración de este bloqueo a treinta minutos o hasta que el administrador del sistema habilite el ID del usuario.

Si una cuenta se bloquea debido a que alguien continuamente trata de adivinar una contraseña, los controles que retardan la reactivación de estas cuentas bloqueadas impiden al delincuente tratar continuamente de adivinar la contraseña (tienen que parar durante al menos 30 minutos hasta que se reactiva la cuenta). Además, si se requiere solicitar la reactivación, el escritorio de administración o soporte puede validar que el dueño de la cuenta es la causa del bloqueo (debido a errores al escribir su contraseña).

8.5.15 Si no ha habido actividad en una sesión durante más de 15 minutos, requerir que el usuario vuelva a ingresar la contraseña.

Cuando los usuarios se alejan de una máquina abierta que brinda acceso a la red o a datos críticos de los tarjetahabientes, otros podrían utilizar esa máquina durante la ausencia del usuario, lo cual podría traer como resultado un acceso no autorizado y/o el uso indebido de la cuenta.

8.5.16 Autenticar todos los accesos a cualquier base de datos que contenga información de los tarjetahabientes. Esto incluye acceso por parte de las aplicaciones, los administradores y todos los demás usuarios.

Si no se implementa la autenticación de base de datos el potencial de acceso no autorizado a la base de datos aumenta, y dicho acceso no se puede registrar en una bitácora porque el usuario no ha sido autenticado y por tanto el sistema no lo reconoce. Igualmente, el acceso a cualquier base de datos debe ser siempre a través de procedimientos programados y almacenados, en lugar de un acceso directo a la base de datos por parte de un usuario final (excepto en el caso de los DBA, que pueden tener acceso directo a la base de


Requisito Orientación datos para realizar sus funciones administrativas).


Requisito 9: Restringir el acceso físico a los datos de los tarjetahabientes. Cualquier acceso físico a los datos o sistemas que contienen datos de los tarjetahabientes brinda una oportunidad de acceder a dispositivos o datos y eliminar sistemas o copias impresas, y debe ser restringido de forma apropiada.


9.1 Usar controles apropiados de entrada a las instalaciones para limitar y monitorear el acceso a los sistemas que almacenan, procesan o transmiten datos de los tarjetahabientes.

Si se implementan controles de acceso físico cualquier persona no autorizada podría obtener acceso al edificio y a la información confidencial, y podría alterar las configuraciones de sistema, introducir vulnerabilidades en la red o destruir o robar equipos.

9.1.1 Usar cámaras para vigilar las áreas vulnerables. Auditar estos datos y correlacionar con otros. Guardar durante al menos tres meses, a menos que existan otras restricciones impuestas por la ley.

Sin “ojos” que vigilen los sistemas críticos, es más difícil prevenir violaciones de la seguridad física e investigarlas, y no es posible identificar a los atacantes.

9.1.2 Restringir el acceso físico a los conectores de redes (network jacks) accesibles al público.

Restringir el acceso a los conectores de redes evitará que un delincuente cibernético pueda conectarse a cualquier conector disponible, lo cual podría permitirle el acceso a los recursos internos de la red. Considere desactivar todos los conectores de redes que no estén en uso y reactivarlos solamente cuando exista la necesidad de usarlos. En áreas públicas tales como salones de conferencias, establezca redes privadas para permitir a los proveedores y visitas el acceso a Internet sin que estén conectados a su red interna.

9.1.3 Restringir el acceso físico a los puntos de acceso inalámbrico, pasarelas y dispositivos handheld.

Si no se implementan medidas de seguridad para el acceso a los componentes y dispositivos inalámbricos, un usuario malicioso podría utilizar los dispositivos de acceso inalámbrico de su empresa para acceder a los recursos de la red o incluso conectar sus propios dispositivos a la red inalámbrica de la compañía para contar con acceso no autorizado. Considere colocar los puntos y pasarelas de acceso inalámbrico en áreas seguras, por ejemplo, un closet cerrado con llave. Asegure que esté habilitada la encriptación de alta seguridad. Habilite el bloqueo de los dispositivos handheld inalámbricos después de un cierto período de inactividad y programe sus dispositivos para que requieran una contraseña al encenderse.



9.2 Desarrollar procedimientos para ayudar a todo el personal a distinguir fácilmente a los empleados de los visitantes en las áreas en que la información de los tarjetahabientes está accesible. “Empleado” se refiere a los funcionarios que laboran a jornada completa o parcial, empleados y personal temporal y consultores “residentes” en la ubicación. Un “visitante” es un proveedor, invitado de un funcionario o cualquier otra persona que entre a las instalaciones durante un período breve, normalmente no más de un día.

Si no se implementan sistemas de gafetes y controles en las puertas, un usuario no autorizado o malicioso podría fácilmente obtener acceso a sus instalaciones para robar, deshabilitar, bloquear o destruir sistemas críticos y datos de los tarjetahabientes. Para tener un control óptimo, considere implementar un sistema de acceso con gafetes o tarjetas para controlar entradas y salidas en áreas donde haya datos de los tarjetahabientes.

9.3 Asegurar que se haga lo siguiente en el caso de todos los visitantes:

El control de visitas es importante para reducir las probabilidades de que una persona no autorizada o maliciosa obtenga acceso a sus instalaciones (y potencialmente a los datos de los tarjetahabientes).

9.3.1 Sean autorizados antes de entrar a las áreas donde se procesa o mantiene la información de los tarjetahabientes.

9.3.2 Reciban una identificación física (gafete o dispositivo de acceso) que caduque y que los identifique como personas que no son empleados.

9.3.3 Entreguen su identificación física antes de salir de las instalaciones o en la fecha en que caduque la misma.

El control de visitas es importante para asegurar que los visitantes entren solamente a las áreas donde están autorizados a entrar, que se puedan identificar para que los empleados puedan supervisar sus actividades, y que el acceso esté restringido a la duración de su visita por motivos legítimos.

9.4 Usar un registro de visitas para mantener una bitácora física de la actividad de visitas. Retener este registro por un mínimo de tres meses, a menos que existan otras restricciones impuestas por la ley.

Un registro de visitas resulta poco costoso y fácil de mantener y será de ayuda durante una posible investigación de una violación de seguridad de los datos para identificar el acceso físico a un edificio o sala, y el posible acceso a los datos de los tarjetahabientes. Considere implementar bitácoras en la entrada a las instalaciones y especialmente a las zonas donde haya datos de los tarjetahabientes.



9.5 Guardar las copias de respaldo en un lugar seguro fuera de las instalaciones, que puede ser las instalaciones de un tercero o un almacenaje comercial.

Las copias de respaldo pueden contener datos de los tarjetahabientes y, si se guardan en un lugar que no cuente con la debida seguridad, podrían fácilmente extraviarse, ser robados o copiados con intenciones maliciosas. Para contar con un almacenaje seguro considere contratar con una compañía de almacenaje de datos comerciales O, en el caso de una entidad de menor volumen, utilizar una caja fuerte o caja de seguridad.

9.6 Asegurar físicamente todos los medios electrónicos y en papel (es decir, computadores, medios electrónicos y hardware de redes y comunicaciones, líneas de telecomunicaciones, recibos en papel, reportes impresos y telefacsímiles) que contengan información de los tarjetahabientes.

Los datos de los tarjetahabientes son susceptibles a que alguien los vea, copie o escanee si no están protegidos mientras se encuentran en medios portátiles, en copias impresas, o si se dejan a la vista en un escritorio. Considere establecer procesos y procedimientos para proteger los datos de los tarjetahabientes en los medios distribuidos a usuarios internos o externos. Si no se implementan esos procedimientos es posible que los datos se extravíen o sean robados y utilizados para fines fraudulentos.

9.7 Mantener un control estricto de la distribución interna y externa de cualquier tipo de medio que contenga información de los tarjetahabientes:

9.7.1 Clasificar los medios para que puedan ser identificados como confidenciales.

Es posible que los medios que no estén identificados como confidenciales no se manejen con el debido cuidado y se extravíen o sean robados, Incluya un proceso de clasificación de medios en los procedimientos recomendados en el 9.6 anteriormente.

9.7.2 Enviar los medios a través de un servicio de mensajería o mecanismo de entrega seguro que pueda rastrearse en forma precisa.

Los medios se podrían extraviar o ser robados si se envían utilizando un método que no se pueda rastrear como, por ejemplo, el correo postal normal. Contrate a un servicio de mensajería seguro para efectuar la entrega de cualquier medio que contenga datos de los tarjetahabientes, para poder usar sus sistemas de rastreo al mantener un control de los envíos y la ubicación de los medios.

9.8 Asegurar que la administración apruebe todos los medios que se trasladen desde áreas seguras (particularmente cuando estos medios se distribuyan a personas).

Los datos de los tarjetahabientes que salen de áreas seguras sin pasar por un proceso de aprobación administrativa pueden terminar extraviados o robados. Sin un proceso firmemente establecido no se rastrea la ubicación de los medios, ni tampoco existe un proceso para saber adónde van los datos ni con cuáles protecciones cuentan. Incluya el desarrollo de un proceso de aprobación administrativa para el traslado de medios en los procedimientos recomendados en el 9.6 anteriormente.



9.9 Mantener un control estricto del almacenaje y accesibilidad de los medios que contengan información de los tarjetahabientes.

Sin métodos para realizar un inventario cuidadoso y controles de seguridad, es posible que no se detecten los medios robados o faltantes durante un plazo indefinido. Incluya el desarrollo de un proceso para limitar el acceso a los medios que contengan datos de los tarjetahabientes en los procedimientos recomendados en el 9.6 anteriormente.

9.9.1 Mantener un inventario apropiado de todos los medios y asegurar que los mismos estén almacenados en forma segura.

Si no se mantiene un inventario de los medios, es posible que no se detecten durante un largo tiempo los medios robados o extraviados. Incluya el desarrollo de un proceso para mantener un inventario apropiado de todos los medios y para el almacenaje seguro de los mismos en los procedimientos recomendados en el 9.6 anteriormente.

9.10 Destruir los medios que contengan información de los tarjetahabientes cuando ya no sean necesarios para el negocio o por razones legales, de la manera siguiente:

Si no se toman medidas para destruir la información que contienen los discos duros de los computadores, la información contenida en CD y en papel, descartar esa información podría traer como consecuencia un compromiso de la seguridad y conducir a pérdidas financieras o daño a la reputación de la empresa. Por ejemplo, los delincuentes cibernéticos podrían usar una técnica conocida como “dumpster diving,” que les permite buscar en los cestos de basura y archivos de reciclaje de los computadores y utilizar la información que encuentran allí para lanzar un ataque. Incluya el desarrollo de un proceso para destruir en forma apropiada los medios que contengan datos de los tarjetahabientes en los procedimientos recomendados en el 9.6 anteriormente.

9.10.1 Pasar los materiales impresos por una trituradora que corte en zig zag o reducirlos a pulpa.

9.10.2 Purgar, borrar electrónicamente, triturar o de otra manera destruir los medios electrónicos para que los datos de los tarjetahabientes no se puedan reconstruir.


Orientaciones para los Requisitos 10 y 11: Monitorear y Probar Regularmente las Redes

Requisito 10: Rastrear y monitorear todo el acceso a los recursos de la red y datos de los tarjetahabientes. Los mecanismos de conexión y la capacidad de rastrear las actividades de los usuarios son críticos. La presencia de registros o bitácoras en todos los ambientes permite un rastreo y análisis detallados cuando algo marcha mal. Determinar la causa de un compromiso de la seguridad es una tarea muy difícil cuando el sistema no cuenta con registros de actividad.


10.1 Establecer un proceso para vincular todos los accesos a componentes del sistema (particularmente aquellos realizados con privilegios administrativos - root) a un usuario individual.

Resulta crítico contar con un proceso o sistema que vincule el acceso de los usuarios a los componentes de sistemas a los cuales acceden, en particular para los usuarios con privilegios administrativos. Este sistema genera bitácoras de auditoría y permite trazar la actividad sospechosa a un usuario específico. Los equipos forenses que investigan los incidentes después que ocurren los mismos dependen en gran medida de estas bitácoras para iniciar su investigación.

10.2 Implementar bitácoras de auditoría automatizadas para reconstruir los siguientes eventos en todos los componentes de sistemas: 10.2.1 Todos los accesos a los datos de los

tarjetahabientes por parte de un usuario individual

10.2.2 Todas las acciones de cada persona con privilegios root o administrativos

10.2.3 Acceso a todas las bitácoras de auditoría 10.2.4 Intentos inválidos para lograr un acceso

lógico 10.2.5 Uso de mecanismos de identificación y

autenticación 10.2.6 Inicialización de los registros o bitácoras de

auditoría 10.2.7 Creación y eliminación de todos los objetos a nivel de sistema.

Los delincuentes cibernéticos que navegan la red frecuentemente realizan múltiples intentos para acceder a los sistemas que han seleccionado como blanco de sus actividades. La generación de pistas de auditoría de las actividades sospechosas alerta al administrador del sistema, envía datos a otros mecanismos de monitoreo (como los sistemas de detección de intrusiones) y proporciona una pista para hacer un seguimiento después de un incidente de seguridad.



10.3 Registrar al menos las siguientes bitácoras de auditoria en todos los componentes del sistema para cada evento: 10.3.1 Identificación de usuario 10.3.2 Tipo de evento 10.3.3 Fecha y hora 10.3.4 Éxito o fallo 10.3.5 Origen del evento 10.3.6 Identidad o nombre de los datos, componente

de sistema o recursos afectados.

Registrando estas entradas en el caso de los eventos auditables mencionados en el 10.2 es posible identificar rápidamente un posible compromiso de la seguridad, en suficiente detalle como para saber quién, qué, dónde y cómo.

10.4 Sincronizar todos los relojes y horas de todos los sistemas críticos.

Si un delincuente cibernético ha obtenido acceso a la red, frecuentemente intentará cambiar la hora registrada de sus acciones en las bitácoras de auditoría para evitar que se detecte su actividad. Para los equipos forenses que investigan los incidentes después de ocurridos, la hora de cada actividad es un factor crítico para determinar la forma en que se comprometió la seguridad de los sistemas. Un delincuente podría también tratar de cambiar directamente el reloj en un servidor de hora, si las restricciones de acceso no son las adecuadas, para cambiar la hora a una anterior a la hora en que el delincuente estaba dentro de la red.

10.5 Asegurar las bitácoras de auditoría para que no se puedan alterar.

A menudo un delincuente que ha logrado penetrar en la red intentará editar las bitácoras de auditoría para ocultar su actividad. Si las bitácoras de auditoría no cuentan con protección adecuada, no se podrá garantizar que estén completas y que sean exactas, ni se podrá confiar en su integridad, y es posible que las bitácoras de auditoría sean, por tanto, inservibles como herramientas en una investigación después de ocurrir un compromiso de la seguridad.



10.5.1 Limitar la visualización de las bitácoras de auditoría a las personas que tengan necesidad de verlas por razones de trabajo.

10.5.2 Proteger los archivos de bitácoras de auditoría de las modificaciones no autorizadas.

10.5.3 Respaldar rápidamente los archivos de bitácoras de auditoría a un servidor centralizado o medio de respaldo que sea difícil de alterar.

10.5.4 Copiar los registros o bitácoras de las redes inalámbricas a un servidor de la red de acceso local (LAN).

La protección adecuada de las bitácoras de auditoría incluye un control de acceso fuerte (que limite el acceso a las bitácoras basándose solamente en la necesidad de conocer la información) y el uso de la segregación interna (para lograr que las bitácoras sean difíciles de encontrar y modificar).

10.5.5 Usar el monitoreo de la integridad de los archivos y software para detectar cualquier cambio en las bitácoras a fin de asegurar que los datos existentes en dichos registros no se puedan cambiar sin generar un alerta (aunque al agregar nuevos datos no se deberá generar un alerta).

Los sistemas que monitorean la integridad de los archivos detectan cambios en archivos críticos y notifican cuando se observan esos cambios. Para fines de monitoreo de la integridad de los archivos, una entidad normalmente monitorea los archivos que no necesitan cambios regulares, donde un cambio podría indicar un posible compromiso de la seguridad. En el caso de las bitácoras (que sí cambian con frecuencia) lo que debe monitorear es, por ejemplo, cuando un archivo de bitácora se elimina, súbitamente aumenta o disminuye significativamente de tamaño, o cualquier otro indicador de que un delincuente cibernético ha alterado un archivo de bitácora. Hay herramientas comerciales y de distintos proveedores disponibles para el monitoreo de la integridad de los archivos.

10.6 Revisar los registros y bitácoras de todos los componentes de sistemas al menos diariamente. Estas revisiones deben incluir todos los servidores que realicen funciones de seguridad como servidores de detección de intrusiones (IDS) y de autenticación, autorización y protocolo de contabilidad (AAA) (por ejemplo, RADIUS). Nota: Se puede usar la cosecha de bitácoras, parsing y herramientas para generar alertas para cumplir con el Requisito 10.6.

Muchas violaciones de seguridad ocurren durante días o meses antes de ser detectadas. Verificar diariamente las bitácoras minimiza el tiempo y el riesgo de una violación de seguridad. El proceso de revisión de bitácoras no tiene que ser manual. Especialmente en el caso de las entidades que tienen un gran número de servidores, considere usar la cosecha de bitácoras, parsing y herramientas para generar alertas.



10.7 Retener el historial de bitácoras de auditoría durante al menos un año, con un mínimo de tres meses de disponibilidad en línea.

Retener las bitácoras durante al menos un año toma en consideración el hecho de que a veces transcurre un tiempo antes que se detecte que ha ocurrido o está ocurriendo un compromiso de la seguridad y da a los investigadores un historial lo suficientemente detallado para poder determinar mejor el tiempo que ha durando la violación de seguridad y su posible impacto en los sistemas afectados.


Requisito 11: Probar regularmente los sistemas y procesos de seguridad. Los delincuentes que roban datos de los computadores e investigadores continuamente descubren nuevas vulnerabilidades que se introducen a través de nuevos softwares. Los sistemas, procesos y programas deben probarse frecuentemente para garantizar que los mismos mantengan su seguridad a través del tiempo y los cambios.


11.1 (a) Probar anualmente los controles de seguridad, limitaciones, conexiones de redes y restricciones para asegurar que puedan identificar o detener en forma apropiada cualquier intento de uso no autorizado. Usar un analizador inalámbrico al menos trimestralmente para identificar todos los dispositivos inalámbricos en uso.

Si no se prueban en forma constante, podrían surgir brechas en los controles de seguridad que se pueden explotar.

(b) Usar un analizador inalámbrico al menos trimestralmente para identificar todos los dispositivos inalámbricos en uso.

La implementación y/o explotación de la tecnología inalámbrica dentro de una red es una de las vías más comunes para que los usuarios maliciosos obtengan acceso a la red y a los datos de los tarjetahabientes. Si un dispositivo inalámbrico o red inalámbrica se instala sin el conocimiento de la compañía, puede permitir a un delincuente que fácil e “invisiblemente” entre a la red. Además de analizadores inalámbricos, se pueden usar “nmap” y otras herramientas que detectan los dispositivos inalámbricos en una red.

11.2 Realizar escanes de vulnerabilidad de redes internas y externas al menos trimestralmente y después de cualquier cambio significativo en la red (por ejemplo, instalación de nuevos componentes de sistemas, cambios en la topología de red, modificación de reglas de cortafuegos, mejora de productos). Nota: Los escanes externos de vulnerabilidad trimestrales deberá realizarlos un proveedor calificado especializado en escanes de la industria de tarjetas de pago. El personal interno podrá realizar los escanes después de hacer cambios en las redes.

Un escán de vulnerabilidad es una herramienta automatizada que se usa para analizar los puntos de acceso externos e internos de una red y los dispositivos y servidores de dicha red, a fin de exponer cualquier posible vulnerabilidad e identificar puertos que los delincuentes podrían localizar y explotar. Una vez identificadas estas debilidades, la entidad las corrige para que su red sea más segura.



11.3 Realizar pruebas de penetración de la infraestructura de la red y aplicaciones al menos una vez al año y después de actualizar o mejorar significativamente la infraestructura o cualquier aplicación (por ejemplo, actualización del sistema operativo, adición de una subred al ambiente, adición de un servidor de Web al ambiente). Estas pruebas de penetración deben incluir lo siguiente: 11.3.1 Pruebas de penetración de capas de red 11.3.2 Pruebas de penetración de capa de

aplicación.

Las pruebas de penetración de red y de aplicaciones son distintas a los escanes de vulnerabilidad en el hecho de que las pruebas de penetración son más de índole manual, intentan explotar algunas de las debilidades identificadas en los escanes, y siguen las prácticas que utilizan los delincuentes cibernéticos para aprovechar los sistemas o procesos de seguridad débiles. Antes de activar las aplicaciones, dispositivos de red y sistemas para producción, es necesario asegurarlos utilizando las mejores prácticas de seguridad (según el requisito 2.2). Los escanes de vulnerabilidad y las pruebas de penetración expondrán cualquier vulnerabilidad que quede y que los delincuentes luego podrían localizar y explotar.

11.4 (a) Usar sistemas de detección de intrusiones en la red, sistemas de detección de intrusiones basados en host y/o sistemas de prevención de intrusiones para monitorear todo el tráfico de la red y alertar al personal sobre cualquier sospecha de un compromiso de la seguridad.

Estas herramientas comparan el tráfico que entra en la red con “firmas” conocidas de miles de tipos de compromisos de la seguridad (herramientas que usan los delincuentes, troyanos, etc.) y envían alertas y/o bloquean el intento al ocurrir el mismo. Sin un enfoque proactivo para detectar la actividad no autorizada mediante estas herramientas, los ataques contra los recursos de computación (o el uso indebido de los mismos) podría pasar inadvertido en tiempo real. Los alertas de seguridad que generan estas herramientas se deben monitorear para poder bloquear cualquier intento de intrusión.

(b) Mantener todos los motores de detección y prevención de intrusiones al día.

Existen miles de formas de comprometer la seguridad, y cada día se descubren más. Las versiones más antiguas de los sistemas no tendrán las “firmas” actualizadas y no podrán identificar nuevas vulnerabilidades que pueden traer como resultado que no se detecte una violación de seguridad. Los vendedores de los productos deben proporcionar actualizaciones frecuentes, a menudo diariamente.



11.5 Implementar software de monitoreo de la integridad de los archivos para alertar al personal sobre cualquier modificación no autorizada de un sistema o contenido de un archivo crítico y realizar comparaciones de archivos críticos al menos semanalmente. Los archivos críticos no son necesariamente aquellos que contienen datos de los tarjetahabientes. Para fines de monitoreo de integridad de archivos, los archivos críticos son normalmente aquellos que no cambian regularmente, pero cuya modificación podría indicar un compromiso o riesgo de compromiso de la seguridad del sistema. Los productos para monitorear la integridad de los archivos normalmente vienen preconfigurados con los archivos críticos para el sistema operativo relacionado. Otros archivos críticos, tales como los de aplicaciones individuales, deben ser evaluados y definidos por el comercio o proveedor de servicio).

Los sistemas que monitorean la integridad de los archivos detectan los cambios en archivos críticos y notifican cuando se detectan esos cambios. Hay herramientas comerciales y de distintos proveedores disponibles para el monitoreo de la integridad de los archivos. Si no se implementan estas herramientas y si no se monitorean los datos de salida, un delincuente o un usuario con intenciones maliciosas podría alterar el contenido de los archivos o robar datos sin ser detectado.


Orientaciones para el Requisito 12: Mantener una Política de Seguridad de la Información

Requisito 12: Mantener una política que contemple la seguridad de la información para los empleados y contratistas. Una política sólida de seguridad establece la pauta de la seguridad en toda la compañía y hace a los empleados tomar conciencia de lo que se espera de ellos. Todos los empleados deben estar conscientes del carácter confidencial de los datos y de su responsabilidad de protegerlos.


12.1 Establecer, publicar, mantener y diseminar una política de seguridad que logre lo siguiente: 12.1.1 Contemple todos los requisitos de esta

especificación. 12.1.2 Incluya un proceso anual para identificar

amenazas y vulnerabilidades y que traiga como resultado una evaluación formal de los riesgos.

12.1.3 Incluya una revisión al menos una vez al año y una actualización cuando el ambiente cambie.

La política de seguridad de la información de una compañía crea el plano y la base para implementar medidas de seguridad destinadas a proteger sus activos más valiosos. Una política de alta seguridad establece el tono en el área de la seguridad para toda la compañía y dice a los empleados lo que se espera de ellos. Todos los empleados deben estar conscientes del carácter confidencial de los datos y de sus responsabilidades para protegerlos. Las amenazas de seguridad y los métodos de protección evolucionan rápidamente a lo largo de un año. Si no se actualiza la política de seguridad para reflejar estos cambios, las nuevas medidas de protección para combatir estas amenazas no existirán.

12.2 Desarrollar procedimientos diarios de seguridad operativa que sean congruentes con los requisitos establecidos en esta especificación (por ejemplo, procedimientos de mantenimiento de cuentas, procedimientos de revisión de registros y bitácoras).

Los procedimientos operativos diarios de seguridad sirven como “un manual de instrucciones” que los empleados pueden usar en sus actividades diarias de administración y mantenimiento de sistemas. Si los procedimientos operativos de seguridad no están documentados, eso causará que los empleados no estén conscientes del pleno alcance de sus tareas, y conducirá a procesos que los nuevos empleados no podrán repetir fácilmente, así como a posibles brechas en los procesos, las cuales podrían permitir a un delincuente penetrar los sistemas y recursos críticos.



12.3 Desarrollar políticas de uso de tecnologías críticas que utilizan los empleados (como módems y dispositivos inalámbricos), a fin de definir el uso apropiado de estas tecnologías por parte de todos los empleados y contratistas. Asegurar que estas políticas de uso requieran lo siguiente:

Las políticas de uso por parte de los empleados pueden prohibir que los mismos usen dichos dispositivos si esa es la política de la empresa, o proporcionar a los empleados Orientaciones para el uso e implementación correctos. Si no hay una política de uso establecida, los empleados podrían usar los dispositivos violando la política de la empresa, podrían inadvertidamente establecer módems y/o redes inalámbricas sin seguridad y permitir así a los delincuentes que obtengan acceso a los sistemas críticos y a los datos de los tarjetahabientes. Para asegurar que se sigan las normas de la empresa y solamente se implementen tecnologías aprobadas, considere restringir la implementación a los equipos de operaciones únicamente, y no permita a empleados no especializados instalar estas tecnologías.

12.3.1 Aprobación explícita de la administración Si no se requiere aprobación adecuada por parte de la administración para la implementación de estas tecnologías, un empleado podría implementar inocentemente una solución para un problema percibido del negocio, abriendo una gran brecha que haga a los sistemas y datos críticos vulnerables a los delincuentes cibernéticos.

12.3.2 Autenticación para el uso de la tecnología Si esta tecnología se implementa sin una autenticación apropiada (ID de usuario y contraseñas, tokens, VPN, etc.), los delincuentes podrían utilizar esta tecnología sin protección para acceder a los sistemas críticos y a los datos de los tarjetahabientes.

12.3.3 Una lista de todos los dispositivos y personal que tiene acceso a ellos

Los delincuentes podrían penetrar la seguridad física y colocar sus propios dispositivos en la red para que sirvan como una “puerta trasera”. Los empleados también podrían obviar los procedimientos e instalar dispositivos. Un inventario exacto con etiquetas apropiadas para clasificar los dispositivos permite una identificación rápida de cualquier instalación no aprobada. Considere establecer una convención oficial para nombrar, marcar y registrar todos los dispositivos en consonancia con los controles de inventario establecidos.

12.3.4 Etiquetas en los dispositivos que indiquen su dueño, información de contacto y propósito

12.3.5 Usos aceptables de la tecnología Al definir el uso comercial aceptable y la ubicación de las tecnologías y los dispositivos aprobados por la compañía, la compañía puede administrar y controlar mejor las brechas en las configuraciones y controles operativos, a fin de asegurar que no se abra una “puerta trasera” para que un delincuente obtenga acceso a los sistemas críticos y datos de los tarjetahabientes.

12.3.6 Ubicaciones aceptables en la red para estas tecnologías

12.3.7 Una lista de los productos aprobados por la empresa

12.3.8 Desconexión automática de las sesiones de Los módems son frecuentemente “puertas traseras” para acceder a los


Requisito Orientación módem después de un período específico de inactividad

recursos críticos y a los datos de los tarjetahabientes. Desconectar los módems cuando no se están usando (por ejemplo, los que utilizan los proveedores de equipos de punto de venta para soporte de sistemas y los de otros proveedores), minimiza el acceso a las redes y el riesgo para las mismas. Considere usar controles de módem estándar para desconectar los dispositivos después de 15 minutos de inactividad. Vea también el requisito 8.5.6 para más detalles sobre este tema.

12.3.9 Activación de módems por parte del proveedor solamente cuando sea necesario, con desactivación inmediata después del uso

12.3.10 Al acceder a los datos de los tarjetahabientes en forma remota por módem, prohibir el almacenaje de dichos datos en discos duros locales, disquetes y otros medios externos. Prohibición de las funciones que permiten cortar y pegar e imprimir datos durante el acceso remoto.

Para asegurar que sus empleados estén conscientes de sus responsabilidades de no guardar o copiar los datos de los tarjetahabientes en sus computadores personales y otros medios, la compañía debe contar con una política que claramente prohíba esas actividades.

12.4 Garantizar que la política y los procedimientos de seguridad definan claramente las responsabilidades de seguridad de la información en el caso de todos los empleados y contratistas.

Si los roles con respecto a la seguridad no están claramente definidos y las responsabilidades no están claramente asignadas, es posible que la interacción con el grupo de seguridad no sea constante, lo cual conduciría a una implementación no segura de las tecnologías o al uso de tecnologías obsoletas o que no brindan la debida seguridad.



12.5 Asignar a una persona o equipo las siguientes responsabilidades de administración de seguridad de la información: 12.5.1 Establecer, documentar y distribuir las

políticas y los procedimientos de seguridad. 12.5.2 Monitorear y analizar los alertas y la

información de seguridad y distribuirlos al personal apropiado.

12.5.3 Establecer, documentar y distribuir procedimientos de respuesta a incidentes y procedimientos para acudir a una autoridad superior a fin de asegurar un manejo oportuno y eficaz en todas las situaciones.

12.5.4 Administrar las cuentas de usuarios incluyendo la adición, eliminación y modificación de información.

12.5.5 Monitorear y controlar todo el acceso a los datos.

Cada persona o equipo que tenga responsabilidades relacionadas con la administración de la seguridad de la información debe estar consciente y entender claramente sus responsabilidades y las tareas relacionadas con las mismas, por medio de una política específica. Sin esta posibilidad de asignar responsabilidad concretamente a una persona o equipo podrían existir brechas en los procesos, las cuales podrían abrir el acceso a los recursos críticos o a los datos de los tarjetahabientes.

12.6 Implementar un programa formal de información sobre la seguridad para que todos los empleados estén conscientes de la importancia de la seguridad de los datos.

Si no se educa a los usuarios acerca de sus responsabilidades en relación con la seguridad, las medidas de seguridad y los procesos que se han implementado podrían resultar ineficaces a causa de errores o actos intencionales de los empleados.

12.6.1 Educar a los empleados al contratarlos y al menos anualmente (por ejemplo, por medio de afiches, cartas, memorandos, reuniones y promociones).

Si el programa para aumentar la conciencia sobre la seguridad no incluye sesiones anuales para refrescar los conocimientos, es posible que se olviden u obvien procesos y procedimientos clave de seguridad, lo cual expondría los recursos críticos y los datos de los tarjetahabientes.

12.6.2 Requerir a los empleados que hagan constar por escrito que han leído y comprendido la política y los procedimientos.

Requerir la firma de un empleado ayuda a asegurar que el mismo haya leído y comprendido las políticas y procedimientos de seguridad y se comprometa a cumplir con ellos.



12.7 Hacer una investigación de antecedentes de los candidatos a empleo para minimizar el riesgo de ataques procedentes de fuentes internas. En el caso de los empleados que sólo tengan acceso a un número de tarjeta en un momento dado para facilitar una transacción, tales como los cajeros en las tiendas, este requisito es solamente una recomendación.

Realizar una investigación exhaustiva de antecedentes en el caso de los empleados que tienen acceso a los datos de los tarjetahabientes reduce el riesgo de uso no autorizado de los números de cuenta por parte de personas que tengan antecedentes cuestionables o penales. Se espera que la compañía tenga una política y un proceso para realizar la verificación de antecedentes, incluyendo su propio proceso de decisión sobre cuáles resultados tendrán un impacto en la decisión de contratar o no al candidato a empleo (y cuál será ese impacto).

12.8 Si los datos de los tarjetahabientes se comparten con proveedores de servicio, requerir contractualmente lo siguiente: 12.8.1 Los proveedores de servicio deben adherirse

a los requisitos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI).

12.8.2 Acuerdo que incluye un reconocimiento al efecto de que el proveedor de servicio es responsable por la seguridad de los datos de los tarjetahabientes que tiene en su posesión.

Si un comercio o proveedor de servicio comparte los datos de los tarjetahabientes que tiene con un proveedor de servicio, entonces el proveedor de servicio que recibe los datos de los tarjetahabientes debe firmar un documento local que lo hace responsable de acatar las políticas de seguridad de datos de los tarjetahabientes y reconocer esta responsabilidad. Esto ayuda a garantizar que las entidades externas cumplirán con las medidas para la continua protección de los datos.

12.9 Implementar un plan de respuesta en caso de incidente. Estar preparado para responder inmediatamente a una violación del sistema. 12.9.1 (a) Crear un plan de respuesta a incidentes,

el cual se usará en caso de un compromiso de la seguridad del sistema.

Si no se cuenta con un plan detallado y completo para responder a los incidentes de seguridad que haya sido correctamente diseminado, leído y entendido por todos los responsables, la posible confusión y falta de una respuesta unificada puede traer como resultado más tiempo inoperativo para el negocio, una exposición innecesaria a los medios públicos, y nuevas obligaciones legales.

(b) Asegurar que el plan contemple, como mínimo, procedimientos específicos de respuesta a incidentes, recuperación comercial y reanudación de actividades comerciales, procesos de respaldo de datos, roles y responsabilidades y estrategias de comunicación y contacto (por ejemplo, informar a los Adquirentes y a las asociaciones de tarjetas de pago).

El plan para responder a un incidente de seguridad debe contener todos los elementos clave para que la compañía pueda reaccionar en forma eficaz en caso de una violación de seguridad que afecte los datos de los tarjetahabientes.



12.9.2 Probar el plan al menos anualmente. Si no se realizan pruebas apropiadas, es posible que se omitan pasos clave que pudieran limitar la exposición durante un incidente.

12.9.3 Designar a miembros específicos del personal que estén disponibles 24 horas al día los 7 días de la semana para responder a los alertas.

Si no se cuenta con un equipo de respuesta a incidentes bien capacitado e inmediatamente disponible, es posible que la red sufra más daño y que los datos y sistemas críticos se vean “contaminados” por un manejo incorrecto de los sistemas afectados. Esto podría obstaculizar el éxito de una investigación posterior al incidente. Si no hay recursos internos disponibles, considere contratar con un proveedor que brinde estos servicios. 12.9.4 Proporcionar capacitación apropiada al

personal que tenga la responsabilidad de responder a una violación de la seguridad. .

12.9.5 Incluir alertas de los sistemas de detección de intrusiones, prevención de intrusiones y monitoreo de la integridad de los archivos.

Estos sistemas de monitoreo están diseñados para concentrarse en el posible riesgo para los datos y son críticos para implementar acciones rápidas y prevenir una violación. Asegure que los sistemas de monitoreo estén incluidos en los procesos para responder a un incidente de seguridad.

12.9.6 Desarrollar un proceso para modificar y mejorar el plan de respuesta a incidentes según las lecciones aprendidas de la experiencia e incorporar los desarrollos en la industria.

Incorporar las “lecciones aprendidas” al plan de respuesta a incidentes después de un incidente ayuda a mantener el plan actualizado y en capacidad de reaccionar a las tendencias de seguridad.

12.10 Todos los procesadores y proveedores de servicio deben mantener e implementar políticas y procedimientos para la gestión de las entidades conectadas, los cuales incluirán lo siguiente:

Una “entidad conectada” es una entidad "upstream" que está conectada a un procesador o proveedor de servicio para fines de recibir datos de los tarjetahabientes, incluyendo procesadores, agentes, organizaciones de venta y otros proveedores de servicio. Esta definición de “entidades conectadas” no incluye entidades "downstream" como comercios y otros proveedores de servicio y procesadores que enviaron originalmente los datos y reciben dichos datos de nuevo al serles devueltos los mismos por la entidad en cuestión. Para manejar a estas entidades conectadas en forma eficaz los procesadores y proveedores de servicio deben contar con políticas establecidas que les sirvan de Orientación.

12.10.1. Mantener una lista de las entidades conectadas.

Se debe mantener una lista de inventario de las entidades conectadas para proporcionar información acerca de cada conexión y ayudar a resolver problemas, si es necesario.



12.10.2. Asegurar la debida diligencia antes de conectar a una entidad.

La política debe incluir un proceso de debida diligencia, de acuerdo con la debida diligencia que considere necesaria la compañía.

12.10.3. Asegurarse de que la entidad cumple con las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago.

La intención de este requisito se cumple si la compañía tiene un contrato con la entidad conectada, según el 12.8.1 anterior.

12.10.4. Conectar y desconectar a las entidades siguiendo un proceso establecido.

La política debe incluir una lista de verificación de los pasos que deben ocurrir en el proceso de conexión y en el proceso de desconexión.


Orientaciones para el Requisito A.1: Aplicabilidad de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago para Proveedores de Servicios de Hospedaje Web

Requisito A.1: El proveedor del servicio de hospedaje Web protegerá el ambiente de datos de los tarjetahabientes. Según se menciona en el Requisito 12.8, se requiere que todos los proveedores de servicio que tengan acceso a los datos de los tarjetahabientes (incluidos los proveedores de servicios de hospedaje Web) se adhieran a los requisitos establecidos en las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS). Además, el Requisito 2.4 estipula que todos los proveedores de servicios de hospedaje Web deberán proteger el ambiente y los datos hospedados de cada entidad. Por consiguiente, los proveedores de servicios de hospedaje Web deberán dar especial consideración a lo siguiente: Requisito Orientación

A.1 Proteger el ambiente y los datos hospedados de cada entidad (es decir, del comercio, del proveedor de servicio o de otra entidad) según se indica en los puntos A.1.1 a A.1.4:

El Apéndice A de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago está dirigido a los proveedores de servicios de hospedaje Web que desean proporcionar a sus comercios y/o proveedores de servicio clientes un ambiente de hospedaje que cumpla con dichas normas. Estos pasos se deben cumplir, además de todos los demás requisitos relevantes de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago.

A.1.1 Asegurar que cada entidad tenga acceso únicamente a su propio ambiente de datos de tarjetahabientes.

Si se permite a un comercio o proveedor de servicio ejecutar sus propias aplicaciones en el servidor compartido, las mismas deben ejecutarse con el ID de usuario del comercio o proveedor de servicio, y no como usuario privilegiado. Un usuario privilegiado tendría acceso a los ambientes de datos de tarjetahabientes de todos los demás comercios y proveedores de servicio, al igual que al suyo propio.

A.1.2 Restringir el acceso y los privilegios de cada entidad solamente a su propio ambiente de datos de tarjetahabientes.

Para garantizar que el acceso y los privilegios estén restringidos de forma que cada comercio o proveedor de servicio tenga acceso solamente a su propio ambiente de datos de tarjetahabientes, considere lo siguiente: 1) privilegios de el ID de usuario de servidor de Web del comercio o proveedor de servicio; 2) permisos otorgados para leer, escribir y ejecutar archivos; 3) permisos otorgados para escribir a archivos binarios de sistema; 4) permisos otorgados a los archivos de bitácora del comercio y proveedor de servicio; y 5) controles para asegurar que un comercio o proveedor de servicio no pueda monopolizar los recursos de sistemas.

A.1.3 Asegurar que estén habilitadas las bitácoras de auditoría y que sean únicas para el

Las bitácoras deben estar disponibles en un ambiente de hospedaje compartido para que los comercios y proveedores de servicio tengan acceso a


Requisito Orientación ambiente de datos de tarjetahabientes de cada entidad y cumplan con el Requisito 10 de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago.

las bitácoras específicas de su ambiente de datos de tarjetahabientes y puedan revisar las mismas.

A.1.4 Habilitar procesos que aseguren la investigación forense oportuna en caso de un compromiso de la seguridad de cualquier comercio hospedado o proveedor de servicios.

Los proveedores de servicios de hospedaje Web deben habilitar un proceso para proporcionar una respuesta rápida y fácil en caso de ser necesaria una investigación forense con motivo de un compromiso de la seguridad, hasta el nivel de detalle apropiado, de forma que todos los detalles sobre cada comercio y proveedor de servicio estén disponibles.


Apéndice A: Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI): Documentos Relacionados Los siguientes documentos se han creado para ayudar a los comercios y proveedores de servicio a entender las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago, los requisitos para cumplir con las mismas y sus responsabilidades.

Documento Dirigido a:

PCI Data Security Standard Normas de Seguridad de Datos de la Industria de Tarjetas de Pago

Todos los comercios y proveedores de servicio

Navigating PCI DSS: Understanding the Intent of the Requirements Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Entendiendo la Intención de los Requisitos


PCI Data Security Standard: Self-Assessment Guidelines and Instructions Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Lineamientos e Instrucciones para Completar el Cuestionario de Autoevaluación


PCI Data Security Standard: Self-Assessment Questionnaire A and Attestation Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Cuestionario de Autoevaluación A y Confirmación de Cumplimiento

Comercios1

PCI Data Security Standard: Self-Assessment Questionnaire B and Attestation Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Cuestionario de Autoevaluación B y Confirmación de Cumplimiento

Comercios1

PCI Data Security Standard: Self-Assessment Questionnaire C and Attestation Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Cuestionario de Autoevaluación C y Confirmación de Cumplimiento

Comercios1

PCI Data Security Standard: Self-Assessment Questionnaire D and Attestation Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Cuestionario de Autoevaluación D y Confirmación de Cumplimiento

Proveedores de servicio y todos los demás comercios9

9 A fin de determinar cuál es el Cuestionario de Autoevaluación apropiado, vea Normas de Seguridad de Datos de la Industria de Tarjetas de

Pago: Lineamientos e Instrucciones, “Para Seleccionar el Cuestionario de Autoevaluación y Confirmación de Cumplimiento Que Mejor Se Aplican a Su Organización”.


PCI DSS Glossary, Abbreviations, and Acronyms Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Glosario, Abreviaturas y Acrónimos


Industria de Tarjetas de Pago (PCI) Normas de Seguridad de ...€¦ · de la red que posee los...

Documents

Transcript of Industria de Tarjetas de Pago (PCI) Normas de Seguridad de ...€¦ · de la red que posee los...