18 diciembre 2008

No seas vulnerable

Seguro que ya lo sabes. Probablemente, ya estés actualizado. Quizás ni siquiera lo necesites porque no utilizas Internet Explorer. Pero por si acaso se te ha pasado, recuerda que se ha descubierto una vulnerabilidad de Internet Explorer que permite que la ejecución arbitraria de código sin necesidad de interacción con el usuario con sólo visitar una página web preparada para aprovecharse de esa vulnerabilidad, y que está siendo activamente explotada. Y que Microsoft ya ha publicado un parche extraordinario que soluciona la citada vulnerabilidad. Así que ya no hay excusa para seguir siendo vulnerable, sólo tienes que instalarlo. ¿Que no tienes tiempo? Luego no digas que no te avisé... ;-)

¿Que tú eres de los que no ha necesitado el aviso? Así me gusta. No esperaba menos de vosotros!

Para todos vosotros (sí, también para los del párrafo de arriba)...



- ZORIONAK, ETA URTE BERRI ON -

- FELIZ NAVIDAD Y PRÓSPERO AÑO 2009 -



Nos vemos el año que viene (o quizás antes).

15 diciembre 2008

El futuro presidente de EEUU y la seguridad ¿nacional?

No hay duda de que Obama, el próximo presidente de los Estados Unidos de América, puede cambiar el mundo. Y no estoy hablando de sus ideas políticas y económicas, sino de una nueva forma de actuar, de relacionarse, de la influencia que puede tener en la sociedad que conocemos su capacidad para utilizar la tecnología. ¿Qué consecuencias puede tener la capacidad de Obama para eliminar las barreras socio-económicas vigentes?

Espero que el primer párrafo del post haya servido para captar la atención de los lectores. No, no quiero hacer un sesudo análisis del impacto social de Obama ni de sus ideas políticas, sino tan sólo una breve reflexión del tremendo potencial que tiene su forma de trabajar, y de los consiguientes riesgos que pueden subyacer bajo ese gran potencial. La reflexión surge de la lectura de un artículo en el que se habla del gran potencial que tiene el uso de las redes sociales por parte de Obama, y sobre el que invito a reflexionar a todos los lectores.

El impresionante potencial que tiene Obama es increíblemente fácil de comprender. Por una parte va a ser una de las personas con más poder del planeta, tanto de forma directa por sus decisiones en EEUU como de forma indirecta por las repercusiones que pueden tener sus opiniones a nivel global. Pero por otra parte también va a ser una de las personas con más capacidad de convocatoria a nivel social dentro de EEUU: millones de partidarios a un solo clic de distancia, predispuestos a secundar cualquier iniciativa que llegue desde su "amigo" presidente (¿quién no lo haría, si el propio presidente de EEUU te pide ayuda a título personal a través de tu Facebook?). Poder "legal" desde lo alto de la pirámide y poder "social" desde el último escalón. ¿No es la situación ideal? Capacidad para llegar instantánea y directamente a las masas y potencial para hacer realidad cualquier iniciativa que se haya propuesto...

El mayor problema desde el punto de vista de la seguridad, más allá de las cuestiones "filosóficas" sobre el buen o mal uso que se puede hacer de tanto poder, es que el riesgo que subyace es proporcional al poder que ostentan estas herramientas. Si una usurpación de la identidad de cualquier persona puede ser algo grave, las consecuencias que se podrían derivar de una usurpación de la identidad de Obama en estas redes sociales podría tener consecuencias desastrosas. Me imagino a millones de personas a las que un supuesto Obama incita a la desobediencia civil porque el congreso no ha aprobado cierta propuesta de ley... y realmente no quiero imaginarme el resultado.

La tecnología es neutra, es el uso que se haga de ella el que la convierte en algo bueno o malo. No obstante, no podemos olvidar que el uso de la tecnología lleva implícita la existencia de ciertos riesgos asociados a ella, y que en este caso siempre son negativos. Por tanto, creo que a la hora de hacer uso de la tecnología, de querer aprovechar sus beneficios, tenemos el deber moral (y muchas veces también legal) de luchar contra dichos riesgos (o al menos evaluarlos y asumirlos conscientemente), de hacer un uso responsable de los medios a nuestra disposición. Quizás este sea uno de los motivos por los que los presidentes de EEUU deben dejar de utilizar su móvil y su e-mail personal. ¿Pasará finalmente Barack Obama por el mismo trámite? ¿Conseguirá ser el primer presidente que no debe cumplir con dichas restricciones? En caso de que esta norma sea extensible a su participación en las redes sociales... ¿Renunciará Barack Obama a ese poder? ¿Renunciará a su propia filosofía de trabajo? Y si consigue mantenerla... ¿Será capaz de hacer un uso seguro de esa tecnología? Y lo que es más importante: ¿Hará un uso responsable de ese poder?

11 diciembre 2008

Virus en el hospital

La verdad es que, cuando el ritmo profesional aumenta, muchas veces el blog sale perjudicado. Siento no poder escribir post con mayor frecuencia, pero a veces es necesario dedicar el tiempo libre a desconectar...

Hoy quiero comentar una noticia que tenía pendiente desde hace casi un mes. No se puede decir que sea nueva, pero sí preocupante. En los hospitales van a tener que empezar a preocuparse más por los virus... porque también los informáticos pueden afectarles gravemente. En este caso, la noticia es de un virus informático que consigue paralizar tres hopitales. Aparentemente nada excesivamente peligroso: virus conocido y ampliamente detectado que se propaga por correo electrónico e infecta sistemas windows. Lo típico, podríamos decir. De hecho, la propia web de alerta-antivirus califica el virus de peligrosidad baja (al menos, para la mayor parte de sus variantes). Sin embargo, este virus parece que fue el causante de llegar a las redes de estos 3 hospitales y propagarse por ellas hasta obligar a que, para resolver el problema, fuera necesario echar abajo la mayor parte de las redes informáticas de los hospitales (parece ser que consiguieron mantener levantadas las de los departamentos de emergencias, cuidados intensivos y patología). No me quiero imaginar la cara de los pacientes que, en la ambulancia, les dijeran que no iban al hospital más cercano porque había una infección por virus... informático.

En definitiva, otro ejemplo más de que seguridad informática y seguridad personal cada vez empiezan a tener más puntos en común. ¿Se podría achacar al virus la hipotética muerte de un paciente muerto en la ambulancia por tardar demasiado en llegar al hospital alternativo? ¿Podría ser la "pasividad informática" que aparentemente hubo en relación al virus un argumento a esgrimir en un hipotético juicio por dicha muerte? Espero que al menos el personal de esos hospitales den a partir de este momento algo más de importancia a la seguridad informática...

09 diciembre 2008

AENOR acreditada para certificar SGSIs

Parece que esta vez los rumores sí eran ciertos, y finalmente AENOR ha recibido la acreditación de ENAC para certificar SGSIs bajo ISO 27001. Por lo tanto, todas las certificaciones en 27001 que lleve a cabo AENOR a partir de noviembre contarán con la correspondiente acreditación. Además, todas las certificaciones utilizadas para la concesión de la acreditación también se considerarán acreditadas, lo que supone que la mayor parte de los certificados en 27001 emitidos por AENOR pueden considerarse como certificados acreditados (aunque es posible que no sean el 100% si todas las certificaciones no han seguido idénticos procesos de certificación). Ahora queda en manos de ENAC firmar el MLA (acuerdo multilateral) que permita homologar los certificados acreditados por ENAC con el resto de certificados acreditados por otras compañías, con el fin de que todos los certificados emitidos por las empresas acreditadas por ENAC puedan subir al registro internacional de certificados.

24 noviembre 2008

Crisis y seguridad

Hoy sencillamente quiero referenciar el último post del blog Eddasec sobre los efectos que puede tener la crisis económica sobre la postura de las organizaciones en torno a su seguridad (y a la consiguiente inversión en seguridad). Aprovecho para recomendar el blog, que después de 3 meses de andadura ha demostrado sobradamente la calidad de sus contenidos.

El post en cuestión se titula lo bueno y lo malo de la crisis, y como ya he dicho hace un análisis de las repercusiones que puede tener la crisis sobre la inversión en seguridad de las empresas. Es un planteamiento interesante, ya que analiza ventajas e inconvenientes y lo particulariza para empresas "compradoras" y "vendedoras" de seguridad, con lo que ofrece una visión bastante completa (y creo que acertada) de la situación que nos podemos encontrar en el sector. Un post sin duda interesante, y digno de un análisis con calma. ¿A alguien se le ocurren estretegias de comercialización a partir de este cuadro? ;-)

19 noviembre 2008

Priorizar controles de seguridad

A veces, aquello que nos parece más obvio es precisamente en lo que hace falta incidir. Al menos, a mí en ocasiones me ocurre que tiendo a presuponer unos ciertos conceptos de partida que utilizo para mis exposiciones, y más de una vez he caído en la cuenta de que los problemas de la audiencia son precisamente que no poseen esos conceptos, o que no los han entendido correctamente.

Uno de los casos más repetidos, y no sólo entre los profanos en materia de seguridad, es el de tratar de encontrar algún tipo de criterio estándar para priorizar unos controles sobre otros. Evidentemente, la ISO 27002 (antigua ISO 17799, guía de buenas prácticas en seguridad también conocida como catálogo de controles) tiene un listado extenso de controles de seguridad, y encontrar algún criterio (o alguna guía o ranking, a poder ser) para priorizar unos sobre otros sería una magnífica ayuda. ¿Cuál es el problema?

El problema es que cualquier guía estandarizada va a ser incorrecta. Es completamente imposible dar una respuesta universal a qué controles son más importantes que otros. Es cierto que el sentido común nos puede ayudar a encontrar algunos controles "prioritarios" desde un punto de vista genérico, y la propia ISO 27001 exige una serie de cumplimientos cuya traducción a controles de la ISO 27002 nos puede ayudar a encontrar un subconjunto de controles "preferentes", pero... Un ranking estándar? Imposible.

La razón es muy sencilla. El criterio para priorizar controles de seguridad debe ser el resultado del análisis de riesgos. Será en base a las principales carencias identificadas en materia de seguridad como tendremos que identificar aquellos controles que son prioritarios, ya que serán los que mitiguen los mayores riesgos identificados. Y lamentablemente los análisis de riesgos son distintos en cada organización, ya que los requerimientos y necesidades de seguridad varían enormemente. Por lo tanto, nunca encontraremos una regla general para priorizar los controles, ya que el criterio de priorización varía con cada organización.

Evidentemente, el resultado del análisis de riesgos no es el único criterio a aplicar. Para mitigar un riesgo concreto puede haber más de un control a aplicar. ¿Se puede en este caso usar una regla genérica de priorización? Pues me temo que tampoco, ya que tendremos que tener en cuenta la eficiencia y la eficacia de cada uno de ellos (o, dicho de otra forma, el coste y la disminución de riesgos que produce cada uno de ellos). De nuevo cada organización es quien va a determinar cuánto necesita reducir su riesgo y cuánta inversión está dispuesta a realizar para ello. Es más, un mismo riesgo puede ser mitigado por distintos controles que actúan en distintos ámbitos, y por lo tanto será cada organización quien decida en cuál de esos ámbitos prefiere actuar. Y eso por no hablar de que cada control puede ser implementado de múltiples formas (las que propone la ISO 27002 y muchas otras más), y que por lo tanto la eficiencia y eficacia de cada uno va a depender también del método de implementación que elijamos...

