22 diciembre 2006

Feliz Navidad y Próspero 2007!

Antes de irme de vacaciones, quería desear a todos los visitantes del blog una feliz navidad y un próspero año nuevo. Son fechas en las que, además de juntarnos con la familia, solemos aprovechar para hacer balance de los momentos vividos durante el año y, sobre todo, para plantear los propósitos del año venidero. Aunque sepamos que no vamos a cumplirlos! Lo bonito de estas fechas es que, por una vez, todos soñamos con un futuro mejor y, aunque sea por un instante, nos parece que realmente podemos conseguirlo. Yo sólo quiero animar a todo el mundo a que no olvide estos sueños, a que realmente trate de que se cumplan. Porque aunque no logremos alcanzar las metas fijadas, un pequeño paso en el camino soñado realmente merecerá la pena. Y en navidad, todo parece más fácil...

Feliz navidad a todos, y hasta el año que viene.

Zorionak, eta urte berri on.

Nos vemos,

Joseba

19 diciembre 2006

Gestión de la Continuidad de Negocio

El pasado 4 de Diciembre se presentó oficialmente en Londres la norma BS 25999-1:2006. Esta norma recoge los esfuerzos de BSI por desarrollar un código de buenas prácticas en materia de Gestión de la Continuidad de Negocio (BCM, Business Continuity Management).

Esta norma viene a dar respuesta a las crecientes necesidades del mercado de contar con una guía válida para este tipo de actividades, puesto que ni la SS507:2004 (estándar de Singapur para los proveedores de servicios de BC/DR) ni la guía británica PAS 56:2003 (también editada por BSI) cubrían adecuadamente las necesidades corporativas actuales. La norma, que durante algún tiempo se especuló que podría publicarse como norma ISO bajo el número 27006, cubre todos los aspectos relacionados con las mejores prácticas de la industria en materia de gestión de la continuidad a nivel global, y va desde el propio sistema de gestión a nivel de gobierno corporativo hasta los requisitos de negocio asociados a los sistemas de información, entre otros muchos aspectos.

En esta línea, se espera que para mediados de 2007 se publique la parte 2 de la norma, en la que ya se especificarán los requisitos que debe tener un Sistema de Gestión de la Continuidad del Negocio, y por lo tanto será certificable. ¿Cuánto tardarán estas normas en llegar a ser normas ISO? En realidad nadie lo sabe, pero dados los antecedentes de BSI y las exigencias del mercado en este tipo de iniciativas, es probable que los plazos sean realmente breves, si no se interponen otro tipo de intereses "colaterales".

Problemas de confianza

Estamos muy habituados a que el principal motivo por el que se hable de la seguridad sean los "ataques" externos. Cada día aparecen nuevos virus, cientos de e-mails de spam y phising inundan los buzones de correo, se difunden nuevos exploits, y cientos de crackers intentan acceder de forma ilegítima a servicios webs a lo largo de todo el ciberespacio. Y sin embargo, cada día las empresas ignoran más a menudo este tipo de amenazas. Por qué? Sencillamente, porque el mayor riesgo está en el interior.

Tal y como señalaba Diario TI hace unos días en esta noticia, el mayor riesgo percibido por las organizaciones proviene del interior. Sencillamente, los directivos no confían en sus propias organizaciones, y ponen en duda la capacidad de mantener la confidencialidad tanto a nivel interno como de cara a sus clientes y colaboradores. Evidentemente, esto supone un grave problema en términos de confianza y credibilidad de la propia compañía, dada la repercusión que puede tener este hecho a nivel de negocio.

El propio artículo identifica algunos de los elementos asociados a esta falta de confianza, como son:
  • No se definen roles y responsabilidades encaminados a garantizar la confianza de clientes y colaboradores.
  • Se aprecia una falta de formación de los directivos en este ámbito.
  • No existe una visión conjunta de los elementos que favorecen esta confianza.
  • No se dedican recursos de forma adecuada para logran un aumento de dicha confianza.

Evidentemente, este panorama no es nuevo, y probablemente todos conoceremos ejemplos concretos en los que se pueden aplicar estos y otros criterios. Desde mi punto de vista, este es uno de los principales motivos por los que los SGSIs están teniendo un auge tan importante: las empresas buscan algún salvavidas al que aferrarse, que les permita librarse de la sensación de inseguridad que se cierne sobre ellas. Y resulta que la ISO 27001, entre otros aspectos, resulve todos los citados anteriormente...

12 diciembre 2006

Introducción a la continuidad de negocio

Hoy quiero destacar un artículo publicado hace ya algún tiempo por Redes&Telecom. En él, varios representantes de diversas empresas del sector, encuadrados en distintos campos (fabricantes, consultores, integradores, ...) revisan la evolución que están sufriendo las empresas desde el punto de vista de la continuidad.

El artículo, dividido en cuatro secciones (1 - 2 - 3 - 4), explica la transición que se está llevando a cabo en el mundo empresarial actual desde el backup hacia la continuidad de negocio. El artículo comienza con una breve exposición de algunos motivos de dicho cambio, y continúa con una breve exposición de los servicios que las empresas están empezando a ofrecer para dar respuesta a estas necesidades. En su tercer apartado profundiza en las características básicas que definen los requisitos para desarrollar un completo Plan de Continuidad de Negocio, y en su último apartado se presentan distintas soluciones de cada uno de estos fabricantes de acuerdo con dichas necesidades.

En definitiva, es un artículo que probablemente no aporte nada nuevo a quienes ya están metidos de lleno en el mundo de la continuidad de negocio, pero que supone una perfecta introducción a todos los profanos en la materia que quieran informarse, en pocas líneas, sobre cómo se mueve este mundillo y cuál es el estado del arte en este campo.

11 diciembre 2006

El secreto de los mejores

Ya que hoy estoy de homenaje a Antonio Valle, no quiero dejar de destacar otro post publicado por él que, si bien ha tenido mucho menor impacto que el señalado anteriormente, me parece muy revelador. Antonio reflexiona sobre un estudio que analiza los elementos que diferencian a las buenas organizaciones en gestión TIC de las no tan buenas. La conclusión no puede ser más clara: los mejores tienen dos secretos (cito textualmente):
  • Existe una política para evitar la realización de cambios no autorizados
  • Se han definido y comunicado claramente las consecuencias para aquellos que realicen cambios no autorizados de forma voluntaria

Así de sencillo. Una estricta gestión de cambios, tanto a nivel de definición como de cumplimiento. Que cómo se consigue? Con disciplina, según el autor. Que no tiene por qué ser lo mismo que con régimen disciplinario. Convencer es preferible a vencer, y más en estos temas.

Y qué deben hacer las organizaciones que únicamente aspiran a mejorar su gestión TIC? Pues según parece, una buena idea podría ser la de comenzar por implantar un proceso de gestión de cambios...

Carencias de ITIL

Al igual que otros muchos blogs, no puedo sino hacer mención al fantástico post publicado por Antonio Valle en su blog. En él detalla algunos ámbitos en los que la archiconocida ITIL presenta carencias. Los aspectos que señala son, resumiendo, los siguientes:
  1. ITIL no tiene un modelo de madurez.
  2. Las métricas que propone son pobres y obsoletas.
  3. No contempla la gestión de requerimientos.
  4. No contempla el proceso de operaciones.
  5. La seguridad sufre un tratamiento muy deficiente.
  6. No contempla el ciclo de vida de los servicios.
  7. No contempla la gestión de proveedores.
  8. No integra desarrollo y sistemas.
  9. No se contemplan adecuadamente los pasos a producción.
  10. No presenta ningún programa de gestión de proyectos propio.
  11. No llega a muchos aspectos relativos a la gestión de personas.
  12. Prácticamente no habla de planes estratégicos de IT.
  13. No contempla la gestión de riesgos.
  14. No habla de la finalización del servicio.
  15. No presenta guías ni ejemplos de implantación.

En caso de que alguien quiera profundizar un poco más, le remito al post inicial. Creo que el autor se merece que este post sea consultado in-situ en su blog.

Por lo demás, sólo quiero destacar dos aspectos. El primero, que no hay que tirarse de los pelos, ya que estas carencias son bastante conocidas y, en mayor o menor medida, resueltas en otras metodologías, como bien refleja el post original. Y el segundo, que no sólo los elementos señalados, sino también muchos otros, son comunes a otros sistemas de gestión como los SGSIs o los BCMS (Sistemas de Gestión de la Continuidad del Negocio). Por lo tanto, y hasta la aparición de un buen sistema de gestión integrado que recoja de forma unificada todos estos requerimientos dispersos, la adopción de metodologías complementarias a ITIL ya permite, a muchas organizaciones, suplir las deficiencias que aquí se presentan.

07 diciembre 2006

Certificados ISO 27001 en España

Como lo prometido es deuda, hoy intentaré aclarar el "barullo" que hay en torno a los certificados ISO 27001:2005 en España. Y creo que lo más fácil es empezar por la parte de arriba, es decir, por las entidades de acreditación.

A día de hoy, todavía no se ha publicado una norma específica que permita acreditar los esquemas de certificación de ISO 27001. Dicha norma será la ISO 27006, y se espera su publicación para principios (o mediados) del año que viene. En la práctica, esto supone que a día de hoy no hay una norma internacional que permita a las entidades de acreditación (ENAC, en este caso) acreditar certificados bajo ISO 27001. Sin embargo, la mitad de los certificados ISO 27001 expedidos en España llevar acreditación UKAS. Por qué UKAS sí que ha sido capaz de acreditar certificados ISO27001?

UKAS ha utilizado una adaptación de la EN45012, la norma para acreditar los esquemas de certificación de ISO 9001, para acreditar las certificaciones de BS7799-2 en el pasado y las de ISO 27001 en la actualidad. Esta misma norma modificada ha sido adoptada por otras entidades de acreditación, tanto en Europa como en Asia, pero ENAC no se sumó al acuerdo. Probablemente, esto se debiera a que esta norma (EN45012 adaptada para SGSIs) fue impulsada por el ISMS International User Group (ISMS IUG) para poder acreditar las certificaciones bajo BS7799-2, mientras que en España se trabajaba en su versión nacional alternativa, la UNE 71502.

