29 mayo 2007

Procesos y procesos

A menudo me suele pasar que termino enfrascado en "discusiones" filosóficas sobre el sexo de los ángeles. Una de las habituales suele ser sobre qué es un proceso, y aunque parezca algo sencillo, os puedo asegurar que la discusión da mucho de sí.

El problema, en realidad, no está en la definición del concepto. Creo que referencias ya señaladas, como esta, aclaran bastante bien el término y sus implicaciones. A priori son conceptos sencillos de entender y fáciles de diseñar. Y sin embargo, son conceptos difíciles de acotar a la hora de hablar de ellos de forma genérica.

El problema de definir adecuadamente un proceso, desde mi punto de vista, es su dimensionamiento. Todos hablamos de macroprocesos, sistemas de procesos, procesos "a secas" y subprocesos utilizando el término genérico "proceso". Y aunque este abanico de términos sí que se puede usar para dar una idea del "tamaño" de los procesos a los que se refiere, nada nos asegura que su interlocutor los esté dimensionando de la misma forma, ya que no hay "tamaños de proceso" de referencia.

Creo que un ejemplo puede servir para ilustrar el problema. Es muy habitual que, en el mapa de procesos de muchas organizaciones, haya uno denominado "gestión de sistemas de información" (o similar). Recoge, en definitiva, las actividades de "los informáticos" de la empresa. Pero resulta que, si pensamos en ITIL, por ejemplo, tenemos definidos 10 procesos a desarrollar dentro del que ya teníamos. 11 si contamos con el de gestión de la seguridad en los términos de ITIL. Pero resulta que la gestión de la seguridad también puede ser un proceso de "gran tamaño" si pensamos en una organización con un SGSI implantado cuyo alcance sea toda la compañía...

Este problema, ya sea de terminología o conceptual, se puede agravar si pensamos en la estructura de procesos de algunas organizaciones. Porque muchas de ellas tienen implementada una "gestión por procesos" concebida como una ISO 9001 "avanzada" (una especie de ISO 9001 + ISO 9004 parcial). El problema es que, en muchos casos, la "evolución" de la ISO 9001 ha sido sencillamente adaptar a "formato proceso" los procedimientos ya desarrollados, e integrarlos de la mejor forma posible en el mapa de procesos. Con lo cual es fácil encontrarse con un mapa de procesos en el que aparecen procesos del tipo "gestión de las compras" con otros del tipo de "proceso de ajuste del grosor de la lámina", que no hacen otra cosa que agravar esta falta de criterio a la hora de dimensionar los procesos.

Si ahora pensamos en implantar un sistema de gestión (de calidad, de seguridad de la información, o cualquier otro) cuyo alcance se define "por procesos", podemos encontrarnos con que el problema ya no es sólo de terminología. ¿Es lo mismo establecer un SGSI, por ejemplo, para el proceso de "gestión de sistemas de información" que para el subproceso ITIL de "gestión de cambios"? Parece evidente que no. Y yendo un poco más allá: ¿Tiene sentido pensar en establecer un SGSI para el "proceso de ajuste del grosor de la lámina", que consiste en que un operario ajuste una tuerca hasta que el grosor de la lámina sea 'X'? A priori, y teniendo en cuenta que en los tres casos podemos estar hablando de un alcance "de un único proceso", todas las opciones podrían parecer similares. Y está claro que no lo son...

La solución creo que debería pasar por estandarizar (o formalizar, al menos) una terminología que permita determinar el "tamaño" de los procesos. No tengo claro si el término "proceso de negocio" podría servir para definir los procesos de "primer nivel" del mapa de procesos, o si quizás pueda llevar a confusión con otras clasificaciones de procesos (operativos/estratégicos/de soporte). Lo que sí me parece imprescindible es conseguir llegar a una terminología común para todos los que trabajamos con este tipo de conceptos. No sea que nos terminemos encontrando con clientes que quieran establecer sistemas de gestión "completos" (certificables) para procesos del tipo del "proceso de ajuste del grosor de la lámina", o con empresas que les quieran vender esa posibilidad...

28 mayo 2007

Avances LOPD

