Actualización de PCI 3.0

octubre 24, 2013 § Deja un comentario

Ciberdelincuencia, robo de identidad y el fraude van en aumento; y en la mayoría de los casos, las violaciones de datos están asociadas con las tarjetas de crédito y datos del titular. El impacto de la violación de datos afecta a las organizaciones y a sus clientes.

Es fácil notar que la mayoría de las organizaciones tienen dificultades para cumplir con los requisitos necesarios para el procesamiento de datos del titular de las tarjetas de crédito. Por eso, basado en la retroalimentación de la industria, PCI Security Councilha introducido algunos cambios en las regulaciones de cumplimiento y los mismos serán publicados en la versión 3.0 de PCI, cuya versión final está programada para el lanzamiento el próximo 07 de noviembre de 2013, y se espera que será efectiva a partir de enero de 2014.

¿Cuáles son las actualizaciones y cuál será del impacto del cumplimiento de PCI de la organización?

La actualización 3.0 también clarificará la intención de los requisitos y los métodos de aplicación: Flexibilidad:se añade mayor flexibilidad en términos de cómo cumplir con los requisitos de PCI y cómo las organizaciones deben mitigar los riesgos. Responsabilidad compartida:PCI 3.0 cita que la protección de datos de los titulares de las tarjetas es una responsabilidad compartida debido al aumento en el número de puntos de acceso a los datos de los titulares.

Entre los factores considerados para las revisiones en PCI 3.0

  • Mejoras en la seguridad del pago
  • Aplicabilidad global
  • Costo del cambio de la infraestructura
  • Impacto de los cambios

¿Novedades de PCI 3.0 y por qué la nueva versión?

PCI Requirement No. Current PCI DSS Standard(as of October 2013) Proposed PCI DSS Update for 3.0 on top of existing standards Purpose
1 Install and maintain a firewall configuration to protect cardholder data. Have a current diagram that shows cardholder data flows. To clarify that documented cardholder data flows are an important component of network diagrams.
2 Do not use vendor-supplied defaults for system passwords and other security parameters. Maintain an inventory of system components in scope for PCI DSS. To support effective scoping practices.
3 Protect stored cardholder data. No change from the existing version.
4 Encrypt transmission of cardholder data across open, public networks. No change from the existing version
5 Use and regularly update antivirus software. Evaluate evolving malware threats for systems not commonly affected by malware. To promote ongoing awareness and due diligence to protect systems from malware
6 Develop and maintain secure systems and applications. Update list of common vulnerabilities in alignment with OWASP, NIST, and SANS for inclusion in secure coding practices. To keep current with emerging threats.
7 Restrict access to cardholder data by business need-to-know. No change from the existing version
8 Assign a unique ID to each person with computer access. Security considerations for authentication mechanisms such as physical security tokens, smart cards, and certificates. To address feedback about requirements for securing authentication methods, other than passwords, that need to be included.
9 Restrict physical access to cardholder data. Protect POS terminals and devices from tampering or substitution. To address the need for physical security of payment terminals.
10 Track and monitor all access to network resources and cardholder data. No change from the existing version
11 Regularly test security systems and processes. Implement a methodology for penetration testing, and perform penetration tests to verify that the segmentation methods are operational and effective. To address requests for more details about penetration tests, and for more stringent scoping verification.
12 Maintain a policy that addresses information security. Maintain information about which PCI DSS requirements are managed by service providers and which are managed by the entity.
Service providers need to accept responsibility for maintaining applicable PCI DSS requirements.
To address feedback from the 3rd-Party Security Assurance SIG.

La actualización incluye las siguientes mejoras:

  • Eliminación de los requisitos redundantes
  • Aclaración de los procedimientos de prueba para cada requisito
  • Fortalecimiento de los requisitos de pruebas de penetración y validación de segmentos de red
  • Mayor flexibilidad en métodos de mitigación de riesgo que comprende los requerimientos de fuerza y complejidad de contraseña.

Fuente: The Hacker News

Criterios de PCI DSS para la obtención de evidencia en auditorías

junio 14, 2013 § Deja un comentario

Cuando se realiza una auditoría PCI DSS a un Comercio (“Merchant“) o Proveedor de Servicio (“Service Provider“) clasificados como nivel 1 (“Level 1″) por la cantidad de transacciones anuales realizadas y dichos resultados deben ser reportados a Visa, de forma obligatoria el auditor QSA debe rellenar un documento específico con los detalles pormenorizados de los hallazgos de la auditoría y la evidencia asociada. Dicho documento se denomina “Report on Compliance” (RoC) y de forma discrecional otras marcas (como Discover) lo pueden requerir para evaluar el cumplimiento del estándar.  Este RoC suele acompañar el formulario de  Declaración de cumplimiento para evaluaciones in situ (“Attestation of Compliance”) (AoC) y los resultados de los escaneos ASV como requerimientos de validación.