El resultado final es que, por el motivo que sea, ENAC no ha suscrito el MLA que permite acreditar SGSIs bajo dicha norma. Y como ENAC no ha desarrollado ninguna alternativa, y la ISO 27006 todavía no está publicada, el caso es que ENAC no dispone, por el momento, de ningún esquema de acreditación que permita acreditar certificados de SGSIs, ni bajo ISO 27001 ni bajo UNE 71502.

Por lo tanto, si una entidad de certificación quiere que sus certificados de ISO 27001 estén acreditados, a día de hoy tendrá que acreditarlos contra una entidad extranjera. Estas entidades tienen, como aval adicional y elemento de marketing, el respaldo del ISMS IUG, y aparecen listadas en la web que mantiene este organismo. Este mismo organismo también es el responsable de mantener actualizada la lista de SGSIs certificados y acreditados a nivel internacional, y que puede consultarse en esta web.

Y qué ocurre con los certificados sin acreditación? Pues que la credibilidad que tienen es, por el momento, la que la sociedad les otorgue a las entidades que los expiden. Sin embargo, esto puede cambiar, ya que hay entidades de certificación, como Applus y AENOR, que están en proceso de acreditación por parte de ENAC.

Para poder acreditar un esquema de certificación se necesita tener una serie de certificados emitidos, ya que son precisamente esas auditorías de certificación las que la entidad de acreditación tiene que examinar y validar. Y cuando la acreditación sea positiva, los certificados cuyas auditorías se han evaluado para otorgar esa acreditación pasan a estar automáticamente acreditados. Por tanto, que en la actualidad existan certificados sin acreditar no quiere decir que ese mismo certificado no vaya a poder estar acreditado en un futuro.

Resumiendo: A día de hoy hay en España varios certificados ISO 27001 (y también alguno BS7799-2:2002 expedido por BSI, DQS GMBH y LSTI SAS RCS) con acreditación internacionalmente reconocida, expedidos por BSI y LRQA, que pueden consultarse en http://www.iso27001certificates.com. También hay otros certificados, expedidos principalmente por Applus+ y AENOR, que actualmente no están acreditados pero están en proceso de hacerlo (ENAC está utilizando el draft de la ISO 27006 para acelerar el proceso). Y por último, seguro que existen certificados ISO 27001 sin acreditación y que por el momento no tienen visos de tenerla.

05 diciembre 2006

Certificando al certificador

En muchas empresas, el tema de las certificaciones no lo tienen muy claro. Normalmente conocen los "sellos" que tienen y que quieren, pero normalmente no conocen las implicaciones que tiene que sea una u otra entidad quien te otorgue esa certificación.

Como todos sabemos, una entidad de certificación lleva a cabo una auditoría a la empresa en cuestión y, si la supera, le otorga el certificado correspondiente. Cualquiera puede otorgar, en principio, un certificado. Lo importante es la validez que ese certificado tenga. Y eso depende, sencillamente, de la credibilidad que tenga la organización que lo ha expedido. Yo puedo montarme mi empresa CertificadoresUnidos, S.L. y certificar sistemas de gestión de la calidad bajo la norma ISO9001, por ejemplo. Pero... qué credibilidad tienen esos certificados? Sencillamente, la que me quieran dar. Soy conocido? Soy respetable? Qué nivel de credibilidad tiene que darle la sociedad a ese certificado que yo he expedido? El que tenga mi nombre.

Es probable que yo quiera darle una mayor credibilidad a mis certificados. Cómo lo puedo lograr? Pues... intentando que alguien me certifique a mí como entidad certificadora. A esto se le llama acreditación. De forma similar al caso inicial, una entidad de acreditación tendrá que llevar a cabo una auditoría a mi empresa, CertificadoresUnidos, S.L. y, si la supero, acreditarme como certificador de sistemas de gestión de la calidad bajo ISO9001. Lo que van a auditar es mi esquema de certificación, es decir, si yo realizo bien las auditorías, si tengo capacitación suficiente, si mis registros y logs son correctos, etc. Y me acreditarán para certificar SGCs bajo ISO9001 (y ninguna otra cosa más). Si quisiera certificar SGSIs, por ejemplo, tendría que obtener una nueva acreditación, que en este caso correspondería a mi esquema de certificación para SGSIs bajo la norma ISO 27001.

Ahora mis certificados tienen la misma validez que cualquier certificado de ISO 9001 que haya emitido otra empresa acreditada por la misma entidad de acreditación. En qué ámbito son válidos? En principio, en el ámbito en el que actúe la entidad de acreditación, que es el nacional. En nuestro caso, la entidad de acreditación es ENAC, y por tanto la garantía del certificado abarcaría a todo el territorio nacional. Fuera de él, la credibilidad del certificado que yo he emitido dependerá de la credibilidad que tenga ENAC como entidad acreditadora.

Pero todavía es posible llegar más allá. Para que el certificado ISO 9001 que CertificadoresUnidos, S.L. ha emitido tenga validez internacional, ENAC debe establecer acuerdos multilaterales de reconocimiento (MLAs) en foros de carácter internacional (a nivel de europa o a nivel mundial). Estos acuerdos, que se verifican mediante la realización de auditorías cruzadas entre entidades de acreditación, homologan las acreditaciones que en relación a una misma norma establecen distintas entidades de acreditación. En pocas palabras, la credibilidad de ese certificado pasa a ser internacionalmente reconocida (al nivel que alcance el MLA).

Esta explicación, que espero que haya sido clara, es aplicable para cualquier tipo de certificación, no sólo para los sistemas de gestión. Sin embargo, probablemente sea necesario explicar en qué situación se encuentran los certificados de ISO 27001 en nuestro país. Aunque lo haré en unos días en un post independiente, que creo que el tema da lo suficiente de sí.

04 diciembre 2006

Check-lists de seguridad técnica

Hoy quiero hacer referencia al repositorio de guías de seguridad y checklists que publica el NIST. Para muchos profesionales de la seguridad probablemente esta referencia pueda ser de gran ayuda a la hora de abordar aspectos de seguridad técnica a nivel de configuración de seguridad y bastionado en ámbitos tan concretos como las bases de datos, los sistemas operativos o los servidores web. Este repositorio recopila distintas guías técnicas de configuración y testeo de una gran cantidad de aplicaciones y plataformas, se actualiza periódicamente y cuenta con la garantía del NIST (National Institute of Standards and Technology), una entidad dependiente del departamento de comercio de EE.UU. con una contrastada calidad en sus trabajos dentro del campo de la seguridad de la información. Para todo aquél que todavía no conozca sus trabajos, recomiendo una visita a este link, donde se referencian todas las guías (gratuitas) que este organismo ha publicado en materia de seguridad. Que tengais una buena lectura! :-)

30 noviembre 2006

Delimitando responsabilidades

Normalmente, una de las principales dificultades a la hora de implementar cualquier tipo de gestión de la seguridad suele ser la delimitación de responsabilidades. A todos los niveles, aunque con distintas implicaciones.

A nivel interno, la disputa suele venir dada por la disociación entre responsabilidad y ejecución. Los jefes tratan de delegar cada vez más tareas en sus subordinados, y mientras los subordinados intentan que sean sus jefes los que asuman la responsabilidad de las decisiones. ¿Cuándo termina la disputa? En la práctica, nunca. Como mal menor, un buen reparto de funciones, una buena gestión de perfiles corporativos y un sólido procedimiento de autorizaciones y aceptaciones puede ayudar a suavizar bastante las tiranteces.

A nivel externo, la situación no es tan delicada, aunque también tiene su miga. Aquí entran en juego las relaciones entre clientes y proveedores, y juega un papel decisivo la cadena de negocio. La solución pasa por el desarrollo de SLAs, pero entendidos en toda su magnitud. Hoy en día todos escuchamos ese término para referirse a indicadores y objetivos a cumplir... y nos quedamos contentos. Pero un SLA no sólo tiene que definir el compromiso, también tiene que contemplar cómo se resuelten las situaciones en las que no se alcanzan los objetivos, las condiciones que permiten su incumplimiento, los procedimientos de resolución de conflictos... Es decir, que un SLA tiene que ser un ACUERDO entre ambas partes, de forma que ate a ambos por igual. No me sirve que mi proveedor me prometa el 99% de disponibilidad del servicio, si una indisponibilidad superior al 2% me hace perder millones y su respuesta es que ese mes no pague la cuota correspondiente.

Y no nos olvidemos que a nivel de "sociedad" también existen responsabilidades. En este caso, son las leyes las que las regulan, y la forma de afrontarlas es sencilla. Tenemos la obligación de cumplirlas. El problema es... ¿Cómo de bien las cumplo? ¿Cumplirlas hoy me garantiza cumplirlas mañana? Y desde el otro lado... ¿Qué responsabilidades tiene la sociedad con la empresa? ¿Y con los individuos? Es un tema complejo, pero que no debemos olvidar. Sobre todo, porque el impacto que puede tener en nuestro negocio puede ser crucial. Y si no, basta con mirar a AllOfMP3 o a la misma asociación de internautas. Y hay que estar atentos, porque en este campo, las responsabilidades y su delimitación pueden cambiar, tal y como expone Enrique Dans en uno de sus artículos.

En definitiva, la delimitación de responsabilidades es uno de los aspectos cruciales a la hora de gestionar la seguridad. Y no sólo vale trabajar en ello a todos los niveles (personal propio, clientes, proveedores y sociedad), sino que hay que mantener actualizada continuamente dicha definición, porque como es sabido, todo cambia. Menos mal que los SGSIs ya incorporan el ciclo PDCA y esta obligación de seguimiento continuo...

28 noviembre 2006

El negocio se abre camino

En uno de mis primeros post en este blog, hablaba sobre los sistemas de consolidación de logs y sobre el potencial que podían llegar a tener. Hoy retomo este tema con la satisfacción de ver que mis pronósticos no iban muy desencaminados.

Como exponía en su momento, los sistemas de consolidación de logs tienen un gran potencial. Y aunque hasta el momento se han vendido como motores de correlación de eventos de seguridad, hoy retomo el tema con un ejemplo en el que, como dice el título, el negocio se ha abierto camino.

