navigating dss v2

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

Comprensin del objetivo de los requisitos Versin 2.0

Octubre de 2010

Navegacin de las PCI DSS: Comprensin del objetivo de los requisitos, versin 2.0 Octubre de 2010 Copyright 2010, PCI Security Standards Council LLC Pgina 2

Modificaciones realizadas a los documentos Fecha Versin Descripcin

1 de octubre de 2008 1.2

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

28 de octubre de 2010 2.0 Alinear contenido con la nueva versin 2.0 de las PCI DSS.


ndice

Modificaciones realizadas a los documentos...................................................................................................................2 Prefacio................................................................................................................................................................................4

Virtualizacin ........................................................................................................................................................................................................... 5

Elementos de datos de titulares de tarjetas y de datos confidenciales de autenticacin............................................6 Ubicacin de datos de titulares de tarjetas y de datos confidenciales de autenticacin ........................................................................................ 8 Datos de la pista 1 vs. pista 2.................................................................................................................................................................................. 9

Gua relacionada por las Normas de Seguridad de Datos de la PCI.............................................................................10 Gua para los Requisitos 1 y 2: Desarrollar y mantener una red segura......................................................................11

Requisito 1: Instalar y mantener una configuracin de firewall para proteger los datos del titular de la tarjeta ................................................... 11 Requisito 2: No usar los valores predeterminados suministrados por el proveedor para las contraseas del sistema y otros parmetros de seguridad ............................................................................................................................................................................................................... 17

Gua para los Requisitos 3 y 4: Proteja los datos del titular de la tarjeta ....................................................................20 Requisito 3: Proteja los datos del titular de la tarjeta que fueron almacenados ................................................................................................... 20 Requisito 4: Cifrar la transmisin de los datos del titular de la tarjeta en las redes pblicas abiertas. ................................................................ 28

Gua para los Requisitos 5 y 6: Mantener un programa de administracin de vulnerabilidad ..................................30 Requisito 5: Utilice y actualice regularmente el software o los programas antivirus ............................................................................................ 30 Requisito 6: Desarrolle y mantenga sistemas y aplicaciones seguras ................................................................................................................. 32

Gua para los Requisitos 7, 8 y 9: Implemente medidas slidas de control de acceso..............................................40 Requisito 7: Restrinja el acceso a los datos del titular de la tarjeta segn la necesidad de saber que tenga la empresa................................... 40 Requisito 8: Asignar una ID exclusiva a cada persona que tenga acceso por computadora............................................................................... 42 Requisito 9: Restrinja el acceso fsico a los datos del titular de la tarjeta............................................................................................................. 47

Gua para los Requisitos 10 y 11: Supervise y evale las redes con regularidad.......................................................51 Requisito 10: Rastree y supervise todos los accesos a los recursos de red y a los datos de los titulares de las tarjetas................................... 51 Requisito 11: Probar peridicamente los sistemas y procesos de seguridad....................................................................................................... 55

Gua para los Requisitos 12: Mantenga una poltica de seguridad de informacin....................................................61 Requisito 12: Mantener una poltica que trate la seguridad de la informacin para todo el personal .................................................................. 61

Gua para el requisito A.1: Requisitos de las PCI DSS adicionales para proveedores de hosting compartido .......67 Anexo A: Norma de seguridad de datos de la PCI: Documentos relacionados ......................................................69


Prefacio Este documento describe los 12 requisitos de las Normas de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS), al tiempo que proporciona orientacin para explicar el objetivo de cada requisito. El objetivo de este documento es ayudar a comerciantes, proveedores de servicios e instituciones financieras que pudieran necesitar comprender ms claramente la Norma de Seguridad de Datos de la Industria de Tarjetas de Pago, as como el significado y objetivo especficos de los requisitos detallados para asegurar los componentes de sistemas (servidores, red, aplicaciones, etc.) que respaldan los entornos de datos de los titulares de tarjetas. NOTA: Navegacin de las PCI DSS: La comprensin del objetivo de los requisitos es slo para efectos de gua. Cuando se finaliza una evaluacin in situ de las PCI DSS o un Cuestionario de Autoevaluacin (SAQ), los Requisitos de las PCI DSS y los Procedimientos de Evaluacin de Seguridad y los Cuestionarios de Autoevaluacin de las PCI DSS 2.0 son documentos de registro. Los requisitos de las PCI DSS se aplican a todos los componentes del sistema. En el contexto de las PCI DSS, los "componentes del sistema" se definen como cualquier componente de red, servidor o aplicacin que est incluida en el entorno de los datos del titular de la tarjeta o que est conectado a ste. Los componentes del sistema tambin incluyen cualesquiera componentes de virtualizacin tales como mquinas virtuales, switches/routers virtuales, dispositivos virtuales, aplicaciones/escritorios virtuales e hipervisores. El entorno de los datos de los titulares de tarjetas consta de personas, procesos y tecnologa que manipulan datos de titulares de tarjetas o datos confidenciales de autenticacin.

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

Los tipos de servidores incluyen, a modo de ejemplo: web, aplicacin, base de datos, autenticacin, correo electrnico, proxy, protocolo de tiempo de red (NTP) y servidor de nombre de dominio (DNS).

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

El primer paso de una evaluacin de las PCI DSS es determinar con exactitud el alcance de la revisin. Por lo menos una vez al ao y antes de la evaluacin anual, la entidad evaluada debera confirmar la exactitud del alcance de las PCI DSS al identificar todas las ubicaciones y los flujos de datos de titulares de tarjetas y al asegurar que se incluyan en el alcance de las PCI DSS. Para confirmar la exactitud e idoneidad del alcance de las PCI DSS, realice lo siguiente:

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

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

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

La entidad retiene la documentacin que demuestre los resultados y cmo se confirm el alcance de las PCI DSS para la revisin por parte de los asesores y/o como referencia durante la actividad anual de la siguiente confirmacin de alcance de las PCI SCC.


La segmentacin de red, o separacin (segmentacin), del entorno de los datos del titular de la tarjeta del resto de la red corporativa de una entidad no constituye un requisito de las PCI DSS. Sin embargo, constituye un mtodo ampliamente recomendado que puede reducir el alcance del entorno de datos de los titulares de tarjetas. Un Asesor de Seguridad Calificado (QSA) puede ayudar a determinar el alcance dentro del entorno de datos de los titulares de tarjetas de una entidad, adems de proporcionar orientacin sobre cmo reducir el alcance de una evaluacin de las PCI DSS al implementar una segmentacin apropiada de la red. En lo que se refiere a las preguntas sobre si una implementacin especfica concuerda con la norma o cumple con un requisito especfico, el PCI SSC recomienda a las compaas consultar a un QSA para validar su implementacin de tecnologa y procesos, as como el cumplimiento de las Normas de Seguridad de Datos de la PCI. La experiencia que tienen los QSA trabajando en entornos de red complejos ayuda a proporcionar mejores prcticas y orientacin al comerciante o proveedor de servicios que intenta lograr el cumplimiento. La lista de Asesores de Seguridad Calificados del PCI SSC est disponible en: https://www.pcisecuritystandards.org.

Virtualizacin Si la virtualizacin est implementada, todos los componentes dentro del entorno virtual se debern identificar y considerar en el alcance de la revisin, incluidos hosts o dispositivos virtuales individuales, mquinas husped, aplicaciones, interfaces de administracin, consolas de administracin centrales, hipervisores, etc. Todas las comunicaciones y flujos de datos dentro del host se deben identificar y documentar, as como todas aquellas entre el componente virtual y otros componentes del sistema. La implementacin de un entorno virtualizado debe cumplir con el objetivo de todos los requisitos, de modo tal que los sistemas virtualizados se puedan concebir efectivamente como una unidad de hardware independiente. Por ejemplo, debe existir una clara segmentacin de funciones y segregacin de redes con diferentes niveles de seguridad; la segmentacin debe impedir compartir los entornos de produccin y prueba/desarrollo; la configuracin virtual se debe asegurar de modo tal que las vulnerabilidades de una funcin no puedan afectar la seguridad de otras funciones; y los dispositivos conectados, tales como dispositivos USB/en serie, no deberan ser accesibles por todas las instancias virtuales. Adicionalmente, todos los protocolos de interfaces de administracin virtuales se deben incluir en la documentacin del sistema, adems, los roles y permisos se deben definir para administrar redes virtuales y componentes de sistemas virtuales. Las plataformas de virtualizacin deben estar en capacidad de exigir la separacin de tareas y menos privilegio para separar la administracin de la red virtual de la administracin del servidor virtual. Cuando se implementan controles de autenticacin, se debe tener especial cuidado para asegurar que los usuarios se autentiquen ante los componentes virtuales apropiados del sistema y para distinguir entre las VM (mquinas virtuales) husped y el hipervisor.