En definitiva, no podemos decir que exista ninguna regla general para priorizar unos controles sobre otros. Tiene que ser cada organización quien seleccione los que más le convienen, llegando a un compromiso final entre riesgo resultante e inversión requerida. Y más allá de la pura lógica sólo nos encontraremos con propuestas más o menos orientadas que lo único que nos garantizan es simplificar y reducir el trabajo de gestión de riesgos a costa de perder efectividad en nuestra gestión de riesgos. Y no querremos descubrir, después de haber hecho un determinado gasto en seguridad, que no hemos sido capaces de mitigar nuestros riesgos, verdad?

18 noviembre 2008

ISO 9001:2008 publicada

Ocho años después ya tenemos una nueva versión de la ISO 9001. A partir de hoy, la nueva UNE - EN - ISO 9001:2008 ya está disponible para su descarga (por supuesto, en español). Sólo 5 días más tarde que la fecha de publicación oficial en ISO, ya podemos consultar la nueva versión de la norma.

No he tenido tiempo de revisar a fondo los cambios, pero aparentemente no son muchos (o al menos no son muy significativos). Distintas referencias en las que se indicaban los cambios entre la versión de 2000 y la versión de 2008 ya estaban disponibles desde hace algún tiempo, y si echamos un vistazo a los mismos podemos ver que son cambios de forma más que de fondo. Aunque seguro que si los miramos con un poco más de detenimiento se les puede sacar bastante más jugo del que parece...

En definitiva, creo que esta nueva versión no hace otra cosa que ratificar el avanzado estado de madurez de la norma, que entra en una etapa de estabilidad en el que probablemente se mantenga durante un largo periodo de tiempo. No obstante, como ya dije en el post anterior, tendremos que estar atentos a otro tipo de referencias capaces de complementar y ampliar (e incluso de reemplazar) el status quo de la gestión de la calidad vigente en la actualidad.

17 noviembre 2008

Que es Calidad

Es muy habitual oir hablar de que las cosas se hacen (o no) "con calidad", y que siempre nos quedemos con la sensación de que el término calidad es algo abstracto, que significa que algo es bueno, pero sin que seamos totalmente capaces de argumentar por qué decimos eso, o cómo de bueno es.

Quien quiera gestionar adecuadamente esa calidad tiene una norma, la ISO 9001, para ayudarle a mantener y mejorar esos "niveles" de calidad. Claro, que si no somos capaces de definir completamente esos "niveles", difícilmente podremos tener claro si los mantenemos o no, o cuánto somos capaces de mejorarlos, no?

La lucha contra esa indefinición es uno de los motivos por los que me gusta el planteamiento de la ISO 20000. Sí, es una norma para gestionar la calidad de los servicios TI, pero... por qué no pueden esos planteamientos ser extrapolables a cualquier tipo de servicios? Yo creo que la filosofía es perfectamente aplicable. Veamos por qué.

La base de la filosofía de esta norma son los acuerdos de nivel de servicio. Es decir, que prestar un servicio con calidad quiere decir lo siguiente:
  1. Definir un servicio
  2. Caracterizarlo en base a parámetros cuantificables
  3. Acordar con el cliente qué nivel va a tener mi servicio (definir un valor a cumplir en relación a cada uno de los parámetros).
  4. Cumplir con los niveles establecidos

Es decir, que la calidad tiene que ser un parámetro medible y prestar un servicio con calidad quiere decir que ese parámetro mantenga el valor dentro de los límites acordados con el cliente. ¿Es esto algo propio de los servicios TI? ¿No, verdad? Por lo tanto, la referencia es totalmente reutilizable.

Pero vamos un poco más allá. Sin que nadie nos diga cuáles deben ser esos parámetros que caracterizan el servicio, la norma sí que nos da una serie de procesos que tenemos que desarrollar. Y cada uno de esos procesos lo que persigue es "cuidar" un aspecto distinto del servicio. ¿Somos capaces de encontrar parámetros de servicio entre esos aspectos? Algunos de los aspectos que tratan son:

  • Disponibilidad
  • Capacidad
  • Coste
  • Seguridad
  • Incidentes
  • Cambios

Es decir, que al menos estos aspectos de los servicios los tenemos que "cuidar" si queremos prestar un servicio "de calidad". ¿No sigue siendo esto aplicable a cualquier tipo de servicio? ¿No podríamos decir que estos aspectos son parámetros mínimos que caracterizan la calidad de cualquier tipo de servicio?

En definitiva, creo que la ISO 20000 lo que permite es llevar a cabo una aproximación específica al concepto de calidad de un servicio, y que por lo tanto puede ser una buena referencia para gestionar la calidad de cualquier tipo de servicio en el que queramos pensar. Ahora ya podemos tener un poco más claro qué es eso de la calidad...

12 noviembre 2008

Metodologias de Analisis de Riesgos

Hoy simplemente quiero hacer un repaso de las distintas metodologías específicas de análisis y/o gestión de riesgos que existen actualmente. No va a ser una lista exhaustiva, pero creo que servirá para la reflexión.


En primer lugar tenemos las normas que versan sobre el análisis de riesgos. Entre las más conocidas podemos encontrar:
  • AS/NZS 4360:2004: Norma australiana para la gestión de riesgos (en general).
  • BS7799-3:2006: Norma británica para la gestión de los riesgos de seguridad de la información.
  • ISO/IEC 27005:2008: Norma internacional sobre la gestión de los riesgos de seguridad de la información. Distinta a la anterior, aunque también sirve para dar cumplimiento a la ISO 27001.
  • UNE 71504:2008: Norma española que recoge una metodología de análisis y gestión de riesgos para los sistemas de información. No es equivalente a las anteriores, ya que esas eran para seguridad de la información.

Pero no sólo disponemos de normas de análisis de riesgos, también existen metodologías ampliamente reconocidas y de uso generalizado. Las principales son:

  • MAGERIT, metodología española de análisis y gestión de riesgos para los sistemas de información, promovida por el MAP y diferente a la UNE 71504.
  • EBIOS, metodología francesa de análisis y gestión de riesgos de seguridad de sistemas de información.
  • CRAMM, metodología de análisis y gestión de riesgos desarrollada por el CCTA inglés.
  • OCTAVE, metodología de evaluación de riesgos desarrollada por el SEI (Software Engineering Institute) de la Carnegie Mellon University.
Y no son las únicas. Para el que quiera conocer alguna más, tanto en la web de ENISA como en la web de ISO27000.es podéis encontrar más información sobre metodologías de análisis de riesgos.

En definitiva, existe una gran variedad de metodologías, muchas de ellas con reconocimiento internacional, pero lamentablemente todas distintas. Es cierto que, como metodologías de análisis de riesgos que son, todas se parecen, pero no se puede decir que sean compatibles de entrada. Cada una tiene sus particularidades, sus puntos fuertes... y será trabajo de quien quiera utilizarlas el saber sacar lo mejor de cada una de ellas.

10 noviembre 2008

El catalogo de servicios

Parece mentira que algo tan aparentemente sencillo como contar "a qué te dedicas" suponga, en la práctica, tantos problemas. No sé si en todos los ámbitos pasará lo mismo, pero en concreto en el sector de TI es algo realmente complicado.

Con el fin de aclarar un poco esto del catálogo de servicios TI y cómo se elabora encontré hace algún tiempo este enlace que quiero compartir con vosotros. Habla del menú de TI, y cuenta cómo se parece un catálogo de servicios al menú de un restaurante. Las claves que me gustan son:
  • El restaurante publica el menú. Yo añadiría que es un menú con platos del tipo "alta cocina", de 4 líneas por plato en el que figuran todos los ingredientes, incluso los decorativos.
  • No se explican ni la receta ni los utensilios utilizados para elaborar cada plato.
  • El cliente tiene cierto margen para personalizar el plato. Yo añadiría que este margen debe estar acotado e incluso estipulados los costes de cada variación, en caso de que los tenga. Y hago una pregunta capciosa: un plato de carne con una salsa o con otra es el mismo plato, o son dos platos distintos?
  • Se permite llamar al chef si algo no va bien (y claro, el chef sale y atiende al comensal, tanto para una queja como para una felicitación).
  • Y sobre todo, no olvidar que el menú hay que desarrollarlo pensando en el cliente, no en el cocinero. Lo importante no es si son platos de preparación rápida o si se requiere más o menos pericia para prepararlos, lo que importa es que el cliente tenga claro qué quiere y cómo elegirlo (entrantes o platos fuertes, carnes o pescados, calóricos o "sanos", o cualquier cosa que le pueda interesar al cliente, no al cocinero).

En definitiva, que si la cocina es un arte, y comer un placer... habrá que empezar a aprender de los grandes chefs, y preparar "alta cocina" en los departamentos de TI.

05 noviembre 2008

Invertir en seguridad

La semana pasada también leía una noticia acerca de una presentación de un conocido fabricante de seguridad en la que se animaba a las empresas a replantearse las líneas de inversión en materia de seguridad. Según dicho artículo, las líneas que deben guiar la inversión en seguridad son:
  • Centrarse en maximizar la ecuación coste-beneficio en relación a la gestión del riesgo.
  • Integrar la seguridad con la innovación, incorporándola a la fórmula del éxito.
  • Implementar soluciones de seguridad transparentes e intuitivas, de modo que sean lo menos intrusivas posible y permitan a los usuarios centrarse en su actividad de negocio.
  • Orientar las soluciones de seguridad a las amenazas reales en lugar de dejarse guiar por factores como el miedo o el cumplimiento normativo.
  • Centrar el foco de la seguridad en la propia información y su nivel de sensibilidad, en lugar de hacerlo en los sistemas.
  • Orientar la seguridad de forma dinámica en lugar de estática, orientándola por tanto al comportamiento del usuario.

En general estoy de acuerdo con los planteamientos realizados, y la única objeción sería quizás que el cumplimiento normativo no me parece una mala orientación, ya que se puede entender tanto desde el punto de vista del cumplimiento legal o regulatorio, en cuyo caso sería una orientación "obligada", como desde el punto de vista de consecución de un "premio" a la seguridad (certificación u otro tipo), en cuyo caso puede ser una orientación válida desde el punto de vista de beneficios para el negocio derivados del marketing en seguridad.

¿Estais de acuerdo con estas líneas de actuación? ¿Añadiríais o eliminaríais alguna?

04 noviembre 2008

Transacciones seguras

La semana pasada leí una reseña sobre un dispositivo para asegurar las transacciones bancarias que me gustó. El dispositivo en cuestión es un llavero USB cuyo cometido básico es establecer un canal de comunicación seguro entre el propio dispositivo y el banco, a través del cual se visualizan y validan manualmente las transacciones que realicemos, si realmente la información visualizada se corresponde con la transacción que queremos realizar.

Me gusta el planteamiento por varios motivos. El primero de ellos es que coincido con el planteamiento de partida, que supone la utilización, en el extremo del usuario, de un recurso proporcionado por la entidad bancaria que permite garantizar la seguridad de las transacciones. El hecho de que sea la entidad bancaria la que trate de garantizar la seguridad extremo a extremo me parece algo fundamental, ya que supone un incremento en la responsabilidad que el banco está dispuesto a asumir en términos de la seguridad global del servicio proporcionado.

