Pci Dss Saq Navigating Dss PDF

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

Exploracin de PCI DSS
Modificaciones realizadas a los documentos
Fecha Versin Descripcin

1. de octubre de Alinear el contenido con las nuevas PCI DSS versin 1.2 e implementar cambios menores observados desde la
1.2
2008 versin 1.1. original.
Exploracin de PCI DSS: Comprensin del objetivo de los requisitos; versin 1.2 Octubre de 2008
Copyright 2008 PCI Security Standards Council LLC Pgina i
ndice
Modificaciones realizadas a los documentos ....................................................................................................................i

Prefacio ............................................................................................................................................................................... iii
Elementos de los datos del titular de la tarjeta y de los datos confidenciales de autenticacin ................................1
Ubicacin de los datos de los titulares de tarjetas y de los datos confidenciales de autenticacin ....................................................................... 2
Datos de la pista 1 y pista 2 .................................................................................................................................................................................... 3
Gua relacionada para las Normas de Seguridad de Datos de la PCI ............................................................................. 4
Gua para los requisitos 1 y 2: Desarrollar y mantener una red segura ..................................................................................... 5
Requisito 1: Instale y mantenga una configuracin de firewall para proteger los datos de los titulares de las tarjetas ......................................... 5
Requisito 2: No utilice los valores predeterminados que ofrece el proveedor para las contraseas del sistema u otros parmetros de
seguridad. ........................................................................................................................................................................................... 10
Gua para los requisitos 3 y 4: Proteja los datos del titular de la tarjeta .................................................................................. 13
Requisito 3: Proteja los datos del titular de la tarjeta que fueron almacenados ................................................................................................... 13
Requisito 4: Codifique la transmisin de los datos de los titulares de tarjetas a travs de redes pblicas abiertas. ........................................... 19
Gua para los requisitos 5 y 6: Desarrolle un programa de administracin de vulnerabilidad ............................................... 21
Requisito 5: Utilice y actualice regularmente el software o los programas antivirus ............................................................................................ 21
Requisito 6: Desarrolle y mantenga sistemas y aplicaciones seguras ................................................................................................................. 23
Gua para los requisitos 7, 8 y 9: Implemente medidas slidas de control de acceso ........................................................... 30
Requisito 7: Restrinja el acceso a datos de titulares de tarjetas slo a la necesidad de conocimiento de la empresa. ...................................... 30
Requisito 8: Asigne una ID nica a cada persona que tenga acceso a computadoras ........................................................................................ 31
Requisito 9: Limite el acceso fsico a los datos del titular de la tarjeta ................................................................................................................. 35
Gua para los requisitos 10 y 11: Supervise y pruebe las redes con regularidad ................................................................... 39
Requisito 10: Rastree y supervise los accesos a los recursos de red y a los datos de los titulares de las tarjetas ............................................. 39
Requisito 11: Pruebe los sistemas y procesos de seguridad regularmente ......................................................................................................... 42
Gua para el requisito 12: Mantenga una poltica de seguridad de informacin ..................................................................... 44
Requisito 12: Mantenga una poltica que aborde la seguridad de la informacin para empleados y contratistas. .............................................. 44
Gua para el requisito A.1: Requisitos de las PCI DSS adicionales para proveedores de hosting compartido .................... 50
Anexo A: Normas de seguridad de datos de la PCI: documentos relacionados ....................................................... 52
Copyright 2008 PCI Security Standards Council LLC Pgina ii
Prefacio
Este documento describe los 12 requisitos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS), junto con
orientacin para explicar el propsito de cada requisito. Este documento pretende ayudar a comerciantes, proveedores de servicios e instituciones
financieras que quiz deseen comprender las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago, y el significado especfico y la
intencin detrs de los requisitos detallados para asegurar los componentes del sistema (servidores, redes, aplicaciones, etc.) que admiten entornos
de datos de los titulares de las tarjetas.
NOTA: Exploracin de PCI DSS: La comprensin del objetivo de los requisitos es slo orientativa. Cuando se realiza un Cuestionario de
Autoevaluacin (SAQ) o una evaluacin in situ de las PCI DSS, los requisitos de las PCI DSS y procedimientos para la evaluacin de la
seguridad y los Cuestionarios de Autoevaluacin de las PCI DSS, versin 1.2, son los documentos de registro.
Los requisitos de las PCI DSS se aplican a todos los componentes del sistema que se incluyen en el entorno de los datos del titular de la tarjeta o
que estn relacionados con ste. El entorno de los datos del titular de la tarjeta es la parte de la red que posee los datos del titular de la tarjeta o
los datos confidenciales de autenticacin, incluidos los componentes de la red, los servidores y las aplicaciones.
Los componentes de la red incluyen, a modo de ejemplo, firewalls, interruptores, routers, puntos de acceso inalmbricos, dispositivos
de red y otros dispositivos de seguridad.
Los tipos de servidores incluyen, a modo de ejemplo: web, base de datos, autenticacin, correo electrnico, proxy, protocolo de
tiempo de red (NTP) y servidor de nombre de dominio (DNS).
Las aplicaciones incluyen todas las aplicaciones compradas y personalizadas, incluidas las aplicaciones internas y externas (Internet).
La adecuada segmentacin de red, que asla los sistemas que almacenan, procesan o transmiten datos del titular de la tarjeta de los que no lo
hacen, puede reducir el alcance del entorno de los datos del titular. Un Asesor de Seguridad Certificado (QSA) puede ayudar a determinar el
alcance dentro del entorno de los datos del titular de una entidad y brindar orientacin sobre cmo reducir el alcance de una evaluacin de las
PCI DSS mediante la implementacin de una segmentacin de red adecuada. Si las empresas tienen preguntas acerca de si una implementacin
especfica concuerda con la norma o si cumple con un requisito especfico, las PCI SSC recomiendan que consulten con un Asesor de
Seguridad Certificado (QSA) para validar su implementacin de tecnologa y procesos, y el cumplimiento de las Normas de Seguridad de Datos
de la Industria de Tarjetas de Pago. La experiencia del QSA en el trabajo con entornos de red complejos se presta bien para ofrecer las mejores
prcticas y orientacin para el comerciante o proveedor de servicios que intenta lograr el cumplimiento. Puede encontrar la lista de PCI SSC de
los Asesores de Seguridad Certificados en: https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf.
Copyright 2008 PCI Security Standards Council LLC Pgina iii
Elementos de los datos del titular de la tarjeta y de los datos confidenciales de
autenticacin
La siguiente tabla ilustra los elementos de los datos de titulares de tarjetas y de los datos confidenciales de autenticacin que habitualmente se
utilizan; independientemente de que est permitido o prohibido el almacenamiento de dichos datos o de que esos datos deban estar protegidos.
Esta tabla no intenta ser exhaustiva, sino que tiene como finalidad ilustrar distintos tipos de requisitos que se aplican a cada elemento de datos.
Los datos del titular de la tarjeta se definen como el nmero de cuenta principal (PAN, o nmero de tarjeta de crdito) y otros datos obtenidos
como parte de una transaccin de pago, incluidos los siguientes elementos de datos (para obtener informacin detallada vea debajo de la tabla).
PAN
Nombre del titular de la tarjeta
Fecha de vencimiento
Cdigo de servicio
Datos confidenciales de autenticacin: (1) todos los datos de banda magntica, (2) CAV2/CVC2/CVV2/CID, y (3) los PIN/los bloqueos de PIN)
El nmero de cuenta principal (PAN) es el factor que define la aplicabilidad de los requisitos de las PCI DSS y las PA-DSS. Si no se almacena,
procesa ni transmite el PAN, no se aplicarn las PCI DSS ni las PA-DSS.
Almacenamiento Proteccin
Elemento de datos permitido requerida PCI DSS req. 3, 4
Nmero de cuenta principal S S S
1 1
Datos del titular de Nombre del titular de la tarjeta S S No
la tarjeta Cdigo de servicio
1
S S
1
No
1 1
Fecha de vencimiento S S No
Datos completos de3la banda
Datos magntica No N/C N/C
confidenciales de
2 CAV2/CVC2/CVV2/CID No N/C N/C
autenticacin
PIN/Bloqueo de PIN No N/C N/C
1
Estos elementos de datos deben quedar protegidos si se los almacena con el PAN. Esta proteccin debe brindarse por cada requisito de las PCI DSS, a fin de asegurar una
proteccin integral del entorno del titular de la tarjeta. Adems, es posible que otras leyes (por ejemplo, las leyes relacionadas con la proteccin, la privacidad, el robo de identidad o la
seguridad de los datos personales del consumidor) exijan proteccin especfica de esos datos o la debida divulgacin de las prcticas de una empresa en caso de que se recopilen
datos personales sobre el consumidor durante el transcurso de los negocios. Sin embargo, las PCI DSS no se aplica si no se almacenan, procesan ni transmiten los PAN.
2
No se deben almacenar los datos confidenciales de autenticacin despus de la autorizacin (incluso si estn cifrados).
3
Contenido completo de la pista de banda magntica, imagen de la banda magntica que est en el chip o en cualquier otro dispo sitivo.
Copyright 2008 PCI Security Standards Council LLC Pgina 1
Ubicacin de los datos de los titulares de tarjetas y de los datos confidenciales de autenticacin
4 5
Los datos confidenciales de autenticacin constan de datos de banda (o pista) magntica, el cdigo de validacin de la tarjeta o valor y los datos de
6
PIN . Se prohbe el almacenamiento de datos confidenciales de autenticacin! Estos datos son muy valiosos para las personas malintencionadas
ya que les permiten generar tarjetas de pago falsas y crear transacciones fraudulentas. Consulte el Glosario de trminos, abreviaturas y acrnimos de
las PCI DSS y las PA-DSS para obtener la definicin completa de los datos confidenciales de autenticacin. Las imgenes del anverso y el reverso de
la siguiente tarjeta de crdito muestran la ubicacin del titular de la tarjeta y los datos confidenciales de autenticacin.
4
Datos codificados en la banda magntica que se utilizan para realizar la autorizacin durante una transaccin con tarjeta presente. Estos datos tambin pueden encontrarse en la
imagen de la banda magntica que est en el chip o en algn otro lugar de la tarjeta. Es posible que las entidades no retenga n todos los datos de banda magntica despus de la
autorizacin de la transaccin. Los nicos elementos de datos de pistas que se pueden retener son: el nmero de cuenta principa l, el nombre del titular de la tarjeta, la fecha de
vencimiento y el cdigo de servicio.
5
El valor de tres o cuatro dgitos impreso en el panel de firma, a la derecha del panel de firma o en el anverso de la tarjeta de pago que se utiliza para verificar l as transacciones con
tarjeta ausente (CNP).
6
El nmero de identificacin personal introducido por el titular de la tarjeta durante una transaccin con tarjeta presente y/o el bloqueo del PIN cifrado presente dentro del mensaje de
la transaccin.
Datos de la pista 1 y pista 2
Si se almacena el contenido completo (ya sea de la pista 1 o de la pista 2 de banda magntica, imagen de la banda magntica que est en un
chip o en cualquier otro dispositivo) las personas malintencionadas que obtienen datos pueden reproducir y vender tarjetas de pago en todo el
mundo. El almacenamiento del contenido completo de la pista viola la reglamentacin operativa de las marcas de pago y puede ocasionar multas
o sanciones. La siguiente imagen ofrece informacin sobre los datos de la pista 1 y de la pista 2, mediante la descripcin de las diferencias y la
exhibicin de la composicin de los datos como estn almacenados en la banda magntica.
Pista 1 Pista 2
Contiene todos los campos de la pista 1 y de la pista 2 Tiempo de procesamiento ms corto para las transmisiones por
Longitud de hasta 79 caracteres lnea telefnica ms antiguas.
Longitud de hasta 40 caracteres
Gua relacionada para las Normas de Seguridad de Datos de la PCI
Desarrollar y mantener una red segura
Requisito 1: Instale y mantenga una configuracin de firewall para proteger los datos de los titulares de las tarjetas
Requisito 2: No utilice los valores predeterminados que ofrece el proveedor para las contraseas del sistema u otros
parmetros de seguridad.
Proteja los datos del titular de la tarjeta
Requisito 3: Proteja los datos del titular de la tarjeta que fueron almacenados
Requisito 4: Codifique la transmisin de los datos de los titulares de tarjetas a travs de redes pblicas abiertas.
Desarrolle un programa de administracin de vulnerabilidad
Requisito 5: Utilice un software antivirus y actualcelo regularmente