El caso es sencillo. Una organización que dispone de una herramienta de consolidación de logs. Inicialmente, en ella se replicaban los logs de firewalls, antivirus e IDSs. Vamos, el caso clásico. Pero, desde el punto de vista de la seguridad, a alguien se le ocurrió que también podían consolidar en esa máquina los logs de otros sistemas en los que la seguridad era importante, como el servidor web. O mejor dicho, el cluster de servidores web. Así, se podría llegar a ver el rastro de un ataque que consiguiera llegar hasta el servidor. Así que introdujeron este servidor en el sistema de consolidación de logs. Pero como la visión que ofrecía era incompleta, decidieron introducir también el resto de las capas que daban el servicio web, es decir, el motor de aplicaciones y la base de datos.

Pero resulta que un buen día, y aunque no se había detectado ningún ataque, la aplicación web tuvo un fallo importante. Algo andaba mal... y no estaba muy claro por qué. Un montón de gente estudiando el problema... y nada. Hasta que a alguien se le ocurrió ponerse a revisar logs. Una tarea ardua, porque cada sistema tenía los suyos. Pero... Un momento! Si en el sistema de consolidación de logs están todos juntos! ¿Por qué no intentamos utilizarlo?

Dicho y hecho. En cinco minutos disponían de todos los logs que necesitaban, y en otros diez habían dado con la solución. Eureka! No habían localizado un ataque, pero habían traducido todos los datos que tenían los logs en información útil para identificar el fallo en la aplicación. ¿Por qué no aprender la lección? En unos meses, todos los sistemas críticos estaban integrados en el sistema de consolidación de logs. Y también los entornos de desarrollo y pre-producción.

¿Cuál es la situación actual? La mayor parte de los usuarios de ese sistema son usuarios del área de desarrollo, ya que les permite realizar de forma sencilla y rápida seguimientos y análisis del funcionamiento de sistemas distribuídos y dispersos, que en otro caso serían tediosos o inasumibles. ¿Cuál es la lección aprendida? Que a la hora de la verdad, seguridad y negocio no son elementos tan distantes e irreconciliables como puede parecer. Sencillamente, hay que aprender a transformar los sistemas y recursos "de seguridad" en sistemas y recursos "de negocio". Tener la mente abierta...

27 noviembre 2006

El fracaso de la calidad

La mayor parte de nosotros habremos oído expresiones del tipo de "no entiendo cómo esta empresa puede estar certificada en calidad" o "la calidad es un cuento chino". ¿A qué se deben? ¿Cómo puede ser que muchas empresas gasten dinero en algo con tan poco reconocimiento, incluso entre sus propios empelados, como una certificación ISO 9001?

El problema radica, sencillamente, en que una ISO 9001 certifica un Sistema de Gestión (de la Calidad), y no la calidad de un producto (o servicio). ¿Por qué? Porque es una norma que está desarrollada desde un punto de vista muy estructurado, en el que originalmente se desarrolla el producto/servicio, posteriormente se pasa a asegurar su calidad (a nivel de resultado final), y por último se llega a la fase de gestionar dicha calidad a nivel de proceso, para poder garantizarla. Por lo tanto, si certificamos el proceso de gestión de la calidad, damos por hecho que tanto producto como calidad final, como requisitos previos, están garantizados. Es decir, que certificamos el tejado del edificio porque damos por hecho que tanto los cimientos como las paredes están construidos lo suficientemente bien como para haber llegado a construir el tejado, y por lo tanto una certificación del tejado conlleva una certificación del resto de la casa.

Sin embargo, en nuestra cultura mediterránea hay casos en los que este requisito previo no se cumple. Para bien o para mal, somos capaces de construir un tejado bonito y lustroso sobre cimientos inestables y paredes poco sólidas. Somos capaces de desarrollar un sistema de gestión, correctamente estructurado y autoconsistente, que sea en gran medida independiente de las actividades productivas. Y somos capaces de certificarlo, dedicando recursos específicos a mantener dicho sistema de gestión. Este es el gran error: dedicar recursos a limpiar y sacar brillo al sistema de gestión (puede hacerse continuamente o justo antes de las auditorías) en lugar de dedicarlos a reforzar las paredes y afianzar los cimientos, en lugar de integrar el sistema de gestión en (y no con) los procesos y productos/servicios que desarrollamos.

Cómo hemos llegado hasta aquí? Por una parte, gracias a nuestra cultura, no tan estructurada ni concienzuda como pueden ser la nórdica o la japonesa. Y por otra, alentados por la vorágine de "titulitis empresarial" en la que vivimos inmersos. Porque resulta que en muchos casos lo importante no es tener un buen sistema de gestión de la calidad, sino tener un certificado. Porque si conseguimos el certificado podemos acceder a una determinada subvención, a un determinado concurso o a un determinado cliente. Y una vez que hemos accedido, nuestro lustroso proceso de gestión de incidencias ya se preocupará de resolver las reclamaciones de los clientes. Pero mientras tanto, seguiremos sin ser capaces de utilizar el sistema de gestión de la calidad que hemos desarrollado para reducir la cantidad de productos/servicios defectuosos, y por consiguiente el número de reclamaciones de los clientes. Sencillamente, porque con las prisas de obtener el certificado, se nos olvidó que tenía que ser útil para el negocio. Aunque... pensándolo bien... No importa: ya tenemos El Certificado. No es lo que queríamos?

(Nota: el final es irónico. A ver si va a haber malos entendidos... :-) )

21 noviembre 2006

Costes de Seguridad

Hace unos días, Jorge Ortiz publicaba en su blog compartido un post muy interesante. En él plantea una postura crítica ante los análisis de riesgos, y afirma que no pueden ser utilizados para definir la estrategia de seguridad de una organización.

Esta visión, que comparto al 100%, es básica si queremos obtener una estrategia de seguridad alineada con el negocio. Un análisis de riesgos va a identificar cuáles son nuestras principales fortalezas y carencias en materia de seguridad, identificando nuestra situación de seguridad. Pero no va a decir nada acerca de hacia dónde queremos ir en materia de seguridad, que es precisamente el cometido de la estrategia de seguridad.

Pongamos un ejemplo. Una empresa de venta on-line de productos y una empresa de mensajería identifican en sus respectivos análisis dos riesgos a tratar: un riesgo extremo derivado del insuficiente control de accesos en el servidor web y un riesgo alto debido a una capacidad insuficiente en la centralita telefónica. Si sólo tenemos en cuenta el análisis de riesgos, ambas empresas deberían tratar en primer lugar el riesgo asociado al servidor web. Sin embargo, si tenemos en cuenta el negocio, los objetivos de la empresa dirán que es más importante dirigir la estrategia de seguridad hacia la disponibilidad de los servicios de atención al cliente, y por tanto se primará el tratamiento del riesgo asociado a la capacidad de la centralita, aunque sea menor.

En el mismo post el autor afirma que la seguridad, desde el punto de vista de negocio, conlleva un gasto adicional (precisa recursos), y por tanto tiene que proporcionar un valor añadido para el cliente, de forma que se justifique ese incremento en el coste. Esta visión permite al autor una catalogación muy interesante de los costes de seguridad:
  • Costes de seguridad obligatorios: Aquellos en los que todas las empresas deben incurrir, debido a legislaciones, regulaciones, etc.
  • Costes estratégicos de seguridad: Aquellos derivados de la implementación de medidas de seguridad que aportan un valor añadido al negocio.
  • Costes de gestión de la seguridad: Aquellos costes provocados por la gestión de los riesgos, que se derivan de la implementación de medidas para reducir el riesgo por debajo del umbral aceptado.

Evidentemente, cualquier otro coste de seguridad que no esté contemplado entre estos debería ser eliminado. Y de todas formas, el objetivo a perseguir será la integración de el tercer grupo dentro del segundo, con el fin tanto de optimizar costes como de alinear al máximo las medidas de seguridad y el SGSI desarrollado con los objetivos del negocio. Una conclusión similar a la que yo mismo exponía ayer en este post. Vamos, que al final nos encontramos con resultados similares aunque el origen del análisis sea tan distinto. Si es que en estos temas de la seguridad, el sentido común es el mejor consejero...

20 noviembre 2006

Procesos seguros y SGSIs

Es muy habitual que la implantación de un SGSI se realice sobre uno o varios procesos, ya que es el tipo de alcance que definen las dos principales normas que los regulan (ISO27001 y UNE71502). Sin embargo, este es un hecho que en algunas implantaciones se suele obviar, sobre todo cuando pensamos en SGSIs de gran tamaño, y este hecho puede conducirnos a perder, en cierto modo, el sentido práctico de un SGSI.

Un SGSI es, obviamente, un sistema de gestión. Como tal, define una serie de parámetros que deben ser cumplidos, las políticas, una serie de manuales que guíen el modo concreto de cumplirlas, los procedimientos, y una sistemática de control que facilite la monitorización, revisión y optimización de todos y cada uno de los elementos desarrollados. En el caso de un SGSI, estos parámetros son parámetros de seguridad, y entorno a ella va a girar la articulación del sistema de gestión. Pero, por lo demás, un SGSI es un sistema de gestión como otro cualquiera.

¿Es esto cierto? Sí y no. En el párrafo anterior acabamos de cometer el error que citaba inicialmente: nos hemos olvidado de la orientación a procesos. Qué implica esto? Que un SGSI no es sólo un sistema de gestión, la Seguridad juega un papel propio. Además de definir la estructura de gestión, un SGSI tiene que definir los controles específicos que aplicamos para securizar los procesos cubiertos. Precisamente por éso las normas incluyen un listado de controles aplicables. Porque no nos podemos limitar a implementar los controles definidos dentro de la "estructura de gestión", sino que también tendremos que implementar todos aquellos que son necesarios para el negocio. Y estos son precisamente los que tendremos que aplicar de forma específica a cada proceso, una vez los hayamos analizado e identificado sus carencias y debilidades en materia de seguridad.


Resumiendo, la implantación de un SGSI realmente efectivo tendría dos partes:
  • Securizar los procesos cubiertos por el SGSI.
  • Desarrollar el sistema de gestión que permita mantener y optimizar el nivel de seguridad alcanzado en todos y cada uno de los procesos cubiertos.

Es evidente que no podemos olvidar ninguna de las dos partes si queremos que nuestro SGSI realmente funcione. Si olvidamos la primera, tendremos un sistema de gestión no alineado con el negocio, poco útil. Y si olvidamos la segunda, no seremos capaces de cumplir los objetivos de seguridad que precisa el negocio.

