30 junio 2007

Libro recomendado

Casi se me olvida. Hace 2 meses, se ponía a la venta el libro "Gobierno de las Tecnologías y los Sistemas de Información" publicado por la Editorial RA-MA.

Se trata de un libro divulgativo, promovido por el capítulo de Madrid de ISACA, en concreto por dos miembros de la anterior Junta Directiva del capítulo, Fernando Hervada y Mario Piattini, y en el cual, he tenido el placer y el honor de colaborar.

Quizás haya dicho muchas cosas sin explicarlas. Para los que no conozcan ISACA, se trata de una Asociación estadounidense que viene funcionando desde finales de los 60, en un principio, orientada a la auditoría y control de los Sistemas de Información y, últimamente, enfocada en el buen gobierno de las Tecnologías y Sistemas de Información.

Actualmente cuenta con más de 65.000 asociados a lo largo de más de 70 países por todo el mundo y organizados en "capítulos" (en inglés, chapters). Estos capítulos se crean en distintas ciudades (existen alrededor de 170) y pretenden dotar de cercanía a la labor de la asociación. Pues bien, en España (si no me equívoco) contamos con 3 capítulos (el mencionado de Madrid - el más antiguo, Barcelona y Valencia). Yo pertenezco al de Madrid y, creo que somos ya, más de 400 asociados (no está nada mal) pues, hemos sobrepasado a capítulos como el de Milán, que hace 2 años, nos doblaba en número.

Bueno, una vez explicado todo esto, puedo centrarme de nuevo en el libro ("yo venía a hablar de mi libro"). Como decía, es un libro divulgativo que sirve como introducción a todos aquellos preocupados por el buen gobierno de las TIC. ¿En qué consiste este problema? Pues bien, no es ni más ni menos, que la equivalencia de lo que ocurre a nivel corporativo, la creación de un modelo de gestión que permita alinear la estrategia de Sistemas de Información con las estrategias de negocio. En el libro se dan algunas orientaciones y se explican los conceptos generales que se promueven desde ISACA para mejorar en este área.

En concreto, mi aportación son 2 capítulos:
  • Capítulo 5. Visión general del gobierno de la seguridad
  • Capítulo 8. Cuadros de mando para el gobierno de TSI

Como veréis, temas de los que más me interesan, la seguridad y los cuadros de mando, es decir, la gestión de la seguridad.

Para finalizar, solo decir, que debo dar las gracias a mi empresa (ya sabéis, S21sec) por haber contribuido a la edición del libro (nada más y nada menos que junto a un gigante, Telefónica).

27 junio 2007

PCI - DSS: Una realidad

Ya he comentado anteriormente algo en relación al estándar creado por las marcas de tarjetas para tratar de evitar los robos masivos de información de titulares de tarjetas: PCI-DSS - Data Security Standard. Lo cierto es que se trataba (obsérvese el tiempo pasado) de un estándar que estaba encontrando muchas dificultades para ser implementado / exigido de forma efectiva en el mercado español.

Al margen de otras particularidades, lo cierto es que el mercado español (no sé si se trata de una característica común de lo latino) se distingue por hacer las cosas, no por ser una best practice, sino cuando son obligatorias (véase, la LOPD). En realidad, como comenta Bruce Schneier, para invertir en seguridad hemos de tener algún tipo de incentivo: mayor rentabilidad, menor riesgo... lo que sea, pero tiene que "compensar" (de nuevo me asalta Goldratt: "Cuando contribuya a obtener más meta para la organización"). Ahora, parece ser que alguna de las marcas de tarjetas ha empezado a imponer multas (algo insignificante... ¡¡¡50.000$/día!!!) a las entidades financieras que no puedan demostrar que los comercios que tramitan las operaciones a través suyo, cumplen con lo requerido en el estándar.

En definitiva, ahora (igual que ocurrió con la LOPD) las organizaciones tienen clarísimo que existe un coste por no cumplir con una norma y pueden valorar el coste de la no-seguridad.

No sé si es bueno o malo. Lo único que sé es que, ahora, a todo el mundo le entra prisa por demostrar que cumple con el estándar (no digo que no lo cumplieran, digo que quieren demostrar que cumplen).

Me llamo Antonio Ramos

Efectivamente, después de darle muchas vueltas, me he decidido: Me llamo Antonio y he sido 'sorani' en este blog.

He estado algún tiempo dándole vueltas y la verdad es que no he encontrado motivos para no dejar el anonimato. La única cuestión que merodea mi cabeza es si podrá surgir algún conflicto de interés con mi empresa (actualmente soy el Director de Consultoría y Auditoría Informática en S21sec), puesto que mi blog va sobre seguridad y es a lo que me dedico en mi empresa.

En cualquier caso, vaya por delante: Las opiniones vertidas en este blog son total y exclusivamente responsabilidad mía y en ningún caso tienen nada que ver con la organización en la que trabajo.

En fin, vaya el disclaimer por delante que luego, nunca se sabe... Aunque estoy convencido de que no habrá ningún problema...

11 junio 2007

El eslabón más débil de la cadena

A cualquier profesional le suena: "La seguridad es como una cadena, es tan fuerte como el eslabón más débil". Esto lo decimos por varios motivos: Para enfatizar la naturaleza de seguridad como proceso, como sistema, pero también para entender que se trata de una posición de defensa débil, es decir, el defensor tiene que defender todos los puntos, mientras que al atacante le basta con encontrar un punto vulnerable para tener éxito en su ataque.

Sin embargo, aunque todos estamos convecidos de que esto es así, muy pocos (por no decir, ninguo) gestionamos este proceso conforme a esta máxima. ¿Por qué digo esto? Porque si gestionáramos la seguridad teniendo este paradigma in mente, lo mejor sería emplear la misma estrategia que cualquier otro sistema cuya producción esté gobernada por su factor limitante. Me explico, después de identificarlo, habría que hacer que este factor limitante produjese al máximo nivel.
Esta forma de gestionar la seguridad cambiaría sobremanera el enfoque actual del proceso de gestión. Si seguimos lo establecido en los estándares, por ejemplo, el archi-conocido ISO/IEC 27001 que establece las pautas para montar un Sistema de Gestión de la Seguridad de la Información (SGSI) "certificable", tenemos que (como ya hemos comentado aquí anteriormente) llevar a cabo un análisis de riesgos que nos permita identificar el nivel de riesgo por cada área o dominio del alcance establecido y pasar a gestionar el riesgo en función de la estrategia definida.
Si planteamos la seguridad como un sistema en el que el output fuera el nivel de seguridad de la organización (parece obvio, ¿no?), el máximo nivel estaría marcado por el máximo caudal que pudiera gestionar el cuello de botella del sistema, es decir, el nivel de seguridad de la organización sería el del eslabón más débil de la cadena...
¿Cuál es la diferencia entre estas dos maneras de gestionar la seguridad? Según yo lo entiendo, la diferencia es que no tendría tanto interés realizar un análisis de riesgos como el hecho de encontrar cuál es el factor limitante, cuál es el eslabón más débil, puesto que sería el que marcaría el nivel de seguridad de nuestra organización. A partir de ahí, si quisiéramos elevar el nivel de seguridad de nuestra organización, lo que tocaría sería gestionar esa limitación y eso, ya se sabe, hay que preguntarle a Goldratt el cómo...