Requisito 6: Desarrolle y mantenga sistemas y aplicaciones seguras
Implemente medidas slidas de control de acceso
Requisito 7: Restrinja el acceso a los datos de los titulares de las tarjetas conforme a la necesidad de conocer de la empresa
Requisito 8: Asigne una ID nica a cada persona que tenga acceso a computadoras
Requisito 9: Limite el acceso fsico a los datos del titular de la tarjeta
Supervise y pruebe las redes con regularidad
Requisito 10: Rastree y supervise los accesos a los recursos de red y a los datos de los titulares de las tarjetas
Requisito 11: Pruebe los sistemas y procesos de seguridad regularmente
Mantenga una poltica de seguridad de informacin
Requisito 12: Mantenga una poltica que aborde la seguridad de la informacin
Gua para los requisitos 1 y 2: Desarrollar y mantener una red segura
Requisito 1: Instale y mantenga una configuracin de firewall para proteger los datos de los titulares de las tarjetas
Los firewalls son dispositivos computarizados que controlan el trnsito permitido en la red de una empresa (interna) y de redes no confiables
(externas) as como el trnsito de entrada y salida a reas ms sensibles dentro de la red interna confidencial de la empresa. El entorno del titular
de la tarjeta es un ejemplo de un rea ms confidencial dentro de la red confiable de la empresa.
El firewall evala todo el trnsito de la red y bloquea las transmisiones que no cumplen con los criterios especificados de seguridad.
Es necesario proteger todos los sistemas contra el acceso no autorizado desde redes no confiables, ya sea que ingresen al sistema a travs de
Internet como comercio electrnico, del acceso a Internet desde las computadoras de mesa de los empleados, del acceso al correo electrnico
de los empleados, de conexiones dedicadas como conexiones de empresa a empresa mediante redes inalmbricas o a travs de otras fuentes.
Con frecuencia, algunas vas de conexin hacia y desde redes no confiables aparentemente insignificantes pueden proporcionar un acceso sin
proteccin a sistemas clave. Los firewalls son un mecanismo de proteccin esencial para cualquier red de computadoras.
Requisito Gua
1.1 Establezca las normas de configuracin del firewall y Los firewalls y los routers son componentes clave de la arquitectura que
del router que incluyen lo siguiente: controlan la entrada a la red y la salida de sta. Estos dispositivos son
dispositivos de software o hardware que bloquean el acceso no deseado y
administran el acceso autorizado de los elementos que entran y salen de la red.
Sin la implementacin de polticas y procedimientos para documentar cmo el
personal debe configurar los firewalls y los routers, una empresa puede perder
fcilmente su primera lnea de defensa en la proteccin de datos. Las polticas y
los procedimientos ayudarn a asegurar que la primera lnea de defensa de la
organizacin se mantenga fuerte en la proteccin de sus datos.
1.1.1 Un proceso formal para aprobar y evaluar Una poltica y un proceso para aprobar y evaluar todas las conexiones y los
todos los cambios y las conexiones de red en cambios que se realizan en los firewalls y en los routers ayudarn a prevenir
la configuracin de los firewalls y los routers los problemas de seguridad que causa una mal configuracin de la red, del
router o del firewall.
1.1.2 Un diagrama actualizado de la red con todas Los diagramas de red permiten a la organizacin identificar la ubicacin de
las conexiones que acceden a los datos de todos sus dispositivos de red. Adems, el diagrama de red se puede usar para
los titulares de las tarjetas, incluida toda red trazar el flujo de datos de los datos del titular de la tarjeta en la red y entre los
inalmbrica dispositivos individuales para comprender plenamente el alcance del entorno
del titular de la tarjeta. Sin diagramas de red y de flujos de datos actualizados,
los dispositivos con datos del titular de la tarjeta pueden pasarse por alto e,
inconcientemente, pueden dejarse afuera de los controles de seguridad en
capas que se implementan para las PCI DSS y, por ende, tornarse
vulnerables al peligro.
Requisito Gua
1.1.3 Requisitos para tener un firewall en cada El uso de un firewall en todas las conexiones que ingresan a la red (y las que
conexin a Internet y entre cualquier zona salen) permite a la organizacin supervisar y controlar todo lo que entra y sale
desmilitarizada (DMZ) y la zona de la red y minimizar las posibilidades de que personas malintencionadas logren
obtener acceso a la red interna.
interna
1.1.4 Descripcin de grupos, de papeles y de Esta descripcin de funciones y asignacin de responsabilidades garantiza que
responsabilidades para una administracin alguien sea responsable de la seguridad de todos los componentes y que sea
lgica de los componentes de la red consciente de su responsabilidad, y que ningn dispositivo quede sin administrar.
1.1.5 Razn documentada y comercial para la Generalmente, los riesgos existen debido a servicios o puertos inseguros o que
utilizacin de todos los servicios, los no se usan, ya que stos generalmente tienen vulnerabilidades conocidas, y
protocolos y los puertos permitidos, incluida la muchas organizaciones son vulnerables a estos tipos de riesgos porque no
corrigen provisionalmente la vulnerabilidad de seguridad de los servicios,
documentacin de funciones de seguridad protocolos y puertos que no usan (aunque las vulnerabilidades an estn
implementadas en aquellos protocolos que se presentes). Cada organizacin debe decidir de manera clara qu servicios,
consideran inseguros protocolos y puertos son necesarios para su empresa, documentarlos para sus
registros y asegurarse de que todos los otros servicios, protocolos y puertos
estn desactivados o se hayan eliminado. Adems, las organizaciones deben
considerar el bloqueo de todo el trnsito y slo volver a abrir esos puertos una
vez que se ha determinado y documentado una necesidad.
Asimismo, existen muchos servicios, protocolos y puertos que una empresa
puede necesitar (o ha activado de manera predeterminada) y que
generalmente son usados por personas malintencionadas para poner en
riesgo una red. Si estos servicios, protocolos y puertos inseguros son
necesarios para la empresa, la organizacin debe comprender y aceptar el
riesgo que ocasiona el uso de estos protocolos, se debe justificar el uso del
protocolo y se deben documentar e implementar las funciones de seguridad
que permiten que estos protocolos se usen de manera segura. Si estos
servicios, protocolos y puertos inseguros no son necesarios para la empresa,
deben desactivarse o eliminarse.
1.1.6 Requisitos de la revisin de las normas del Esta revisin le da una oportunidad a la organizacin, al menos cada seis
firewall y del router, al menos, cada seis meses, para limpiar toda norma innecesaria, obsoleta o incorrecta, y asegura
meses que todas las normas permitan slo servicios autorizados y puertos que se
ajusten a razones comerciales.
Se recomienda realizar estas revisiones con ms frecuencia, por ejemplo,
mensualmente, para garantizar que las normas estn actualizadas y satisfagan
las necesidades de la empresa sin abrir los agujeros de seguridad y correr
riesgos innecesarios.
Requisito Gua
1.2 Desarrolle una configuracin de firewall que restrinja Es esencial instalar proteccin de red, como un firewall, entre la red interna
las conexiones entre redes no confiables y todo confiable y cualquier otra red no confiable externa o que excede la capacidad de
componente del sistema en el entorno de los datos del control o administracin de la entidad. Si no se implementa esta medida de
manera correcta significa que la entidad ser vulnerable al acceso no autorizado
titular de la tarjeta. de personas malintencionadas y software malicioso.
Nota: Una red no confiable" es toda red que es externa a las Si se instala un firewall pero no hay normas que controlen o limiten cierto
redes que pertenecen a la entidad en evaluacin y que trnsito, las personas malintencionadas an pueden explotar los puertos y
excede la capacidad de control o administracin de la entidad. protocolos vulnerables para atacar su red.
1.2.1 Restrinja el trnsito entrante y saliente a la cantidad Este requisito tiene como objetivo impedir que personas malintencionadas
que sea necesaria en el entorno de datos del titular tengan acceso a la red de la organizacin a travs de direcciones IP no
de la tarjeta. autorizadas o a travs del uso de servicios, protocolos o puertos de manera
no autorizada (por ejemplo, para enviar a un servidor no confiable datos que
han obtenido de su red).
Todos los firewalls deben incluir una norma que niegue todo trnsito entrante
y saliente que no sea especficamente necesario. Esto impide que haya
agujeros inadvertidos que pueden permitir otro trnsito entrante o saliente
accidental y potencialmente peligroso.
1.2.2 Asegure y sincronice los archivos de configuracin de Si bien los archivos de configuracin en ejecucin generalmente se
routers. implementan con una configuracin segura, es posible que los archivos de
arranque (los routers slo ejecutan estos archivos al reiniciarse) no se
implementen con la misma configuracin de seguridad porque slo se
ejecutan ocasionalmente. Cuando un router se reinicia sin la misma
configuracin segura que las de los archivos de configuracin en ejecucin, es
posible que se produzcan normas ms dbiles que permitan que personas
malintencionadas ingresen en la red, ya que es posible que los archivos de
arranque no se hayan implementado con la misma configuracin segura que
los archivos de configuracin en ejecucin.
1.2.3 Instale firewalls de permetro entre las redes La implementacin y explotacin conocida (o desconocida) de tecnologa
inalmbricas y el entorno de datos del titular de la inalmbrica dentro de una red es una va comn para que las personas
tarjeta y configure estos firewalls para negar todo malintencionadas obtengan acceso a la red y a los datos del titular de la
tarjeta. Si se instala una red o un dispositivo inalmbrico sin que la empresa
trnsito desde el entorno inalmbrico o para controlar sepa, una persona malintencionada puede fcilmente e inevitablemente
(en caso de que ese trnsito fuera necesario para ingresar a la red. Si los firewalls no restringen el acceso desde redes
fines comerciales). inalmbricas hacia el entorno de la tarjeta de pago, las personas
malintencionadas que obtienen acceso no autorizado a la red inalmbrica
pueden conectarse fcilmente con el entorno de la tarjeta de pago y poner en
riesgo la informacin de la cuenta.
Requisito Gua
1.3 Prohba el acceso directo pblico entre Internet y todo El propsito de un firewall es administrar y controlar todas las conexiones que
componente del sistema en el entorno de datos de los hay entre sistemas pblicos y sistemas internos (especialmente los que
titulares de tarjetas. almacenan datos de titulares de tarjetas). Si se permite el acceso directo entre
sistemas pblicos y los que almacenan datos de titulares de tarjetas, se omite
la proteccin que ofrece el firewall y los componentes del sistema que
almacenan datos de titulares de tarjetas pueden estar en peligro.
1.3.1 Implemente un DMZ para limitar el trnsito entrante y Estos requisitos tienen como objetivo impedir que personas malintencionadas
saliente a los protocolos que sean necesarios en el tengan acceso a la red de la organizacin a travs de direcciones IP no
entorno de datos del titular de la tarjeta. autorizadas o a travs del uso de servicios, protocolos o puertos de manera
no autorizada (por ejemplo, para enviar a un servidor externo no confiable de
1.3.2 Restrinja el trnsito entrante de Internet a las una red no confiable datos que han obtenido de su red).
direcciones IP dentro del DMZ.
1.3.3 No permita ninguna ruta directa de entrada o salida El DMZ es la parte del firewall que hace frente a la Internet pblica y
de trnsito entre Internet y el entorno del titular de la administra las conexiones entre Internet y los servicios internos que una
tarjeta. organizacin necesita tener disponibles para el pblico (como un servidor
web). Es la primera lnea de defensa que asla y separa el trnsito que
necesita para comunicarse con la red interna del trfico que no necesita
comunicarse con la red interna.
1.3.4 No permita que las direcciones internas pasen desde Normalmente, un paquete contiene la direccin IP de la computadora que lo
Internet al DMZ. envi originalmente. Esto les permite a otras computadoras de la red saber de
dnde viene ese paquete. En ciertos casos, personas malintencionadas
falsificarn esta direccin IP.
Por ejemplo, personas malintencionadas envan un paquete con una direccin
falsa, de manera que (a menos que su firewall lo prohba) el paquete ingresa a
la red desde Internet, como trnsito interno y, por ende, legtimo. Una vez que
las personas malintencionadas estn dentro de la red, pueden poner en
peligro sus sistemas.
El filtrado de ingreso es una tcnica que puede usar en su firewall para filtrar
paquetes que ingresan en su red para, entre otras cosas, asegurarse de que
los paquetes no se falsifiquen a fin de que parezca que provienen de su
propia red interna.
Si necesita ms informacin sobre el filtrado de paquetes, puede obtener
informacin sobre una tcnica de consecuencia natural denominada filtrado
de salida.
1.3.5 Restrinja el trnsito saliente del entorno de datos del El DMZ tambin debe evaluar todo el trnsito saliente desde el interior de la
titular de la tarjeta a Internet de forma tal que el red para asegurar que todo el trnsito saliente siga las normas establecidas.
trnsito saliente slo pueda acceder a direcciones IP Para que el DMZ realice esta funcin con eficacia, no se deben permitir
conexiones desde el interior de la red hacia cualquier direccin fuera de la red,
dentro del DMZ. a menos que antes pasen por el DMZ y este evale su legitimidad.
Requisito Gua
1.3.6 Implemente la inspeccin completa, tambin conocida Un firewall que realiza una inspeccin meticulosa de paquetes mantiene el
como filtrado dinmico de paquetes. (Es decir, slo estado (o el estatus) de todas las conexiones del firewall. Al mantener el
se permite la entrada a la red de conexiones estado, el firewall sabe si lo que parece ser una respuesta a una conexin
establecidas). anterior es verdaderamente una respuesta (ya que "recuerda" la conexin
anterior) o es un software malicioso o una persona malintencionada que
intenta burlar o engaar el firewall para que permita la conexin.
1.3.7 Coloque la base de datos en una zona de red Los datos del titular de la tarjeta requieren el mayor nivel de proteccin de la
interna, segregada del DMZ. informacin. Si se ubican datos del titular de la tarjeta dentro del DMZ, el
acceso a esta informacin es ms simple para un atacante externo, ya que
hay menos capas para penetrar.
1.3.8 Implemente la simulacin IP a los efectos de evitar La simulacin IP, que administra el firewall, permite a una organizacin tener
que las direcciones internas se traduzcan y se direcciones internas que son slo visibles dentro de la red y direcciones
divulguen en Internet mediante la utilizacin del externas que son visibles fuera de la red. Si un firewall no esconde u oculta
espacio de direccin RFC 1918. Utilice tecnologas las direcciones IP de la red interna, una persona malintencionada puede
de traduccin de direccin de red (NAT), por descubrir direcciones IP internas e intentar acceder a la red con una direccin
ejemplo, traduccin de direccin de puertos (PAT). IP falsa.
1.4 Instale software de firewall personal en toda Si una computadora no tiene un firewall o un programa antivirus instalado, se
computadora mvil o de propiedad de los trabajadores pueden descargar spyware, troyanos, virus, gusanos y rootkit (malware) o
con conectividad directa a Internet (por ejemplo, laptops instalarse sin saberlo. La computadora es an ms vulnerable cuando est
que usan los trabajadores), mediante las cuales se directamente conectada a Internet y no detrs del firewall de la empresa. El
accede a la red de la organizacin. malware cargado en una computadora que no est protegida por el firewall de
la empresa puede dirigirse maliciosamente a la informacin que hay en la red
cuando la computadora se vuelve a conectar a la red corporativa.
Requisito 2: No utilice los valores predeterminados que ofrece el proveedor para las contraseas del sistema u otros
parmetros de seguridad.
Los delincuentes (externos e internos a la empresa), por lo general, utilizan las contraseas predeterminadas por los proveedores y otros
parmetros que el proveedor predetermine para afectar los sistemas. Estas contraseas y parmetros son conocidos entre las comunidades de
hackers y se establecen fcilmente por medio de informacin pblica.
Requisito Gua
2.1 Siempre cambie los valores predeterminados de los Los delincuentes (externos e internos a la empresa), por lo general, utilizan las
proveedores antes de instalar un sistema en la red contraseas, los nombres de cuenta y los valores de configuracin
(por ejemplo, incluya contraseas, cadenas predeterminados por los proveedores para afectar los sistemas. Las
comunitarias de protocolo simple de administracin de comunidades de hackers conocen bien estos valores de configuracin y hacen
red [SNMP] y elimine cuentas innecesarias). que su sistema sea muy vulnerable a un ataque.
2.1.1 En el caso de entornos inalmbricos que Muchos usuarios instalan estos dispositivos sin la aprobacin de la gerencia y
estn conectados al entorno de datos del no cambian los valores de configuracin predeterminados ni establecen la
titular de la tarjeta o que transfieren datos del configuracin de seguridad. Si las redes inalmbricas no se implementan con
titular de la tarjeta, cambie los valores suficientes configuraciones de seguridad (incluido el cambio de los valores de
predeterminados proporcionados por los configuracin predeterminados), los analizadores inalmbricos de protocolos
proveedores, incluidas, a modo de ejemplo, pueden espiar el trnsito, capturar datos y contraseas de manera sencilla e
claves de criptografa inalmbricas ingresar fcilmente en su red y atacarla. Adems, se ha roto el protocolo de
predeterminadas, contraseas y cadenas intercambio clave para la versin anterior de cifrado 802.11x (WEP) y puede
comunitarias SNMP. Asegrese de que la hacer que el cifrado sea intil. Verifique que el firmware de los dispositivos
configuracin de seguridad de los dispositivos est actualizado para admitir protocolos ms seguros, como WPA/WPA2.
inalmbricos est habilitada para la tecnologa
de cifrado de la autenticacin y transmisin.
Requisito Gua
2.2 Desarrolle normas de configuracin para todos los Existen debilidades conocidas en muchos sistemas operativos, bases de
componentes de sistemas. Asegrese de que estas datos y aplicaciones de empresas, y tambin existen formas conocidas de
normas contemplen todas las vulnerabilidades de configurar estos sistemas para arreglar las vulnerabilidades de seguridad.
seguridad conocidas y que concuerden con las normas Para ayudar a quienes no son expertos en seguridad, las organizaciones de
de alta seguridad de sistema aceptadas en la industria. seguridad han establecido recomendaciones de alta seguridad de sistema,
que aconsejan cmo corregir estas debilidades. Si no se eliminan estas
debilidades de los sistemas, como una configuracin de archivo dbil o
servicios y protocolos predeterminados (para los servicios o protocolos que
generalmente no son necesarios), un atacante puede usar distintos puntos
vulnerables conocidos para atacar servicios y protocolos vulnerables y, as,
obtener acceso a la red de la organizacin. Puede visitar estos tres sitios web
de ejemplo, en los que podr obtener ms informacin sobre las mejores
prcticas de la industria que pueden ayudarlo a implementar normas de
configuracin: www.nist.gov, www.sans.org, www.cisecurity.org.
2.2.1 Implemente solamente una funcin principal Esto tiene como objetivo garantizar que las normas de configuracin de los
por cada servidor. sistemas y los procesos relacionados de una empresa tratan las funciones de
los servidores que necesitan tener distintos niveles de seguridad o que
pueden introducir debilidades de seguridad en otras funciones del mismo
servidor. Por ejemplo:
1. Una base de datos, que requiere fuertes medidas de seguridad, estara en
riesgo si compartiera un servidor con una aplicacin web, que necesita
estar abierta y enfrenarse directamente con Internet.
2. Si no se aplica un parche a una funcin aparentemente menor se puede
correr un riesgo que puede repercutir en otras funciones ms importantes
(como la base de datos) del mismo servidor.
Este requisito es para servidores (generalmente Unix, Linux o Windows), pero
no para sistemas mainframe.
2.2.2 Deshabilite todos los servicios y protocolos Como se mencion en 1.1.7, existen muchos protocolos que una empresa
innecesarios e inseguros (servicios y puede necesitar (o ha activado de manera predeterminada) y que
protocolos que no sean directamente generalmente son usados por personas malintencionadas para poner en
necesarios para desempear la funcin riesgo una red. Para garantizar que estos servicios y protocolos estn siempre
especificada de los dispositivos). desactivados cuando se implementan nuevos servidores, este requisito debe
ser parte de las normas de configuracin y los procesos relacionados de su
empresa.
Requisito Gua
2.2.3 Configure los parmetros de seguridad del Esto pretende garantizar que las normas de configuracin de los sistemas y
sistema para evitar el uso indebido. los procesos relacionados de su empresa traten especficamente los
parmetros y la configuracin de seguridad que han conocido implicaciones
de seguridad.
2.2.4 Elimine todas las funcionalidades innecesarias, Las normas de alta seguridad de servidor deben incluir procesos para abordar
tales como secuencias de comandos, las funcionalidades innecesarias con implicaciones de seguridad especficas
controladores, funciones, subsistemas, (como eliminar/desactivar el FTP o el servidor web si el servidor no ejecutar
sistemas de archivos y servidores web esas funciones).
innecesarios.
2.3 Cifre el acceso administrativo que no sea de consola. Si la administracin remota no se realiza con autenticacin segura y
Utilice tecnologas como SSH, VPN o SSL/TLS para la comunicaciones cifradas, la informacin confidencial de nivel operativo o
administracin basada en la web y otros tipos de administrativo (como las contraseas de los administradores) puede revelarse
acceso administrativo que no sea de consola. a un espa. Una persona malintencionada puede usar esta informacin para
acceder a la red, convertirse en administrador y robar datos.
2.4 Los proveedores de servicio de hosting deben proteger Este punto est pensado para los proveedores de hosting que ofrecen
el entorno hosting y los datos del titular de la tarjeta. entornos de servicio de hosting compartido para varios clientes en el mismo
Estos proveedores deben cumplir requisitos servidor. En general, cuando todos los datos estn en el mismo servidor, bajo
especficos detallados en el Anexo A: Requisitos de el control de un solo entorno, los clientes individuales no pueden controlar la
las PCI DSS adicionales para proveedores de hosting configuracin de estos servidores, pero se les permite agregar secuencias y
compartido. funciones inseguras que afectan la seguridad de los entornos de los otros
clientes y, por ende, hacen que sea ms fcil para las personas
malintencionadas poner en riesgo los datos de un cliente y, as, obtener
acceso a todos los otros datos de los clientes. Consulte el Anexo A.
Gua para los requisitos 3 y 4: Proteja los datos del titular de la tarjeta
Requisito 3: Proteja los datos del titular de la tarjeta que fueron almacenados
Las medidas de proteccin como el cifrado, el truncamiento, el ocultamiento y la refundicin son importantes componentes de la proteccin de
datos del titular de la tarjeta. Si un intruso viola otros controles de seguridad de red y obtiene acceso a los datos cifrados, sin las claves
criptogrficas adecuadas no podr leer ni utilizar esos datos. Los otros mtodos eficaces para proteger los datos almacenados deberan
considerarse oportunidades para mitigar el riesgo posible. Por ejemplo, los mtodos para minimizar el riesgo incluyen no almacenar datos de los
titulares de la tarjeta salvo que sea absolutamente necesario, truncar los datos de los titulares de la tarjeta si no se necesita el PAN completo y no
enviar el PAN en correos electrnicos no cifrados.
Consulte el Glosario de trminos, abreviaturas y acrnimos de las PCI DSS y las PA-DSS para obtener definiciones de "criptografa slida" y
otros trminos de las DSS de la PCI.
Requisito Gua
3.1 Almacene la menor cantidad de datos posibles del El almacenamiento de gran extensin de datos de los titulares de las tarjetas
titular de la tarjeta. Desarrolle una poltica de retencin que excede la necesidad de la empresa crea un riesgo innecesario. Los
y de disposicin de datos. Reduzca la cantidad de nicos datos de los titulares de las tarjetas que pueden almacenarse son el
datos almacenados y el tiempo de retencin a los que nmero de cuenta principal o PAN (ilegible), la fecha de vencimiento, el
sean necesarios para fines comerciales, legales o nombre y el cdigo de servicio. Recuerde: si no lo necesita, no lo
reglamentarios, segn se documente en la poltica de almacene!
retencin de datos.
7
3.2 No almacene datos confidenciales de autenticacin Los datos confidenciales de autenticacin constan de datos 8de banda (o
despus de recibir la autorizacin (aun cuando estn pista)
9
magntica, el cdigo de validacin de la tarjeta o valor y los datos de
cifrados). PIN . Se prohbe el almacenamiento de datos confidenciales de
Los datos confidenciales de autenticacin incluyen los autenticacin despus de recibir la autorizacin! Estos datos son muy
datos mencionados en los requisitos 3.2.1 a 3.2.3 valiosos para las personas malintencionadas ya que les permiten generar
establecidos a continuacin. tarjetas de pago falsas y crear transacciones fraudulentas. Consulte el
Glosario de trminos, abreviaturas y acrnimos de las PCI DSS y las PA-DSS
para obtener la definicin completa de los datos confidenciales de
autenticacin.
7
Datos codificados en la banda magntica que se utilizan para realizar la autorizacin durante una transaccin con tarjeta presente. Estos datos tambin pueden encontrarse en la
imagen de la banda magntica que est en el chip o en algn otro lugar de la tarjeta. Es posible que las entidades no retenga n todos los datos de banda magntica despus de la
autorizacin de la transaccin. Los nicos elementos de datos de pistas que se pueden retener son: el nmero de cuenta principal, el nombre del titular de la tar jeta, la fecha de
vencimiento y el cdigo de servicio.
8
El valor de tres o cuatro dgitos impreso en el panel de firma, a la derecha del panel de firma o en el anverso de la tarjeta de pago que se utiliza para verificar las transacciones con
tarjeta ausente (CNP).
9
El nmero de identificacin personal introducido por el titular de la tarjeta durante una transaccin con tarjeta presente y/o el bloqueo del PIN cifrado presente dentro del mensaje de
la transaccin.
Requisito Gua
No almacene contenidos completos de Si se almacena el contenido completo, las personas malintencionadas que
ninguna pista de la banda magntica (que obtienen datos pueden reproducir y vender tarjetas de pago en todo el mundo.
est en el reverso de la tarjeta, en un chip o
en cualquier otro dispositivo). Estos datos se
denominan alternativamente, pista completa,
pista, pista 1, pista 2 y datos de banda
magntica.
Nota: En el transcurso normal de los
negocios, es posible que se deban retener los
siguientes elementos de datos de la banda
magntica:
El nombre del titular de la tarjeta.
Nmero de cuenta principal (PAN).
Fecha de vencimiento.
Cdigo de servicio.
Para minimizar el riesgo, almacene solamente
los elementos de datos que sean necesarios
para el negocio.
Nota: Consulte el Glosario de trminos,
abreviaturas y acrnimos de las PCI DSS
para obtener ms informacin.
No almacene el valor ni el cdigo de El objetivo del cdigo de validacin de la tarjeta es proteger las transacciones
validacin de tarjetas (nmero de tres o de tarjetas ausentes (transacciones de pedidos por Internet o correo/
cuatro dgitos impreso en el anverso o telfono). Estos tipos de transacciones pueden autenticarse y demostrar que
reverso de una tarjeta de pago) que se utiliza provienen del propietario de la tarjeta con slo solicitar este cdigo de
para verificar las transacciones de tarjetas validacin de la tarjeta, ya que el propietario tiene la tarjeta en la mano y
ausentes. puede leer el valor. Si estos datos prohibidos se almacenan y luego son
Nota: Consulte el Glosario de trminos, robados, las personas malintencionadas pueden ejecutar transacciones de
abreviaturas y acrnimos de las PCI DSS pedidos por Internet o correo/telfono fraudulentas.
para obtener ms informacin.
No almacene el nmero de identificacin Slo el propietario de la tarjeta o el banco que la emiti deben conocer estos
personal (PIN) ni el bloqueo del PIN cifrado. valores. Si estos datos prohibidos se almacenan y luego son robados, las
personas malintencionadas pueden ejecutar transacciones de dbito con PIN
fraudulentas.
Requisito Gua
3.3 Oculte el PAN cuando aparezca (los primeros seis y La aparicin del PAN completo en artculos como las pantallas de computadoras,
los ltimos cuatro dgitos es la cantidad mxima de los recibos de tarjetas de pago, los faxes o los informes en papel puede facilitar la
dgitos que aparecer). obtencin de estos datos por parte de individuos no autorizados y su uso
Notas: fraudulento. El PAN puede mostrarse completo en los recibos de copia de
comerciantes; sin embargo, los recibos en papel deben adherirse a los mismos
Este requisito no se aplica a trabajadores y a otras requisitos de seguridad que las copias electrnicas y seguir los lineamientos de
partes que posean una necesidad especfica de las Normas de Seguridad de Datos de la PCI, especialmente el Requisito 9 sobre
conocer el PAN completo. seguridad fsica. El PAN completo tambin puede mostrarse a quienes tienen una
Este requisito no reemplaza los requisitos ms necesidad comercial legtima de visualizar el PAN completo.
estrictos que fueron implementados y que
aparecen en los datos del titular de la tarjeta (por
ejemplo, los recibos de puntos de venta [POS]).
3.4 Haga que el PAN quede, como mnimo, ilegible en La falta de proteccin del PAN puede permitir a los individuos malintencionados
cualquier lugar donde se almacene (incluidos los datos visualizar o descargar estos datos. Todos los PAN que se almacenan en
que se almacenen en medios digitales porttiles y en almacenamiento principal (bases de datos o archivos planos, como hojas de
registros) utilizando cualquiera de los siguientes clculo de archivos de texto) y en almacenamiento no principal (copias de
mtodos: seguridad, registros de auditora, registros de excepcin o resolucin de
problemas) deben protegerse. El dao ocasionado por el robo o la prdida de
cintas de respaldo durante el transporte puede reducirse si se asegura que los
PAN sean ilegibles mediante el cifrado, el truncamiento y la refundicin. Como
los registros de auditora, de resolucin de problemas y de excepcin deben
conservarse, puede impedir la divulgacin de los datos del registro si se
asegura que los PAN sean ilegibles (los elimina u oculta) en los registros.
Consulte el Glosario de trminos, abreviaturas y acrnimos de las PCI DSS y
las PA-DSS para obtener definiciones de criptografa slida.
Valores hash de una va en criptografa slida Los valores hash de una va (como SHA-1) en criptografa slida pueden
usarse para que los datos de los titulares de tarjetas sean ilegibles. Los
valores hash son apropiados cuando no hay necesidad de recuperar el
nmero original (los valores hash de una va son irreversibles).
Truncamiento. El propsito del truncamiento es que se almacene slo una porcin del PAN
(que no se superen los primeros seis dgitos y los ltimos cuatro). Esto es
distinto al ocultamiento, en donde el PAN completo se almacena pero se
oculta cuando aparece (es decir, slo aparece una parte del PAN en las
pantallas, los informes, los recibos, etc.).
Token y ensambladores de ndices (los Los tokens y ensambladores de ndices tambin pueden usarse para que los
ensambladores se deben almacenar de manera datos de los titulares de tarjetas sean ilegibles. Un token de ndice es un token
segura). criptogrfico que reemplaza el PAN en base a un ndice dado para un valor
imprevisible. Un ensamblador de una vez es un sistema en el que una clave
privada, que se genera de forma aleatoria, se usa slo una vez para cifrar un
mensaje que luego se descifra con un ensamblador de una vez y una clave.
Requisito Gua
Criptografa slida con procesos y procedimientos El propsito de una criptografa slida (consulte la definicin y las longitudes
de gestin de claves relacionadas. de las claves en el Glosario de trminos, abreviaturas y acrnimos de las PCI
DSS) es que el cifrado est basado en un algoritmo probado y aceptado en la
La informacin de cuenta MNIMA que se debe dejar
industria (no en un algoritmo propietario o propio).
ilegible es el PAN.
Notas:
Si por alguna razn, la empresa no puede hacer
que el PAN sea ilegible, consulte el Anexo B:
Controles de compensacin.
La criptografa slida se define en el Glosario de
trminos, abreviaturas y acrnimos de las PCI
DSS.
3.4.1 Si se utiliza cifrado de disco (en lugar de un El objetivo de este requisito es tratar la aceptabilidad del cifrado de disco para
cifrado de base de datos por archivo o que los datos de los titulares de tarjetas sean ilegibles. El cifrado de disco cifra
columna), se debe administrar un acceso los datos almacenados en el almacenamiento masivo de una computadora y
lgico independientemente de los descifra automticamente la informacin cuando un usuario autorizado la
mecanismos de control de acceso del sistema solicita. Los sistemas de cifrado de disco interceptan las operaciones de
operativo nativo (por ejemplo, no se deben lectura y escritura del sistema operativo y realizan las transformaciones
utilizar bases de datos de cuentas de criptogrficas apropiadas sin ninguna accin especial por parte del usuario;
usuarios locales). Las claves de descifrado no slo debe suministrar una contrasea o frase al iniciar sesin. En base a estas
deben estar vinculadas a cuentas de caractersticas de cifrado de disco, para cumplir con este requisito, el mtodo
usuarios. de cifrado de disco no puede tener:
1) Una asociacin directa con el sistema operativo.
2) Claves de descifrado asociadas con las cuentas de usuario.
3.5 Proteja las claves criptogrficas que se utilizan para Las claves criptogrficas deben estar muy protegidas porque quienes obtienen
cifrar los datos de los titulares de tarjetas contra su acceso podrn descifrar los datos.
posible divulgacin o uso indebido:
3.5.1 Restrinja el acceso a las claves criptogrficas Muy pocas personas deben tener acceso a claves criptogrficas;
al nmero mnimo de custodios necesarios. generalmente, slo quienes tienen responsabilidad como custodios de las
claves.
3.5.2 Guarde las claves criptogrficas de forma Las claves criptogrficas deben almacenarse de manera segura,
segura en la menor cantidad de ubicaciones y generalmente con claves de cifrado, y en muy pocos lugares.
formas posibles.
Requisito Gua
3.6 Documente completamente e implemente todos los La forma en la que se gestionan las claves criptogrficas es una parte
procesos y los procedimientos de gestin de claves de fundamental de la seguridad constante de la solucin de cifrado. Un buen
las claves criptogrficas que se utilizan para el cifrado procedimiento de gestin de claves, ya sea manual o automtico como parte
de datos de titulares de tarjetas, incluido lo siguiente: del producto de cifrado, incluye todos los elementos clave desde 3.6.1 hasta
3.6.8.
3.6.1 Generacin de claves criptogrficas slidas La solucin de cifrado debe generar claves slidas, segn se define en el
Glosario de trminos, abreviaturas y acrnimos de las PCI DSS en
criptografa slida.
3.6.2 Distribucin segura de claves criptogrficas La solucin de cifrado debe distribuir las claves de manera segura; esto
significa que las claves no se distribuyen en el espacio libre y que slo son
distribuidas a los custodios que se identifican en 3.5.1.
3.6.3 Almacenamiento seguro de claves La solucin de cifrado debe almacenar las claves de manera segura; esto
criptogrficas significa que las claves no se almacenan en el espacio libre (cfrelas con una
clave de cifrado de clave).
3.6.4 Cambios peridicos de claves criptogrficas Si el proveedor de aplicacin de cifrado le suministra recomendaciones o
Segn se considere necesario y lo procesos del proveedor para el cambio peridico de claves, sgalos. El cambio
recomiende la aplicacin asociada (por anual de claves de cifrado es imprescindible para minimizar el riesgo de que
ejemplo, volver a digitar las claves), alguien obtenga las claves de cifrado y pueda descifrar los datos.
preferentemente en forma automtica
Por lo menos, anualmente
3.6.5 Destruccin o reemplazo de claves Las claves antiguas que ya no se usan ni se necesitan deben retirarse o
criptogrficas antiguas o supuestamente en destruirse para asegurarse de que no se vuelvan a usar. Si es necesario
riesgo conservar las claves antiguas (por ejemplo, para respaldar los datos cifrados y
archivados), debe protegerlas muy bien (consulte 3.6.6 a continuacin). La
solucin de cifrado tambin debe permitir y facilitar un proceso para
reemplazar claves que sepa que estn sospechadas o en riesgo.
3.6.6 Divida el conocimiento y la creacin del La divisin del conocimiento y el control dual de claves se usan para eliminar
control dual de claves criptogrficas la posibilidad de que una persona tenga acceso a toda la clave.
Generalmente, este control se aplica en sistemas de cifrado de clave
manuales o donde el producto de cifrado no implementa la gestin de claves.
Por lo general, este tipo de control se implementa dentro de mdulos de
seguridad de hardware.
Requisito Gua
3.6.7 Prevencin de sustitucin no autorizada de La solucin de cifrado no debe permitir ni aceptar la sustitucin de claves
claves criptogrficas provenientes de fuentes no autorizadas ni procesos inesperados.
3.6.8 Requisito de que los custodios de claves Este proceso garantiza que el individuo se compromete con el rol de custodio
criptogrficas firmen un formulario en el que de las claves y comprende sus responsabilidades.
declaren que comprenden y aceptan su
responsabilidad como custodios de las claves
Requisito 4: Codifique la transmisin de los datos de los titulares de tarjetas a travs de redes pblicas abiertas.
La informacin confidencial se debe codificar durante su transmisin a travs de redes a las que delincuentes puedan acceder fcilmente. Las
redes inalmbricas mal configuradas y las vulnerabilidades en cifrados herederos y protocolos de autenticacin pueden ser los objetivos de
delincuentes que explotan estas vulnerabilidades a los efectos de acceder a los entornos de datos de los titulares de las tarjetas.
Requisito Gua
4.1 Utilice criptografa y protocolos de seguridad slidos La informacin confidencial se debe codificar durante su transmisin a travs
como SSL/TLS o IPSEC para salvaguardar los datos de redes pblicas, ya que para una persona malintencionada es simple y
confidenciales de los titulares de las tarjetas durante su comn interceptar o desviar datos mientras se transmiten. La Capa de
transmisin a travs de redes pblicas abiertas. Conexin Segura (SSL) cifra pginas web y los datos que se ingresan en
Ejemplos de redes pblicas abiertas que se encuentran stas. Cuando use sitios web asegurados con SSL, asegrese de que https
dentro del alcance de las DSS de la PCI son: est en el URL.
Tenga en cuenta que las versiones de SSL anteriores a v3.0 contienen
Internet
vulnerabilidades documentadas, como desbordamientos de buffer, que un
Tecnologas inalmbricas atacante puede usar para obtener el control del sistema afectado.
Sistema global de comunicaciones mviles (GSM)
Servicio de radio paquete general (GPRS)
Requisito Gua
4.1.1 Asegrese de que las redes inalmbricas que Los usuarios malintencionados usan herramientas gratuitas y ampliamente
transmiten datos de los titulares de las tarjetas o que disponibles para espiar las comunicaciones inalmbricas. El uso del cifrado
estn conectadas al entorno de datos del titular de la apropiado puede impedir que estos individuos espen y divulguen informacin
tarjeta utilizan las mejores prcticas de la industria (por confidencial en la red. Muchos riesgos conocidos de datos de titulares de
ejemplo, IEEE 802.11i) a los efectos de implementar tarjetas almacenados slo en la red cableada se originan cuando un usuario
cifrados slidos para la autenticacin y transmisin. malintencionado extiende el acceso de una red inalmbrica insegura.
En el caso de nuevas implementaciones Se necesita un cifrado slido para la autenticacin y transmisin de los datos
inalmbricas, se prohbe la implementacin WEP de titulares de tarjetas para poder impedir que usuarios malintencionados
despus del 31 de marzo de 2009. obtengan acceso a la red inalmbrica (a los datos de la red) o utilicen las
En el caso de actuales implementaciones redes inalmbricas para tener acceso a otras redes inalmbricas o datos.
inalmbricas, se prohbe la implementacin WEP WEP no utiliza un cifrado slido. El cifrado WEP nunca debe usarse solo, ya
despus del 30 de junio de 2010. que es vulnerable debido a vectores iniciales dbiles (IV) en el proceso de
intercambio de clave WEP, y la falta de la rotacin de claves necesaria. Un
atacante puede usar herramientas de craqueo de fuerza bruta para penetrar el
cifrado WEP.
Los dispositivos inalmbricos actuales deben actualizarse (por ejemplo:
actualizar el firmware de punto de acceso a WPA) para admitir un cifrado
slido. Si los dispositivos actuales no pueden actualizarse, es necesario
adquirir nuevas computadoras.
Si las redes inalmbricas estn usando WEP, no deben tener acceso a
entornos de datos de los titulares de las tarjetas.
4.2 Nunca debe enviar PAN no cifrados por medio de El correo electrnico, la mensajera instantnea y el chat pueden ser
tecnologas de mensajera de usuario final (por fcilmente interceptados por el olfateo de paquetes durante la entrega en
ejemplo, el correo electrnico, la mensajera redes internas y pblicas. No utilice estas herramientas de mensajera para
instantnea o el chat). enviar PAN a menos que le ofrezcan capacidades de cifrado.
Gua para los requisitos 5 y 6: Desarrolle un programa de administracin de vulnerabilidad
Requisito 5: Utilice y actualice regularmente el software o los programas antivirus

