Entendiendo la Intención de los Requisitos

(1)

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

Cómo Navegar a través de las

Normas de Seguridad de Datos de la Industria de Tarjetas de Pago

Entendiendo la Intención de los Requisitos

Versión 1.1

Febrero 2008

(2)

Contenido

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

Ubicación de los Datos de los Tarjetahabientes y Datos Confidenciales de Autenticación ... v

Datos de la Pista 1 y Datos de la Pista 2 ... vi

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

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

Requisito 1: Instalar y mantener una configuración de cortafuegos para proteger los datos de los tarjetahabientes ... 3

Requisito 2: No usar contraseñas del sistema y otros parámetros de seguridad provistos por los suplidores ... 9

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

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

Requisito 4: Encriptar los datos de los tarjetahabientes e información confidencial transmitida a través de redes públicas abiertas ... 18

Orientaciones para los Requisitos 5 and 6: Mantener un Programa de Manejo de Vulnerabilidad ... 20

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

Requisito 6: Desarrollar y mantener sistemas y aplicaciones seguros ... Error! Bookmark not defined. Orientaciones para los Requisitos 7, 8 y 9: Implementar Medidas Sólidas de Control de Acceso ... 26

Requisito 7: Restringir el acceso a los datos de los tarjetahabientes tomando como base la necesidad del funcionario de conocer la información ... 26

Requisito 8: Asignar una identificación única a cada persona que tenga acceso a un computador ... 27

Requisito 9: Restringir el acceso físico a los datos de los tarjetahabientes... 32

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

Requisito 10: Rastrear y monitorear todo el acceso a los recursos de la red y datos de los tarjetahabientes ... 36

Requisito 11: Probar regularmente los sistemas y procesos de seguridad ... 40

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

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

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

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

(3)

Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Febrero 2008

Prefacio

Este documento describe los doce requisitos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) y ofrece orientaciones que explican la intención de cada requisito. La intención de este documento es asistir a los comercios, proveedores de servicio e instituciones financieras que deseen llegar a un entendimiento más claro de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago, el significado y la intención específica que hay detrás de cada requisito detallado para garantizar la seguridad de los componentes de sistemas (servidores, redes, aplicaciones, etc.), que brindan soporte a los ambientes de datos de tarjetahabientes.

NOTA: Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Entendiendo la Intención de los Requisitos es un documento que sólo se deberá usar para fines de orientación. Al realizar auditorías in situ o completar el

Cuestionario de Autoevaluación (SAQ), los documentos oficiales a utilizar son las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS), versión 1.1, los Procedimientos de Auditoría de Seguridad de Normas de Seguridad de Datos de la Industria de Tarjetas de Pago, y los Cuestionarios de Autoevaluación, versión 1.1.

Los requisitos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago se aplican a todos los componentes de sistemas que están incluidos en el ambiente de datos de los tarjetahabientes o conectados al mismo. El ambiente de datos de los tarjetahabientes es la parte de la red que posee los datos de los tarjetahabientes o los datos confidenciales de autenticación, incluyendo los componentes de red, los servidores y las aplicaciones.

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

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

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

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

https://www.pcisecuritystandards.org/pdfs/pci_qsa_list.pdf

(4)

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

La tabla que aparece a continuación ilustra los elementos de datos confidenciales de los tarjetahabientes y de autenticación que normalmente se usan, e indica si se permite o se prohíbe guardar cada elemento de datos y si se requiere proteger cada elemento de datos. Esta tabla no es exhaustiva, pero se presenta únicamente con el fin de ilustrar los distintos tipos de requisitos que se aplican a cada elemento de datos.

Los datos de los tarjetahabientes se definen como el número de cuenta primario (“PAN” o número de la tarjeta de crédito) y otros datos que se obtienen al realizar una transacción de pago, incluyendo los siguientes elementos de datos (vea la tabla que sigue para más detalles):

PAN o Número de Cuenta Primario

Nombre del Tarjetahabiente

