Mostrando entradas con la etiqueta Anéctodas de abuelo cebolleta. Mostrar todas las entradas
Mostrando entradas con la etiqueta Anéctodas de abuelo cebolleta. Mostrar todas las entradas
miércoles, 4 de enero de 2012 8 comentarios

Carta a los Reyes Magos de un Responsable de Seguridad para el 2012

Iba a postear sobre el repaso al 2011 y los pronósticos del 2012 pero en las fechas que estamos me parece más pertinente escribir la carta a los Reyes Magos y aplazar las reflexiones anteriores para la semana próxima. Así que allá voy, esta sería mi carta a los Reyes Magos como "responsable de seguridad de la información" o "CISO" o "DPO".

"Queridos Reyes Magos,
Este año, como en años anteriores he sido bueno y he logrado que en mi organización no haya ocurrido ningún incidente. Mis compañeros no lo valoran pero he tenido que trabajar mucho para que esto sea así. Sin embargo, como la rutina habitual es que no ocurra nada parece que yo no hago mi trabajo. Aun con eso, tengo que pedir algunas cosas para el año 2012. Mi lista sería:

  • Pediría que en mi Organización entiendan que aporto valor. Que las cosas funcionen y que no hayan imprevistos no es una situación que se logre no haciendo nada. Es necesario que yo esté vigilante y atento del día a día y sobre todo, del funcionamiento de los sistemas para detectar cuando sospecho que algo extraño está sucediendo o puede suceder y avisar para mitigar el posible problema. Este año he tenido que notificar la existencia de bastantes vulnerabilidades en los entornos de producción que estaban sin parchear, he descubierto tráfico extraño desde portátiles internos que estaban infectados aunque por suerte no se habían conectado a la red corporativa. Creo que no pasan más cosas porque tenemos mucha suerte. La cantidad de pendrives y discos USB que veo por las mesas de mis compañeros dan miedo. Por las noches tengo pesadillas y no duermo tranquilo. Sueño con una llamada de la gente de guardia a las 3 de la mañana diciendome, "-Javier, vente para acá que se ha liao parda". En fin, sólo espero que mi Organización entienda que la seguridad, una vez que se ponen en marcha medidas, es una tarea de mantenimiento y supervisión continua que no puede desfallecer nunca. Es como estar aguantando una barrera con los brazos para evitar que la gente pase. En cuanto no haces lo que toca, la barrera cae y la gente se cuela. Yo solo espero disponer de información que me permita tener la tranquilidad de saber que las cosas funcionan y pueda así dormir tranquilo sabiendo que hago mi trabajo lo mejor posible. No podré evitar todos los incidentes pero al menos, no lo pongo fácil para que éstos ocurran.
  • Pediría que los usuarios sean buenos y contribuyan a facilitar mi labor. Aunque tengo desplegadas acciones de concienciación sobre la materia, la gente pulsa antes de leer y eso suele generar problemas. También quiero hacerles conscientes de que nuestra Organización trata con datos de carácter personal sensibles y que existe una legislación que respetar. Yo no estoy para proteger las cosas sino para lograr que todas las medidas funcionen según lo previsto pero esta guerra es cosa de todos. Con que un usuario cometa un error y ciertos datos acaben en Internet mi trabajo se verá frustrado y mi puesto cuestionado. Asumo que siempre ando en la cuerda floja porque al más minimo fallo se me apuntará con el dedo de la culpabilidad pero necesito que todos entiendan que en esta guerra todos somos soldados. 
  • Pediría que la Dirección de mi Organización entienda los resultados de mi análisis de riesgos y obre en consecuencia. Yo como responsable de seguridad estoy para detectar y diagnosticar problemas pero las decisiones y sus prioridades no son cosa mia. Yo puedo aconsejar o asesorar respecto a lo que entiendo debe ser tratado pero los riesgos de mi Organización deben ser asumidos por la Dirección, no por mi. Yo no tengo tanto poder para tomar decisiones de ese calado.
  • En relación con lo anterior, también necesitaría que la Dirección de mi Organización me proporcione algunos recursos cuando decide poner en marcha algún plan de tratamiento de riesgos. Para poder tomar decisiones y sobre todo, para detectar anomalías necesito tener 1000 ojos y eso implica desplegar ciertas tecnologías de centralización de logs, correlación de eventos y tiempo para poderlas ajustar atendiendo a nuestro contexto y nuestros riesgos de negocio. Mi único objetivo es poderles proporcionar una información de mayor calidad que les lleve a tomar decisiones más correctas y precisas pero eso implica invertir un poco. Evitar y prevenir problemas siempre es más barato que tener que sufrir un incidente y reparar los daños. Este año 2011 además hemos visto retozar en el lodazal de las empresas hackeadas o con incidentes a organizaciones de todo tipo y supongo que en esa lotería algún día nos puede tocar a nosotros.
  • También pediría a mis compañeros de Sistemas que no me vean como un enemigo o alguien que se mete en sus asuntos. Yo soy consciente que la prioridad es que todo funcione pero a veces, por poner en producción demasiado rápido las cosas se cometen errores que luego pasan facturas muy caras. Obviamente esas facturas, si suponen un incidente de seguridad las voy a tener que pagar yo pero no debemos olvidar que estamos todos en el mismo barco que es nuestra Organización y aquí todos queremos que los incidentes no nos sorprendan.
  • A mis compañeros de Desarrollo les pediría un poco más de prudencia y de concienciación respecto a las aplicaciones que mi Organización vaya a hacer accesibles desde el exterior. Hoy en día es de ingenuos pensar que todo el mundo en Internet es bueno. Hay gente que se dedica a buscar agujeros o fallos que luego les permiten llegar más lejos. Por tanto, las aplicaciones deben ser programadas con una mentalidad defensiva y las baterías de pruebas de desarrollo no solo deben probar funcionalidades operativas, deben también superar pruebas de estrés y resistencia frente a los ataques más comunes.
  • En materia de Protección de Datos de Carácter Personal pediría también a muchos departamentos que comprendan que esto de la LOPD no es una tortura o el multazo que nos puede pegar la Agencia Española de Protección de Datos. Nuestros clientes se merecen, como parte de los servicios que les damos, una adecuada y diligente gestión de su información. Al fin y al cabo, a nosotros nos prestan ciertos datos para que les podamos dar servicios pero la información es suya, no nuestra.
  • Por terminar y ya en relación al área de auditoría, sólo deseo que mis compañeros sean capaces de hacer lo mejor posible su trabajo y me puedan reportar las máximas deficiencias posibles. En el momento se que me escocerá el informe pero entendiendo que ellos buscan lo mismo que yo, cuanto más barran ellos la casa y más alfombras se levanten, menos riesgo de sustos o incidentes tendré que asumir yo. Cuatro ojos ven más que dos y por tanto, es bueno que de vez en cuando alguien ajeno a mi día a día me revise y me recomiende cosas a cambiar. Yo creo profundamente en el ciclo de mejora continua y lo que no te mata te hace más fuerte.