No quiero terminar sin resaltar un último aspecto. Como acabamos de ver, un SGSI tiene dos grandes componentes, de similar importancia. Por ello, cuando llevemos a cabo una implantación práctica de un SGSI tendremos que tener en cuenta tanto el estado de la organización en relación a ambos componentes como sus objetivos y necesidades frente a cada uno de ellos. Porque no es lo mismo implementar un SGSI en una organización con una fuerte cultura de gestión, que en otra con una importante andadura en materia de seguridad. Porque si no tenemos esto en cuenta, no seremos capaces ni de satisfacer las necesidades reales de la organización ni de hacer un uso eficiente y eficaz de recursos a la hora de acometer el proyecto. Que conste que estoy avisando... ;-)

16 noviembre 2006

Seguridad Vs Libertad

Uno de los dilemas éticos más habituales que se suele plantear a la hora de hablar de seguridad son las implicaciones que esta tiene en relación a la libertad. Todos podemos recordar la polémica que levantó la aprobación de la famosa "Patriot Act" en EEUU tras los atentados del 11-S, donde se recortaban las libertades de los ciudadanos para lograr una mayor seguridad anti-terrorista, pero existen multitud de ejemplos, en todos los entornos imaginables, en los que parece que estas palabras son antónimos irreconciliables. Pero... ¿Es esto del todo cierto?

Para empezar, una reflexión semántica. Si tratamos de identificar el antónimo de seguridad, probablemente se nos ocurra inseguridad, es decir, ausencia de seguridad. Si buscamos lo contrario a libertad... quizás nos resulte más difícil dar con el término óptimo. Yo me voy a quedar con restricción, como concepto representativo de ausencia de libertad. Ya sé que académicamente quizás no sea la mejor opción (puede que ni siquiera buena), pero me parece útil para analizar ambos conceptos. Y si no recuerdo mal la lógica que se estudiaba en el instituto (hoy estoy académico, primero clase de lengua castellana y ahora de filosofía), si ambos conceptos son contrarios, sus contrarios deberían ser equivalentes. ¿Se puede decir que seguridad = restricción, y que inseguridad = libertad?

La pregunta anterior creo que permite identificar mejor cuál es el problema. En realidad, en muchas ocasiones la seguridad se suele ejercer aplicando restricciones. Sin embargo, no es la única forma. Por tanto, no deberían ser tan irreconciliables. Si vamos a la segunda equivalencia, creo que está mucho más claro que ambos conceptos no tienen por qué ser contrarios. La inseguridad no garantiza en absoluto libertad, y la libertad no tiene por qué ser sinónimo de inseguridad.

Por otra parte, si vamos a la RAE, una de las definiciones que se dan para el término libertad es "Facultad que se disfruta en las naciones bien gobernadas de hacer y decir cuanto no se oponga a las leyes ni a las buenas costumbres". Es decir, que ya introduce restricciones en el propio concepto, derivadas del hecho de vivir en sociedad (Vaya! Todavía recuerdo algo del capítulo de la libertad del libro de filosofía, y todo aquello del homo homini lupus est!). Por tanto, quiere decir que ya hay ciertas restricciones (y nada asegura que no puedan ser restricciones "de seguridad") aceptables dentro del concepto de libertad, relativas a leyes y buenas costumbres. Vamos, que en algunos casos, seguridad y libertad pueden ser compatibles.

Vayamos un poco más allá. La seguridad tiene tres dimensiones básicas, como son la integridad, la disponibilidad y la confidencialidad. Y precisamente este es uno de los elementos que más se esgrimen a la hora de hablar de libertad, cuando la confidencialidad se entiende como "privacidad" del individuo. De hecho, hay leyes que, tratando de garantizar la libertad individual, luchan por esta privacidad. Entonces, resulta que hay casos en los que libertad y seguridad no sólo no son contrarios, sino que parecen estar en el mismo lado (la seguridad como parte de la libertad). Entonces, cuál es el problema?

Desde mi punto de vista, el problema de fondo no es la antítesis entre libertad y seguridad, sino el conflicto entre libertad grupal versus libertad individual. La seguridad forma parte de ambas libertades, y el problema real está en el equilibrio entre ellas. Qué es más importante, garantizar la seguridad del trabajador en términos de privacidad (confidencialidad) de sus comunicaciones o garantizar la seguridad de la empresa frente a fugas de información? Qué se prioriza, la seguridad del estado frente a ataques terroristas, o la integridad del individuo que es cacheado en un aeropuerto? Realmente, la seguridad está presente en ambos lados de la balanza, y el problema real es que las restricciones que se aplican para desarrollar una u otra seguridad son contrarias entre sí.

Para terminar, sólo quiero añadir que este post es sólo un sencillo ejemplo de que hay situaciones en las que el concepto de seguridad se utiliza de forma parcial, como excusa para justificar unas restricciones que, en realidad, también podrían ser ejercidas con los mismos argumentos en sentido contrario. Por tanto, espero que cualquier persona que lea estas líneas intente ir ver más allá y trate de diferenciar las verdaderas motivaciones que se esconden tras esos argumentos, sea cual sea el ámbito en el que se efectúen, y cuáles de ellos son realmente motivados por la seguridad.

15 noviembre 2006

Auditoría interna

Hoy solo quiero destacar el magnífico post publicado por Jose Manuel Fernández en su blog, titulado Auditoría interna de un SGSI según ISO 27001. En él, el autor analiza paso por paso los requisitos que la citada norma presenta en su apartado 6, aclarando las implicaciones de cada frase en relación a la auditoría interna de un SGSI y profundizando en sus consecuencias. En un segundo apartado, Jose M. Fdez. aclara la metodología a seguir para llevar a cabo una auditoría interna del SGSI que cumpla con todos los requisitos que ha desgranado previamente, y aprovecha para aclarar de forma clara y sencilla las diferencias entre una auditoría clásica de sistemas y una de un SGSI. Un artículo realmente recomendable, tanto por su profundidad como por su claridad. Recomiendo a todo aquél que lea este post que reserve algo de tiempo (es un post extenso) para leerlo y reflexionarlo, porque realmente no tiene desperdicio. Y aprovecho para felicitar al autor por el artículo publicado. Zorionak!

13 noviembre 2006

Más allá de la investigación del personal

La investigación previa del personal es un tema recurrente a la hora de hablar de seguridad gestionada. Existen multitud de artículos y comentarios al respecto, aunque voy a rescatar este, de Jose Manuel Fernández, por sus referencias normativas, y este otro, de Javier Cao, por su originalidad. Sin embargo, en este post no voy a hablar específicamente de la investigación del personal a raíz de una contratación, sino que voy a ir un poco más allá.

Hoy ha salido publicada en diversos medios esta noticia, que me parece bastante preocupante. Un tribunal ha anulado un curso de formación de examinadores de la Dirección General de Tráfico, y como consecuencia todos los permisos de conducción "otorgados" por los examinadores titulados en ese curso pueden ser ilegales. Si dejamos a un lado todas las implicaciones políticas, administrativas y judiciales de esta sentencia, nos encontramos con que entre 60000 y 70000 carnés pueden ser anulados, con el consiguiente "cabreo" (justificado, sin duda) de los afectados.

En relación a este punto, la pregunta que quiero plantear es: ¿Podría haber servido de algo un procedimiento de investigación previa del personal? Vamos a verlo.

Por parte de los afectados, parece que poco se puede hacer. Por lo que yo recuerdo, es el profesor de la autoescuela el que te lleva al lugar de partida para el examen, y una vez que el examinador se sube al coche y te da la orden, tú comienzas tus 20 minutos de calvario (examen). En las condiciones de nerviosismo en las que se suelen hacer estos examenes, no creo que a ningún alumno se le ocurra exigir el título al examinador (no vaya a ser que se moleste, y se convierta en un factor subjetivo en su contra). Y aunque lo hiciese, no serviría de mucho, puesto que hasta el momento de la sentencia, los citados examinadores estaban en posesión de una titulación válida. El examinador superaría las posibilidades de investigación que pueda llevar a cabo el alumno.

A partir de este punto, desconozco cuál es el proceso de selección y asignación de examinadores que se lleva a cabo. De todas formas, ya sean las autoescuelas, la delegación de tráfico o cualquier otra organización la que desarrolla esta tarea, la única información que podría haber obtenido es que la licencia del examinador está expedida por la DGT (en vez de estarlo por los Instructores de Seguridad Vial, según el artículo) y, como mucho, que existe un procedimiento contencioso-administrativo abierto contra el curso en el que dicho examinador ha obtenido la acreditación. ¿Serían estos datos suficientes como para "vetar", en caso de que sea posible jurídicamente, la participación de dicho examinador? Legalmente es un aspecto complejo, y lo más probable es que cualquiera que se plantease la opción acabase desechándola, dada la poca consistencia de la duda y los problemas que puede acarrear el posible veto.

Por lo tanto, estamos ante una situación en la que procedimientos aparentemente sólidos como la investigación previa del personal pierden consistencia si se sacan fuera de su ámbito de actuación más habitual, la empresa privada. ¿Qué conclusiones podemos extraer de este análisis? Desde mi punto de vista, varias. La primera, tener claro que el ámbito de actuación puede condicionar la aplicabilidad de las normativas, y por lo tanto que no podemos utilizar ninguna normativa ni estándar como verdad absoluta. La segunda, que en el ámbito de la sociedad, donde el cliente es el ciudadano y las empresas son las administraciones públicas, se aprecia una carencia en materia de seguridad de la información, y por tanto las administraciones deberán esforzarse en desarrollar normativas que corrijan este hecho (en relación a este tema, invito a releer este post anterior). Y la tercera, pero no menos importante, que estándares tan sólidos como la ISO 27001 siempre tendrán margen para ser completados y mejorados, y como bien señala la propia norma será necesario analizar la necesidad de incluir controles adicionales para resolver casuísticas cuyo ámbito, por ser demasiado específico o demasiado general, excedan al alcance de los controles propuestos por la norma.

09 noviembre 2006

Planes de Tratamiento de Riesgos

Aunque parezca llamativo, una de las principales dudas que suele existir a la hora de implementar un SGSI es cómo abordar el RTP (Plan de Tratamiento de Riesgos), una vez que disponemos del análisis de riesgos. El objetivo de este post es intentar aclarar cómo encajar esta tarea, tan común en la práctica, con los conceptos ya conocidos dentro del ámbito de la consultoría de seguridad.

