02 noviembre 2010

PCI-DSS y EMV: Complementarios o alternativos

Continuando con el post anterior vamos a comentar el otro documentado liberado por el PCI Council a principios de octubre relativo a la aplicabilidad de PCI-DSS en los entornos EMV [pdf]. Ante la duda que podía surgir sobre si en los entornos EMV debíamos aplicar también el estándar PCI-DSS, el Council lo deja bastante claro: Hoy por hoy, dado el grado de implantación de EMV, hay que seguir cumpliendo con PCI-DSS, es decir, son COMPLEMENTARIOS.

Las razones que aduce el Council son bastante lógicas:
  • EMV ha sido diseñado para frenar el fraude en operaciones de tarjeta-presente, pero EMV, por sí mismo, no protege la confidencialidad de los datos de autenticación sensibles ni de los datos del titular de la tarjeta (tanto el PAN, como el nombre del titular o la fecha de caducidad, por ejemplo, son transmitidos en claro. lo cual es suficiente para realizar transacciones en algunas situaciones).
  • Los entornos EMV actuales procesan tanto transacciones EMV como no-EMV, por lo que es necesario seguir aplicando PCI-DSS (está situación se acrecienta si consideramos que las tarjetas EMV llevan banda magnética por razones de compatibilidad y como backup del chip).
  • Existe la posibilidad de introducir transacciones manualmente, para lo que solo se necesita el PAN, la fecha de caducidad y la firma del cliente (en el caso de venta por correo o por teléfono, denominadas tarjeta-no-presente, es necesario también el código de servicio).
Lo que sí reconoce el estándar es que en la medida en la que EMV sea el único método para transacciones cara-a-cara y se adopten procesos robustos de autenticación para transacciones de tarjeta-no-presente, la necesidad de mantener secreto el PAN y el resto de datos de autenticación se verá sensiblemente reducida y, por tanto, el estándar PCI-DSS deberá adaptarse a esta nueva situación y ser modificado en consecuencia.

 ... ¿Todavía no me sigues en twitter.com/antonio_ramosga?
 
Más información sobre EMV | www.emvco.com
 

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?

23 septiembre 2010

Cita

[Micropost]

Hace unos meses, me pidieron una cita sobre seguridad que se pudiera incorporar a una web que se estaba creando. Ni que decir tiene que me sentí muy orgulloso y alagado por tal solicitud. Finalmente, por razones que no vienen al caso, no ha podido ser, pero ya que trabajamos sobre ella, me he dicho, "chico, publícala tú y así, al menos, aprovecharemos algo el trabajo realizado". Así que, aquí la tenéis:
 
"Cualquier inversión en seguridad está justificada siempre que: el nivel de seguridad sea el factor limitante para que la organización alcance su meta o la seguridad se subordine al factor limitante de la organización y contribuya a que rinda a su máxima capacidad".
 
Os dejo un link a una versión antigua...(Actualización: La versión cacheada tampoco contiene ya la cita... que le vamos a hacer)
 
 ... ¿Todavía no me sigues en twitter.com/antonio_ramosga?

20 septiembre 2010

Lectura: "¿Existe la suerte? Las trampas del azar"

Esta ha sido la última lectura del verano. Como no tuve suficiente con "El cisne negro" y debo ser un poco masoquista, pues me puse manos a la obra con su predecesora... 

La obra tiene el estilo propio de Nassim, ya sabéis ácido y un poco irreverente y provocador... vamos, para no dejar indiferente a nadie. Por lo demás, vuelve a ser un libro duro de leer, denso y con muchos conceptos que hay que masticar bien antes de digerirlos pero, señoras y señores, ¡es lo que hay!.
 
Básicamente, el libro da vueltas alrededor de una idea principal que resume el propio autor casi al principio de la obra: "el trabajo duro, consciente de los riesgos y la disciplina, puede hacer que una persona logre una vida cómoda con un alto grado de probabilidad. Lo demás es mero azar: ya sea aceptando enormes riesgos, o siendo extraordinariamente afortunado. El éxito moderado se puede explicar por las habilidades y el trabajo. Un éxito enorme sólo es atribuible a la varianza".

Quizás en este libro se vea más la influencia como operador bursátil de Nassim, pero al final, lo que importa son los conceptos sobre probabilidad, estadística y percepción del riesgo que transmite, puesto que son aplicables con carácter general.

Hay un pasaje bastante interesante para los que trabajamos en seguridad. Al tratar de explicar que la realidad es incluso más "viciosa" que los juegos de azar, Nassim da tres razones. Primero, porque existen sucesos que pasan muy pocas veces. Segundo, porque en la vida real uno no sabe cuántas opciones existen, es decir, no podemos ver el generador de la aleatoriedad. Y, finalmente, porque existe "un factor de ingratitud cuando se advierte a la gente sobre algo abstracto (por definición, cualquier cosa que no ha ocurrido es abstracta). Digamos que participa en un negocio para proteger a los inversores de los sucesos raros [...] Digamos que no ocurre nada durante el período. Algunos inversores se quejarán de que ha estado desperdiciando su dinero; algunos intentarán que se sienta arrepentido." ¿Os suena a alguna/o?
 