En fin, queridos Reyes. Se que éste es un año difícil y que las Organizaciones todavía no valoran/comprenden/entienden qué pinta la seguridad de la información y cómo eso les ayuda a ser mejores y más competitivas, pero esperemos que con los años y no a base de incidentes, las cosas vayan cayendo por su propio peso. No pido para este año tener presupuesto para certificar mi SGSI con la ISO 27001 porque todavía soy consciente de que necesito mejorar algunas áreas de control aunque será el deseo para el año que viene casi seguro."
viernes, 26 de noviembre de 2010 2 comentarios

Conocimiento inducido y la pandemia del "cut&paste"

Aunque últimamente no puedo publicar demasiado, hoy he podido sacar un hueco para hacer bloggerterapia. Lo que vengo a contar es una pandemia que tiene como consecuencia la poca valoración que se da al contenido y que hace pensar en si realmente somos la "sociedad del conocimiento". Vivimos inmersos en la sociedad más tecnificada que ha existido con acceso casi inmediato e independiente de dónde nos encontramos y sin embargo se produce una paradoja curiosa, justo en el momento en que más información tenemos disponible es cuando creo que peor la estamos procesando. Estamos tan saturados e inundados que la escala de procesamiento que empieza en los datos, se organizan como información, se transforman en conocimiento y supone adquirir sabiduría hace que no podamos masticar ni conocimiento ni información quedando solo como meros datos, lo que podemos denominar como "infoxicación".