Elementos de datos de titulares de tarjetas y de datos confidenciales de autenticacin Las PCI DSS se aplican donde sea que se almacenen, procesen o transmitan datos de cuentas. Los datos de cuentas constan de los datos de los titulares de tarjetas ms datos confidenciales de autenticacin, como se detalla a continuacin:

Los datos de titulares de tarjetas incluyen: Los datos confidenciales de autenticacin incluyen:

Nmero de cuenta principal (PAN) Nombre del titular de la tarjeta Fecha de vencimiento Cdigo de servicio

Todos los datos de la banda magntica o datos equivalentes que estn en un chip

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

El nmero de cuenta principal es el factor que define la aplicabilidad de los requisitos de las PCI DSS. Los requisitos de las PCI DSS se aplican si se almacena, procesa o transmite un nmero de cuenta principal (PAN). Si un PAN no se almacena ni procesa ni transmite, no se aplican los requisitos de las PCI DSS.

Si el nombre del titular de la tarjeta, el cdigo de servicio y/o la fecha de vencimiento no se almacenan ni procesan ni transmiten con el PAN, ni estn presentes de alguna otra manera en el entorno de datos del titular de la tarjeta, se deben proteger de acuerdo con todos los requisitos de las PCI DSS, a excepcin de los Requisitos 3.3 y 3.4, que slo se aplican al PAN.

Las PCI DSS representan un conjunto mnimo de objetivos de control que puede ser reforzado con leyes y regulaciones locales, regionales y sectoriales. Adems, la legislacin o las regulaciones pueden requerir proteccin especfica de la informacin de identificacin personal u otros elementos de datos (por ejemplo, el nombre del titular de la tarjeta), o definir las prcticas de divulgacin de una entidad en lo que respecta a las informacin de los consumidores. Entre los ejemplos est la legislacin relacionada con la proteccin de los datos de los consumidores, la privacidad, el robo de identidad o la seguridad de los datos. Las PCI DSS no sustituyen las leyes locales ni regionales, las regulaciones del gobierno ni otros requisitos legales.

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


Elemento de datos Almacenamiento

permitido Hace que los datos de la

cuenta almacenados no se puedan leer segn el

Requisito 3.4 Nmero de cuenta principal

(PAN) S S

Nombre del titular de la tarjeta S No Cdigo de servicio S No

Datos del titular de la

tarjeta Fecha de vencimiento S No

Datos completos de la banda magntica 2 No

No se pueden almacenar segn el Requisito 3.2

CAV2/CVC2/CVV2/CID No No se pueden almacenar segn el Requisito 3.2

D

a

t

o

s

d

e

l

a

c

u

e

n

t

a

Datos confidenciales

de autenticacin

1 PIN/Bloqueo de PIN No No se pueden almacenar

segn el Requisito 3.2

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

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

1 No se deben almacenar los datos confidenciales de autenticacin despus de la autorizacin (incluso si estn cifrados).

2 Contenido completo de la pista de banda magntica, datos equivalentes que estn en el chip o en cualquier otro dispositivo.


Ubicacin de datos de titulares de tarjetas y de datos confidenciales de autenticacin Los datos confidenciales de autenticacin constan de los datos de la banda magntica (o pista)3, cdigo o valor de validacin de la tarjeta4, y datos del PIN5. 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 PA-DSS para obtener la definicin completa de datos confidenciales de autenticacin. Las siguientes fotografas del reverso y el frente de una tarjeta de crdito muestran la ubicacin de los datos del titular de la tarjeta y los datos confidenciales de autenticacin.

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

3 Datos codificados en la banda magntica utilizada para la autorizacin durante una transaccin con tarjeta presente. Estos datos tambin se pueden encontrar en un chip, o en

cualquier otra parte de la tarjeta. Es posible que las entidades no retengan todos los datos de banda 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 tarjeta, la fecha de vencimiento y el cdigo de servicio.

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

presente. 5 El nmero de identificacin personal ingresado por el titular de la tarjeta durante una transaccin con tarjeta presente y/o el bloqueo de PIN cifrado presente en el mensaje de la

transaccin.


Datos de la pista 1 vs. pista 2

Si los datos de la pista completa (ya sea la pista 1 o pista 2, de la banda magntica, la imagen de la banda magntica en un chip o en cualquier otro lugar) se almacenan, es posible que las personas malintencionadas que obtengan los datos, los reproduzcan y vendan tarjetas de pago en todo el mundo. El almacenamiento de todos los datos de la pista tambin viola las regulaciones operativas de las marcas de pago y puede acarrear multas y sanciones. La ilustracin de abajo proporciona informacin sobre los datos de la Pista 1 y Pista 2 al describir las diferencias y mostrar el diseo de los datos segn se almacenan en la banda magntica.

Pista 1 Pista 2 Contiene todos los campos de la pista 1 y pista 2 Longitud de hasta 79 caracteres

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

Longitud de hasta 40 caracteres

Nota: El emisor de la tarjeta y/o la marca de la tarjeta de pago definen los campos de Datos discrecionales. Los campos definidos por el agente emisor que contienen datos que el agente emisor/marca de pago considere datos confidenciales de autenticacin pudieran estar incluidos en la porcin de datos discrecionales de la pista, y pudiera ser posible almacenar estos datos particulares bajo circunstancias y condiciones especficas, tal como lo defina el agente emisor/marca de la tarjeta de pago. Sin embargo, ningn dato considerado dato confidencial de autenticacin se puede almacenar despus de la autorizacin, independientemente de si se encuentran en un campo de datos discrecionales o cualquier otro lugar.


Gua relacionada por las Normas de Seguridad de Datos de la PCI

Desarrollar y mantener una red segura

Requisito 1: Instalar y mantener una configuracin de firewall para proteger los datos del titular de la tarjeta Requisito 2: No utilizar contraseas de sistemas y otros parmetros de seguridad provistos por los proveedores

Proteger los datos del titular de la tarjeta Requisito 3: Proteger los datos del titular de la tarjeta que fueron almacenados Requisito 4: Cifrar la transmisin de los datos del titular de la tarjeta en las redes pblicas abiertas Mantener un programa de administracin de vulnerabilidad

Requisito 5: Utilizar y actualizar con regularidad los programas o software antivirus Requisito 6: Desarrollar y mantener sistemas y aplicaciones seguras

Implementar medidas slidas de control de acceso

Requisito 7: Restringir el acceso a los datos de titulares de tarjetas segn la necesidad del negocio Requisito 8: Asignar una ID exclusiva a cada persona que tenga acceso por computadora Requisito 9: Restringir el acceso fsico a los datos del titular de la tarjeta Supervisar y evaluar las redes con regularidad

Requisito 10: Rastrear y supervisar todos los accesos a los recursos de red y a los datos de los titulares de tarjetas Requisito 11: Probar peridicamente los sistemas y procesos de seguridad

Mantener una poltica de seguridad de informacin

Requisito 12: Mantener una poltica que aborde la seguridad de la informacin para todo el personal


Gua para los Requisitos 1 y 2: Desarrollar y mantener una red segura