Para finalizar, como siempre, una selección de fragmentos que me han resultado interesantes por uno u otro motivo:
 
"Las cosas que llegan con poca ayuda de la suerte resisten más al azar"
"No importa la frecuencia con la que algo tiene éxito si es demasiado caro asumir el fracaso (sesgo)"
"Los héroes son héroes porque su comportamiento es heroico, no porque hayan ganado o perdido (Patroclo)."
"... también es un hecho científico, y uno sorprendente, que tanto la detección del riesgo como la evitación no se resuelven en la parte "pensante" del cerebro, sino en la parte emocional."
"El hombre sabio escucha el significado, el idiota sólo percibe el ruido."
"... una persona que sólo tiene un conocimiento casual sobre los problemas del azar creerá que un animal tiene la máxima aptitud para las condiciones de su época. Esto no es lo que la evolución quiere decir; de media, los animales serán aptos, pero no todos y cada uno de ellos, y no en todo momento."
"Nadie acepta el azar en su propio éxito, sólo en su fracaso".
"La mayoría de nosotros sabe muy bien cómo debería comportarse. Es la ejecución lo que constituye un problema, no la ausencia de conocimiento".

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

18 agosto 2010

Lectura: "La reina del sur"

Como dice la crítica en contraportada del Publishers Weekly: "Los lectores no podrán pasar las páginas lo suficientemente rápido. Una historia apasionante". Y es que las más de 500 páginas han caído en una semana, más o menos.

Empecé a leer a Pérez-Reverte (@perezreverte) en 'Territorio Comanche' y luego, como no podía ser menos, me enganché al Capitán Alatriste... y al oír que se iba a empezar a rodar una serie para TV en Colombia partiendo de esta novela, me decidí a leer "La Reina del Sur".

¿Qué puedo decir? Que te engancha, que quieres saber ya que va a pasar y que, todo ese viaje interior por la evolución de la Reina del Sur y su maduración a base de  las hostias que le va dando la vida es increíble.

Además de eso, pues que, como extremeño adoptivo, me ha encantado que un rincón de Extremadura tuviera su paginita de protagonismo y que, como apasionado de la seguridad, pues también ha habido un parrafito para ella:

"Teresa lo había reclutado porque era capaz de camuflar los contactos operaciones a través de Internet, desviándolo todo bajo la cobertura ficticia de países sin acceso para las policías europeas y norteamericana: Cuba, India, Libia, Irak. En cuestión de minutos podía abrir, usar y dejar dormidas varias direcciones electrónicas camufladas tras servidores locales de esos u otros países, recurriendo a números de tarjetas de crédito robadas o de testaferros. También era experto en esteganofrafía y en el sistema de encriptado PGP."

Respecto a esto, como os podéis imaginar tengo una pega: El uso de cifrar versus encriptar.

Para finalizar, unas cuantas citas, como siempre...

"Nadie está a salvo, y toda seguridad es peligrosa. De pronto despiertas con la evidencia de que resulta imposible sustraerse a la mera vida; de que la existencia es camino, y que caminar implica elección continua."
"Aquellos veraneantes gachupines o gringos con sus calzones floreados y sus pieles enrojecidas y grasientas, sus gafas de sol, sus niños requetegritones y sus carnes rebosándoles bañadores, camisetas y pareos, resultaban peores, más egoístas y desconsiderados, que quienes frecuentaban los puticlubs de Dris Larbi."
"Como apuntó más tarde, filosófico, el propio capitán Castro cuando me acompañaba cortésmente al coche, los Pepitos Grillo nunca hicieron carrera en ninguna parte."
"La clave [...] consistía en que la Mejicana utilizó su experiencia técnica sobre el uso de planeadoras para las operaciones a gran escala."
"Disparo luego existo."

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

09 agosto 2010

Lectura: "CISO soft skills"

Tuve el placer de moderar a Ron Collette, uno de los tres autores de esta obra, en la V Jornada Internacional del ISMS Forum Spain y por fin he sacado un hueco para leérmela - ¿será que ahora tengo más tiempo? :-). Ya Ron, en su momento, me causó una gran impresión, pero su libro ha conseguido mejorarla. Es, sencillamente, genial. Como dicen los anglosajones, "It is a must", vamos, que es de obligada lectura.

Hay varios aspectos que han llamado mi atención:
  • Lo primero, que incluye el concepto de limitación que, como sabéis, para los que nos gusta la Teoría de las Limitaciones (TOC para los amigos) es uno de los conceptos básicos. Según los autores, son cuatro las limitaciones que, en su opinión, limitan el nivel de seguridad en las organizaciones: La apatía, miopía y primacía que se puede observar en los empleados y la infancia en la que se encuentra la seguridad de la información como práctica empresarial.
  • Y lo segundo, que adopta la interpretación de la seguridad en las organizaciones como parte de un sistema dinámico dónde tenemos que manejar conceptos como inputs, outputs, feedback o throughput y entender que todo está relacionado aunque el sistema sea complicado (que no complejo - ver diferencia según el modelo Cynefin [gracias, Mario]) y nos cueste entender las relaciones causa-efecto existentes, ya sea por el volumen, por los retardos o por el motivo que fuera.

