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...

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...

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... :-) )

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...

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... ;-)

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.