Requisito 1: Instalar y mantener una configuracin de firewall para proteger los datos del titular de la tarjeta Los firewalls son dispositivos que controlan el trfico computarizado entre las redes (internas) y las redes no confiables (externas) de una entidad, as como el trfico de entrada y salida a reas ms sensibles dentro de las redes internas confidenciales de una entidad. El entorno del titular de la tarjeta es un ejemplo de un rea ms confidencial dentro de la red confiable de una entidad. El firewall examina todo el trfico de la red y bloquea las transmisiones que no cumplen con los criterios de seguridad especificados. Todos los sistemas debe estar protegidos contra el acceso no autorizado desde redes no confiables, ya sea que ingresen al sistema a 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 entre negocios 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 computadores. Otros componentes del sistema pueden funcionar como firewall, siempre y cuando renan los requisitos mnimos correspondientes a firewalls, segn se especifica en el Requisito 1. En las reas donde se utilizan otros componentes del sistema dentro del entorno de datos de los titulares de tarjetas a fin de proporcionar la funcionalidad de firewall, estos dispositivos se deben incluir dentro del alcance y la evaluacin del Requisito 1.

Requisito Gua 1.1 Establezca normas de configuracin para firewall y router que incluyan lo siguiente:

Los firewalls y los routers son componentes clave de la arquitectura que controla la entrada a y la salida de la red. Estos dispositivos son unidades de software o hardware que bloquean el acceso no deseado y administran el acceso autorizado hacia dentro y fuera de la red. Sin las polticas ni los procedimientos implementados para documentar la manera como el personal debe configurar los firewalls y los routers, un negocio podra 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 en la proteccin de sus datos mantenga su solidez. Los entornos virtuales donde los flujos de datos no transitan una red fsica se deben evaluar a fin de asegurar que se logr la segmentacin de red apropiada.

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

Una poltica y un proceso para aprobar y probar todas las conexiones y cambios de los firewalls y los routers ayudarn a prevenir problemas de seguridad causados por una configuracin errnea de la red, del router o del firewall. Los flujos de datos entre mquinas virtuales se deben incluir en la poltica y el proceso.


Requisito Gua 1.1.2 Un diagrama actualizado de la red con todas las conexiones que acceden a los datos de los titulares de tarjetas, incluida toda red inalmbrica

Los diagramas de la red permiten que la organizacin identifique la ubicacin de todos sus dispositivos de red. Adems, el diagrama de la red tambin se puede utilizar para relacionar el flujo de datos de titulares de tarjetas con la red y entre dispositivos individuales para entender en su totalidad el alcance del entorno de datos de los titulares de tarjetas. Sin los diagramas actuales de red y flujo de datos, es posible que se omitan los dispositivos que contienen datos de titulares de tarjetas y se excluyan accidentalmente de los controles de seguridad en capas implementados para las PCI DSS y, por lo tanto, se puedan comprometer. Los diagramas de red y flujo de datos deben incluir componentes de sistemas virtuales y documentar los flujos de datos dentro del host.

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

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

1.1.4 Descripcin de grupos, roles y responsabilidades para una administracin lgica de los componentes de la red

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

1.1.5 Documentacin y justificacin de negocio para la utilizacin de todos los servicios, protocolos y puertos permitidos, incluida la documentacin de funciones de seguridad implementadas en aquellos protocolos que se consideran inseguros. Entre los servicios, protocolos o puertos no seguros se incluyen, a modo de ejemplo, FTP, Telnet, POP3, IMAP y SNMP.

Con frecuencia se producen exposiciones debido a que los servicios y puertos no se utilizan o no son seguros, ya que stos, por lo general, tienen vulnerabilidades conocidas y muchas organizaciones son vulnerables a estos tipos de exposicin porque no implementan parches de seguridad para vulnerabilidades de los servicios, protocolos y puertos que no se utilizan (incluso estando presentes las vulnerabilidades). Cada organizacin debe decidir con claridad cules servicios, protocolos y puertos son necesarios para su negocio, documentarlos para sus registros y asegurar que se inhabiliten o eliminen el resto de los servicios, protocolos y puertos. Adems, las organizaciones deben considerar bloquear todo el trfico y slo volver a abrir esos puertos una vez que se haya determinado o documentado una necesidad. Adicionalmente, hay numerosos servicios, protocolos o puertos que pudiera necesitar un negocio (o tener habilitados por opcin predeterminada) que utilizan habitualmente las personas malintencionadas para comprometer una red. Si estos servicios, protocolos o puertos no seguros son necesarios para el negocio, la organizacin debe entender y aceptar el riesgo que plantea el uso de estos protocolos, adems, se debe justificar el uso del protocolo, as como documentar e implementar las funciones de seguridad que permiten utilizar estos protocolos de manera segura. Si estos servicios, protocolos o puertos no seguros no son necesarios para el negocio, se deben inhabilitar o eliminar.


Requisito Gua 1.1.6 Requisito de la revisin de las normas del firewall y el router, al menos, cada seis meses

Esta revisin brinda a la organizacin la oportunidad de deshacerse de todas las reglas innecesarias, desactualizadas o incorrectas por lo menos cada seis meses y de asegurar que todos los conjuntos de reglas otorguen permiso slo a los servicios y puertos autorizados que coincidan con las justificaciones del negocio. Es recomendable aplicar estas revisiones ms frecuentemente; por ejemplo, mensualmente, a fin de asegurar que los conjuntos de reglas estn actualizados y coincidan con las necesidades del negocio sin tener que abrir agujeros de seguridad ni correr riesgos innecesarios.

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

Nota: Una red no confiable es toda red que es externa a las redes que pertenecen a la entidad en evaluacin y/o que excede la capacidad de control o administracin de la entidad.

Es fundamental instalar proteccin para la red; es decir, un componente de sistema con (como mnimo) capacidad de firewall de inspeccin completa, entre la red interna confiable y otra red no confiable que sea externa y/o fuera de la capacidad de control y administracin de la entidad. No implementar esta medida correctamente significa que la entidad estar expuesta al acceso no autorizado por parte de personas malintencionadas o un software malintencionado. Si se instala la funcionalidad de firewall, pero no tiene reglas que controlen o restrinjan el trfico, es posible que las personas malintencionadas sean capaces de utilizar tcnicas de exploit para detectar vulnerabilidades de protocolos y puertos con el fin de atacar su red.

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

Este requisito busca impedir que personas malintencionadas accedan a la red de la organizacin a travs de direcciones IP no autorizadas o que se utilicen servicios, protocolos o puertos sin autorizacin (por ejemplo, para enviar datos que se hayan obtenido mientras salan de su red hacia un servidor no confiable). Todos los firmales deben incluir una regla que rechace todo el trfico entrante y saliente cuya necesidad no se haya especifico. Esto evitar todos los agujeros inadvertidos que garantizaran la entrada y salida de trfico fortuito y potencialmente peligroso.

1.2.2 Asegure y sincronice los archivos de configuracin de routers.

Si bien los archivos de configuracin en ejecucin por lo general se implementan con parmetros de configuracin seguros, los archivos de inicio (los cuales los routers ejecutan slo al inicio) pueden no implementarse con los mismos parmetros de configuracin seguros, debido a que estos archivos slo se ejecutan ocasionalmente. Cuando un router realiza un reinicio sin los mismos parmetros de configuracin seguros que tienen los archivos de configuracin en ejecucin, pueden producirse reglas ms dbiles que permitan que personas malintencionadas accedan a la red, debido a que es posible que los archivos de inicio no se hayan implementado con los mismos parmetros de configuracin seguros que los archivos de configuracin en ejecucin.


Requisito Gua 1.2.3 Instale firewalls de permetro entre las redes inalmbricas y el entorno de datos del titular de la tarjeta y configure estos firewalls para negar o controlar (en caso de que ese trfico fuera necesario para fines de negocio) todo trfico desde el entorno inalmbrico hacia el entorno del titular de la tarjeta.

