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...
30 noviembre 2006
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...
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... :-) )
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:
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:
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.
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.
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.
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...
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...
Suscribirse a:
Entradas (Atom)