En mi opinión, los autores han puesto el dedo en la llaga y coincido plenamente con ellos en que existen limitaciones (no sé si las que ellos han identificado u otras, según los casos) que hacen que las inversiones que realizan las organizaciones en seguridad no tengan el reflejo esperado en el nivel de seguridad que podemos observar en las mismas y que, hasta que no se trabaja en eliminarlas (y para eso, hay que identificarlas primero) las organizaciones no experimentan una mejoría significativa.

En esta ocasión, no voy a finalizar con la típica relación de citas porque he estado repasando mis notas y no sabría con cuál quedarme... me temo que tendréis que leeros el libro para tener más detalles...

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

14 julio 2010

Nueva web de ISACA

¿Qué os parece la nueva web de ISACA? Quizás lo primero y principal que haya que decir es que es muy 2.0, ¿verdad? De hecho, creo que es una apuesta clara por la creación de una web participativa, como lo corrobora el hecho de la desaparición de las listas de correo.

Yo he empezado a trastear un poco en ella hace unos pocos días y, de momento:

  • Me he creado mi perfil.
  • He creado mi propio blog dentro de la web de ISACA (podéis consultarlo en este link) donde traslado algunas de las entradas de Carpe Diem.
  • He definido mis áreas de interés.
  • Incluso me he conectado con algún compañero del capítulo de Madrid que también se ha creado un perfil en ISACA.

En definitiva, como comentábamos, muy 2.0, con sus nubes de tags, la posibilidad de compartir documentos y enlaces y un sistema de puntuación para que los propios usuarios señalen a aquellos que más les aportan (tipo menéame)...

Está claro que todos tendremos que pasar por un período de aprendizaje para "encontrar" en la nueva página dónde están las cosas que buscábamos antes (documentos, tests, la revista...) pero, en mi opinión, me parece una apuesta atrevida, moderna y que, desde luego, demuestra que ISACA está dispuesta a dar un paso adelante como punto de encuentro de los profesionales de la seguridad.

Si hubiera que ponerle algún pero, hoy por hoy, serían, por un lado, su extrema lentitud que, en algunos momentos es desesperante y, por otro, los pequeños fallos que se producen en momentos puntuales y que nos enseñan el MS Sharepoint (R) que subyace al nuevo portal... esperemos que lo solucionen pronto porque ya sabemos que la usabilidad es esencial para que los usuarios no abandonen la página y logren el efecto contrario al deseado.

¿Cuál es vuestra opinión?

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

09 julio 2010

Proporcionando un servicio de seguridad de alta calidad utilizando la identificación de activos

Tenía pendiente comentar este artículo publicado en el volumen 2, 2010 de la ISACA Journal (ya sabéis que hay que ser miembro de ISACA para poder consultarlo) por Vinoth Sivasubramanian (responsable de políticas TI en UAE Exchange Centre LLC).

Vinoth, en su artículo, viene a esbozar un modelo para la toma de decisiones de inversión en seguridad en un entorno como el actual, de elevadas restricciones presupuestarias, que nos obligan a sopesar muy bien dónde invertir los pocos fondos disponibles. El modelo que nos propone Vinoth parte, como no puede ser de otra forma, de la identificación de las necesidades de la organización respecto a la seguridad mediante la identificación de 'especificaciones de requerimientos de seguridad' y lo que denomina CIFs (Critical Impact Factors) o Factores de Impacto Críticos. Estos CFIs recogen el tipo de daño que un incidente de seguridad causaría en la organización y actúan como enlace entre los activos y la Visión del negocio, permitiendo clasificar dichos activos en función de su impacto sobre la mencionada visión. Aunque cada organización puede tener su propia visión, Vinoth identifica tres patrones típicos sobre la base de los trabajos de Michael Treacy y Frederik Wiersema:
  1. Excelencia operativa
  2. Intimidad con el cliente
  3. Liderazgo en producto
Hasta aquí el resumen del artículo. ¿Qué por qué os lo quería comentar? Pues porque me recuerda sobremanera a la aproximación que podemos realizar a la seguridad de la información utilizando la Teoría de las Limitaciones (o TOC - Theory of Constraints para los amigos). Para los que estuvisteis en la rootedCON de este año quizás os sonará, pero el razonamiento es similar:
  1. Debemos identificar los elementos clave de la estrategia de la organización y las condiciones necesarias para que sus objetivos se cumplan (aquí utilizaríamos el Árbol de Objetivos Intermedios) [en las investigaciones con Mario también sospechábamos que, en el fondo, las organizaciones se parecen y se podrían obtener "patrones" de comportamiento].
  2. Una vez identificados los elementos clave, debemos analizar para cuales de ellos, la seguridad es, a su vez, condición necesaria.
  3. El análisis debemos realizarlo en las diferentes dimensiones de la seguridad (a saber, confidencialidad, integridad y disponibilidad... al menos).

El resultado es una lista de áreas en los que la seguridad es una prioridad, una prioridad para que la organización para la que trabajamos cumpla sus objetivos, haga realidad su estrategia.