El segundo motivo es que este planteamiento sigue la premisa de que la forma de garantizar esa seguridad extremo a extremo sea mediante el uso de un elemento seguro "per se" y que proporciona toda la funcionalidad necesaria para esa seguridad. En este caso estamos ante un dispositivo hardware externo, pero el mismo planteamiento sería válido con otro tipo de módulo de usuario que fuese capaz de ofrecer las mismas garantías: ser un entorno cerrado y sólo accesible en un extremo por el canal de comunicaciones seguro y en el otro por el usuario. Esto supone, sencillamente, que sea el propio interfaz de usuario el que incorpore todas las funcionalidades de seguridad precisas y que además dicha interfaz sea cerrada al resto de elementos que intervienen en la comunicación, ya que en este caso el equipo de usuario es un simple elemento de comunicación sobre el que opera el dispositivo.

Y el tercero de los motivos es que este planteamiento supone una nueva forma de afrontar este tipo de problemas. Se puede estar o no de acuerdo en si la mejor forma de asegurar una transacción electrónica es validarla manualmente, pero al menos supone una forma distinta de afrontar este problema. Además, en este caso tenemos la ventaja de que no es necesario utilizar un canal de comunicación alternativo como puede ser la telefonía móvil para llevar a cabo esta tarea de validación, lo cual creo que favorece la penetración de esta solución.

En definitiva, un dispositivo interesante. A diferencia del autor del post no tengo muy claro el futuro de su implantación generalizada, aunque al menos espero que sirva de inspiración a los diseñadores de soluciones de seguridad en este tipo de entornos para empezar a pensar en otro tipo de soluciones que realmente sean capaces de resolver de forma más efectiva todas las problemáticas que deben resolver este tipo de soluciones.

25 octubre 2008

Seguridad, parte de la excelencia empresarial

En el último post mencionaba las modas de la gestión y sus múltiples variantes. Hoy, sin embargo, quiero volver a enarbolar la bandera de la seguridad y a reivindicar una posición privilegiada para ella entre esas modas, dado que en muchos casos podemos ver que es una de las más olvidadas.


La iniciativa no es nueva. Ya en el ISMS Forum Spain se hablaba de ello hace cosa de un año en su II Jornada Internacional, orientada a ver la seguridad de la información como parte de la responsabilidad social corporativa, y se volvía a mencionar el pasado verano en la III Jornada Internacional al hablar del Buen Gobierno Corporativo. No obstante, si buscamos referencias al respecto más allá de los límites del sector probablemente nos encontraremos con que la seguridad brilla por su ausencia a la hora de buscar referencias sobre la tan deseada excelencia empresarial.

Si nos vamos al modelo de excelencia empresarial por antonomasia, el modelo EFQM, quizás podamos encontrar algunas de las causas de esta ausencia. La verdad es que, si revisamos el modelo, seguro que encontramos sitios en los que encajaría perfectamente la seguridad: un apartado de política y estrategia, uno referido al personal, otro referente a los recursos, uno más referido a los procesos... Si profundizamos un poco más, vemos que incluso la filosofía REDER (Enfoque - Despliegue - Evaluación y Revisión - Resultados - y vuelta a empezar) encaja a la perfección con la filosofía PDCA que subyace en los SGSIs. ¿Si todo parece encajar, por qué no aparece mencionado?

Desde mi punto de vista creo que el problema está en la filosofía con la que se desarrolla el modelo. Bajo el riesgo de que los defensores acérrimos del modelo EFQM se me echen encima, tengo que decir que el modelo EFQM es un modelo muuuuy optimista. Está desarrollado desde el punto de vista de la empresa perfecta, del entorno ideal. Es un modelo que anima a desarrollar al máximo tu potencialidad, pero creo que pierde de vista la realidad empresarial. El mercado, la competencia o la rentabilidad son aspectos que creo que no se tienen suficientemente en cuenta en el modelo. El término riesgo prácticamente se obvia en el modelo, y es precisamente en torno a ese término cuando aparece la seguridad. Por tanto, aunque las bases del modelo puedan ser coherentes es la propia filosofía del mismo la que prácticamente imposibilita la aparición de la seguridad, ya que es un aspecto que sólo cobra importancia en un entorno más realista (o pesimista?), en el que existen factores negativos con los que lidiar.

Esta reflexión creo que puede ser extensible a otras estrategias "positivistas" del management, en las que mientras no se contemple el lado "pesimista" de la actividad nunca se podrá integrar la seguridad como parte constitutiva de la estrategia corporativa. Y lo más llamativo de todo esto es que podría llegar a darse el caso de que una organización calificada como "excelente" (muchos puntos en el modelo EFQM, innovadora, con buena gestión del talento, etc.) sufriera fugas de información o incumplimientos de la LOPD, por poner un par de ejemplos, sin que esa "excelencia" se viese prácticamente afectada (meto el prácticamente ya que quizás sí podría verse afectada, aunque de forma indirecta y a medio plazo, a través de los criterios de resultados en los clientes y/o en la sociedad). ¿No os parece llamativo que existan modelos capaces de denominar excelente a una empresa en la que la seguridad pueda ser un tema totalmente residual?

20 octubre 2008

Más allá

Ver cómo van evolucionando las modas del management empresarial es un ejercicio muy interesante para darnos cuenta de la relatividad de todas ellas. La calidad, la innovación, la responsabilidad social, el I+D, la gestión del talento, la seguridad (sí, también la seguridad)... Y a la hora de la verdad, cuando nos dicen que vienen malos tiempos y toca apretarse el cinturón, cuáles son las recetas más escuchadas? Plegar velas, apretarse el cinturón, recortes de personal... Un panorama muy distinto al inicial. ¿No es un poco incoherente? ¿Por qué las recetas del éxito no son las recetas de la lucha contra las dificultades?



Una de las respuestas que se me ocurre es que las empresas tienen su propia pirámide de Maslow corporativa, y que no son comparables las modas del management, ubicadas en las capas superiores, con las soluciones para tiempos difíciles, que se atajan en las inferiores. De este modo, sería lógico y evidente que, si peligran las capas inferiores, queden a un lado las soluciones destinadas al reconocimiento y autorrealización corporativos y las organizaciones se centren en los problemas de más bajo nivel.



Sin embargo, si pensamos en el proceso que lleva a una persona (o en este caso, a una organización) a satisfacer esos niveles altos de la pirámide, nos daremos cuenta de que algo falla. Se supone que sólo pensamos en satisfacer las necesidades superiores cuando las inferiores están cubiertas. Sin embargo, la situación que vivimos parece que está impactando directamente en los niveles inferiores de la pirámide sin afectar, curiosamente, a los niveles superiores. ¿Cuál es el problema?



Desde mi punto de vista creo que ha llegado un momento en el que las modas del management han pegado tan fuerte entre algunos directivos que han llegado a confundir las consecuencias con los objetivos. Hay empresas que han tratado de saltarse los pasos intermedios y que han querido llegar a unos niveles de excelencia empresarial al alcance sólo de unos pocos a costa de erigir ese modelo de management sobre unos cimientos insuficientemente sólidos, cuando menos. En una burda caricatura empresarial de aquél anuncio del Peugeot 206, ha habido empresas del tipo "Seat 600" que han pensado que era suficiente con poner una carrocería "Ferrari" para poder ser un super-deportivo. Y claro, cuando ha tocado apretar el acelerador resulta que ni el motor, ni el chasis, ni los frenos funcionan tan bien como los de aquellos a los que han querido emular...

Al refinamiento en la gestión se debería llegar una vez alcanzado el refinamiento en la producción, por decirlo de algún modo. La evolución lógica es que, cuando has alcanzado un gran nivel en los productos o servicios que proporcionas, la forma de seguir mejorando ya no puede ser a través de la mejora del propio producto o servicio, ya que está tan optimizado que no sería rentable, sino que hay que buscarla en la mejora de la propia gestión. Y es en este escenario donde todas esas modas del management tienen sentido, ya que lo que se busca es mejorar el segundo o tercer decimal, no el valor entero.

En definitiva, una empresa que haya alcanzado el refinamiento en la gestión de forma natural no debería tener excesivos problemas en afrontar tiempos difíciles, ya que parte de una base sólida y probablemente sólo precise dedicar a gestionar las dificultades económicas los esfuerzos dedicados a este refinamiento en la gestión. ¿Y el resto? Les quedan dos opciones: o rentabilizar recursos y sacrificar premios a cambio de negocio real, o mantener los galones impecables y ser el capitán que se aferra a lo alto del mástil cruzando los dedos para que el barco, aunque haga aguas, no se hunda.

14 octubre 2008

Seguridad: motor o freno?

Los estudios no se ponen de acuerdo sobre si la seguridad es un motor o un freno para el negocio de las organizaciones. Hace algún tiempo veíamos cómo el riesgo puede ser un motor para la empresa, y ahora nos dicen que la seguridad puede ser un freno para el negocio. ¿En qué quedamos?

Si seguimos leyendo el segundo de los enlaces encontraremos la solución: la clave está en la famosa alineación entre la seguridad y el negocio. En el fondo, es lo de siempre: si la seguridad no está alineada con el negocio sólo es un obstáculo, y entendamos o no la innovación como parte del negocio, el obstáculo sigue siendo el mismo. Sólo que en este caso quizás esté agravado, ya que la innovación supone cambio y la seguridad muchas veces no se lleva nada bien con los cambios.

Lo que me encanta del artículo es la solución que proponen: dar un nuevo enfoque a la gestión del riesgo. Simple y efectiva, desde mi punto de vista (no puedo negar que me he sentido bastante identificado al leer el artículo):
  • Cambiar el enfoque de "gestión de la seguridad" por uno que busque la "gestión del riesgo" es la clave, ya que supone cambiar un enfoque defensivo (que encima trata de defender algo cuya plenitud es inalcanzable) y pesimista por otro proactivo en el que implícitamente suele contar la variable "negocio".
  • Hablar de "tolerancia al riesgo" posiblemente sea una forma sencilla de que todo el mundo entienda ese concepto de aceptación del riesgo que a veces resulta tan difícil de matizar.
  • Definir claramente las responsabilidades en relación a las decisiones sobre gestión del riesgo es la solución a los problemas de indefinición que suelen aparecer, ya que muchas veces nadie quiere ponerle el cascabel al gato.
  • Usar una metodología estandarizada, repetible, sistemática y objetiva de análisis de riesgos que tenga en cuenta el balance coste / beneficio supone disponer de la herramienta que permite llevar a cabo este cambio de enfoque.

En definitiva, cuatro pequeñas líneas de actuación que, bien desarrolladas, pueden hacer realidad el famoso santo grial de la seguridad. Es sólo cuestión de matices, pero incluso en estos temas de la seguridad la teoría del caos también se cumple...

13 octubre 2008

Caracterizar un servicio

Intentar definir conceptos suele ser algo más difícil de lo que parece a priori. Algo tan obvio como definir qué es un servicio TI puede ser un importante reto incluso dentro del sector TI. Así que no es de extrañar que, si intentamos ir un poco más allá, las aparentemente pequeñas dificultades puedan crecer exponencialmente cuando nos enfrentamos a ellas en la práctica.