El RoC – a diferencia del SAQ y del AoC - va más allá del SI/NO en la columna “Estado de cumplimiento”, ya que se requiere un detalle granular justificando el porqué de dicho cumplimiento y respaldándolo con diferentes tipos de evidencia, como se describirá en este artículo. Es importante que tanto el auditor QSA como la empresa auditada conozcan el tipo de evidencia que se requerirá en este proceso:

  • El auditor, para preparar su plan de auditoría y coordinar tiempo y esfuerzo en la obtención de evidencia dependiendo de la complejidad del entorno auditado.
  • La empresa auditada, para poder preparar permisos, autorizaciones, personal acompañante, disponibilidad y encargados de proveer dicha evidencia al auditor.

De esta manera, el proceso de auditoría no tendrá contratiempos y la información a ser revisada podrá estar disponible cuando se requiera

Contenido completo en fuente original PCI Hispano

La autenticación en el Compliance de los estándares mundiales

abril 26, 2013 § Deja un comentario

Garantizar que el usuario establecido sea quien realmente ingrese a la información es imprescindible para garantizar su integridad. Pero cómo encaja este tema en las principales normativas y estándares de seguridad lo veremos a continuación.

Cada empresa de acuerdo a sus necesidades decide gestionar la seguridad de la información de acuerdo a un determinado estándar. El compliance o cumplimiento de estas normatividades es de suma importancia obviamente para garantizar la seguridad de la información más sensible y por otra parte para evitar multas o sanciones legales que pueden darse a partir de su incumplimiento.
El objetivo de estos estándares o regulaciones es garantizar la integridad, disponibilidad y confidencialidad de la información. Uno de los controles más comunes para garantizar estas tres características es la autenticación de usuarios. Veamos qué es lo que las principales normativas piden al respecto de este control.

El PCI DSS es un estándar que aplica donde sea que se almacenen, procesen o transmitan datos de cuentas bancarias. En su requisito 3 pide proteger los datos del titular de la tarjeta que fueron almacenados y en el requisito 7 restringir el acceso a los datos del titular de la tarjeta según la necesidad de saber del negocio, con el objetivo de que se limite el acceso a los componentes del sistema a aquellos individuos cuyas tareas necesitan de ese acceso. Para esto recomienda un sistema de control de acceso automático.

En el requisito 8 pide asignar una ID exclusiva a cada persona que tenga acceso por computadora, empleando al menos uno de los métodos siguientes para autenticar a todos los usuarios: algo que el usuario sepa, algo que el usuario tenga, algo que el usuario sea. Además sugiere incorporar la autenticación de dos factores para el acceso remoto (acceso en el nivel de la red que se origina fuera de la red) a la red de empleados, administradores y terceros.

Los lineamientos del FFIEC (Federal Financial Institutions Examination Council) son recomendaciones para que las entidades financieras evalúen el riesgo en las transacciones electrónicas y como se pueden mitigar con la aplicación de sistemas de autenticación. Este estándar incluye un apartado sobre los programas de seguridad por capas que deberían implementar las entidades financieras para garantizar la seguridad en las transacciones basadas en servicios a través de Internet. Dentro de los controles que sugiere esta norma se encuentra precisamente el uso de sistemas de doble autenticación utilizando diferentes dispositivos.

La Ley Sarbanes–Oxley, regulación impuesta a las empresas que participan en el mercado financiero estadounidense, sugiere que para cumplir con los lineamientos de seguridad se implemente COSO, el cual posee cinco componentes de control. El tercero de estos, Actividades de Control, trata entre otras cosas sobre el control de los sistemas de procesamiento electrónico de datos, dentro de los que destacan los controles sobre la seguridad lógica. Destaca los sistemas de autenticación para proteger los sistemas contra el acceso y uso no autorizados.

El NIST (National Institute of Standards and Technology) provee entre otras, las recomendaciones para implementar sistemas de autenticación. La seguridad en la autenticación, la divide en cuatro niveles, de los cuáles el tercer nivel hace referencia a la protección de acceso a la red de forma remota mediante factor de múltiple autenticación. Este estándar reúne, además, las características que deben tener los sistemas para garantizar la seguridad en la autenticación, describiendo su uso y tipos de acuerdo al factor de protección elegido (credenciales, tokens, procesos de autenticación, assertions).

