Spanish Navigating Pci Dss v1-1 PDF

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
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 i
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
Entendiendo la Intención de los Requisitos Página ii
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.
Entendiendo la Intención de los Requisitos Página iii
Se Permite Protección
Elemento de Datos Guardar Requerida PCI DSS Req. 3, 4
Número de Cuenta Primario Sí Sí Sí
1 1
Datos de los Nombre del Tarjetahabiente Sí Sí No
Tarjetahabientes Código de Servicio1 Sí Sí 1 No
1 1
Fecha de Vencimiento Sí Sí No
Contenido de la Banda
No N/A N/A
Magnética1
Datos Confidenciales de
Autenticación 2 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).
Entendiendo la Intención de los Requisitos Página iv
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.
Entendiendo la Intención de los Requisitos Página v
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.
Entendiendo la Intención de los Requisitos Página vi
Pista 1 Pista 2
Contiene todos los campos de las pistas 1 y 2 Tiempo de procesamiento más corto para las transmisiones con
Longitud de hasta 79 caracteres equipos de discado más antiguos
Longitud de hasta 40 caracteres
Entendiendo la Intención de los Requisitos Página vii
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.
Entendiendo la Intención de los Requisitos Página 2
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 Los cortafuegos son software o dispositivos de hardware que bloquean la
que incluyan lo siguiente: 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 Una política y un proceso para aprobar y probar todas las conexiones y
todas las conexiones externas de la red y los cambios al cortafuego ayudará a prevenir problemas de seguridad a causa de
cambios a la configuración de cortafuegos. una configuración errónea de la red o del cortafuego.
1.1.2 Un diagrama actualizado de la red con todas Los diagramas de la red permiten a la organización identificar la ubicación de
las conexiones que acceden a los datos de todos los dispositivos en su red. Sin un diagrama de red es posible que se
los tarjetahabientes, incluyendo cualquier red pase por alto algún dispositivo, y también podrían quedar sin protección
inalámbrica. 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 Utilizar un cortafuego en cada conexión hacia y desde la red permite a la
conexión a Internet y entre cualquier zona organización monitorear y controlar el acceso hacia dentro y hacia fuera de la
desmilitarizada (DMZ) y la zona de la red red y minimizar las probabilidades de que un delincuente cibernético obtenga
interna. acceso a la red interna.
1.1.4 Descripción de grupos, roles y La descripción de los roles y la asignación de responsabilidades aseguran que
responsabilidades para una administración alguien sea claramente responsable por la seguridad de todos los
lógica de los componentes de la red. 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 Los compromisos de la seguridad frecuentemente ocurren debido a servicios y
necesarios para las actividades del negocio. puertos que no se usan o no tienen seguridad, ya que estos a menudo tienen
vulnerabilidades conocidas y muchas organizaciones no instalan los parches
1.1.6 Justificación y documentación de cualquier
de seguridad en el caso de los servicios y puertos que no usan (aunque las
protocolo disponible aparte de Hypertext vulnerabilidades estén presentes). Cada organización debe decidir claramente
Transfer Protocol (HTTP) y Secure Sockets cuáles servicios y puertos son necesarios para operar su negocio,
Layer (SSL,) Secure Shell (SSH,) y Virtual documentarlos para que quede un registro de los mismos, y asegurar que
Private Network (VPN). 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.7 Justificación y documentación de cualquier Existen muchos protocolos que una empresa podría necesitar (o que están
protocolo riesgoso permitido (por ejemplo, activados por defecto) y que los delincuentes cibernéticos normalmente
File Transfer Protocol o FTP), que incluya la utilizan para comprometer la seguridad de una red. Además de la explicación
razón para usar el protocolo y las funciones sobre el 1.1.5, si es necesario utilizar protocolos riesgosos para el negocio, la
de seguridad implementadas. 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 Esta revisión da a la organización una oportunidad trimestral para eliminar
de cortafuegos y ruteadores. 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
Si se instala un cortafuego pero no se establecen reglas que controlen o
datos de los tarjetahabientes.
limiten ciertos tipos de tráfico, los usuarios maliciosos podrían explotar los
1.3 Desarrollar una configuración de cortafuegos que protocolos y puertos vulnerables para lanzar ataques contra la red de la
restrinja las conexiones entre los servidores empresa.
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 Normalmente un paquete contiene la dirección IP del computador que
direcciones IP (Internet Protocol) dentro del originalmente lo envió. Esto permite que otros computadores de la red sepan
DMZ (filtros de ingreso). de dónde vino. En ciertos casos los delincuentes cibernéticos falsifican esta
dirección IP remitente.
1.3.2 No permitir que las direcciones internas
pasen de Internet al DMZ. 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.3 Implementar la inspección completa, también Un cortafuego que realiza una inspección completa mantiene el “estado” (o
conocida como filtrado dinámico de paquetes “status”) de cada conexión al cortafuego. Al mantenerse el estado, el
(es decir, solamente se permite la entrada a cortafuego sabe si lo que parece ser la respuesta a una conexión previa es
la red a través de las conexiones realmente una respuesta (ya que “recuerda” la conexión previa), o si se trata
“establecidas”). 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 La información de cuenta de la tarjeta de pago requiere el más alto nivel de
de la red, segregada del DMZ. 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 La intención de este requisito es impedir a los delincuentes cibernéticos que
que sea necesario para el ambiente de datos accedan a la red de la organización por medio de una dirección IP no
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 Aunque los archivos de configuración activos normalmente se implementan
configuración de ruteador. Por ejemplo, los con parámetros de seguridad, los archivos de inicio (los ruteadores sólo
archivos de configuración (para el ejecutan estos archivos al reinicio) podrían no estar implementados con los
funcionamiento normal de los ruteadores) y mismos parámetros seguros porque solamente se ejecutan ocasionalmente.
los archivos de configuración de inicio de Cuando un ruteador se reinicia sin los mismos parámetros de seguridad que
operaciones (cuando se hace un re-booting tienen los archivos de configuración, ello podría traer como resultado un
de las máquinas), deben tener la misma debilitamiento de las reglas que permitiría a un delincuente cibernético
configuración segura. penetrar la red.
1.3.7 Rechazar todo el tráfico entrante y saliente Todos los cortafuegos deben incluir una regla que bloquee todo el tráfico
de Internet que no esté específicamente entrante y saliente que no sea específicamente necesario. Ello prevendrá
permitido. 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 La implementación y explotación (a sabiendas o no) de la tecnología
cualquier red inalámbrica y el ambiente de inalámbrica dentro de una red es una vía común para que los usuarios
datos de los tarjetahabientes y configurar maliciosos obtengan acceso a la red y a los datos de los tarjetahabientes. Si
estos cortafuegos para rechazar cualquier se instala un dispositivo o red inalámbrica sin conocimiento de la compañía,
tráfico del ambiente inalámbrico o controlar (si un delincuente podría fácil e “invisiblemente” entrar a la red. Si los cortafuegos
dicho tráfico es necesario para los fines del no restringen el acceso desde redes inalámbricas al ambiente de tarjetas de
negocio) todo el tráfico desde el ambiente pago, los delincuentes que obtengan acceso no autorizado a la red
inalámbrico. 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 Si un computador no tiene instalado un cortafuego o programa antivirus, es
cualquier computador móvil o de propiedad posible descargar sin saberlo algún tipo de spyware, troyano, virus o gusano
de los empleados con conectividad directa a (malware). El computador está aún más vulnerable cuando está conectado
Internet (por ejemplo, laptops que usan los directamente a Internet y no está detrás del cortafuego corporativo. Los
empleados), mediante el cual se acceda a la programas dañinos que se cargan a un computador que no está protegido por
red de la organización. 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 La intención del cortafuego es administrar y controlar todas las conexiones
y cualquier componente de sistema que guarde datos entre los sistemas públicos y los sistemas internos (especialmente aquellos
de los tarjetahabientes (por ejemplo, bases de datos). 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 El DMZ es la parte del cortafuego que queda frente a la red pública, Internet, y
todo el tráfico y prohibir las rutas directas para administra las conexiones entre Internet y los servicios internos que una
el tráfico entrante y saliente de Internet. 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 El DMZ también debe evaluar todo el tráfico saliente de la red para asegurar
aplicaciones de tarjetas de pago a las que todo ese tráfico saliente siga las reglas establecidas. Para que el DMZ
direcciones de Internet (IP) dentro del 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 La implementación de máscaras de IP, que son administradas por el
direcciones internas se traduzcan y revelen en Internet. cortafuego, permite a la organización tener direcciones internas que
Usar tecnologías que implementan el espacio de solamente son visibles dentro de la red y direcciones externas que sólo son
dirección RFC 1918 tales como Port Address visibles externamente. Si un cortafuego no “oculta” o enmascara las
Translation (PAT) o Network Address Translation direcciones de IP de la red interna, es posible que un delincuente cibernético
(NAT). 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 Los delincuentes cibernéticos (externos e internos en una compañía)
proveedores antes de instalar un sistema en la red frecuentemente utilizan los valores, nombres de cuenta y contraseñas por
(por ejemplo, incluir contraseñas, cadenas defecto de los proveedores para comprometer la seguridad de los sistemas.
comunitarias SNMP (Simple Network Management Estos valores por defecto son bien conocidos por los delincuentes y hacen
Protocol), y eliminar cuentas innecesarias). que el sistema de su organización sea altamente vulnerable a un ataque.
2.1.1 En los ambientes inalámbricos, cambiar los Muchos usuarios instalan estos dispositivos sin aprobación de la
valores por defecto programados por los administración y no cambian los valores por defecto ni configuran los
vendedores del equipo inalámbrico, parámetros de seguridad. Si no se implementan las redes inalámbricas con
incluyendo, sin limitación, claves Wireless suficientes configuraciones de seguridad (inluyendo el cambio de valores por
Equivalent Privacy (WEP), Service Set defecto) los “sniffers” que espían las redes inalámbricas podrían espiar el
Identifier (SSID) de selección automática, tráfico, fácilmente capturar datos y contraseñas y penetrar y atacar su red.
contraseñas y cadenas comunitarias SNMP. Además, el protocolo de cambio de claves de la versión 802.11x Encryption
Deshabilitar transmisores SSID. Habilitar la (WEP) más antigua ha sido descifrado y puede inutilizar la encriptación.
tecnología Wi-Fi Protected Access (WPA y
WPA2) para la encriptación y la autenticación
cuando exista capacidad WPA.
2.2 Desarrollar normas de configuración para todos los Existen debilidades conocidas en muchos sistemas operativos, bases de
componentes de sistemas. Asegurar que estas normas datos y aplicaciones empresariales y también existen formas conocidas de
contemplen todas las vulnerabilidades de seguridad configurar estos sistemas para subsanar las vulnerabilidades de seguridad. A
conocidas y sean congruentes con las normas de alta fin de ayudar a los que no son expertos en seguridad, las firmas
seguridad aceptadas en la industria, por ejemplo, por especializadas en seguridad han establecido recomendaciones para aumentar
SysAdmin Audit Network Security Networks (SANS), el la seguridad de los sistemas, las cuales sirven de asesoría para corregir estas
National Institute of Standards Technology (NIST) y el debilidades. Si estas debilidades de los sistemas no se subsanan—por
Center for Internet Security (CIS). 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 La intención en este caso es asegurar que las normas de configuración de
por cada servidor (por ejemplo, los servidores sistemas de su organización y los procesos relacionados contemplen las
de Web, servidores de base de datos y DNS funciones de servidor que necesitan tener diferentes niveles de seguridad o
se deben implementar en servidores que pueden introducir debilidades de seguridad a otras funciones en el mismo
separados). 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 Como se indica en el 1.1.7, muchos protocolos que una empresa podría
innecesarios (servicios y protocolos que no sean necesitar (o tener activados por defecto) son comúnmente utilizados por los
directamente necesarios para realizar la función delincuentes cibernéticos para comprometer la seguridad de una red. Para
especificada de los dispositivos). 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 La intención de este requisito es garantizar que las normas de configuración
sistema para prevenir el uso indebido. 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 Las normas para aumentar la seguridad de los servidores deben incluir
innecesarias, tales como archivos de procesos que contemplen las funcionalidades innecesarias que tengan
comandos (scripts), accionadores, funciones, implicaciones específicas para la seguridad (como eliminar/deshabilitar los
subsistemas, sistemas de archivos y protocolos de transferencia de archivo o el servidor de Web si el servidor no
servidores de Web innecesarios. va a realizar esas funciones).
2.3 Encriptar todo el acceso administrativo que no sea de Si la administración remota no se realiza con autenticación segura y mediante
consola. Usar tecnologías como SSH, VPN o SSL/TLS comunicaciones encriptadas, la información confidencial a nivel administrativo
(Transport Layer Security) para la administración u operativo (como las contraseñas de los administradores) podría ser revelada
basada en Web y otros tipos de acceso administrativo a un espía. Un delincuente cibernético podría utilizar esta información para
sin consola. acceder a la red, hacerse pasar por un administrador del sistema y robar
datos.
2.4 Los proveedores de servicio de hospedaje Web deben Este requisito se aplica a los proveedores de servicio de hospedaje Web que
proteger el ambiente hospedado y los datos de cada mantienen ambientes de hospedaje compartidos por múltiples clientes en el
entidad. Estos proveedores deben cumplir con mismo servidor. Cuando todos los datos se encuentran en el mismo servidor y
requisitos específicos detallados en las Normas de bajo el control de un solo ambiente, a menudo los valores de programación de
Seguridad de Datos de la Industria de Tarjetas de estos servidores compartidos no pueden ser administrados por los clientes
Pago. Consulte el “Apéndice A: “Aplicabilidad de las individuales, y los clientes pueden agregar funciones no seguras y archivos de
Normas de Seguridad de Datos de la Industria de comandos que afectan la seguridad de los ambientes de todos los demás
Tarjetas de Pago para los Proveedores de Servicios clientes, facilitándole a un delincuente el poder comprometer la seguridad de
de Hospedaje Web.” 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 El almacenaje de los datos de los tarjetahabientes más allá del tiempo
almacenados. Desarrollar una política de retención de necesario para fines del negocio crea un riesgo innecesario. Los únicos datos
datos y una política para disponer de los datos. Limitar de los tarjetahabientes que se pueden guardar son el número de cuenta
la cantidad de datos almacenados y el tiempo de primario o PAN (en forma ilegible), la fecha de vencimiento, el nombre y
retención a los que se requieren para fines código de servicio. Recuerde: si no lo necesita, ¡no lo guarde!
comerciales, legales y/o regulatorios, según se haya
documentado en la política de retención de datos.
3.2 No almacenar datos de autenticación confidenciales Los datos confidenciales de autenticación son los datos de la banda
después de la autorización (ni siquiera en forma magnética (o pista)6, el código de validación o valor de la tarjeta7, y los datos
encriptada). del PIN8. Está prohibido guardar los datos confidenciales de
Los datos confidenciales de autenticación incluyen los autenticación. Estos datos son muy valiosos para los delincuentes, ya que
datos citados en los Requisitos 3.2.1 a 3.2.3: 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 Si se guarda el contenido íntegro de la pista los delincuentes cibernéticos que
pista de banda magnética (en el reverso de obtengan esos datos pueden reproducir y vender tarjetas de pago alrededor
una tarjeta, en un chip, o en cualquier otro del globo. El almacenaje de los datos de la pista también viola los reglamentos
lugar). Estos datos alternativamente se operativos de las marcas de pago y puede conducir a multas y penalidades.
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.
3.2.2 No guardar el valor o código de validación de La finalidad del código de validación de tarjeta es proteger las transacciones
tarjeta (número de tres o cuatro dígitos con tarjeta ausente (Internet y órdenes por correo y teléfono), donde ni el
impreso en el anverso o reverso de una consumidor ni la tarjeta están presentes en el momento de realizarse la
tarjeta de pago) utilizado para verificar las transacción. Estos tipos de transacciones se pueden autenticar como
transacciones con tarjeta ausente. realizadas por el titular de la tarjeta solamente solicitando este código de
Nota: Vea el documento titulado “Glosario, validación de tarjeta, ya que el titular de la tarjeta tiene el plástico en su
Abreviaturas y Acrónimos” de las Normas de posesión y puede leer el valor. Si este dato se almacena y después es robado
Seguridad de Datos de la Industria de los delincuentes pueden llevar a cabo transacciones fraudulentas por Internet
Tarjetas de Pago para obtener información y por correo y teléfono. Por eso está prohibido guardar este valor. El
adicional. 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 Estos valores deben ser conocidos solamente por el titular de la tarjeta o el
Personal (PIN) o el bloque de PIN encriptado. banco que emitió la misma. Si se almacenan estos datos y después son
robados los delincuentes pueden llevar a cabo transacciones fraudulentas de
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 El despliegue del número de cuenta primario o PAN completo en pantallas de
desplieguen (los primeros seis y los últimos cuatro computadores, recibos de tarjeta de pago, telefacsímiles o reportes en papel
dígitos son el número máximo de dígitos que se puede puede traer como resultado que personas no autorizadas obtengan y utilicen
desplegar). fraudulentamente el número de cuenta. Tenga presente que este dato se
(Nota: Este requisito no se aplica a empleados y otras puede desplegar completo en la “copia del comercio” de los recibos o en los
entidades que tienen específicamente necesidad de casos en que específicamente se necesite ver el número de cuenta primario
ver el Número de Cuenta Primario, ni supersede los completo.
requisitos más estrictos establecidos para el
despliegue de datos de los tarjetahabientes (por
ejemplo, en recibos de terminales de punto de venta
[POS]).
3.4 Asegurar que el Número de Cuenta Primario (PAN), No proteger los números de cuenta primarios podría permitir que usuarios
como mínimo, sea ilegible en cualquier lugar donde internos no autorizados e intrusos vean o descarguen estos datos. Los
esté guardado (incluyendo datos en medios digitales números de cuenta primarios guardados en un almacenaje primario (base de
portátiles, medios de respaldo, registros o bitácoras, y datos o archivo plano como los archivos de texto y hojas de cálculo) así como
datos recibidos de redes inalámbricas o guardados en en un almacenaje no primario (copias de respaldo, bitácoras de auditoría,
las mismas) utilizando los siguientes métodos: 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).
• 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 Los tokens de índice y pads también se pueden usar para hacer ilegibles los
guardado bajo seguridad) 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 La intención de la criptografía de alta seguridad (vea la definición y longitudes
Triple-DES de 128 bits o el AES de 256 bits con de las claves en el Glosario, Abreviaturas y Acrónimos de las Normas de
procesos y procedimientos asociados de Seguridad de Datos de la Industria de Tarjetas de Pago) es basar la
administración de claves 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 intención de este requisito es contemplar si la encriptación de disco es
la encriptación a nivel de archivo o columna aceptable para lograr que los datos de los tarjetahabientes queden ilegibles.
de base de datos), el acceso lógico deberá La encriptación de disco encripta los datos guardados en almacenaje masivo
administrarse independientemente de los en un computador y automáticamente decripta la información cuando un
mecanismos de control de acceso de los usuario autorizado lo solicita. Los sistemas de encriptación de disco
sistemas operativos nativos (por ejemplo, no interceptan las operaciones de lectura y escritura del sistema operativo y
usar las cuentas del sistema o Directorio llevan a cabo las transformaciones criptográficas apropiadas sin ninguna
Activo local). Las claves de decriptación no acción específica o especial del usuario, con la excepción de proporcionar una
deberán estar vinculadas a las cuentas de los contraseña o frase en clave al comenzar la sesión. Dadas estas
usuarios. características de la encriptación de disco, para cumplir con este requisito el
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 Las claves (o llaves) de encriptación deben estar sólidamente protegidas
divulgación y el uso indebido. 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 Sólo muy pocas personas deben tener acceso a las claves de encriptación,
número mínimo de custodios necesarios. por lo general solamente las personas que tengan responsabilidades de
custodia.
3.5.2 Guardar las claves en forma segura en el Las claves de encriptación se deben guardar en forma segura, normalmente
mínimo número de ubicaciones y formatos con las claves de encriptación de clave, y en muy pocos lugares.
posibles.
3.6 Documentar e implementar totalmente todos los La forma en que se administran las claves de encriptación es crítica para la
procesos y procedimientos de administración de continua seguridad de la solución de encriptación. Un buen proceso de
claves, incluyendo los siguientes: 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 Si el proveedor de la aplicación de encriptación los ha proporcionado, siga sus
• Según se considere necesario y lo procesos y recomendaciones para cambiar periódicamente las claves.
recomiende la aplicación asociada (por Es esencial cambiar anualmente las claves de encriptación para minimizar el
ejemplo volver a digitar las claves), riesgo de que alguien las obtenga y pueda decriptar los datos.
preferiblemente en forma automática
• Al menos anualmente.
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 El conocimiento no compartido y el control dual se usan para eliminar la
control dual de las claves (de forma que se posibilidad de que una persona tenga acceso a la clave completa. Este control
requiera a 2 o 3 personas, cada una de las normalmente se aplica en el caso de los sistemas de encriptación manual de
cuales conozca solamente una parte de la claves o donde el producto de encriptación no implementa la administración
clave, para reconstruir la clave completa). 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 La solución de encriptación no debe permitir o aceptar la sustitución de claves
las claves procedente de fuentes no autorizadas o procesos inesperados.
3.6.8 Reemplazo de claves cuando se sepa o La solución de encriptación debe permitir y facilitar un proceso para
sospeche que su seguridad ha sido reemplazar las claves cuya seguridad se sabe o sospecha ha sido
comprometida. 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 Este proceso asegurará que la persona se comprometa con su papel de
firmen un formulario especificando que custodio de las claves y comprenda sus responsabilidades.
comprenden y aceptan su responsabilidad
como custodios de las claves.
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 La información confidencial se debe encriptar durante su transmisión a través
Secure Sockets Layer (SSL)/Transport Layer Security de redes públicas, ya que es fácil y común que un delincuente cibernético
(TLS) e Internet Protocol Security (IPSEC) para intercepte y/o desvíe los datos mientras se encuentran en tránsito. Tenga
salvaguardar los datos confidenciales de los presente que las versiones SSL anteriores a la versión 3.0 contienen
tarjetahabientes durante su transmisión a través de vulnerabilidades documentadas como, por ejemplo, buffer overflows, que un
redes públicas abiertas. atacante puede utilizar para obtener el control del sistema afectado.
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).
4.1.1 En el caso de las redes inalámbricas que Los delincuentes cibernéticos utilizan herramientas que se obtienen en forma
transmitan datos de los tarjetahabientes, gratuita y están fácilmente disponibles para espiar las comunicaciones
encriptar las transmisiones usando la tecnología inalámbricas. El uso apropiado de la encriptación puede evitar este tipo de
Wi-Fi Protected Access (WPA o WPA2), IPSEC espionaje y la divulgación de la información confidencial a través de la red. En
VPN, o SSL/TLS. Nunca depender muchas ocasiones en que solamente la seguridad de los datos de los
exclusivamente de Wired Equivalent Privacy tarjetahabientes almacenados en la red alámbrica se ha visto comprometida el
(WEP) para proteger el carácter confidencial y el origen del compromiso de la seguridad fue que el delincuente logró el acceso
acceso a una red de acceso local (LAN) desde una red inalámbrica. No se debe usar nunca la encriptación con WEP
inalámbrica: por sí sola, ya que es vulnerable debido a vectores iniciales débiles (IV) en el
• Usar con una clave de encriptación de un proceso de intercambio de claves WEP, y carece de la rotación requerida de
mínimo de 104 bits y valor de claves. Un atacante podría utilizar libremente herramientas de penetración con
inicialización de 24 bits. fuerza bruta para penetrar la encriptación WEP.
• 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).
4.2 No enviar nunca información del tarjetahabiente por El correo electrónico se puede interceptar fácilmente espiando los paquetes
correo electrónico sin encriptar. 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 Constantemente se lanzan ataques contra sistemas que en lo demás son
comúnmente afectados por virus (particularmente seguros utilizando debilidades ampliamente divulgadas, a menudo con “0
computadores personales y servidores). días” (porque se publicaron y divulgaron a través de las redes en menos de
Nota: Los sistemas comúnmente afectados por virus una hora a partir de su descubrimiento). Sin un software antivirus que se
típicamente no incluyen los sistemas operativos actualice regularmente, estos nuevos virus pueden atacar y desactivar su red.
basados en UNIX o mainframes.
5.1.1 Asegurar que todos los programas antivirus Es importante contar con protección contra TODO tipo y formato de software
sean capaces de detectar, eliminar y proteger malicioso.
contra otros tipos de software malicioso y
destructivo, incluyendo spyware y adware.
5.2 Asegurar que todos los mecanismos antivirus estén El mejor software antivirus está limitado en su eficacia si no cuenta con firmas
actualizados, estén funcionando activamente y sean antivirus actualizadas o si no está activo en la red o en el computador de un
capaces de generar registros y bitácoras de auditoría. 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 Hay un considerable número de ataques utilizando debilidades ampliamente
software cuenten con los parches de seguridad más divulgadas y publicadas, a menudo “0 días” (es decir, con menos de una hora
recientes proporcionados por los proveedores. Instalar de publicadas) contra sistemas que en lo demás son seguros. Si no se
los parches de seguridad relevantes dentro de un plazo implementan los parches más recientes en los sistemas lo más pronto posible,
de de un mes de publicados. 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 La intención de este requisito es mantener a las organizaciones al día con
vulnerabilidades de seguridad recientemente respecto a las nuevas vulnerabilidades, a fin de que puedan proteger su red
descubiertas (por ejemplo, suscribirse a los servicios en forma apropiada e incorporar vulnerabilidades recientemente descubiertas
de alerta disponibles en forma gratuita a través de y relevantes a sus normas de configuración.
Internet). Actualizar sus normas para subsanar
cualquier nuevo problema de vulnerabilidad que
pudiera surgir.
6.3 Desarrollar aplicaciones de software basadas en las Si no se incluye la seguridad durante las etapas de definición, diseño, análisis
mejores prácticas de la industria e incorporar la y prueba del desarrollo de software, se podrían introducir inadvertida o
seguridad de la información a través de todo el ciclo de maliciosamente vulnerabilidades de seguridad en el ambiente de producción.
desarrollo de software.
6.3.1 Hacer pruebas de todos los parches de Eso asegura que todas las instalaciones y cambios funcionen de la forma
seguridad y cambios de configuración de esperada y que no tengan ninguna función inesperada, indeseable o dañina.
sistema antes de implementarlos.
6.3.2 Separar los ambientes de desarrollo, prueba y A menudo los ambientes de desarrollo y prueba son menos seguros que el
producción. 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 Esto minimiza el número de empleados que tienen acceso al ambiente de
ambientes de desarrollo, prueba y producción y ayuda a asegurar que el acceso esté limitado a aquellos que
producción. verdaderamente necesiten ese acceso.
6.3.4 Los datos de producción (números reales de Los controles de seguridad normalmente no son tan estrictos en el ambiente
cuentas de tarjetas) no se usan para fines de de desarrollo. El uso de datos de producción da a los delincuentes
prueba y desarrollo. 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 Los datos y cuentas de prueba deben eliminarse del código de producción
antes de activar los sistemas 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 Las cuentas, nombres de usuarios y contraseñas de las aplicaciones
contraseñas de las aplicaciones individuales individuales deben eliminarse del código de producción antes que la
antes que las aplicaciones se activen o se aplicación se active o ponga a disposición de los clientes, ya que estos datos
pongan a disposición de los clientes. 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 Los delincuentes comúnmente explotan las vulnerabilidades de seguridad en
ponerlos en producción o a disposición de los los códigos individuales para obtener acceso a una red y comprometer la
clientes, a fin de identificar cualquier seguridad de los datos de los tarjetahabientes. Los que tengan conocimiento
vulnerabilidad relacionada con la codificación. 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 Sin controles apropiados de cambio de sistemas las funciones de seguridad
todas las modificaciones de configuración de sistemas podrían inadvertida o deliberadamente omitirse o deshabilitarse de manera
y software. Los procedimientos deben incluir lo que queden inoperables, podrían ocurrir irregularidades de procesamiento o
siguiente: 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 La aprobación de la administración significa que el cambio es legítimo y está
funcionarios apropiados 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 La capa de aplicaciones es de alto riesgo y puede ser objeto de ataques de
como base las directrices de codificación segura como procedencia tanto interna como externa. Sin una seguridad apropiada los
Open Web Application Security Project Guidelines. datos de los tarjetahabientes y otros tipos de información confidencial de la
Revisar el código de aplicación individual para identificar empresa podrían verse expuestos, lo que podría traer como resultado un daño
vulnerabilidades de codificación. Contemplar la para la compañía, sus clientes y su reputación.
prevención de vulnerabilidades comunes de codificación
en los procesos de desarrollo de software, que incluyen
las siguientes:
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, Los usuarios maliciosos a menudo intentan escanear y enumerar las cuentas
uso malicioso de las identificaciones de de usuarios existentes en las aplicaciones para encontrar un punto de entrada
usuarios) 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 Las credenciales de las cuentas y tokens de sesiones deben estar protegidos
administración de sesiones (uso de en forma apropiada. Los ataques contra las contraseñas, claves, cookies de
credenciales de cuenta y cookies de sesión) 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 En el caso de estos ataques se usa la aplicación de Web para enviar un
ventanas pertenecientes a diferentes ataque al explorador de red de un usuario final, lo cual puede traer como
dominios (el llamado Cross-Site Scripting o resultado la divulgación del token de sesión del usuario, un ataque contra la
XSS). 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 Para agilizar la conectividad y reducir el desempeño en el servidor, con
de Structured Query Language, SQL) 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 Los ataques en las aplicaciones hacia la Web son comunes y a menudo
estén protegidas contra ataques conocidos mediante exitosos y las prácticas de codificación deficientes son las que permiten que
cualquiera de los siguientes métodos: 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 También se debe usar para satisfacer este requisito una herramienta que
seguridad de aplicaciones revise todos los realice revisiones de codificación y/o escanee para detectar vulnerabilidades
códigos individuales de aplicación para eliminar en las aplicaciones.
vulnerabilidades comunes.
• Instalando un cortafuego a nivel de capa de Los cortafuegos de aplicaciones se utilizan para filtrar y bloquear todo el
aplicación frente a las aplicaciones conectadas a tráfico que no sea esencial en la capa de aplicación. Utilizado en conjunción
la Web. 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.
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.
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 Mientras más personas tengan acceso a los datos de los tarjetahabientes,
la información de los tarjetahabientes exclusivamente a más riesgo habrá de que la cuenta de un usuario se utilice en forma maliciosa.
aquellas personas que por necesidad de su trabajo Limitar el acceso a aquellas personas que por razones de su trabajo tengan
requieran dicho acceso. 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 Sin un mecanismo que restrinja el acceso basándose en la necesidad del
múltiples usuarios que restrinja el acceso tomando usuario de conocer la información, un usuario podría inadvertidamente
como base la necesidad del usuario de conocer la obtener acceso a los datos de los tarjetahabientes.
información y esté programado para negar el acceso a
todo el mundo, a menos que esté permitido
específicamente.
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 Asegurando que se identifique en forma única a cada usuario—en lugar de
usuario único antes de permitirles el acceso a los usar un ID para varios empleados—una organización puede mantener la
componentes de sistemas y datos de los responsabilidad individual por las acciones y una pista de auditoría eficaz por
tarjetahabientes. 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 Cuando se utilizan junto con un ID único, estos elementos de autenticación
menos uno de los métodos enumerados a continuación ayudan a proteger el ID único del usuario para que no se vea comprometida
para autenticar a todos los usuarios: su seguridad (ya que el que intenta comprometer esa seguridad necesita
• Contraseña conocer el ID único del usuario y, además, la contraseña u otro elemento de
autenticación).
• Dispositivos de token (por ejemplo, SecureID,
certificados o clave pública)
• Biométrica
8.3 Implementar la autenticación de 2 factores para el Las tecnologías de autenticación de dos factores brindan una contraseña para
acceso remoto a la red por parte de los empleados, un solo uso, la cual se utiliza cuando se necesita otro elemento de
administradores y terceros. Usar tecnologías como autenticación adicional para accesos de más alto riesgo, por ejemplo, desde
Remote Authentication and Dial-In Service (RADIUS) o fuera de su red. Para contar con seguridad adicional su organización podría
Terminal Access Controller Access Control System también considerar el uso de la autenticación de dos factores para acceder de
(TACACS) con tokens, o VPN (basado en SSL/TLS o una red de menor seguridad a una red de mayor seguridad (por ejemplo,
IPSEC) con certificados individuales. 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 Muchos dispositivos de red y aplicaciones transmiten el ID del usuario y la
y el almacenaje, en todos los componentes de contraseña a través de la red sin encriptarla y/o guardan la contraseña sin
sistemas. 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 Puesto que uno de los primeros pasos de un delincuente cibernético para
la administración correcta de las contraseñas de los comprometer la seguridad de un sistema es explotar las contraseñas débiles o
usuarios y administradores en todos los componentes el hecho de que no existan contraseñas, es importante implementar buenos
de sistemas de la manera siguiente: procesos de autenticación de usuarios y administración de contraseñas.
8.5.1 Controlar la adición, eliminación y Para asegurar que los usuarios añadidos a su sistema sean todos usuarios
modificación de las identificaciones de válidos y reconocidos, un pequeño grupo de empleados con autoridad
usuarios, credenciales y otros objetos de específica debe administrar y controlar la adición, eliminación y modificación
identificació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 Muchos delincuentes cibernéticos utilizan la “ingeniería social”—por ejemplo,
reprogramar (reset) las contraseñas. 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 Si se usa la misma contraseña para cada nuevo usuario que se establece, un
usuario a un valor único para dicho usuario y usuario interno, antiguo empleado o delincuente cibernético puede conocer o
cambiarla inmediatamente después del primer fácilmente descubrir esta contraseña y utilizarla para obtener acceso a las
uso. cuentas.
8.5.4 Revocar inmediatamente el acceso de todo Si un empleado ha cesado en sus funciones con la empresa y aún tiene
usuario que ya no sea un empleado o no lo acceso a la red a través de su cuenta de usuario, podría ocurrir un acceso
requiera. 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 La existencia de cuentas inactivas permite a un usuario no autorizado explotar
menos cada 90 días. la cuenta que no se utiliza para posiblemente acceder a los datos de los
tarjetahabientes.
8.5.6 Habilitar las cuentas que usan los Permitir a los proveedores (por ejemplo, de equipos de punto de venta) que
proveedores para mantenimiento remoto tengan acceso a su red las 24 horas del día, los 7 días de la semana, en caso
solamente durante el tiempo necesario. 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 Comunicar a todos los usuarios los procedimientos relacionados con las
relacionadas con las contraseñas a todos los contraseñas ayuda a esos usuarios a entender y acatar las políticas y a estar
usuarios que tengan acceso a los datos de alerta para detectar a cualquier usuario malicioso que intente explotar su
los tarjetahabientes. 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, Si múltiples usuarios comparten la misma cuenta y contraseña, será imposible
compartidas o genéricas. 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 Las contraseñas de alta seguridad son la primera línea de defensa para
menos cada 90 días. 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
8.5.10 Requerir una longitud mínima de contraseña
no estén protegidas por una contraseña. Hay más tiempo para que un
de al menos siete caracteres. atacante localice estas cuentas débiles y comprometa la seguridad de la red
8.5.11 Usar contraseñas que contengan tanto bajo el disfraz de un ID de usuario válido si las contraseñas son breves y
caracteres numéricos como alfabéticos. 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
8.5.12 No permitir a ninguna persona que presente mantener de acuerdo con estos requisitos habilitando las funciones de
una nueva contraseña que sea igual que seguridad de contraseña y cuenta que vienen con su sistema operativo (por
cualquiera de las últimas cuatro que ha ejemplo Windows), las redes, bases de datos y otras plataformas.
utilizado.
8.5.13 Limitar los intentos repetidos de lograr acceso Sin mecanismos establecidos para bloquear los intentos de acceso a las
bloqueando la ID del usuario después de un cuentas un atacante puede continuamente tratar de adivinar una contraseña
máximo de seis intentos. 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 Si una cuenta se bloquea debido a que alguien continuamente trata de
treinta minutos o hasta que el administrador adivinar una contraseña, los controles que retardan la reactivación de estas
del sistema habilite el ID del usuario. 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 Cuando los usuarios se alejan de una máquina abierta que brinda acceso a la
durante más de 15 minutos, requerir que el red o a datos críticos de los tarjetahabientes, otros podrían utilizar esa
usuario vuelva a ingresar la contraseña. 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 Si no se implementa la autenticación de base de datos el potencial de acceso
de datos que contenga información de los no autorizado a la base de datos aumenta, y dicho acceso no se puede
tarjetahabientes. Esto incluye acceso por registrar en una bitácora porque el usuario no ha sido autenticado y por tanto
parte de las aplicaciones, los administradores el sistema no lo reconoce. Igualmente, el acceso a cualquier base de datos
y todos los demás usuarios. 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
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 Si se implementan controles de acceso físico cualquier persona no autorizada
instalaciones para limitar y monitorear el acceso a los podría obtener acceso al edificio y a la información confidencial, y podría
sistemas que almacenan, procesan o transmiten datos alterar las configuraciones de sistema, introducir vulnerabilidades en la red o
de los tarjetahabientes. destruir o robar equipos.
9.1.1 Usar cámaras para vigilar las áreas Sin “ojos” que vigilen los sistemas críticos, es más difícil prevenir violaciones
vulnerables. Auditar estos datos y de la seguridad física e investigarlas, y no es posible identificar a los
correlacionar con otros. Guardar durante al atacantes.
menos tres meses, a menos que existan otras
restricciones impuestas por la ley.
9.1.2 Restringir el acceso físico a los conectores de Restringir el acceso a los conectores de redes evitará que un delincuente
redes (network jacks) accesibles al público. 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 Si no se implementan medidas de seguridad para el acceso a los
acceso inalámbrico, pasarelas y dispositivos componentes y dispositivos inalámbricos, un usuario malicioso podría utilizar
handheld. 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 Si no se implementan sistemas de gafetes y controles en las puertas, un
personal a distinguir fácilmente a los empleados de los usuario no autorizado o malicioso podría fácilmente obtener acceso a sus
visitantes en las áreas en que la información de los instalaciones para robar, deshabilitar, bloquear o destruir sistemas críticos y
tarjetahabientes está accesible. datos de los tarjetahabientes. Para tener un control óptimo, considere
“Empleado” se refiere a los funcionarios que laboran a implementar un sistema de acceso con gafetes o tarjetas para controlar
jornada completa o parcial, empleados y personal entradas y salidas en áreas donde haya datos de los tarjetahabientes.
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.
9.3 Asegurar que se haga lo siguiente en el caso de todos El control de visitas es importante para reducir las probabilidades de que una
los visitantes: 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 El control de visitas es importante para asegurar que los visitantes entren
donde se procesa o mantiene la información solamente a las áreas donde están autorizados a entrar, que se puedan
de los tarjetahabientes. identificar para que los empleados puedan supervisar sus actividades, y que el
9.3.2 Reciban una identificación física (gafete o acceso esté restringido a la duración de su visita por motivos legítimos.
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.
9.4 Usar un registro de visitas para mantener una bitácora Un registro de visitas resulta poco costoso y fácil de mantener y será de ayuda
física de la actividad de visitas. Retener este registro durante una posible investigación de una violación de seguridad de los datos
por un mínimo de tres meses, a menos que existan para identificar el acceso físico a un edificio o sala, y el posible acceso a los
otras restricciones impuestas por la ley. 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 Las copias de respaldo pueden contener datos de los tarjetahabientes y, si se
fuera de las instalaciones, que puede ser las guardan en un lugar que no cuente con la debida seguridad, podrían
instalaciones de un tercero o un almacenaje comercial. 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 Los datos de los tarjetahabientes son susceptibles a que alguien los vea,
en papel (es decir, computadores, medios electrónicos copie o escanee si no están protegidos mientras se encuentran en medios
y hardware de redes y comunicaciones, líneas de portátiles, en copias impresas, o si se dejan a la vista en un escritorio.
telecomunicaciones, recibos en papel, reportes Considere establecer procesos y procedimientos para proteger los datos de
impresos y telefacsímiles) que contengan información los tarjetahabientes en los medios distribuidos a usuarios internos o externos.
de los tarjetahabientes. 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 Es posible que los medios que no estén identificados como confidenciales no
identificados como confidenciales. 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 Los medios se podrían extraviar o ser robados si se envían utilizando un
mensajería o mecanismo de entrega seguro método que no se pueda rastrear como, por ejemplo, el correo postal normal.
que pueda rastrearse en forma precisa. 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 Los datos de los tarjetahabientes que salen de áreas seguras sin pasar por un
medios que se trasladen desde áreas seguras proceso de aprobación administrativa pueden terminar extraviados o robados.
(particularmente cuando estos medios se distribuyan a Sin un proceso firmemente establecido no se rastrea la ubicación de los
personas). 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 Sin métodos para realizar un inventario cuidadoso y controles de seguridad,
accesibilidad de los medios que contengan información es posible que no se detecten los medios robados o faltantes durante un plazo
de los tarjetahabientes. indefinido. Incluya el desarrollo de un proceso para limitar el acceso a los
medios que contengan datos de los tarjetahabientes en los procedimientos
9.9.1 Mantener un inventario apropiado de todos Si no se mantiene un inventario de los medios, es posible que no se detecten
los medios y asegurar que los mismos estén durante un largo tiempo los medios robados o extraviados. Incluya el
almacenados en forma segura. desarrollo de un proceso para mantener un inventario apropiado de todos los
medios y para el almacenaje seguro de los mismos en los procedimientos
9.10 Destruir los medios que contengan información de los Si no se toman medidas para destruir la información que contienen los discos
tarjetahabientes cuando ya no sean necesarios para el duros de los computadores, la información contenida en CD y en papel,
negocio o por razones legales, de la manera siguiente: 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
9.10.1 Pasar los materiales impresos por una empresa. Por ejemplo, los delincuentes cibernéticos podrían usar una técnica
trituradora que corte en zig zag o reducirlos a
conocida como “dumpster diving,” que les permite buscar en los cestos de
pulpa. basura y archivos de reciclaje de los computadores y utilizar la información
9.10.2 Purgar, borrar electrónicamente, triturar o de que encuentran allí para lanzar un ataque. Incluya el desarrollo de un proceso
otra manera destruir los medios electrónicos para destruir en forma apropiada los medios que contengan datos de los
para que los datos de los tarjetahabientes no tarjetahabientes en los procedimientos recomendados en el 9.6 anteriormente.
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 Resulta crítico contar con un proceso o sistema que vincule el acceso de los
a componentes del sistema (particularmente aquellos usuarios a los componentes de sistemas a los cuales acceden, en particular
realizados con privilegios administrativos - root) a un para los usuarios con privilegios administrativos. Este sistema genera
usuario individual. 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 Los delincuentes cibernéticos que navegan la red frecuentemente realizan
reconstruir los siguientes eventos en todos los múltiples intentos para acceder a los sistemas que han seleccionado como
componentes de sistemas: blanco de sus actividades. La generación de pistas de auditoría de las
10.2.1 Todos los accesos a los datos de los actividades sospechosas alerta al administrador del sistema, envía datos a
tarjetahabientes por parte de un usuario otros mecanismos de monitoreo (como los sistemas de detección de
individual intrusiones) y proporciona una pista para hacer un seguimiento después de un
incidente de seguridad.
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.
10.3 Registrar al menos las siguientes bitácoras de auditoria Registrando estas entradas en el caso de los eventos auditables mencionados
en todos los componentes del sistema para cada en el 10.2 es posible identificar rápidamente un posible compromiso de la
evento: seguridad, en suficiente detalle como para saber quién, qué, dónde y cómo.
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.
10.4 Sincronizar todos los relojes y horas de todos los Si un delincuente cibernético ha obtenido acceso a la red, frecuentemente
sistemas críticos. 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 A menudo un delincuente que ha logrado penetrar en la red intentará editar
puedan alterar. 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 La protección adecuada de las bitácoras de auditoría incluye un control de
auditoría a las personas que tengan acceso fuerte (que limite el acceso a las bitácoras basándose solamente en la
necesidad de verlas por razones de trabajo. necesidad de conocer la información) y el uso de la segregación interna (para
10.5.2 Proteger los archivos de bitácoras de lograr que las bitácoras sean difíciles de encontrar y modificar).
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).
10.5.5 Usar el monitoreo de la integridad de los Los sistemas que monitorean la integridad de los archivos detectan cambios
archivos y software para detectar cualquier en archivos críticos y notifican cuando se observan esos cambios. Para fines
cambio en las bitácoras a fin de asegurar que de monitoreo de la integridad de los archivos, una entidad normalmente
los datos existentes en dichos registros no se monitorea los archivos que no necesitan cambios regulares, donde un cambio
puedan cambiar sin generar un alerta podría indicar un posible compromiso de la seguridad. En el caso de las
(aunque al agregar nuevos datos no se bitácoras (que sí cambian con frecuencia) lo que debe monitorear es, por
deberá generar un alerta). 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 Muchas violaciones de seguridad ocurren durante días o meses antes de ser
componentes de sistemas al menos diariamente. Estas detectadas. Verificar diariamente las bitácoras minimiza el tiempo y el riesgo
revisiones deben incluir todos los servidores que de una violación de seguridad. El proceso de revisión de bitácoras no tiene
realicen funciones de seguridad como servidores de que ser manual. Especialmente en el caso de las entidades que tienen un
detección de intrusiones (IDS) y de autenticación, gran número de servidores, considere usar la cosecha de bitácoras, parsing y
autorización y protocolo de contabilidad (AAA) (por herramientas para generar alertas.
ejemplo, RADIUS).
Nota: Se puede usar la cosecha de bitácoras, parsing y
herramientas para generar alertas para cumplir con el
Requisito 10.6.
10.7 Retener el historial de bitácoras de auditoría durante al Retener las bitácoras durante al menos un año toma en consideración el
menos un año, con un mínimo de tres meses de hecho de que a veces transcurre un tiempo antes que se detecte que ha
disponibilidad en línea. 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, Si no se prueban en forma constante, podrían surgir brechas en los controles
limitaciones, conexiones de redes y restricciones de seguridad que se pueden explotar.
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.
(b) Usar un analizador inalámbrico al menos La implementación y/o explotación de la tecnología inalámbrica dentro de una
trimestralmente para identificar todos los red es una de las vías más comunes para que los usuarios maliciosos
dispositivos inalámbricos en uso. 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 Un escán de vulnerabilidad es una herramienta automatizada que se usa para
externas al menos trimestralmente y después de analizar los puntos de acceso externos e internos de una red y los dispositivos
cualquier cambio significativo en la red (por ejemplo, y servidores de dicha red, a fin de exponer cualquier posible vulnerabilidad e
instalación de nuevos componentes de sistemas, identificar puertos que los delincuentes podrían localizar y explotar. Una vez
cambios en la topología de red, modificación de reglas identificadas estas debilidades, la entidad las corrige para que su red sea más
de cortafuegos, mejora de productos). segura.
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.
11.3 Realizar pruebas de penetración de la infraestructura Las pruebas de penetración de red y de aplicaciones son distintas a los
de la red y aplicaciones al menos una vez al año y escanes de vulnerabilidad en el hecho de que las pruebas de penetración son
después de actualizar o mejorar significativamente la más de índole manual, intentan explotar algunas de las debilidades
infraestructura o cualquier aplicación (por ejemplo, identificadas en los escanes, y siguen las prácticas que utilizan los
actualización del sistema operativo, adición de una delincuentes cibernéticos para aprovechar los sistemas o procesos de
subred al ambiente, adición de un servidor de Web al seguridad débiles.
ambiente). Estas pruebas de penetración deben incluir Antes de activar las aplicaciones, dispositivos de red y sistemas para
lo siguiente: producción, es necesario asegurarlos utilizando las mejores prácticas de
11.3.1 Pruebas de penetración de capas de red seguridad (según el requisito 2.2). Los escanes de vulnerabilidad y las
11.3.2 Pruebas de penetración de capa de pruebas de penetración expondrán cualquier vulnerabilidad que quede y que
aplicación. los delincuentes luego podrían localizar y explotar.
11.4 (a) Usar sistemas de detección de intrusiones en Estas herramientas comparan el tráfico que entra en la red con “firmas”
la red, sistemas de detección de intrusiones conocidas de miles de tipos de compromisos de la seguridad (herramientas
basados en host y/o sistemas de prevención de que usan los delincuentes, troyanos, etc.) y envían alertas y/o bloquean el
intrusiones para monitorear todo el tráfico de la red intento al ocurrir el mismo. Sin un enfoque proactivo para detectar la actividad
y alertar al personal sobre cualquier sospecha de no autorizada mediante estas herramientas, los ataques contra los recursos
un compromiso de la seguridad. 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 Existen miles de formas de comprometer la seguridad, y cada día se
prevención de intrusiones al día. 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 sistemas que monitorean la integridad de los archivos detectan los
los archivos para alertar al personal sobre cualquier cambios en archivos críticos y notifican cuando se detectan esos cambios.
modificación no autorizada de un sistema o contenido Hay herramientas comerciales y de distintos proveedores disponibles para el
de un archivo crítico y realizar comparaciones de monitoreo de la integridad de los archivos. Si no se implementan estas
archivos críticos al menos semanalmente. herramientas y si no se monitorean los datos de salida, un delincuente o un
Los archivos críticos no son necesariamente aquellos usuario con intenciones maliciosas podría alterar el contenido de los archivos
que contienen datos de los tarjetahabientes. Para fines o robar datos sin ser detectado.
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).
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 La política de seguridad de la información de una compañía crea el plano y la
de seguridad que logre lo siguiente: base para implementar medidas de seguridad destinadas a proteger sus
12.1.1 Contemple todos los requisitos de esta activos más valiosos. Una política de alta seguridad establece el tono en el
especificación. á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
12.1.2 Incluya un proceso anual para identificar
confidencial de los datos y de sus responsabilidades para protegerlos.
amenazas y vulnerabilidades y que traiga
como resultado una evaluación formal de los Las amenazas de seguridad y los métodos de protección evolucionan
riesgos. 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
12.1.3 Incluya una revisión al menos una vez al año
estas amenazas no existirán.
y una actualización cuando el ambiente
cambie.
12.2 Desarrollar procedimientos diarios de seguridad Los procedimientos operativos diarios de seguridad sirven como “un manual
operativa que sean congruentes con los requisitos de instrucciones” que los empleados pueden usar en sus actividades diarias
establecidos en esta especificación (por ejemplo, de administración y mantenimiento de sistemas. Si los procedimientos
procedimientos de mantenimiento de cuentas, operativos de seguridad no están documentados, eso causará que los
procedimientos de revisión de registros y bitácoras). 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 Las políticas de uso por parte de los empleados pueden prohibir que los
utilizan los empleados (como módems y dispositivos mismos usen dichos dispositivos si esa es la política de la empresa, o
inalámbricos), a fin de definir el uso apropiado de estas proporcionar a los empleados Orientaciones para el uso e implementación
tecnologías por parte de todos los empleados y correctos. Si no hay una política de uso establecida, los empleados podrían
contratistas. Asegurar que estas políticas de uso usar los dispositivos violando la política de la empresa, podrían
requieran lo siguiente: 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 Los delincuentes podrían penetrar la seguridad física y colocar sus propios
que tiene acceso a ellos dispositivos en la red para que sirvan como una “puerta trasera”. Los
empleados también podrían obviar los procedimientos e instalar dispositivos.
12.3.4 Etiquetas en los dispositivos que indiquen su Un inventario exacto con etiquetas apropiadas para clasificar los dispositivos
dueño, información de contacto y propósito
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.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
12.3.6 Ubicaciones aceptables en la red para estas
controlar mejor las brechas en las configuraciones y controles operativos, a fin
tecnologías de asegurar que no se abra una “puerta trasera” para que un delincuente
12.3.7 Una lista de los productos aprobados por la obtenga acceso a los sistemas críticos y datos de los tarjetahabientes.
empresa
12.3.8 Desconexión automática de las sesiones de Los módems son frecuentemente “puertas traseras” para acceder a los
módem después de un período específico de recursos críticos y a los datos de los tarjetahabientes. Desconectar los
inactividad 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
12.3.9 Activación de módems por parte del otros proveedores), minimiza el acceso a las redes y el riesgo para las
proveedor solamente cuando sea necesario, mismas. Considere usar controles de módem estándar para desconectar los
con desactivación inmediata después del uso
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.10 Al acceder a los datos de los tarjetahabientes Para asegurar que sus empleados estén conscientes de sus
en forma remota por módem, prohibir el responsabilidades de no guardar o copiar los datos de los tarjetahabientes en
almacenaje de dichos datos en discos duros sus computadores personales y otros medios, la compañía debe contar con
locales, disquetes y otros medios externos. una política que claramente prohíba esas actividades.
Prohibición de las funciones que permiten
cortar y pegar e imprimir datos durante el
acceso remoto.
12.4 Garantizar que la política y los procedimientos de Si los roles con respecto a la seguridad no están claramente definidos y las
seguridad definan claramente las responsabilidades de responsabilidades no están claramente asignadas, es posible que la
seguridad de la información en el caso de todos los interacción con el grupo de seguridad no sea constante, lo cual conduciría a
empleados y contratistas. 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 Cada persona o equipo que tenga responsabilidades relacionadas con la
responsabilidades de administración de seguridad de administración de la seguridad de la información debe estar consciente y
la información: entender claramente sus responsabilidades y las tareas relacionadas con las
12.5.1 Establecer, documentar y distribuir las mismas, por medio de una política específica. Sin esta posibilidad de asignar
políticas y los procedimientos de seguridad. responsabilidad concretamente a una persona o equipo podrían existir
brechas en los procesos, las cuales podrían abrir el acceso a los recursos
12.5.2 Monitorear y analizar los alertas y la
críticos o a los datos de los tarjetahabientes.
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.
12.6 Implementar un programa formal de información sobre Si no se educa a los usuarios acerca de sus responsabilidades en relación
la seguridad para que todos los empleados estén con la seguridad, las medidas de seguridad y los procesos que se han
conscientes de la importancia de la seguridad de los implementado podrían resultar ineficaces a causa de errores o actos
datos. intencionales de los empleados.
12.6.1 Educar a los empleados al contratarlos y al Si el programa para aumentar la conciencia sobre la seguridad no incluye
menos anualmente (por ejemplo, por medio sesiones anuales para refrescar los conocimientos, es posible que se olviden
de afiches, cartas, memorandos, reuniones y u obvien procesos y procedimientos clave de seguridad, lo cual expondría los
promociones). recursos críticos y los datos de los tarjetahabientes.
12.6.2 Requerir a los empleados que hagan constar Requerir la firma de un empleado ayuda a asegurar que el mismo haya leído y
por escrito que han leído y comprendido la comprendido las políticas y procedimientos de seguridad y se comprometa a
política y los procedimientos. cumplir con ellos.
12.7 Hacer una investigación de antecedentes de los Realizar una investigación exhaustiva de antecedentes en el caso de los
candidatos a empleo para minimizar el riesgo de empleados que tienen acceso a los datos de los tarjetahabientes reduce el
ataques procedentes de fuentes internas. riesgo de uso no autorizado de los números de cuenta por parte de personas
En el caso de los empleados que sólo tengan acceso a que tengan antecedentes cuestionables o penales. Se espera que la
un número de tarjeta en un momento dado para compañía tenga una política y un proceso para realizar la verificación de
facilitar una transacción, tales como los cajeros en las antecedentes, incluyendo su propio proceso de decisión sobre cuáles
tiendas, este requisito es solamente una resultados tendrán un impacto en la decisión de contratar o no al candidato a
recomendación. empleo (y cuál será ese impacto).
12.8 Si los datos de los tarjetahabientes se comparten con Si un comercio o proveedor de servicio comparte los datos de los
proveedores de servicio, requerir contractualmente lo tarjetahabientes que tiene con un proveedor de servicio, entonces el
siguiente: proveedor de servicio que recibe los datos de los tarjetahabientes debe firmar
12.8.1 Los proveedores de servicio deben adherirse un documento local que lo hace responsable de acatar las políticas de
a los requisitos de las Normas de Seguridad seguridad de datos de los tarjetahabientes y reconocer esta responsabilidad.
de Datos de la Industria de Tarjetas de Pago Esto ayuda a garantizar que las entidades externas cumplirán con las medidas
(PCI). para la continua protección de los datos.
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.
12.9 Implementar un plan de respuesta en caso de Si no se cuenta con un plan detallado y completo para responder a los
incidente. Estar preparado para responder incidentes de seguridad que haya sido correctamente diseminado, leído y
inmediatamente a una violación del sistema. entendido por todos los responsables, la posible confusión y falta de una
12.9.1 (a) Crear un plan de respuesta a incidentes, respuesta unificada puede traer como resultado más tiempo inoperativo para
el cual se usará en caso de un el negocio, una exposición innecesaria a los medios públicos, y nuevas
compromiso de la seguridad del sistema. obligaciones legales.
(b) Asegurar que el plan contemple, como El plan para responder a un incidente de seguridad debe contener todos los
mínimo, procedimientos específicos de elementos clave para que la compañía pueda reaccionar en forma eficaz en
respuesta a incidentes, recuperación caso de una violación de seguridad que afecte los datos de los
comercial y reanudación de actividades tarjetahabientes.
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).
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 Si no se cuenta con un equipo de respuesta a incidentes bien capacitado e
que estén disponibles 24 horas al día los 7 inmediatamente disponible, es posible que la red sufra más daño y que los
días de la semana para responder a los datos y sistemas críticos se vean “contaminados” por un manejo incorrecto de
alertas. los sistemas afectados. Esto podría obstaculizar el éxito de una investigación
posterior al incidente. Si no hay recursos internos disponibles, considere
12.9.4 Proporcionar capacitación apropiada al contratar con un proveedor que brinde estos servicios.
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 Estos sistemas de monitoreo están diseñados para concentrarse en el posible
intrusiones, prevención de intrusiones y riesgo para los datos y son críticos para implementar acciones rápidas y
monitoreo de la integridad de los archivos. 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 Incorporar las “lecciones aprendidas” al plan de respuesta a incidentes
mejorar el plan de respuesta a incidentes después de un incidente ayuda a mantener el plan actualizado y en capacidad
según las lecciones aprendidas de la de reaccionar a las tendencias de seguridad.
experiencia e incorporar los desarrollos en la
industria.
12.10 Todos los procesadores y proveedores de servicio Una “entidad conectada” es una entidad "upstream" que está conectada a un
deben mantener e implementar políticas y procesador o proveedor de servicio para fines de recibir datos de los
procedimientos para la gestión de las entidades tarjetahabientes, incluyendo procesadores, agentes, organizaciones de venta
conectadas, los cuales incluirán lo siguiente: 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 Se debe mantener una lista de inventario de las entidades conectadas para
conectadas. 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 La política debe incluir un proceso de debida diligencia, de acuerdo con la
conectar a una entidad. debida diligencia que considere necesaria la compañía.
12.10.3. Asegurarse de que la entidad cumple con La intención de este requisito se cumple si la compañía tiene un contrato con
las Normas de Seguridad de Datos de la la entidad conectada, según el 12.8.1 anterior.
Industria de Tarjetas de Pago.
12.10.4. Conectar y desconectar a las entidades La política debe incluir una lista de verificación de los pasos que deben ocurrir
siguiendo un proceso establecido. 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:
A.1 Proteger el ambiente y los datos hospedados de cada El Apéndice A de las Normas de Seguridad de Datos de la Industria de
entidad (es decir, del comercio, del proveedor de Tarjetas de Pago está dirigido a los proveedores de servicios de hospedaje
servicio o de otra entidad) según se indica en los Web que desean proporcionar a sus comercios y/o proveedores de servicio
puntos A.1.1 a A.1.4: 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 Si se permite a un comercio o proveedor de servicio ejecutar sus propias
únicamente a su propio ambiente de datos de aplicaciones en el servidor compartido, las mismas deben ejecutarse con el ID
tarjetahabientes. 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 Para garantizar que el acceso y los privilegios estén restringidos de forma que
entidad solamente a su propio ambiente de cada comercio o proveedor de servicio tenga acceso solamente a su propio
datos de tarjetahabientes. 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 Las bitácoras deben estar disponibles en un ambiente de hospedaje
de auditoría y que sean únicas para el compartido para que los comercios y proveedores de servicio tengan acceso a
ambiente de datos de tarjetahabientes de las bitácoras específicas de su ambiente de datos de tarjetahabientes y
cada entidad y cumplan con el Requisito 10 puedan revisar las mismas.
de las Normas de Seguridad de Datos de la
Industria de Tarjetas de Pago.
A.1.4 Habilitar procesos que aseguren la Los proveedores de servicios de hospedaje Web deben habilitar un proceso
investigación forense oportuna en caso de un para proporcionar una respuesta rápida y fácil en caso de ser necesaria una
compromiso de la seguridad de cualquier investigación forense con motivo de un compromiso de la seguridad, hasta el
comercio hospedado o proveedor de nivel de detalle apropiado, de forma que todos los detalles sobre cada
servicios. 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 Todos los comercios y proveedores de servicio
Normas de Seguridad de Datos de la Industria de Tarjetas de Pago
Navigating PCI DSS: Understanding the Intent of the Requirements Todos los comercios y proveedores de servicio
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 Todos los comercios y proveedores de servicio
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 Comercios1
Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Cuestionario de
Autoevaluación A y Confirmación de Cumplimiento
PCI Data Security Standard: Self-Assessment Questionnaire B and Attestation Comercios1
Autoevaluación B y Confirmación de Cumplimiento
PCI Data Security Standard: Self-Assessment Questionnaire C and Attestation Comercios1
Autoevaluación C y Confirmación de Cumplimiento
PCI Data Security Standard: Self-Assessment Questionnaire D and Attestation Proveedores de servicio y todos los demás
Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Cuestionario de comercios9
Autoevaluación D y Confirmación de Cumplimiento
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 Todos los comercios y proveedores de servicio
Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Glosario, Abreviaturas
y Acrónimos

Spanish Navigating Pci Dss v1-1 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Spanish Navigating Pci Dss v1-1 PDF

Cargado por

Copyright:

Formatos disponibles

Industria de Tarjetas de Pago (PCI)

Normas de Seguridad de Datos

Entendiendo la Intención de los Requisitos

Datos de Tarjetahabientes y Elementos de Datos Confidenciales de Autenticación .................................................. iii

Proteger los Datos de los Tarjetahabientes

Mantener un Programa de Manejo de Vulnerabilidad

Implementar Medidas Sólidas de Control de Acceso

Monitorear y Probar Regularmente las Redes

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

Requisito 3: Proteger los datos de los tarjetahabientes que están almacenados.

Requisito 5: Usar y actualizar regularmente el software o programas antivirus.

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

9.7 Mantener un control estricto de la distribución interna y

También podría gustarte