Fecha de Vencimiento

Código de Servicio

 Datos Confidenciales de Autenticación (1) todos los datos de la banda magnética, 2) CAV2/CVC2/CVV2/CID, y 3) PINes/bloques de PIN) El Número de Cuenta Primario (PAN) es el factor que define la aplicabilidad de los requisitos de las Normas de Seguridad de Datos de la

Industria de Tarjetas de Pago (PCI DSS) y PA-DSS. Si no se guarda, procesa o transmite el Número de Cuenta Primario, estas normas no aplican.

(5)

Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Febrero 2008 Elemento de Datos

Se Permite Guardar

Protección

Requerida PCI DSS Req. 3, 4

Datos de los Tarjetahabientes

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

Nombre del Tarjetahabiente¹ Sí Sí ¹ No

Código de Servicio¹ Sí Sí ¹ No

Fecha de Vencimiento¹ Sí Sí ¹ No

Datos Confidenciales de Autenticación ²

Contenido de la Banda

Magnética¹ No N/A N/A

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

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

1 Se requiere proteger estos elementos de datos si se guardan junto con el Número de Cuenta Primario (PAN). Esta protección debe cumplir con los requisitos establecidos en las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) para la protección general del ambiente de tarjetahabientes.

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

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

(6)

Ubicación de los Datos de los Tarjetahabientes y Datos Confidenciales de Autenticación

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

3 Los datos codificados en la banda magnética se usan para fines de autorización durante una transacción con tarjeta presente. Las entidades no pueden retener los datos completos de la banda magnética después de autorizada la transacción. Los únicos elementos de datos de la pista que se pueden retener son el número de cuenta, la fecha de vencimiento y el nombre.

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

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

(7)

Datos de la Pista 1 y Pista 2

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

(8)

Pista 1 Pista 2

Contiene todos los campos de las pistas 1 y 2

Longitud de hasta 79 caracteres

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

Longitud de hasta 40 caracteres

(9)

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

Desarrollar y Mantener una Red Segura

Requisito 1: Instalar y mantener una configuración de cortafuegos para proteger los datos de los tarjetahabientes.

Requisito 2: No usar contraseñas del sistema y otros parámetros de seguridad provistos por los suplidores.

Proteger los Datos de los Tarjetahabientes

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

Requisito 4: Encriptar los datos de los tarjetahabientes e información confidencial transmitida a través de redes públicas abiertas.

Mantener un Programa de Manejo de Vulnerabilidad

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

Requisito 6: Desarrollar y mantener sistemas y aplicaciones seguros.

Implementar Medidas Sólidas de Control de Acceso

Requisito 7: Restringir el acceso a los datos tomando como base la necesidad del funcionario de conocer la información.

Requisito 8: Asignar una Identificación única a cada persona que tenga acceso a un computador.

Requisito 9: Restringir el acceso físico a los datos de los tarjetahabientes.

Monitorear y Probar Regularmente las Redes

Requisito 10: Rastrear y monitorear todo el acceso a los recursos de la red y datos de los tarjetahabientes.

Requisito 11: Probar regularmente los sistemas y procesos de seguridad.

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

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

(10)

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

Requisito 1: Instalar y mantener una configuración de cortafuegos para proteger los datos de los tarjetahabientes.

Los cortafuegos son dispositivos computarizados que controlan el tráfico permitido a y desde una red de computadores de una compañía, así como el tráfico a áreas vulnerables de la red interna de una compañía. El cortafuego examina todo el tráfico de la red y bloquea las transmisiones que no cumplen con los criterios de seguridad especificados.

Es necesario proteger todos los sistemas contra el acceso no autorizado desde Internet, sea para fines de comercio electrónico, acceso a Internet de los empleados a través de los navegadores de los computadores de escritorio o acceso al correo electrónico de los empleados. Con

frecuencia algunas vías de conexión hacia y desde Internet aparentemente insignificantes pueden proporcionar un acceso sin protección a sistemas clave. Los cortafuegos son un mecanismo de protección esencial para cualquier red de computadores.

