16 diciembre 2013

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?

10 diciembre 2013

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

06 noviembre 2013

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. 

26 septiembre 2013

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.

28 mayo 2013

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

13 mayo 2013

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?

02 mayo 2013

Atentado de Boston y APTs

Según se han ido sucediendo las noticias relativas al atentado de la Maratón de Boston y las averiguaciones posteriores no he podido evitar la tentación de establecer una analogía entre los hechos de Boston (o el terrorismo en general) y las APTs informáticas. Y la pregunta que surge a continuación es clave: ¿Es válido ese paralelismo? Y si fuera así... Podrían realimentarse ambos mundos?

Analicemos el paralelismo. Para empezar, el punto de partida de una APT es un "troyano" que conseguimos introducir en el sistema de la víctima. En el mundo físico, el sistema objetivo sería el entorno a atacar, en este caso Boston (o EEUU, cada uno que lo interprete como quiera). Las personas serían las aplicaciones que corren en ese sistema, y por lo tanto tendríamos dos formas de "infectar" el sistema: introduciendo directamente un software malicioso tipo "virus" (terrorista proveniente del exterior) o "troyanizando" una aplicación del sistema ("convirtiendo a la causa" a un ciudadano local, al más puro estilo homeland).

Al igual que en el mundo informático, los países están preparados para proteger el perímetro de la red (frontera) y controlar las entradas (firewalls), pero la capacidad de detección de terroristas externos que tienen estos sistemas es muy limitada, ya que generalmente se limita a firmas (identidades específicas que se chequean) y heurística básica (análisis de los datos del propio viaje -origen, destino, motivos del mismo, y cosas así). El resultado es que los "virus" sencillos se pueden llegar a detectar, pero las APTs más sofisticadas (personas "troyanizadas" o incluso malware durmiente con puertas traseras) suelen colarse. Además, al igual que en los sistemas de información, no sólo podemos infectarnos por la red. Los pendrives (inmigración ilegal o no controlada, cuerpos diplomáticos, etc.) también pueden llevar alguna aplicación maliciosa en su interior, consciente o inconscientemente.

En el mundo TIC se suelen poner sistemas IDS en la red interna, para tratar de detectar ataques que hayan podido superar la protección perimetral. Sin embargo, en el mundo físico no hay (oficialmente) demasiados recursos destinados al "espionaje" interno, más allá de la labor policial habitual. En cualquier caso, normalmente un IDS tampoco suele ser capaz de detectar la actividad de una APT...

Las APTs son difíciles de detectar porque su actividad es esporádica. Suelen ser aplicaciones "durmientes", que realizan una actividad aparentemente normal (o ninguna) hasta que, por un motivo determinado, activan su payload malicioso y lo ejecutan, realizando la fechoría en cuestión. Este funcionamiento es muy similar al de cualquier célula terrorista, y la dificultad de su detección estriba en identificar el detonante para su activación, que potencialmente puede ser cualquier cosa. Las autónomas pueden activarse con una cuenta atrás, un hito específico, una fecha, etc., mientras que otras dependen de la recepción de una orden externa desde un nodo de comando y control (C&C). Estas son algo más detectables, pero también mucho más flexibles, ya que pueden ser reprogramadas. En cualquier caso, esas comunicaciones llevadas al mundo físico son prácticamente imposibles de detectar, dada la infinidad de medios existentes y la poca capacidad de supervisión de los mismos.

Y por último, las APTs actúan. Roban la información, hacen estallar la bomba... Este suele ser el momento en el que son detectadas, cuando el incidente se materializa. El problema es que en este momento ya no sirve de nada, su acción no ha podido ser evitada. En ese momento es cuando empieza la "desinfección"... si es que han sido detectadas. Si no es así, podrán continuar con su actividad.

Hasta aquí la exposición. Ahora vuelvo a lanzar la pregunta, para la que no tengo respuesta. ¿Puede servir el conocimiento adquirido en cualquiera de ambos mundos para mejorar la lucha contra amenazas físicas y cibernéticas? Hay algún tipo de iniciativa de colaboración en este sentido? Seguro que un buen guionista sabe cómo hacerlo...

16 abril 2013

Publicada la norma UNE 71020:2013 - Modelo incremental para la ISO 20000

