Herramientas de apoyo a las politicas de seguridad

Hace algunos días leí un artículo que me llamó la atención. Hablaba sobre la conveniencia de utilizar herramientas que automaticen la revisión de cumplimiento de las políticas de seguridad de la compañía. El artículo se enfoca principalmente en las ventajas que aportan las herramientas cuando hay que verificar las políticas contra distintas normas. Sin embargo, creo que hay otros motivos que deben tenerse en cuenta, y que muchas veces suelen ser más determinantes a la hora de tomar estas decisiones.

La primera, y desde mi punto de vista, la más importante en la práctica, es la capacidad que aporta una herramienta a la hora de mantener actualizadas las políticas de la organización. Un simple checklist automatizado tiene muchas más posibilidades de ser rellenado que el mismo checklist en formato tabla. Inexplicablemente, algo dinámico motiva más a la hora de utilizarlo que el mismo contenido en versión estática. Y mantener actualizado el cumplimiento normativo quizás pueda ser tedioso, pero es imprescindible...

Otro de los motivos para optar por una herramienta son las ventajas que ofrece tener un lugar centralizado y multi-usuario para ubicar toda la información relativa a dicho cumplimiento. Una herramienta puede ser accesible por varias personas, con varios perfiles, para distintos fines... pero todos accediendo al mismo repositorio. Desde el responsable de seguridad al auditor, pasando por los directores o los técnicos. Porque todo el que tenga implicaciones en las normativas chequeadas tendrá que conocerlas y actualizarlas...

Y el último de los motivos que quiero destacar, para no extenderme, es la capacidad de registro de cambios que ofrecen este tipo de herramientas. Es uno de los aspectos más duros de cumplir en la práctica, y no sólo a nivel de cambios en la documentación, sino también a la hora de llevar un registro de las distintas formas en las que se cumplen los controles. Nuevos procedimientos, distintas formas de implementar los mismos controles en distintos entornos... Muchas particularidades, que de forma manual sería difícil mantener al día.

En definitiva, las herramientas suelen existir por una razón muy sencilla: facilitan las cosas. Y cuando los fabricantes les dan un coste económico, y hay empresas dispuestas a comprarlas, tiene que ser porque realmente son útiles, no? De todos modos, no olvidemos algo: las herramientas ayudan, pero lo importante es saber hacer las cosas, y entender la lógica que subyace. No debemos cometer el error de volvernos dependientes de ellas.

Sucesos de seguridad

A veces, las cosas más sencillas acaban pareciendo las más complicadas. Una de ellas suele ser lo relativo a la gestión de sucesos de seguridad. Incidentes, eventos, incidencias, fallos... Un montón de términos que a veces se confunden, se entremezclan, y que a los encargados de tratar con ellos dan más quebraderos de cabeza de los que debieran. Y sin embargo, las cosas suelen ser más sencillas de lo que parecen...

Por un lado, tenemos las incidencias de seguridad. Entendidas, sencillamente, como que "ha pasado algo relacionado con la seguridad". Qué ha pasado? Tenemos tres opciones. La primera es que haya pasado "algo malo". Hemos tenido un problema, algo ha fallado. Técnicamente, una amenaza ha conseguido explotar una vulnerabilidad sobre un activo. Y qué hay que hacer? Simplemente, arreglarlo. A eso se le llama corrección.

Otra opción es que la incidencia haya quedado "en nada". Ha sucedido un evento, pero no ha llegado a ser incidente. Una amenaza que nos ha atacado pero finalmente no se ha materializado, una vulnerabilidad nueva que ha aparecido, pero que aún no ha sido explotada... Lo que haya sucedido todavía no nos ha hecho ningún daño. Aunque si no hacemos nada, podría llegar a causarlo. Qué hay que hacer? Evitarlo antes de que suceda: corregir aquello que acabamos de descubrir que está mal, antes de que pase nada (acciones correctivas) o reforzar nuestras medidas de protección, por si acaso (acciones preventivas).