Requisito Orientación

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

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

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

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

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

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

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

Utilizar un cortafuego en cada conexión hacia y desde la red permite a la organización monitorear y controlar el acceso hacia dentro y hacia fuera de la red y minimizar las probabilidades de que un delincuente cibernético obtenga acceso a la red interna.

1.1.4 Descripción de grupos, roles y

responsabilidades para una administración lógica de los componentes de la red.

La descripción de los roles y la asignación de responsabilidades aseguran que alguien sea claramente responsable por la seguridad de todos los

componentes y esté consciente de los mismos, y que ningún dispositivo quede sin administrar.

(11)

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

Los compromisos de la seguridad frecuentemente ocurren debido a servicios y puertos que no se usan o no tienen seguridad, ya que estos a menudo tienen vulnerabilidades conocidas y muchas organizaciones no instalan los parches de seguridad en el caso de los servicios y puertos que no usan (aunque las vulnerabilidades estén presentes). Cada organización debe decidir claramente cuáles servicios y puertos son necesarios para operar su negocio,

documentarlos para que quede un registro de los mismos, y asegurar que todos los demás servicios y puertos se desactiven o eliminen. Igualmente, las organizaciones deben considerar un bloqueo de todo el tráfico y solamente volver a abrir esos puertos cuando se haya determinado y documentado la necesidad de utilizar los mismos.

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

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

Existen muchos protocolos que una empresa podría necesitar (o que están activados por defecto) y que los delincuentes cibernéticos normalmente utilizan para comprometer la seguridad de una red. Además de la explicación sobre el 1.1.5, si es necesario utilizar protocolos riesgosos para el negocio, la organización debe entender claramente y aceptar el riesgo que esos

protocolos significan para la empresa, el uso del protocolo debe estar justificado y las características de seguridad que permiten usar estos protocolos en forma segura deben estar documentadas e implementadas.

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

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

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

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

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

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

(12)

Requisito Orientación públicamente accesibles y cualquier componente de

sistemas que guarde datos de los tarjetahabientes, incluyendo cualquier conexión de redes inalámbricas.

Esta configuración de cortafuegos debe incluir lo siguiente:

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

Normalmente un paquete contiene la dirección IP del computador que originalmente lo envió. Esto permite que otros computadores de la red sepan de dónde vino. En ciertos casos los delincuentes cibernéticos falsifican esta dirección IP remitente.

Por ejemplo, el delincuente envía un paquete con una dirección falsa para que (a menos que su cortafuego lo prohíba) el paquete pueda entrar a la red de la empresa desde Internet como si fuera tráfico interno, y, por lo tanto, legítimo.

Una vez que el delincuente ha penetrado la red puede comenzar a comprometer la seguridad de los sistemas de la empresa.

Los filtros de ingreso son una técnica que puede usar en su cortafuego para filtrar los paquetes que entran a su red y, entre otras cosas, asegurar que los paquetes no se hayan falsificado para fingir que vienen de su propia red interna.

Para obtener más información sobre los filtros de paquetes, considere obtener información sobre una técnica complementaria llamada “filtros de egreso”.

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

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

“establecidas”).