La implementacin y explotacin conocida (o desconocida) de tecnologa inalmbrica dentro de una red constituyen una ruta comn para que personas malintencionadas obtengan acceso a la red y a datos de titulares de tarjetas. Si un dispositivo inalmbrico o una red inalmbrica se instala sin el conocimiento de la empresa, una persona malintencionada podra ingresar fcilmente y sin ser vista a la red. Si los firewalls no restringen el acceso al entorno de tarjetas de pago desde las redes inalmbricas, las personas malintencionadas que obtengan acceso no autorizado a la red inalmbrica se pueden conectar fcilmente al entorno de tarjetas de pago y comprometer la informacin de cuentas. Se deben instalar firewalls entre las redes inalmbricas y el CDE, independientemente del propsito del entorno al que est conectado la red inalmbrica. Esto puede incluir, a modo de ejemplo, redes corporativas, comercios, almacenes, etc.

1.3 Prohba el acceso directo pblico entre Internet y todo componente del sistema en el entorno de datos de los titulares de tarjetas.

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

1.3.1 Implemente un DMZ para limitar el trfico entrante slo a aquellos componentes del sistema que proporcionan servicios, protocolos y puertos con acceso pblico autorizado.

El DMZ se refiere a la porcin de la red que administra las conexiones entre Internet (u otras redes no confiables) y los servicios internos que una organizacin necesita poner a la disposicin del pblico (como un servidor web). Es la primera lnea de defensa para aislar y separar el trfico que necesita comunicarse con la red interna del trfico que no lo necesita. El objetivo de esta funcionalidad es impedir que personas malintencionadas accedan a la red de la organizacin a travs de direcciones IP no autorizadas o que se utilicen servicios, protocolos o puertos sin autorizacin.

1.3.2 Restrinja el trfico entrante de Internet a las direcciones IP dentro del DMZ.

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

1.3.3 No permita ninguna conexin directa de entrada o salida de trfico entre Internet y el entorno del titular de la tarjeta.

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


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

Normalmente, un paquete contiene la direccin IP de la computadora desde la cual se envo. Esto permite que otras computadoras en la red sepan el origen del paquete. En algunos casos, las personas malintencionadas suplantarn la direccin IP que se enva. Por ejemplo, las personas malintencionadas envan un paquete con una direccin suplantada, de modo que (a menos que su firewall lo prohba) el paquete pueda ingresar en su red desde Internet hacindose pasar por su trfico interno y, por lo tanto, legtimo. Una vez que la persona malintencionada haya ingresado en su red, sta puede empezar a comprometer su sistema. El filtrado de ingreso es una tcnica que se puede utilizar en el firewall para filtrar paquetes que entran a su red para, entre otras opciones, asegurar que los paquetes no se suplanten para que parezcan que provienen de su propia red interna. Para obtener ms detalles sobre el filtrado de paquetes, considere obtener informacin sobre una tcnica corolario llamada filtrado de egreso.

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

Todo el trfico saliente desde el entorno de datos de titulares de tarjetas se debe evaluar para asegurar que dicho trfico sigue las reglas establecidas y autorizadas. Las conexiones se deben inspeccionar a fin de limitar el trfico slo a las comunicaciones autorizadas (por ejemplo, al limitar direcciones/puertos de origen/destino y/o bloquear contenido). Cuando la conectividad entrante de los entornos no est permitida, las conexiones salientes se pueden realizar a travs de arquitecturas o componentes de sistemas que interrumpen e inspeccionan la conectividad IP.

1.3.6 Implemente la inspeccin completa, tambin conocida como filtrado dinmico de paquetes. (Es decir, slo se permite la entrada a la red de conexiones establecidas).

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

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

Los datos de los titulares de tarjetas requieren la proteccin de informacin de ms alto nivel. Si los datos de los titulares de tarjetas se encuentran en el DMZ, el acceso a esta informacin es ms fcil para un atacante externo, ya que hay menos capas que penetrar. Nota: el objetivo de este requisito no incluye el almacenamiento en una memoria voltil.


Requisito Gua 1.3.8 No divulgue direcciones IP privadas ni informacin de enrutamiento a partes no autorizadas. Nota: Entre los mtodos para ocultar direcciones IP se pueden incluir, a modo de ejemplo: Traduccin de Direccin de Red (NAT) Ubicar servidores que contengan datos de titulares de

tarjetas detrs de servidores proxy/firewalls o cachs de contenido,

Eliminacin o filtrado de anuncios de enrutamiento para redes privadas que emplean direcciones registradas,

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

Restringir la difusin de direcciones IP es esencial para evitar que un hacker adquiera las direcciones IP de la red interna y utilice esa informacin para acceder a la red. Los medios efectivos para cumplir con el objetivo de este requisito puede variar dependiendo de la tecnologa de red especfica utilizada en su entorno. Por ejemplo, los controles utilizados para cumplir con este requisito en el caso de las redes IPv4 difieren de los de las redes IPv6. Una tcnica para evitar que se descubran las direcciones IP en una red IPv4 es implementar la Traduccin de Direccin de Red (NAT). NAT, que generalmente administra el firewall, permite que una organizacin tenga direcciones internas que slo son visibles dentro de la red y direcciones externas que slo son visibles fuera de la red. Si un firewall no oculta o enmascara las direcciones IP de la red interna, una persona malintencionada podra descubrirlas e intentar acceder a la red con una direccin IP suplantada. En el caso de las redes IPv4, el espacio de direcciones RFC1918 est reservado para direcciones internas y no se debera poder enrutar en Internet. Por tal motivo, es preferible para las direcciones IP de redes internas. Sin embargo, las organizaciones pueden tener razones para utilizar un espacio de direcciones que no sea RFC1918 en la red interna. En estas circunstancias, la prevencin de anuncios de enrutamiento u otras tcnicas se deben utilizar para evitar que se difunda el espacio de direcciones internas o se divulgue a partes no autorizadas.

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

Si una computadora no tiene instalado un firewall o programa antivirus, es posible que se descarguen o instalen inadvertidamente spyware, troyanos, virus, gusanos y rootkits (malware). La computadora es incluso ms vulnerable cuando se conecta directamente a Internet y no a travs de un firewall corporativo. Los malware que se cargan en una computadora cuando la conexin no se realiza a travs del firewall corporativo pueden localizar informacin de manera mal intencionada dentro de la red cuando la computadora se vuelva a conectar a la red corporativa. Nota: El objetivo de este requisito se aplica a las computadoras con acceso remoto, independientemente de si pertenecen a los empleados o la empresa. Los sistemas que la poltica corporativa no puede administrar introducen debilidades en el permetro y brindan oportunidades que las personas malintencionadas pueden explotar.


Requisito 2: No usar los valores predeterminados suministrados por el proveedor para las contraseas del sistema y otros parmetros de seguridad Las personas malintencionadas (externas e internas a una entidad), por lo general, utilizan las contraseas predeterminadas por los proveedores y otros parmetros que el proveedor predetermine para comprometer 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 proveedores antes de instalar un sistema en la red, incluidas, a modo de ejemplo, contraseas, cadenas comunitarias de protocolo simple de administracin de red (SNMP) y la eliminacin de cuentas innecesarias.

Las personas malintencionadas (externas e internas a la empresa), por lo general, utilizan contraseas predeterminadas por los proveedores, nombres de cuentas y contraseas para comprometer sistemas. Estos parmetros de configuracin son bien conocidos dentro de las comunidades de hackers y dejan a su sistema sumamente vulnerable a ataques.

2.1.1 En el caso de entornos inalmbricos que estn conectados al entorno de datos del titular de la tarjeta o que transmiten datos del titular de la tarjeta, cambie los valores predeterminados proporcionados por los proveedores, incluidas, a modo de ejemplo, claves de cifrado inalmbricas predeterminadas, contraseas y cadenas comunitarias SNMP.