Uno de estos retos es, precisamente, caracterizar un servicio TI. ¿Qué parámetros tiene un servicio TI? ¿Cuál es el conjunto mínimo de parámetros que deberíamos utilizar para poder modelizar un servicio TI? La pregunta no es trivial si lo que queremos obtener es una caracterización general de los servicios TI, que nos sirva de patrón de referencia para cualquier tipo de servicio. El objetivo no es tratar de comparar servicios distintos, sino utilizar los mismos patrones mentales para distintos servicios, con el fin de que podamos lidiar con ellos de forma más sencilla.

Para hacer este ejercicio no tenemos que pensar en un servicio concreto, sino que tenemos que ser capaces de abstraernos y pensar en el propio concepto de servicio. Y de todos los parámetros que se nos puedan ocurrir tratar de separar entre los que nos parecen primarios y los que pueden ser secundarios, es decir, los descriptivos del propio servicio y los que reflejan otros "valores añadidos" a dicho servicio.

No es un ejercicio fácil, y probablemente los resultados a los que llegaréis cada uno sean distintos. A mí se me ha ocurrido que un servicio podría quedar caracterizado en base a estos 3 parámetros:
  • Rendimiento: Podríamos entenderlo como la "velocidad" del servicio, la facultad del servicio de proporcionar los resultados esperados.
  • Capacidad: Hace referencia a la facilidad que tiene el servicio de atender simultáneamente distintas peticiones de servicio.
  • Inteligencia: Trata de caracterizar el grado de funcionalidad del servicio, de reflejar el nivel de resultados que puede llegar a ofrecer.

Esta tripleta no tiene por qué ser necesaria en todos los casos, es posible que en muchos sólo sea necesario utilizar uno o dos de los parámetros, pero el objetivo es que cualquier tipo de servicio se pueda caracterizar, en líneas generales, utilizando exclusivamente estos tres. ¿Qué os parece la propuesta? ¿Coincidiría con la vuestra, o creeis que falta o sobra algún parámetro? Estoy deseando leer vuestras aportaciones

01 octubre 2008

Sistemas de Gestion

A veces resulta difícil transmitir qué es un sistema de gestión. Así, a secas, sin ningún añadido por detrás. Porque si cosas aparentemente tan distintas como un sistema de gestión de la calidad, un sistema de gestión de la seguridad de la información, un sistema de gestión de la continuidad del negocio o un sistema de gestión de los servicios IT tienen dos de sus términos en común, en algo tendrán que parecerse, no?

Lo primero que se me ocurre es ir al diccionario y buscar el significado de esos dos términos:
  • Sistema: Conjunto de reglas o principios sobre una materia racionalmente enlazados entre sí.
  • Gestión: Acción y efecto de hacer diligencias conducentes al logro de un negocio o de un deseo cualquiera.

Es decir, que por su significado un Sistema de Gestión sería un conjunto de reglas y principios interrelacionados cuya intención es el lograr el éxito en un asunto concreto. ¿Y Cuál es ese asunto? Sencillamente, el término que venga detrás: calidad, seguridad, ...

Vale, el significado está claro, pero... ¿Qué supone eso en la práctica? ¿Cuáles son esas reglas y principios interrelacionados? La verdad es que en este caso la simple definición no da ninguna pista. ¿Solución? Analizar los distintos sistemas de gestión normalizados existentes y buscar sus elementos comunes. ¿Cuáles son? Yo diría que los siguientes:

  • Compromiso de la dirección: Para cualquier sistema de gestión normalizado es imprescindible que la dirección de la organización se comprometa formalmente con el asunto en concreto, y que ese compromiso se traduzca en la práctica en la asignación de los recursos necesarios.
  • Ciclo PDCA: Todo sistema de gestión normalizado debe estar estructurado en forma de proceso de mejora continua, de modo que se garantice la filosofía de que primero se piensa, luego se actúa, después se revisa la actuación y finalmente se corrige y optimiza, volviendo a empezar.
  • Formación: Otro de los elementos imprescindibles de un sistema de gestión normalizado es que se garantice la capacitación y concienciación de todos los implicados en el asunto en cuestión.
  • Gestión documental: Una de las exigencias de todo sistema de gestión normalizado es garantizar una adecuada gestión documental, tanto en lo referente a la propia documentación "descriptiva" del sistema de gestión (esas reglas y principios que lo determinan) como a los registros que se generan durante su aplicación práctica.
  • Auditoría interna: Uno de los aspectos más importantes es garantizar que el sistema de gestión normalizado se evalúa de forma independiente y objetiva, por lo que las auditorías son imprescindibles, y por lo tanto las internas son obligatorias.
  • Revisión por la dirección: Todo sistema de gestión normalizado debe garantizar su continuidad en el tiempo, y eso supone que no basta con la asignación inicial de recursos y la puesta en marcha de las prácticas que correspondan. La garantía de esa validez contínua supone que la propia dirección sea la que revisa los objetivos y resultados globales del sistema de gestión y sus principales parámetros de funcionamiento, con el fin de conocer de primera mano los principales aspectos del sistema de gestión y poder ir adaptándolo a las necesidades cambiantes de la organización.
  • Mejora continua: Por último, todo sistema de gestión normalizado deberá garantizar su continua evolución y mejora. Por ello, no sólo deberá estar estructruado en forma de ciclo PDCA; sino que se deberá llevar a cabo un seguimiento de todas las desviaciones que pueda sufrir y establecer las acciones correctivas y preventivas necesarias para cumplir con ese precepto.

No tenemos que perder de vista que estas son las características de todo sistema de gestión normalizado. Esto no quiere decir que un conjunto de reglas y principios interrelacionados que carezca de alguna de estas características no pueda ser un sistema de gestión, sino que no cumplirá los preceptos de uno estandarizado (o estandarizable) en forma de norma de gestión.

Por último, sólo recordar que el sistema de gestión es sencillamente el marco en el que hay que encajar todas las reglas y principios encaminados a lograr ese determinado asunto. Y que esas reglas y principios no tienen por qué ser similares, ni siquiera tienen por qué estar establecidas de la misma forma. Algunas de esas reglas y principios pueden estar establecidas en forma de políticas, otras en forma de controles, otras en forma de procesos... Y obviamente cada una de ellas podrá hablar de un asunto totalmente distinto.

29 septiembre 2008

Seguridad y miedo

Hace unos días leí un post bastante curioso, titulado hacer frente al miedo, que se hacía eco de un estudio en el que se concluye que las personas más miedosas tienden a mantener unas posiciones más conservadoras que los menos miedosos. Y la consiguiente pregunta desde la temática de este blog creo que es obvia: ¿Tiene el miedo alguna relación con la seguridad?

Yo cre que la pregunta tiene una respuesta clara, aunque a veces reconocerla nos pueda resultar incómodo: sí, están relacionados. ¿Alguna vez nos hemos sentido tentados de "asustar" a nuestro interlocutor en un análisis de riesgos con las terribles consecuencias que puede tener una amenaza determinada? ¿Nunca hemos tratado de "meter miedo" a nadie como argumento de venta de la seguridad? Evidentemente, la gestión de riesgos es una tarea con un importante factor implícito de subjetividad, y el miedo es uno de los elementos que puede modificar directamente ese factor... ¿Nadie ha oído nunca el consejo de "vender" un Plan de Continuidad de Negocio al poco tiempo de que una empresa cercana, sectorial o geográficamente, haya sufrido una importante crisis?

Ahora bien, hay una interpretación del artículo que me parece más provocadora que la anterior. En general, creo que no es descabellado pensar que la propia actividad de gestión de riesgos lleva implícita una postura conservadora a la hora de afrontar la tarea. ¿Quiere decir esto que a las personas encargadas de gestionar riesgos se nos podría catalogar como miedosas? ¿O es precisamente el hecho de gestionar esos riesgos la prueba de que esos miedos están superados? El mismo artículo hace referencia a que en pocas ocasiones el miedo se muestra tal y como es, y que en muchos casos aparece disfrazado de otro tipo de comportamientos. ¿Qué estrategias de gestión podrían enmascarar ese miedo? ¿Cuáles de ellas son más apropiadas desde este punto de vista?

Como reflexión final me quedo con otra cita del mismo artículo: "el miedo (...) limita nuestro abanico de alternativas y genera acciones de las que solemos ser los primeros perjudicados". ¿Seremos capaces de integrar como parte de la gestión de riesgos las actividades de superación de nuestros propios miedos como parte de la estrategia global de la compañía? ¿Tendremos así organizaciones más libres? ¿Y más seguras?

24 septiembre 2008

Estas seguro de que estas seguro?

El juego de palabras del título puede parecer divertido, pero plantea una pregunta con mucha miga. ¿Puedes garantizar la seguridad de tus sistemas en este mismo instante? Esa es la pregunta que plantea Sebastián Bortnik en su post Cómo sé si estoy seguro.

La verdad es que es una pregunta con trampa. Si la seguridad completa es imposible de conseguir, nunca podremos asegurar al 100% nuestra seguridad. Eso quiere decir que ese % de riesgo residual se puede traducir en un % de certeza residual acerca de nuestra seguridad plena. ¿Se puede estar un 95% seguro de que los sistemas de información no han sido violados? Eso es precisamente lo que habría que garantizar en términos estadísticos.

Y el artículo continúa con un check-list de elementos a verificar para poder garantizar esa seguridad de los sistemas. Un check-list interesante, sobre todo, para plantearnos cuál es el nivel de supervisión que tenemos sobre nuestra seguridad. ¿Cuántos de estos ítems aparecen en nuestro cuadro de mando de seguridad? ¿En qué parámetros nos basamos para responder a preguntas sobre nuestra seguridad? Vemos la lista:
  • Identificadores de usuario (no) autorizados.
  • Servicios corriendo (no) conocidos.
  • Fecha (des)actualizada y/(o) (des)sincronizada.
  • Sistemas (no) desarrollados bajo normativas y estándares, incluyendo los de seguridad.
  • Vulnerabilidades conocidas (no) parcheadas.
  • Actividad del administrador (no) autorizada.
  • (No) Ausencia de alertas en los sistemas de seguridad -Antimalware, IDS/IPS, SIM, etc.-.
  • Parámetros de funcionamiento de los servidores (in)controlados -carga, ocupación, etc.-.
  • (No) Ausencia de tráfico inusual en la red -firewall, routers, etc.-.
  • Anti-malware (des)actualizado.
  • (No) Ausencia de intentos fallidos de log-on.
  • (No) Ausencia de errores en los logs de los sistemas y aplicaciones.
  • (No) Ausencia de accesos físicos no autorizados.
  • Caídas de los sistemas (no) justificadas.

Seguro que a todos se nos ocurren más apartados a controlar, pero la pregunta es... ¿Cuántos de ellos controlamos? ¿Sobre cuántos somos capaces de responder adecuadamente? Y en última instancia... ¿Qué argumentos tenemos, en realidad, para poder asegurar con bastante certeza que nuestros sistemas son seguros? Porque no olvidemos que hay dos motivos para no registrar incidentes de seguridad: que no los tengamos o que no nos enteremos de que suceden.

22 septiembre 2008

Cesiones al Gran Hermano

La verdad es que hoy no tengo muchas ganas de escribir. Y no porque el tema no sea interesante, sino porque creo que deberíais ser vosotr@s, los lectores, los que escribais.