La semana pasada se publicó la norma española UNE 71020:2013 - Modelo de conformidad incremental basado en la norma UNE-ISO/IEC 20000-1.

Esta norma es, en resumidas cuentas, un modelo de adopción de la norma ISO 20000 por niveles, que establece dos niveles intermedios antes de llegar a cubrir todas las exigencias recogidas en la ISO 20000-1.

Mucho ha llovido desde que se empezó a hablar de la ISO 20000 por niveles. Yo mismo valoraba esta posibilidad allá por 2008, como una vía para "aligerar" la adopción de la ISO 20000 sobre todo para las PYMEs. Y sin embargo, el tiempo, que es en el fondo quien puede dar o quitar la razón, en este caso me la ha quitado. No sólo es que la mayor parte de empresas certificadas en España en ISO 20000 sean PYMEs, sino que he vivido de forma directa la experiencia de la adopción de la ISO 20000 en múltiples PYMEs y os puedo asegurar que en absoluto han necesitado un modelo de este tipo.

Y en ese caso, cuál es el motivo de que haya seguido adelante el desarrollo de esta norma? Pues desde mi punto de vista el argumento principal es precisamente el contrario, las grandes empresas. Los cambios organizativos y operativos que requiere la adopción de un sistema de gestión de servicios certificable bajo ISO 20000 son infinitamente más sencillos de realizar en una PYME que en un gran departamento de TI, tanto por flexibilidad interna como por posibles impactos en los servicios prestados, más críticos cuanto mayor sea su dimensión. Para estos casos, la existencia de niveles intermedios "oficiales" puede suponer una gran diferencia a la hora de subdividir los proyectos y tener metas intermedias que impulsen un proyecto de cambio que bajo otro planteamiento puede ser excesivamente complejo. No perdamos de vista que el hasta ahora gran éxito de los proyectos ITIL en grandes corporaciones se basaba precisamente en éso, en abordar proyectos más pequeños y específicos, y por tanto con resultados más rápidos y tangibles.

Por otro lado, creo que este modelo de referencia puede ser muy útil para organizaciones que, sin tener un departamento TIC demasiado potente, cuenten con un cierto grado de madurez en su gestión interna corporativa y quieran mejorar la calidad de sus TIC sin encorsetarse demasiado. Estoy pensando, sobre todo, en empresas del sector industrial y productivo en general, en los que las TIC "apoyan" al negocio pero no son el "core" del negocio. En este tipo de organizaciones, plantearse un nivel 1 de madurez puede ser una meta mucho más interesante que la de desarrollar un sistema de gestión de servicios completo y certificable...