¿A qué viene todo este rollo previo? Lo que trato de contar es la experiencia personal que sufro en ciertos proyectos donde participo como consultor de seguridad para el desarrollo de un marco normativo (normas y procedimientos de seguridad) basados en la ISO 27001. Parte de mi trabajo consiste en asesorar o recomendar la forma de hacer efectivas las medidas de seguridad que requieren los sistemas de gestión de la seguridad de la información. Hace ya mas de cuatro años participé en el proyecto de construcción de un SGSI y como mi experiencia y conocimiento se centra más en los aspectos formales de la gestión y de la formalización de las medidas, desarrolle un conjunto de normas básicas de seguridad (que establecen las restricciones o requisitos que la organización quiere cumplir) y un conjunto de procedimientos que los implantan (definen las tareas, actores y registros de ejecución que deben implantarse). Este tipo de proyectos se ha venido repitiendo en los últimos años y por tanto, la documentación inicial ha ido mejorando, evolucionando y completándose para hacer de ella un marco maduro y bastante completo de más de doscientos folios.

Sin embargo, lo que más me sorprende últimamente es el poco "valor percibido" que se dan a esos documentos por parte de nuestros clientes. Ellos no han tenido que enfrentarse al temible "folio en blanco" y por tanto, no pueden valorar lo complejo del proceso creativo que supone leer la norma ISO 27002 e imaginar cómo hacer algo real y ejecutable su cumplimiento. Ellos se limitan en muchos casos a cambiar logotipos, modificar las responsabilidades y con eso, suponen que adquieren y reciben el conocimiento inducido que cada documento tiene tras de sí. El algunos casos, la redacción de un solo documento ha podido costar más de dos semanas de trabajo y sin embargo, la adaptación en su organización es cuestión de horas. En parte este es el servicio que se proporciona en un proyecto así y es el valor que aporta la consultora.

Lo que falla por parte de los clientes es, en muchos casos, que ese conocimiento inducido no es procesado, no es adquirido ni asimilado y el desarrollo del marco normativo se limita al "cut&paste" de las "formas" sin procesar el "fondo". Nuestro conocimiento en forma de plantilla de documento requiere de un esfuerzo por integrar en la realidad de cada cliente cómo hacer las cosas. Es cierto que al basarnos en estándares, lo que hay que hacer está mas o menos definido y es lo que nos ha permitido formalizar con carácter general los controles, pero hay cierto margen de libertad que permite a cada cliente adecuar a su contexto los controles. Sin embargo, no hay en muchos casos esa reflexión madura de tratar de entender qué persigue el control, que plantea el documento-plantilla y qué finalmente será la redacción particular que deberá tener el procedimiento integrado en la organización.

