Analytics

jueves, 28 de agosto de 2014

El PCI SSC publica su Guía para garantizar la Seguridad de Proveedores de Servicio en ámbitos PCI DSS.

El 7 de agosto el PCI SSC publicaba uno de los documentos resultado de dos años de trabajo del SIG (Special Interest Group) creado el año 2012 por el PCI SSC. El objetivo último de este grupo de interés, en el que Internet Security Auditors tenía presencia y participación, siendo la única empresa española participante, ha sido el definir y publicar las directrices que debían tener todas las empresas que contaran con terceros en los procesos de pago afectados por el cumplimiento de PCI DSS.

El resultado ha sido publicado bajo el nombre “Information Supplement: Third-Party Security Assurance” y lo primero que debe tenerse en cuenta es que no modifica ni altera el propio cumplimiento de PCI DSS sino que su objetivo es el de clarificar y profundizar en cómo llevar a cabo el cumplimiento del requerimiento 12.8 de la norma.

El requerimiento 12.8 determina que se ha de “Mantener e implementar políticas y procedimiento para gestionar los proveedores de servicio con los cuales los datos de pago ese comparte o que podrían afectar en la seguridad de los datos de pago”. Estas terceras empresas serán las que denominaremos Proveedores de Servicio Terceros (emplearemos el término en inglés TPSP, Third-Party Service Providers).

Esta nueva Guía se centra en cuatro aspectos clave que deben tener presentes todas las organizaciones (en la Guía se denominan “entities”) que contraten servicios a estos TPSP:
  1. Antes de establecer acuerdos o contratar sus servicios debemos llevar a cabo procesos de diligencia debida para confirmar que sus capacidades y experiencia son adecuadas para garantizar el cumplimiento.
  2. Será clave tener muy claro que responsabilidades de cumplimiento deberán ser llevadas a cabo por los TPSP contratados y cuales seguirán siendo nuestras a fin de ser capaces de evaluar el impacto sobre la seguridad del entorno PCI DSS que implica contar con el TPSP.
    Aun cuando se deleguen responsabilidades al TPSP, el responsable último del cumplimiento seremos nosotros independientemente de las responsabilidades definidas entre ambas partes.
  3. Será imprescindible trasladar a Acuerdos, Políticas y Procedimientos las responsabilidades y obligaciones de cumplimiento que el TPSP deberá conocer, asumir y cumplir.
  4. Monitorizar el cumplimiento de PCI DSS del TPSP será una actividad a incluir dentro del propio cumplimiento por lo que únicamente conociendo de forma detallada el o los servicios ofrecidos por el TPSP podremos conocer su efecto en nuestra evaluación de cumplimiento.
En las Figuras 1 y 2 se esquematizan los pasos que deberían seguirse en el proceso de contratación y validación de un TPSP adecuado para ser incluido dentro de nuestros procesos de pago.



Algo que merece especial atención de la Guía es la referencia a su pretendida audiencia, haciendo foco en tres tipologías de organizaciones: empresas que piensen contar con terceros dentro de sus procesos de pago (comercios, proveedores de servicio, adquirientes, emisores, etc.), los propios proveedores de servicio que quieran dar estos servicios de forma adecuada con un nivel de cumplimiento de PCI DSS y quieran conocer cuáles son sus responsabilidades y, por último, las entidades adquirientes (bancos adquirientes, bancos comerciales instituciones financieras) que ofreciendo servicios a los comercios son responsables de asegurar que éstos trabajan con TPSP que implementan medidas adecuadas de seguridad.

Según la Guía, será conveniente para comercios y proveedores de servicios que se valide y contraste con la entidad adquiriente con la que se pueda estar trabajando que el TPSP escogido es aceptado por esta. Para los comercios esto podrá ser una muestra de diligencia debida y de implicar a su entidad adquiriente en las responsabilidades posteriores en caso que se produjera un incidente donde su TPSP estuviera involucrado.