Parece que el nuevo reglamento para la LOPD sigue su avance (lento, muy lento, pero avance al fin y al cabo). Aunque desde hace más de tres meses no había habido nuevas noticias al respecto, parece que la tramitación sigue su avance. Si hace unos días Martín Pérez anunciaba en su blog que el ministerio de justicia había enviado el borrador del nuevo reglamento a ASIMELEC para que desde esta organización lo valorasen, el pasado viernes fue la Asociación de Internautas quien publicó sus comentarios en relación a dicho documento. De estos comentarios quiero quedarme con dos detalles, que me parecen de particular relevancia:
  • El nuevo reglamento debería dejar claro (comentario -c)-) el tratamiento que se ha de dar a la información recabada desde Internet. Probablemente sea la fuente de información más utilizada a día de hoy, y si no es así es seguro que lo será en un breve lapso de tiempo. Por lo tanto, me parece totalmente imprescindible que el nuevo reglamento regule el trato que se debe dar a estos datos, que hasta la fecha tantos quebraderos de cabeza dan a algunas organizaciones a la hora de pensar en tratar datos recogidos de estas fuentes.
  • La conclusión que hace la Asociación de Internautas me parece fundamental. No tenemos que olvidar que la LOPD es una ley difícil de interpretar en algunos apartados, y por lo tanto el reglamento no debería ser únicamente una referencia para su aplicación práctica, sino también un lugar en el que se aclaren, acoten y delimiten, al menos, las principales indefiniciones contempladas en la ley, con el fin de disponer de un marco legislativo más completo que el actual. Ahora que ya llevamos unos años lidiando con el anterior reglamento, creo que un documento que complemente adecuadamente a la Ley también debería servir para no tener que depender tanto de las resoluciones de la AEPD a la hora de depurar la aplicación de la ley.

Espero que no sólo la Asociación de Internautas nos obsequie con la publicación de sus comentarios respecto al borrador del nuevo reglamento. Así será más fácil para todos ir viendo los derroteros de este esperado (temido?) documento.

24 mayo 2007

Más que una moda

La seguridad informática es algo más que una moda pasajera. Empezó por ser una preocupación de organismos relacionados con la "seguridad" civil, de ahí pasó a las grandes multinacionales, posteriormente a las regulaciones y leyes nacionales de los países, y de ahí de nuevo a las empresas, aunque en este caso alcanzando a todo el tejido empresarial. Una evolución clásica, e incluso lógica, diría yo. Difundiéndose desde los sectores más "paranoicos" de la sociedad y en todas direcciones, a través de los entramados económicos y políticos de la sociedad moderna.

Sin embargo, el motivo de esta difusión no es símplemente económico o político. De fondo está motivada por la necesidad de que la seguridad informática se vaya extendiendo progresivamente, porque la inseguridad informática avanza a grandes pasos (y aquí sí que pueden ser más visibles los intereses políticos y económicos, tal y como nos recuerdan los expertos). Algo de esa necesidad hay en la última decisión de la Comisión Europea, que ve con preocupación el continuo crecimiento de los delitos informáticos. Un crecimiento que, sin conocer las propuestas que se presenten a final de año, tengo muchas dudas de que se consiga paliar de forma efectiva con este tipo de medidas. Y el motivo es sencillo: creo que hasta el momento ningún gobierno ni institución ha sabido encontrar una solución que permita que medidas como las que se puedan asociar a la seguridad informática den el último salto: de las empresas a las personas. Este punto, en el que confluyen la vía política y la económica, es la clave para conseguir que cualquier tipo de medida de seguridad informática sea realmente efectiva, y sin embargo es el punto al que en muy pocas ocasiones se consigue llegar.

Cuando intento explicar a algún profano en la materia de qué trata esto de la seguridad informática, siempre le pido que piense en una gran ciudad. Tiene su zona de negocios, su calle con boutiques de última moda, su casco histórico, sus colegios... Pero también tiene sus barrios de chabolas, sus parques mal iluminados, sus bandas callejeras o su barrio rojo. Y todo el mundo tiene muy claro qué se puede encontrar en cada zona, a qué horas no es aconsejable pasear o con qué tipo de gente no se quiere juntar. El problema es que en Internet los barrios de chabolas son tan elegantes como la zona de negocios, no hay zonas mal iluminadas y todo el mundo tiene el mismo aspecto. Y además en esta ciudad "está de moda" ir de "chico malo", y ser de los que "trapichean" con SW o de los que tienen su PC "tuneado" con los widgets más exclusivos.