En el fondo, a nuestro marco normativo le ocurre como a otras muchas cosas de esta cultura del "cut&paste". Quiere ser publicado y utilizado rápidamente pero no es masticado, generando un marco normativo que no es ni siquiera conocido por el área responsable de su difusión y ejecución. Y es que comprar un documento no es comprar conocimiento, es simplemente adquirir una base bastante desarrollada que permite tomar rápidamente las decisiones más oportunas para poder lograr implantar un control. Sin ese esfuerzo de moldear y particularizar el documento al contexto y a la realidad de cada cliente, las cosas quedan muy cojas, produciéndose cierta "infoxicación" en materia de seguridad. El marco documental está constituido por 11 normas (una por bloque para tener claro en qué documento se regula qué aspecto de la seguridad, de acuerdo con lo establecido por ISO 27001) y unos 30 procedimientos (con las tareas operativas que hay debajo de muchos de los 133 controles de la norma). Un total de unos 200 folios que se ven como un ladrillo si no se tiene claro que se quiere hacer con ellos y por qué. Sin embargo, para quien tiene claro qué necesita, permite formalizar y documentar perfectamente el marco normativo que quiere aplicarse a la información y hacerlo en relativamente muy poco tiempo (a tiempo completo, en un mes se puede tener todo adaptado). La documentación ha sido desarrollada basándose en la norma (pero sin ser un copia y pega de la misma sino una interpretación práctica) bajo un criterio de máximos (Se redactó pensando en disponer de las mejores y más restrictivas medidas de seguridad para que los clientes borren o eliminen aquello que no pueden cumplir o no van a implantar). Sin embargo, este potente armamento necesita de un soldado hábil que conozca lo que la norma dice y lo que él quiere hacer real. De lo contrario, se transforma en un texto que se interpreta como ley y del que da miedo borrar cosas siendo visto más como un obstáculo que como una ventaja competitiva. Y esa distorsión de la percepción es causada principalmente por no haber tenido que sufrir la dura batalla de luchar contra el folio en los primeros momentos y no saber cuanto hay que sudar la camiseta para tener una norma o procedimiento en condiciones.

Casualmente poco después de haber posteado este artículo, he podido ver en la televisión el nuevo anuncio del Audi A7 que viene a expresar algo parecido, el poder de la hoja en blanco.



Nuestra sociedad va tan deprisa que apenas valora lo complejo que es producir o crear y sólo se limita a localizar o utilizar. Sin embargo, para "generar" o "crear" se requiere talento y conocimiento. Para "localizar" o "utilizar" sólo se requiere habilidad. El camino de la creación siempre conduce hacia la sabiduría. El de la utilización o uso puede que acabe en el mismo sitio pero no tiene porqué ocurrir siempre.

Para terminar en positivo, creo interesante que veáis las reflexiones de Alfons Cornellá sobre qué es la "Infoxicación".




Como recomendación, creo interesante que leáis también a Berto Pena y sus dos magníficos post sobre "la Dieta de información" (Leer en ThinkWasabi los post I y II).

Este verano, como parte de las tareas de mejora de mi productividad personal pasé varios días reordenando mis subscripciones RSS en Google Reader agrupándolas en los 5 temas que más me interesan y poniendo además la etiqueta LD (lectura diaria) y LS (Lectura semanal) como sufijos. Además, decidí que una vez que la etiqueta caduca, doy el contenido por procesado, marcando como leído esos contenidos y eliminando esa tarea semanal de mi agenda. Si no lo puedo procesar, no puede figurar entre mis asuntos como pendientes. Tampoco es viable o posible estar al tanto de todo y prefiero, cuando tengo un momento, dedicarle un rato a lo que considero imprescindible antes que andar buceando en miles de entradas pendientes que no voy a poder masticar como es debido. Prefiero la "calidad del procesamiento" a la "cantidad" aunque pueda sacrificar el estar al tanto al menos de oídas de cómo van las cosas. He cambiado el hojear por el procesar, de acuerdo también al tiempo máximo que estoy dispuesto a dedicarle a esa tarea dentro de mi día a día. Es importante para mi pero no es mi trabajo ni mi máxima prioridad.
jueves, 30 de julio de 2009 6 comentarios

Ya sois más de 2000 lectores vía RSS

Lo siento pero hoy toca un post filosófico. Aunque no suelo darle mucha importancia al tema de las estadísticas del blog y tampoco publico con ningún objetivo amortizador o lucrativo, hoy he podido comprobar que las suscripciones vía RSS superan ya los 2000 usuarios.

Las cifras redondas siempre hacen a uno reflexionar y en este caso, cada vez soy más consciente de la responsabilidad que se adquiere al tener a tantos lectores visitando el blog con asiduidad.