Últimamente parece que Google está en boca de todos. Nuevo navegador (por cierto, os dejo un link a una comparativa de navegadores que me ha gustado), nuevo sistema operativo para móviles, nueva política de retención de datos, ... Y de fondo, el eterno debate sobre si Google es o no el nuevo Gran Hermano. Al respecto, una de las opiniones más equilibradas que he leído es la de Asbel López, que hace referencia a un aspecto fundamental desde mi punto de vista: la cesión de información a Google es voluntaria. ¿Estais de acuerdo con esta postura? ¿Cambia algo el hecho de que los usuarios sean o no conscientes de esa cesión?

Otro de los aspectos sobre los que me gustaría incitar a la reflexión es el relativo a la significancia individual. Está claro que un árbol en medio de una estepa destaca claramente. Pero si ese mismo árbol está en medio de un bosque de árboles ya no destaca, sólo es uno más, y toda la curiosidad que podía despertar ese árbol tiende a desaparecer. ¿Creéis que cambia algo el hecho de que la información recopilada de cada individuo sea sólo una más entre los millones de individuos de los que se tienen datos? ¿Tendría importancia la existencia de un tratamiento diferenciado de la información de ciertos individuos particulares? ¿Y la no diferenciación de nadie?

Por último, sólo me queda volver a recordar que, desde mi punto de vista, el concepto de privacidad de las nuevas generaciones está cambiando. ¿Cuál es el valor que damos a nuestros datos personales? ¿Es un valor objetivo o subjetivo? ¿Cuál es el valor que tiene la información? No olvidemos que hoy en día también se comercia con la información...

18 septiembre 2008

Abrimos la empresa?

Estos días he leído con bastante interés algunos post acerca de la conveniencia o no de "abrir" la empresa a los "nuevos" servicios web 2.0. En el primero de ellos, tic616 comentaba la noticia de que una cierta empresa estaba considerando relajar las políticas de seguridad para acomodar aplicaciones destinadas a usos personales, ya que "tanta" seguridad podía hacer menos atractiva la empresa para potenciales candidatos con talento.

Bajo el post en cuestión creo que se esconden un par de asuntos distintos, aunque relacionados. Por una parte subyace el debate de si se debe permitir o no el acceso a servicios web personales desde el puesto de trabajo. Pero también creo que hay un importante componente de "filosofía empresarial" si entendemos el post como valorar la posibilidad de utilizar este tipo de servicios con fines corporativos y de manera oficial (no sólo a título particular).

En el primer caso el debate es evidente. ¿Hasta qué punto tenemos que permitir el uso personal de los recursos corporativos? Es un debate clásico en el que hoy no me voy a meter, ya que es precisamente el tema de debate en los siguientes post de tic616 (informática corporativa y uso personal I y II) y además me parece más interesante la segunda opción. Esta vía es ir más allá de integrar una wiki en nuestros servidores para favorecer la gestión del conocimiento, es utilizar los servicios de blogger, por ejemplo, para publicar el blog corporativo. ¿Qué hacemos en este momento con las políticas de seguridad? Estamos adheriéndonos a unos servicios cuyo uso no está planteado desde el punto de vista corporativo, por lo que el "contrato" difícilmente va a reflejar nuestras necesidades corporativas. ¿Están las empresas a día de hoy, desde el punto de vista de la seguridad jurídica, para valorar y gestionar este riesgo?

Curiosamente, si avanzamos en esta vía de hacer un uso corporativo de los servicios pensados para el público particular, el camino empieza a converger con el primer planteamiento del uso personal de los recursos corporativos. ¿Hasta qué punto vamos a ser capaces de diferenciar el uso corporativo y el uso personal de estos servicios? ¿Vamos a poder establecer unas normas claras para que todo el personal sepa si puede o no puede usar dichos servicios de una u otra forma, en función del uso que se le de? Porque lo que tenemos que tener claro es que es imposible conseguir que se sigan unas normas que no son lo suficientemente claras. ¿Seremos capaces de establecer normas diferentes en función del uso que se haga de un cierto servicio? ¿O nos veremos obligados a decidir sólo si permitimos o prohibimos su uso, sabiendo que puede ser al mismo tiempo corporativo y personal? Porque de lo que estoy seguro es de que es algo que poco a poco nos vamos a ir encontrando, sobre todo cuando las nuevas generaciones vayan accediendo al mercado laboral.

15 septiembre 2008

Los seguros tambien cuentan

Después de realizar un análisis de riesgos todos somos conscientes de que existen 4 estrategias posibles para gestionar esos riesgos: eliminarlos, transferirlos, reducirlos o asumirlos. Lo que ocurre es que normalmente sólo nos acordamos de las dos últimas opciones, obviando las posibilidades que nos ofrecen las dos primeras.

El parámetro principal para ayudarnos a decidir cómo se gestionan los riesgos debería ser la relación coste/beneficio. Y ojo, que coste no es lo mismo que precio, aunque al final podamos llegar a traducirlo de esa forma. ¿Por qué digo esto? Porque ese es el factor clave para la eliminación de riesgos. ¿Qué beneficio aporta a mi organización el comercio electrónico? ¿Cuántos ingresos nos supone? ¿Qué futuro espero de ese canal de vantas? ¿Ese beneficio (tanto presente como futuro) compensa los riesgos que supone esa infraestructura? Ese es el análisis que hay que hacer para poder llegar a la conclusión de que podemos eliminar todos los riesgos asociados a las ventas por internet, eliminando dicho canal.

La otra opción que normalmente se suele quedar en el tintero es la de transferir los riesgos. Y aquí hay que tener cuidado, porque no es una opción sencilla, y no todos los riesgos se pueden transferir. ¿Transifero el riesgo derivado de la ejecución de un proceso por el mero hecho de subcontratarlo en modo BPO? Pongamos el caso de un banco que subcontrata por completo la gestión de ventas por Internet. Como mínimo está transfiriendo el riesgo operativo asociado a estas actividades. ¿Está transfiriendo completamente el riesgo? En absoluto. ¿Acaso no es la subcontratación en sí misma la asunción de un cierto tipo de riesgo? ¿Qué consecuencias tendría en la imagen de ese banco un incidente de seguridad en la empresa subcontratada? Es obvio que el riesgo no se puede transferir por completo. Lo que sí se puede transferir es una parte del riesgo, y esta transferencia también puede servir para transformar un tipo de riesgo en otro (en el ejemplo, un riesgo operativo lo convertimos en un riesgo contractual).

Y en este punto es donde aparecen los seguros. Su trabajo consiste precisamente capitalizar los riesgos que les transfieren sus clientes. Y los riesgos de seguridad de la información también se pueden transferir de este modo. Quizás no estemos muy acostumbrados a ellos, pero estoy seguro de que es una tendencia que va a ir al alza. ¿Cuál es el coste de adoptar una determinada medida de seguridad para reducir un determinado riesgo? ¿Y cuál puede ser el coste de adquirir un seguro que cubra ese posible incidente de seguridad? Las empresas que trabajan con "seguros cibernéticos" piensan de este modo. Al fin y al cabo, si me sale más "barato" (en términos de coste global, no sólo en términos directamente económicos) "apechugar" con el incidente y usar el dinero del seguro que reducir el riesgo asociado a él estamos ante una mejor opción en términos de coste/beneficio. ¿Por qué no hacer uso de ella?

Por supuesto, antes de terminar con el post tengo que recordar que los seguros no son la panacea. Por poner un ejemplo, podemos pensar que el perjuicio en imagen derivado del incidente vamos a poder recuperarlo invirtiendo parte del dinero del seguro en una campaña de marketing. Ahora bien... ¿Cuándo vamos a disponer de ese dinero en efectivo? ¿Podremos ejecutar la campaña en el momento en el que es necesario? ¿Existirán costes adicionales derivados de tener que litigar con el seguro porque no nos ha dado el dinero que esperábamos? En resumidas cuentas: ¿Estamos gestionando adecuadamente el riesgo de contratar ese seguro?

10 septiembre 2008

Que certifica una ISO 20000

Cada vez que empiezo a hablar con algún compañero de la ISO 20000 acabamos siempre con el mismo debate. ¿Qué certifica exactamente una ISO 20000? Sí, certifica un Sistema de Gestión de Servicios IT. Pero... ¿qué es exactamente un servicio IT?

La pregunta, que podría parecer trivial, no lo es en absoluto. La norma, curiosamente, no define qué es un servicio IT. Y sinceramente, la definición dista mucho de estar estandarizada. ¿Creéis que no? Echadle un vistazo a este post de Antonio Valle sobre la importancia de las definiciones, y veréis que no miento.

¿Cuál es exactamente el problema? Que la norma no especifica en ninguna parte si al hablar de servicio IT está pensando en servicios técnicos (servicios prestados por una máquina, tipo correo electrónico o almacenamiento) o servicios profesionales (servicios prestados por personas, tipo consultoría o mantenimiento de sistemas de segundo nivel). Lo que sí especifica la norma es que tienes que desarrollar los 13 procesos (y recordad que proceso no es lo mismo que servicio) que especifica para poder gestionar esos servicios adecuadamente. Y claro, si pensamos, por ejemplo, en la gestión de la capacidad, no es lo mismo gestionar la capacidad de un servicio de correo electrónico que gestionar la capacidad de un servicio de consultoría. Por no hablar de la gestión de versiones de ambos servicios...

La solución que se me ha ocurrido es consultar los alcances de las empresas certificadas, para ver qué tipo de servicios son los que se certifican. Así que me he ido al registro internacional y he consultado las empresas certificadas en España. Los resultados son, en traducción y simplificación libre, los siguientes:
  • La instalación, operación, administración, gestión, soporte, mantenimiento y reparación de sistemas TIC.
  • La provisión de servicios de hosting y housing.
  • El outsourcing de servicios de backup, acceso a internet y monitorización.

Es decir, que aparentemente se pueden certificar ambos tipos de servicios (yo entiendo el primer caso como servicios profesionales y el segundo como servicios técnicos).

En busca de más información se me ha ocurrido la posibilidad de ver si en los foros de itSMF España había algo útil, y la verdad es que tampoco he encontrado una solución definitiva. Veo con agrado que mi opinión coincide con la de Antonio, pero nadie parece tener una respuesta clara. De hecho, en otro de los foros me encuentro con un nuevo alcance, que también parece un servicio profesional:

  • Servicios Gestionados de explotación de los sistemas y actividades relacionadas de la División de Tecnología de Sistemas

En definitiva, no tengo nada claro si es o no admisible la certificación de servicios profesionales. Siendo estrictos yo entendería que no, pero el enunciado de algunos alcances parece contradecir mi opinión. No obstante, sería necesario conocer el catálogo de servicios certificados para ver si realmente estamos o no ante servicios profesionales (puede que sencillamente el enunciado del alcance de esa impresión, pero luego los servicios sean IT "puros"). ¿Alguien tiene alguna información al respecto? ¿Alguien podría aportar algún dato esclarecedor? También estaría bien si alguien nos pudiera aclarar el espíritu de la norma... Si hay alguna persona que pueda ayudarnos a resolver esta duda, desde aquí le animo a que lo haga. Los comentarios están a su disposición.

08 septiembre 2008

El riesgo como valor