Si recurrimos a la ISO27001, vemos cómo, si hemos seleccionado una estrategia de reducción de riesgos para todos aquellos que en el análisis superan el umbral aceptado, tenemos que seleccionar los controles más apropiados para reducir todos esos riesgos excesivos identificados. Para cada riesgo analizaremos la efectividad y coste de los controles aplicables, y seleccionaremos los más adecuados.

Una vez que disponemos del listado de controles a aplicar, tendremos que articularlos. Habrá que definir los proyectos de implementación correspondientes, especificando tareas, responsables, tiempos y recursos. Este plan de proyectos constituirá el RTP. Así de sencillo. El RTP no implica la utilización de un formato determinado, ni de un tipo de archivo concreto para su representación. Símplemente tiene que articular el plan de proyectos definido para reducir los niveles de riesgo identificados por debajo del umbral máximo determinado.

En una terminología más común, este RTP es sencillamente un Plan de Choque o Plan de Acción a Corto Plazo, que busca la reducción de los riesgos identificados como excesivos a través de medidas concretas de resolución de problemas específicos. Algo que ya se llevaba a cabo sin necesidad de un SGSI, pero que la ISO27001 obliga a realizar de forma estructurada, repetible y consistente.

De acuerdo a esta terminología "clásica", el Plan de Choque suele ir unido a un Plan Director de Seguridad o Plan de Seguridad a Medio/Largo Plazo, que complementa las medidas a corto plazo del Plan de Choque con otra serie de medidas más generales de "defensa en profundidad", que tratan de afianzar la seguridad y reforzar sus bases. Y resulta que este Plan Director de Seguridad no es otra cosa, dentro de un SGSI, que el plan de implementación del resto de los controles (técnicos, organizativos, operativos y contractuales) aplicables, que destaca y prioriza los controles más "importantes" y su acometida, pero que al fin y al cabo lo que define son la estrategias de gestión de la seguridad que la organización debe seguir a medio y largo plazo, articulado en formato "proyectos".

Y la conclusión de este post es, como no podía ser de otra forma, que la implantación de un SGSI en cualquier organización no es algo tan complejo como pueda parecer a priori, puesto que en la práctica son tareas que de un modo u otro ya se realizan en la mayor parte de las organizaciones. Y un SGSI, en el fondo, no es más que llevar a cabo esas tareas de una forma un poco más organizada.

07 noviembre 2006

Sistemas de Gestión Integrados

Un tema del que últimamente se está hablando bastante es el de los sistemas de gestión integrados, y más en concreto de la integración de los SGSIs en los sistemas de gestión corporativos. El objetivo de este post es señalar una serie de referencias de utilidad para todo aquél que quiera profundizar en estos temas.

La primera referencia que quiero citar es normativa, en concreto la norma UNE 66177:2005, como referencia a la integración de los sistemas de gestión de Calidad, Medio Ambiente y Seguridad Laboral (ISO 9001, ISO 14001 y OHSAS 18001). Me parece un gran trabajo desarrollado por parte de AENOR, que define a nivel práctico una interesante y útil metodología de integración de los distintos sistemas de gestión desarrollados o a desarrollar por la organización. Además, incluye unos anexos realmente interesantes, que complementan perfectamente el cuerpo de la norma y ayudan a una óptima comprensión de qué es un SGI. Se puede considerar un documento de referencia totalmente válido, y predecesor de los trabajos de integración de los SGSIs.

La segunda referencia que voy a citar es este artículo, a modo de ejemplo práctico de integración entre un sistema de gestión de calidad y otro de seguridad de la información. Presenta de forma sencilla y comprensible la integración de ambos sistemas, a través del desarrollo de un sistema de control interno basado en análisis de riesgos y oportunidades. Es un artículo sencillo, de fácil comprensión y que refleja claramente una estructura integrada de gestión de la seguridad a nivel corporativo, claramente reflejada en la figura 2 del citado documento.

La tercera referencia que quiero señalar es el Enterprise Risk Management Framework, un marco integrado de gestión de riesgos corporativos desarrollado en el informe COSO II por el equipo que forma el Committee of Sponsoring Organizations of the Treadway Commission. De nuevo se presenta un sistema de gestión integrado en el que encaja perfectamente un SGSI, basado en un sistema de control interno. Se podría considerar como una de las fuentes que han alimentado el trabajo anterior.

Y no me gustaría terminar sin una referencia a otro tipo de marcos de gestión como pueden ser los marcos de gestión de servicios IT. En concreto, Antonio Valle ha publicado recientemente en su blog una interesantísima reflexión acerca de las posibilidades de "extrapolación" de COBIT a otros entornos. Desde aquí quiero apoyar esa iniciativa, y animar a llevar a cabo una reflexión en torno a la posibilidad de uso de COBIT como referencia para el desarrollo de un sistema integrado de gestión global, en el que se integre tanto la gestión de los servicios IT como la gestión de la calidad o de la seguridad de la información supongan un pilar esencial. Al fin y al cabo, partir de una correcta de gestión de seguridad e IT para el desarrollo de un sistema de gestión integrado puede ser la clave para muchas empresas cada vez más abrumadas por la creciente dependencia de los sistemas IT...

31 octubre 2006

Empresas y código penal

Habitualmente, al hablar de legislación aplicable en el entorno empresarial nuestro pensamiento se suele centrar en leyes "tecnológicas" como la LOPD, la LSSI o la LPI. Sin embargo, en muchas ocasiones nos olvidamos de que las empresas también están sujetas a la ordenación jurídica "común", es decir, las leyes de aplicación general.

En relación a este tema, la web ISO27000.es publica, entre las presentaciones de la jornada "Nuevos escenarios en Seguridad de la Información", que tuvo lugar en Valencia el día 27 de Septiembre de 2006, una presentación de Manuel Badenes, de Equipo Marzo, que expone las implicaciones que tiene el Código Penal en el ámbito de la empresa, y sus relaciones con las leyes anteriormente citadas. Una presentación realmente interesante, que nos recuerda que el incumplimiento de ciertas normativas y políticas internas no sólo puede llevar acarreadas acciones disciplinarias , sino que, si estas normas reflejan determinadas directrices legales, dicho imcumplimiento puede llegar a acarrear penas de prisión. Mejor tenerlo en cuenta, verdad?

30 octubre 2006

Cumpliendo con la LOPD

En un post anterior, un visitante exponía sus dudas acerca de las dificultades reales a la hora de cumplir con los requisitos del Reglamento de la LOPD. Esta reflexión me ha llevado a analizar un poco más a fondo lo que suponen las distintas exigencias de la LOPD y el reglamento, y los motivos más habituales de su incumplimiento.

Las obligaciones de la Ley (parte administrativa) son sencillas de cumplir para las empresas. Identificar los ficheros, definir su nivel y propiedades, desarrollar las fórmulas legales (garantizar derechos de acceso, rectificación, cancelación y oposición) y dar de alta los ficheros no es una tarea compleja. Sin embargo, la realidad nos dice que todavía hay empresas que no cumplen este apartado, sobre todo entre las PYMEs y microPYMEs, y la principal razón aducida suele ser el desconocimiento. Pese a todo, esto no supone un problema para el común de los usuarios, ya que en su mayoría también desconocen los citados derechos, y por lo tanto no suelen pretender hacer uso de ellos. Ni siquiera el ejercicio del deber de información (por cierto, uno de los apartados en los que más suspensos suelen tener las empresas) suele tener efectos, ya que los usuarios no suelen leer la "letra pequeña".

Las obligaciones técnicas impuestas por el Reglamento suponen un problema distinto. En este caso, se impone la adopción de determinadas medidas técnicas que, en muchos casos, obligan a la adquisición y uso de ciertas tecnologías que permitan control de accesos, logging, backup, etc. Aquí las empresas con presupuesto ajustado se llevan la peor parte, ya que muchas aducen que su presupuesto es incapaz de afrontar la compra de estas herramientas y/o la contratación de servicios técnicos para su integración. Por un lado, la compra de las licencias software necesarias no suele ser una prioridad, y en ciertos entornos con datos hasta ahora de nivel alto la adquisición de herramientas que cumplan con el control de acceso y logging a nivel de registro suele ser prohibitiva. Por otra parte, son todavía muchos los ámbitos en los que la informática se ve como un "bicho raro", y la filosofía de "mejor no tocar" suele ser común. Por lo tanto, en muchas empresas que cuentan con la tecnología base para implementar las citadas medidas técnicas, estas no se despliegan por desconocimiento o dejadez.

Y precisamente la dejadez es uno de los motivos por los que no se desarrollan las medidas operativas a las que obliga el reglamento. El mantenimiento de listas de usuario, la realización y comprobación de backups o el registro de entradas y salidas son tareas que exigen cierta dedicación. Sin embargo, son muchos los casos en los que no se da a estas tareas la prioridad necesaria, o en los que el responsable del fichero ni siquiera define a los encargados de realizarlas. En definitiva, estas tareas acaban por no realizarse con la frecuencia necesaria, y en algunos casos terminan por dejar de hacerse. Cuando el negocio y la productividad es lo fundamental, en algunos entornos se descuidan otras obligaciones. Sobre todo, si los recursos humanos son escasos, están sobre-explotados o sus responsabilidades están insuficientemente definidas.

Como comentaba este visitante, es dificil que las empresas que no cumplen adecuadamente con los requisitos de la LOPD garanticen la continuidad de su negocio. En este tipo de entornos, en muchos casos el día a día es suficiente preocupación. Y, sin embargo, toda empresa, independientemente de su dimensión, está obligada a cumplir con las exigencias legales aplicables, y por tanto con la LOPD. Es más: en un entorno cada día más interactivo e interconectado, aspectos como la seguridad de la información van a ir cobrando cada día más relevancia. ¿Cómo conciliar estos dos aspectos?

Esta última pregunta, desde mi punto de vista, subyace en la redacción del nuevo reglamento. Al menos, en el apartado de reducir el nivel de ciertos ficheros "comunes", con el fin de reducir las exigencias mínimas para las empresas "corrientes". Creo que este nuevo reglamento reduce estos mínimos y facilita la adopción de medidas, en muchos casos no-técnicas, para el común de las empresas. Sin embargo, creo que este nuevo borrador de reglamento también intensifica, en los ficheros de mayor nivel, los controles a implementar, con la particularidad de que tras la redefinición de niveles estas medidas son aplicables en entornos que habitualmente tienen mayor capacidad técnica y económica, a priori. De este modo, empresas pequeñas como talleres de reparación, bares o comercios verán relajadas sus exigencias, mientras que aseguradoras, banca o empresas del ámbito sanitario deberán cumplir con mayores exigencias, acordes al mayor nivel de los datos manejados y al mayor potencial económico para su cumplimiento. En definitiva, se trata de adecuar las medidas tanto a los datos manejados como a la capacidad de las empresas, para que todos podamos salir beneficiados.

