Seguridad Vs Privacidad. O estamos equivocados?

Es muy habitual pensar en la privacidad y en la seguridad como dos aspectos prácticamente antagónicos. No hay más que buscar noticias sobre privacidad y seguro que nos encontramos con alguna en la que ambos conceptos estén enfrentados. Sin embargo, cuando participas en congresos sobre alguna de las dos temáticas, te das cuenta de que los profesionales que se dedican a ambas disciplinas trabajan de la misma manera, persiguen objetivos similares y tratan asuntos prácticamente idénticos. Cómo puede ser posible que una misma cosa y su contraria puedan ser tan similares?

La realidad es que seguridad y privacidad son prácticamente lo mismo. La única (aunque gran) diferencia entre ambos conceptos está en el foco: la privacidad se preocupa por las personas, la seguridad se preocupa por las organizaciones (empresas o incluso estados). O dicho de otro modo: si aplicásemos todos los conceptos que maneja una de las disciplinas al foco de la otra, estaríamos hablando de lo mismo.

Siendo conscientes de la gran proximidad entre ambas disciplinas todavía puede sorprender más ese antagonismo percibido. Si la privacidad consiste en levantar los muros de mi casa y la seguridad supone añadir una valla exterior, no deberían ser dos planteamientos convergentes en lugar de divergentes?

Por añadir otro argumento más a esta visión, no deberíamos olvidarnos del hecho (trivial, pero importante) de que las organizaciones están compuestas por personas. Por lo tanto, si protegemos la seguridad de las personas, no estaríamos protegiendo también la seguridad de la organización? Por qué en la ilustración montan la seguridad de la organización destruyendo la privacidad de los individuos?

Vistos los argumentos anteriores, el planteamiento clásico de seguridad Vs privacidad no tendría ningún sentido si no fuera por un aspecto importante, y es que la seguridad trata de proteger a la organización INCLUSO de sus propios miembros. La valla de la ilustración no está completa, ya que en realidad debería ser una valla doble con otro frente hacia el interior. Y es precisamente bajo ese planteamiento, consistente en que los propios miembros de la organización también pueden ser una amenaza, cuando tiene sentido que uno de los objetivos de la seguridad sea conocer lo mejor posible a estas potenciales amenazas, tratando de limitar por tanto la seguridad de las personas en favor de la seguridad de la organización.

Y precisamente es en este punto en el que quería plantear un par de reflexiones que me parecen importantes, aunque no sé si fáciles de responder. La primera es en torno al debate sobre las organizaciones y las personas que las componen. ¿Qué es lo que hay exactamente entre esas dos vallas, para que tengamos que protegerlo "contra" (y a costa de la privacidad de) los miembros de la organización? Y la segunda es sobre la forma de aplicar la seguridad. ¿Nos estamos planteando estrategias complementarias o alternativas de tipo "zanahoria" (recompensas, incentivos, etc.) en relación al personal de la organización, o sólo estamos planteando estrategias de tipo "palo" a la hora de aplicar la seguridad?

En definitiva, creo que el debate de seguridad contra privacidad no hace sino ocultar otros debates más profundos, como es el de la definición de las estrategias en las que basamos la aplicación de la seguridad, y en última instancia el eterno debate entre personas físicas y jurídicas y las consecuencias sociales de su disociación. No os parecen estos debates mucho más apasionantes?

Información, transparencia y limitaciones

Hoy se ha publicado en el BOE la esperada Ley 19/2013 de Transparencia. Para los habituales del blog no resultará nueva la relación entre el ENS y la Transparencia, ni creo que les sorprenda ver un post al respecto teniendo en cuenta que hace más de 3 años que esperaba poder publicar algo en este sentido. Por lo tanto, hoy tocaba postear algo, aunque sea breve...

Como positivo, esta Ley nos proporciona una especie de "catálogo" de información clasificable como pública, si hacemos un análisis de su Capítulo II:

• Información institucional y organizativa: Funciones del organismo, normativa aplicable, estructura organizativa, responsables (y su perfil y trayectoria profesional), etc. 
• Información de planificación:  Planes y programas, objetivos, actividades, medios y plazos previstos para su ejecución, resultados de todos ellos, etc. 
• Información de relevancia jurídica: Interpretaciones legislativas, proyectos legislativos y reglamentarios, memorias e informes, etc.
• Información económica y presupuestaria: Información económica del organismo (contratos, convenios, subvenciones, presupuestos, cuentas anuales, etc.) así como información económica asociada a los altos cargos (retribuciones, indemnizaciones, declaraciones de bienes, etc.
• Información estadística: Tanto de carácter económico como de funcionamiento, necesaria para valorar la calidad de los servicios prestados. 

También nos da una serie de criterios en base a los cuales deberíamos considerar la "confidencialidad" de la información que manejan los organismos públicos (junto a los "clásicos" como la seguridad nacional, la defensa o la seguridad pública se incluyen otros previsibles, como los aspectos relacionados con la comisión de ilícitos, las funciones administrativas de supervisión o los procesos judiciales, y otros que me parecen potencialmente polémicos, como los económico-comerciales o los medio-ambientales). Sin embargo, no se para a establecer niveles de criticidad en relación a estos criterios, indicando simplemente que dicha evaluación será específica para cada caso, justificada y proporcionada. 

Uno de los aspectos que más me ha llamado la atención es que no se habla expresamente de los procedimientos administrativos, ni en el "catálogo de información clasificable como pública" ni en la lista de limitaciones. Por lo tanto, la mayor parte de la información en poder de las administraciones públicas parece quedar al margen de estos "criterios" de clasificación.

Pero sobre lo que me gustaría incidir es sobre una limitación existente en torno al concepto de "clasificación" de la información, y es su carácter estático. El ENS nos "anima" a clasificar la información, a determinar si un determinado tipo de información es público, confidencial o secreto. Pero no podemos olvidar que esta clasificación puede variar a lo largo del tiempo. Un ejemplo de película podría ser la desclasificación de expedientes, por la que un determinado expediente X pasa a ser público transcurrido un determinado número de años. Otro más cercano podría ser la valoración de las ofertas asociadas a un contrato público, que sería confidencial mientras se están evaluando las ofertas pero pasaría a ser pública (información económica y presupuestaria) una vez que haya concluido el proceso de adjudicación.  Este tipo de situaciones no quedan bien contempladas dentro de los planteamientos del ENS, y la Ley de Transparencia pone más de manifiesto este tipo de situaciones. 

En definitiva, creo que la Ley de Transparencia, más allá de valoraciones de otro tipo, ha sido una oportunidad perdida para establecer un catálogo de referencia general para clasificar la información administrativa, y por lo tanto una cierta decepción para muchos organismos que podrían haber visto en esta Ley una importante ayuda para impulsar la adopción del ENS. Adopción que, por otra parte, no aparece ligada en ningún punto. No hubiera sido deseable que la seguridad de la información hubiera estado expresamente citada? Una pena...

De itSMF Euskadi al Congreso Nacional VISION13

El pasado día 24 de Octubre se celebró la I Jornada organizada por el comité regional de Euskadi de itSMF, titulada Presente y Futuro de la Gestión TIC en Euskadi. La jornada, con un gran éxito de asistencia (más de 120 asistentes creo que es una buena muestra del interés que despertó) fue la guinda al primer año de trabajo de este comité, al que auguro un gran futuro, vistos los resultados. 

Las principales conclusiones que pude sacar del evento son las siguientes:

• La cultura de los departamentos TIC sigue centrada en la tecnología. Aunque sus responsables empiezan a pensar en servicios, el cambio de mentalidad todavía no está asimilado.
• A causa de lo anterior, los planteamientos que se hacen sobre las nuevas modas del sector TIC (cloud, BYOD, BigData, ...) se siguen entendiendo bajo una visión técnica, sin mucha "orientación al cliente". 
• Se mide poco, no sólo porque sea difícil sino porque da miedo ver "cómo hemos salido en la foto". 
• El reto de los grandes departamentos de TI no es tecnológico, sino de gestión y coordinación. 
• La orientación al negocio sigue siendo algo a perseguir, pero que se ve muy lejos.

Algunas de estas conclusiones me han llamado mucho la atención, porque encajan bastante bien con la ponencia que voy a realizar en el congreso nacional de itSMF VISION13 el próximo día 11, a las 13:00 en la sala Plaza de Armas. En mi ponencia trataré de responder de forma sencilla (y un poco tajante, para qué negarlo) a preguntas como las siguientes: 

• Por qué los departamentos de TI le tienen tanto miedo al Cloud Computing?
• Cómo podemos dejar atrás definitivamente el problema de la "alineación con el negocio"?
• Por qué la piedra angular del departamento de TI debería ser el catálogo de servicios?
• Cómo encaja de manera natural el BYOD con la ISO 20000?
• Es posible diseñar un modelo de departamento de TI que integre todos estos problemas... sin morir en el intento?

Si alguna de estas preguntas suscitan tu interés... Nos vemos el próximo lunes. 

Publicada la nueva ISO/IEC 27001:2013

Tras un cierto tiempo ausente de este blog (espero recuperar mi ritmo de publicación habitual ahora que prácticamente he terminado con el Master que estaba cursando) me alegra poder comunicar que ayer se publicó la esperada nueva versión de la norma ISO 27001, varios días antes de lo previsto.

Esta nueva versión, pese a no introducir cambios demasiado significativos, puede suponer un nuevo impulso al desarrollo de la seguridad de la información, sobre todo desde el punto de vista de su integración y aceptación por parte de áreas típicamente alejadas del mundo de la seguridad. Esto se debe a que esta nueva versión de la norma está adaptada a los requisitos del Anexo SL, la nueva referencia de ISO para cualquier sistema de gestión. Esta adaptación supone que un SGSI tendrá exactamente la misma estructura que cualquier otro sistema de gestión normalizado por ISO, y por tanto será más fácilmente integrable con cualquier otro sistemas de gestión ya implantado en la organización.

Más allá de estos cambios, la versión 2013 de la norma ISO 27001 incorpora una nueva versión del anexo de medidas de seguridad,  en el que se ha modificado sobre todo la organización de los controles más técnicos y se han incluido dominios específicos para la criptografía y la relación con proveedores, a la vez que se ha reducido el número total de controles hasta los 113 (gracias sobre todo a la eliminación de controles redundantes).

En definitiva, un nuevo lavado de cara para una norma con bastante éxito y mucho potencial, que esperemos que sirva para que poco a poco las organizaciones se animen a mejorar la seguridad de su información.

Continuidad de los procesos de negocio y temporalidad

En muchas ocasiones, a la hora de hablar de procesos de negocio, nos solemos olvidar de un pequeño detalle que, sin embargo, es crítico desde muchos puntos de vista: su dimensión temporal. Obviamente, no todos los procesos de negocio tienen la misma duración, periodicidad ni frecuencia de ocurrencia. Los hay que duran segundos mientras otros duran días o meses. Hay procesos diarios mientras que otros muchos son mensuales o incluso anuales. Y por último, no es lo mismo un proceso que se desencadene (instancie, que dirían los programadores) 10 veces al día que uno que lo haga 1 vez al año... aunque ambos procesos tengan la misma duración y periodo.

Estas dos dimensiones temporales van a tener un peso fundamental a la hora de caracterizar los procesos de negocio. Estos aspectos son fundamentales cuando hablamos de Continuidad de Negocio, y sin embargo no se suelen explicitar a la hora de realizar un BIA (Business Impact Analysis, o Análisis de Impacto en el Negocio). De hecho, estos tres serían los parámetros fundamentales para evaluar la "degradación" que provocaría la materialización de una amenaza sobre un proceso de negocio, parámetro que combinado con el "valor" del proceso de negocio (su importancia para la actividad productiva de la organización) nos daría el "impacto" de dicha amenaza. Y si quisiéramos completar el estudio no tendríamos más que evaluar la "probabilidad" de ocurrencia de dicha amenaza y tendríamos como resultado el "riesgo" que supone esa amenaza para ese proceso de negocio, consiguiendo un análisis de riesgos completo.

Pero volvamos sobre el primer análisis. ¿Cómo podríamos parametrizar los procesos de negocio habituales de una organización? Simplificando mucho podríamos decir algo así como:

• Los procesos de venta son de duración muy variable, en función del producto/servicio vendido, pero en general podríamos pensar que están entre 1 día y 1 mes. No tienen una periodicidad pre-establecida, y su frecuencia de ocurrencia podría ir desde la diaria (o incluso menos) hasta muchas (a veces, miles) veces al día 
• Los procesos productivos son los de mayor variabilidad, ya que tendriamos desde los de duración de segundos (entrega instantánea de información, como los bancarios o los web) hasta los de duración de días e incluso meses (por ejemplo, la fabricación de maquinaria pesada). No tienen por qué tener una periodicidad establecida, y su frecuencia de ocurrencia depende mucho del producto/servicio producido y de la estrategia de producción (en cadena, en paralelo, secuencial, etc.).
• Los procesos de gestión económica podríamos pensar que tienen una duración de varios días, en general, una periodicidad mensual y una frecuencia de ocurrencia que puede ser diaria. 
• Podríamos pensar que los procesos de gestión de personal tienen en general una duración de varios días, una periodicidad variable (dependiendo de las características de la organización puede no tener periodicidad predeterminada) y una frecuencia directamente dependiente del tamaño de la organización. 

Esta caracterización de los procesos puede facilitar el diseño de diferentes estrategias de continuidad en función de la tipología de los procesos de negocio soportados. ¿Encajan vuestras estrategias de continuidad con un análisis de este tipo? ¿Son las soluciones adoptadas coherentes con este planteamiento? Ya tenéis tema para la reflexión...

Análisis de Riesgos para directivos

Muchos responsables de seguridad se quejan de que les resulta difícil conseguir que la dirección revise con detalle (y no hablemos ya de participar en su realización) los análisis de riesgos. ¿Hay alguna forma de conseguir que el ejercicio sea más "natural" para ellos? Creo que sí.

La propuesta que hago a continuación no es excesivamente ortodoxa, pero creo que puede servir para aproximar los análisis de riesgos a un colectivo como es el directivo que puede estar familiarizado con los conceptos que se tratan, pero que les cuesta usar la metodología "clásica". No obstante, los primeros que tendremos que hacer un esfuerzo seremos nosotros, que tendremos que dejar de pensar en riesgos de TI (o de cualquier otro ámbito) y empezar a pensar en riesgos de negocio.

Si hemos superado el primer obstáculo, el resto es sencillo. Sólo hay que seguir unos pequeños pasos que indico a continuación:

1. Identificar el "negocio" del ámbito que estemos analizando, listando los servicios que presta, o los procesos de negocio que desarrolla, o como queramos llamar a la actividad de negocio que desarrolla ese ámbito. 
2. Clasificar esos servicios en 3 niveles, en función de su importancia para la organización (llamémosle importancia alta, normal y baja). 
3. Realizar un análisis DAFO de cada uno de esos servicios, identificando sus Debilidades, Amenazas, Fortalezas y Oportunidades.
4. Valorar cada una de esas debilidades, amenazas, fortalezas y oportunidades en función de su importancia (llamémosle importancia alta, media o baja).  
5. Ahora sólo queda que alguien, a nivel más técnico, interrelacione debilidades (aka vulnerabilidades) y amenazas por un lado, y fortalezas y oportunidades por otro, multiplique el valor de cada tripleta (servicio-debilidad-amenaza y servicio-fortaleza-oportunidad)... et voila! Ya tenemos el análisis de riesgos.

Con este sencillo ejercicio, que para un directivo puede ser bastante más fácil de llevar a cabo que un análisis de riesgos "de libro", hemos conseguido tener un análisis de riesgos de negocio cuantitativo por un lado y un análisis de potencialidades (no he querido usar oportunidades, que ya se usa, y no se me ocurre un término mejor como antónimo de riesgo) por otro. De este modo no sólo reducimos la complejidad técnica que puede tener un análisis de riesgos, sino que lo aproximamos a la visión de negocio, tanto por utilizar metodologías más propias de este nivel como por desarrollar una visión "en positivo" del análisis de riesgos, al identificar no sólo riesgos a mitigar sino también potencialidades a favorecer, dentro del mismo análisis (de hecho, esta propuesta de análisis de riesgos en positivo ya la planteé en este mismo blog hace algún tiempo).

Obviamente, si lo que estamos buscando es un análisis de riesgos TI probablemente no encontremos bajo este planteamiento una solución válida, aunque... realmente el análisis de riesgos TI es un análisis de riesgos para directivos?