Centrándonos en los proveedores de servicio TPSP que estarían incluidos y deberían leer esta Guía, la lista es extensa, por mencionar algunos según la clasificación del propio documento:
  • Organizaciones involucradas en el almacenamiento, procesamiento y transmisión de datos de pago (Cardholder data, CHD) como Call centers, proveedores de pago de e-commerce, procesadores y pasarelas de pago, servicios anti-fraude, de análisis de crédito, etc.
  • Organizaciones involucradas en la protección del CHD: destrucción de medio físicos y electrónicos, almacenamiento de datos lógicos o soportes lógicos, empresas que ofrecen servicios de cifrado y tokenización de CHD así como proveedores de soluciones servicios de gestión e inyección de claves de cifrado, proveedores de soluciones y servicios de aplicaciones de e-commerce y móviles, etc.
  • Organizaciones involucradas en la protección del Entorno de Datos de  Tarjetas (Cardholder Data Environment, CDE): proveedores de servicios de infraestructura, de gestión de firewalls/routers, de alojamiento seguro de centros de datos, de monitorización y gestión de alertas de seguridad de IDS, AV, detección de cambios, etc.
  • Organizaciones que pueden tener accesos incidentales al CHD o el CDE: proveedores TIC, compañías proveedoras de desarrollo de software como de aplicaciones web, empresas de servicios de mantenimiento.
Es muy posible que cualquier empresa que ofrezca servicios a una entidad que deba cumplir con PCI DSS tenga que revisar con “detenimiento” cuáles son las implicaciones de cumplimiento en los servicios contratados por sus clientes. Este ejercicio de evaluación debería llevarse a cabo en el proceso de presentación de ofertas o contratación dado que estos requerimientos podrían aparecer durante el proceso de selección de proveedores de su potencial cliente o, incluso, una vez éste hubiera contratado sus servicios.

El documento integro puede descargarse desde la sección “Info Supps” de la Librería del PCI SSC:

https://www.pcisecuritystandards.org/security_standards/documents.php
https://www.pcisecuritystandards.org/documents/PCI_DSS_V3.0_Third_Party_Security_Assurance.pdf

Desde Internet Security Auditors vamos a seguir participando en los SIG que el PCI SSC seleccionará mediante una votación abierta de las iniciativas candidatas este año y que consideramos que permiten, gracias a la participación abierta, la mejora en las normas PCI en general y en los procesos de adecuación y cumplimiento.

Si su empresa requiere ayuda sobre el cumplimiento o quiere conocer cómo podemos ayudarle para alcanzarlo de la forma más pragmática posible, contacte con nosotros a través del correo pcidss@isecauditors.com, a través de los formularios de contacto de nuestra web, redes sociales o teléfono.

jueves, 21 de agosto de 2014

