25 octubre 2010

Cifrado punto a punto (point-to-point encryption)

El pasado 5 de octubre, el PCI Council publicaba una guía denominada "Initial Roadmap: Point-to-Point Encryption Technology and PCI DSS Compliance" (pdf) dada la importancia creciente de esta tecnología (más conocida como P2PE) y las muchas interpretaciones a su alrededor, tanto de fabricantes como QSAs a los que les tocaba lidiar con ellas dado que son un método efectivo y eficiente para simplificar el cumplimiento con el estándar. En España, por ejemplo, es muy conocida la propuesta de las redes denominada SNCP - Solución Normalizada de Cifrado de Pista que precisamente es una implementación de P2PE desde el terminal hasta dichas redes.

Lo primero que hemos de decir es que se trata de una guía escrita desde la perspectiva del merchant y que, por tanto, NO cubre todas las posibles variantes que nos podemos encontrar, es decir, no es un análisis exhaustivo y lo que para mi es más importante, NO define los requerimientos para validar una solución P2PE como válida desde la perspectiva de PCI-DSS (para eso tendremos que esperar a un nuevo documento que verá la luz en 2011 y que llevará por título, "Validation Requirements for Point-to-Point Encryption").

Una vez dicho esto, vamos a identificar los aspectos que son más importantes IMHO:
  • En primer lugar, destacar que aunque el PCI Council ya se había pronunciado (artículo #10359 de las FAQ) y dejado fuera del alcance los datos cifrados siempre que la entidad depositaria no tuviera medios para descifrar, se nos abre una nueva vía: Si una Entidad puede validar que los entornos y los medios utilizados para el cifrado cumplen con los estándares de la industria recogidos en la publicación comentada anteriormente entonces, la Entidad puede considerar que el alcance se reduce a los entornos de cifrado y/o descrifado. Es decir que, incluso si la Entidad tiene capacidad de descifrar los datos pero cumple con los requerimientos que vendrán, también podría reducir el alcance de la validación.
  • Para determinar correctamente el alcance, el merchant debe realizar un ejercicio de descubrimiento de datos para verificar que no existe ninguna fuga de Datos de Titulares de Tarjeta - DTT del entorno P2PE al resto de sistemas (cualquier dispositivo que no esté adecuadamente segmentado seguirá estando dentro del alcance de PCI-DSS).
  • Para maximizar el aprovechamiento del P2PE, el cifrado se debe producir en el primer punto de interacción con la tarjeta mediante un dispositivo seguro y tamper-resistant.
  • Se reconoce que las tecnologías P2PE son una forma de simplificar el proceso, pero que no eximen de la necesidad de mantener y validar el cumplimiento con PCI-DSS.
  • Los requerimientos de validación tocarán aspectos que pueden ser gestionados por distintas partes y que, además, no se limitarán a su implantación inicial sino que incluirán también aspectos relacionados con su operación y mantenimiento. Algunos ejemplos de áreas que se tocarán son: el dispositivo de cifrado, la aplicación de pagos, gestión de claves y operación del cifrado y/o descifrado (que serán ampliados por el documento de validación), etc.
Para finalizar, un aspecto que me ha resultado interesante como son las amenazas principales de este tipo de tecnologías puesto que me ha gustado ver reflejadas muchos de los aspectos que tuve considerar hace bastante tiempo, la primera vez que me toco lidiar con este tipo de tecnologías y tuvimos que "inventarnos" desde cero como validar una solución de este tipo. Os dejo con la relación de amenzas del PCI Council:
  1. Vuelta a las transacciones no cifradas por algún aspecto técnico.
  2. Datos de titulares de tarjeta históricos.
  3. Listas blancas (es decir, relaciones de tarjetas que el merchant desea mantener, normalmente, tarjetas affinity).
  4. Datos impresos de las tarjetas.
  5. Datos obtenidos por los merchants por otros medios.

 ... ¿Todavía no me sigues en twitter.com/antonio_ramosga?

16 octubre 2010

Reglamento de prevención de riesgos...

Según acabo de leer, se ha aprobado un Reglamento de los Servicios de Prevención:
 
Este reglamento delimita cuáles deben ser los recursos materiales y humanos mínimos en cada empresa, los requisitos de acreditación como empresa de prevención de riesgos laborales por parte del Ministerio de Trabajo o la correspondiente CCAA que tenga cedido el área de prevención así como el control de modificaciones y variaciones que se lleven a cabo en las empresas que deban ser comunicadas a la autoridad laboral.

El reglamento establece también la obligatoriedad de los informes anuales de las empresas de prevención de riesgos y su estandarización para la inscripción en un registro controlado por el Ministerio de Trabajo y define claramente los criterios de aceptación o denegación de las autorizaciones para la puesta en marcha de una empresa de prevención.
 
Dado que la seguridad de la información no deja de ser otro ejercicio de gestión de riesgos, las empresas que se dedican a prevenir los riesgos tecnológicos, ¿deberían estar reguladas? ¿debería existir una obligación legal para que las empresas previeran sus riesgos tecnológicos al igual que hacen con los riesgos laborales? Evidentemente, lo que se pierde en unos casos y otros no es comparable, pero desde el punto de vista empresarial, no cabe duda que hay empresas que están consiguiendo mejores resultados por incurrir en riesgos extraordinarios y que exceden los límites deseados para la sociedad en su conjunto (servidores puente infectados para crear botnets, que lanzan DDoS o envían spam, etc.)

Supongo que no estamos maduros para esto, pero no creo que sea descabellado pensar que a largo plazo veremos llegar algo así (creo que ya se empieza a atisbar con la problemática de la protección de las infraestructuras críticas)...

 ... ¿Todavía no me sigues en twitter.com/antonio_ramosga?

01 octubre 2010

Jornadas Técnicas ISACA Madrid

Esta semana han tenido lugar las Jornadas Técnicas organizadas por el capítulo de Madrid de ISACA. En mi opinión han sido todo un éxito, tanto en nivel de asistencia como en el de representatividad de ponentes y asistentes.

Una de las cosas que me ha sorprendido gratamente ha sido lo poco que decayó la asistencia según las jornadas fueron evolucionando, tanto el primer día por la tarde, como el segundo día, el nivel fue más que aceptable.

En cuanto a las ponencias, las que más me gustaron por su temática fueron las del control de servicios externalizados (Rocío Troyano, BDO) y la de seguridad en el cloud computing (Luís Buezo, CSA-ES). También me gustaron Luís Carro (Deloitte) y Javier Garzas (Kybele Consulting) porque realizaron unas ponencias amenas y demostraron un gran conocimiento de la temática que presentaban.

Si hubiera que ponerle un pero, sería quizás que se hubiera generado un poco más de debate en la mesa redonda, pero ya sabemos que eso depende de muchos factores...

En definitiva, mi enhorabuena a los organizadores (y patrocinadores, claro).

 ... ¿Todavía no me sigues en twitter.com/antonio_ramosga?