Finalmente, la norma certificable ISO 27001, quizá la más conocida, es un estándar para implementar y certificar un sistema de gestión de la seguridad de la información. De los pilares básicos de la norma ISO 27001 el dominio de control A.11 está relacionado con el control de acceso. Precisamente el control A.11.4 está asociado con el acceso a la red, cuyo objetivo es prevenir accesos no autorizados.

Fuente: ESET Latinoamérica

Cómo cumplir con PCI DSS si utilizo Cloud Computing

febrero 16, 2013 § Deja un comentario

En esta entrada vamos a analizar el recién suplemento informativo publicado por el PCI Security Standards Council relativo a la computación en la nube (PDF).

En primer lugar, destacar que es un documento bastante exhaustivo (52 páginas) que incluso, en nuestra opinión, va un poco más allá de lo que se esperaría de un suplemento informativo del PCI SSC, puesto que dedica todo un apartado (el sexto) a “otras consideraciones” sobre la computación en la nube que, como su propio nombre indica, no afectan a la cuestión a cubrir: Servir como punto inicial de discusión para proveedores de servicios en la nube y clientes (especialmente centrado en los casos de nubes públicas).

Desde nuestro punto de vista, el documento gira entorno a tres ideas principales que gobiernan todo el contenido:

  • Los servicios en la nube suponen una pérdida de control, por lo que es necesario delimitar claramente las responsabilidades de las partes antes de utilizarlos y llevar a cabo un proceso de due diligence previo que permita verificar el cumplimiento del proveedor con los requisitos de PCI DSS.
  • Es necesario establecer un adecuado aislamiento de los datos en los entornos en la nube mediante mecanismos de segmentación que permitan limitar el alcance de las evaluaciones de cumplimiento.
  • El proveedor y el cliente deben contar con mecanismos para asegurar que el cumplimiento se mantiene de manera continuada.

Respecto a la primera idea nos gustaría destacar que:

  • Se proporciona una guía muy útil (no prescriptiva) de cómo se pueden distribuir las responsabilidades entre cliente y proveedor (Anexos A y C) para cada una de las modalidades de servicios en la nube (SaaS, PaaS e IaaS) puesto que se considera indispensable que conste por escrito (a ser posible en los SLAs del servicio) quien se responsabiliza de la implantación y ejecución de cada control, cómo se va a informar sobre su estado y su gestión y que el cliente entienda qué responsabilidad acepta el proveedor para cada control.
  • Se refuerza la idea de que una pérdida de control sobre los controles no supone una pérdida de responsabilidad del cliente de que dichos contrales deben ser efectivos y, por tanto, debe asegurarse un nivel de visibilidad y de monitorización de los mismos adecuado.
    • Por dicho motivo, se recomienda a los clientes que trabajen con proveedores que cumplan PCI DSS pero que, antes de contratar un servicio, se informen de:
    • Desde cuándo cumple el proveedor con PCI DSS y cuándo fue su última evaluación.
    • Qué servicios y requerimientos fueron incluidos en dicha evaluación.
    • Qué sistemas e instalaciones fueron evaluados.
    • Si algún componente del sistema necesario para la prestación del servicio no fue incluido en la evaluación.
    • Cómo evita el proveedor que los clientes no introducen componentes que no cumplan con PCI DSS o eviten los controles existentes.
  • Con independencia de utilizar servicios en la nube, el cliente tiene que seguir demostrando su cumplimiento con los requisitos de PCI DSS.

Respecto al segundo concepto sobre la necesidad de aislamiento mediante segmentación, lo más destacable, a nuestro juicio es que pone realmente difícil utilizar servicios de nube pública que no hayan sido pensados para cumplir con PCI DSS. Decimos esto porque obliga (en línea con lo establecido en el estándar para proveedores de servicio) a una total segmentación entre entornos de distintos clientes y con el propio proveedor sin ninguna conectividad entre ellos; es decir, no se puede compartir ningún elemento del sistema, ni aplicación, ni bases de datos, ni comunicaciones… en definitiva, realmente complejo pensar en una aplicación SaaS que pueda ser eficiente si tenemos que aplicar todas estas medidas de segmentación. Como mucho, podremos ver servicios de plataforma o infraestructura. En cualquier caso, en relación a este concepto nos gustaría destacar las siguientes ideas recogidas en el suplemento:

La segmentación debe proporcionar un aislamiento equiparable al que obtendríamos con una separación física de redes.