Internet Security Auditors se une a la iniciativa del PCI SSC como Password for Payments Ambassador (#P4P14)



El Consejo de Estándares de Seguridad PCI (PCI SSC), un foro mundial abierto para el desarrollo de los estándares de seguridad de tarjetas de pago, ha iniciado una llamada a 50 organizaciones para dar un paso adelante en un esfuerzo de colaboración para aumentar la concienciación sobre la seguridad del pago en la comunidad global de las empresas.

Los Password for Payments Ambassador (#P4P14) educarán a las empresas sobre el uso de contraseñas seguras en los dispositivos y ordenadores de punto de venta para reducir las posibilidades de ser hackeadas.

Desde Internet Security Auditors hemos querido participar de esta iniciativa, para poder aportar nuestra amplia experiencia y conocimientos.

Puedes seguir todas las novedades desde Twitter con el hashtag #P4P14

viernes, 8 de agosto de 2014

Participamos en la No cON Name ’14 (#ncn2k14)

El próximo mes de octubre se celebra en el CosmoCaixa de Barcelona una nueva edición de la No cON Name, el congreso tiene lugar en un momento en el que la seguridad de equipos informáticos y la información se han convertido en la principal preocupación para todo tipo de organizaciones y particulares.

El comité del congreso ha escogido en su CFP la ponencia de Vicente Aguilera: Vigilados: Explotando las redes sociales para predecir nuestro comportamiento, dónde se expondrá cómo las redes sociales son una fuente de información sobre nuestra vida profesional y personal. 

Entre estas redes, Twitter destaca por la actividad de sus usuarios dada la facilidad de uso y su simplicidad. No obstante, en muchas ocasiones, no somos conscientes de todos los datos que facilitamos (directa o indirectamente) y del uso que un tercero puede realizar de la información que publicamos. 

Se presentará una nueva versión, desarrollada específicamente para el congreso No cON Name, de la herramienta Tinfoleak, mostrando casos reales de uso para explotar la información existente en redes sociales. La información obtenida por Tinfoleak puede tener uso a varios niveles:
  • En Ingeniería Social: la herramienta permite obtener información, entre otra, sobre la ubicación de los usuarios (como lugares habituales que frecuenta: residencia, lugar de trabajo, restaurante preferido, etc.) y predecir dónde se encontrará en una determinada fecha y franja horaria.
  • En Hacking Ético: permite identificar aplicaciones utilizadas por el usuario, sistemas operativos, metadatos existentes en las imágenes, etc.
  • En Vigilancia de Marca y Reputación: la herramienta permite conocer de qué habla un usuario, con quién habla, en qué fechas y franjas horarias, etc.

Esperamos que este pequeño resumen haya servido para ir abriendo boca y anime a todos a asistir al congreso de este año…

¡Os esperamos en la No cON Name 2014! #ncn2k14
https://www.noconname.org/

lunes, 4 de agosto de 2014

Internet Security Auditors Official Training Provider del SecureIberia ‘14



El próximo 16 de septiembre el (ISC)2 celebra por primera vez en Madrid, uno de sus encuentros para profesionales de la Seguridad TIC, el SecureIberia Conference.

Estas Conferencias se han organizado para que los asistentes adquieran conocimientos y herramientas para impulsar las oportunidades de mejora y asegurar su negocio con mayor eficacia contra el riesgo.

Desde Internet Security Auditors, como Official Training Provider, queremos invitar a todos aquellos que estén interesados en mejorar la seguridad de su negocio.

Y para los asistentes no miembros, ofrecemos un descuento especial del 50% en su asistencia registrándose con el este código: ISCISECAUDITORS.



Claves para la ejecución del análisis de riesgos requerido por PCI DSS

PCI DSS y el análisis de riesgos
Dentro de los requerimientos PCI DSS hay uno específico que requiere la implementación de un análisis de riesgos sobre el entorno de cumplimiento PCI DSS. Se trata del requerimiento 12.2 y un error común en las empresas que abordan por primera vez una adecuación al estándar PCI DSS consiste en no dar la suficiente importancia a este requerimiento, que es simple en su definición pero complejo en su ejecución. Su dificultad se entiende fácilmente si pensamos en que implica la colaboración de diferentes roles, un análisis en profundidad del entorno y la toma de decisiones para definir un plan de acción consensuado, justificado y alineado con PCI DSS.

Tal es la complejidad que el PCI SSC ha definido un documento de soporte que ayuda a clarificar los aspectos críticos a tener en cuenta en la implementación de este requerimiento. 

https://www.pcisecuritystandards.org/documents/PCI_DSS_v2_Risk_Assmt_Guidelines.pdf


Características del análisis de riesgos
Existen una serie de conceptos que se deben tener en cuenta en el momento de ejecutar o auditar un análisis de riesgos:
  • Metodología. Debe aplicarse una metodología reconocida.  El propio requerimiento proporciona ejemplos de las metodologías permitidas (Octave, ISO27005, NIST). Existen dos opciones:
    • Basarse plenamente en una metodología reconocida.
    • Definir una metodología propia basándose en una reconocida conservando los conceptos básicos de la misma.
    El documento de la metodología debe definir las actividades a realizar y los criterios a seguir para la determinación del riesgo.
  • Alcance. Debe incluir todos los activos dentro del entorno PCI DSS incluyendo procesos, personas, terceros y tecnologías. Todo componente que de alguna manera pueda suponer un riesgo para la protección de las tarjetas debe estar representado en el análisis de riesgos. Una forma de simplificar esta representación consiste en el uso de dependencias entre los activos.
  • Criticidad de los activos. Podemos obtener la criticidad de los activos de muchas fuentes de información. Por ejemplo:
    • Valoración de los propietarios o responsables de los activos. Las opiniones tienen que ser imparciales por lo que es recomendable consultar a los responsables de los diferentes procesos o servicios sobre la importancia de todos los procesos dentro del alcance, incluso de los que no son responsables, o bien consultar a un responsable que tenga una visión global del negocio.
    • Basarse en la información del Bussiness Impact Analysis, del Bussines Continuity Plan u otro análisis anterior en el que los activos hayan sido  clasificados según su criticidad e impacto en la organización.
  • Análisis de las amenazas. En ocasiones es útil partir de los catálogos de amenazas existentes y públicos. Se trata de catálogos basados en estadísticas y son generales para cualquier tipo de empresa, por lo que resulta necesario un trabajo de personalización para adecuarlo a las características de la empresa analizada. Por ejemplo: si el personal de la empresa lleva 30 años trabajando en ella se puede considerar que es menos probable que haya un ataque interno que en una empresa con un alto grado de rotación del personal.

    En cualquier caso, partamos de unos catálogos estándares o partamos de cero, el  análisis interno para determinar las amenazas existentes debe tener en cuenta los incidentes de seguridad detectados en la empresa.

    También hay que tener en cuenta que las amenazas resultantes se deben asociar a los activos dentro del alcance. Evidentemente no es lo mismo lo que le puede ocurrir a un servidor que a una persona.

  • Vulnerabilidades. Cada empresa presenta un escenario diferente de vulnerabilidades. Afortunadamente, la implementación del estándar PCI DSS nos proporciona información que podemos tener en cuenta para representar este escenario de vulnerabilidades en el análisis de riesgos. Hay ciertas tareas que proporcionan la información que necesitamos, por ejemplo:
    • Escaneos trimestrales de vulnerabilidades: externos ASV, internos y wifi.
    • Tests de Intrusión.
    • Revisión de las reglas de los firewalls. 
    • Revisión de código.

    Adicionalmente se debería tener en cuenta la actividad de la empresa, el sector, el beneficio para el atacante, el grado de exposición y cualquier otro parámetro que ayude a determinar lo vulnerable que es la empresa.
  • Análisis de los controles de seguridad implementados. Se trata de evaluar cuál es la situación de la empresa en cuanto a seguridad y para ello se evalúan diferentes controles de seguridad de diferentes ámbitos (físico, lógico, legal…). El estándar PCI DSS proporciona un marco de referencia en cuanto a controles de seguridad a evaluar, aunque también es posible completarlo con otros estándares que hayan podido ser utilizados en la empresa.
  • Riesgo. La metodología de análisis de riesgos debe definir cómo afectan los conceptos anteriores al cálculo del riesgo. Básicamente, la lógica nos dice que el riesgo será proporcional a la criticidad del activo, a las amenazas y a las vulnerabilidades e inversamente proporcional a las medidas de seguridad implementadas.

    A continuación será necesario definir estrategias de tratamiento de riesgo y una priorización de los riesgos a tratar. Sobre este concepto hay dos peculiaridades a tener en cuenta:
    • Teniendo en cuenta que se trata de un análisis de riesgos orientado a la protección del entorno PCI DSS, los riesgos más críticos son los que afectan a la confidencialidad de los datos de las tarjetas.
    • Dentro de las acciones posibles para el tratamiento del riesgo no existe la posibilidad de aceptar, transferir o compartir el riesgo si esto resulta en la no implementación de alguno de los requerimientos PCI DSS.
  • Plan de acción. La definición del plan de acción es un requisito imprescindible y su ejecución se verificará durante la siguiente auditoría. Este plan de acción estará alineado con los análisis y las conclusiones anteriormente comentadas.
¿Qué aporta a PCI DSS el análisis de los riesgos?
PCI DSS contempla varios ámbitos de seguridad: seguridad en la red, sistemas y aplicaciones, desarrollo, gestión de terceros, recursos humanos... Podríamos pensar que su implementación no debería dejar ningún cabo suelto, pero no podemos olvidar que el estándar PCI DSS es precisamente eso, un estándar que se aplica a todas las empresas afectadas por PCI independientemente de lo diferentes que sean entre ellas. Es por ello que, a veces ocurre que hay carencias de seguridad que únicamente se podrían asociar al requerimiento del estándar PCI DSS  12.2  que requiere realizar un análisis de los riesgos.

Por lo tanto, si hay una carencia en seguridad esto supone un riesgo que debe contemplarse y tratarse dentro del Análisis de Riesgos. Su implementación debe entenderse como una ayuda definitiva  para mejorar la seguridad en el entorno PCI DSS.

La última versión del estándar PCI DSS publicada en Noviembre del 2013 añade una aclaración sobre el requerimiento 12.2. No sólo es necesario realizarlo anualmente, sino también cada vez que se realice un cambio importante en la organización. Bajo estas nuevas circunstancias los resultados de un análisis de riesgos pueden quedar totalmente obsoletos.

PCI DSS vs ISO/IEC 27001
Hemos visto muchos mapeos y tablas de equivalencia entre los requerimientos PCI DSS y la norma ISO/IEC 27001. De hecho, es fácil crear falsas expectativas de cumplimiento de los  requerimientos PCI DSS en empresas y entidades que se han certificado o han hecho trabajos de implementación sobre el estándar ISO/IEC 27001. Sin embargo, es necesario tener en cuenta que hay una diferencia muy grande entre los dos estándares.
  • La ISO/IEC 27001 se basa en un ciclo de mejora continua y en la elección de los controles de seguridad a implementar basándose en los resultados de un análisis de riesgos. Permite por lo tanto cierta flexibilidad para decidir hasta dónde queremos reducir el riesgo y cómo lo vamos a conseguir, todo ello con el conocimiento y la autorización de la Dirección.
  • El estándar PCI DSS establece unos requerimientos obligatorios para todas las empresas a las que aplique dicho estándar. El no cumplimiento de uno de los requerimientos determina el no cumplimiento del estándar. Así pues la flexibilidad permitida es poca o nula y se apoya simplemente en la definición de controles compensatorios.
Aun así podemos decir que el cumplimiento del estándar PCI DSS facilita el cumplimiento de la ISO y viceversa.

La nueva versión de la ISO/IEC 27001
La nueva versión de la ISO/IEC 27001 aporta más flexibilidad en la elección de una metodología para implementar el ciclo PDCA (Plan, Do, Check, Act) y  reestructura la organización documental afectando tanto al lugar donde típicamente se documentaban ciertos controles como en la obligatoriedad o no de definir ciertos documentos. La nueva versión de la ISO realiza un cambio de enfoque, mira todo el proceso desde el punto de vista de la organización , no da la posibilidad de “olvidar” dentro del análisis un proceso que pueda afectar a la seguridad de los activos esté dentro o no dentro del entorno a certificar.
Aunque el PCI SSC por el momento no ha actualizado el documento “PCI DSS Risk Assessment Guidelines” anteriormente mencionado, es posible que en el futuro intente alinearlo con esta estrategia. Quizá el cambio más probable consistirá en  aclarar (porque ahora mismo está implícito) que el alcance del análisis de riesgos debe incluir todos los procesos que puedan afectar a la seguridad del entorno PCI DSS y no solamente los activos directamente afectados por el cumplimiento del estándar. Otro posible cambio podrá consistir en aportar más flexibilidad en los elementos que ahora mismo está requiriendo dentro del análisis (gestión de amenazas, vulnerabilidades…). Sin embargo, para considerar realmente cómo afecta los cambios en los requerimientos del análisis de riesgos contemplado dentro de la ISO/IEC 27001 tendremos que esperar a la nueva versión del documento "PCI DSS Risk Assessment Guidelines”.


Autor: Núria Colinas - CISM, CISA, CISSP, PCI QSA, CHFI, ITILF, MCSA
Departamento de Consultoría.