Este post sigue la misma línea que el artículo Análisis de Riesgos en tiempos de crisis, cuyo objetivo es dejar de ver el riesgo como algo negativo y empezar a verlo como algo intrínsecamente ligado al negocio. Por eso quiero referenciar hoy una noticia de hace ya algún tiempo, en la que se hacían eco de un informe que asegura que las economías emergentes utilizan el riesgo para aumentar la ventaja competitiva. Un artículo muy interesante en el que se ilustra cómo el riesgo puede ser utilizado como factor de beneficio directo en el negocio.

En el artículo se plantea la inversión en gestión del riesgo como un factor de ventaja competitiva, traducido en la práctica en hechos tan tangibles como contar con un director de seguridad corporativa o de riesgo corporativo en el consejo de dirección. Parece que las empresas que apuestan por el riesgo como ventaja competitiva centran su estrategia de gestión del riesgo en las siguientes líneas de actuación:
  • Usar la gestión del riesgo para promover la innovación.
  • Desarrollar estrategias de gestión del riesgo para amenazas globales.
  • Apostar por la colaboración (real) inter-organizaciones como factor de éxito.
  • Confiar en las políticas de gestión del riesto TIC.

Desde mi punto de vista, la filosofía que subyace en estos principios es simple pero efectiva. Por una parte, se gestionan los riesgos de forma "optimista", desde el punto de vista de alguien que tiene "poco" que perder y mucho que ganar. Además, las amenazas se entienden no como algo contra lo que luchar, sino como algo cuya existencia hay que asumir y, si es posible, utilizar en nuestro beneficio. Y a partir de ahí se construyen una serie de políticas de gestión del riesgo que tratan de "obviar" los perjuicios y maximizar los beneficios, nombrando una figura cuyo cometido sea precisamente el de exprimir esos beneficios planteados. Y para que las propias limitaciones de la organización no supongan un obstáculo a las propuestas que se planteen se ligan dichas propuestas a los programas de innovación y creatividad de la compañía. A partir de ahí, las líneas de actuación sobre las que desarrollar las políticas que se definan símplemente tratarán de ser lo más eficientes y eficaces, de forma que se apoyen en programas de colaboración para reducir o distribuir costes y en el uso de las TIC para aumentar el rendmiento de las soluciones que se planteen. Quizás se pueda pensar que son estrategias arriesgadas, pero precisamente estábamos hablando de que la clave era precisamente asumir más riesgos en aquellos ámbitos en los que se puede maximizar el beneficio...

En definitiva, creo que es posible orientar la gestión de riesgos para conseguir que ese alineamiento con el negocio sea algo tangible. Sólo hace falta exprimirse un poco el cerebro, y creo que esta época empresarial que atravesamos puede ser un buen momento...

04 septiembre 2008

Integridad de la información pública

La verdad es que no tenía muy claro si escribir o no este post. Por una parte creo es fácil dejarse llevar por la inercia y escribir sobre el fatídico accidente de barajas, pero por otra me causa cierto rechazo tener la sensación de que soy partícipe del amarillismo que rodea esa noticia. Así que me he pasado unos cuantos días dándole vueltas al tema, aunque finalmente he decidido escribirlo. Sólo espero que nadie se sienta molesto al leerlo.

Probablemente todos tengamos muy claro que la integridad de la información, a nivel general, es algo importante. Pero hay ciertos casos en los que dicha integridad es especialmente relevante, por distintos motivos. Uno de ellos es el relativo a la información que ponemos a disposición del público en general, debido a los problemas de imagen (entre otros) que puede ocasionar que la información que publicamos oficialmente sea incorrecta. Es importante que la información sea veraz, como ya expuse en su momento, pero también es clave que la información sea íntegra una vez difundida. Y si está la opinión pública pendiente de ella, mucho más. Y sobre todo si no es sólo la imagen de la organización la que está en juego, sino que esa información afecta a título personal a una gran cantidad de personas y de manera general a los sentimientos de toda una sociedad. Por eso no me explico cómo, en unos comunicados oficiales, aparece un comunicado (nº 2) en el que indica que en el avión había 164 pasajeros y 9 tripulantes, otro (nº 3) en el que se indica que son 162 pasajeros y 10 tripulantes, y por fín una lista oficial donde actualmente sí que figuran 160 nombres propios + 2 bebés (aunque en el momento en el que la contrasté creo recordar que sólo contabilicé 161).

Es cierto que los comunicados están publicados en momentos difíciles, y que se pueden producir errores de contabilización. Pero también es cierto que estamos precisamente ante un os comunicados oficiales, donde la información se presupone más que verificada y validada. Si hubieran sido erratas o errores de recuento se deberían haber indicado como tal, y si hubiese existido incertidumbre en los datos no se deberían haber publicado datos exactos. Porque, al fin y al cabo, ¿cuál de los dos comunicados es el que tiene validez, si ninguno desmiente al otro? ¿Qué argumentos reales tenemos para suponer que el cronológicamente posterior es el válido? ¿Y si la lista de pasajeros realmente hubiera tenido sólo 161 nombres?

Hay personas que creen que debemos mejorar la forma de reaccionar ante un desastre desde los planos informativo y organizativo. De lo que estoy seguro es de que éste puede ser un buen ejemplo para analizar cómo puede reaccionar una organización ante una situación de crisis, y para intentar aprender de los errores ajenos. Al fin y al cabo, la gestión de una crisis desde el punto de vista informativo (hacia todos los grupos de interés) es un apartado fundamental dentro de los planes de continuidad de negocio. ¿Cuántas organizaciones tienen este aspecto en cuenta dentro de sus pruebas periódicas programadas? Seguro que todos somos capaces de extraer alguna lección de este hecho... y ójala que esas lecciones aprendidas sirvan para que catástrofes como la sucedida no se vuelvan a producir.

01 septiembre 2008

Escribiendo Políticas de Seguridad

Hoy quiero referenciar una serie de post sobre Políticas de Seguridad que nos ofrece apokalyptica79 en su blog, que aprovecho para recomendar.

El primero de ellos es una introducción a las políticas de seguridad, en el que trata de definir exactamente qué es eso de las políticas de seguridad y cuáles son sus connotaciones más importantes. Como ya he comentado en otras ocasiones, no estoy de acuerdo en la simplificación que se hace al reducir la seguridad de la información a un concepto más acotado como es el de la seguridad informática, pero aun así sigo considerando que la introducción es muy instructiva.

El siguiente post trata de justificar la necesidad de las políticas de seguridad, desde el punto de vista de herramienta regulatoria ya presentado en el post anterior, y además presenta una estructura típica de políticas de seguridad, basada en el índice propuesto por la serie 27000 y con un listado muy interesante de elementos que debe contener una buena política de seguridad en cualquiera de los citados ámbitos.

Y el último (al menos, por el momento) de los post sobre políticas de seguridad es el referido al propio proceso de elaboración de las políticas de seguridad, en el que detalla distintos elementos a tener en cuenta durante la elaboración de las políticias (aspectos a considerar, participantes, etc.). En conjunto, una excelente tripleta (y ójala que siga evolucionando en cuarteto, quinteto o más) de artículos que puede servirnos de gran ayuda a la hora de enfrentarnos a la dura tarea de escribir políticas de seguridad para nuestra organización.

19 agosto 2008

Direccion y seguridad: siguen sin entenderse

Me gustan los artículos donde, sin necesidad de aportar nada especialmente novedoso, son capaces de resumir y concretar en pocas palabras muchas ideas que siempre andan revoloteando por ahí pero que pocas veces encontramos sintetizadas. Este artículo, que explica los 10 peores errores de la dirección en materia de seguridad de la información, es uno de ellos. En resumen, estos errores vienen a ser los siguientes:
  • Asignar la seguridad de la información a personal no especializado: No me parece tan grave el hecho inicial, sobre todo teniendo en cuenta que no es tan sencillo encontrar a alguien realmente especializado, como la segunda parte, la de no proporcionar a esa persona la formación especializada que requiere. Aunque normalmente sí que le exijan que haga bien la función que le han asignado...
  • Seguridad de ámbito parcial: Es un caso muy habitual, y es no ver la seguridad de la información desde el punto de vista del negocio, global, sino restringirlo a un ámbito determinado, normalmente IT o seguridad física.
  • Falta de entendimiento: Aunque es posible que la culpa en este caso sea más de los responsables de seguridad, hay que ser capaz de traducir la inversión en seguridad a términos de negocio, que entienda la dirección.
  • Insuficiente mantenimiento de los dispositivos de seguridad: Aunque el artículo sólo habla de que los dispositivos de seguridad no sólo hay que comprarlos, sino mantenerlos y operarlos para que sigan siendo efectivos, yo también recordaría aquí aquello de que no es suficiente con tener (incluso actualizados) "cacharros" de seguridad. La seguridad real va mucho más allá...
  • Seguridad dependiendo de informática: También suele pasar, y es un agravante del caso de seguridad de ámbito parcial. Como bien dice el artículo, no se puede ser juez y parte.
  • Externalizar completamente la seguridad informática: Aunque también se puede hablar del mismo problema ligado sólo a uno de los dos términos (seguridad o informática), la externalización completa no suele ser una buena solución. El principio de que la responsabilidad nunca se puede delegar (y mucho menos en un externo, añadiría yo) debe ser el principio fundamental.
  • No valorar adecuadamente la información: Si la clave de un SGSI son los activos de información es por algo. Toda compañía debería saber con qué información trabaja y cuál es su importancia en términos tanto internos como de mercado, y no olvidar de contrastar esos valores desde el ámbito de la reputación corporativa.
  • Actuar de forma reactiva y con parches: Me temo que uno de los males más extendidos del mundo empresarial es no atajar las causas de los problemas, y en el ámbito de la seguridad este hecho es especialmente grave.
  • Ignorar los problemas: Es un comportamiento muy unido al anterior. La frase de que la ignorancia es atrevida es una verdad universal, pero en materia de seguridad esa ignorancia no nos va a salvar de los incidentes, ni de pagar sus consecuencias si llegan a ocurrir.
  • Maquillar resultados por motivos presupuestarios: Es una de las prácticas más negativas en torno a la seguridad, ya que no sólo no se atajan los problemas sino que probablemente se agraven, mientras se mantenga la intencionalidad de ocultar los hechos. Y si encima se debe a motivos presupuestarios la situación es peor todavía, ya que supone que la inversión no se administra donde es necesaria...

En resumen, creo que es un listado bastante interesante. Y no por ser un análisis exhaustivo de los problemas más graves, sino porque es un buen ejemplo que puede servir a cualquiera como espejo en el que mirarse. ¿Os habeis sentido identificados? ¿Creeis que habeis superado estos 10 errores? Espero que no salgais demasiado mal en la foto...

13 agosto 2008

Analisis de Riesgos en tiempos de crisis

Como parece que está de moda eso utilizar la crisis como pretexto para hablar de casi cualquier cosa, he decidido subirme yo también al carro antes de que se convierta en un recurso tan explotado que el título del post pierda la "gracia" (queda bien, verdad?) :-)

Evidentemente, los análisis de riesgos son unas actividades que pueden salir reforzadas cuando toca apretarse el cinturón. Nos permiten analizar, de forma "objetiva" y cuantificada, el riesgo que sufre una organización frente a un determinado catálogo de amenazas. Y sobre todo nos permite jerarquizar estos riesgos en base a los resultados del análisis, y poder priorizar la solución de aquellos que tras el análisis hayan sido identificados como más preocupantes. Está claro que, en épocas de limitación de recursos, un buen análisis de riesgos nos permite aumentar la eficacia de la inversión dedicada al tratamiento de los riesgos, ya que somos capaces de dedicar los recursos allá donde más falta hacen, y por lo tanto donde mejores resultados (en términos de disminución del riesgo global) van a ofrecer.