Lo mejor de esto es que es así de simple, así de rápido y así de eficaz... mucho más rápido que un Plan Director de Seguridad con análisis de riesgos incluido... bueno, para ser exactos, habría que decir que en realidad se hace una análisis de riesgos express.

¿No os lo creéis? Doy fe que es cierto...

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

01 julio 2010

[S21sec)

Sí, sí... no penséis que se me ha ido el dedo y he "colado" los corchetes en el título de esta entrada. Ha sido a propósito: Como los más matemáticos habréis identificado, es la notación que se utiliza para definir los intervalos, en concreto, el corchete denota un intervalo cerrado y el paréntesis un intervalo abierto.

Y toda esta parrafada, ¿para qué? Pues para deciros a todos los que me seguís que S21sec y un servidor hemos decidido poner un punto y a parte en nuestra relación. Efectivamente, desde hoy mismo soy, como se suele decir, un consultor independiente.

Ha sido un paso profundamente meditado y del que espero no tener que arrepentirme... :-) Dado que hemos acabado como amigos, seguro que seguiré colaborando con ellos en el futuro (por eso lo del intervalo abierto) pero ya, desde fuera de la organización; y es que, desde dentro, era imposible desde hacía algún tiempo... como dice [el gran] Sabina: "Me sentía como un pato en el Manzanares".
Tengo algunas ideas para esta nueva etapa, pero eso tendrá que esperar para entradas futuras... ¡sigan atentos a sus pantallas!

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

29 junio 2010

Desarrollando una estrategia de Gestión del Riesgo y de Seguridad de la Información

Este es el título del artículo publicado por John P. Pironti (Presidente de IP Architects LLC) en el volumen 2, 2010 de la ISACA Journal (ya sabéis que hay que ser miembro de ISACA para poder consultarlo). Supongo que algunos de vosotros ya lo habréis leído porque corresponde al número del pasado mes de abril, pero para los que no lo hayáis hecho y os interese la gestión de la seguridad, os recomiendo su lectura. Es un texto, no muy largo, sólo son 8 páginas que se leen rápidamente, pero completo en cuanto al funcionamiento del modelo que nos propone.

Son varias las cosas que me han interesado del artículo pero, yendo por partes, lo primero que me ha hecho reflexionar ha sido la dicotomía que plantea entre las funciones de gestión del riesgo de información y de la seguridad de la información funcional, la primera más consultiva y la segunda, más operativa. He visto esta diferencia de planteamiento en muchas organizaciones y me ha gustado encontrar un "modelo" que recoga esta diferencia de enfoque. Sobre todo, la reflexión de Pironti sobre la circunstancia de que un modelo consultivo enfocado en la gestión del riesgo y alineado con la estrategia de negocio puede ser más recomendable y fácil de implementar que un modelo más técnico y enfocado en el cumplimiento [bueno, como dice muy bien el autor, dependerá de la cultura de la organización].

En segundo lugar, como ya he dicho, el planteamiento exhaustivo que hace, partiendo de la estrategia de la organización y su grado de aversión al riesgo hasta su seguimiento y monitorización pasando por la definición y la implantación de la estrategia. En concreto, Pironti plantea seis fases para el desarrollo de la estrategia:
  1. Concienciación del negocio
  2. Definición de la estrategia
  3. Desarrollo de la estrategia
  4. Métricas y benchmarking
  5. Implantación y operación

Tercero, en relación a la elección de un estándar al que alinearse, estoy de acuerdo en la afirmación de Piroti, "es importante recordar que ningún estándar por sí solo es apropiado para todas las organizaciones, ni ninguna estrategia debería estar basado en una sola opción". Hay ocasiones en las que nos obsesionamos con la implantación de una ISO o COBIT y perdemos un poco la perspectiva o pretendemos ajustar todos los aspectos de nuestra organización, aunque sea con calzador...

Para ir finalizando, dos aspectos que resaltar y que alguna vez se olvidan:
  • La utilización de un comité supervisor como mecanismo que garantice el alineamiento el alineamiento de la función operativa de seguridad con el negocio y como lugar en el que expresar las diferencias respecto a la estrategia planteada.
  • La comunicación debe realizarse mediante el mecanismo más adecuado en cada caso (mezcla de online y presencial) y debe contar con sus propios KPIs.

Y, finalmente, una reflexión que comparto plenamente con el autor: "La verdadera medida del éxito de una estrategia bien desarrollada e implantada la podemos encontrar en las impresiones y acciones de la constituencia a la que sirve. Si utilizan las capacidades de la función durante momentos de toma de decisión claves y consultan con el equipo de forma regular, el éxito ha sido alcanzado."

En fin, un buen artículo que merece la pena analizar. Os lo recomiendo.
... ¿Todavía no me sigues en twitter.com/antonio_ramosga?

24 junio 2010

Mercado para la asignación de recursos

Como habréis podido comprobar por mi entrada anterior, hace unos días que he terminado de leer 'Wikinomics'. Pues bien, casi al final del libro me pasó una anécdota curiosa: hay un apartado dedicado a la asignación de recursos que me hizo recordar una afirmación de un profesor de matemáticas de la carrera que nos dijo que "si se nos ocurría alguna forma novedosa de resolver un problema, debíamos desconfiar... era probable que se le hubiera ocurrido a alguien antes".