El software malicioso, llamado "malware", incluidos los virus, los gusanos (worm) y los troyanos (Trojan), ingresa a la red durante muchas actividades
comerciales aprobadas incluidos los correos electrnicos de los trabajadores y la utilizacin de Internet, de computadoras porttiles y de dispositivos
de almacenamiento y explota las vulnerabilidades del sistema. El software antivirus deber utilizarse en todos los sistemas que el malware, por lo
general, afecta para proteger los sistemas contra las amenazas de software maliciosos actuales o que eventualmente se desarrollen.
Requisito Gua
5.1 Implemente software antivirus en todos los sistemas Hay un flujo constante de ataques que usan puntos vulnerables ampliamente
comnmente afectados por software malicioso (en publicados, generalmente "da cero" (publicado y extendido en las redes no ms
especial, computadoras personales y servidores). de una hora despus de su descubrimiento) contra sistemas que no estn
asegurados. Sin un software antivirus que se actualice regularmente, estas
nuevas formas de software malicioso pueden atacar y desactivar su red.
El software malicioso puede descargarse sin saberlo o instalarse de Internet,
pero las computadoras tambin son vulnerables cuando se usan dispositivos de
almacenamiento extrables, como CD y DVD, memorias USB y discos duros,
cmaras digitales, asistentes digitales personales (PDA) y otros dispositivos
perifricos. Si estas computadoras no tienen ningn software antivirus instalado,
pueden convertirse en puntos de acceso a su red y dirigirse maliciosamente a la
informacin que hay en la red.
Si bien los sistemas que comnmente se ven afectados por software malicioso,
en general, no incluyen mainframes y la mayora de los sistemas Unix (consulte
ms detalles a continuacin), cada entidad debe tener un proceso segn el
Requisito 6.2 de las PCI DSS para identificar y tratar las nuevas
vulnerabilidades de seguridad y actualizar sus procesos y normas de
configuracin. Las tendencias en software malicioso relacionadas con los
sistemas operativos que usa una entidad deben incluirse en la identificacin de
las nuevas vulnerabilidades de seguridad y los mtodos para tratar nuevas
tendencias deben incorporarse en las normas de configuracin y los
mecanismos de proteccin de la empresa segn sea necesario.
Generalmente, el software malicioso no afecta estos sistemas operativos:
mainframes y ciertos servidores Unix (como AIX, Solaris y HP-Unix). Sin
embargo, las tendencias de la industria para software malicioso pueden cambiar
rpidamente y cada organizacin debe cumplir con el Requisito 6.2 para
identificar y tratar las nuevas vulnerabilidades de seguridad y actualizar sus
procesos y normas de configuracin.
Requisito Gua
5.1.1 Asegrese de que todos los programas Es importante proteger las computadoras contra TODO tipo y forma de software
antivirus sean capaces de detectar y malicioso.
eliminar todos los tipos conocidos de
software malicioso y de proteger los
sistemas contra estos.
5.2 Asegrese de que todos los mecanismos antivirus El mejor software antivirus es limitado en eficacia si no tiene las firmas antivirus
son actuales, estn en funcionamiento y son capaces actualizadas o si no est activa en la red o en una computadora. Los registros
de generar registros de auditora. de auditora ofrecen la capacidad de supervisar la actividad de los virus y las
reacciones antivirus.
Requisito 6: Desarrolle y mantenga sistemas y aplicaciones seguras
Las personas sin escrpulos utilizan las vulnerabilidades de seguridad para obtener acceso privilegiado a los sistemas. Muchas de estas
vulnerabilidades se pueden subsanar mediante parches de seguridad proporcionados por los proveedores. Las entidades que administran los
sistemas deben instalar estos parches. Todos los sistemas importantes deben poseer la ltima versin de los parches adecuados para estar
protegidos contra la explotacin de los datos de los titulares de las tarjetas y el riego que representan los delincuentes y el software malicioso.
Nota: Los parches de software adecuados son aqullos que se evaluaron y probaron para confirmar que no crean conflicto con las
configuraciones de seguridad existentes. En el caso de las aplicaciones desarrolladas internamente por la institucin, es posible evitar numerosas
vulnerabilidades mediante la utilizacin de procesos estndares de desarrollo de sistemas y tcnicas de codificacin segura.
Requisito Gua
6.1 Asegrese de que todos los componentes de sistemas Existe una gran cantidad de ataques que usan puntos vulnerables
y software cuenten con los parches de seguridad ms ampliamente publicados, generalmente "da cero" (publicado y extendido en
recientes proporcionados por los proveedores. Instale una hora) contra los sistemas que no estn asegurados. Si no se implementan
los parches importantes de seguridad dentro de un los parches ms recientes en los sistemas importantes lo antes posible, una
plazo de un mes de su lanzamiento. persona malintencionada puede usar estos puntos vulnerables para atacar y
Nota: Las organizaciones pueden tener en cuenta la desactivar la red. Considere priorizar cambios como los parches importantes
aplicacin de un enfoque basado en el riesgo a los de seguridad para los sistemas importantes o en riesgo que pueden instalarse
efectos de priorizar la instalacin de parches. Por en no ms de 30 das y otros cambios menos riesgosos que pueden instalarse
ejemplo, al priorizar infraestructura de importancia (por en no ms de 2 3 meses.
ejemplo, dispositivos y sistemas pblicos, bases de
datos) superiores a los dispositivos internos menos
crticos a los efectos de asegurar que los dispositivos y
los sistemas de alta prioridad se traten dentro del
periodo de un mes y se traten dispositivos y sistemas
menos crticos dentro de un periodo de tres meses.
6.2 Establezca un proceso para identificar las El objetivo de este requisito es que las organizaciones se mantengan
vulnerabilidades de seguridad recientemente actualizadas con respecto a las nuevas vulnerabilidades para que puedan
descubiertas (por ejemplo, suscrbase a los servicios proteger de manera apropiada su red e incorporar las vulnerabilidades
de alerta disponibles de forma gratuita a travs de recientemente descubiertas y relevantes en sus normas de configuracin.
Internet). Actualice las normas de configuracin
conforme al Requisito 2.2 de las DSS de la PCI para
subsanar cualquier otro problema de vulnerabilidad.
Requisito Gua
6.3 Desarrolle aplicaciones de software conforme a las Sin la inclusin de seguridad durante las fases de desarrollo de software de
DSS de la PCI (por ejemplo, registro y autenticacin definicin de requisitos, diseo, anlisis y prueba, las vulnerabilidades de
seguros) sobre la base de las mejores prcticas de la seguridad pueden introducirse de forma inadvertida o maliciosamente en el
industria e incorpore la seguridad de la informacin en entorno de produccin.
todo el ciclo de desarrollo de software. Los procesos
deben incluir lo siguiente:
6.3.1 La prueba de todos los parches de seguridad Asegrese de que todas las instalaciones y los cambios se realicen de la
y los cambios de configuracin del sistema y manera esperada y que no tengan ninguna funcin inesperada, no deseada o
del software antes de su implementacin daina.
6.3.1.1 Validacin de las entradas (para prevenir
el lenguaje de comandos entre distintos
sitios, los errores de inyeccin, la
ejecucin de archivos maliciosos, etc.)
6.3.1.2 Validacin de un correcto manejo de los
errores
6.3.1.3 Validacin del almacenamiento
criptogrfico seguro.
6.3.1.4 Validacin de las comunicaciones
seguras
6.3.1.5 Validacin de un correcto control del
acceso basado en funciones (RBAC)
6.3.2 Desarrollo/prueba por separado y entornos de Generalmente, los entornos de desarrollo y prueba son menos seguros que el
produccin entorno de produccin. Sin una separacin adecuada, el entorno de
produccin y los datos de titulares de tarjetas pueden estar en riesgo debido a
vulnerabilidades o procesos internos dbiles.
6.3.3 Separacin de funciones entre Esto minimiza la cantidad de personal con acceso al entorno de produccin y
desarrollo/prueba y entornos de produccin a los datos de titulares de tarjetas y ayuda a garantizar que el acceso quede
limitado a quienes verdaderamente necesitan ese acceso.
6.3.4 Los datos de produccin (PAN activos) no se En general, los controles de seguridad no son tan estrictos en el entorno de
utilizan para las pruebas ni para el desarrollo desarrollo. El uso de datos de produccin ofrece a las personas
malintencionadas la posibilidad de obtener acceso no autorizado a datos de
produccin (datos de titulares de tarjetas).
Requisito Gua
6.3.5 Eliminacin de datos y cuentas de prueba Los datos y las cuentas de prueba se deben eliminar del cdigo de produccin
antes de que se activen los sistemas de antes de que se active la aplicacin, ya que estos elementos pueden revelar
produccin informacin sobre el funcionamiento de la aplicacin. La posesin de esta
informacin puede poner en riesgo la aplicacin y los datos de titulares de
tarjetas relacionados.
6.3.6 Eliminacin de las cuentas, los ID de usuario Las cuentas, los ID de usuario y las contraseas personalizadas de la
y las contraseas personalizadas de la aplicacin se deben eliminar del cdigo de produccin antes de que la
aplicacin antes que las aplicaciones se aplicacin se active o se ponga a disposicin de los clientes, ya que estos
activen o se pongan a disposicin de los elementos pueden revelar informacin sobre el funcionamiento de la
clientes aplicacin. La posesin de esta informacin puede poner en riesgo la
aplicacin y los datos de titulares de tarjetas relacionados.
6.3.7 Revisin del cdigo personalizado antes del En general, las personas malintencionadas explotan las vulnerabilidades de
envo a produccin o a los clientes a fin de los cdigos personalizados para obtener acceso a una red y poner en riesgo
identificar posibles vulnerabilidades de la los datos de titulares de tarjetas. Quienes tienen conocimiento sobre tcnicas
codificacin de codificacin segura deben revisar el cdigo para identificar
Nota: Este requisito de revisin de cdigos se vulnerabilidades.
aplica a todos los cdigos personalizados
(tanto internos como pblicos) como parte del
ciclo de vida de desarrollo del sistema que el
Requisito 6.3 de las DSS de la PCI exige. Las
revisiones de los cdigos pueden ser
realizadas por personal interno con
conocimiento. Las aplicaciones web tambin
estn sujetas a controles adicionales, si son
pblicas, a los efectos de tratar con las
amenazas continuas y vulnerabilidades
despus de la implementacin, conforme al
Requisito 6.6 de las DSS de la PCI.
Requisito Gua
6.4 Siga los procedimientos de control de todos los Sin controles de cambio de software adecuados, las funciones de seguridad
cambios en los componentes del sistema. Los pueden omitirse de manera inadvertida o deliberada, o volverse inoperables, y
procedimientos deben incluir lo siguiente: es posible que se procesen irregularidades o se introduzcan cdigos
maliciosos. Si las polticas de personal relacionadas con las verificaciones de
antecedentes y los controles de acceso a los sistemas no son adecuadas,
existe el riesgo de que individuos poco fiables y faltos de formacin tengan
acceso ilimitado a los cdigos de software; los empleados cesantes pueden
tener la oportunidad de poner en riesgo los sistemas y es posible que no se
detecten acciones no autorizadas.
6.4.1 Documentacin de incidencia El impacto del cambio debe documentarse para que todas las partes
afectadas puedan programar de manera apropiada cualquier cambio de
procesamiento.
6.4.2 Aprobacin de la gerencia a cargo de las La aprobacin de la gerencia indica que el cambio es legtimo y est
partes pertinentes autorizado por la organizacin.
6.4.3 Pruebas de la funcionalidad operativa Se deben realizar pruebas rigurosas para verificar que todas las acciones son
las esperadas, que los informes son precisos, que todas las posibles
condiciones de error reaccionan adecuadamente, etc.
6.4.4 Procedimientos de desinstalacin Para cada cambio, debe haber procedimientos de desinstalacin en caso de
que el cambio falle, para permitir que se pueda volver al estado previo.
6.5 Desarrolle todas las aplicaciones web (internas y La capa de aplicacin es de alto riesgo y puede ser el blanco de amenazas
externas, que incluyan acceso administrativo web a la internas y externas. Sin la seguridad apropiada, se pueden exponer los datos
aplicacin) basadas en las directrices de codificacin de titulares de tarjetas y otra informacin confidencial de la empresa, lo que
segura, como la Gua para proyectos de seguridad de puede ocasionar daos a la empresa, a sus clientes y a su reputacin.
aplicaciones web abierta. Considere la prevencin de
las vulnerabilidades de codificacin comunes en los
procesos de desarrollo de software, a fin de incluir:
Nota: Las vulnerabilidades que se enumeran desde el
punto 6.5.1 hasta el punto 6.5.10 se actualizaron en la
gua OWASP cuando se public la v1.2 de las DSS de
la PCI. Sin embargo, al actualizar la gua OSWAP, y si
se actualiza, la versin actual se debe utilizar para
estos requisitos.
Requisito Gua
6.5.1 Lenguaje de comandos entre distintos sitios Todos los parmetros deben ser validados antes de su inclusin. Los errores
(XSS) de XSS se producen cuando una aplicacin toma datos suministrados por el
usuario y los enva a un explorador web sin primero validar o codificar ese
contenido. XSS permite a los atacantes ejecutar secuencias en el navegador
de la vctima que puede apropiarse de las sesiones del usuario, destruir sitios
web y posiblemente introducir gusanos, etc.
6.5.2 Errores de inyeccin, en especial, errores de Valide la entrada para verificar que los datos del usuario no pueden modificar
inyeccin SQL. Tambin considere los errores el significado de los comandos ni el de las consultas. Los errores de inyeccin,
de inyeccin LDAP y Xpath, as como otros en especial, los errores de inyeccin SQL son comunes en las aplicaciones
errores de inyeccin. web. La inyeccin se produce cuando se envan datos suministrados por el
usuario a un intrprete como parte de un comando o una consulta. Los datos
hostiles del atacante engaan al intrprete para que ejecute comandos
accidentales o cambie datos, y le permiten atacar los componentes que hay
dentro de la red a travs de la aplicacin, para iniciar ataques como
desbordamientos de buffer o para revelar informacin confidencial y la
funcionalidad de la aplicacin del servidor. sta tambin es una forma
generalizada de realizar transacciones fraudulentas en sitios web habilitados
para el comercio. La informacin de solicitudes web debe validarse antes de
enviarse a la aplicacin web; por ejemplo, mediante la verificacin de todos
los caracteres alfa, la combinacin de caracteres numricos y alfa, etc.
6.5.3 Ejecucin de archivos maliciosos Valide la entrada para verificar que la aplicacin no acepte nombres de
archivos inesperados ni archivos de los usuarios. El cdigo vulnerable a la
inclusin de archivos remotos permite a los atacantes incluir datos y cdigos
hostiles, lo que genera ataques devastadores, como el riesgo total del
servidor. Los ataques por ejecucin de archivos maliciosos afectan PHP, XML
y cualquier marco que acepte nombres de archivos o archivos de los usuarios.
6.5.4 Referencias inseguras a objetos directos No exponga referencias a objetos internos ante los usuarios. Una referencia a
un objeto directo se produce cuando un desarrollador expone una referencia a
un objeto de implementacin interna, por ejemplo, un archivo, un directorio, un
registro de base de datos o una clave, como un URL o un parmetro de forma.
Los atacantes pueden manipular estas referencias para acceder a otros
objetos sin autorizacin.
Requisito Gua
6.5.5 Falsificacin de solicitudes entre distintos No confe en las credenciales de autorizacin ni en los tokens que los
sitios (CSRF) exploradores presentan automticamente. Un ataque de CSRF obliga al
navegador de la vctima conectada a enviar una solicitud preautenticada a una
aplicacin web vulnerable, que luego obliga al navegador de la vctima a
ejecutar una accin hostil para beneficio del atacante. La CSRF puede ser tan
poderosa como la aplicacin web que ataca.
6.5.6 Filtracin de informacin y manejo No filtre informacin por medio de mensajes de error u otros medios. Las
inadecuado de errores aplicaciones pueden filtrar informacin sobre su configuracin o trabajos
internos sin querer o pueden violar la privacidad a travs de una variedad de
problemas de aplicaciones. Los atacantes usan esta debilidad para robar
datos confidenciales o para realizar ataques ms graves. Adems, el manejo
inadecuado de errores ofrece informacin que ayuda a las personas
malintencionadas a poner en riesgo el sistema. Si una persona
malintencionada puede crear errores que una aplicacin web no puede
manejar correctamente, puede obtener informacin detallada del sistema,
puede crear interrupciones por negacin de servicios, puede hacer que la
seguridad falle o puede bloquear el servidor. Por ejemplo, el mensaje "la
contrasea suministrada es incorrecta indica a los delincuentes que el ID de
usuario suministrada es correcto y que deben concentrar sus esfuerzos slo
en la contrasea. Use mensajes de error ms genricos, como no se pueden
verificar los datos.
6.5.7 Autenticacin y administracin de sesin Autentique correctamente a los usuarios y proteja las credenciales de cuentas
interrumpidas y los tokens de sesin. Por lo general, las credenciales de cuentas y los
tokens de sesin no se protegen de manera adecuada. Los atacantes ponen
el riesgo las contraseas, las claves o los tokens de autenticacin para asumir
la identidad de otros usuarios.
6.5.8 Almacenamiento criptogrfico inseguro Prevenga errores criptogrficos. Las aplicaciones web casi nunca usan
funciones criptogrficas de manera adecuada para proteger los datos y las
credenciales. Los atacantes usan estos datos dbilmente protegidos para
ejecutar robos de identidad y otros delitos, como el fraude de tarjeta de crdito.
6.5.9 Comunicaciones inseguras Cifre correctamente todas las comunicaciones autenticadas y confidenciales.
Con frecuencia, las aplicaciones no cifran el trnsito de la red cuando es
necesario proteger comunicaciones confidenciales.
Requisito Gua
6.5.10 Omisin de restringir el acceso URL Refuerce constantemente el control del acceso en la capa de presentacin y
la lgica comercial para todas las URL. Con frecuencia, una aplicacin slo
protege la funcionalidad confidencial; para ello, no permite a los usuarios no
autorizados que vean vnculos o URL. Los atacantes pueden usar esta
debilidad para tener acceso y realizar operaciones no autorizadas mediante el
acceso a esos URL directamente.
6.6 En el caso de aplicaciones web pblicas, trate las En general, los ataques a aplicaciones web son comunes tienen xito y estn
nuevas amenazas y vulnerabilidades continuamente y permitidos por las malas prcticas de codificacin. Este requisito para revisar
asegrese de que estas aplicaciones estn protegidas aplicaciones o instalar firewalls de aplicacin web pretende reducir en gran
contra ataques conocidos a travs de alguno de los medida la cantidad de riesgos que corren las aplicaciones web pblicas que
siguientes mtodos: ocasionan fallos en los datos de titulares de tarjetas.
Controlar las aplicaciones web pblicas mediante Puede usar herramientas o mtodos de evaluacin de seguridad de
herramientas o mtodos de evaluacin de vulnerabilidad automticos o manuales que revisen o examinen las
seguridad de vulnerabilidad de aplicacin vulnerabilidades de las aplicaciones para cumplir con este requisito.
automticas o manuales, por lo menos, Los firewalls de aplicacin web filtran y bloquean el trnsito no
anualmente y despus de cada cambio esencial en la capa de aplicacin. Junto con un firewall de red, un
Instalar un firewall de aplicacin web enfrente de firewall de aplicacin web correctamente configurado previene
aplicaciones web pblicas ataques a la capa de aplicacin si las aplicaciones estn codificadas o
configuradas incorrectamente.
Consulte el Suplemento informativo: aclaracin del requisito 6.6 sobre
revisiones de aplicaciones y firewalls de aplicacin web
(www.pcisecuritystandards.org), para obtener ms informacin.
Gua para los requisitos 7, 8 y 9: Implemente medidas slidas de control de acceso
Requisito 7: Restrinja el acceso a datos de titulares de tarjetas slo a la necesidad de conocimiento de la empresa.
A los efectos de asegurar que el personal autorizado sea el nico que pueda acceder a los datos importantes, se deben implementar sistemas y
procesos que limiten el acceso conforme a la necesidad de conocer y conforme a la responsabilidad del cargo. "La necesidad de conocer" es la
situacin en que se otorgan derechos a la menor cantidad de datos y privilegios necesarios para realizar una tarea.
Requisito Gua
7.1 Limite el acceso a los componentes del sistema y a los Mientras ms gente tenga acceso a los datos de titulares de tarjetas, ms
datos del titular de la tarjeta a aquellos individuos riesgo hay de que una cuenta de usuario se use maliciosamente. Limitar el
cuyas tareas necesitan de ese acceso. Las limitaciones acceso a quienes tienen una razn comercial slida para tener acceso ayuda
al acceso deben incluir lo siguiente: a su organizacin a prevenir el mal manejo de los datos de titulares de tarjetas
7.1.1 Restricciones a los derechos de acceso a ID de por falta de experiencia o maldad. Cuando se otorgan derechos de acceso a
usuarios privilegiadas a la menor cantidad de la menor cantidad de datos y privilegios necesarios para realizar una tarea, se
privilegios necesarios para cumplir con las denomina necesidad de conocer y cuando los privilegios se asignan a
responsabilidades del cargo individuos en base a la clasificacin y la funcin, se denomina "control de
acceso basado en funciones" o RBAC. Su organizacin debe crear una
7.1.2 La asignacin de privilegios se basa en la tarea del poltica clara y procesos para el control de acceso a datos en base a la
personal individual, su clasificacin y funcin necesidad de conocer y mediante el uso del "control de acceso basado en
7.1.3 Los requisitos de un formulario de autorizacin funciones" para definir cmo y a quin se le otorga acceso.
escrito por la gerencia que detalle los privilegios
solicitados
7.1.4 Implementacin de un sistema de control de acceso
automtico
7.2 Establezca un mecanismo para componentes del Sin un mecanismo para restringir el acceso en base a la necesidad de
sistema con mltiples usuarios que restrinja el acceso conocer que tiene el usuario, es posible que sin saberlo se le otorgue acceso
en base a la necesidad del usuario de conocer y se a los datos de titulares de tarjetas a un usuario. El uso de un mecanismo o
configure para "negar todos", salvo que se permita sistema de control de acceso automtico es esencial para administrar varios
particularmente. Este sistema de control de acceso usuarios. Este sistema debe establecerse de acuerdo con la poltica y los
debe incluir lo siguiente: procesos de control de acceso de su organizacin (incluida la necesidad de
Nota: "La necesidad de conocer" es la situacin en que conocer y el control de acceso basado en funciones), debe administrar el
se otorgan derechos a la menor cantidad de datos y acceso a todos los componentes del sistema y debe tener un ajuste
privilegios necesarios para realizar una tarea. predeterminado de negar todos para garantizar que a nadie se le otorgue
acceso a menos que se establezca una norma especfica que le otorgue dicho
7.2.1 Cobertura de todos los componentes del sistema
acceso.
7.2.2 La asignacin de privilegios a individuos se basa en
la clasificacin del trabajo y la funcin
7.2.3 Ajuste predeterminado "negar todos"
Requisito 8: Asigne una ID nica a cada persona que tenga acceso a computadoras
La asignacin de una identificacin (ID) nica a cada persona que tenga acceso garantiza que cada una de ellas es responsable de sus actos.
Cuando se ejerce dicha responsabilidad, las acciones en datos crticos y sistemas las realizan usuarios conocidos y autorizados, y adems se
pueden realizar seguimientos.
Requisito Gua
8.1 Asigne a todos los usuarios una ID nica antes de Si una organizacin se asegura que cada usuario tiene una identificacin nica
permitirles tener acceso a componentes del sistema y (en vez de usar una misma ID para varios empleados), puede mantener la
a datos de titulares de tarjetas. responsabilidad individual de las acciones y una pista de auditoras efectiva por
empleado. Esto ayuda a acelerar la resolucin de problemas y la contencin
cuando se producen malos usos o intenciones malintencionadas.
8.2 Adems de la asignacin de una ID nica, emplee al Estos elementos de autenticacin, cuando se usan adems de las ID nicas,
menos uno de los mtodos siguientes para autenticar a ayudan a impedir que las ID nicas de los usuarios corran riesgos (ya que
los usuarios: quien intenta poner en riesgo las ID necesita saber el ID nico y la contrasea
Contrasea o frase de seguridad u otro elemento de autenticacin).
Autenticacin de dos factores (por ejemplo,
dispositivos token, tarjetas inteligentes, biometra o
claves pblicas)
8.3 Incorpore la autenticacin de dos factores para el La autenticacin de dos factores requiere dos formas de autenticacin para los
acceso remoto (acceso en el nivel de la red que se accesos de mayor riesgo, como los que se originan fuera de su red. Para mayor
origina fuera de la red) a la red de empleados, seguridad, su organizacin tambin puede considerar usar autenticacin de dos
administradores y terceros. Utilice tecnologas tales factores cuando accede a redes de mayor seguridad desde redes de menor
como autenticacin remota y servicio dial-in (RADIUS); seguridad; por ejemplo, desde escritorios de la empresa (baja seguridad) a
sistema de control de acceso mediante control del bases de datos/servidores de produccin con datos de titulares de tarjetas (alta
acceso desde terminales (TACACS) con tokens; o VPN seguridad).
(basada en SSL/TLS o IPSEC) con certificados
individuales.
8.4 Deje ilegibles todas las contraseas durante la Muchas aplicaciones y dispositivos de red transmiten el ID de usuario y la
transmisin y el almacenamiento en todos los contrasea no cifrada por la red y tambin almacenan contraseas sin cifrado.
componentes del sistema mediante una criptografa Una persona malintencionada puede fcilmente interceptar la contrasea y el
slida (se define en el Glosario de trminos, ID de usuario no cifrados o legibles durante la transmisin mediante un
abreviaturas y acrnimos de las PCI DS). olfateador o acceder directamente a los ID de usuario y a las contraseas no
cifradas en los archivos donde estn almacenadas y usar estos datos robados
para obtener acceso no autorizado.
Requisito Gua
8.5 Asegrese de que sean correctas la autenticacin del Debido a que uno de los primeros pasos que una persona malintencionada
usuario y la administracin de contraseas de usuarios dar para poner en riesgo un sistema es explotar las contraseas dbiles o no
no consumidores y administradores en todos los existentes, es importante implementar buenos procesos para la autenticacin
componentes del sistema de la siguiente manera: del usuario y la administracin de las contraseas.
8.5.1 Controle el agregado, la eliminacin y la Para asegurarse de que los usuarios agregados a sus sistemas son todos
modificacin de las ID de usuario, las usuarios reconocidos y vlidos, un pequeo grupo con autoridad especfica
credenciales, entre otros objetos de debe administrar el agregado, la eliminacin y la modificacin de las ID de
identificacin. usuario. La capacidad de administrar estas ID de usuario slo debe limitarse a
un grupo pequeo.
8.5.2 Verifique la identidad del usuario antes de Muchas personas malintencionadas usan la ingeniera social (por ejemplo,
restablecer contraseas. llaman a una mesa de ayuda y se hacen pasar por usuarios legtimos) para
cambiar la contrasea y poder utilizar una ID de usuario. Considere el uso de
una pregunta secreta que slo el usuario apropiado pueda responder para
ayudar a los administradores a identificar el usuario antes de borrar las
contraseas. Asegrese de que las preguntas estn correctamente
aseguradas y no se compartan.
8.5.3 Configure la primera contrasea en un valor Si se usa la misma contrasea para todas las nuevas configuraciones de
nico para cada usuario y cmbiela de usuario, un usuario interno, un ex empleado o una persona malintencionada
inmediato despus del primer uso. pueden saber o descubrir fcilmente esta contrasea y usarla para obtener
acceso a cuentas.
8.5.4 Cancele de inmediato el acceso para cualquier Si un empleado se va de la empresa y an tiene acceso a la red con su cuenta
usuario cesante. de usuario, se puede producir un acceso innecesario o malintencionado a los
datos de titulares de tarjetas. El autor de este acceso puede ser un ex empleado
o un usuario malintencionado que explota una cuenta antigua o que no se usa.
Considere implementar un proceso con Recursos Humanos para que se realice
una notificacin inmediata cuando un empleado queda cesante para que la
cuenta de usuario se desactive rpidamente.
8.5.5 Elimine/desactive las cuentas de usuario cada La existencia de cuentas inactivas permite a un usuario no autorizado explotar
90 das, como mnimo. la cuenta que no se usa para poder acceder a los datos de titulares de tarjetas.
Requisito Gua
8.5.6 Active las cuentas que utilicen los Si permite que los proveedores (como los proveedores de POS) tengan
proveedores para el mantenimiento remoto acceso a su red las 24 horas, todos los das, cuando necesitan realizar el
nicamente durante el perodo necesario. soporte de sus sistemas, aumentarn las posibilidades de acceso no
autorizado, ya sea de un usuario del entorno de proveedores o de un individuo
malintencionado que encuentra y usa este punto siempre listo de acceso
externo a la red. Consulte tambin 12.3.8 y 12.3.9 para obtener ms
informacin sobre este tema.
8.5.7 Informe los procedimientos y las polticas de Comunicar los procedimientos de contraseas a todos los usuarios ayuda a
contraseas a todos los usuarios que tengan esos usuarios a comprender y acatar las polticas y a estar alertas a cualquier
acceso a datos de titulares de tarjetas. individuo malintencionado que puede intentar explotar sus contraseas para
obtener acceso a los datos de titulares de tarjetas (por ejemplo, llamando a un
empleado y solicitndole su contrasea para que quien llama pueda resolver
un problema).
8.5.8 No utilice cuentas ni contraseas grupales, Si varios usuarios comparten la misma cuenta y la misma contrasea, se torna
compartidas o genricas. imposible asignar responsabilidad o tener un registro efectivo de las acciones
de un individuo, ya que una accin especfica puede haber sido realizada por
cualquier persona del grupo que comparte la cuenta y la contrasea.
8.5.9 Cambie las contraseas de usuario al menos Las contraseas fuertes son la primera lnea de defensa de una red ya que,
cada 90 das. generalmente, un individuo malintencionado primero intentar obtener acceso
a cuentas con contraseas dbiles o no existentes. Un individuo
8.5.10 Solicite una longitud de contrasea mnima de
malintencionado tiene ms tiempo para encontrar estas cuentas dbiles y
siete caracteres. poner en riesgo una red con la apariencia de una ID de usuario vlida, si las
8.5.11 Utilice contraseas que contengan tanto contraseas son breves, fciles de adivinar o vlidas durante un largo tiempo
caracteres numricos como alfabticos. sin cambiar. Las contraseas fuertes pueden hacerse valer y mantenerse
segn estos requisititos porque admiten las funciones de seguridad de
8.5.12 No permita que ninguna persona enve una contraseas y cuentas incluidas con el sistema operativo (por ejemplo,
contrasea nueva igual a cualquiera de las Windows), las redes, las bases de datos y otras plataformas.
ltimas cuatro contraseas utilizadas.
8.5.13 Limite los intentos de acceso repetidos Sin la implementacin de mecanismos de cierre de cuenta, un atacante puede
mediante el bloqueo del ID de usuario intentar constantemente adivinar una contrasea a travs de herramientas
despus de ms de seis intentos. manuales o automticas (por ejemplo, el craqueo de contraseas), hasta que
logre descifrarla y obtenga acceso a una cuenta de usuario.
Requisito Gua
8.5.14 Establezca la duracin del bloqueo en un Si una cuenta est bloqueada debido a que alguien intenta constantemente
mnimo de 30 minutos o hasta que el adivinar una contrasea, los controles para demorar la reactivacin de estas
administrador habilite el ID de usuario. cuentas bloqueadas detienen al individuo malintencionado para que no pueda
seguir adivinando constantemente la contrasea (tendr que esperar al menos
30 minutos hasta que la cuenta se reactive). Adems, si es necesario solicitar
la reactivacin, la mesa de ayuda o admin pueden validar que el propietario de
la cuenta es la causa (por errores de tipeo) del bloqueo.
8.5.15 Si alguna sesin estuvo inactiva durante ms Cuando los usuarios se alejan de una mquina encendida con acceso a datos
de 15 minutos, solicite al usuario que vuelva a importantes de red o de titulares de tarjetas, esa mquina puede ser usada
escribir la contrasea para que se active la por otras personas durante la ausencia del usuario, lo que puede ocasionar un
terminal nuevamente. acceso no autorizado a cuentas o un mal uso de cuentas.
8.5.16 Autentique todos los accesos a cualquier Sin la autenticacin del usuario para acceder a bases de datos y aplicaciones,
base de datos que contenga datos de titulares la posibilidad de acceso no autorizado o malintencionado aumenta, y dicho
de tarjetas. Esto incluye el acceso de acceso no puede ser registrado porque el usuario no ha sido autenticado y,
aplicaciones, administradores y dems por lo tanto, el sistema no lo reconoce. Adems, el acceso a la base de datos
usuarios. debe otorgarse slo a travs de mtodos programticos (por ejemplo, a travs
de procedimientos almacenados), en vez de a travs de acceso directo a las
bases de datos por parte de los usuarios finales (excepto para los DBA, que
pueden tener acceso directo a la base de datos para sus funciones
administrativas).
Requisito 9: Limite el acceso fsico a los datos del titular de la tarjeta
Cualquier acceso fsico a datos o sistemas que alojen datos de titulares de tarjetas permite el acceso a dispositivos y datos, as como tambin
permite la eliminacin de sistemas o copias en papel, y se debe restringir correctamente.
Requisito Gua
9.1 Utilice controles de entrada a la empresa para limitar y Sin controles de acceso fsico, las personas no autorizadas pueden obtener
supervisar el acceso a sistemas en el entorno de datos acceso al edificio y a informacin confidencial, y pueden alterar las
de titulares de tarjetas. configuraciones del sistema, introducir vulnerabilidades en la red o destruir o
robar computadoras.
9.1.1 Utilice cmaras de video u otros mecanismos Cuando se investigan fallos fsicos, estos controles pueden ayudar a
de control de acceso para supervisar el identificar individuos que tienen acceso fsico a esas reas que almacenan
acceso fsico de personas a reas datos de titulares de tarjetas.
confidenciales. Revise los datos recopilados y
correlacinelos con otras entradas. Gurdelos
durante al menos tres meses, a menos que la
ley estipule lo contrario.
Nota: reas confidenciales hace referencia Formatted: Indent: First line: 0", Tab stops:
a cualquier centro de datos, sala de servidores Not at 0.25"
o cualquier rea que aloje sistemas que
almacenan datos de titulares de tarjetas. No se
incluyen las reas en las que se encuentran
presentes terminales de punto de venta, tales
como el rea de cajas en un comercio.
9.1.2 Restrinja el acceso fsico a conexiones de red Si se restringe el acceso a conexiones de red, se impide que personas
de acceso pblico. malintencionadas tengan acceso a las conexiones de red disponibles que
pueden permitirles acceder a recursos de red internos. Considere cerrar las
conexiones de red cuando no las use y reactivarlas slo cuando sean
necesarias. En las reas pblicas, como las salas de conferencias, establezca
redes privadas para permitir a los proveedores y visitantes tener acceso slo a
Internet para que accedan a su red interna.
9.1.3 Restrinja el acceso fsico a puntos de acceso Sin seguridad en el acceso a los dispositivos y componentes inalmbricos, los
inalmbrico, puertas de enlace y dispositivos usuarios malintencionados pueden usar los dispositivos inalmbricos sin
manuales. vigilancia de su empresa para acceder a los recursos de red o, incluso,
conectar sus propios dispositivos a la red inalmbrica, lo que les da acceso no
autorizado. Considere establecer puntos de acceso inalmbrico y puertas de
enlace en reas de almacenamiento seguro, como dentro de armarios
cerrados o salas de servidores. Asegrese de que el cifrado slido est
habilitado. Habilite el bloqueo automtico de dispositivos en dispositivos
manuales inalmbricos despus de un perodo inactivo prolongado y configure
los dispositivos para que soliciten una contrasea cuando se los enciende.
Requisito Gua
9.2 Desarrolle procedimientos para que el personal pueda Sin sistemas de placas de identificacin y controles de puertas, los usuarios
distinguir con facilidad entre empleados y visitantes, no autorizados y malintencionados fcilmente pueden obtener acceso a su
especialmente en las reas donde se puede acceder instalacin y robar, desactivar, afectar o destruir sistemas importantes y datos
fcilmente a datos de titulares de tarjetas. de titulares de tarjetas. Para un control ptimo, considere implementar un
A los fines de este requisito, empleados se refiere a sistema de acceso con tarjetas o placas de identificacin para ingresar y salir
personal de tiempo completo y parcial, personal a las reas de trabajo que contienen datos de titulares de tarjetas.
temporal, y contratistas y consultores que residan en
las instalaciones de la entidad. "Visitante se define
como proveedor, invitado de algn empleado, personal
de servicio o cualquier persona que necesite ingresar a
las instalaciones de la empresa durante un tiempo no
prolongado, generalmente no ms de un da.
9.3 Asegrese de que todos los visitantes reciban el Los controles que se realizan a visitantes son importantes para reducir las
siguiente trato: posibilidades de que personas no autorizadas o malintencionadas obtengan
acceso a sus instalaciones (y posiblemente, tengan acceso a datos de los
titulares de tarjetas).
9.3.1 Autorizacin previa al ingreso a reas en las Los controles que se realizan a visitantes son importantes para garantizar que
que se procesan o se conservan datos de stos slo ingresen a reas a las que estn autorizados a ingresar, que se los
titulares de tarjetas identifique como visitantes para que los empleados puedan controlar sus
9.3.2 Token fsico otorgado (por ejemplo una placa de actividades y que su acceso est restringido slo a la duracin de su visita
identificacin o dispositivo de acceso) con legtima.
vencimiento y que identifique a los visitantes
como personas no pertenecientes a la empresa.
9.3.3 Solicitud de entrega del token fsico antes de
salir de las instalaciones de la empresa o al
momento del vencimiento.
9.4 Use un registro de visitas para implementar una pista de Es simple y econmico mantener un registro de visitantes que documente
auditora fsica de la actividad de visitas. Documente el informacin mnima sobre el visitante y, en una posible investigacin de fallo
nombre del visitante, la empresa a la que representa y el de datos, ayuda a identificar el acceso fsico a un edificio o a una sala y el
empleado que autoriza el acceso fsico en el registro. posible acceso a datos de titulares de tarjetas. Considere implementar
Conserve este registro durante tres meses como registros en el ingreso a instalaciones y, en particular, en el ingreso a zonas
mnimo, a menos que la ley estipule lo contrario. donde hay datos de titulares de tarjetas.
9.5 Almacene los medios de copias de seguridad en un Si las copias de seguridad que contienen datos de titulares de tarjetas estn
lugar seguro, preferentemente en un lugar externo a la almacenadas en una instalacin no asegurada, se pueden perder con facilidad
empresa, como un centro alternativo o para copias de o pueden ser robadas o copiadas con malas intenciones. Para un
seguridad, o un centro de almacenamiento comercial. almacenamiento seguro, considere contratar una empresa de almacenamiento
Revise la seguridad de dicho lugar una vez al ao de datos comerciales o, en si la empresa es ms pequea, use una caja de
como mnimo. seguridad en un banco.
Requisito Gua
9.6 Resguarde de forma fsica todos los papeles y Los datos de titulares de tarjetas son propensos a que personas no
dispositivos electrnicos que contengan datos de autorizadas los vean, copien o escaneen, si no estn protegidos cuando estn
titulares de tarjetas. en medios porttiles, impresos o se dejan en algn escritorio. Considere la
implementacin de procedimientos y procesos para proteger los datos de
titulares de tarjetas en medios distribuidos a usuarios internos o externos. Sin
estos procedimientos, los datos se pueden perder o pueden ser robados y
usados para fines fraudulentos.
9.7 Lleve un control estricto sobre la distribucin interna o
externa de cualquier tipo de medios que contenga
datos de titulares de tarjetas, incluidos:
9.7.1 Clasifique los medios de manera que se Es posible que los medios que no se identifican como confidenciales no
puedan identificar como confidenciales. reciban el cuidado que requieren, de madera pueden ser robados o se pueden
perder. Incluya un proceso de clasificacin de medios en los procedimientos
que se recomiendan en el Requisito 9.6.
9.7.2 Enve los medios por correo seguro u otro Si los medios son enviados a travs de un mtodo que no se puede rastrear,
mtodo de envo que se pueda rastrear con como el correo postal comn, pueden ser robados o los pueden robar. Use los
precisin. servicios de un correo seguro para entregar todos los medios que contienen
datos de titulares de tarjetas, a fin de poder usar los sistemas de rastreo para
tener un inventario y poder ubicar los envos.
9.8 Asegrese de que la gerencia apruebe todos y cada Los datos de titulares de tarjetas que salen de reas seguras sin un proceso
uno de los medios que contengan datos de titulares de aprobado por la gerencia pueden perderse o es posible que los roben. Sin un
tarjetas que se muevan desde un rea segura proceso firme, no se rastrean las ubicaciones de los medios ni existe un
(especialmente cuando se los distribuye a personas). procedimiento para saber dnde van los datos o cmo se protegen. Incluya la
creacin de un proceso aprobado por la gerencia para mover los medios en
los procedimientos que se recomiendan en el Requisito 9.6.
9.9 Lleve un control estricto sobre el almacenamiento y la Sin mtodos de inventarios y controles de almacenamiento cuidadosos, los
accesibilidad de los medios que contengan datos de medios robados o perdidos pueden pasar inadvertidos durante un perodo de
titulares de tarjetas. tiempo indefinido. Incluya el desarrollo de un proceso para limitar el acceso a
los medios con datos de titulares de tarjetas en los procedimientos que se
recomiendan en el Requisito 9.6.
9.9.1 Lleve registros de inventario adecuadamente Si no se realiza un inventario de los medios, los que se pierden o son robados
de todos los medios y realice inventarios de pueden pasar inadvertidos durante un largo tiempo. Incluya la creacin de un
medios anualmente como mnimo. proceso para inventarios de medios y almacenamiento seguro en los
procedimientos que se recomiendan en el Requisito 9.6.
Requisito Gua
9.10 Destruya los medios que contengan datos de titulares Si no se toman medidas para destruir la informacin que se almacena en los
de tarjetas cuando ya no sea necesario para la empresa discos duros de las computadoras, en los CD y en papel, la disposicin de esa
o por motivos legales, de la siguiente manera: informacin puede ocasionar riesgos y provocar prdidas econmicas o de
reputacin. Por ejemplo, personas malintencionadas pueden usar una tcnica
9.10.1 Corte en tiras, incinere o haga pasta los
conocida como buscar en la basura, en donde buscan en contenedores de
materiales de copias en papel para que no se basura y papeleras de reciclaje y usan la informacin que encuentran para
puedan reconstruir los datos de titulares de lanzar un ataque. Incluya el desarrollo de una proceso para destruir los
tarjetas.
medios con datos de titulares de tarjetas, incluido el almacenamiento
9.10.2 Entregue los datos de titulares de tarjetas en adecuado de estos medios antes de su destruccin, en los procedimientos
dispositivos electrnicos no recuperables para que se recomiendan en el Requisito 9.6.
que dichos datos no se puedan reconstruir.
Gua para los requisitos 10 y 11: Supervise y pruebe las redes con regularidad
Requisito 10: Rastree y supervise los accesos a los recursos de red y a los datos de los titulares de las tarjetas
Los mecanismos de registro y la posibilidad de rastrear las actividades del usuario son crticos para la prevencin, deteccin o minimizacin del
impacto de los riesgos de datos. La presencia de los registros en todos los entornos permite el rastreo, alertas y anlisis cuando algo no funciona
bien. La determinacin de la causa de algn riesgo es muy difcil sin los registros de la actividad del sistema.
Requisito Gua
10.1 Establezca un proceso para vincular todos los accesos Es fundamental tener un proceso o un sistema que vincule el acceso de los
a componentes del sistema (especialmente el acceso usuarios con los componentes del sistema a los que se ha accedido y, en
con privilegios administrativos, tales como de raz) a particular, para esos usuarios con privilegios administrativos. Este sistema
cada usuario en particular. genera registros de auditora y ofrece la posibilidad de realizar un seguimiento
de las actividades sospechosas de un usuario especfico. Los equipos
forenses posincidentes dependen mucho de estos registros para comenzar su
investigacin.
10.2 Implemente pistas de auditora automatizadas para En general, las personas malintencionadas que entran en la red efectan
todos los componentes del sistema a fin de reconstruir muchos intentos para acceder a los sistemas objetivos. La generacin de
los siguientes eventos: pistas de auditora de las actividades sospechosas alerta al administrador del
10.2.1 Todo acceso de personas a datos de titulares sistema, enva datos a otros mecanismos de monitorizacin (como los
de tarjetas sistemas de deteccin de intrusiones) y ofrece un historial de pistas para un
seguimiento posincidente.
10.2.2 Todas las acciones realizadas por personas
con privilegios de raz o administrativos
10.2.3 Acceso a todas las pistas de auditora
10.2.4 Intentos de acceso lgico no vlidos
10.2.5 Uso de mecanismos de identificacin y
autenticacin
10.2.6 Inicializacin de los registros de auditora
10.2.7 Creacin y eliminacin de objetos en el nivel
del sistema.
Requisito Gua
10.3 Registre al menos las siguientes entradas de pistas de Si registra estas entradas para los eventos auditables de 10.2, cualquier
auditora de los componentes del sistema para cada posibilidad de riesgo puede identificarse rpidamente y con suficientes
evento: detalles como para saber quin fue, qu hizo, dnde lo hizo y cmo lo hizo.
10.3.1 Identificacin de usuarios
10.3.2 Tipo de evento
10.3.3 Fecha y hora
10.3.4 Indicacin de xito u omisin
10.3.5 Origen del evento
10.3.6 Identidad o nombre de los datos,
componentes del sistema o recurso afectados
10.4 Sincronice todos los relojes y horarios crticos del En general, si un individuo malintencionado ingresa en la red, intenta cambiar
sistema. los sellos de fecha de sus acciones dentro de los registros de auditora para
impedir que detecten su actividad. Para los equipos forenses posincidentes, la
hora de cada actividad es esencial para determinar cmo se puso en riesgo
los sistemas. Una persona malintencionada tambin puede intentar cambiar
directamente el reloj de un servidor de hora, si las restricciones de acceso no
son las apropiadas, para volver a colocar la hora que haba antes de que el
individuo malintencionado ingresara a la red.
10.5 Resguarde las pistas de auditora para evitar que se Por lo general, un individuo malintencionado que ingresa a una red intenta
modifiquen. editar los registros de auditora par ocultar su actividad Sin la proteccin
adecuada de los registros de auditora, no se puede garantizar su integridad ni
exactitud, y los registros de auditora pueden resultar intiles como
herramienta de investigacin despus de que han estado en riesgo.
10.5.1 Limite la visualizacin de pistas de auditora a La proteccin adecuada de los registros de auditora incluye un fuerte control
quienes lo necesiten por motivos de trabajo. de acceso (acceso limitado a registros slo en base a la necesidad de
10.5.2 Proteja los archivos de las pistas de auditora conocer) y el uso de segregacin interna (para hacer que los registros sean
contra las modificaciones no autorizadas. ms difciles de encontrar y modificar). Si los registros se escriben desde
tecnologas externas como inalmbricas, firewalls, DNS y servidores de
10.5.3 Realice copias de seguridad de los archivos
correo, se reduce el riesgo de que esos registros se pierdan o se alteren, ya
de las pistas de auditora de inmediato en un
que son ms seguros dentro de la red interna.
servidor de registros central o medios que
resulten difciles de modificar.
10.5.4 Escriba registros para tecnologas externas
en un servidor de registros en la LAN interna.
Requisito Gua
10.5.5 Utilice el software de monitorizacin de Los sistemas de monitorizacin de integridad de archivos verifican los
integridad de archivos y de deteccin de cambios que se realizan en los archivos importantes y notifican cuando se
cambios en registros para asegurarse de que observan esos cambios. A los fines de la monitorizacin de integridad de
los datos de los registros existentes no se archivos, una entidad generalmente monitorea los archivos que no se
puedan cambiar sin que se generen alertas modifican regularmente, pero que cuando se modifican indican un posible
(aunque el hecho de agregar nuevos datos no riesgo. En el caso de los archivos de registro (que no cambian con
deba generar una alerta). frecuencia), lo que debe monitorearse es, por ejemplo, cuando se elimina un
archivo, las disminuciones o los aumentos repentinos y cualquier otro
indicador de que un individuo malintencionado ha alterado un archivo de
registro. Existen herramientas de forma estndar y de cdigo abierto
disponibles para la monitorizacin de integridad de archivos.
10.6 Revise los registros de todos los componentes del Existen fallos que son detectados das o meses despus. Verificar los
sistema al menos una vez al da. Las revisiones de registros a diario reduce la cantidad de tiempo y exposicin de un posible
registros incluyen a los servidores que realizan riesgo. Los procesos de revisin de registro no necesariamente deben ser
funciones de seguridad, tales como sistema de manuales. Especialmente en el caso de las entidades con una gran cantidad
deteccin de intrusiones (IDS) y servidores de de servidores, considere el uso de herramientas de recoleccin, anlisis y
autenticacin, autorizacin y contabilidad (AAA) (por alerta de registros.
ejemplo, RADIUS).
Nota: las herramientas de recoleccin, anlisis y alerta
de registros pueden ser utilizadas para cumplir con el
requisito 10.6.
10.7 Conserve el historial de pista de auditoras durante al La conservacin de registros durante al menos un ao es importante, ya que,
menos un ao, con un mnimo de tres meses en general, transcurre cierto tiempo antes de que se detecte un riesgo, y esto
inmediatamente disponible para el anlisis (por permite a los investigadores contar con un historial de registros lo
ejemplo, en lnea, archivado o recuperable para la suficientemente grande para determinar mejor el tiempo de un posible fallo y
realizacin de copias de seguridad). los posibles sistemas afectados. Si una entidad tiene tres meses de registros
inmediatamente disponibles, puede identificar rpidamente el fallo de datos y
minimizar su impacto. El almacenamiento de cintas de respaldo en un lugar
externo a la empresa puede hacer que se necesite ms tiempo para
restablecer los datos, realizar anlisis e identificar los sistemas o datos que
han sido afectados.
Requisito 11: Pruebe los sistemas y procesos de seguridad regularmente
Las vulnerabilidades ocasionadas por personas malintencionadas e investigadores se descubren continuamente, y se introducen mediante
software nuevo. Los componentes, procesos y software personalizado del sistema se deben probar con frecuencia para garantizar que los
controles de seguridad continen reflejando un entorno dinmico.
Requisito Gua
11.1 Las pruebas para comprobar la presencia de puntos de La implementacin y explotacin de tecnologa inalmbrica dentro de una red
acceso inalmbricos mediante el uso de un analizador es una de las vas ms comunes para que los usuarios malintencionados
inalmbrico al menos trimestralmente o la obtengan acceso a la red y a los datos de titulares de tarjetas. Si se instala
implementacin de un sistema de deteccin de una red o un dispositivo inalmbrico sin que la empresa sepa, un atacante
intrusiones (IDS)/sistema contra intrusos (IPS) puede ingresar a la red fcilmente y de manera invisible. Adems de
inalmbrico para identificar todos los dispositivos analizadores inalmbricos, se pueden usar anlisis de puertos y otras
inalmbricos en uso. herramientas de red que detectan dispositivos inalmbricos.
Debido a la facilidad con la que un punto de acceso inalmbrico puede
conectarse a una red, la dificultad para detectar su presencia y el gran riesgo
que presentan los dispositivos inalmbricos no autorizados, estos anlisis
deben realizarse incluso cuando existe una poltica que prohbe el uso de
tecnologa inalmbrica.
Una organizacin debe tener, como parte de su plan de respuesta a
incidentes, procedimientos documentados para seguir en caso de que se
detecte un punto de acceso inalmbrico no autorizado. Se debe configurar un
IDS/IPS inalmbrico para que automticamente genere una alerta, pero el
plan tambin debe documentar procedimientos de respuesta si se detecta un
dispositivo no autorizado durante un anlisis inalmbrico manual.
11.2 Realice anlisis internos y externos de vulnerabilidades Un anlisis de vulnerabilidades es una herramienta automtica que se utiliza
de red al menos trimestralmente y despus de cada en servidores y dispositivos de red internos y externos, y est diseada para
cambio significativo en la red (tales como instalaciones exponer posibles vulnerabilidades e identificar puertos en redes que personas
de componentes del sistema, cambios en la topologa malintencionadas pueden hallar y explotar. Una vez que estas debilidades son
de red, modificaciones en las normas de firewall, identificadas, la entidad las corrige y repite el anlisis para verificar que las
actualizaciones de productos). vulnerabilidades se hayan corregido.
Nota: los anlisis trimestrales de vulnerabilidades externas En el momento de una evaluacin inicial de PCI DSS en una entidad, es
debe realizarlos un Proveedor Aprobado de Escaneo (ASV) posible que an no se hayan realizado cuatro anlisis trimestrales. Si el
certificado por el Consejo de Normas de Seguridad de la resultado del anlisis ms reciente cumple con los criterios de un anlisis
Industria de Tarjetas de Pago (PCI SSC). Los anlisis aprobado y se han implementado polticas y procedimientos para futuros
realizados despus de cambios en la red puede realizarlos el anlisis trimestrales, el objetivo de este requisito se ha logrado. No es
personal interno de la empresa. necesario demorar una evaluacin implementada para este requisito por la
falta de cuatro anlisis si se cumplen estas condiciones.
Requisito Gua
11.3 Realice pruebas de penetracin externas e internas al Las pruebas de penetracin de la red y aplicacin son diferentes de los
menos una vez al ao y despus de cualquier anlisis de vulnerabilidades porque las pruebas de penetracin son ms
actualizacin o modificacin significativa de manuales, intentan explotar algunas de las vulnerabilidades que se identifican
infraestructuras o aplicaciones (como por ejemplo la en los anlisis e incluyen tcnicas que usan las personas malintencionadas
actualizacin del sistema operativo, la adicin de una para aprovechar los procesos o sistemas de seguridad dbiles.
subred al entorno, o la adicin de un servidor Web al Antes de que las aplicaciones, los dispositivos de red y los sistemas se
entorno). Estas pruebas de penetracin deben incluir lo comiencen a producir, deben fortalecerse y asegurarse con las mejores
siguiente: prcticas de seguridad (segn el Requisito 2.2). Los anlisis de
11.3.1 Pruebas de penetracin de la capa de red vulnerabilidades y las pruebas de penetracin exponen todas las
11.3.2 Pruebas de penetracin de la capa de aplicacin. vulnerabilidades que quedan y que un atacante puede encontrar y explotar.
11.4 Utilice los sistemas de deteccin y/o prevencin de Estas herramientas comparan el trnsito que ingresa a la red con firmas
intrusiones para supervisar el trfico en el entorno de conocidas de miles de tipos de riesgos (herramientas de hackers, troyanos y
datos de titulares de tarjetas y alerte al personal ante la otro malware) y envan alertas o detienen el intento mientras se produce. Sin
sospecha de riesgos. Mantenga actualizados todos los un enfoque proactivo para la deteccin de actividades no autorizadas a travs
motores de deteccin y prevencin de intrusiones. de estas herramientas, los ataques a recursos informticos (o su mal uso)
pueden pasar inadvertidos en tiempo real. Las alertas de seguridad que
generan estas herramientas pueden monitorearse para que los intentos de
intrusiones puedan detenerse.
Existen miles de tipos de riesgos y, a diario, se descubren muchos ms. Las
versiones obsoletas de estos sistemas no tendrn firmas actualizadas y no
identificarn nuevas vulnerabilidades que pueden provocar un fallo no
detectado. Los proveedores de estos productos suministran actualizaciones
con frecuencia o, incluso, diariamente.
11.5 Implemente el software de monitorizacin de integridad Los sistemas de monitorizacin de integridad de archivos verifican los
de archivos para alertar al personal ante modificaciones cambios que se realizan a los archivos importantes y notifican cuando se
no autorizadas de archivos crticos del sistema, archivos detectan esos cambios. Existen herramientas de forma estndar y de cdigo
de configuracin o archivos de contenido; asimismo abierto disponibles para la monitorizacin de integridad de archivos. Si la
configure el software para realizar comparaciones de monitorizacin de integridad de archivos no se implementa correctamente y no
archivos crticos al menos semanalmente. se controla su resultado, un individuo malintencionado puede alterar el
Nota: a los fines de la monitorizacin de integridad de contenido de los archivos de configuracin, los programas de los sistemas
archivos, los archivos crticos generalmente son los operativos o los ejecutables de aplicaciones. Si no se detectan estos cambios
que no se modifican con regularidad, pero cuya no autorizados, los controles de seguridad existentes pueden ser ineficientes
modificacin podra indicar un riesgo o peligro para el o es posible que se roben los datos de titulares de tarjetas sin un impacto
sistema. Los productos para la monitorizacin de perceptible en el procesamiento normal.
integridad de archivos generalmente vienen
preconfigurados con archivos crticos para el sistema
operativo relacionado. La entidad (es decir el
comerciante o el proveedor de servicios) debe evaluar
y definir otros archivos crticos, tales como los archivos
para aplicaciones personalizadas.
Gua para el requisito 12: Mantenga una poltica de seguridad de informacin
Requisito 12: Mantenga una poltica que aborde la seguridad de la informacin para empleados y contratistas.
Una poltica de seguridad slida establece el grado de seguridad para toda la empresa e informa a los empleados lo que se espera de ellos.
Todos los empleados deben estar al tanto de la confidencialidad de los datos y de su responsabilidad para protegerlos. A los fines de este
requisito, empleados se refiere a personal de tiempo completo y parcial, personal temporal, y contratistas y consultores que residan en las
instalaciones de la empresa.
Requisito Gua
12.1 Establezca, publique, mantenga y distribuya una La poltica de seguridad de la informacin de una empresa crea un plan de
poltica de seguridad que logre lo siguiente: accin para implementar medidas de seguridad para proteger su activo ms
12.1.1 Aborde todos los requisitos de PCI DSS. valioso. Una poltica de seguridad slida establece el grado de seguridad para
toda la empresa e informa a los empleados lo que se espera de ellos. Todos
12.1.2 Incluya un proceso anual que identifique las
los empleados deben estar al tanto de la confidencialidad de los datos y de su
amenazas, y vulnerabilidades, y los resultados
responsabilidad para protegerlos.
en una evaluacin formal de riesgos.
Las amenazas de seguridad y los mtodos de proteccin evolucionan
12.1.3 Incluya una revisin al menos una vez al ao
rpidamente durante el ao. Si la poltica de seguridad no se actualiza para
y actualizaciones al modificarse el entorno.
reflejar estos cambios, no se implementarn nuevas medidas de proteccin
para luchar contra estas amenazas.
12.2 Desarrolle procedimientos diarios de seguridad Los procedimientos de seguridad operativa funcionan como instrucciones de
operativa coherentes con los requisitos de esta escritorio para que los trabajadores usen en sus actividades cotidianas de
especificacin (por ejemplo, procedimientos de mantenimiento y administracin de sistemas. Los procedimientos de seguridad
mantenimiento de cuentas de usuarios y operativa no documentados conducen a trabajadores que no conocen al
procedimientos de revisin de registros). alcance total de sus tareas, procesos que los trabajadores no pueden repetir
fcilmente y posibles brechas en estos procesos que pueden permitir a una
persona malintencionada obtener acceso a recursos y sistemas importantes.
Requisito Gua
12.3 Desarrolle polticas de utilizacin para tecnologas Las polticas de utilizacin de los empleados pueden prohibir ciertos
crticas para empleados (por ejemplo, tecnologas de dispositivos y otras tecnologas, si es parte de la poltica de la empresa, u
acceso remoto, tecnologas inalmbricas, dispositivos ofrecer orientacin para los empleados respecto al correcto uso y la
electrnicos extrables, computadoras porttiles, implementacin. Si no se implementan polticas de uso, los empleados
asistentes digitales/para datos personales [PDA], pueden usar la tecnologa para violar la poltica de la empresa y, as, permitir
utilizacin del correo electrnico Internet) para definir el a personas malintencionadas obtener acceso a sistemas importantes y datos
uso adecuado de dichas tecnologas por parte de de titulares de tarjetas. Un ejemplo puede ser configurar, sin saberlo, redes
empleados y contratistas. Asegrese de que estas inalmbricas sin seguridad. Para garantizar que se sigan las normas de la
polticas de uso requieran lo siguiente: empresa y que slo se implemente la tecnologa aprobada, considere limitar la
implementacin slo a equipos de operaciones y no permitir que empleados
generales/no especializados instalen esta tecnologa.
12.3.1 Aprobacin explcita de la gerencia Si no se requiere la correcta aprobacin de la gerencia para la implementacin
de estas tecnologas, un empleado puede, de manera inocente, implementar
una solucin para una necesidad percibida de la empresa, pero tambin
puede abrir un gran agujero que somete a datos y sistemas importantes a
personas malintencionadas.
12.3.2 Autenticacin para el uso de la tecnologa Si la tecnologa se implementa sin una autenticacin correcta (ID de usuario y
contrasea, tokens, VPN, etc.), los individuos malintencionados pueden usar
fcilmente esta tecnologa no protegida para acceder a datos de titulares de
tarjetas y sistemas importantes.
12.3.3 Lista de todos los dispositivos y personal que Las personas malintencionadas pueden poner en peligro la seguridad fsica y
tenga acceso colocar sus propios dispositivos en la red como puerta trasera. Los
empleados tambin pueden omitir procedimientos e instalar dispositivos. Un
12.3.4 Etiquetado de dispositivos con propietario,
inventario preciso con un etiquetado adecuado de los dispositivos permite una
informacin de contacto y objetivo
rpida identificacin de las instalaciones no aprobadas. Considere establecer
una convencin de nombres oficial para los dispositivos y etiquete y registre
todos los dispositivos conjuntamente con los controles de inventario
establecidos.
12.3.5 Usos aceptables de la tecnologa Si se define el uso y la ubicacin de la tecnologa y los dispositivos aprobados
por la empresa, la empresa est mejor capacitada para administrar y controlar
12.3.6 Ubicaciones aceptables de las tecnologas en
las diferencias de configuracin y los controles operativos, para asegurarse de
la red
que no haya ninguna puerta trasera abierta para que personas
12.3.7 Lista de productos aprobados por la empresa malintencionadas obtengan acceso a sistemas crticos y datos de titulares de
tarjetas.
Requisito Gua
12.3.8 Desconexin automtica de sesiones para La tecnologa de acceso remoto es una puerta trasera frecuente para los
tecnologas de acceso remoto despus de un datos de titulares de tarjetas y los recursos importantes. Si se desconecta la
perodo especfico de inactividad tecnologa de acceso remoto cuando no se utiliza (por ejemplo, la que se usa
para que los POS u otros proveedores realicen el soporte de sus sistemas) se
12.3.9 Activacin de tecnologas de acceso remoto
reduce el acceso y el riesgo que corren las redes. Considere el uso de
para proveedores slo cuando estos lo
controles para desconectar los dispositivos despus de 15 minutos de
requieren, con desactivacin automtica inactividad. Consulte tambin el Requisito 8.5.6 para obtener ms informacin
despus de la utilizacin sobre este tema.
12.3.10 Al tener acceso remoto a datos de titulares de Para estar seguro de que sus empleados conocen sus responsabilidades con
tarjetas mediante tecnologas de acceso remoto, respecto a no almacenar ni copiar datos de titulares de tarjetas en su
prohba copiar, mover y almacenar los datos de computadora personal local o en otros medios, su empresa debe tener una
titulares de tarjetas en unidades de disco locales poltica que prohba claramente esas actividades.
y dispositivos electrnicos extrables.
12.4 Asegrese de que las polticas y los procedimientos de Sin responsabilidades y roles de seguridad claramente definidos y asignados,
seguridad definan claramente las responsabilidades de puede haber una interaccin contradictoria con el grupo de seguridad, lo que
seguridad de la informacin de todos los empleados y puede ocasionar una implementacin no segura de tecnologa o el uso de
contratistas. tecnologa no segura u obsoleta.
12.5 Asigne las siguientes responsabilidades de gestin de Cada persona o equipo con responsabilidades en la gestin de seguridad de
seguridad de la informacin a una persona o a un la informacin debe saber muy bien sus responsabilidades y tareas
equipo: relacionadas, a travs de una poltica especfica. Sin esta responsabilidad, las
12.5.1 Establezca, documente y distribuya polticas y diferencias en los procesos pueden permitir el acceso a datos de titulares de
procedimientos de seguridad. tarjetas y recursos importantes.
12.5.2 Supervise y analice las alertas e informacin
de seguridad, y distribyalas entre el personal
correspondiente.
12.5.3 Establezca, documente y distribuya los
procedimientos de respuesta ante incidentes
de seguridad y escalacmiento para garantizar
un manejo oportuno y efectivo de todas las
situaciones.
12.5.4 Administre las cuentas de usuario, incluidas
las adiciones, eliminaciones y modificaciones.
12.5.5 Supervise y controle todo acceso a datos.
Requisito Gua
12.6 Implemente un programa formal de concienciacin Si no se ensea a los usuarios a ser responsables de la seguridad, los
sobre seguridad para que todos los empleados tomen procesos y garantas de seguridad que se han implementado pueden ser
conciencia de la importancia de la seguridad de los ineficientes debido a acciones intencionales o errores de los empleados.
datos de titulares de tarjetas.
12.6.1 Eduque a los empleados al contratarlos y al Si el programa formal de concienciacin no incluye sesiones de actualizacin
menos una vez al ao. anuales, los procedimientos y procesos de seguridad de claves pueden
olvidarse u omitirse, lo que hace que los datos de titulares de tarjetas y los
recursos importantes queden expuestos.
12.6.2 Exija a los empleados que reconozcan al La solicitud a los empleados de un reconocimiento (por ejemplo: por escrito o
menos una vez al ao haber ledo y entendido de forma electrnica) ayuda a garantizar que hayan ledo y comprendido los
la poltica y los procedimientos de seguridad procedimientos y las polticas de seguridad y que se han comprometido a
de la empresa. cumplir con estas polticas.
12.7 Examine a los posibles empleados (consulte la La realizacin de investigaciones minuciosas antes de contratar empleados a
definicin de empleados en 9.2 ms arriba) antes de quienes se les dar acceso a datos de titulares de tarjetas reduce el riesgo del
contratarlos a los fines de minimizar el riesgo de uso no autorizado de PAN y de otros datos de titulares de tarjetas por parte de
ataques provenientes de orgenes internos. personas con antecedentes criminales o cuestionables. Se supone que una
En el caso de empleados tales como cajeros de un empresa debe tener una poltica y un proceso para el control de antecedentes,
comercio, que slo tienen acceso a un nmero de incluido su propio proceso de decisiones para el que los resultados del control
tarjeta a la vez al realizarse una transaccin, este de antecedentes tienen incidencia en las decisiones al momento de contratar
requisito constituye slo una recomendacin. personal (y cul es ese impacto).
12.8 Si los datos de titulares de tarjeta se comparten con Si un comerciante o proveedor de servicios comparte datos de titulares de
proveedores de servicios, mantenga e implemente tarjetas con un proveedor de servicios, entonces se aplican ciertos requisitos
polticas y procedimientos a los fines de que los para garantizar que estos proveedores de servicios respeten una proteccin
proveedores de servicio incluyan lo siguiente: constante de estos datos.
12.8.1 Mantenga una lista de proveedores de Saber quines son los proveedores de servicios permite identificar dnde se
servicios. extiende el posible riesgo hacia afuera de la organizacin.
12.8.2 Mantenga un acuerdo escrito que incluya una El reconocimiento de los proveedores de servicios demuestra su compromiso
mencin de que los proveedores de servicios de mantener la seguridad adecuada de los datos de titulares de tarjetas que
son responsables de la seguridad de los obtienen de los clientes y, por ende, los hace responsables.
datos de titulares de tarjetas que ellos tienen
en su poder.
Requisito Gua
12.8.3 Asegrese de que exista un proceso establecido El proceso garantiza que la organizacin investigue minuciosamente a nivel
para comprometer a los proveedores de interno todo compromiso de un proveedor de servicios; esta investigacin
servicios que incluya una auditora de compra debe incluir un anlisis de los riesgos antes de establecer una relacin formal
adecuada previa al compromiso. con el proveedor de servicios.
12.8.4 Mantenga un programa para supervisar el Conocer el estado de cumplimiento con las PCI DSS de un proveedor de
estado de cumplimiento con las PCI DSS del servicios ofrece mayor garanta de que cumple con los mismos requisitos a los
proveedor de servicios. que est sujeta una organizacin.
12.9 Implemente un plan de respuesta a incidentes. Sin un plan meticuloso de respuesta a incidentes de seguridad que las partes
Preprese para responder de inmediato ante un fallo responsables reciban, lean y comprendan de manera adecuada, la confusin
en el sistema. y la falta de una respuesta unificada puede provocar ms tiempo de
inactividad para la empresa, exposicin innecesaria a los medios pblicos y
nuevas responsabilidades legales.
12.9.1 Cree el plan de respuesta a incidentes que El plan de respuesta a incidentes debe ser meticuloso y debe contener todos
se va a implementar en caso de fallos en el los elementos clave para permitir a su empresa responder de manera eficaz
sistema. Asegrese de que el plan aborde, en caso de que se produzca un fallo que pueda afectar los datos de titulares
como mnimo, lo siguiente: de tarjetas.
Funciones, responsabilidades y estrategias
de comunicacin y contacto en caso de un
riesgo que incluya, como mnimo, la
notificacin de las marcas de pago.
Procedimientos especficos de respuesta
a incidentes.
Procedimientos de recuperacin y
continuidad comercial.
procesos de realizacin de copia de
seguridad de datos;
Anlisis de los requisitos legales para el
informe de riesgos.
Cobertura y respuestas de todos los
componentes crticos del sistema.
referencia o inclusin de procedimientos
de respuesta a incidentes de las marcas
de pago.
Requisito Gua
12.9.2 Pruebe el plan al menos una vez al ao. Sin una prueba adecuada, es posible que se pierdan pasos clave que limitan
la exposicin durante un incidente.
12.9.3 Designe personal especializado que se Sin un equipo de respuesta a incidentes capacitado y disponible, se puede
encuentre disponible permanentemente para producir un gran dao a la red y es posible que se contaminen datos y
responder a las alertas. sistemas importantes debido al manejo no apropiado de los sistemas objetivos.
Esto puede dificultar el xito de una investigacin posincidente. Si no cuenta
12.9.4 Proporcione capacitacin adecuada al
con recursos internos disponibles, considere contratar un proveedor que le
personal sobre las responsabilidades de ofrezca estos servicios.
respuesta ante fallos de seguridad.
12.9.5 Incluya alertas de sistemas de deteccin y Estos sistemas de monitorizacin estn diseados para concentrarse en los
prevencin de intrusiones, y de monitorizacin posibles riesgos para los datos. Son esenciales para tomar medidas rpidas para
de integridad de archivos. impedir fallos y deben incluirse en los procesos de respuesta a incidentes.
12.9.6 Elabore un proceso para modificar y desarrollar La incorporacin de las lecciones aprendidas en el plan de respuesta a
el plan de respuesta a incidentes segn las incidentes ayuda a mantener el plan actualizado y capaz de reaccionar ante
lecciones aprendidas, e incorporar los las nuevas emergentes y tendencias de seguridad.
desarrollos de la industria.
Gua para el requisito A.1: Requisitos de las PCI DSS adicionales para proveedores de hosting
compartido
Requisito A.1: Los proveedores de hosting compartidos protegen el entorno de datos de titulares de tarjetas
Tal como se menciona en el Requisito 12.8, todos los proveedores de servicios con acceso a datos de titulares de tarjetas (incluidos los
proveedores de hosting compartido) deben adherirse a PCI DSS. Adems, el requisito 2.4 establece que los proveedores de hosting compartido
deben proteger el entorno y los datos que aloja cada entidad. Por lo tanto, los proveedores de hosting compartido deben cumplir adems con los
requisitos de este Anexo.
Requisito Gua
A.1 Proteger el entorno y los datos alojados de cada El Anexo A de las PCI DSS est pensado para los proveedores de hosting
entidad (es decir comerciante, proveedor de servicio u compartido que desean ofrecer a los clientes de su proveedor de servicios o
otra entidad), segn A.1.1 a A.1.4: comerciante un entorno de hosting que cumpla con las PCI DSS. Adems de
Un proveedor de hosting debe cumplir con estos todos los otros requisitos relevantes de las PCI DSS, deben cumplirse estos
requisitos, as como tambin con las dems secciones pasos.
correspondientes de PCI DSS.
Nota: aunque posiblemente el proveedor de hosting
cumpla con estos requisitos, no se garantiza el
cumplimiento de la entidad que utiliza al proveedor de
hosting. Cada entidad debe cumplir con las PCI DSS y
validar el cumplimiento segn corresponda.
A.1.1 Asegrese de que cada entidad slo lleve a Si un comerciante o un proveedor de servicios puede ejecutar sus propias
cabo procesos con acceso al entorno de aplicaciones en el servidor compartido, estas aplicaciones debern ejecutarse
datos de titulares de tarjetas de la entidad. con el ID de usuario del comerciante o del proveedor de servicios, en vez de
como usuario privilegiado. Un usuario privilegiado tendra acceso a todos los
otros entornos de datos de titulares de tarjetas de los proveedores de
servicios y comerciantes y tambin a los datos propios.
Requisito Gua
A.1.2 Restrinja el acceso y los privilegios de cada Para garantizar que el acceso y los privilegios sean limitados, de manera que
entidad para que slo contengan el entorno un comerciante o un proveedor de servicios slo tenga acceso a su propio
de datos de titulares de tarjetas. entorno de datos de titulares de tarjetas, considere lo siguiente: (1) privilegios
del ID de usuario del servidor web del comerciante o del proveedor de
servicios; (2) permisos otorgados para leer, escribir y ejecutar los archivos; (3)
permisos otorgados para escribir en binarios compartidos; (4) permisos
otorgados a los archivos de registro de los proveedores de servicio y
comerciantes, y (5) controles para asegurar que un comerciante o proveedor
de servicios no pueda monopolizar los recursos del sistema.
A.1.3 Asegrese de que los registros y las pistas de Los registros deben estar disponibles en un entorno de hosting compartido,
auditora estn habilitados y sean exclusivos para que los comerciantes y los proveedores de servicios puedan acceder a
para el entorno de datos de titulares de ellos y puedan revisar los registros especficos de su entorno de datos de
tarjetas de cada entidad, as como tambin titulares de tarjetas.
que cumplan con el Requisito 10 de las PCI
DSS.
A.1.4 Habilite los procesos para proporcionar una Los proveedores de hosting compartido deben tener procesos para ofrecer
investigacin forense oportuna en caso de una respuesta rpida y simple en caso de que se necesite una investigacin
riesgos para un comerciante o proveedor de forense para un riesgo y deban llegar al nivel de detalle apropiado de manera
servicios alojado. que la informacin de un comerciante o de un proveedor de servicios en
particular est disponible.
Anexo A: Normas de seguridad de datos de la PCI: documentos relacionados
Los siguientes documentos fueron creados para ayudar a los comerciantes y a los proveedores de servicios a comprender las Normas de
seguridad de datos de la PCI y las responsabilidades y los requisitos de cumplimiento.
Documento Destinatarios
Requisitos de normas de seguridad de datos de la PCI y procedimientos de Todos los comerciantes y proveedores de servicios
evaluacin de seguridad
Exploracin de PCI DSS: Comprensin del objetivo de los requisitos Todos los comerciantes y proveedores de servicios
Normas de seguridad de datos de la PCI: Instrucciones y directrices del Todos los comerciantes y proveedores de servicios
cuestionario de autoevaluacin
10
Normas de seguridad de datos de la PCI: Declaracin y cuestionario de Comerciantes
autoevaluacin A
10
autoevaluacin B
10
autoevaluacin C
10
Normas de seguridad de datos de la PCI: Declaracin y cuestionario de Comerciantes y todos los proveedores de servicios
autoevaluacin D
Glosario de trminos, abreviaturas y acrnimos de las PCI DSS Todos los comerciantes y proveedores de servicios
10
Para determinar el Cuestionario de Autoevaluacin apropiado, consulte las Normas de seguridad de datos de la PCI: Instrucciones y directrices
del cuestionario de autoevaluacin, Seleccin del SAC y de la declaracin que mejor se adapta a su organizacin".

Pci Dss Saq Navigating Dss PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Pci Dss Saq Navigating Dss PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Normas de Seguridad de Datos

de la Industria de Tarjetas de Pago (PCI DSS)

Fecha Versin Descripcin

Modificaciones realizadas a los documentos ....................................................................................................................i

Desarrollar y mantener una red segura

Proteja los datos del titular de la tarjeta

Desarrolle un programa de administracin de vulnerabilidad

Requisito 5: Utilice un software antivirus y actualcelo regularmente

Implemente medidas slidas de control de acceso

Supervise y pruebe las redes con regularidad

Mantenga una poltica de seguridad de informacin

Requisito 12: Mantenga una poltica que aborde la seguridad de la informacin

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

Você também pode gostar