Sin una adecuada segmentación, todos los clientes de la infraestructura compartida, así como el propio proveedor, tendrán que cumplir con PCI DSS para que cualquiera de sus clientes pueda ser considerado como que cumple con el estándar. Es decir, todos ellos estarán considerados en el alcance de la evaluación de cumplimiento de cualquiera de ellos, haciendo prácticamente imposible alcanzar el cumplimiento.
El proveedor debe asumir la responsabilidad de establecer los mecanismos de segmentación adecuados entre clientes y con el propio proveedor, evitando que incluso el hypervisor o cualquier otra sistema subyacente puedan suponer una vía de comunicación entre ellos.

Los mecanismos de segmentación a utilizar serían los mismos que los utilizados en un entorno no virtualizado: cortafuegos y segmentación de red a nivel de infraestructura, cortafuegos, IPS, DLP a nivel de hypervisor y máquina virtual, uso de VLANes, aislamiento de procesos y recursos, almacenes de datos segmentados, autenticación fuerte de doble factor, segregación de tareas.

  • La segmentación implementada debe ser validada, como siempre, por el QSA.
  • Es importante entender las relaciones del proveedor con terceros, puesto que añaden complejidad a la delimitación del alcance y al objetivo de cumplir con el estándar.
  • Las recomendaciones para reducir el alcance serían:
    • No utilizar servicios en la nube (¡¡¿?!!)
    • Utilizar una infraestructura dedicada (¡¡¿?!!) solo para el entorno incluido en el alcance
    • Minimizar la dependencia en el proveedor para cumplir con los requerimientos (es decir, utilizar servicios en los que el cliente mantenga más el control: IaaS o, como mucho, PaaS).
    • Tratar de evitar que los datos estén en claro en la nube [Esta es la única recomendación como tal]
  • En relación a la propia evaluación, si el cliente no ha sido evaluado, debe ser incluido en la evaluación de cumplimiento del cliente y, entonces, deben establecerse SLAs que claramente identifiquen el permiso del proveedor a ser auditado y la parte de las tareas que van a ser realizadas por cada uno de ellos.

Finalmente, en relación a la tercera idea de mantenimiento a lo largo del tiempo, obviamente el documento recoge la necesidad de que el cumplimiento se mantenga durante la prestación del servicio y el proveedor debe demostrar cómo se mantiene dicho cumplimiento en el tiempo.

Como último punto de nuestro análisis, destacar también que el documento incluye un apartado final (el séptimo) con la guía que sugiere a los clientes antes de adoptar un servicio en la nube (ENTENDER, COMPARAR, EVALUAR, CONOCER…), así como un apéndice (el D) con preguntas a realizar al proveedor como orientación para todo este proceso de due diligence.

En definitiva y como resumen, una guía que desalienta bastante la utilización de servicios en la nube (especialmente los de SaaS públicos) para aquellos que se lo estuvieran pensando.

Fuente: En Plus One

Normas de Seguridad PCI DSS, PA DSS y PCI PTS

enero 3, 2013 § Deja un comentario

Hace poco más de un mes se llevó a cabo en Madrid una nueva edición del seminario “Últimos avances en Medios de Pago” donde se desarrollaron cada uno de los aspectos más importantes de los sistemas de pago que actualmente están en funcionamiento.

Uno de los temas que más comentarios suscitó fue la complejidad para saber qué empresas habían sido auditadas por la organización PCI DSS, aspecto que ha despertado mi curiosidad sobre cuál es la función de esta organización y sus aspectos más destacables y que me ha hecho indagar en este sentido.

Según su propia página web, “PCI Security Standards Council es un foro mundial abierto establecido en el 2006″, cuya misión es la de aumentar la seguridad de la industria de las tarjetas de pago, proteger al usuario y disminuir el fraude de tarjetas de crédito.

Las empresas fundadoras de esta organización son American Express, Discover Financial Services, JCB International, MasterCard Worldwide y Visa, Inc. Estas empresas unificaron sus requisitos propios de seguridad en un único punto con el fin de facilitar el cumplimiento en materia de seguridad. En caso de no cumplir la normativa, esta organización puede imponer multas o incluso denegar el servicio de utilización de las mismas. Actualmente, todas ellas comparten de manera ecuánime el control de la organización así como aquellas actividades relacionadas con la seguridad en la industria de las tarjetas de pago. Además, reconocen que los Evaluadores de Seguridad Certificados (QSA) y los Proveedores Aprobados de Escaneo (ASV) certificados por el PCI SSC son los únicos habilitados para validar el cumplimiento con PCI DSS.