Muchos usuarios instalan estos dispositivos sin aprobacin de la gerencia y no cambian los parmetros predeterminados ni configuran parmetros de seguridad. Si las redes inalmbricas no se implementan con suficientes configuraciones de seguridad (incluido el cambio de los parmetros predeterminados), los sniffers inalmbricos pueden espiar el trfico, capturar datos y contraseas de manera sencilla e ingresar en su red y atacarla fcilmente. Adems, el protocolo de intercambio de claves de la versin anterior de cifrado 802.11x (WEP) ha sido transgredido y puede inutilizar el cifardo. Verifique que el firmware de los dispositivos est actualizado para admitir protocolos ms seguros (por ejemplo, WPA2).

2.2 Desarrolle normas de configuracin para todos los componentes de sistemas. Asegrese de que estas normas contemplen todas las vulnerabilidades de seguridad conocidas y que concuerden con las normas de alta seguridad de sistema aceptadas en la industria. Entre las fuentes de normas de alta seguridad aceptadas en la industria, se pueden incluir, a modo de ejemplo: Center for Internet Security (CIS) International Organization for Standardization (ISO) SysAdmin Audit Network Security (SANS) National Institute of Standards Technology (NIST)

Existen debilidades conocidas en muchos sistemas operativos, bases de datos y aplicaciones de empresas, as como tambin existen maneras de configurar estos sistemas a fin de corregir las vulnerabilidades de seguridad. Con la finalidad de ayudar a quienes no son expertos en seguridad, las organizaciones especializadas han establecido recomendaciones para fortalecer los sistemas, las cuales proporcionan consejos para corregir estas debilidades. Si no se eliminan estas debilidades de los sistemas; por ejemplo, una configuracin de archivos dbil o servicios y protocolos predeterminados (para los servicios o protocolos que generalmente no son necesarios), un atacante estar en capacidad de aplicar tcnicas o programas conocidos para atacar servicios y protocolos vulnerables y, de esta manera, obtener acceso a la red de su organizacin. Entre los sitios web donde puede obtener ms informacin sobre las mejores prcticas de la industria que contribuyen a la implementacin de normas de configuracin se encuentran: www.nist.gov, www.sans.org, www.cisecurity.org, www.iso.org. Las normas de configuracin de sistemas tambin se deben mantener actualizadas a fin de asegurar que las debilidades recientemente identificadas se corrijan antes de instalar un sistema en la red.


Requisito Gua 2.2.1 Implemente slo una funcin principal por servidor a fin de evitar que coexistan funciones que requieren diferentes niveles de seguridad en el mismo servidor. (Por ejemplo, los servidores web, servidores de base de datos y DNS se deben implementar en servidores separados). Nota: Cuando se utilicen tecnologas de virtualizacin, implemente slo una funcin principal por componente de sistema virtual.

El objetivo de esto es asegurar las normas de configuracin de sistemas y los procesos relacionados de su organizacin que tratan las funciones de los servidores que necesitan tener diferentes niveles de seguridad, o que pudieran introducir debilidades de seguridad en otras funciones del mismo servidor. Por ejemplo: 1. Una base de datos, que necesite tener medidas de seguridad slidas

implementadas, correra riesgos si comparte un servidor con una aplicacin web, que deba permanecer abierta y estar en contacto directo con Internet.

2. Si no se aplica un parche a una funcin aparentemente insignificante, es posible que se comprometan otras funciones ms importantes (como una base de datos) del mismo servidor.

Este requisito se aplica a todos los servidores dentro del entorno de datos de titulares de tarjetas (usualmente basados en Unix, Linux o Windows). Este requisito no se aplica a sistemas que tengan la capacidad de implementar niveles de seguridad de manera nativa en un mismo servidor (por ejemplo, un mainframe). Donde se utilicen tecnologas de virtualizacin, cada componente virtual (por ejemplo, una mquina virtual, un switch virtual, un dispositivo de seguridad virtual, etc.) se debe considerar como un lmite del servidor. Cada hipervisor puede admitir diferentes funciones, pero una mquina virtual individual debe acatar la regla de una sola funcin principal. Segn este supuesto, si se compromete el hipervisor, se podran comprometer todas las funciones del sistema. En consecuencia, tambin se debe tomar en consideracin el nivel de riesgo cuando se colocan mltiples funciones o componentes en un mismo sistema fsico.

2.2.2 Habilite slo los servicios, protocolos, daemons, etc. necesarios y seguros, segn lo requiera la funcin del sistema. Implemente funciones de seguridad para los servicios, protocolos o daemons requeridos que no se consideren seguros. Por ejemplo, utilice tecnologas aseguradas, tales como SSH, S-FTP, SSL o IPSec VPN, para proteger servicios no seguros como NetBIOS, archivos compartidos, Telnet, FTP, etc.

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

2.2.3 Configure los parmetros de seguridad del sistema para evitar el uso indebido.

El objetivo de esto es asegurar que las normas de configuracin de sistemas y los procesos relacionados de su organizacin traten especficamente los valores de configuracin y parmetros de seguridad que tienen implicaciones de seguridad conocidas.


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

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

2.3 Cifre todo el acceso administrativo que no sea de consola utilizando un cifrado slido. Utilice tecnologas como SSH, VPN o SSL/TLS para la administracin basada en la web y el acceso administrativo que no sea de consola.

Si la administracin remota no se realiza con una autenticacin segura y comunicaciones cifradas, la informacin confidencial a nivel administrativo u operativo (como las contraseas del administrador) se pueden revelar a un espa. Una persona malintencionada podra utilizar esta informacin para acceder a la red, hacerse pasar por administrador y hurtar datos.

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

Se concibi pensando en los proveedores de servicio de hosting que proporcionan entornos de hosting compartidos para mltiples clientes en el mismo servidor. Cuando todos los datos se encuentran en el mismo servidor y bajo el control de un solo entorno, con frecuencia los parmetros de configuracin de estos servidores compartidos no pueden ser administrados por clientes individuales, permiten que los clientes agreguen funciones y secuencias de comandos no seguros que afectan la seguridad de todos los dems entornos; y, en consecuencia, ayudan a que personas malintencionadas comprometan los datos de un cliente y, por lo tanto, obtengan acceso a los datos de los dems 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 Los mtodos de proteccin como el cifrado, el truncamiento, el ocultamiento y la funcin de hash son importantes componentes para proteger los datos de los titulares de tarjetas. Si un intruso viola otros controles de seguridad y obtiene acceso a los datos cifrados, sin las claves de cifrado adecuadas, no podr leer ni utilizar esos datos. Los otros 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 titulares de tarjetas salvo que sea absolutamente necesario, truncar los datos de titulares de tarjetas si no se necesita el PAN completo y no enviar el PAN utilizando tecnologas de mensajera de usuario final, tales como correos electrnicos y mensajera instantnea.

Consulte el Glosario de trminos, abreviaturas y acrnimos de las PCI DSS para obtener definiciones de "cifrado slido" y otros trminos de las PCI DSS.

Requisito Gua 3.1 Almacene la menor cantidad posible de datos de titulares de tarjetas implementando polticas, procedimientos y procesos de retencin y disposicin de datos, como se indica abajo.

3.1.1 Implemente una poltica de retencin y disposicin de datos que incluya: Limitacin del almacenamiento de datos y del tiempo de

retencin a la cantidad exigida por los requisitos legales, reglamentarios y del negocio

Procesos para eliminar datos de manera cuando ya no se necesiten

Requisitos de retencin especficos para datos de titulares de tarjetas

Un proceso automtico o manual trimestral para identificar y eliminar de manera segura los datos de titulares de tarjetas almacenados que excedan los requisitos de retencin definidos

Una poltica formal para la retencin de datos identifica los datos que se deben retener, as como el lugar donde residen los datos, de modo que se puedan destruir o eliminar de manera segura una vez que ya no sean necesarios. A fin de definir los requisitos de retencin apropiados, una entidad primero debe entender las necesidades de su negocio, as como cualesquiera obligaciones legales y regulatorias que se apliquen a su industria, y/o que se apliquen al tipo de dato que se retiene. Un almacenamiento extenso de datos de titulares de tarjetas que exceda la necesidad del negocio crea un riesgo innecesario. Los nicos datos de titulares de tarjetas que se pueden almacenar despus de la autorizacin son el nmero de cuenta principal o PAN (el cual debe ser ilegible), la fecha de vencimiento, el nombre del titular de la tarjeta y el cdigo de servicio. La implementacin de mtodos de eliminacin seguros asegura que los datos no se puedan recuperar cuando ya no sean necesarios.