Todavía tenemos una tercera opción. Lo que ha pasado es que hemos descubierto que nuestros controles no funcionan bien. No es que haya pasado algo malo, sino que hemos encontrado un fallo en nuestro sistema de gestión. La incidencia, en este caso, se cataloga como no conformidad, y lo que tendremos que arreglar en este caso es el control en sí, mediante las acciones correctivas correspondientes.

Por último, existe otro tipo de entrada que puede dar lugar a este tipo de acciones. En este caso yo no lo catalogaría como incidencia, ya que no es que "haya pasado algo", sino que alguien realiza una aportación (sugerencia, comentario, ...). En este caso, la aportación (realizada por cualquier persona de la organización) puede ser una propuesta de mejora (lo que desencadenaría la correspondiente acción preventiva si así se considera) o puede "levantar alguna liebre", descubrir algún fallo que deba ser resuelto, mediante las correspondientes acciones correctivas.

Y no olvidemos que una corrección puede conllevar, en su tratamiento a posteriori, una acción correctiva para resolver la causa que ha provocado el incidente. Y que a su vez las acciones correctivas también pueden desencadenar acciones preventivas que ayuden a optimizar las protecciones existentes en relación al origen de los hipotéticos incidentes. En el fondo, todo está relacionado, no?

Pensando en la seguridad

Hace ya algún tiempo, en VNUnet publicaron un artículo (1-2-3-4-5-6) en el que relataban los resultados de un estudio realizado por McAfee en relación a las empresas y la seguridad. En resumidas cuentas, el artículo venía a decir que las empresas tienen importantes debilidades en materia de seguridad de la información. Las causas son la incapacidad de responder adecuadamente a las exigencias legales en materia de seguridad, el excesivo coste que supondría el hacerlo, la dificultad de llevarlas a la práctica, el número insuficiente de especialistas para poder hacerlo y la gran repercusión en imagen que tienen los incidentes relacionados con la seguridad.

La verdad es que el artículo plantea un panorama duro para las empresas en general... y optimista para las consultoras que se dediquen a ello :-) . El estudio es estadounidense, donde SOX está teniendo bastante impacto en materia de seguridad de la información, así que es posible que este panorama no se vea directamente reflejado en el tejido empresarial europeo o latinoamericano. Sin embargo, dice un refrán que "cuando veas las barbas de tu vecino cortar, pon las tuyas a remojar". Así que creo que no es mala idea ver lo que está sucediendo en aquellos lares, y que las empresas de por aquí se vayan preparando desde ahora, para que cuando lleguen medidas similares el impacto que supongan sea mucho menor... Y que nadie dude de que, tarde o temprano, todas las empresas medianamente potentes deberán adoptar medidas similares. Bien por ley, o bien por exigencias de mercado. Pero mucho me temo que todo llegará...

Calidad no es igual que Gestión

En muchas ocasiones, al nombrar la calidad la gente piensa automáticamente en los sistemas de gestión. Supongo que el mérito se debe a la archiconocida ISO 9001. Esa norma define un sistema de gestión de la calidad. Sin embargo, deberíamos ser capaces de diferenciar las dos partes: el sistema de gestión y el componente de calidad. Los motivos para tener clara esta distinción son diversos, pero yo me voy a quedar con uno en particular: hay muchas normas que definen sistemas de gestión para distintos fines (seguridad de la información, medio ambiente, ...), y si somos capaces de identificar los componentes del sistema de gestión tendremos al alcance de la mano la integración de todos ellos.

Y qué es el sistema de gestión? Como alguien me ha dicho alguna vez, el sistema de gestión es el motor. Es la forma de trabajar, lo que permite que la calidad (en este caso) se gestione de forma adecuada. En resumen, el sistema de gestión es el ciclo PDCA. Y por tanto se compone de:

• Plan: Políticas, objetivos, metas, planes, ...
• Do: Procesos, difusión, formación, gestión documental, registros, ...
• Check: Auditorías, mediciones, gestión de incidencias, no conformidades, revisión por la dirección, ...
• Act: Correcciones, acciones correctivas, acciones preventivas, ...

Estos elementos (junto con algún otro) forman el sistema de gestión, y por tanto serán comunes en cualquier norma que defina un SGx. Es más, serán los elementos principales de un SGI (Sistema de Gestión Integrado).