Las empresas que trabajan con datos de tarjetas deben cumplir una serie de requisitos de seguridad, tanto de cara a la seguridad del propio cliente como a la seguridad propia de la compañía, ya que se enfrentan a auditorias severas y un incumplimiento de las mismas puede acarrear una cuantiosa multa.

La función de los miembros del PCI Security Standards Council es la de supervisar y definir normas de seguridad de datos (PCI DSS), requisitos de seguridad de transacciones con PIN (PCI PTS) y elaborar la norma de seguridad para la aplicación de pagos(PA-DSS).

PCI Security Standards Council define en su página web tres normas, cada una de ellas centrada en un ámbito determinado, que unifican los requisitos propios de cada una de las marcas:

PCI DSS

Es un estándar que recoge los requisitos y normas de seguridad de datos que deben seguir todas las compañías que trabajen con transacciones de tarjetas de pago. Es la que más repercusión tiene, se aplica a todas las entidades que participan en procesos de pago con tarjeta y recoge los requerimientos técnicos y operativos desarrollados para proteger los datos de los usuarios. Su adopción es obligatoria desde junio de 2007 y las marcas pueden imponer sanciones a las entidades que no realicen las auditorías prescritas.

Fue actualizada en Octubre de 2010, proporcionándole mayor flexibilidad, comprensión y facilitando su implantación por parte de empresarios y comerciantes. Comenzó a ser efectiva a partir del 1 Enero de 2011, pero se les concedió un año a las organizaciones para adecuarse a la actualización.

La norma está dividida en 12 requisitos de cumplimiento, organizados en 6 secciones llamadas “objetivos de control”. Estas secciones son las siguientes:

  • Desarrollar y Mantener una Red Segura.
  • Proteger los Datos de los propietarios de tarjetas.
  • Mantener un Programa de Manejo de Vulnerabilidad.
  • Implementar Medidas sólidas de control de acceso.
  • Monitorear y Probar regularmente las redes.
  • Mantener una Política de Seguridad de la Información.

Cada una de las secciones recoge los requisitos necesarios para proteger los datos de los titulares de tarjeta y en consecuencia, los pasos que deben seguir las organizaciones para protegerse en caso que ofrezcan el servicio de pago con tarjeta.

Algo que nos puede llevar resultar curioso a las personas que trabajamos en la gestión de la seguridad de la información es la comparación de PCI DSS con la norma ISO 27001 y buscar sus puntos comunes. Ambas normativas comparten propósito, pero difieren mucho en los métodos. Tienen la finalidad de proteger y controlar los datos de los clientes y ambas requieren auditorias periódicas, pero esos son los únicos puntos que comparten.

En la página http://www.focusonpci.com/site/ se puede encontrar un artículo que trata directamente estas diferencias, exponiendo además que “ISO es una medida global para toda la empresa, mientras que PCI está más centralizada en la gestión de la información referida a los pagos con tarjeta. Además la ISO es voluntaria, mientras la PCI DSS es obligatoria”. Incluye también una tabla con algunas de las diferencias más notables:

En el portal de información http://www.iso27001security.com/ se puede encontrar la relación entre los requerimientos que exige el PCI DSS y qué punto de la norma ISO 27.001 lo cubre. Puede ser consultado en el siguiente link: http://www.iso27001security.com/ISO27k_Mapping_ISO_27001_to_PCI-DSS_V1.2.pdf.

PA DSS

Se aplica a los proveedores software. Según su página web “su objetivo es ayudar a los proveedores de software y otros a desarrollar aplicaciones de pago seguro que no almacenen datos prohibidos, como la banda magnética completa, datos de PIN o de CVV2 (Valor de verificación de la tarjeta), y cerciorarse de que sus aplicaciones de pago admitan el cumplimiento de la PCI DSS.”

Este estándar está basado en las buenas prácticas de pago PABP (Payment Application Best Practices) [DOC], que Visa proporciona a los proveedores de aplicaciones. Estas buenas prácticas son voluntarias y aseguran que las aplicaciones de pago no almacenan datos engañosos colaborando en el cumplimiento del PCI DSS.

Esta norma está constituida por 14 requerimientos, y al igual que PCI DSS, fue actualizada en octubre de 2010.

PCI PTS

Aplica a los dispositivos de pago, definiendo los requisitos que debe tener su proceso de fabricación.