Recuerde, si no los necesita, no los almacene!


Requisito Gua 3.2 No almacene datos confidenciales de autenticacin despus de recibir la autorizacin (aun cuando estn cifrados). Los datos confidenciales de autenticacin incluyen los datos mencionados en los requisitos 3.2.1 a 3.2.3, establecidos a continuacin: Nota: Es posible que los emisores de tarjetas de pago y las empresas que respaldan los servicios de emisin almacenen datos confidenciales de autenticacin si existe una justificacin de negocio y los datos estn almacenados de forma segura.

Los datos confidenciales de autenticacin constan de los datos de la banda magntica (o pista)6, cdigo o valor de validacin de la tarjeta7, y datos del PIN8. Se prohbe el almacenamiento de datos confidenciales de autenticacin despus de la autorizacin! 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 PA-DSS para obtener una definicin exhaustiva de datos confidenciales de autenticacin. Nota: A las compaas que realizan, facilitan o respaldan servicios de emisin se les permite almacenar datos confidenciales de autenticacin SLO SI tienen una necesidad de negocio legtima de almacenar dichos datos. Cabe sealar que todos los requisitos de las PCI DSS se aplican a los emisores, y que la nica excepcin para los emisores y procesadores emisores es que pueden retener datos si existe una razn legtima para hacerlo. Una razn legtima es que si es necesario para el desempeo de la funcin proporcionada por el emisor y no por conveniencia. Dichos datos se deben almacenar de manera segura y de conformidad con las PCI DSS y los requisitos especficos de las marcas de pago.

6 Datos codificados en la banda magntica utilizada para la autorizacin durante una transaccin con tarjeta presente. Estos datos tambin se pueden encontrar en un chip, o en

cualquier otra parte de la tarjeta. Las entidades no pueden retener todos los datos de la banda 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 tarjeta, la fecha de vencimiento y el cdigo de servicio.

7 El valor de tres o cuatro dgitos impreso sobre o a la derecha del panel de firma, o en el frente de una tarjeta de pago, que se utiliza para verificar las transacciones sin tarjeta

presente. 8 El nmero de identificacin personal ingresado por el titular de la tarjeta durante una transaccin con tarjeta presente y/o el bloque de PIN cifrado presente en el mensaje de la

transaccin.


Requisito Gua 3.2.1 No almacene contenido completo de ninguna pista de la banda magntica (ubicada en el reverso de la tarjeta, datos equivalentes que estn en un chip o en cualquier otro dispositivo). Estos datos se denominan alternativamente datos de pista completa, pista, pista 1, pista 2 y 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.

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

3.2.2 No almacene el valor ni el cdigo de validacin de tarjetas (nmero de tres o cuatro dgitos impreso en el anverso o reverso de una tarjeta de pago) que se utiliza para verificar las transacciones de tarjetas ausentes.

El propsito del cdigo de validacin de las tarjetas es proteger las transacciones que se efectan de manera no presencial, ya sean transacciones por Internet o correo/telfono (MO/TO), en las que ni el consumidor ni la tarjeta estn presentes. Estos tipos de transaccin se pueden autenticar como provenientes del propietario de la tarjeta slo al solicitar el cdigo de validacin, ya que el propietario de la tarjeta tiene la tarjeta en la mano y puede leer el valor. Si se almacenan estos datos prohibidos y luego los hurtan, las personas malintencionadas pueden efectuar transacciones por Internet y transacciones MO/TO fraudulentas.

3.2.3 No almacene el nmero de identificacin personal (PIN) ni el bloqueo del PIN cifrado.

Slo el propietario de la tarjeta o el banco emisor de la tarjeta deben conocer estos valores. Si se almacenan estos datos prohibidos y luego los hurtan, las personas malintencionadas pueden efectuar transacciones de dbito basadas en PIN (por ejemplo, retiros de cajeros automticos).


Requisito Gua 3.3 Oculte el PAN cuando aparezca (los primeros seis y los ltimos cuatro dgitos es la cantidad mxima de dgitos que aparecer). Notas: Este requisito no se aplica a trabajadores y a otras partes

que posean una necesidad de negocio legtima de conocer el PAN completo.

Este requisito no reemplaza los requisitos ms estrictos implementados para la presentacin de los datos del titular de la tarjeta (por ejemplo, los recibos de puntos de venta [POS]).

La presentacin de un PAN completo en pantallas de computadoras, recibos de tarjetas de pago, faxes o informes impresos puede facilitar la obtencin y uso fraudulento de estos datos por parte de personas malintencionadas. El PAN se puede exhibir completamente en la copia del comerciante; sin embargo, los recibos impresos deben acatar los mismos requisitos de seguridad que las copias electrnicas y seguir las directrices de las Normas de Seguridad de Datos de la PCI, especialmente el Requisito 9, que trata la seguridad fsica. El PAN tambin se puede exhibir completamente a quienes tengan una necesidad de negocio legtima de ver el PAN completo. Este requisito se relaciona con la proteccin del PAN que se muestra en pantallas, recibos impresos, etc., y no se debe confundir con el Requisito 3.4 para la proteccin del PAN cuando se almacena en archivos, bases de datos, etc.

3.4Haga que el PAN quede ilegible en cualquier lugar donde se almacene (incluidos los datos que se almacenen en medios digitales porttiles, en medios de copia de seguridad y en registros) utilizando cualquiera de los siguientes mtodos: Valores hash de una va basados en cifrado slido (el hash

debe ser de todo el PAN). Truncamiento (los valores hash no se pueden usar para

reemplazar el segmento truncado del PAN) Tokens y ensambladores de ndices (los ensambladores se

deben almacenar de manera segura). Cifrado slido con procesos y procedimientos de

administracin de claves relacionadas Nota: Para una persona malintencionada sera relativamente fcil reconstruir el PAN original si tiene acceso tanto a la versin truncada como a la versin en valores hash de un PAN. Si el entorno de una entidad tiene versiones en valores hash y truncadas del mismo PAN, se deben implementar controles adicionales para asegurar que las versiones en valores hash y truncadas no se puedan correlacionar para reconstruir el PAN original.

La ausencia de proteccin de los PAN puede permitir que personas malintencionadas vean o descarguen estos datos. Todos los PAN guardados en un almacenamiento principal (bases de datos o archivos planos como archivos de texto y hojas de clculo) y en almacenamiento secundario (copia de seguridad, registros de auditora, registros de excepciones o soluciones de problemas) deben estar protegidos. Los daos causados a las cintas de copia de seguridad por robo o prdida durante el transporte se puede reducir asegurando que los PAN sean ilegibles a travs de cifrado, truncamiento o funcin de hash. Debido a que los registros de auditora, soluciones de problemas y excepciones se deben retener, se puede prevenir la divulgacin de los datos de registros haciendo ilegibles o eliminando los PAN de los registros. Al correlacionar las versiones en valores hash o truncadas de un PAN determinado, una persona malintencionada puede derivar fcilmente el valor original del PAN. La aplicacin de controles que ayuden a prevenir la correlacin de estos datos ayudar a asegurar que el PAN original permanezca ilegible. Consulte el Glosario de trminos, abreviaturas y acrnimos de las PCI DSS y PA-DSS para obtener definiciones de cifrado slido.


Requisito Gua Valores hash de una va basados en cifrado slido (el hash

debe ser de todo el PAN). Las funciones hash de una va, tal como el Algoritmo de Hash Seguro (SHA) basado en cifrado slido, se pueden utilizar para hacer que los datos de los titulares de tarjetas sean ilegibles. Las funciones hash son apropiadas cuando no existe necesidad de recuperar el nmero original (las funciones hash de una va son irreversibles). Para complicar la creacin de tablas rainbow se recomienda, pero no es un requisito, que se introduzca un valor de sal en la funcin hash adems del PAN.

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