Y si quitamos el sistema de gestión a la ISO 9001, qué nos queda? Pues sencillamente, la calidad. La calidad es, formalmente, el grado en el que las características de los productos/servicios cumplen con unos requisitos. Qué requisitos? Los del cliente. Es decir, que podemos entender la calidad, sencillamente, como "satisfacer al cliente". Evidentemente, la ISO 9001 introduce otra serie de elementos propios, entre los que podemos identificar como más significativos la selección de proveedores o las encuestas de satisfacción. Además, también regula las líneas generales bajo las que se deben desarrollar los procesos productivos. Sin embargo, creo que lo más destacable desde el punto de vista de la calidad propiamente dicha es la orientación al cliente.

En definitiva, podemos resumir que las principales aportaciones de la ISO 9001 son dos: ser la primera norma de gran difusión que define un sistema de gestión e introducir la orientación al cliente como referencia principal para los procesos productivos. Y aunque a día de hoy ambos conceptos se hayan podido ver degradados, la próxima revisión de la norma puede ayudar a que vuelvan a cobrar la significancia que tuvieron durante su redacción.

Póngame una de SLAs!

Últimamente, eso de los SLAs (Service Level Agreements) se ha convertido en un tema de conversación tan habitual que parece algo que sirvan en los bares de tapas. El problema es que la terminología se ha trivializado tanto que en muchas ocasiones se utiliza el término de forma incorrecta.

Un SLA debe ser, en primer lugar, un acuerdo. En caso contrario estaríamos, como mucho, ante un SLI (de Imposition). Debe ser un acuerdo en todos los sentidos, desde el precio hasta los elementos a valorar. Vamos, que el contrato particular del ADSL nunca será un SLA, aunque nos garanticen un cierto ancho de banda o nos regalen el primer mes de cuota si no funciona bien. ¿O alguien piensa que el operador de banda ancha va a negociar el contrato con los particulares?

Evidentemente, un SLA tiene que incluir niveles de servicio (que por algo aparecen la S y la L). Pero... qué es una disponibilidad del servicio de asistencia técnica del 99%? ¿Significa que casi siempre que llamo me cogen el teléfono? ¿Tanto si llamo a las 10 de la mañana como a las 12 de la noche? El SLA tiene que definir no sólo el servicio en sí, sino sus características, cómo se calcula el indicador, en qué periodo se mide...

Normalmente, los SLAs incluyen penalizaciones si no se alcanzan los compromisos. Pero... es suficiente? Si en lugar del 99% me dan una disponibilidad del 50%, las penalizaciones me resarcen de los perjuicios causados? Y si por culpa del incumplimiento pierdo clientes? Un SLA también debería incluir un mínimo garantizado, que me asegure que la curva de penalización realmente me compensa.

Y otro apartado que debería incluir todo SLA son las condiciones adicionales. Y aquí es donde la mayoría de los mal llamados SLAs fallan. No es suficiente con especificar en el contrato todos los apartados anteriores. Hay otros aspectos como el seguimiento, la gestión de cambios en los servicios prestados, la resolución de conflictos o los roles y funciones de proveedor y cliente que deberían estar especificados. Contemplan estos aspectos los SLAs del bar de tapas?

En resumen, un SLA es un contrato en el que, en el caso ideal, todas las situaciones que se puedan dar en relación a la prestación del servicio han sido contempladas y reguladas. Sobre todo, un contrato en el que se contemple no sólo qué hacer cuando todo va bien, sino que tenga en cuenta cómo actuar cuando todo va mal. ¿El objetivo final? Que los problemas graves entre cliente y proveedor se puedan resolver como amigos, porque hemos acordado en el SLA cómo se deben resolver situaciones que, en otro caso, quizás llegasen a los tribunales.

Valorando con criterio

Uno de los elementos fundamentales a la hora de llevar a cabo un análisis de riesgos es la valoración de los activos. Sin embargo, también suele ser uno de los apartados más difíciles. ¿A qué se debe? Fundamentalmente, la dificultad estriba en dos apartados: Entender el motivo de la valoración y asignar un valor de forma objetiva.