Esta norma recoge los requisitos de seguridad para transacciones con PIN. Va dirigida a los productores de los dispositivos de pago, definiendo los requisitos que deben seguir en el diseño, fabricación y transporte de estos dispositivos así como las entidades que los utilicen.

Este ha sido un pequeño resumen de las tres normas que la PCI ha desarrollado para mejorar la protección de los datos de los titulares de las tarjetas y con ello facilitar la adopción de medidas comunes para reducir el fraude en la industria de las tarjetas de crédito.

A finales de 2010 el PCI Security Standards Council publicó la versión 2.0 del PCI DSS y PA-DSS, respondiendo a la necesidad de mayor comprensión y flexibilidad de las normas, así como facilitando su aplicación en las organizaciones.

Fuente: Security Art Work I y II

Guía Cumplimiento PCI-DSS

diciembre 20, 2012 § Deja un comentario

El fabricante de seguridad perimetral NETASQ, uno de nuestros partners tecnológicos, dispone de una guía para asegurar el cumplimiento PCI [PDF].

PCI (Payment Card Industry) es un estándar de seguridad de datos creado por American Express, Discover Financial Services, JCB, MasterCard Worldwide, y Visa Internacional cuyo objetivo es definir las medidas de protección para las infraestructuras de sistemas que intervienen en el tratamiento, procesamiento o almacenamiento de información de los medios de pago. Los requerimientos que marca este estándar son conocidos como PCI Data Security Standard (PCI-DSS).

El cumplimiento de estos requerimientos se puede resumir en 3 etapas principales:

  • Recogida y almacenamiento: Recogida segura y almacenamiento inalterable de todos los datos de registros de forma que estén disponibles para el análisis.
  • Generación de informes: Ser capaz, en caso de auditoría, de probar el cumplimiento del estándar y presentar evidencias de que existen los controles para la protección de datos.
  • Monitorización y alarma: Tener sistemas de información que permitan a los administradores monitorizar constantemente el acceso y uso de la información. De esta manera, los administradores son capaces de identificar posibles problemas y, en su caso, tratarlos de forma rápida y eficaz. Estos sistemas también deberán extenderse a los mismos datos de registro, debe probarse que los datos de registros son recogidos y almacenados.

Fuente: Audea

Comentarios a la versión de PCI DSS

noviembre 4, 2012 § Deja un comentario

En estos momentos nos encontramos en la etapa 6 del ciclo de vida de PCI DSS, “Feedback Review” o revisión de comentarios y el PCI Security Standard Council ha publicado un resumen de los comentarios que ha recibido [PDF] que me ha parecido interesante porque, se supone, que la nueva versión del estándar incluirá modificaciones y/o aclaraciones, sobre todo, en esos puntos.

Los puntos más comentados (suponen más de la mitad del total, el 54%) han sido los siguientes:

  • Requerimiento 11.2 [13%] – Prescribir el uso de herramientas específicas, solicitar a los ASV la realización de escaneos internos y definir que supone un “cambio significativo”.
  • Alcance [10%] – Proporcionar una guía detallada para definir el alcance y la segmentación.
  • Requerimiento 12.8 [8%] – Clarificar los términos “proveedor de servicios” y “compartido” y proporcionar unos requerimientos más prescriptivos para los acuerdos escritos que aplican a los proveedores de servicio.
  • SAQs [8%] – Considerar actualizar los SAQs; son, o bien, demasiado complejos (difíciles de comprender) o bien no son suficientemente detallados.
  • Requerimiento 3.4 [8%] – Los requerimientos de gestión de clave y de cifrado son complejos; proporcionar una mayor claridad. El truncado / tokenizado / hashing no es un método conveniente para almacenar y recuperar datos; proporcionar mayor guía.
  • Requerimiento 8.5 [7%] – Considerar actualizar los requisitos de las contraseñas (expandir la autenticación más allá de las contraseñas). Los requisitos actuales sobre contraseñas son muy o poco estrictos; ser más o menos prescriptivos.

Fuente: Antonio Ramos (@antonio_ramosga)

Informe anual de PCI: la seguridad es un proceso

octubre 17, 2011 § Deja un comentario

Recientemente PCI DSS (Del inglés, Payment Card Industry Data Security Standard), la organización dedicada a certificar la seguridad de la información en empresas que comercializan y realizan transacciones con tarjetas de crédito, ha liberado su informe 2011 PCI Compliance Report [PDF], que incluye información estadística y analítica sobre las empresas que han intentado (y eventualmente logrado) certificar en la norma PCI.
Tal como reporta Anton Chuvakin en el blog oficial, 8 de cada 10 empresas que certificaron el último año, no han logrado certificar en el 2011. Este dato, además de alarmante, refleja algo que siempre menciono en contextos de concientización en empresas: la seguridad es un proceso.