El motivo de este dejà vu es una reflexión de hace algún tiempo con Mario en la que le preguntaba sobre la forma de aplicar la Teoría de las Limitaciones y más en concreto, la contabilidad basada en el throughput (el throughput accounting) a la toma de decisiones para llevar a cabo o no un proyecto de consultoría en función de su rentabilidad.

Para los que no estéis familiarizados con esta teoría deciros simplemente que, para calcular el throughput o tasa a la que el sistema genera dinero a través de las ventas, solo se tienen en cuenta los costes totalmente variables (el throughput son los ingresos menos dichos costes totalmente variables) y que, para los casos en los que la limitación es interna (como en el caso que nos ocupa donde tenemos bastantes proyectos y tenemos que elegir por cuál empezar), debemos elegir la opción que maximice el throughput por unidad de tiempo del recurso limitante (o sea, de los consultores).

Suponiendo que en dicho proyecto de consultoría nos encontramos con  gastos de personal (los consultores están en nómina), gastos de desplazamiento y otros gastos indirectos imputados conforme algún criterio objetivo,  de todos ellos, solo consideraríamos  como  gastos totalmente variables de un proyecto aquellos originados por realizar el proyecto, es decir, los de desplazamiento porque los de personal y los asignados de manera indirecta seguirán existiendo con independencia del proyecto. Por tanto, el throughput sería el ingreso generado por el proyecto menos los costes de desplazamiento y, si aplicamos el criterio mencionado anteriormente, deberíamos elegir el proyecto que maximizara dicho throughput, o lo que es lo mismo, el que suponga un mayor precio/hora porque los costes totalmente variables serían prácticamente cero.

Y toda esta parrafada ha sido porque se me había ocurrido que se podría crear un mercado interno en el que, a modo de subasta, se asignaran los recursos a aquel proyecto que, en cada momento, maximizara dicha condición, es decir, el precio/hora del consultor o consultora. Y esto es, justamente, lo que me encontré en 'Wikinomics' en relación a la producción y la asignación de recursos:

"[...] los recursos son mercancías que se pueden comprar y vender, así que ¿por qué no asignarlos desde un enfoque mercantil que garantice que van allí donde más se valoren? Con ello, se eliminan del proceso grandes dosis de "cuestiones políticas" internas y se establece una dinámica en la que los equipos compran y venden acceso a los recursos en función de sus valoraciones independiente sobre lo mucho o poco que los necesitan"

Es decir, como me dijo mi profesor de matemáticas (al que por cierto, no creí): "si se nos ocurría alguna forma novedosa de resolver un problema, debíamos desconfiar... era probable que se le hubiera ocurrido a alguien antes".

Más información | Nodos en la red: Toma de decisiones gerenciales con Throughput Accounting

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


21 junio 2010

Lectura: "Wikinomics. La nueva economía de las multitudes inteligentes"

No es una obra novedosa que digamos (Don Tapscott y Anthony D. Williams la escribieron en... ¡2006!), así que era una especie de deuda que tenía, lo reconozco.

Básicamente se trata de una obra que trata de explicar cómo Internet y los mecanismos de colaboración que incorpora están cambiando y van a cambiar en el futuro aún más los modelos económicos y de relación entre usuarios, empresas y  también  con la administración pública. Como ellos mismos dicen: "En apenas unos pocos años, la colaboración tradicional ha sido desbancada por nuevas colaboraciones de proporciones gigantescas".

Recomiendo su lectura (y la del blog que crearon los autores) a todos aquellos que estéis interesados en Internet y cómo está cambiando nuestras vidas. En concreto, los autores identifican 4 principios que rigen el nuevo modelo: Apertura, interacción entre iguales, compartir y actuación global.

Y ahora, como siempre, unas cuantas citas:

"Igual que ha ocurrido con todas las revoluciones económicas anteriores, las exigencias que recaerán en los particulares, las organizaciones y las naciones serán considerables y, en ocasiones, traumáticas, ya que los sectores y modos de vida antiguos están dando paso a procesos, tecnologías y modelos de negocio nuevos."
"... un mundo más pequeño, abierto e interdependiente posee el potencial de ser dinámico y activo, pero también resulta más vulnerable a las redes de delincuentes y terroristas."
"... la actividad colaboradora [...] amenaza con desplazar intereses arraigados que han prosperado bajo la protección de distintas barreras a la entrada..."
"El colectivismo implica coerción y control centralizado; la acción colectiva implica autoselección elegida con libertad y coordinación distribuida".
"... la verdadera ventaja de la contratación global de servicios no es el ahorro en costes, sino las infinitas posibilidades de crecimiento, innovación y diversidad".
"[La producción entre iguales] se fundamenta en principios meritocráticos de organización; esto es, los miembros más cualificados y con más experiencia asumen el liderazgo..."
"La capacidad de la humanidad para generar nuevas ideas y conocimientos es la fuente del arte, la ciencia, la innovación y el desarrollo económico."
"Colaboración, publicación, revisión por iguales e intercambio de información precompetitiva se están erigiendo en claves de éxito en la actual economía basada en el conocimiento."
"El éxito, pues, genera complacencia."
"Cuando los empleados viven en una estructura jerárquica, hay mucho miedo. [...] Y, debido a todo ese temor, la mayoría de las personas no hacen nada. Dejan que la jerarquía se imponga."
"[...] las medidas de tipo regulatorio sólo sirven como medidas de freno provisionales, nunca como fuentes de una ventaja competitiva duradera para quienes las impulsan."
"La apertura [...] hace aflorar el valor real y obliga a todas las empresas a competir sobre un terreno de juego igualado."
"... la colaboración y la apertura son más un arte que una ciencia."

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