Un cortafuego que realiza una inspección completa mantiene el “estado” (o

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

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

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

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

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

(13)

de tarjetahabientes. autorizada o que usen servicios, protocolos y puertos en forma no autorizada (por ejemplo, para enviar datos que hayan obtenido dentro de su red a un servidor externo).

1.3.6 Asegurar y sincronizar los archivos de configuración de ruteador. Por ejemplo, los archivos de configuración (para el

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

Aunque los archivos de configuración activos normalmente se implementan con parámetros de seguridad, los archivos de inicio (los ruteadores sólo ejecutan estos archivos al reinicio) podrían no estar implementados con los mismos parámetros seguros porque solamente se ejecutan ocasionalmente.

Cuando un ruteador se reinicia sin los mismos parámetros de seguridad que tienen los archivos de configuración, ello podría traer como resultado un debilitamiento de las reglas que permitiría a un delincuente cibernético penetrar la red.

(14)

Requisito Orientación 1.3.7 Rechazar todo el tráfico entrante y saliente

de Internet que no esté específicamente permitido.

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

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

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

inalámbrica podrían fácilmente conectarse con el ambiente de tarjetas de pago y comprometer la seguridad de la información de las cuentas.

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

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

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

La intención del cortafuego es administrar y controlar todas las conexiones entre los sistemas públicos y los sistemas internos (especialmente aquellos sistemas que guardan datos de los tarjetahabientes). Si se permite un acceso directo entre los sistemas públicos y los que almacenan datos de los

tarjetahabientes, las protecciones que ofrece el cortafuego se pasan por alto y la seguridad de los componentes de sistemas que guardan datos de los tarjetahabientes podría verse comprometida.

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

El DMZ es la parte del cortafuego que queda frente a la red pública, Internet, y administra las conexiones entre Internet y los servicios internos que una organización necesita tener a disposición del público (como, por ejemplo, un servidor de Web). Es la primera línea de defensa para aislar y separar el tráfico que necesita comunicarse con la red interna del tráfico que no necesita esta comunicación.

(15)

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

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

1.5 Implementar máscaras de IP para prevenir que las direcciones internas se traduzcan y revelen en Internet.

Usar tecnologías que implementan el espacio de dirección RFC 1918 tales como Port Address Translation (PAT) o Network Address Translation (NAT).

La implementación de máscaras de IP, que son administradas por el cortafuego, permite a la organización tener direcciones internas que

solamente son visibles dentro de la red y direcciones externas que sólo son visibles externamente. Si un cortafuego no “oculta” o enmascara las

direcciones de IP de la red interna, es posible que un delincuente cibernético descubra las direcciones de IP de la red interna e intente acceder a la red con una dirección de IP falsa.

(16)

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

Los delincuentes que roban datos de computadores—comúnmente llamados “hackers” o delincuentes cibernéticos, y que pueden ser externos o internos en una compañía—a menudo usan las contraseñas y otras opciones automáticamente programadas por los proveedores para

comprometer la seguridad de los sistemas. Estas contraseñas y opciones son bien conocidas entre los delincuentes y fácilmente se determinan por medio de información pública.

2.1 Cambiar siempre los valores por defecto de los proveedores antes de instalar un sistema en la red (por ejemplo, incluir contraseñas, cadenas

comunitarias SNMP (Simple Network Management Protocol), y eliminar cuentas innecesarias).

Los delincuentes cibernéticos (externos e internos en una compañía) frecuentemente utilizan los valores, nombres de cuenta y contraseñas por defecto de los proveedores para comprometer la seguridad de los sistemas.

Estos valores por defecto son bien conocidos por los delincuentes y hacen que el sistema de su organización sea altamente vulnerable a un ataque.

2.1.1 En los ambientes inalámbricos, cambiar los valores por defecto programados por los vendedores del equipo inalámbrico, incluyendo, sin limitación, claves Wireless Equivalent Privacy (WEP), Service Set Identifier (SSID) de selección automática, contraseñas y cadenas comunitarias SNMP.

Deshabilitar transmisores SSID. Habilitar la tecnología Wi-Fi Protected Access (WPA y WPA2) para la encriptación y la autenticación cuando exista capacidad WPA.

Muchos usuarios instalan estos dispositivos sin aprobación de la administración y no cambian los valores por defecto ni configuran los parámetros de seguridad. Si no se implementan las redes inalámbricas con suficientes configuraciones de seguridad (inluyendo el cambio de valores por defecto) los “sniffers” que espían las redes inalámbricas podrían espiar el tráfico, fácilmente capturar datos y contraseñas y penetrar y atacar su red.

Además, el protocolo de cambio de claves de la versión 802.11x Encryption (WEP) más antigua ha sido descifrado y puede inutilizar la encriptación.

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

Existen debilidades conocidas en muchos sistemas operativos, bases de datos y aplicaciones empresariales y también existen formas conocidas de configurar estos sistemas para subsanar las vulnerabilidades de seguridad. A fin de ayudar a los que no son expertos en seguridad, las firmas

especializadas en seguridad han establecido recomendaciones para aumentar la seguridad de los sistemas, las cuales sirven de asesoría para corregir estas debilidades. Si estas debilidades de los sistemas no se subsanan—por ejemplo, parámetros débiles de archivos o servicios y protocolos por defecto (para los servicios y protocolos que no se usan a menudo)—un atacante podrá usar muchas de estas debilidades conocidas para atacar los servicios y protocolos vulnerables y obtener así acceso a la red de su organización.

(17)

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

separados).

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

1. Una base de datos que necesita tener medidas de alta seguridad

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

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

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

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

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

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

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

2.2.4 Eliminar todas las funcionalidades innecesarias, tales como archivos de

comandos (scripts), accionadores, funciones, subsistemas, sistemas de archivos y

servidores de Web innecesarios.

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

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

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

(18)

Requisito Orientación 2.4 Los proveedores de servicio de hospedaje Web deben

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

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

(19)

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

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

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

3.1 Mantener un mínimo de datos de tarjetahabientes almacenados. Desarrollar una política de retención de datos y una política para disponer de los datos. Limitar la cantidad de datos almacenados y el tiempo de retención a los que se requieren para fines

comerciales, legales y/o regulatorios, según se haya documentado en la política de retención de datos.

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

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

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

Los datos confidenciales de autenticación son los datos de la banda

magnética (o pista)⁶, el código de validación o valor de la tarjeta⁷, y los datos del PIN⁸. Está prohibido guardar los datos confidenciales de

autenticación. Estos datos son muy valiosos para los delincuentes, ya que les permite fabricar tarjetas de pago falsas y generar transacciones

fraudulentas. Vea el documento titulado Glosario, Abreviaturas y Acrónimos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago para obtener la definición completa de los “datos confidenciales de autenticación”.

6 Los datos codificados en la banda magnética se usan para procesar la autorización durante una transacción con tarjeta presente. Las entidades no pueden retener los datos completos de la banda magnética después que la transacción se autoriza. Los únicos elementos de datos de la pista que se pueden retener son el número de cuenta, la fecha de vencimiento y el nombre.

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

8El número de identificación personal (PIN) que marca el tarjetahabiente durante una transacción con tarjeta presente y/o el bloque de PIN encriptado presente dentro del mensaje de transacción.

(20)

Requisito Orientación 3.2.1 No guardar el contenido íntegro de ninguna

pista de banda magnética (en el reverso de una tarjeta, en un chip, o en cualquier otro lugar). Estos datos alternativamente se conocen como pista completa, pista 1, pista, pista 2 y datos de la banda magnética.

En el curso normal de los negocios es posible que sea necesario retener los siguientes elementos de datos de la banda magnética: el nombre del titular de la cuenta, el número de cuenta primario o PAN, la fecha de

vencimiento y el código de servicio. A fin de minimizar el riesgo, guarde solamente aquellos elementos de datos que se necesiten por razones de negocio. NUNCA guarde el código de verificación de tarjeta o elementos de verificación de PIN.

Nota: Vea el documento titulado “Glosario, Abreviaturas y Acrónimos” de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago para obtener información adicional.

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

3.2.2 No guardar el valor o código de validación de tarjeta (número de tres o cuatro dígitos impreso en el anverso o reverso de una tarjeta de pago) utilizado para verificar las transacciones con tarjeta ausente.

Nota: Vea el documento titulado “Glosario, Abreviaturas y Acrónimos” de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago para obtener información adicional.

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

almacenaje de este valor también viola los reglamentos de las marcas de pago y puede conducir a multas y penalidades.

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

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

(21)

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

3.3 Enmascarar los números de cuenta cuando se desplieguen (los primeros seis y los últimos cuatro dígitos son el número máximo de dígitos que se puede desplegar).

(Nota: Este requisito no se aplica a empleados y otras entidades que tienen específicamente necesidad de ver el Número de Cuenta Primario, ni supersede los requisitos más estrictos establecidos para el

despliegue de datos de los tarjetahabientes (por ejemplo, en recibos de terminales de punto de venta [POS]).

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

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

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

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

(22)

• Números truncados La intención del requisito de truncar el número de cuenta es guardar

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

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

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

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

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

La información MÍNIMA sobre las cuentas que necesita estar en forma ilegible es el número de cuenta de la tarjeta de pago.

Si por alguna razón una compañía no puede encriptar los datos de los tarjetahabientes, consulte el Apéndice B: “Controles Compensatorios” en las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago.

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

La intención de este requisito es contemplar si la encriptación de disco es aceptable para lograr que los datos de los tarjetahabientes queden ilegibles.

La encriptación de disco encripta los datos guardados en almacenaje masivo en un computador y automáticamente decripta la información cuando un usuario autorizado lo solicita. Los sistemas de encriptación de disco interceptan las operaciones de lectura y escritura del sistema operativo y llevan a cabo las transformaciones criptográficas apropiadas sin ninguna acción específica o especial del usuario, con la excepción de proporcionar una contraseña o frase en clave al comenzar la sesión. Dadas estas

características de la encriptación de disco, para cumplir con este requisito el

(23)

método de encriptación de disco no puede tener:

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

2) Claves de decriptación que estén asociadas con las cuentas de los usuarios.

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

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

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

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

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

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

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

La forma en que se administran las claves de encriptación es crítica para la continua seguridad de la solución de encriptación. Un buen proceso de

administración de claves, sea manual o automatizado como parte del producto de encriptación, contempla todos los elementos clave de los requisitos 3.6.1 a 3.6.10.

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

seguridad”.

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

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

(24)

Requisito Orientación 3.6.4 Cambio periódico de claves

• Según se considere necesario y lo recomiende la aplicación asociada (por ejemplo volver a digitar las claves), preferiblemente en forma automática

• Al menos anualmente.

Si el proveedor de la aplicación de encriptación los ha proporcionado, siga sus procesos y recomendaciones para cambiar periódicamente las claves.

Es esencial cambiar anualmente las claves de encriptación para minimizar el riesgo de que alguien las obtenga y pueda decriptar los datos.

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

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

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

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

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

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

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

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

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

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

(25)

Cómo Navegar a través de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago: Febrero 2008 Requisito 4: Encriptar los datos e información confidencial de los tarjetahabientes transmitida a través de redes públicas abiertas.

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

4.1 Usar criptografía y protocolos de alta seguridad como Secure Sockets Layer (SSL)/Transport Layer Security (TLS) e Internet Protocol Security (IPSEC) para salvaguardar los datos confidenciales de los tarjetahabientes durante su transmisión a través de redes públicas abiertas.

Ejemplos de redes públicas abiertas que caen dentro del alcance de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago son Internet, WiFi (IEEE 802.11x), Global System for Mobile

Communications (GSM), y General Packet Radio Service (GPRS).

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

(26)

Requisito Orientación 4.1.1 En el caso de las redes inalámbricas que

transmitan datos de los tarjetahabientes, encriptar las transmisiones usando la tecnología Wi-Fi Protected Access (WPA o WPA2), IPSEC VPN, o SSL/TLS. Nunca depender

exclusivamente de Wired Equivalent Privacy (WEP) para proteger el carácter confidencial y el acceso a una red de acceso local (LAN)

inalámbrica:

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

inicialización de 24 bits.

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

• Rotar trimestralmente (o

automáticamente si la tecnología lo permite) las claves WEP compartidas.

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

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

Los delincuentes cibernéticos utilizan herramientas que se obtienen en forma gratuita y están fácilmente disponibles para espiar las comunicaciones inalámbricas. El uso apropiado de la encriptación puede evitar este tipo de espionaje y la divulgación de la información confidencial a través de la red. En muchas ocasiones en que solamente la seguridad de los datos de los

tarjetahabientes almacenados en la red alámbrica se ha visto comprometida el origen del compromiso de la seguridad fue que el delincuente logró el acceso desde una red inalámbrica. No se debe usar nunca la encriptación con WEP por sí sola, ya que es vulnerable debido a vectores iniciales débiles (IV) en el proceso de intercambio de claves WEP, y carece de la rotación requerida de claves. Un atacante podría utilizar libremente herramientas de penetración con fuerza bruta para penetrar la encriptación WEP.

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

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

(27)

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

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

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

5.1 Implementar software antivirus en todos los sistemas comúnmente afectados por virus (particularmente computadores personales y servidores).

Nota: Los sistemas comúnmente afectados por virus típicamente no incluyen los sistemas operativos basados en UNIX o mainframes.

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

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

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

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

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

(28)

Requisito 6: Desarrollar y mantener sistemas y aplicaciones seguros.

Las personas sin escrúpulos utilizan las vulnerabilidades en la seguridad para obtener acceso privilegiado a los sistemas. Muchas de estas vulnerabilidades se pueden subsanar mediante parches de seguridad desarrollados por los proveedores. Todos los sistemas deben contar con los parches de software apropiados y más recientes para estar protegidos contra la explotación por parte de empleados, delincuentes externos y virus. Nota: Los parches de software apropiados son aquellos que han sido suficientemente evaluados y probados para determinar que no crean conflicto con las configuraciones de seguridad existentes. En el caso de las aplicaciones desarrolladas internamente por la institución es posible evitar numerosas vulnerabilidades utilizando los procesos normales de desarrollo de sistemas y técnicas de codificación seguras.

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

Hay un considerable número de ataques utilizando debilidades ampliamente divulgadas y publicadas, a menudo “0 días” (es decir, con menos de una hora de publicadas) contra sistemas que en lo demás son seguros. Si no se

implementan los parches más recientes en los sistemas lo más pronto posible, un delincuente puede aprovechar esas debilidades para lanzar un ataque y deshabilitar la red. Considere asignar prioridad a los cambios, de forma que los parches de seguridad en los sistemas críticos o en riesgo se instalen dentro de un plazo de 30 días y otros cambios en sistemas menos riesgosos tengan menos prioridad.

6.2 Establecer un proceso para identificar las vulnerabilidades de seguridad recientemente

descubiertas (por ejemplo, suscribirse a los servicios de alerta disponibles en forma gratuita a través de Internet). Actualizar sus normas para subsanar cualquier nuevo problema de vulnerabilidad que pudiera surgir.

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

6.3 Desarrollar aplicaciones de software basadas en las mejores prácticas de la industria e incorporar la

seguridad de la información a través de todo el ciclo de desarrollo de software.

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

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

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

(29)

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

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

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

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

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

Los controles de seguridad normalmente no son tan estrictos en el ambiente de desarrollo. El uso de datos de producción da a los delincuentes

cibernéticos, así como a los que desarrollan software, la oportunidad de obtener acceso no autorizado a la información de producción.

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

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

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

Las cuentas, nombres de usuarios y contraseñas de las aplicaciones individuales deben eliminarse del código de producción antes que la

aplicación se active o ponga a disposición de los clientes, ya que estos datos pueden dar a conocer información referente al funcionamiento de la

aplicación. La posesión de esa información podría facilitar el compromiso de la seguridad de la aplicación y los datos de los tarjetahabientes relacionados.

6.3.7 Revisar los códigos individuales antes de ponerlos en producción o a disposición de los clientes, a fin de identificar cualquier

vulnerabilidad relacionada con la codificación.

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