Fuente: ESET Latinoamérica

Dudas a la hora de definir el alcance de PCI DSS

septiembre 6, 2011 § Deja un comentario

Dentro de PCI DSS la definición del alcance resulta un requisito fundamental a la hora de establecer los sistemas de información que van a ser afectados por el cumplimiento de los requisitos de PCI DSS.

Por otro lado la segmentación de red resulta un paso muy útil para reducir este alcance y así aminorar en gran medida la implantación de los requerimientos de seguridad y abaratar de forma importante el coste de implantación de los mismos. Ahora bien la segmentación no es una cuestión baladí teniendo en cuenta que la mayoría de redes que predominan entre los afectos al cumplimiento de este estándar han sido creadas bajo necesidades de negocio y no para el cumplimiento de PCI DSS, y consiguientemente el hacer una segmentación de las redes supone hacer una reingeniería de procesos informáticos que no es para nada sencilla.

Dentro de este ámbito de la definición del alcance y la segmentación de redes, no son pocas las cuestiones que se suscitan y aquí quiero exponer dos de ellas:

  • Primera: Imaginemos un sistema dentro de un proceso de negocio afectado por PCI DSS (hay PANes involucrados) que en sus funcionalidades sólo es llamado para validar ciertas transacciones del proceso donde los datos de tarjeta no intervienen (este sistema no transmite, procesa ni almacena datos de tarjeta) pero sin cuya existencia la transacción no podría acometerse. No pasan datos de tarjeta, pero si ese sistema es atacado o su disponibilidad cae podría caer todo el proceso de negocio de tarjetas. Si este sistema está en un segmento de red aparte de los sistemas que almacenan procesan, transmiten datos de tarjeta, estaría fuera del alcance del cumplimiento de PCI DSS?
  • Segunda: mirando sobre el alcance de PCI DSS, existen algunos sistemas como por ej. El DNS por los que no pasan, transmiten o se almacenan datos de tarjeta pero que sí están implicados en el cumplimiento de los requisitos de PCI DSS respecto de los sistemas que si están afectados por datos de tarjeta.

Revisando PCI DSS 2.0 se dice lo siguiente “Scope of Assessment for Compliance with PCI DSS Requirements. The PCI DSS security requirements apply to all system components. In the context of PCI DSS, “system components” are defined as any network component, server, or application that is included in or connected to the cardholder data environment. “System components” also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors. The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS).”

Tal como veis otros sistemas que pudieran estar implicados son sistemas autenticación (DNS), servidores NTP… etc. Cuando se define el alcance de PCI DSS sobre el que luego se va a hacer una auditoria PCI DSS estos sistemas no se ven dentro de los “canales” por los que se transmiten, procesan o almacenan datos de tarjetas, ahora bien, si es necesario tenerlos en cuenta en cuanto a su funcionalidad y de cara a cumplir los requisitos de PCI DSS Ej. DNS para ver la autenticación (R. 8 y 9), servidores de back up para mirar back up (R.9), CPD 2 para ver si hay un DRP (R.12), servidores NTP y servidores de logs (R.10)… pero la pregunta es: ¿estos sistemas deben estar identificados como tal dentro del apartado de alcance del informe? ¿El meterlos dentro del alcance supone que estos servidores deban cumplir todos los requisitos de PCI DSS como el estar correctamente bastionados? Y lo más duro… ¿los segmentos de red donde están estos servidores deben ser escaneados y realizarse test de intrusión?

Mi opinión es la siguiente:
Entiendo que los sistemas que no trasmiten, procesan o almacenan datos de tarjeta, como propongo en el caso primero no deberían estar dentro del alcance de PCI DSS.

En cambio, en el segundo caso estos sistemas no estarían dentro de los canales de datos de tarjeta pero si dentro del alcance de PCI DSS únicamente en cuanto se vean afectados como sistemas auxiliares para el cumplimiento de ciertos requisitos PCI DSS y no como si fueran componentes de sistemas tal como define PCIDSS.

Por ejemplo un sistema de monitorización no debería cumplir todos los requisitos de PCI DSS pero si debería garantizar en su definición los requisitos del requerimiento 10 de PCI DSS: estar ubicado en un segmento de red interno, correctamente configurada la hora mediante NTP, garantizar integridad y disponibilidad de logs,…