Espero seguir aportando cosas al escenario de la seguridad de la información y que la calidad de mis textos logre seguir manteniendo estas cotas. Como creyente convencido de la "mejora continua", deseo también recibir vuestras críticas para poder hacer aquellas correcciones que permitan al blog ser mejor cada día.

Tengo pendiente investigar por qué Feedburner no envía el texto completo del feed pero estoy en ello ya algún tiempo y no doy con la tecla...

No quiero perder la oportunidad de recomendar ver la entrevista que le hicieron ayer a Rafael Nadal en TVE-1 donde desnuda que hay detrás de un gran campeón. Básicamente cualidades que deberían ser ejemplo y modelo para todos los que aspiramos a ser grandes profesionales: humildad, sacrificio, constancia, ilusión y trabajo, mucho trabajo. Levantarse cada día pensando en positivo, analizando cómo se pueden hacer las cosas cada día mejor. Todo ello manteniendo el dificil equilibrio entre la faceta profesional y la faceta personal. La serenidad llega cuando ambas cosas se equilibran. Podéis disfrutar de ella en Entrevista Nadal TVE-1.

Un saludo a todos y mil gracias. Es reconfortante pensar que uno escribe para un público interesado en estos temas.



PD: La próxima celebración será pronto cuando cumpla las 1000 entradas y posiblemente coincida con el cierre del año.
lunes, 9 de febrero de 2009 1 comentarios

Diez años de seguridad de la información

Tal día como hoy, mi director de proyecto de fin de carrera me ofrecía participar en un proyecto piloto de la Universidad relacionado con el "Análisis de los riesgos de seguridad de la Información" para la Dirección General de Informática de la Comunidad Autónoma de la Región de Murcia.
Aquella oferta de trabajo era mi primera actividad profesional tras la finalización de la carrera y me puso entre las manos la versión 1.0 de MAGERIT junto con el software desarrollado por Sema Group para dar soporte a la metodología. El año 1999 fue, en temas de seguridad, bastante movidito. Todo el mundo iba como loco con las pruebas para superar el año 2000. Algunas aplicaciones de gestión económica empezaban la migración hacia el Euro. Además, en verano de ese año se publica el R.D. 994/1999 con las medidas de seguridad para los sistemas automatizados de tratamiento de datos de carácter personal.
Aunque este post no pretende ser un resumen de batallas de un abuelo cebolletas, recuerdo que las primeras referencias por aquel entonces en "gestión de la seguridad" venían establecidas por las Guias NIST y los libros conocidos como Rainbow Series de la NSA, en concreto el famoso libro naranja.

En aquel momento, los criterios de seguridad de la información americanos eran la referencia aunque ya empezaba a ser famosa la norma BS-7799 con las buenas prácticas para la gestión de la seguridad de la información.
Recuerdo que había dos visiones enfrentadas donde por un lado, los americanos establecían sus criterios propios para todo lo suyo y por otro, se hablaba de gestión de la seguridad de la información en base al cumplimiento de buenas prácticas. Este mismo choque de enfoques se producía en los criterios de certificación de productos de seguridad, donde los americanos defendían los TCSEC y los europeos los criterios ITSEC. Finalmente ambos criterios acabaron unificados bajo los "Common Criteria" o ISO 15408.