Agradecimientos

Este post lo quiero dedicar únicamente a dar las gracias a todas las personas que han referenciado este blog, y que han contribuido a que tenga mucha más difusión de la que yo me esperaba. Son, como mínimo, los siguientes:
  • Sergio Hernando, a través de este post en su blog.
  • Jose Manuel Fernández, en este post.
  • Segu-Info.com.ar, en sus citas.

Seguro que me dejo a muchas personas (pido disculpas). A todos ellos, muchas gracias por los elogios, y espero no defraudaros. Intentaré que los post sigan teniendo la misma calidad que les habeis concedido a los publicados hasta el momento.

Y por último, gracias a todos los que leeis habitualmente el blog. Es una verdadera satisfacción ver que hay más personas a las que interesan estas reflexiones. Y que sepais que trataré de dar respuesta a todas las inquietudes que planteeis a través del blog.

Muchas gracias a todos.

Un saludo,

Joseba.

27 octubre 2006

Outsourcing de servicios de seguridad

No sé si por casualidad o porque en estos últimos tiempos se está poniendo de moda, el caso es que últimamente han caído entre mis manos varios artículos sobre outsourcing de seguridad. En general, el mensaje de todos ellos venía a ser similar:
El outsourcing de servicios de seguridad es positivo siempre y
cuando el prestador de servicios sea de garantía, se externalicen únicamente
aquellos servicios en los que el expertise externo suponga un verdadero
valor añadido y en todo caso se mantenga el adecuado control sobre los
servicios externalizados.

Realmente, la conclusión no aporta demasiado, puesto que las tres condiciones parecen evidentes y de sentido común. Pesea a ello, creo que es una conclusión interesante ya que define, a grandes rasgos, las líneas de trabajo a seguir por una organización que quiera externalizar servicios (nótese que no me limito exclusivamente a los servicios de seguridad):
  • Selección de prestadores de servicios de garantía: Definamos los requisitos a exigir a los prestadores, y verifiquemos las referencias. Si no tenemos claros los requisitos, las certificaciones pueden ser de gran ayuda (por ejemplo, exigir una certificación en seguridad tipo ISO 27001 a un prestador de servicios de seguridad parece una buena idea).
  • Definición de los servicios a externalizar: Este es quizás el punto clave, y por su extensión requeriría un post específico. Aquí me limito a señalar que, para empezar a externalizar, lo hagamos por aquellos servicios en los que claramente la subcontratación sea beneficiosa económicamente (subcontratar salga más barato que desarrollar con personal interno la misma tarea con el mismo nivel de servicio), y no suponga el acceso a know-how de negocio ni información confidencial. Si hay dudas, mejor empezar por otros servicios.
  • Control sobre los servicios externalizados: Tenemos que definir tanto los requisitos a controlar (SLAs, indicadores de nivel de servicio, cláusulas específicas, auditoría) como la metodología de control y supervisión, y que figure claramente en el contrato. No olvidemos que subcontratamos la operación, no la responsabilidad.

Como una primera aproximación, creo que estas ideas pueden servir para identificar los primeros pasos a seguir en la externalización de servicios. Si son ciertos los pronósticos de que el futuro va en esa dirección, tratemos de estar preparados para cuando se convierta en necesidad...

25 octubre 2006

Desarrollando Métricas

El objetivo de este post es ampliar un poco mi comentario en relación al post de Antonio Valle sobre métricas en su blog.

Como bien dice el citado post, las métricas están de moda. Sin embargo, a la hora de la verdad es difícil encontrar a alguien que tenga claro qué medir y cómo medirlo. Ni siquiera los propios estándares se ponen de acuerdo entre ellos, y hay diversos modelos de métricas. Esta pretende ser una breve guía sobre un modelo flexible y sencillo (espero), que creo que puede ser efectivo:
  1. En primer lugar, tenemos que identificar los procesos cubiertos y, sobre todo, qué hace cada uno (para una mayor aclaración sobre procesos, os recomiendo este post, de Jose Manuel Fernández).
  2. Una vez que tengamos claro el funcionamiento de cada proceso, tenemos que identificar aquellas situaciones en las que el proceso funciona bien. ¿Por qué decimos que funciona bien? Qué variable estamos identificando como correcta? Aquí tenemos los primeros candidatos a métricas.
  3. Cuando ya tenemos las primeras variables identificadas, tenemos que analizarlas. Ver sus interrelaciones, el significado de cada una, su composición y los parámetros que evalúa. ¿Cuáles son los que más nos interesan? ¿Cuáles reflejan de forma clara el principal objetivo del proceso? Tendremos que seleccionar los más adecuados, y ya tendremos las métricas operativas, de cada proceso.
  4. A continuación, pensemos en los procesos trabajando de forma conjunta para ofrecer servicios. Si cada proceso viene parametrizado por sus métricas, con los servicios va a suceder algo similar. El proceso a seguir es parecido, aunque con un elemento adicional a tener en cuenta. Van a aparecer métricas compuestas, derivadas de la interrelación de las anteriores, y otras propias del servicio, como entidad de nivel superior.
  5. Siguiendo el citado proceso de identificación y selección, llegaremos a escoger las métricas tácticas, que parametrizarán los servicios. Estas métricas serán más generales, estarán más cerca del nivel de negocio que las anteriores. Y si los servicios están estandarizados, algo necesario para el benchmarking, las métricas también lo estarán. Por tanto, aquí ya podemos hacer uso de estándares y guías que nos ayuden en esta identificación.
  6. Por último, y si queremos disponer de un juego de métricas completo, tendremos que desarrollar (o integrar) las métricas estratégicas. En este punto no sólo tendremos que identificar los parámetros de nuestros servicios, sino identificarlos y relacionarlos con parámetros de negocio como el rendimiento económico o la productividad. De nuevo, a este nivel nos ayudan los estándares, así como todo el conjunto de indicadores de negocio que, en mayor o menor medida, todas las organizaciones tienen desarrollado.

Por último, sólo señalar que esta es una aproximación botton-up, que parte de la ausencia de métricas para desarrollar el juego completo, de abajo hacia arriba. Sin embargo, en muchas organizaciones ya se cuenta, como he señalado, con indicadores estratégicos, y por lo tanto se puede tratar de usar una aproximación top-down. Para estos casos, mi consejo es que se siga una metodología compuesta, y que sea en el nivel táctico de parametrización de servicios donde se integren ambas aproximaciones. De este modo, será más sencillo identificar los indicadores de negocio con indicadores tácticos, y a partir de ahí encajar las métricas desarrolladas a nivel de proceso. Aunque esto sólo es un consejo...

Saludos

20 octubre 2006

Control Interno y Auditoría

En muchas ocasiones me encuentro con empresas que no tienen muy clara la diferencia entre control interno y auditoría. El objetivo de este post es, sencillamente, tratar de diferenciar ambos conceptos.

El control interno (siendo estrictos, las actividades de control interno) lo constituyen tareas y funciones inherentes a la propia actividad de la organización, y son aquellas actividades del día a día que tratan de verificar que los procesos se realizan según lo establecido. Son tareas distribuidas, que desarrollan desde los directivos hasta los técnicos y operarios. Hay actividades de control tan sencillas y acotadas como verificar que todas las piezas fabricadas están dentro del umbral permitido, y otras que pueden ser tan difusas como comprobar el grado de aprovechamiento de las acciones formativas. Ligado al control interno deberían aparecer los indicadores (tanto estratégicos como tácticos y operativos), como parámetros a evaluar dentro de esas actividades de control interno.

Por otro lado tenemos la auditoría. A diferencia de lo anterior, las auditorías son acciones puntuales y ajenas a los elementos auditados, cuyo objetivo es tratar de identificar el grado de cumplimiento de determinadas normativas y objetivos asociados. Las auditorías son análisis puntuales, cuyo objetivo es primordialmente emitir un diagnóstico objetivo y neutral sobre el estado del elemento auditado.

La confusión entre ambos conceptos nace de que ambas actividades están encaminadas a la evaluación del elemento controlado o auditado. Sin embargo, la diferencia es que las auditorías buscan más el análisis de estado y la consiguiente identificación de fortalezas y debilidades, mientras que el control interno se centra más en la identificación de tendencias. Además, las primeras son acciones puntuales, mientras que las segundas son continuas.

Está claro que existen muchas más connotaciones que habría que analizar a la hora de dar una definición y diferenciación completa entre ambos conceptos, pero espero que estas breves nociones sirvan para identificar más fácilmente las diferencias entre ambas. Al menos, para saber qué podemos exigir cuando tengamos que sentarnos frente a un auditor y pedirle que analice nuestra organización...

19 octubre 2006

Responsabilidad estatal en materia de seguridad (II)

Hoy recupero el tema de un post anterior, una vez que ha surgido algún que otro comentario al respecto. Como esperaba, es un tema que despierta controversia, aunque en este caso creo que no está correctamente interpretado.

La responsabilidad estatal, al menos desde mi punto de vista (creo que el autor del artículo se puede aproximar a él, pero prefiero no posicionarle y que lo haga él mismo si es que tiene conocimiento de este post y lo considera oportuno), pasa por establecer unas condiciones mínimas de funcionamiento. De hecho, no es algo nuevo, ya que estas condiciones mínimas son, sencillamente, las leyes (junto con el resto de ordenación y regulación, evidentemente). Si lo traducimos a términos relacionados con la seguridad de la información, y usamos un ejemplo tan conocido como puede ser la LOPD, creo que es sencillo de entender. Las leyes (en este caso, la propia Ley Orgánica de Protección de Datos) serían las políticas de seguridad, a las que entiendo que se refiere el artículo. Y el procedimiento correspondiente, que regula cómo se debe aplicar la política, no sería otro que el Reglamento de Medidas de Seguridad.