El objetivo del truncamiento es que slo se almacene una porcin (sin exceder los primeros seis y los ltimos cuatro dgitos) del PAN. Esto es diferente en el enmascaramiento, donde todo el PAN se almacena, pero se enmascara cuando se muestra; es decir, slo una parte del PAN aparece en pantallas, informes, recibos, etc. Este requisito se relaciona con la proteccin del PAN cuando se almacena en archivos, bases de datos, etc., y no se debe confundir con el Requisito 3.3 para la proteccin del PAN cuando se muestra en pantallas, recibos impresos, etc.

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

Los tokens y ensambladores de ndices tambin se pueden utilizar para hacer que los datos de los titulares de tarjetas sean ilegibles. Un token de ndice es un token de cifrado que reemplaza el PAN basndose en un ndice determinado por un valor impredecible. Un ensamblador nico es un sistema en el que una clave privada, la cual se genera aleatoriamente, slo se utiliza una nica vez para cifrar un mensaje que luego se descifra utilizando un ensamblador y una clave nicos que coincidan.

Cifrado slido con procesos y procedimientos de gestin de claves relacionadas.

El objetivo de un cifrado slido (consulte la definicin y las longitudes de las claves en el Glosario de trminos, abreviaturas y acrnimos de las PCI DSS y PA-DSS) es que el cifrado se base en un algoritmo probado y aceptado por la industria (no un algoritmo de propiedad exclusiva ni desarrollado internamente).

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

El objetivo de este requisito es tratar la aceptabilidad del cifrado de discos para hacer que los datos de los titulares de tarjetas sean ilegibles. El cifrado de discos cifra datos que se encuentran en el almacenamiento masivo de una computadora y descifra la informacin automticamente cuando un usuario autorizado la solicita. Los sistemas de cifrado de discos interceptan las operaciones de lectura y escritura del sistema operativo y efectan las transformaciones de cifrado apropiadas sin que el usuario realice accin especial alguna, salvo suministrar una contrasea al inicio de la sesin. Segn estas caractersticas de cifrado de discos, a fin de cumplir con este requisito, el mtodo de cifrado de discos no puede tener: 1) Una asociacin directa con el sistema operativo, o 2) Claves de descifrado que estn asociadas con cuentas de usuario.


Requisito Gua 3.5 Proteja las claves utilizadas para asegurar los datos de los titulares de tarjeta contra divulgacin o uso indebido. Nota: Este requisito tambin se aplica a las claves de cifrado de claves utilizadas para proteger las claves de cifrado de datos; tales claves de cifrado de claves deben ser por lo menos tan slidas como la clave de cifrado de datos.

Las claves de cifrado deben tener una slida proteccin debido a que aquellos que obtiene acceso podrn descifrar datos. Las claves de cifrado de claves, si se utilizan, deben ser por lo menos tan slidas como la clave de cifrado de datos a fin de asegurar la proteccin adecuada de la clave que cifra los datos as como de los datos cifrados con esa clave. El requisito de proteger las claves de divulgacin y uso indebido se aplica tanto a claves de cifrado de datos como a claves de cifrado de claves. Debido a una clave de cifrado de claves puede otorgar acceso a muchas claves de cifrado de datos, las claves de cifrado de claves requieren medidas de proteccin slidas. Los mtodos de almacenamiento seguro de claves de cifrado de claves incluyen, pero no se limitan a, mdulos de seguridad de hardware (HSM) y alteracin de almacenamiento evidente con control dual y conocimiento dividido.

3.5.1 Restrinja el acceso a las claves de cifrado al nmero mnimo de custodios necesarios.

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

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

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

3.6 Documente completamente e implemente todos los procesos y los procedimientos de gestin de claves de las claves de cifrado que se utilizan para el cifrado de datos de titulares de tarjetas, incluido lo siguiente: Nota: Varias normas de la industria relativas a la administracin de claves estn disponibles en distintos recursos incluido NIST, que puede encontrar en http://csrc.nist.gov.

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

3.6.1 Generacin de claves de cifrado slido La solucin de cifrado debe generar claves slidas, de conformidad con lo definido en el Glosario de Trminos, Abreviaturas y Acrnimos de las PCI DSS y PA-DSS en "cifrado slido".

3.6.2 Distribucin segura de claves de cifrado La solucin de cifrado debe distribuir las claves de forma segura, lo que significa que las claves no se distribuyen en texto claro, y slo a custodios identificados en 3.5.1.

3.6.3 Almacenamiento seguro de claves de cifrado La solucin de cifrado debe almacenar claves de forma segura, lo que significa que las claves no se almacenan en texto claro (cfrelas con una clave de cifrado de claves).


Requisito Gua 3.6.4 La clave de cifrado cambia en el caso de las claves que han llegado al final de su perodo de cifrado (por ejemplo, despus que haya transcurrido un perodo definido y/o despus que cierta cantidad de texto cifrado haya sido producido por una clave dada), segn lo defina el proveedor de la aplicacin relacionada o el responsable de las claves, y basndose en las mejores prcticas y recomendaciones de la industria (por ejemplo, NIST Special Publication 800-57).

Un perodo de cifrado es el intervalo de tiempo durante el cual una clave de cifrado particular se puede utilizar para su propsito definido. Las consideraciones para definir el perodo de cifrado incluyen, pero sin limitarse a, la solidez del algoritmo subyacente, tamao o longitud de la clave, peligro de riesgo de la clave y la confidencialidad de los datos cifrados. Es imperativo cambiar peridicamente las claves de cifrado cuando estn han llegado al final de su perodo de cifrado a fin de minimizar el riesgo de que alguien obtenga las claves de cifrado y pueda descifrar los datos. Si son proporcionadas por un proveedor de la aplicacin de cifrado, siga los proceso o recomendaciones de cambio peridico de claves indicados en los documentos del proveedor. El responsable o custodio designado de las claves tambin puede consultar las mejores prcticas de la industria en algoritmos critogrficos y gestin de claves, por ejemplo NIST Special Publication 800-57, para obtener una gua sobre el perodo de cifrado apropiado para diferentes algoritmos y longitudes de clave. La intencin de este requisito se aplica a claves utilizadas para cifrar datos almacenados de los titulares de tarjetas, y cualquier clave respectiva de cifrado de claves.

3.6.5 Retiro o reemplazo de claves (por ejemplo, mediante archivo, destruccin y/o revocacin) segn se considere necesario cuando se haya debilitado la integridad de la clave (por ejemplo, salida de la empresa de un empleado con conocimiento de una clave en texto claro, etc.) o cuando se sospeche que las claves estn en riesgo. Nota: Si es necesario retener las claves de cifrado retiradas o reemplazadas, stas se deben archivar de forma segura (por ejemplo, utilizando una clave de cifrado de claves). Las claves de cifrado archivadas se deben utilizar slo con fines de descifrado/verificacin.

Las claves antiguas que ya no se utilicen o necesiten se deben retirar y destruir para asegurar que ya no se puedan utilizar. Si es necesario mantener claves antiguas (para respaldar datos cifrados archivado, por ejemplo) deben tener proteccin slida. (Consulte 3.6.6 a continuacin.) La solucin de cifrado tambin debe permitir y facilitar un proceso para reemplazar claves que se sepa, o se sospeche, estn en riesgo.

3.6.6 Si se utilizan operaciones manuales de gestin de claves de cifrado en texto claro, estas operaciones deben aplicar conocimiento dividido y control doble (por ejemplo, utilizando dos o tres personas, cada una de las cuales conoce su propia parte de la clave, para reconstruir toda la clave). Nota: Los ejemplos de operaciones manuales de gestin de claves incluyen, entre otros: generacin, transmisin, carga, almacenamiento y destruccin de claves.

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


Requisito Gua 3.6.7 Prevencin de sustitucin no autorizada de claves de cifrado.

La solucin de cifrado no debe permitir ni aceptar la sustitucin de claves por parte de fuentes no autorizadas o procesos inesperados.

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

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