Al finalizar el proyecto con Magerit no tuve más opción que desplazarme a Madrid para seguir currando con esa nueva y apasionante disciplina conocida como "análisis de riesgos de la seguridad de la información". Por suerte, tuve la oportunidad de entrar en la empresa Innosec, una empresa dedicada a seguridad informática donde Gustavo San Felipe, hoy CISO de Acens apostó por un profesional con experiencia en análisis de riesgos dado que eso del diseño de la seguridad basado en el análisis de riesgos lo veía como algo esencial en el futuro. Era la época de la venta masiva de firewalls, de los primeros antivirus perimetrales y del inicio de las redes privadas virtuales. Y en medio de tanto cacharro estaba yo por allí purulando y dando el follón respecto a lo importante que era escribir políticas de seguridad y el cumplimiento de la LOPD. Fruto de aquella época son dos artículos en la revista SIC sobre "análisis de riesgos" e ISO 15408.
Posteriormente Innosec fue adquirida por el Grupo Satec y pasé a formar parte del departamento de seguridad. Allí más de lo mismo. Empresa muy tecnológica que vendía tanto productos como instalación y configuración de equipamiento de seguridad pero que me tenía como recurso dedicado a los temas burocráticos de la seguridad, el papeleo inutil que eran las políticas, normas y procedimientos. Recuerdo intensamente las discusiones en las comidas sobre la importancia del análisis de riesgos para el diseño de las necesidades de seguridad aunque era un entorno muy técnico que no podía entender como podía haber cosas más importantes que un buen firewall o antivirus. Incluso muchas veces cuando me ponía radical y comentaba que algún día las empresas se certificarían en seguridad igual que se hacía para la calidad con ISO 9000, me veían como el freaky de las políticas y normas de seguridad que nunca sirven para nada. Todavía guardo por ahí un Powerpoint con un diseño de prototipo de herramienta para hacer análisis y gestión del riesgo. De aquella época, muy a mi pesar, me llevé puestas también algunas certificaciones de producto (CCSA de CheckPoint, TSCE de TrendMicro, MCP de Microsoft). Todo esto transcurrió entre el año 2000 a 2004. En materia de gestión de la seguridad de la información, ya estaba publicada ISO 17799:2000 y era una verdadera referencia respecto a qué era necesario considerar cuando se hablaba de "gestión de la seguridad de la información". Una vez cansado de hacer ofertas sobre diseño de políticas de seguridad y análisis de riesgos y tras finalizar un proyecto de diagnóstico del cumplimiento de la LOPD para un servicio de salud de una comunidad autónoma, decido que tenía que ejercer y bajar a la arena de los proyectos concretos relacionados con lo mio (gestión de la seguridad de la información). Un compañero del "CURSO SUPERIOR DE SEGURIDAD DE LA INFORMACIÓN, DE SISTEMAS Y DE REDES" de Belt Iberica me ofrece la oportunidad de dar un paso hacia Murcia y me bajo a Almería a trabajar para una empresa de servicios de una Entidad Financiera que tenía también un área de consultoría de seguridad de la información. El primer trabajo en esta nueva empresa consistió en la realización de un análisis diferencial contra ISO 17799:2000 y el desarrollo de una política corporativa de seguridad que sirviera de marco normativo para un conjunto de normas y procedimientos concretos. En esta empresa también tuve que currar bastante en materia de LOPD dado que la parte de medidas de seguridad intentábamos cubrirla como actividades integradas dentro de ISO 17799:2000 de la época. También, casi al final de esta época, se publica UNE 71502:2004 y me toca entrar ya de lleno en los sistemas de gestión de la seguridad de la información. Estuve impartiendo un cursos sobre UNE 71502 y la importancia de esto que ahora se podía certificar y que era la "gestión de la seguridad de la información". Todo esto transcurrió entre el año 2004 a comienzos del 2007. La verdad es que la publicación de ISO 27001:2005 nos pilló por sorpresa a todos, incluido AENOR. Se hablaba de una futura norma internacional certificable pero lo que en aquel momento se conocía es que cada país trabajaría con su propia norma dentro de su esquema interno de certificación para posteriormente hacer una norma común e internacional certificable. BS tenía su 17799-2, Aenor su UNE 71502 y otros países las suyas. Sin embargo, en 2005 se publica ISO 27001 que deja claro que debido a la importancia y las necesidades de normativa en esta materia, la norma internacional no podía esperar al 2008 que era para cuando se esperaba. Esto en España ha tenido como consecuencia los guisaguisados de los certificados UNE 71502 e ISO 27001 conviviendo un tiempo, hasta que se ha elaborado ya la UNE-ISO/IEC 27001:2007.