En este caso, el papel del estado pasa por definir cuáles son las medidas mínimas que se deben respetar en relación al tratamiento de datos personales, sobre todo en materia de confidencialidad. Pero si nos centramos en otra de las dimensiones de la seguridad, la disponibilidad, creo que podemos ver claramente las repercusiones que en este ámbito tienen ciertas infraestructuras críticas como pueden ser las líneas de comunicaciones o las de transporte de electricidad.

Desde mi punto de vista, el estado debe garantizar unas mínimas políticas de seguridad a sus clientes, los ciudadanos. A partir de ahí, serán las empresas y los propios usuarios los que decidan si prestan o exigen mejores condiciones. Pero si no se definen unos mínimos exigibles... ¿Cómo se puede garantizar que se alcanza el nivel de servicio necesario? En aspectos como la seguridad de la información, dejar todas estas condiciones en manos exclusivas del mercado (con los vicios inherentes que conlleva) creo que es demasiado arriesgado. Volviendo al ejemplo de la LOPD, me parece correcto que el estado, dentro de su responsabilidad en materia de seguridad, defina unos requisitos mínimos tanto a nivel de políticas como de procedimientos, que tanto empresas como administraciones deban cumplir. Y el propio mercado ya provocará que algunas de ellas mejoren esas condiciones y decidan incluso llegar a implantar un SGSI para mejorar dicha seguridad. Pero, mientras tanto, el tratamiento de los datos personales de los ciudadanos será mínimamente seguro.

17 octubre 2006

Definiendo el alcance del SGSI

Uno de los pasos más importantes a la hora de implementar un SGSI es definir adecuadamente el alcance. ¿Qué ámbito debe cubrir? Suele ser un tema complicado de decidir, principalmente porque un alcance global, que cubra toda la organización, no suele ser ni la opción más eficiente ni la más eficaz. Tenemos que pensar que la implantación de un SGSI es un proyecto de gran calado, con repercusiones transversales a todo el alcance que definamos, y cuyas raíces deberían llegar hasta la cultura de la organización. Por tanto, la mejor opción siempre será diseñar un SGSI para un alcance más reducido, optimizando recursos y resultados, que más adelante ya ampliaremos, cuando la filosofía de gestión de la seguridad haya calado y los controles implementados se puedan extender progresivamente.

Por tanto, una vez que hemos decidido que el alcance sea parcial... ¿Qué procesos, divisiones o departamentos debe cubrir? Se trata de identificar aquella parte de la organización en la que la seguridad puede aportar un mayor valor añadido. Pero... ¿Qué filosofía podemos seguir para identificar ese valor añadido? Aquí cito algunas de ellas:
  • Aumentar el valor de un servicio "seguro": Esta filosofía supone implementar un SGSI para potenciar un servicio que ya incorpora funciones de seguridad, en el que un SGSI va a aportar beneficios directos. Es una opción evidente, con el inconveniente es que sólo es aplicable para aquellos servicios en los que la seguridad es un valor intrínseco al mismo.
  • Potenciar un servicio final: Esta opción supone la implantación de un SGSI ligado a los servicios y/o procesos de negocio. De esta forma, se da un valor añadido a los mismos, bañándolos de una capa de seguridad adicional. Es una filosofía muy válida en aquellos entornos en los que se quiera sacar provecho de una certificación, ya que la seguridad repercute directamente en los clientes.
  • Reforzar los servicios y procesos internos: Esta filosofía pretende implantar el SGSI para fortalecer determinados servicios y procesos internos, en los que una mejora en la seguridad pueda suponer una ventaja para la organización. En general, se suele traducir en la implementación del SGSI en el área de IT, por ser uno de los principales responsables del tratamiento y conservación de la información de la compañía, o en áreas en las que se maneja información de especial relevancia, como podrían ser las áreas de I+D+i (prototipos, diseños, etc), recursos humanos (datos de caracter personal) o financiero (datos económicos).
  • Potenciar la gestión interna: Por último, otra de las filosofías que a veces se utiliza para decidir el alcance es identificar aquellas partes de la organización en las que la implantación del SGSI, como sistema de gestión, sirva para potenciar y estructurar la gestión interna. Es quizás una de las filosofías más discutibles, ya que existen multitud de sistemas de gestión centrados en distintos aspectos y quizás el de la seguridad pueda no ser el más indicado en todos los casos, pero en determinadas situaciones puede ser una opción.

Seguro que a todos se nos pueden ocurrir más filosofías para decidir la implantación de un SGSI en una u otra parte de la organización, pero desde mi punto de vista estas son las principales. Ahora, es suficiente con identificar cuál encaja mejor con nuestra organización, y utilizarla para identificar el mejor ámbito para implantar nuestro SGSI. Suerte en el intento...

11 octubre 2006

Responsabilidad estatal en materia de seguridad de las infraestructuras críticas

Hoy he estado releyendo un artículo de editorial de la revista Auditoría+Seguridad. En él, Ricardo Cañizares hace referencia, en un solo párrafo, a un tema de tanta trascendencia como es la responsabilidad estatal en materia de seguridad. El director de la revista afirma lo siguiente:

El estado debe asumir la responsabilidad de garantizar la seguridad de las Infraestructuras Críticas, legislando, implantando políticas y procedimientos, y coordinando los esfuerzos de todas las organizaciones involucradas en el despliegue y gestión de las Infraestructuras Críticas.

Este breve comentario es suficiente como para abrir un interesante debate. ¿En qué medida el estado debe intervenir de cara al aseguramiento de las infraestructuras críticas? ¿Cuál es el grado de responsabilidad estatal, frente al que corresponde a las organizaciones que despliegan dichas infraestructuras? ¿Qué grado de regulación es aceptable? Son muchas las preguntas que surgen alrededor de un tema escabroso, en el que se entremezclan intereses de muy diversa índole, como los económicos, los políticos o incluso los geo-estratégicos. Porque... ¿No es precisamente este uno de los principales argumentos que se esgrimieron durante la polémica surgida en torno a la famosa OPA de E.On? ¿Hasta qué punto es sincero el interés de los estados en proteger las infraestructuras críticas? Son temas delicados...

Como no quiero condicionar ninguna postura, prefiero deternerme aquí e invitar a todos los lectores a que dejen aquí su opinión. Seguro que todas sirven para enriquecer la propia ...

09 octubre 2006

Comentarios al nuevo reglamento para la LOPD

Hace unos días, un compañero de trabajo me hizo llegar un artículo muy interesante titulado "Posibles implicaciones para el directivo TIC del nuevo reglamento sobre la protección de datos", de Raúl Rubio. Es una explicación muy clara de las principales consecuencias que conllevaría el borrador del nuevo reglamento para la protección de datos, en caso de aprobarse.

Entre las aclaraciones más importantes del nuevo reglamento, podemos destacar las siguientes:
  • Se rebaja el nivel de muchos ficheros: Los ficheros de caracter general de las empresas (nóminas, por ejemplo) pasarán a ser de nivel bajo, aunque contengan datos económicos, de afiliación sindical o de salud, siempre y cuando la finalidad de esos ficheros no sea el tratamiento expreso de dichos datos.
  • Para los trabajadores externos que trabajen en nuestras dependencias se exige la firma de cláusulas de confidencialidad o documentos similares, y deberá indicarse en el documento de seguridad.
  • Todos los trabajadores externos con acceso a los ficheros pero cuyo trabajo no suponga el tratamiento de los datos (limpieza, mantenimiento, hosting, etc) deberán firmar cláusulas de prohibición de acceso a los datos y de obligación de mantener el derecho de secreto, en caso de que deban acceder a ellos. Por su parte, el responsable deberá limitar, en la medida de lo posible, el acceso de estas personas a los datos.
  • Los medios removibles que por su naturaleza no puedan ser etiquetados y clasificados (por ejemplo, Pen Drives) están exentos de cumplir dicha obligación.

Desafortunadamente, aparecen nuevas exigencias, entre las que se destacan las siguientes:

  • Se exige que, para TODOS los archivos, se definan no sólo los usuarios con acceso sino los perfiles y niveles de acceso de cada uno de ellos.
  • TODOS los usuarios deben tener identificadores unívocos y personalizados, independientemente del nivel del archivo al que tengan acceso.
  • Será necesario probar los backups con una frecuencia máxima de 6 meses, independientemente del nivel del archivo respaldado.
  • Los ficheros de nivel MEDIO y ALTO tendrán la obligación de registrar los accesos hasta el grado de identificar el registro accedido y el resultado del intento de acceso, a no ser que sólo el propietario del fichero tenga acceso a él.
  • Las auditorías, obligatorias para ficheros de nivel MEDIO y ALTO, deberán ser notificadas a la AEPD.

Por otra parte, el nuevo reglamento establece las exigencias para los ficheros no automatizados (papel). Las principales son las siguientes:

  • Inventariar y controlar el acceso en las mismas condiciones que con los ficheros automatizados.
  • Destruir o borrar cualquier documento o soporte que vaya a ser eliminado.
  • Registrar las entradas y salidas de documentos que contengan datos de nivel MEDIO y ALTO.
  • Almacenar los ficheros de nivel MEDIO y ALTO en lugares ignífugos y con acceso restringido o vigilado.
  • Procedimentar la realización de copias y reproducción de los documentos de nivel MEDIO y ALTO.
  • Para los ficheros de nivel ALTO, también habrá que registrar los accesos a los documentos (durante 2 años como mínimo) y protegerlos mediante llaves o medidas equivalentes.

Como se puede ver, el borrador del nuevo reglamento introduce importantes exigencias, algunas de las cuales van a suponer esfuerzos realmente importantes por las empresas, que deben cumplirlo. ¿Cuantas de estas exigencias sobrevivirán a la publicación final del reglamento? ¿Cuántas se eliminarán? ¿Cuál será el periodo de moratoria para su cumplimiento? En un futuro próximo (o quizás no tanto), lo veremos.

05 octubre 2006

Incumplimientos de la LOPD

Hoy hay varios blogs que hacen eco del informe sobre sentencias de la AEPD que publica firma-e.com en su web. De él se pueden destacar varios aspectos, como son:
  • El incumplimiento más común, y el que mayores sanciones ha supuesto, es el relativo a la calidad de los datos, sobre todo por contener datos inexactos.
  • El siguiente incumplimiento más habitual es el relativo al consentimiento del afectado, por no poder demostrarse un consentimiento inequívoco. En lo relativo a sanciones, se sitúa en tercer lugar.
  • El segundo incumplimiento que más sanciones ha supuesto es el relativo a cesiones no consentidas. Se debe a que, por la gravedad del incumplimiento, las sanciones son más elevadas, ya que este incumplimiento sólo motiva el 6% de las sentencias.
  • Finalmente, el tercer incumplimiento más habitual en las sanciones de la AEPD es el deber de secreto, con un 11% de los casos.