En resumen, creo que nuestros instintos no nos sirven en Internet, y por eso la mayor parte de la sociedad está tan expuesta a los riesgos de esta "ciudad". Porque la evolución no nos ha preparado para un mundo virtual, y suplir nuestros instintos con formación y concienciación "digital" es una tarea enormemente compleja y prácticamente inabordable. Por eso creo que la seguridad informática debe ser algo más que una moda, que tenemos que ser capaces de superar y olvidar los distintos intereses que han convertido este tema en un negocio, para centrarnos en su verdadera esencia, que tiene que ser conseguir que la sociedad actual alcance el nivel de conocimiento necesario como para poder desenvolverse por esta "ciudad" de forma autosuficiente. Sabremos dar el último salto, y llevar la seguridad informática a todos los PCs particulares, y a todos sus usuarios? El tiempo lo dirá.

23 mayo 2007

Referencias

Últimamente he recopilado y refrescado varias referencias de distinto tipo que creo que podrían ser interesantes para todos los lectores del blog, y como corro el riesgo de que se me vayan olvidando o extraviando, prefiero dejar constancia de ellas en este momento.


Las primeras tienen que ver con el control interno. En concreto son dos modelos de control interno inspirados en COSO, y que probablemente algunos ya conozcan. El primero es el modelo ECAR, un modelo de control interno y gestión de riesgos complementario a COSO, y el segundo es el modelo estándar de control interno (MECI) colombiano, vigente por decreto en las entidades del estado de ese país y perfecta referencia para complementar al modelo anterior.


El segundo grupo de referencias tienen que ver con la redacción de políticas de seguridad. En concreto, y para complementar un post anterior en el que Samuel Linares ya nos dejaba una buena referencia, creo que tanto en esta web argentina como en esta otra se pueden encontrar buenos ejemplos de políticas de seguridad. Y si no, las series del Centro Criptológico Nacional siempre constituyen una fuente de indudable calidad.


Y la última referencia que quiero dejar es este modelo de sistema integrado de calidad desarrollado por Telefónica. Muy buena referencia para todo aquél que tenga ya un alto grado de madurez en su gestión de la calidad y esté pensando en optimizarlo en base a una referencia integrada de metodologías, normas y técnicas. Ojo, sólo para empresas "realmente maduras" en temas de calidad, si es que se quieren obtener resultados útiles.


Espero que las referencia sean de interés, y sirvan para todos los interesados puedan profundizar en alguno de estos temas. Y como mínimo, como es mi caso , seguro que sirve para tener un repositorio localizado de referencias accesible desde cualquier lugar...

22 mayo 2007

Más que políticas

Muchas veces, cuando nos ponemos a escribir políticas, se nos olvidan los motivos por los que se redactan. En resumen, una política es, básicamente, una serie de normas dictadas por la organización que regulan un ámbito concreto de la misma (por ejemplo, una política de seguridad para el uso del correo electrónico regularía el uso permitido para el correo electrónico, en aras de garantizar unos niveles mínimos de seguridad durante dicha actividad). Sin embargo, muchas organizaciones se quedan, a la hora de redactarlas, en eso: describir las normas aplicables para un determinado ámbito.

Yo creo que las políticas deben llegar más allá. Sobre todo, una buena política debería indicar las causas y motivos que justifican o llevan a dictar esa determinada norma. Y los motivos son múltiples:
  • El personal no es el hijo pequeño al que se le dice "eso no se come". Si no queremos que lo coma, le tendremos que explicar que es perjudicial para su salud porque contiene dioxinas. Y el argumento tendrá que ser convincente, si queremos una razonable probabilidad de que se cumpla.
  • Una determinada norma puede estar justificada en un momento determinado y perder su sentido en un futuro. Y si no está argumentada, corremos el peligro de establecer dogmas que no podrán ser contradichos, puesto que la justificación se ha perdido. O es preferible que pase como con los monos y los plátanos?
  • Las políticas deben tener espíritu formativo, no sólo informativo. Si están bien redactadas, las políticas de la organización servirán no sólo como núcleo de los programas de formación interna sino como referencia permanente, oficial y actualizada de los contenidos formativos aplicables.
  • La difusión de los motivos es más eficiente si están en la propia política. Es preferible dedicar algo más de tiempo a escribir una buena política, con todas las justificaciones y motivos que sea necesario, a tener que ir aclarándolo uno por uno a todo el personal. Y de ese modo las normas y sus justificaciones aparecen asociadas en todo momento.
  • Las justificaciones no sólo se revisan y actualizan, sino que se establecen formal y oficialmente, a salvo de explicaciones incompletas o incorrectas (aunque no nos libre de que se puedan entender de forma incorrecta).