16 junio 2010

España puede ganar el Mundial (o por qué el pasado no es el mejor predictor del futuro)

A pesar del clamor popular existente a nivel mundial [o quizás debido a él] de que España es favorita para ganar el Mundial (baste con ver este ejemplo), no paran de salir noticias en los medios de organizaciones (bancos de inversión y similares) de "reconocido prestigio" por haber elaborado sesudos cálculos que dicen lo contrario (el último este que os adjunto de PwC).

Y os preguntaréis, ¿qué les pasa? ¿que ya no saben que hacer para salir en la prensa y conseguir algo de publicidad gratis? [Bueno, eso también puede ser pero...] No, lo que pasa es que, por una parte, están empeñados en utilizar el pasado para predecir el futuro y entonces nos encontramos, por ejemplo, con que las posibilidades de España de ganar este Mundial son menores debido a nuestra pobre actuación en España'82 (¿?)... yo creo que no hace ni falta, pero por si acaso lo voy a decir. ¿No fue quizás un cisne negro que España ganara la pasada Eurocopa? Yo casi que me voy a fiar más de las opiniones de los expertos que de la Econometría... lo siento.

Y en segundo lugar, sobre-estiman las correlaciones estrictamente matemáticas y eso hace que variables que tienen tanto que ver con el fútbol como la riqueza o el PIB de los países se incluyan en el modelo... casi que también les voy a recomendar otra lectura: Freakonomics.

Me parece que me estoy repitiendo mucho estos últimos tiempos pero es que: ¿Qué probabilidad existía de que una nube de cenizas de una erupción volcánica en Islandia paralizara el tráfico europeo y causara pérdidas millonarias?

En definitiva, lo que quiero decir es que hay que discernir muy bien en qué casos tiene sentido aplicar un modelo económetrico y en cuál no. Y en este caso, me parece que estamos en la segunda opción... ¿no os parece también a vosotr@s?

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

11 junio 2010

¿Puedo utilizar el cifrado de disco para cumplir con PCI DSS?

Pues como dirían el Council o las marcas en el 90% de los casos: "Depende" :)

El cifrado a nivel de disco se puede utilizar en varios contextos (cifrado de datos históricos o en copias de respaldo, por ejemplo) y en cada caso, el QSA deberá determinar si su utilización permite a la organización cumplir con el objetivo del estándar para dicha situación.

Normalmente, una organización se plantea utilizar el cifrado de disco para dar cumplimiento al requerimiento 3.4 del estándar: "Haga que el PAN quede, como mínimo, ilegible en cualquier lugar donde se almacene..." puesto que es más sencillo de aplicar que el cifrado a nivel de base de datos, de logs o de ficheros planos, en general.

Como norma general, hemos de tener en cuenta lo que el estańdar establece para poder dar este mecanismo como válido:
  1. Utilizar "criptografía sólida". Para los que tengan dudas sobre lo que se entiende por este concepto, la aclaración la tenemos en el Glosario de Términos que maneja el Council.
  2. Como todo mecanismo de cifrado que se utilice debe cumplir con los requerimientos 3.5 y 3.6 del estándar, a saber, protección de las claves criptográficas utilizadas para el cifrado de datos y documentación e implantación de procesos y procedimientos de gestión de claves (generación, distribución, etc.)
  3. Y, si se utiliza en lugar de un cifrado de base de datos, también cumplir con el requerimiento 3.4.1 que establece que "se debe administrar un accesológico independientemente de los mecanismos de control de acceso del sistema operativo nativo [...]. Las claves de descifrado no deben estarvinculadas a cuentas de usuarios ".
Para terminar solo quería incluir una breve reflexión sobre este último aspecto puesto que no es trivial. La excepción que incorpora el requerimiento 3.4.1 hace que los típicos sistemas para sistemas "grandes" (servidores corporativos, mainframes) que realizan el cifrado de forma transparente para el usuario y, normalmente, intercambian las claves de cifrado en el momento que se montan los discos en el sistema, a mi entender, NO podrían considerarse válidos para cumplir el objetivo del estándar.

Ahora bien, sistemas a escala puesto de trabajo que incorporan sistemas de autenticación del usuario independiente sí cumplirían con el requerimiento 3.4.1 aunque les quedaría la tarea mucho más ardua de cumplir con los requisitos 3.5 y 3.6.

No sé lo que opináis vosotr@s pero ya sabéis, para eso están los comentarios :)

Por cierto, nótese el uso de cifrar vs. encriptar...

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

08 junio 2010

Gestión de la Seguridad: De la robustez a la capacidad de recuperación