Raúl Rodríguez Celaya
Departamento de Consultoría

Fuente: S21Sec

Dudas a la hora de definir el alcance de PCI DSS

septiembre 6, 2011 § Deja un comentario

Dentro de PCI DSS la definición del alcance resulta un requisito fundamental a la hora de establecer los sistemas de información que van a ser afectados por el cumplimiento de los requisitos de PCI DSS.

Por otro lado la segmentación de red resulta un paso muy útil para reducir este alcance y así aminorar en gran medida la implantación de los requerimientos de seguridad y abaratar de forma importante el coste de implantación de los mismos. Ahora bien la segmentación no es una cuestión baladí teniendo en cuenta que la mayoría de redes que predominan entre los afectos al cumplimiento de este estándar han sido creadas bajo necesidades de negocio y no para el cumplimiento de PCI DSS, y consiguientemente el hacer una segmentación de las redes supone hacer una reingeniería de procesos informáticos que no es para nada sencilla.

Dentro de este ámbito de la definición del alcance y la segmentación de redes, no son pocas las cuestiones que se suscitan y aquí quiero exponer dos de ellas:

  • Primera: Imaginemos un sistema dentro de un proceso de negocio afectado por PCI DSS (hay PANes involucrados) que en sus funcionalidades sólo es llamado para validar ciertas transacciones del proceso donde los datos de tarjeta no intervienen (este sistema no transmite, procesa ni almacena datos de tarjeta) pero sin cuya existencia la transacción no podría acometerse. No pasan datos de tarjeta, pero si ese sistema es atacado o su disponibilidad cae podría caer todo el proceso de negocio de tarjetas. Si este sistema está en un segmento de red aparte de los sistemas que almacenan procesan, transmiten datos de tarjeta, estaría fuera del alcance del cumplimiento de PCI DSS?
  • Segunda: mirando sobre el alcance de PCI DSS, existen algunos sistemas como por ej. El DNS por los que no pasan, transmiten o se almacenan datos de tarjeta pero que sí están implicados en el cumplimiento de los requisitos de PCI DSS respecto de los sistemas que si están afectados por datos de tarjeta.

Revisando PCI DSS 2.0 se dice lo siguiente “Scope of Assessment for Compliance with PCI DSS Requirements. The PCI DSS security requirements apply to all system components. In the context of PCI DSS, “system components” are defined as any network component, server, or application that is included in or connected to the cardholder data environment. “System components” also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors. The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS).”

Tal como veis otros sistemas que pudieran estar implicados son sistemas autenticación (DNS), servidores NTP… etc. Cuando se define el alcance de PCI DSS sobre el que luego se va a hacer una auditoria PCI DSS estos sistemas no se ven dentro de los “canales” por los que se transmiten, procesan o almacenan datos de tarjetas, ahora bien, si es necesario tenerlos en cuenta en cuanto a su funcionalidad y de cara a cumplir los requisitos de PCI DSS Ej. DNS para ver la autenticación (R. 8 y 9), servidores de back up para mirar back up (R.9), CPD 2 para ver si hay un DRP (R.12), servidores NTP y servidores de logs (R.10)… pero la pregunta es: ¿estos sistemas deben estar identificados como tal dentro del apartado de alcance del informe? ¿El meterlos dentro del alcance supone que estos servidores deban cumplir todos los requisitos de PCI DSS como el estar correctamente bastionados? Y lo más duro… ¿los segmentos de red donde están estos servidores deben ser escaneados y realizarse test de intrusión?

Mi opinión es la siguiente:
Entiendo que los sistemas que no trasmiten, procesan o almacenan datos de tarjeta, como propongo en el caso primero no deberían estar dentro del alcance de PCI DSS.

En cambio, en el segundo caso estos sistemas no estarían dentro de los canales de datos de tarjeta pero si dentro del alcance de PCI DSS únicamente en cuanto se vean afectados como sistemas auxiliares para el cumplimiento de ciertos requisitos PCI DSS y no como si fueran componentes de sistemas tal como define PCIDSS.

Por ejemplo un sistema de monitorización no debería cumplir todos los requisitos de PCI DSS pero si debería garantizar en su definición los requisitos del requerimiento 10 de PCI DSS: estar ubicado en un segmento de red interno, correctamente configurada la hora mediante NTP, garantizar integridad y disponibilidad de logs,…

Raúl Rodríguez Celaya
Departamento de Consultoría

Fuente: S21Sec

¿Dónde estoy?

Actualmente estás explorando la categoría PCI en Seguridad Informática.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 114 seguidores