Probablemente se puedan añadir más justificaciones a esta pequeña lista, pero creo que con estas es suficiente como para ilustrar el comentario. Más vale sentarse con tiempo y calma a redactar unas buenas políticas, que indiquen tanto las normas como los motivos y justificaciones que llevan a tomar dichas decisiones, que lamentar los problemas que pueda causar un mal entendimiento de los mismos, o la oposición a su cumplimiento por falta de argumentos. Hagamos nuestra propia reflexión a tiempo...

17 mayo 2007

Gestión sin burocracia

Algo que suele preocupar bastante a muchas organizaciones es cómo conseguir implementar una metodología de gestión eficiente, que cumpla su cometido pero sin caer en la burocracia. Y no es algo sencillo, sobre todo si pensamos en entornos reducidos, donde prácticamente todo el mundo hace de todo. En estos entornos, es probable que esos extensos procedimientos vendidos al peso por algunas consultoras no sean de mucha ayuda, si es que alguien se plantea usarlos realmente...

Hoy quiero plantear una solución sencilla y útil, asequible para casi todas las organizaciones independientemente del tamaño que tengan, y que permite cumplir con los requisitos mínimos de cualquier gestión normalizada que se nos pueda ocurrir. Incluso en términos de auditoría, creo.

En resumen, los requisitos de gestión que exige cualquier norma son básicamente los mismos: que exista trazabilidad de las decisiones y que se tomen y ejecuten de la forma correcta. Básicamente, que se cumpla para cualquier actividad el siguiente ciclo: propuesta, análisis, validación, ejecución, verificación y cierre. Pasos que, además, se pueden agrupar de cara al registro:
  • Propuesta: Alguien propone algo (innovaciones, quejas, sugerencias, notificaciones de incidencias, solicitudes de cambio, ...).
  • Validación: Alguien tiene que validar (o rechazar) la propuesta, indicando los motivos (es decir, el análisis realizado de dicha propuesta). Si es un rechazo, la validación se corresponde con el cierre.
  • Ejecución: Quizás no se considere imprescindible, pero yo creo que es necesario algún tipo de registro sobre CÓMO se ha realizado la propuesta.
  • Verificación: Alguien debe dar el visto bueno de la ejecución realizada, y dicho visto bueno también se puede considerar como cierre.

Para articular estos pasos, necesitamos definir el alguien y el algo. Vamos allá:

  • Alguien: Cualquier persona dentro del grupo tiene capacidad para realizar las propuestas. Pero las validaciones y las verificaciones se las vamos a dejar al jefe (en entornos pequeños, normalmente suele ser el único cargo que está bastante claro). Y la ejecución... a quien indique el jefe.
  • Algo: Este algo, como ya he comentado, puede ser cualquier tipo de propuesta. Pero las vamos a clasificar, por ejemplo, en las siguientes: Sugerencias, Normas, Cambios, Incidencias, No Conformidades (si alguien prefiere llamarlas quejas, también se puede).

Y ahora, metemos estos ingredientes en una coctelera, añadimos un poco de blogger, agitamos... y ya tenemos nuestra herramienta de "gestión sin burocracia". Tachan!!