La primera parte es conceptual. En un análisis de riesgos, un activo es “cualquier cosa con valor para la organización”, y esto puede ir desde la imagen o la marca hasta los edificios en los que se ubica, pasando por los servicios o productos que desarrolla, el personal de la organización o los equipos informáticos, entre otros ejemplos. Y cada uno de estos activos debe ser valorado.

¿Qué es el valor? Es la importancia que tiene ese activo para la organización. No debemos pensar directamente en su coste económico, sino en la función que ese activo desarrolla en la organización. Un tornillo en sí mismo no tiene mucho valor, pero si es el que sujeta el ala de un avión, creo que todos entenderemos que el valor de ese tornillo es muy elevado (sobre todo, lo apreciarán los que vayan dentro del avión).

¿Qué hay que valorar? En un análisis de riesgos de seguridad de la información lo que se valora es la seguridad de los activos en relación a la información (y negocio) que sustentan. En este caso, no se trata de entender la importancia de que se caiga el tornillo, sino de que la información pierda su confidencialidad (se divulgue), pierda su integridad (se modifique) o pierda su disponibilidad (no se pueda acceder a ella cuando se necesita). Se puede entender fácilmente a nivel particular con un ejemplo: las nónimas. ¿Cuánto nos importa que alguien se entere de lo que cobramos? ¿O que en la nómina aparezca un 0 de menos? ¿O que no tengamos las nóminas cuando las tenemos que presentar para pedir un crédito?

El ejercicio a nivel empresarial es similar. El problema es que a la hora de asignar valores no es tan sencillo ponerse de acuerdo. ¿Cómo se puede resolver? En primer lugar, pidiendo que la valoración la realice la alta dirección. Buscamos la opinión “de empresa”, no las opiniones particulares. Y guste o no, la opinión de empresa viene dictada por la dirección. Así que deben ser ellos los que deben valorar. Y la valoración no debe ser arbitraria, sino que tiene que ser objetiva (lo más objetiva posible) y repetible.

Para conseguir objetivizar las opiniones tenemos que asignar criterios de valoración. ¿Cuál es la escala de “importancia” de la organización? Pensemos en el avión. ¿Por qué es importante el tornillo? ¿Porque se cae el ala? En realidad no, en realidad es importante por las consecuencias finales que tiene la caída del ala: pérdida de vidas humanas. Ya tenemos un criterio de valoración. Y ese criterio vale para cualquier activo: sea el que sea, e indistintamente del motivo que lo cause, si el resultado final es la pérdida de vidas humanas, ese activo tendrá un valor muy alto.

En nuestras empresas tendremos que hacer lo mismo. La dirección tendrá que hacer el ejercicio de identificar los criterios a tener en cuenta, y posteriormente tendrá que asignar distintos niveles. Si las pérdidas económicas es un criterio de valoración, no será lo mismo perder 10 € que perder 100 ó 1000. El resultado final debe ser una tabla que identifique por filas los criterios de valoración (pérdidas económicas, incumplimientos legales, deterioro de imagen, impactos operativos, …) y por columnas los niveles (por ejemplo, bajo-medio-alto), de modo que cada nivel sea equiparable entre los distintos criterios.

¿Y cuál es la ventaja de todo esto? Que si conseguimos que la dirección valide una tabla de criterios, ya no será necesaria su participación directa a la hora de valorar la enorme cantidad de activos que probablemente habremos identificado. Bastará con indicar que el activo “tornillo” tiene un valor “alto” porque en el criterio “daños personales” encaja en el contenido de la casilla “pérdida de vidas”, que está en la columna de "alto". Seguro que la dirección valida esta valoración, ya que los criterios los han puesto ellos. Y además, cualquiera que conozca lo suficiente el negocio (siempre y cuando sepa que de ese tornillo depende el ala del avión, y que del ala depende que el avión se caiga) podrá repetir el año que viene el mismo análisis y llegar a resultados similares, de modo que habremos conseguido que el análisis sea repetible. Objetivo cumplido!