Requisito 4: Cifrar la transmisin de los datos del titular de la tarjeta en las redes pblicas abiertas. La informacin confidencial se debe cifrar 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 siguen siendo los objetivos de delincuentes que explotan estas vulnerabilidades a los efectos de acceder a los entornos de datos de los titulares de las tarjetas.

Requisito Gua 4.1 Utilice cifrado slido y protocolos de seguridad (por ejemplo, SSL/TLS, IPSec, SSH, etc.) para proteger datos confidenciales del titular de la tarjeta durante la transmisin por redes pblicas abiertas. Ejemplos de redes pblicas abiertas que se encuentran dentro del alcance de las PCI DSS incluyen, pero sin limitarse a: La Internet Tecnologas inalmbricas Sistema global para comunicaciones mviles (GSM) Servicio de radio paquete general (GPRS)

La informacin confidencial debe estar cifrada durante la transmisin en redes pblicas, porque es fcil y comn para una persona malintencionada interceptar y/o desviar datos mientras estn en trnsito. Por ejemplo, el Protocolo de Capa de Conexin Segura (SSL) cifra pginas web y los datos ingresados en ellas. Cuando utilice sitios web asegurados con SSL, asegrese de que https forme parte del URL. Tenga en cuenta que algunas implementaciones de protocolo (tales como SSL versin 2.0 y SSH versin 1.0) tienen vulnerabilidades documentadas, como desbordamientos de buffer, que un atacante puede utilizar para obtener el control del sistema afectado. Independientemente del protocolo de seguridad utilizado, asegrese de que est configurado para utilizar slo configuraciones y versiones seguras para impedir el uso de una conexin insegura.


Requisito Gua 4.1.1 Asegrese de que las redes inalmbricas que transmiten datos de los titulares de las tarjetas o que estn conectadas al entorno de datos del titular de la tarjeta utilizan las mejores prcticas de la industria (por ejemplo, IEEE 802.11i) a los efectos de implementar cifrados slidos para la autenticacin y transmisin. Nota: La utilizacin de WEP como control de seguridad est prohibido a partir del 30 de junio de 2010.

Usuarios maliciosos pueden utilizar herramientas gratis y disponibles a gran escala para espiar comunicaciones inalmbricas. El uso de cifrado slido puede limitar la divulgacin de informacin confidencial en la red. Muchos de los riesgos conocidos de datos de titulares de tarjetas almacenados slo en la red de cable se originaron cuando un usuario malicioso expandi el acceso desde una red inalmbrica insegura. Algunos ejemplos de implementaciones inalmbricas que requieren cifrado slido incluyen, sin limitarse a, GPRS, GSM, WIFI, satlite y Bluetooth. Se requiere cifrado slido para autenticacin y transmisin de datos del titular de la tarjeta a efectos de impedir que usuarios maliciosos obtengan acceso a la red inalmbricalos datos en la redo que utilicen las redes inalmbricas para acceder a otras redes internas u otros datos. Nunca se debe utilizar el cifrado WEP como el nico medio de cifrado de datos en un canal inalmbrico ya que no se considera cifrado slido, es vulnerable debido a vectores de inicializacin dbiles en el proceso de intercambio de claves WEP, y carece la rotacin requerida de clave. Un atacante puede usar herramientas de craqueo de fuerza bruta, a las que se puede acceder de forma gratuita, para penetrar el cifrado WEP. Los dispositivos inalmbricos actuales se deben actualizar (ejemplo: actualizar el firmware del punto de acceso a WPA2) para respaldar el cifrado slido. Si los dispositivos actuales no se pueden actualizar, se debe adquirir equipo nuevo o se deben implementar otros controles de compensacin para proporcionar cifrado slido.

4.2 Nunca debe enviar PAN no cifrados por medio de tecnologas de mensajera de usuario final (por ejemplo, el correo electrnico, la mensajera instantnea, el chat, etc.).

El correo electrnico, la mensajera instantnea y el chat se pueden interceptar fcilmente mediante detectores de paquetes durante la exposicin completa de la entrega en redes internas y pblicas. No utilice estas herramientas de mensajera para enviar PAN a menos que proporcionen cifrado slido.


Gua para los Requisitos 5 y 6: Mantener 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 de negocio 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 comnmente afectados por software malicioso (en especial, computadoras personales y servidores).

Existe un flujo constante de ataques utilizando vulnerabilidades ampliamente publicadas, comnmente "da 0" (publicado y difundido a travs de redes en un plazo de una hora a partir del descubrimiento) contra sistemas de otro modo seguros. Sin un software antivirus que se actualice regularmente, estas nuevas formas de software malicioso pueden atacar e inhabilitar su red. El software malicioso se puede descarga y/o instalar sin saberlo desde Internet, pero las computadoras tambin son vulnerables cuando se utilizan dispositivos de almacenamiento extrables como CD y DVD, dispositivos de memoria USB y discos locales, cmaras digitales, asistentes digitales personales (PDA) y otros dispositivos perifricos. Sin un software antivirus instalado, estas computadoras pueden convertirse en puntos de acceso en su red, y/o dirigir, de forma maliciosa, informacin dentro de la red. Aunque entre los sistemas comnmente afectados por software malicioso no se suele incluir mainframes ni la mayora de los sistemas Unix (consulte ms detalles a continuacin), cada entidad debe tener un proceso de conformidad con el Requisito 6.2 de las PCI DSS a efectos de identificar y tratar nuevas vulnerabilidades de seguridad y actualizar sus normas y procesos de configuracin debidamente. Si otro tipo de solucin trata las mismas amenazas con una metodologa diferente a un enfoque basado en firmas, sigue siendo an aceptable para cumplir con el requisito. Las tendencias en software malicioso relacionadas con sistemas operativos que utiliza una entidad deben estar incluidas en la identificacin de nuevas vulnerabilidades de seguridad, y los mtodos para tratar nuevas tendencias deben estar incorporados en las normas de configuracin y los mecanismos de proteccin de la empresa segn sea necesario. Comnmente, los siguientes sistemas operativos no suelen ser afectados por software maliciosos: mainframes y ciertos servidores Unix (como AIX, Solaris y HP-Unix). Sin embargo, las tendencias de la industria para software malicioso pueden cambiar rpidamente y cada organizacin debe cumplir con el Requisito 6.2 para identificar y tratar nuevas vulnerabilidades de seguridad y actualizar sus normas y


Requisito Gua procesos de configuracin debidamente.

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

Es importante proveer proteccin contra TODOS los tipos y formas de software malicioso.

5.2 Asegrese de que todos los mecanismos antivirus estn actualizados, estn en funcionamiento y puedan generar registros de auditora.

El mejor software antivirus es limitado en efectividad si no tiene firmas antivirus actuales o si no est activo en la red o en la computadora de una persona. Los registros de auditora proporcionan la capacidad de supervisar actividad de virus y reacciones antivirus. Por lo tanto, es imprescindible que ese software antivirus se configure para generar registros de auditora y que esos registros se administren de conformidad con el Requisito 10.


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 riesgo 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 y software cuenten con los parches de seguridad ms recientes proporcionados por los proveedores para proteccin contra vulnerabilidades conocidas. Instale los parches importantes de seguridad dentro de un plazo de un mes de su lanzamiento. Nota: Las organizaciones pueden tener en cuenta la aplicacin de un enfoque basado en el riesgo a los efectos de priorizar la instalacin de parches. Por ejemplo, al priorizar infraestructura de importancia (por 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.

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


Requisito Gua 6.2 Establezca un proceso para identificar y asignar una clasificacin de riesgos para vulnerabilidades de seguridad descubiertas recientemente. Notas: Las clasificaciones de riesgo se deben basar en las mejores prcticas de la industria. Por ejemplo, los criterios para clasificar vulnerabilidades de Alto riesgo pueden incluir una puntuacin base CVSS de 4.0 o superior, y/o un parche proporcionado por

navigating dss v2

Documents