Después de la última entrada sobre la gestión de la seguridad, le he estado dando algunas vueltas más al asunto de cómo deberíamos gestionar entonces la seguridad dado ese gran componente de incertidumbre. Y estando en esas, me llegó una entrada del blog Cognitive Edge (From robustness to resilience) sobre el comportamiento de los vecinos de Gloucester para afrontar las inundaciones recurrentes en la zona.

Básicamente, el razonamiento es que, dado que no se puede hacer nada para evitar las inundaciones, lo mejor es cambiar las infraestructuras para resistir su efecto y poder recuperar la habitabilidad de las casas lo antes posible, es decir, se han centrado en la capacidad de recuperación (hacer que las infraestructuras sean más "elásticas" y recuperen lo antes posible la normalidad).

El caso es que, en relación a la gestión de la seguridad, quizás tendríamos que hacer algo similar y haya llegado el momento de restarle algo de importancia al enfoque de robustez (análisis de riesgos y medidas preventivas) y dársela a lo que podríamos denominar, enfoque de capacidad de recuperación, más orientado a dotarnos de mecanismos que nos permitan continuar funcionando en caso de un incidente (planes de contingencia y continuidad, pero también diseño de infraestructuras que sean más elásticas, que tengan más capacidad de volver a su estado previo).

¿Por qué digo esto? Pues porque según una encuesta de la Harvard Business Review a 1.463 gestores de Supply Chain (cadena de suministros) y áreas de negocio a lo largo de 73 países el reparto de la inversión entre medidas preventivas y reactivas era el siguiente:
  • 54% mayor inversión en medidas preventivas
  • 30% inversión equilibrada entre medidas preventivas y reactivas
  • Y, el 16% restante, mayor inversión en medidas reactivas
En este sentido, si somos clientes de servicios en la nube, nos importará más la capacidad de recuperación del proveedor más que el hecho de que no se vea afectado por ningún ataque, ¿no?

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

02 junio 2010

¿Puedo reducir el alcance de PCI-DSS usando tokenización?

Siguiendo con la serie de preguntas relacionadas con el estándar PCI-DSS tenemos ahora esta relativa a la tokenización que está escrita junto con mi amiga Vanesa Gil (una verdadera experta en esta materia, os lo digo yo).

Bueno, pero entrando ya en materia, lo primero a decir es que la solución de tokenización será válida y permitirá reducir el alcance al que afecta PCI-DSS (ya sabéis, sistemas que almacenan, procesan o transmiten datos de tarjetas), siempre y cuando:
  • Los sistemas que solo tengan acceso al token se encuentren segmentados del resto del entorno que trata datos de tarjetas.
  • La solución de tokenización cumpla con la totalidad de requerimientos establecidos en el estándar.
  • Se garantice el cumplimiento de PCI-DSS en relación con los siguientes aspectos:
    • Algoritmo de creación del token.
    • Algoritmo de cifrado del PAN en la tabla/fichero donde se encuentra la asociación entre el PAN y el token. 
    • Módulo para el acceso al PAN. 

En relación al algoritmo de creación del token, es necesario garantizar que no es reversible (es decir, que se trata de un algoritmo único y de sentido unidireccional).

Adicionalmente, es necesario garantizar que la base de datos en la que se almacena la asociación entre el PAN y el token cumple con lo establecido en el estándar PCI-DSS, en especial, los siguientes requerimientos:
  • Req. 2, relacionado con la configuración segura de los sistemas.
  • Reqs. 7 y 8, relativos al control de acceso lógico.
  • Req. 10, sobre la monitorización.

Para finalizar, la solución de tokenización debe además garantizar que:
  • los sistemas que reciben tokens no pueden revelar o dejar ver el PAN en claro.
  • los tokens transmitidos no permiten revelar o dejar ver el PAN en claro.
Esperamos haberos sido de ayuda, pero si aún tenéis más dudas, ya sabéis que para eso están los comentarios.

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


28 mayo 2010

El objetivo de la gestión de la seguridad

Esta semana tuve la oportunidad de asistir a la charla de Fred Piper durante la VII Jornada Internacional del ISMS Forum (ya os dije que teníais que venir...) y tuve uno de esos momentos reveladores: ya sabéis, ese momento en el que alguien dice algo obvio pero que al verlo escrito negro sobre blanco impacta sobremanera sobre uno.

En concreto, fue una frase de Fred en la que venía a decir algo así como que el objetivo de la gestión de la seguridad era minimizar la suma de dos costes, por un lado, el coste de las medidas de seguridad y, por otro, el de la inseguridad. La verdad es que algo obvio, ¿no? Pero no sé, el caso es que debió recordarme a mis clases de Economía en la Facultad y, como decía el anuncio aquel: "M'a impactao".

¿Cuál es la potencia de esta frase? Bueno, pues que, en el fondo, "reduce" la gestión de las seguridad a un problema matemático: Minimizar el valor de una fórmula como la siguiente, Cs = Cm + Ci donde Cs es el coste total de la seguridad, Cm es el coste de las medidas que establecemos y Ci es el coste de la inseguridad (o de la no-seguridad).