Y ahora, me explico. Es muy fácil: lo primero que tenemos que hacer es abrir un blog (en blogger, por ejemplo), generar un usuario por cada persona del grupo, y definir el blog como privado. Así, sólo los usuarios de nuestra empresa tendremos acceso al mismo, pero no tendremos que mantener el sistema. Además, tendremos acceso al blog desde cualquier lugar con acceso a Internet, y los viajes dejarán de ser un problema porque el que tiene que dar las validaciones no vuelve hasta no se sabe cuándo. Eso sí, el requisito es la conexión a Internet. Si no, la solución no sirve. :-(

A continuación, tenemos que crear categorías. Una por cada tipo de "algo". Así, cada vez que alguien postee un comentario, lo asociará a la tipología de "actividad de gestión" correspondiente.

Después, nos tendremos que aprender la secuencia Propuesta-Validación-Ejecución-Verificación. Y todas las entradas llevarán una de las cuatro palabras al principio, e irán seguidas del "algo" en cuestión. De ese modo, si lo que queremos es "comprar un PC", podremos localizarlas visualmente y saber que si figura la entrada "Propuesta comprar un PC" tendremos que esperar hasta que el jefe confirme (o deniegue) la solicitud mediante "Validación comprar un PC".

Y por último, tendremos que acostumbrarnos a postear, durante los últimos 5 minutos de cada jornada, todas aquellas gestiones que hayamos realizado durante el día, si es que deben figurar en la "herramienta de gestión sin burocracia".

Sencillo, no? Seguro que los auditores tienen comentarios acerca de si sistemas de este tipo son válidos o no de cara a una certificación. Y probablemente los no auditores tengan comentarios acerca de la viabilidad, utilidad o comodidad de esta propuesta. Así que si alguien está interesado en hacer comentarios al respecto, ya sabe dónde puede realizarlos...

15 mayo 2007

SecGoogle

Hoy publican en diario TI una noticia interesante. Parece que google va a crear una lista negra de sitios inseguros y peligrosos. En la práctica no es algo tan innovador, ya que como cita el artículo probablemente se trate de una ampliación del servicio actual, que ya presenta una ventana de notificación cuando el usuario intenta acceder a un sitio peligroso, pero la ampliación de servicio me parece algo a destacar. Sobre todo, por dos motivos:

  • Google es la principal referencia (hasta el punto de identificar ambos términos) para una gran cantidad de usuarios sin conocimientos específicos de seguridad. Por lo tanto, sus consejos van a llegar probablemente al grupo de usuarios más necesitados de ellos.
  • Google es un sitio de confianza para la mayor parte de los usuarios de Internet, y un consejo suyo sobre seguridad probablemente sea más valorado y aceptado que si lo diesen otras organizaciones cuyos intereses (del tipo que sean) normalmente suelen provocar desconfianza en ciertos grupos de usuarios.

Además, servicios de este tipo, totalmente gratuitos y dirigidos al público en general, y con un alcance tan amplio, siempre deberían ser bien recibidos. Sobre todo, si atendemos a los datos del estudio realizado por la propia compañía, que afirma que aproximadamente uno de cada 10 sitios web puede ser perjudicial para el PC de los usuarios de Internet.

10 mayo 2007

Quién desarrolla los procesos IT?

Una de los problemas más frecuentes a la hora de implementar modelos como ITIL en las organizaciones es aclarar quién hace cada cosa. Máxime cuando la organización interna del departamento IT suele ser funcional y no por procesos, y exceptuando las grandes corporaciones ni siquiera esa división funcional suele ser completa y se tiende a que todos hagan un poco de todo. Este post no pretende ser un mapeo entre áreas funcionales y procesos de ITIL, pero al menos sí una breve reflexión sobre los distintos perfiles que podrían integrarse en cada uno de los procesos de la gestión de servicios IT.
  • Si empezamos por el service-desk, podemos ver que entre sus funciones están las del clásico call-center, de gestión de incidencias y peticiones, pero también aparecen funciones de soporte técnico (resolución de incidencias) e incluso de interrelación con el cliente a nivel de negocio. Por tanto, este service-desk debería tener gente que no sólo cubriera un perfil de operación básica, sino que sería interesante que hubiese perfiles técnicos algo más elevados e incluso yo creo que deberían existir personas con cierto perfil comercial, dado que se busca un punto único de contacto con el cliente.
  • La gestión de incidentes, desde el punto de vista de una resolución rápida de los mismos, yo creo que debería estar compuesta por perfiles técnicos de nivel medio o alto, a ser posible interdisciplinares, para facilitar el "pensamiento lateral".
  • Si pensamos en la gestión de problemas, desde el punto de vista no sólo de la resolución de las causas de los incidentes sino también del de las funciones preventivas, parece necesario contar con un perfil especialista y con gran profundidad en el conocimiento de la infraestructura IT, un perfil técnico de nivel alto. Y a poder ser con buena capacidad de redacción, de cara a los errores conocidos.
  • Para la gestión de cambios me parece muy útil con contar con perfiles de gestión, sobre todo desde el punto de vista de la gestión de proyectos, ya que su función será la de supervisar y controlar todos los cambios relacionados con los servicios IT.
  • Para la gestión de versiones creo que son más convenientes perfiles no tan especialistas en gestión pero que conjuguen la gestión de proyectos con los conocimientos técnicos en general y a nivel de desarrollo software en particular, ya que esta suele ser la principal aplicación práctica de este proceso.
  • La gestión de la configuración creo que debería tener dos perfiles complementarios. El primero podría ser un perfil técnico de bajo nivel, encargado de mantener al día la CMDB, pero creo que se debería conjugar con un perfil más elevado, con capacidad para abstraerse de los CIs de bajo nivel y aportar una visión más "de negocio" en relación a los posibles reportes del proceso.
  • El proceso de gestión de niveles de servicio también considero que debería estar compuesto por perfiles tanto técnicos como comerciales de alto nivel, e incluso sería interesante la participación de perfiles con conocimiento sobre los procesos de compras de cara a la gestión de los UCs (contratos de soporte). Al fin y al cabo, la negociación de los SLAs y SLRs se desarrolla en este proceso.
  • La gestión financiera debería estar desarrollada por perfiles con conocimientos tanto técnicos como económicos (a partes iguales), y con capacidad de gestión y mano izquierda en la práctica.
  • La gestión de la capacidad debería estar desarrollada por perfiles técnicos de bajo y alto nivel, para poder llevar a cabo tanto las tareas de monitorización como las tareas de ajuste y sobre todo planificación de la capacidad.
  • Para la gestión de la disponibilidad la situación es similar al caso anterior. Los perfiles de bajo nivel creo que deberían ser los encargados de las funciones de monitorización y seguimiento, mientras que los perfiles de alto nivel se deberían encargar del Plan de Disponibilidad y, sobre todo, de la identificación y aseguramiento (en la medida de lo posible) de las funciones vitales de negocio.
  • Y por último, la gestión de la continuidad. En este caso, el perfil será multidisciplinar y multinivel, ya que la exigencia va desde el análisis de riesgos y la planificación hasta la implementación de las soluciones técnicas de continuidad y recuperación.

Y con esto, creo que he pasado por todos los procesos. Esta es una propuesta al vuelo de un mapeo entre los procesos de ITIL y los posibles perfiles que puedan existir en un departamento IT. ¿Alguien tiene algún comentario o quiere aportar su granito de arena? Quedo a la espera.

07 mayo 2007

DRM, ni angel ni demonio

De vez en cuando, en los medios especializados aparecen noticias y comentarios sobre los usos y desusos de la tecnología DRM (Digital Rights Management). Su último repunte se ha debido a la noticia surgida la semana pasada, a raíz de la publicación de una clave utilizada por el sistema de cifrado AACS, que se utiliza en los HD-DVD para implementar la citada tecnología DRM.

Mi reflexión no versa acerca de la noticia en cuestión, sino del llamativo debate que en determinadas ocasiones aparece en relación a esta tecnología. Llamativo no por el debate en sí, sino por los argumentos que se usan y por quiénes los utilizan. Para los no versados en el tema, DRM es una tecnología mediante la cual se puede definir, en relación a un fichero digital, quién tiene permisos para leerlo, modificarlo, ejecutarlo, imprimirlo, copiarlo, ... No es más (ni menos) que eso.

Lo que no me gusta de estos debates es que en muchas ocasiones los argumentos no se esgrimen contra el uso o abuso que se pueda realizar de dicha tecnología, sino contra la tecnología misma. Y lo peor es que hay casos en los que son las mismas personas (o entidades) que defendían las tecnologías P2P, argumentando que no se podía demonizar a una tecnología debido al uso o abuso que se pueda hacer de ella, las que actualmente están cometiendo el error que entonces criticaban. En aquél entonces defendían que una red para compartir archivos era una gran idea, y que el problema debería restringirse a si es o no legal compartir ciertos archivos, pero a día de hoy abogan por la eliminación de la tecnología DRM, olvidando que el debate se debería circunscribir a qué archivos están protegidos por dicha tecnología.

Lo que no debemos olvidar es que tanto la tecnología P2P como la tecnología DRM son independientes de los archivos sobre los que se utilicen. Y que no todos tienen que ser canciones o películas de cine. Del mismo modo que a todo el mundo le puede parecer totalmente lícito utilizar una red P2P para compartir con tus amigos las fotos del último viaje que habeis hecho, debería ser igual de lícito poder proteger dichas fotos para que nadie, fuera de vuestro círculo de amigos, pueda verlas (sobre todo si hay fotos "comprometidas"). Y si pensamos en entornos profesionales, a todos se nos podrían ocurrir casos en los que sería muy útil que cierto diseño del departamento de I+D o determinada oferta comercial estuvieran protegidos por esta tecnología, de forma que no puedan ser reenviados o modificados por personas que previamente no estén autorizadas para ello...

En resumen, creo que no debemos caer en la tentación de demonizar una tecnología por el uso o abuso que se pueda hacer de ella, y no estaría mal que aquellos que sintieron en su día la necesidad de defender una tecnología recuerden que, aunque las tornas cambien, los argumentos de entonces siguen siendo igual de válidos para las tecnologías de ahora.

02 mayo 2007

Empresas hacia el colapso

El lunes, en diario TI publicaban un artículo que me ha hecho reflexionar. Según un estudio de McAfee, un tercio de las empresas encuestadas creen que una brecha importante en seguridad, independientemente de si es intencionada o no, podría provocar el colapso de la organización. Pese a la contundencia del titular, no me quiero parar a analizar la noticia, sino que quiero

En primer lugar, si leemos el artículo nos podemos dar cuenta de que, al hablar de brecha de seguridad, los encuestados están pensando en pérdida o divulgación de datos confidenciales. Parece que la indisponibilidad temporal no es tan crítica a la hora de pensar en la continuidad de la organización para estos encuestados (siempre que no sea definitiva). Curiosamente, la mayor parte de los planes de continuidad de negocio se centran precisamente en minimizar la indisponibilidad (asumiendo que los backups evitan la pérdida), pero no suelen tener en cuenta la confidencialidad de la información. Es decir, que uno de los motivos que según los encuestados puede provocar la muerte de la organización no se contempla en los planes de continuidad. Significativo, verdad? Probablemente sea por ese tipo de detalles por los que la ISO 27001 exige en su control A.14.1.1 que se incluya la seguridad de la información (no sólo la disponibilidad) en el proceso de gestión de la continuidad del negocio.

Por otra parte, el artículo afirma que los encuestados han sido profesionales de IT de empresas de más de 250 empleados. La primera pregunta que me surge es si los CEOs de esas organizaciones hubiesen dado las mismas respuestas. Existe realmente la misma percepción de los riesgos en la dirección y en los departamentos de IT? Pero si leemos un poco más, la pregunta todavía puede ser más incisiva. El artículo afirma que, pese a que se tiene amplia conciencia respecto de los peligros existentes, los encuestados sólo gastan un 0,5% del presupuesto IT en seguridad de los datos. ¿Por qué parece no existir una correlación entre la percepción del riesgo y la gestión del presupuesto IT? La respuesta que se me ocurre es que parece un caso de epidemia de mal gobierno TICS (con S de Seguridad), sazonado con los ingredientes clásicos de una insuficiente concienciación en materia de seguridad.

En resumidas cuentas, un interesante artículo tanto por su propio contenido como por las reflexiones que se pueden realizar a raíz del mismo. Para terminar, me quedo con la cita final “Para proteger a clientes, empleados y accionistas, la prevención de pérdida de datos debe ser una prioridad central en cada nivel de la organización, desde la sala de directorio hasta el comedor de la empresa” y con una reflexión: Serán la continuidad de negocio y el buen gobierno TICS dos materias en las que las empresas se pongan las pilas en los próximos tiempos? Ya veremos…