Finalmente (la historia ya está acabando), a mediados del 2006 me vuelvo a casa a trabajar en la consultora Firma, Proyectos y Formación S.L. dedicada en aquel momento a "protección de datos" que con mi incorporación, abre el área de "seguridad de la información". Y desde entonces hasta ahora, todos los proyectos han estado relacionados o bien con partes de un SGSI (sobre todo el análisis de riesgos, estudios diferenciales ISO 27002 o el desarrollo de marcos normativos de seguridad de la información) o bien con la construcción e implantación de SGSI, siendo actualmente la referencia más importantes la lograda hace un par de años por la Consejería de Agricultura de la Región de Murcia, primera Administración Pública que logró una certificación acreditada bajo esquema UKAS.

Espero que este breve repaso a estos diez años de trayectoria profesional hayan servido para pintar unas breves trazas de cómo ha ido evolucionando esto de la "gestión de la seguridad de la información" hasta alcanzar ya su cuota de relevancia dentro de las organizaciones.

Solo espero y deseo que el ansia y la motivación que supone "certificarse bajo ISO 27001" no acabe prostituyendo a la propia seguridad de la información.Montar la documentación necesaria para establecer un sistema de gestión de lo que sea es fácil (Sólo son necesarios los procedimientos generales que establece todo SG) pero gestionar un SGSI requiere de conocimientos de seguridad de la información (si no sabes de aquello que quieres gestionar, dificilmente podrás controlarlo). En próximos días escribiré un post sobre "SGSI enfermos desde el diseño" que extracta unas primeras impresiones/conclusiones basadas en mis experiencias de estas últimas semanas auditando como auditor interno a varias empresas que han montado su propio SGSI. Mis impresiones no son buenas aunque aquí la principal responsabilidad la tienen las entidades de certificación respecto a su criterio para otorgar o no una certificación. Yo, como auditor/consultor percibo que las nuevas versiones de ISO 27001:2005 tienen que establecer de forma más contundente requisitos formales respecto a:
  • Criterios para que una metodología de análisis de riesgos sea correcta, fiable y completa.

  • Unos mínimos criterios sobre la gestión de la eficacia que hay que hacer para conocer qué y cuanto hay que medir.

  • Una nueva versión de la ISO 27002:2005 que incorpore nuevos objetivos de control y aglutine o agrupe controles dado que hay áreas que tienen relativamente pocos controles y otras que disponen de demasiados.


Por lo que estoy encontrándome al auditar, las cosas más comunes son:
  • Metodologías de análisis de riesgos que suponen lo mismo que sacar el dedo y decidir al azar los principales problemas de seguridad.

  • SGSI sin objetivos de seguridad o con unos indicadores que no sirven para nada para evaluar el cumplimiento de objetivos

  • Hacer el análisis de riesgos de forma exhaustiva y detallada pero no volverlo a mirar más ni siquiera para elaborar el plan de tratamiento de riesgos


Y estoy seguro que luego muchas empresas lucirán con esplendor su magnífico sello "ISO 27001". De todas formas, aquí creo que es tonto autoengañarse y que el tiempo podrá a todo el mundo en su sitio. Quien gestione bien la seguridad evitará o detectará incidentes y no tendrá problemas reales con impactos reales. Aquellos que tengan un SG-SGSI (un sistema de gestión para engañar al sistema de gestión de la seguridad de la información) tendrá unos indicadores preciosos, unos procedimentos cojonudos pero andarán todo el día apagando fuegos y perdiendo datos, cuando no siendo multados por incumplir la LOPD. En este segundo caso, el sello no servirá para nada, dado que los incidentes seguirán produciéndose de igual manera y por tanto, no se beneficiarán de lo que supone una verdadera "gestión de la seguridad de la información". No saldrán de la cultura apagafuegos que tradicionalmente venía utilizándose en esta materia y para la que el SGSI se supone que es el mejor antídoto.
 
;