Sin embargo, aunque los análisis de riesgos puedan parecer unas herramientas útiles en este tipo de situaciones, no hay que perder de vista que son herramientas "defensivas". Son actividades cuyo objetivo último es el de minimizar pérdidas, lo que es propio de una estrategia conservadora. Sin embargo, frente a esta forma de abordar tiempos difíciles, puede haber organizaciones que apuesten por una estrategia "ofensiva", estableciendo un objetivo complementario al anterior, consistente en maximizar ganancias. ¿Es posible encajar un análisis de riesgos en este planteamiento?

La verdad es que no se me ocurre el modo de hacer que un análisis de riesgos encaje de forma natural en una estrategia como la planteada. Supongo que estoy demasiado "intoxicado" después de tantos años justificando el ROI de la seguridad desde un punto de vista de "disminución de pérdidas". Sin embargo, sí que se me ocurre una forma de abordar la situación: al igual que hemos buscado la situación complementaria a la minimización de pérdidas, ¿Por qué no tratamos de encontrar la herramienta complementaria al análisis de riesgos?

La propuesta es muy sencilla. Un análisis de riesgos parte de una serie de activos (factor neutro) para analizar los riesgos (factor "negativo") mediante la cuantificación de dos factores también "negativos", las amenazas y las vulnerabilidades. La propuesta es, sencillamente, rehacer ese mismo análisis de riesgos mediante la cuantificación de los factores complementarios ("positivos") a las amenazas y las vulnerabilidades.

¿Cuáles son esos factores complementarios? A partir de los conceptos no resulta muy complicado identificarlos. Si las amenazas son agentes capaces de provocarnos algún daño, el complementario sería un agente capaz de provocarnos algún beneficio. Y si la vulnerabilidad es lo susceptibles que somos a que ese daño se materialice, lo contrario sería identificar cómo de predispuestos estamos a que ese beneficio se materialice. Si lo queremos llamar de algún modo, podríamos llamar oportunidad al opuesto de la amenaza y fortaleza al opuesto de la vulnerabilidad. ¿A alguien le suenan estos conceptos? Si sustituimos el término vulnerabilidad por un sinónimo como debilidad, quizás sea más fácil reconocerlo. ¿Ahora sí, verdad? Efectivamente, nos encontramos con un cuarteto de conceptos (Debilidades - Amenazas - Fortalezas - Oportunidades) ampliamente utilizado en un determinado tipo de análisis estratégico: los análisis DAFO.

Por lo tanto, ¿Cual es la propuesta? Se trata, sencillamente, de llevar a cabo un análisis de... (anti-riesgos? potencialidades? la verdad es que no he sido capaz de encontrar una palabra que me convenza del todo, así que os animo a que me propongais alguna otra), teniendo en cuenta las oportunidades y las fortalezas asociadas a cada activo de nuestro análisis. O, mejor aún, llevar a cabo un análisis global, en el que analicemos tanto los riesgos como las potencialidades (a falta de otra palabra, me quedo con esta), dentro del mismo análisis. De cara a su cálculo numérico sería tan sencillo como añadir un signo negativo a las amenazas y valorar en positivo las oportunidades... ¿Es esta propuesta, entonces, similar a realizar un análisis DAFO? No, ya que hay varias diferencias sustanciales:
  • Los análisis DAFO no se cuantifican, mientras que los análisis de riesgos y potencialidades sí.
  • Los análisis DAFO se realizan valorando a la organización de forma global, mientras que los análisis de riesgos y potencialidades se realizan activo por activo.
  • Y lo que es más importante, el objetivo de un análisis DAFO es exclusivamente el de estudiar la situación competitiva de una empresa dentro de su mercado, mientras que el objetivo del análisis de riesgos y potencialidades es el estudio de dichos riesgos y potencialidades... en la materia que pongamos de coletilla (en el caso más habitual en este blog, los riesgos y potencialidades de seguridad de la información, pero podría ser cualquier otro).

Pese a todo, estas diferencias no suponen un abismo infranqueable entre ambos análisis. Tanto aquellos que estén acostumbrados a realizar análisis DAFO como aquellos que suelan realizar análisis de riesgos estándar van a ser capaces, sin demasiadas complicaciones, de llevar a cabo un análisis como el propuesto. Sólo es necesario un pequeño esfuerzo mental para ser capaces de ampliar nuestro punto de mira. Y, al fin y al cabo, eso es lo que nos toca a todos en estos tiempos de crisis, verdad?

11 agosto 2008

La curiosidad, un enemigo de la seguridad

Todos estamos acostumbrados a escuchar aquello de que el mayor foco de riesgo viene del interior de nuestras organizaciones. Y es que, por el simple hecho de tener que acceder a información privilegiada para realizar su labor, nuestros usuarios son precisamente los que más fácil pueden provocar su exposición no autorizada. Argumentos tan simples como los malos hábitos de estos "insiders" son, en la práctica, las causas más habituales de las brechas de seguridad. Aunque eso no quita para que haya otros estudios que afirmen, a la contra, que dicha amenaza es exagerada... La clave de esta contradicción la podemos encontrar, tal y como nos aclara Sergio Hernando en su análisis de dicho estudio, en el impacto que producen cada tipo de incidentes: como era de esperar, las brechas de seguridad con origen interno provocan mucho mayor impacto que las de origen externo. De todas formas, los resultados de dicho estudio parecen ser bastante dispares en relación a los de otros estudios similares que van apreciendo, y que nos viene a recordar que las violaciones de seguridad interna parecen ir en constante crecimiento...

Pero el objetivo del post de hoy no es disertar sobre si el mayor foco de riesgo está dentro o fuera de la organización, sino analizar una de las causas más frecuentes de la aparición de brechas de seguridad: la curiosidad. Desde mi punto de vista esta es, junto con los errores y los cabreos, una de las tres principales causas de los incidentes de seguridad.

La curiosidad es algo innato al ser humano, y uno de los principales motores de nuestro aprendizaje. Esto es así desde la más tierna infancia, y cuanto mayores sean las ganas de aprender de una persona más desarrollada estará su curiosidad. Curiosidad, obviamente, hacia lo desconocido, y sobre todo hacia aquello que sabemos que se puede llegar a conocer. ¿Y qué mejor entorno para desarrollar esta curiosidad que un entorno en el que se trabaje con distintos niveles de clasificación de la información, con información cuya distribución esté restringida, o en el que las personas muestren (o se les exija, incluso) una importante capacidad de aprendizaje?

Esta curiosidad mueve a muchas personas a tratar de conocer qué hay más allá de su ámbito. '¿Hay algo interesante en el monitor de al lado, en la mesa de al lado, en el fichero de al lado? Seguro que sí! ¿Y por qué no tratar de ver si me puedo enterar?' Conocer lo prohibido, descubrir lo que sabemos que existe, es una motivación muy intensa para algunas personas. Y no es necesario que haya una motivación ulterior, el descubrimiento en sí mismo ya es suficiente premio. ¿Quién no ha querido conocer la nómina de su jefe, o el contenido de una carpeta del servidor de ficheros etiquetada como "top-secret"? Y es que, al fin y al cabo... ¿A quién no le gustaría ser el protagonista de una peli de espías?

Ante esta amenaza es muy complejo luchar. Nunca podremos eliminar este tipo de motivaciones, son inherentes al propio ser humano. Aquí ni siquiera la concienciación sirve, sobre todo si pensamos en la cultura "mediterránea" (quizás con una forma de ser mucho más rigurosa, como la asiática o la germana, sí que fuese posible). ¿Qué estrategias podemos adoptar? A mí se me ocurren dos.

La primera es la obvia: centrarnos en los controles, en las normas de seguridad, y reforzarlas para ser capaces de impedir que esos impulsos de curiosidad sean fructíferos. Limitar al máximo la cantidad de "pistas" sobre la existencia de algo "más allá" puede ser una buena estrategia: si no somos conscientes de que existe tierra al otro lado del mar probablemente no querramos arriesgarnos a cruzarlo.

Por contra, la segunda es totalmente opuesta: máxima apertura y transparencia. Si todo el mundo puede conocer toda la información, no hay forma de que se produzcan brechas de confidencialidad. La curiosidad puede ser plenamente saciada. ¿Os parece una alternativa válida?

Obviamente, cada una de las opciones tiene sus ventajas e inconvenientes, y seguro que ambas tienen sus defensores y detractores. ¿Qué beneficios veis a cada una de ellas? ¿Cuál os parece más viable? ¿Cuál más efectiva? Estoy deseando escuchar vuestras opiniones

De nuevo On-Line

La verdad es que me da un poco de apuro ver que, en los últimos 2 meses, sólo aparece un triste post en el blog. Podría echar parte de la culpa a las vacaciones o al intenso fin de semestre profesional que tuve, pero la verdad es que no sería del todo sincero. En realidad la culpa la tiene el verano y el síndrome de pereza bloguera que estoy sufriendo. Pero hoy me he levantado más animado, así que estoy dispuesto a combatir este síndrome de la mejor forma posible: con nuevos e interesantes (espero) post sobre seguridad y gestión... y muchas otras cosas más. Espero que os gusten!

07 julio 2008

Buceando en la certificacion ISO 27001

Hace unos días un compañero me reenvió un documento que, la verdad, había pasado por alto. El documento en cuestión es una traducción realizada por el ISMS Forum Spain de un documento de Fabrizio Cirilli, presidente de ISO 27001 ISMS IUG ITALY, sobre la implementación y certificación de los SGSI. Como creo que el documento sólo es accesible para socios de ISMS Forum, paso a realizar un brevísimo comentario de los aspectos más destacables, desde mi punto de vista, del documento:
  • Orígenes de la ISO 27001: Las recomendaciones de la OCDE y la BS 7799.
  • Requisitos definidos por la ISO 27001: Un estupendo esquema donde identifica las fases del ciclo PDCA con cada apartado del estándar y un claro listado de los requisitos de la norma a todos los niveles (documentos obligatorios, obligaciones de cada apartado, etc.).
  • Cambios y evolución de la BS7799-2 a la ISO 27001 (y proceso que siguieron todas las organizaciones certificadas en la norma británica para "homologar" internacionalmente sus certificados).
  • Certificación de un SGSI: Por qué certificar el SGSI y pasos a seguir para lograrlo, incluyendo las exigencias en relación a cada apartado de la certificación y una explicación de cómo se lleva a cabo una certificación.
  • Acreditación de un certificado: Por qué las empresas certificadoras deberían también "certificarse" a su vez, y en qué normas se basa dicha certificación (como listado de referencia, y sin pararme demasiado a analizar las implicaciones de cada una de ellas, podemos decir que en el caso concreto de los SGSIs son de aplicación en mayor o menor medida las normas ISO17021, ISO 19011, EA7/03, ISO 27006 y EN 45012).

Y en resumen esos son los aspectos más destacables del documento. Una lectura más que recomendable para todo aquél que quiera adentrarse un poco más en los vericuetos de las certificaciones, y sobre todo una buena guía de profundización para todos aquellos que quieran certificar un SGSI.