Por qué digo esto? Echándole un vistazo a los niveles (visión simplificada y "redondeada") creo que quedará más claro:

  • Nivel 1 = Núcleo del Sistema de gestión (básico) + Seguridad (básico) + Proveedores + Incidentes + Problemas + Configuración (básico) + Cambios (básico) + Entregas (básico).
  • Nivel 2 = Núcleo del Sistema de gestión (completo) + Seguridad (completo) + Niveles de servicio + Informes + Continuidad y disponibilidad (básico) + Financiero + Capacidad + Proveedores + Clientes (básico) + Incidentes + Problemas + Configuración (completo) + Cambios (completo) + Entregas (completo).
  • Nivel 3 = ISO 20000 completa (se completan todos los procesos y se añade el diseño y transición de servicios.
Así que ya sabéis, si queréis profundizar un poco más en este planteamiento de la ISO 20000 por niveles... ya tenéis un estándar a vuestra disposición. 

02 abril 2013

Herramientas para ISO 20000

Una de las dudas más habituales a la hora de pensar en la ISO 20000 suele ser la de si es necesario disponer de herramientas específicas para su implantación. Y aunque la respuesta "de libro" debiera ser que no, la realidad es que en muchos casos se hace casi imprescindible disponer de alguna herramienta que facilite las tareas a realizar, sobre todo si queremos ser eficientes y eficaces a la hora de realizarlas. Otra cosa muy diferente sería valorar qué herramientas en cuestión se pueden utilizar, ya que hay desde herramientas gratuitas y de código libre hasta herramientas con precios al alcance de sólo unos pocos privilegiados, cada una de ella con sus ventajas y sus inconvenientes. Pero como no pretendo llegar a eso, a continuación va un listado de "tipos" de herramientas que se pueden utilizar, y para qué ámbitos son útiles:

  • Herramientas de monitorización: Son prácticamente imprescindibles para los procesos de gestión de la capacidad y gestión de la continuidad y disponibilidad, ya que permiten monitorizar de forma automática la disponibilidad y capacidad de los sistemas. Además, pueden facilitar los procesos de gestión de niveles de servicio y de informes, en función de los parámetros en base a los cuales hayamos definido la calidad de nuestros servicios. 
  • Herramientas de ticketing: Aunque la gestión de incidentes y peticiones de servicio pudiera hacerse de manera cuasi-manual, la utilización de una herramienta de ticketing se hace prácticamente imprescindible en el momento en el que queramos automatizar dicha gestión y sobre todo obtener indicadores de dicho proceso. En función de los parámetros en base a los que hayamos definido la calidad de nuestros servicios, estas herramientas también pueden facilitar los proceso de gestión de niveles de servicio y de informes. Además, en muchos casos la gestión de problemas también se automatiza mediante la misma herramienta de ticketing, incrementando su utilidad. 
  • Herramientas específicas para CMDB: Aunque una CMDB se podría implementar con una base de datos relacional normal y corriente, las herramientas específicas para CMDB facilitan tanto el trabajo que su utilización acelera enormemente la implementación del proceso de gestión de la configuración, haciéndose muy aconsejables si no imprescindibles. Además, estas herramientas normalmente suelen tener capacidad para integrarse con las herramientas de ticketing, incrementando enormemente su funcionalidad. 
  • Herramientas de soporte a la gestión: Aunque no sean imprescindibles, cada vez están surgiendo en el mercado más herramientas que implementan diferentes procesos de la ISO 20000, normalmente bajo un planteamiento ITIL-compliant. Este tipo de herramientas facilita la gestión de los procesos, y sobre todo mejora enormemente la capacidad de gobierno de los mismos, gracias a su potencial de obtención de indicadores y métricas asociadas. 
  • Herramientas de inventariado automático: No son herramientas imprescindibles para la ISO 20000, pero las herramientas de auto-descubrimiento e inventariado de la infraestructura TIC facilitan la gestión de los activos, sobre todo en los casos en los que la infraestructura TIC es numerosa. Además, las herramientas de CMDB suelen tener interfaces con estas, facilitando la gestión de la configuración
  • Herramientas de administración TIC: Tampoco son herramientas imprescindibles para la ISO 20000, pero al facilitar la administración centralizada de la infraestructura (sistemas y/o comunicaciones) permiten una implantación más sencilla y eficaz de los procesos de gestión de la configuración y gestión de la entrega. Además, este tipo de herramientas suele permitir su integración con otras señaladas anteriormente. 
En definitiva, las herramientas "clásicas" en la gestión TIC facilitan la adopción de un Sistema de Gestión de Servicios certificable bajo ISO 20000, y muchas de ellas han ido evolucionando e incorporando los módulos específicos necesarios para cumplir con las exigencias de la ISO 20000, o al menos definiendo las interfaces necesarias para su integración con este tipo de herramientas. A día de hoy ya existe un amplio y completo catálogo de soluciones, de modo que el uso de este tipo de herramientas sólo dependerá de cada organización, y de la selección que quiera hacer en función de sus intereses y posibilidades.

26 febrero 2013

Las dashcam y la LOPD

Seguro que a estas alturas todo el mundo ha visto alguno de los vídeos en los que aparece el meteorito que la semana pasada cayó en Rusia. Y la grabación de estas imágenes ha sido posible porque parece que en Rusia son muy habituales las dashcams, o cámaras de parabrisas, que son unas cámaras que se instalan en el interior del coche para ir grabando lo que sucede delante de nosotros mientras vamos conduciendo.

Reconozco que la idea de tener una dashcam se me ha ocurrido en innumerables ocasiones, incluso antes de conocer su existencia, sobre todo cuando el conductor de delante te hace una pirula y piensas "si esto se hubiera grabado, menudo puro le iba a caer". Por supuesto, en mi imaginación las dashcams eran mucho más completas, por éso de la deformación profesional:   Módulo GPS integrado para posicionamiento y fechado de fuente externa, memoria read-only para evitar la manipulación de las grabaciones, sistema completo certificado por Common Criteria...   Vamos, un sistema totalmente inexpugnable a nivel legal. No vaya a ser que el de la pirula se libre!

No obstante, puestos a ser realistas, y teniendo en cuenta que en la práctica probablemente no fuese necesaria tanta fortaleza legal para que la grabación en cuestión fuese admitida en un juicio corriente, la idea de la dashcam actual parecería suficiente. Sin embargo, me asalta una duda legal: ¿Es compatible la idea de la dashcam con nuestra LOPD?

Por un lado, parece que la videovigilancia debería ser la última solución, y no tengo claro si en este caso se podría considerar un medio excesivo. Por otro, entiendo que quien tuviera una dashcam debería llevar pegado el cartelito amarillo en el parabrisas (sería gracioso encontrarse con un coche así, la verdad). Pero la duda que más me asalta es la relacionada con la aplicabilidad de la LOPD. Mi idea general simplificada era, básicamente, que la LOPD no aplicaba a personas físicas, por aquello del Artículo 2.a. Sin embargo, hay resoluciones y sentencias que sancionan a personas físicas por grabar el exterior. ¿Es por el "exclusivamente personales o domésticas"? Al final, no me termina de quedar claro...

¿Hay algún jurista en la sala capaz de aclararme si podré instalarme una dashcam?

01 febrero 2013

La LOPD lo permite TODO

En los últimos meses estamos asistiendo a una creciente aparición en prensa de una gran diversidad de documentos que destapan multitud de escándalos: Gürtel, Noos, Bárcenas, ... En todos ellos acaban publicándose documentos cuasi-privados en los que aparecen, como era de esperar, datos personales, entre otra información.

Ante estos hechos ya empiezan a aparecer, y cada vez con más volumen, posicionamientos en contra de la publicación de este tipo de documentos argumentando para ello la protección que la LOPD otorga a este tipo de información. ¿Se puede o no se puede, desde el punto de vista de la LOPD, publicar esa información?

Partiendo del planteamiento de interés legítimo, apoyándome en argumentaciones mucho más consistentes que las que pueda hacer yo, y sin olvidarme del derecho a la información, entiendo que estos argumentos carecen de rigor jurídico, y que no hay ningún problema para publicar este tipo de documentos pese a que incluyan datos personales.

No obstante, el objetivo del post de hoy no era el de profundizar en si se puede o no se puede publicar esa información, sino recordar que LA LOPD LO PERMITE TODO. Así, en mayúsculas. ¿Se pueden publicar datos personales de nivel alto en Internet? SI. ¿Se pueden difundir a los cuatro vientos, por cualquier medio? Por supuesto que SI. Lo único que necesitamos es el consentimiento del afectado.

De hecho, tendríamos que estar aburridos de ver publicados y difundidos datos personales de nivel alto sin el más mínimo problema. ¿Acaso la pertenencia de Mariano Rajoy al Partido Popular no es un dato personal, y de nivel alto? ¿O que Jesús Vázquez sea gay? Por supuesto que sí. ¿Están vulnerando la LOPD quienes lo publican? Claro que no. Simplemente, tienen el consentimiento del afectado.

En resumidas cuentas, la LOPD permite algo tan "duro" como publicar en Internet o a través de cualquier medio de comunicación el historial médico completo de cualquier persona. Tan sólo necesitamos su consentimiento explícito para difundirlo de forma indiscriminada a toda la sociedad. ¿Somos capaces de conseguirlo? Entonces la LOPD lo permite. Otra cosa es que no contemos con dicho consentimiento...

En definitiva, lo que quiero transmitir con esta "reducción al absurdo" es que la LOPD no tiene por qué ser impedimento para nada. Por lo tanto, no hagamos de la LOPD la excusa para no publicar una cierta información, cuando en muchos casos el motivo principal suele ser otro bien distinto...

24 enero 2013

Conceptualizando en Gestión de Crisis y Resiliencia

El post de hoy no está escrito por mí, es una contribución de Jose Miguel Sobrón, miembro de ASIS International y el responsable de la Unidad de Sistemas de Gestión de Resiliencia Organizacional del Department of Safety and Security de Naciones Unidas. Espero que os guste!
Esta es la era de la preparación (preparedness era) hay que estar listos para todo lo que venga. Antes éramos reactivos y ahora somos proactivos. Ahora además tenemos que ser resilientes, para todo también. En toda esta tendencia y obsesión por “estar listos”, ¿qué pasa con continuidad de negocio? ¿Y con gestión de crisis?
A veces la rutina nos confunde y nos hace olvidar el significado real que a las palabras damos, y el porqué de ese mismo significado. Esta es una confusión o polémica muy habitual sobre el huevo y la gallina, o lo que es lo mismo, si fue antes Continuidad de Negocio o Gestión de Crisis o viceversa, o cual de las dos regula a cual.
Si hay algo que esta arrasando en todas las grandes corporaciones a nivel mundial y que se está extendiendo como la pólvora, eso es el concepto de Resiliencia, definida de mil maneras, pero simplificándola a cualquier áreas de estudio, como capacidad de resistir cualquier impacto y conectarlo con las maneras posibles de volvernos a levantar y continuar. Así es en multitud de áreas. Recomiendo por lo exquisito y extenso del estudio un análisis muy concienzudamente detallado llevado a cabo por el US Department of Homeland Security (DHS, grosso modo nuestro Ministerio del Interior) en el Journal ofHomeland Security and Emergency Management, vol 6, Issue 1-2009-Art 83.
En este nuevo mundo global de Resiliencia Corporativa (Organizational Resilience) existe mucha confusión creada a veces por intereses obvios de mercado e influencia de varias tendencias y a veces solo por confusión de la terminología. Si inicialmente el primer paso de gigante en continuidad lo dio la presentación del BS25999 (1-2), el modelo que integraba todo bajo BCM (Gestión de continuidad de negocio) no cubre todas las áreas, a pesar de tener un amplio apoyo y marco experimental en Reino Unido, la misma Unión Europea y algunos países. Es más, vista la escasa acogida actual y la reorientación del mercado hacia la familia ISO 31000 e ISO 28000, los grandes defensores del modelo británico han reaccionado con celeridad y han aunado fuerzas con ASIS International (que sigue el modelo ISO) para elaborar un producto de Gestión de Continuidad de Negocio (Business Continuity Management) “conjunto”, suma de las dos tendencias, para crear una sola alrededor de las familias de estándares de ISO (ASIS/BSI Business Continuity Management Standard - 2010). Sabia elección, porque siempre es mejor aunar que litigar. Muchos de los que practican el modelo británico se han visto y se ven en una situación incómoda, por aquello de que a todos nos cuesta un trocito de ego reconocer que hay que tomar otro camino contrario o diferente al que practicábamos desde hace un tiempo. Merece la pena dejar el ego atrás, sin duda.
El modelo basado en ISO 31000 es mucho más integral y explora un marco que no deja resquicio alguno. Además es relativamente multinacional y compila el esfuerzo inicial australiano y neozelandés, con el impulso del Sudeste Asiático y el reciente apoyo incondicional de Estados Unidos y la mayor parte de países europeos.
En ese marco de ISO 31000 la Gestión de Crisis sí es el pilar fundamental, que no el único, y los demás son absolutamente no solo necesarios sino completamente complementarios. En el ámbito de ISO31000 y en íntimo contacto se localiza el impulso creado y mantenido por ASIS International para Resiliencia Corporativa (acabamos de publicar el ultimo estándar aprobado por ANSI sobre el modelo demadurez de Resiliencia Corporativa). En ese paraguas monumental que es la Resiliencia, cabe todo, pero hace falta un hilo conductor que lo regule y coordine, y ese hilo conductor debe de estar en lo más alto de la cadena de Mando o Gestión si lo preferís.
Empezaré explicando por qué cuando acudimos a la definición se ve mucho mas claro el concepto. Al hilo de esto, permitirme de nuevo recomendaros un sumario sobre el PAS (Publicly Available Section) 200:2011 Crisis Management-Guidance and Good Practice llevado a cabo por Regester Larkin, que recoge bastantes puntos interesantes y también críticos sobre el estudio de Reino Unido (el PAS completo es de pago y creo que cuesta alrededor de 100 libras esterlinas).
Gestión de Crisis como su propio nombre indica hace referencia a dos cosas absolutamente claras en cualquier organización por grande o pequeña que sea: Gestión conecta con el Jefe Ejecutivo o el Consejo Directivo o los dos; y Crisis es una palabra que hemos desgastado y contaminado de tanto usarla. Una crisis no es un incidente ni un problema, es una situación muy, pero que muy complicada que se desarrolla en un ambiente inestable, complejo e inesperado, de desconocidas consecuencias (a veces “black swans”) y que pone en alto riesgo cualquiera de nuestros activos o pasivos más importantes, nuestras instalaciones y personal y nuestra reputación; y por ende hace peligrar la existencia de la propia organización en su estado actual. Podéis hacer una comparativa en uno de los últimos papeles de Marzo del BCI (CM What is and howis it delivered, 2012 BCI).
Las crisis, como los riesgos, no son malas por naturaleza, pueden serlo si nos pilla sin preparar pero pueden ser grandes oportunidades en las que fortalecer y consolidar los cimientos de la Resiliencia Corporativa. Os dejo un link de una definición escalable de cómo Gestión de Crisis conecta conResiliencia Corporativa, que hace poco llevamos a cabo cuando colabore con un par de buenas amigas del Fondo de Población (UNFPA) para finalizar su Plan de Continuidad de Negocio.
Todos tenemos problemas, pero de eso a una crisis hay un trecho, distancia que a veces no queda clara por falta de definición. Se trata en definitiva de una escala temporal que comienza con la localización un problema de desconocido impacto y consecuencias. El problema original se convierte en incidente cuando requiere una intervención de nuestro mecanismo de –primera- respuesta sea el que sea. Cuando la cosa se pone fea y parece ser que el sexto sentido del que responde le dice que esto no tiene muy buena pinta, pues ¿que hace?, lo de siempre, llama al jefe. Y el Jefe es quien declara si hay o no hay crisis. Eso ha sido así contado un poco en “Román paladino” o español de andar por casa.
En el Sistema de Gestión de la Resiliencia Corporativa (ORMS del inglés), el Sistema de Gestión de Incidentes (Incident Command System, ICS; que es básicamente nuestro servicio de seguridad y/o de emergencias internas, incluyendo médicos, psicólogos, encargados de instalaciones y recursos humanos de apoyo) se encarga de estimar la cuantía y calidad del impacto recibido (irrelevante, limitado, relevante, severo y extremo/critico). En cuanto tiene una somera idea de ello, determina si lo puede solucionar por si mismo, lo debe de monitorizar y avisar a alguien para alertar por si acaso o lo lanza al siguiente o más alto supervisor si se trata de un problema grave o gravísimo. También el ICS dispone de mecanismos que son automáticos, como evacuaciones sanitarias, evacuaciones de edificios, et al. que basados en determinados protocolos no precisa de autorización previa por la emergencia de que se trate.
Esto pone en alerta a los mecanismos de gestión de crisis que se preparan para lo peor y esperan lo mejor. Estos mecanismos o están en si mismos compuestos por los mas altos directivos o tienen línea directa con ellos y el consejo de Dirección. Una vez declarada la crisis por la autoridad interna que corresponda, sea el CEO o el equipo de gestión de crisis (CMT), se determinan las medidas a llevar a cabo: seguir monitorizando, activar el plan de continuidad (business continuity), recuperación de desastres (IT Disaster Recovery) o lo que haga falta en función de la situación. Hemos pasado en poco tiempo de un problema a un desastre o incluso una catástrofe. Estos dos últimos en realidad se ven venir inmediatamente, no los eventos en si mismos que son impredecibles pero si sus consecuencias y la magnitud del impacto recibido. Por eso hay que prepara mecanismos que disminuyan al mínimo la respuesta inicial, por limitada y exigua que sea, y que aceleren la integración del modo crisis en el mecanismo de gestión integral. Aquí se hace ver la valía de conectar y coordinar la preparación mediante un marco global como es la Resiliencia Corporativa. Rompemos los silos en la preparación y estamos preparados para la respuesta.
Con todo lo anterior vemos que aunque haya procesos que puedan automatizarse y producirse en aislamiento, el flujo regular obliga a pasar de un escenario a otro escalable en envergadura desde el ICS hasta Gestión de Crisis, y es Gestión de Crisis (conectado al mas alto escalón de mando) quien activa Continuidad o recuperación de desastres e indica como se van a llevar a cabo y cuales operaciones de recuperación, así como la relocalización si fuera precisa.
La conclusión final nos lleva a determinar que efectivamente gestión de crisis juega un papel de coordinación que facilita enormemente la toma de decisiones al más alto nivel y que encaja a la perfección con el concepto de Resiliencia Corporativa. Esto no desmerece en absoluto el papel indispensable que ha jugado la Continuidad de Negocio desde los 90 y las enormes contribuciones que han permitido madurar el modelo hasta el estado actual. Desde el entorno de respuesta inmediata de un negocio de pequeña o mediana entidad, las barreras o diferencias entre gestión de crisis y continuidad de negocio siguen siendo muy difusas o difíciles de identificar, en grandes empresas o instituciones la cosa esta muy clara, la apuesta es resiliencia.

22 enero 2013

La caza del Octubre Rojo

No voy a hablar de la película cuyo título se corresponde con el de este post, por mucho que Sean Connery sea uno de mis actores preferidos, pero he de reconocer que el "virus" descubierto  públicamente estos últimos días, bautizado como "Octubre Rojo", me ha recordado a la película por más motivos que por la simple coincidencia en el nombre: el papel de las instituciones gubernamentales, la capacidad del "virus" para permanecer sumergido en los sistemas... Un material que bien podría servir como argumento para una típica peli de espías hollywoodense.

Sin embargo, mi intención no es analizar las características de la película ni sus coincidencias con este malware en particular, sino hacer una pequeña reflexión acerca de este tipo de malware avanzado, forma tangible de las cada vez más conocidas APTs (Advanced Persistent Threats, o amenazas persistentes avanzadas).

En el fondo, todas las APTs funcionan de la misma forma. Un pequeño malware llega al destinatario, consigue ser ejecutado (por utilización de alguna vulnerabilidad del equipo o simplemente engañando al usuario) y se instala en el equipo de la víctima. A partir de ese momento, ese pequeño malware se dedica a conectarse periódicamente a una serie de servidores en Internet, los centros de control (conocidos como C&C, o Command and Control), desde los que se reciben las órdenes de las actividades maliciosas a llevar a cabo y/o a los que se envía la información recopilada.

En primer lugar me gustaría hacer una observación acerca del papel de los antivirus frente a este tipo de ataques. Obviamente, el software anti-malware es de propósito general, y su objetivo no es identificar ataques dirigidos y personalizados, como suelen ser (en distinto grado) las APTs. No obstante, el comportamiento básico de este tipo de malware es bastante similar en todos los casos, y se basa en actuar  como puerta trasera. ¿No sería posible hacer un esfuerzo especial en identificar este tipo de patrón de funcionamiento? Siendo consciente de la dificultad que puede suponer, creo que este es uno de los ámbitos en los que más se puede incidir en un futuro cercano.

Creo que también es destacable una de las características del "Octubre Rojo": el nivel de personalización (más allá de los destinatarios) del vector de infección (unos archivos en excel y word) era bastante bajo. O dicho de otro modo: esos mismos archivos podrían haber ido dirigidos a cualquiera. ¿Es la sociedad consciente de la existencia de esos ataques?

Redundando en la pregunta anterior, creo que también es destacable que el objetivo potencial del "Octubre Rojo" era prácticamente todo tipo de información que tuviera el usuario. ¿Somos conscientes de que TODA la información que tenemos en nuestro equipo es objetivo potencial de un atacante?

Por último, creo que también es destacable la modularidad del "Octubre Rojo", y su capacidad para cargar, ejecutar y eliminar de forma dinámica diferentes módulos con finalidades diversas, una vez realizas las acciones correspondientes. Me temo que ese planteamiento va a estar cada vez más extendido entre el malware moderno, de modo que cada vez será más complicado su identificación. Está preparado el mercado antimalware para hacer frente a software malicioso de estas características?

En definitiva, creo que la caza del Octubre Rojo puede ser una de las primeras batallas que tenga que lidiar la industria del antimalware a los ojos de la luz pública, y posiblemente sus resultados nos sirvan para hacernos una idea de la capacidad real de la sociedad para hacer frente a este tipo de amenazas. ¿Conseguirán cercar y dar caza al Octubre Rojo? ¿O conseguirán sus tripulantes alcanzar sus objetivos (si no lo han hecho ya)?