No tenemos que olvidar que estos resultados son los referidos a sanciones impuestas por la AEPD, es decir, a incumplimientos investigados por la AEPD. Sin embargo, si presuponemos que estas empresas sancionadas supone una muestra homogénea del parque empresarial nacional, podríamos extender estas conclusiones a incumplimientos generales en las empresas.

Por último, sólo añadir que estos resultados demuestran, sobre todo en el caso de las cesiones no consentidas, que la gravedad del incumplimiento va a determinar la importancia de la sanción. Como no podía ser de otra forma, existen medidas de seguridad más importantes que otras. Y lo fundamental es saber identificarlas, y reforzar las verdaderamente necesarias.

02 octubre 2006

Indicadores y metricas de seguridad

La web ISO27000.es publicó ayer un artículo muy interesante sobre métricas de seguridad. En resumidas cuentas, plantea los conceptos de "madurez" y "calidad de la seguridad" como parámetros principales para la definición de indicadores y métricas. En concreto, los pasos que se deben seguir para implantar un conjunto de métricas de acuerdo a dicho artículo se resume en:
  1. Identificar los elementos a medir a partir del índice de la ISO 17799
  2. Definir los niveles de madurez para cada uno de los elementos medidos
  3. Definir los niveles de calidad para cada uno de los niveles de madurez de cada elemento

De esta forma, tendremos una pareja de valores que, por cada elemento medido, nos informarán del grado de evolución del control y de la calidad con la que lo hemos implementado. Unos valores que, en conjunto, nos pueden dar una imagen REAL del nivel de seguridad de la organización. Métricas que se convierten en indicadores de seguridad. Muy sencillo de entender... aunque me temo que no tan fácil de implantar. Así que lo mejor en estos casos es, como se suele decir, menos hablar y más trabajar. Manos a la obra, y ya veremos cuál es el resultado...

28 septiembre 2006

Conceptos de Continuidad de Negocio

Siguiendo con el objetivo de aclarar conceptos, en este post voy a hacer algunas indicaciones sobre continuidad de negocio. Es un tema que cada día está más en boga, y que vuelve periódicamente a la palestra cada vez que una catástrofe afecta a empresas de cierto renombre.
Para empezar, tratemos de diferenciar entre:
  • Incidente: Es cualquier "problema". Si hacemos una analogía con la salud, sería cuando nos duele una muela, o cuando nos han pegado una patada en la espinilla.
  • Contingencia: Normalmente hablamos de contingencia cuando pensamos en un incidente grave. En temas de salud, estaríamos hablando de nuestras visitas a urgencias. Tanto si el incidente era grave inicialmente como si se ha agravado con el tiempo, por no resolverlo.
  • Crisis: Son incidentes extremadamente graves, que hacen peligrar la continuidad del activo. Estaríamos hablando de una crisis cardiaca, que haría peligrar la vida del paciente.

Como vemos, la diferencia entre esos conceptos es, simplemente, su gravedad. Del mismo modo, hablando de continuidad de negocio tenemos que pensar en términos de "gravedad" o "importancia" a la hora de diferenciar entre conceptos que normalmente se confunden, como son el Plan de Contingencias y el Plan de Continuidad de Negocio.

  • Plan de Contingencias: Hablamos de Plan de Contingencias si nos referimos a un documento con planes concretos para problemas acotados. Estaríamos ante una respuesta concreta para cada contingencia, independientemente de la causa. Podemos pensar en un plan que contemple la implantación de un marcapasos para las arritmias severas, entre otras contingencias posibles.
  • Plan de Continuidad de Negocio: En este caso estamos hablando de un plan más ambicioso, que garantice la continuidad en caso de crisis. Podríamos pensar en un corazón alternativo, para la persona que sufre del corazón.

En este caso, vemos que las contingencias se resuelven de forma distinta que las crisis. Para una contingencia concreta, la arritmia, usamos un marcapasos. Para otra distinta, como podría ser una obstrucción de las arterias, tendríamos un bypass. Todas estas soluciones constituirían el Plan de Contingencias para el enfermo de corazón. Sin embargo, el Plan de Continuidad de Negocio resolvería todos los problemas utilizando otro tipo de solución, el trasplante, aunque con un coste y unas implicaciones mucho mayores.

Por último, señalar que el ejemplo plantea un plan de continuidad de negocio para un elemento muy concreto de la persona (aunque vital, por otra parte). Esta suele ser una duda muy habitual: ¿Los planes de continuidad de negocio contemplan toda la organización a nivel global o los centros vitales a nivel particular? Estrictamente deberíamos pensar en el primer caso. Sin embargo, la situación más habitual suele ser la segunda opción, más rentable a nivel económico y con un alto grado de eficacia. Así que, como siempre, la decisión final queda en manos de la empresa. Y tendrá que ser evaluada y validada tras un análisis de riesgos...

26 septiembre 2006

Conceptos de Analisis de Riesgos

Una de las dificultades más habituales a la hora de abordar un análisis de riesgos suele ser la definición de conceptos. En este post no quiero dar definiciones oficiales, sino tratar de aclarar las diferencias entre todos ellos. Veamos si lo logro.

  • Activo: Es cualquier "cosa" que tiene valor para la empresa. Un servidor es un activo, una licencia también lo es. Pero no sólo eso: las personas, los servicios, los procesos, la imagen de la empresa, la marca... todo son activos.
  • Valor: Es la importancia que tiene ese activo dentro de la empresa. No su valor económico. Pongamos un ejemplo sencillo. ¿Cuál es el valor del carnet de conducir? ¿Lo que ha costado conseguirlo (autoescuela, tasas, ...)? Pues no, depende de la importancia de ese activo para la empresa. Para un autónomo que trabaja entregando paquetes a domicilio tiene más valor que para otro que trabaja en casa como teleoperador.
  • Amenaza: Es aquél elemento que puede provocar daños sobre el activo. Si estamos clavando un clavo, y el activo es nuestro dedo, está claro que la amenaza es que el martillo nos golpee.
  • Probabilidad de ocurrencia de la amenaza: Es la probabilidad de que la amenaza se materialice, es decir, la probabilidad de pegarnos un martillazo en el dedo. A nivel estadístico, genérico.
  • Vulnerabilidad: Es el grado de debilidad de un activo frente a una amenaza, la capacidad que tiene la amenaza de afectar a el activo. En nuestro caso, cómo de resistente es el dedo frente al martillazo.
  • Exposición : Es la medida de la vulnerabilidad, lo desprotegido que está. Dependerá de si tenemos guantes o si somos unos "machotes".
  • Incidente: El martillazo (la materialización efectiva de la amenaza, aprovechando la vulnerabilidad).
  • Degradación: Es un término que utilizan algunas metodologías para referirse al potencial que tiene la amenaza de dañar al activo. Cuánto daño es capaz de provocar el martillazo.
  • Impacto: Es un término con significados parcialmente distintos en función de la metodología que se utilice, pero que viene a hacer referencia al resultado de que se produzca el incidente. En definitiva, cuánto duele el dedo si nos pegamos un martillazo en él.
  • Riesgo o nivel de riesgo: Es el resultado de combinar todos los términos anteriores. Para ser más claros, la probabilidad de que una amenaza aproveche la vulnerabilidad del activo para provocar un daño. La probabilidad de que nos hagamos daño al pegarnos un martillazo en el dedo.
  • Controles o contramedidas: Medidas dispuestas para rebajar el nivel de riesgo: usar guantes (o guantes más gruesos), aprender o perfeccionar nuestro uso del martillo, fortalecer nuestro dedo, subcontratar la tarea...

Estos términos pueden variar en función de la metodología que utilicemos, pero los conceptos van a ser siempre los mismos. Lo importante es tener clara la metodología, y que todo el mundo piense en lo mismo cuando hacemos uso de ellos. Sobre todo, ahora que ya están más claros... ;-)

20 septiembre 2006

La Calidad de la Información

Hace unos días leí un artículo bastante interesante. Hablaba sobre la calidad de la información, y planteaba aspectos a tener muy en cuenta en esta sociedad de la información. Los más destacables quizás sean los siguientes:

  1. Datos es distinto que información. Una mayor cantidad de datos uno supone más información si esos datos no aportan nada. Una reflexión de fondo en mi anterior post sobre Consolidación de Logs, y que en este artículo se plantea de forma muy clara. Siempre será más útil dedicar algo de tiempo a procesar esos datos y poder almacenar poca información útil que dedicar algo más de dinero a recursos que permitan almacenar muchos datos...
  2. La calidad de la información no sólo se basa en la calidad de los propios datos, sino que el modelo de datos, la gestión de la base de datos o la presentación son elementos fundamentales a analizar. ¿Cuántos casos conocemos en los que unos datos de calidad no sirven para generar información de calidad? Y todo por no tener en cuenta cómo se modelizan esos datos, cómo se tratan o cómo se presentan.
  3. La calidad del SGBD está fuertemente enreaizada en la seguridad. El artículo hace referencia a la ISO/IEC 9126 a nivel de calidad de software, para posteriormente adentrarse en aspectos de seguridad como control de acceso, cifrado, logs, backups, ... No recuerdan esos elementos a algunos controles de la ISO 27001?
  4. La calidad de los datos tiene importantes implicaciones jurídicas. El propio artículo ya señala las referencias a la LOPD, pero no está de más tener este aspecto en cuenta en nuestro día a día...
  5. Aseguramiento de la calidad de la información = política + revisión + auditoría. Estamos ante el famoso ciclo de Deming (PDCA), asumiendo que la garantía de la calidad sólo se puede obtener a través de la mejora contínua.

En resumen, estamos ante un artículo que, hablando de la calidad de la información, se aproxima mucho a los principios de sistemas de gestión más conocidos como los SGSI o la gestión de los servicios IT. Porque, en realidad, cuando hablamos de estos temas... no estamos hablando de temas similares? No sería posible un enfoque coordinado? Presumiblemente, este tema dará mucho que hablar en el futuro...