18 junio 2008

Empleado descontento

Hace unos días día leía una noticia sobre un ex-empleado que borró la información de su antigua compañía, al parecer furioso con su organización por hacer recibido un informe laboral desfavorable.

Más allá de los típicos comentarios que se puedan hacer al respecto, de los cuales tenemos una buena representación asociados al propio artículo, creo que es necesario prestar atención a algunos aspectos que creo que pueden ser significativos:
  • La persona en cuestión parece que tenía problemas de relación inter-personal. Si el hecho ya estaba en conocimiento de RR.HH., como parece, vamos a la segunda derivada. ¿Se habían analizado las posibles consecuencias más allá de el propio hecho? ¿Existía una especial atención al comportamiento de esta persona desde otros puntos de vista, como podría ser el de seguridad de la información?
  • Estamos ante una persona con importantes privilegios dentro de la organización, ya que se trata del director de servicios técnicos. Alguien que de hecho tenía que poder realizar las acciones que desarrolló si hubiera seguido formando parte de la organización. ¿Cuál era la estructura de control interno de la compañía? ¿Cómo se supervisaba o auditaba la actividad de las personas con mayores privilegios, que son precisamente las que tienen el mayor riesgo potencial asociado?
  • Tras su dimisión se pudo conectar a los sistemas para llevar a cabo las acciones ilegales. ¿Por qué no funcionó el procedimiento de bajas? ¿No hubiera sido necesaria una especial atención dado el perfil del sujeto, de altos privlegios, y las condiciones de la baja, en forma de "dimisión airada"?

El hecho que quiero destacar es que, en este caso, no es que se produjera un fallo concreto en un elemento específico de la organización, sino que la pérdida de casi medio millón de dólares estuvo producida por la concurrencia de fallos de seguridad en distintos ámbitos (seguridad ligada al personal, monitorización, procedimiento de bajas, ...). Es un claro ejemplo no sólo de que los mayores riesgos de seguridad están dentro de casa, sino de que sin una estrategia que trate la seguridad de forma global es probable que aparezcan casos en los que una conjunción de factores de riesgo sean capaces de desencadenar graves pérdidas para la organización. ¿Hubiera sido posible evitar el incidente con un buen SGSI? Yo creo que sí...

11 junio 2008

Guia basica de adecuacion a la LOPD

Esta semana me he encontrado con un artículo muy sencillo de entender para todo aquél que quiera adecuarse al cumplimiento de la LOPD. El artículo en cuestión se titula LOPD: ¿Una necesidad o una obligación?, y describe de forma secuencial y muy fácil de entender cuales son los pasos que tiene que dar una empresa que vaya a iniciar un proyecto de adecuación a la LOPD. Seguro que no aporta gran cosa a la mayor parte de los lectores de este blog, pero también es seguro que es de gran ayuda para todas aquellas empresas que, con esto del nuevo reglamento, se hayan dado cuenta de que tienen que cumplir la LOPD y no tienen muy claro qué es lo que tienen que hacer en realidad. Sobre todo desde el punto de vista práctico.

La única pega que le puedo poner al artículo es el excesivo tinte comercial que tiene el artículo al final. Estoy de acuerdo en que siempre es mejor contar con una asesoría especializada, sobre todo si la empresa no tiene a nadie con formación específica en estos temas (y me temo que es el caso de muchas PYMEs), pero no estoy de acuerdo con el tinte de exigencia que parece cobrar en el artículo el hecho de contar con una buena consultora como respaldo.

Y al hilo de los párrafos finales del artículo, en los que se señala que la empresa que se quiera adecuar a la LOPD debería exigir una cualificación mínima a la empresa consultora, me gustaría plantear algunos interrogantes. Las exigencias en relación a las auditorías externas que planteaban algunos borradores del nuevo reglamento acabaron desapareciendo del texto final. A día de hoy no existe ningún tipo de requisito ni certificación cuyo cumplimiento sea obligatorio para realizar auditorías de LOPD. ¿Creeis que sería necesario establecer algún tipo de requisito para los auditores de LOPD y/o para las empresas que realizan este tipo de auditorías? ¿Cuál es el nivel de compromiso que se puede exigir a estas empresas? ¿Creeis que estas empresas deberían responder de algún modo por los resultados de dichas auditorías, desde un punto de vista jurídico? ¿Se debería exigir algún tipo de responsabilidad por la "firma" de una auditoría de LOPD, de un modo similar, por ejemplo, al de los arquitectos o ingenieros que firman un proyecto? Seguro que teneis muchas opiniones al respecto, tanto personales como jurídicas. ¿Os animais a contestar? Espero vuestros comentarios...

09 junio 2008

Publicada ISO/IEC 27005:2008

La semana pasada se publicó la norma ISO/IEC 27005:2008, bajo el título Information technology - Security techniques - Information security risk management. Como dice su nombre, esta norma supone una guía para la gestión de riesgos de seguridad de la información, de acuerdo con los principios ya definidos en otras normas de la serie 27000. Sustituye (y actualiza) a las partes 3 y 4 de la norma ISO TR 13335 (Técnicas para la gestión de la seguridad IT y Selección de salvaguardas, respectivamente), y se convierte en la guía principal para el desarrollo de las actividades de análisis y tratamiento de riesgos en el contexto de un SGSI. Constituye, por tanto, una ampliación del apartado 4.2.1 de la norma ISO 27001, en el que se presenta el análisis de riesgos como la piedra angular de un SGSI, y supone una excelente ayuda para todo aquél que quiera profundizar en el desarrollo práctico de un proceso de gestión de riesgos de seguridad de la información.

21 mayo 2008

En quién confiar?

Poco a poco parece que se van calmando los ánimos después del bombazo informativo que supuso la noticia de que las claves criptográficas SSL de debian eran vulnerables. Después de que nos contaran la noticia y de que nos aclarasen algunas dudas al respecto, probablemente todos habremos actualizado ya nuestras claves y respiraremos tranquilos tras comprobar que nadie ha utilizado la vulnerabilidad para hacerse con nuestros sistemas.



Y ahora, cuando ya ha pasado la ola, es cuando algunos pueden empezar a notar la resaca. Debian era una distribución reconocida, de prestigio. ¿Sigue siéndolo después de este incidente? ¿Se puede seguir confiando en debian? ¿Existen alternativas más confiables? Es posible que este tipo de preguntas le hayan surgido a más de uno (de hecho, en los comentarios de esta versión de la noticia tenemos un buen ejemplo).



Mi punto de vista es que este hecho, o cualquier otro de caracter similar, no debería suponer prácticamente ningún cambio en la opinión que teníamos de un determinado producto software. Que aparezca una vulnerabilidad crítica no es algo excepcional, y que sea explotable remotamente tampoco es tan raro. Ni más ni menos de lo que lo era antes. La probabilidad de ocurrencia existe, no sólo en debian sino en cualquier producto software, y que haya ocurrido una vez no cambia nada. Cualquier código tiene fallos, independientemente de que estén o no publicados. La probabilidad de que existan fallos de esta gravedad depende principalmente del propio producto, de su complejidad, tamaño, características y proceso de "fabricación". Que se publiquen tiene tanto de negativo como de positivo, pero no afecta a la "seguridad" del propio producto, sino a la probabilidad de que se intente explotar.



¿En conclusión? Que si queremos valorar la seguridad de debian, o de cualquier otra cosa, nos olvidemos del incidente de moda. Era tan probable que se incendiase un rascacielos antes de que se quemara el Windsor como después. No debemos dejarnos llevar por nuestra percepción del riesgo. Si hasta el incidente habíamos confiado en ese producto, sería por algo, no? Habrá que pensar en ese motivo, y analizar si sigue siendo válido. Y ojo, que la estadística suele jugar malas pasadas. Que no haya salido un 6 en ninguna de las tiradas de dados que hemos hecho no quiere decir que en la siguiente no pueda salir, ni tampoco que salga una de cada seis veces...

14 mayo 2008

Riesgos del teletrabajo

Desde que leí esta noticia sobre los riesgos de seguridad del teletrabajo para las empresas he estado prestando más atención a las personas de mi entorno, con el fin de descubrir hasta qué punto eran ciertas a mi alrededor las afirmaciones que se hacen en el artículo. Y creo que puedo estar satisfecho de poder decir que mis propias conclusiones no son tan negativas como las del artículo.

Para empezar creo que existe una gran diferencia entre el teletrabajador en casa y el desplazado. El primero, el que se lleva a casa el portátil, normalmente suele limitarse a realizar el mismo uso que en la oficina. Para el resto de actividades ya tiene, en la mayoría de los casos, un equipo propio, tan personalizado y a su gusto que difícilmente prefiere seguir utilizando el equipo corporativo para otras actividades fuera de las laborales. Un caso distinto suele ser el de los teletrabajadores desplazados, que sí pueden utilizar durante dichos desplazamientos ese equipo como sustituto del personal. En esos casos el uso "no profesional" del equipo se incrementa, evidentemente, pero por lo general suele ser un uso "comedido". Vamos, que en esos casos se suele navegar mucho más por webs de noticias y viajes que por páginas pornográficas. Y en general no suele haber tráfico P2P, al menos en la mayor parte de los casos que conozco, sobre todo porque los usuarios no tienen este tipo de programas instalados ni pueden instalarlos.

Otro de los casos que mi pequeño "estudio" tampoco ha corroborado es el relativo al uso de esos equipos por parte de otras personas. Sobre todo por el principio anterior: los que se lo llevan a casa ya suelen tener un equipo propio de uso familiar, y los desplazados suelen tener cada uno su propio equipo y generalmente pocas ocasiones para estar con alguien que no tenga y quiera usarlo libremente.

Lo que sí se suele dar más a menudo es la utilización de redes de acceso a Internet cuyas garantías de seguridad generalmente no se conocen o se pasan por alto. Es más habitual de lo que a mí me gustaría las conexiones a redes inalámbricas sin cifrar o el acceso a internet a través de redes que no cuentan con un simple firewall. Y la verdad es que, frente a esto, poco se puede hacer cuando la frase más habitual es que era "la única red disponible" para acceder a Internet. Probablemente la solución pase por que la propia organización proporcione una vía segura de acceso móvil a Internet, vía modem 3G, por ejemplo, pero si la propia organización no pone medios alternativos, la posibilidad de que estos hechos se repitan parece bastante alta...

Y por último, tampoco he detectado una mayor tasa de apertura de correos electrónicos desconocidos o sospechosos en el caso del teletrabajo que en la propia oficina. La política de seguridad que tenga establecida la compañía de turno, y sobre todo el grado de formación y concienciación de los usuarios al respecto son claves para que esto se produzca, pero en general no he identificado diferencias en estos aspectos entre los teletrabajadores y el resto.

En conclusión, sí que es cierto que el teletrabajo introduce nuevos riesgos en las compañías, pero también es evidente que introduce importantes beneficios si se articula de manera adecuada. Y con unos buenos programas de formación y el establecimiento de las medidas técnicas apropiadas creo que es posible conseguir un entorno de trabajo en el que los niveles de seguridad que se establezcan puedan ser totalmente equivalentes a los dispuestos en las sedes de la organización. Eso siempre que no dejemos de gestionar dicha seguridad. ¿Qué tal un SGSI para tenerlo bien atado? ;-)