Las dificultades que nos encontramos en el día a día para resolver este "sencillo" problema son diversas:
  • Para mi, la principal dificultad es que el coste de la inseguridad es un coste oculto (en muchos casos). Normalmente porque, en realidad, ese coste lo sufren otros (es una externalidad) como pueden ser los casos de software con fallos de seguridad, brechas de seguridad con robo de datos de clientes, empleados... o un proveedor se servicios en la nube con una insuficiente seguridad que ocasiona daños a sus clientes o a los clientes de su cliente...
  • Otra dificultad es el componente aleatorio del coste de la inseguridad. Es decir, aunque el software sea inseguro cabe la posibilidad de que no falle o que no se descubra la vulnerabilidad por nadie. Aquí es donde entran en juego los análisis de riesgos que, en teoría, nos deberían ayudar a "estimar" el valor en riesgo (Value at Risk) de forma que el problema de minimización tomara los datos correctos, pero lo de la gestión de la incertidumbre no es nuestro fuerte: subjetividad de las estimaciones, dudosa validez del pasado para predecir el futuro y cisnes negros en general...
Si unimos ambos factores, lo que sucede es que, seguramente, la elección de inversión de seguridad (el único factor sobre el que podemos influir) no será la adecuada, ya que no se habrán tenido en cuenta todos los costes de la inseguridad (bien porque los sufran otros, bien porque todavía no se hayan materializado o porque hayamos errado al calcular el valor en riesgo) provocando, lo que en Economía llamamos, una decisión sub-óptima que minimiza la ecuación utilizada por la organización, pero no la real.

Ya, pero ¿qué podemos hacer? Pues, en mi opinión, la solución pasa por dos aspectos:
  1. Incorporar todas las externalidades a la ecuación (por el mecanismos que sea: sanciones, impuestos, etc.)
  2. Aprender a gestionar la incertidumbre
¿Qué es difícil? ¡Toma, pues claro! ¿Alguien se pensaba que iba a ser fácil? Eso no tendría ningún mérito...

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

25 mayo 2010

¿Cómo aplica PCI-DSS a las grabaciones de voz de los Call Centers?

Esta es otra duda recurrente en relación al cumplimiento del estándar PCI-DSS que vamos a tratar de enfocar / solucionar. Concretamente, la duda surge porque en este entorno los datos de los titulares de tarjeta son grabaciones de voz y no el típico dato en un fichero o base de datos. Dicha situación hace que sea necesario interpretar los requerimientos del estándar y adaptarlos a las especificidades de este entorno.

La primera duda que nos podría surgir sería la de si  las grabaciones de voz estarían dentro del alcance del estándar. La respuesta es sencilla, sí, las grabaciones de voz forman parte del denominado CDE - Cardholder Data Environment siempre que se produzca, como mínimo, el almacenamiento del PAN. Otra cosa es que, como ya hemos dicho, no sea un almacenamiento típico y requiera de la interpretación del estándar para su aplicación.

Evidentemente, la siguiente duda sería que "si las grabaciones de voz están dentro del alcance, ¿cómo protejo los datos de los titulares?". Pues bien, aquí es donde tenemos que hacer el esfuerzo de interpretación. Básicamente, podemos encontrarnos con dos casuísticas en las grabaciones de voz: analógicas vs. digitales.

  • En el primer caso (grabaciones de voz analógicas), las medidas a establecer serían muy similares a las que aplicaríamos al almacenamiento en papel, es decir, controles de acceso físico y lógico a los soportes.
  • En el segundo caso (grabaciones de voz digitales), la cosa se complica porque además de almacenarse la información en ficheros .mp3, .wav o el que sea, las herramientas que se utilizan en estos casos permite realizar búsquedas en dichos ficheros y recuperar información de manera ágil. En estos casos, las medidas son más amplias y, por ejemplo, deberemos aplicar el requerimiento 3.4 y hacer que el "PAN quede, como mínimo, ilegible en cualquier lugar donde se almacene".

Y, finalmente, la madre del cordero: "Pero, si durante el transcurso de la llamada, el cliente me da un dato sensible de autenticación, ¿tengo que eliminarlo o lo puedo archivar?" Para responder a esta pregunta, lo mejor es remitirnos al Council, concretamente a la sección de las FAQ donde encontramos justo esa pregunta: "Are audio/voice recordings containing cardholder data and/or sensitive authentication data included in the scope of the PCI DSS? (5362)". Básicamente lo que nos viene a decir es que:
  1. Aplicando el requerimiento 3.2 no se pueden almacenar los datos sensibles de autenticación (ya sabéis, CAV2/CVC2/CVV2/CID) después de la autorización (ni cifrados) y que, por tanto, no se pueden almacenar esta información en ningún tipo de fichero de audito digital si el sistema permite la realización de búsquedas. 
  2. Para los casos en los que no se puedan realizar búsquedas, entonces volvemos a lo comentado anteriormente y permiten su almacenamiento con las medidas de control de acceso lógico y físico correspondientes requeridas por el estándar.

En fin, aunque es un poco lioso espero haber sido de ayuda... [y si quedan dudas, ya sabéis, para eso están los comentarios ;-) ]

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