Pues como iba diciendo, después de tanto tiempo sin lunes desmotivador y con las vacaciones de por medio, empiezo a notar cierto aire positivo, así que es necesario desempolvar algunos lunes desmotivadores que veréis en las próximas semanas para ir bajando esa ilusión pasajera de mejorar la seguridad.

He aquí, pues, el lunes desmotivador 21. Y recordad, si no es lo suficientemente desmotivador, siempre podéis echar un ojo a todos juntos en nuestra página de lunes desmotivadores.

Cuando se redactan procedimientos de seguridad (o de cualquier otra cosa, dicho sea) es posible pensar que se trata de una especie de programa que será ejecutado por personas. La verdad, como suele ocurrir en estos casos, es bastante más compleja.

El problema de los procedimientos es que hay que leerlos, que no pueden contarlo todo, que tienen que estar actualizados y ser relevantes, hay que comprobar que se han seguido, que hay que saber cómo encontrarlos y si existe uno para eso que vas a hacer, que hay que saber cuándo hay que usarlos, etc.

En definitiva, demasiado complicado para que funcione bien. Sobre todo porque es necesaria la implicación de los que mandan y la colaboración de los que hacen las cosas y, la verdad, a nadie le importa un carajo. Se trabaja mejor sin documentos de por medio que evidencien que nos estamos saltando la mitad de las cosas que queremos hacer.

En fin, os hacéis a la idea ¿no? En cualquier caso, una cosa importante es que, muchos ‘managers‘ piensan que si todo está bien definido: 1) Se puede sustituir a cualquiera por otro que lo hará igual de bien y 2) Es posible sustituir a alguien bueno (y caro) por alguien que sepa menos (y sea más barato).

Pues dejadme deciros que eso es una patraña. No sólo por los inherentes problemas para ‘documentarlo todo’ sino también porque la gestión de TI está bastante alejada de la ‘cadena industrial’, cosa que muchos no quieren ver.

Pero bueno, eso lo discutiremos en el próximo Sec&Beer, que espero que no se deje ir mucho.

Cuando uno escribe normativa de seguridad se pregunta hasta qué punto será útil. Una vez tuve una epifanía en la que comprendí que la documentación de seguridad es un ‘software’ que, para ser efectivo, debe ejecutarse en los ‘procesadores’ de las personas a las que están en su ámbito de aplicación.

Y claro, si redactar la documentación es complicado, hacer que se ejecute en cerebros ajenos puede resultar imposible.

Sin embargo, existe una situación (desmoralizante, claro) en la que los responsables están muy convencidos de que únicamente teniendo el documento ya está todo arreglado, independientemente de que lo haya leído alguien o se hayan implantado las medidas que en él se recojan.

Y yo me pregunto “¿hace ruido un árbol que cae cuando no hay nadie para escucharlo?”. O sea, ¿sirve de algo una normativa que nadie lee ni cumple ni se asemeja a la realidad?

Recordad que la efectividad de la documentación depende de quién se la cree y actúa en consecuencia. Si nadie se la cree ni la lee ni la utiliza para nada, ¿de verdad lo consideras una medida de seguridad? ¿Crees que te va a proteger de algo?

Con estos desvaríos os dejo el lunes desmotivador de esta semana, el primero cuya cita no es de una película sino de una serie.

 

Pues eso, “cuando un tonto coge un camino, el camino se acaba y el tonto sigue”. En este caso el tonto soy yo. La linde es la necesidad de tener en cuenta las características socio/culturales de una organización para el desarrollo de sus modelos de gestión y marcos normativos de seguridad. (Pedazo de frase pedante que me he marcado, verdad?…)

Hace unos días, mi compañero Daniel Santos (no he pedido permiso a Dani para nombrarle ni citarle, espero que no le moleste) hizo una exposición magnífica sobre los proyectos que nuestro equipo desarrolla con pena y gloria a partes iguales.

Cuando habló de aquellos proyectos relacionados con el cumplimiento normativo (el compliance que diría un señor consultor) usó una cita de la película “Gladiator”.

Marco Aurelio y Máximo Décimo conversan: “¿Y qué es Roma Máximo?” “He visto parte del resto del mundo, es brutal, cruel y oscuro, Roma es la luz”.

Dani venía a decirnos que las normas son un instrumento útil para organizarnos y que sin ellas el caos hace nuestra existencia muuuuy complicada e incómoda.  Y esto, aplícalo al código civil, al código penal, al de circulación o a las políticas de seguridad.

Como digo, en el caso de las normas o políticas de seguridad es lo mismo, son muy útiles especialmente en situaciones que nos resultan ambiguas. Para un usuario con conocimientos limitados de la tecnología, la elección de guardar sus documentos en el servidor de ficheros o en local en su portátil es completamente ambigua. Con sus conocimientos no puede evaluar los pros y contras de cada una de las dos formas de proceder y las dos le parecen conductas válidas. Si en este caso existe una norma clara que le diga que toda documentación corporativa va al servidor de ficheros y la documentación personal se queda en su carpeta de documentos locales, la situación se des-ambigua de forma inmediata.

Sin embargo…. al igual que ocurre con las metodologías de gestión de seguridad  (ver la entrada de VIC Information Security Management Mediterranean Mode), en el desarrollo de políticas de seguridad cometemos el mismo error y desarrollamos normas como si nuestros usuarios fueran luteranos alemanes o individualistas norteamericanos. Ni las políticas ni la forma de hacerlas cumplir puede ser la misma aquí que en Londres.

A continuación voy a citaros un par de fragmentos de sendos post del blog politikon, que nada tienen que ver con la gestión de la seguridad de la información, pero sí con las diferencias culturales y la aceptación y cumplimiento de normas.

El primero sobre los alemanes Esa cultura que es Alemania II, cito traduciendo:

“La afición alemana por el orden, sobre la que a menudo se hacen bromas, ha demostrado ser cierta, dijo Carlos Baixeras, de 30 años. Un ingeniero que comenzó a trabajar cerca de Frankfurt hace 18 meses. “Hay reglas para todo”, dijo. “Hay una política de uso de la papelera.”

Y otro de nuestros amigos centroeuropeos Esa cultura que es Alemania III, cito y traduzco:

“Según el diario alemán Der Spiegel, la policía alemana disparó únicamente 85 balas en todo 2011… la mayoría de estos disparos ni siquiera fueron dirigidos a personas: “49 disparos de advertencia, 36 disparos a sospechosos. 15 personas fueron heridas, 6 resultaron muertas.”

Y ahora para comparar, una de nuestros cercanos (culturalmente hablando) primos griegos, Esa cultura que es grecia, cito y aviso que es un poco largo pero merece la pena:

“Resulta que el gobierno griego, en un momento de inspiración, decidió que era hora que la gente empezara a pagar un impuesto sobre propiedades para tapar el enorme agujero fiscal del país. Es un impuesto decente, bastante progresivo; los que tienen una casa más grande cobran más, etcétera. Como el sistema de recaudación griego es una verbena, el ministro de turno decidió que el impuesto se cobraría junto con el recibo de la luz. Todo el mundo necesita electricidad, al fin y al cabo; nadie va a quedarse a oscuras con tal de evadir dinero a hacienda.

Bueno, esto es Grecia. Primero, los sindicatos protestaron, montando un pollo tremendo, organizando desobediencia civil y llevando el tributo a juicio. La gente, lisa y llanamente, prefirió dejar de pagar el recibo de la luz antes que (horror) pagar un miserable duro al gobierno. La compañía eléctrica (pública, como todo en ese país), que ya iba justa de dinero, tuvo que ser rescatada de mala manera por el gobierno ante la barbaridad de gente que sencillamente dejó de pagar por el suministro completamente. Para acabarlo de arreglar, un tribunal decretó que cortar la luz a alguien por no pagar un impuesto es ilegal, así que el gobierno ha acabado no viendo un duro del nuevo tributo y encima gastándose una millonada para cubrir las pérdidas.

La cosa, sin embargo, no se queda aquí. La eléctrica ha decidido que esto de aplicar la ley no va con ella, así que este año ni va a intentar cobrar el impuesto. El gobierno griego, como ni está ni se le espera, no ha dicho nada, así que tenemos un impuesto (otro más) que está en los libros pero que todo el mundo va a ignorar olímpicamente”

Creo que sobra que os haga la analogía con la normalización de seguridad.

¿Qué modelo de desarrollo normativo creo que puede funcionar en nuestro entorno? Os lo cuento en mi próximo post…

Era el año 2003, más o menos, y estaba yo trabajando en un proyecto de Auna cuyo objetivo era integrar la documentación de normativa de seguridad de Amena (que se había unido al grupo) y la existente del grupo, aportando además, nuevas modificaciones allí donde hubiera carencias.

Total que, como buen consultor de empresa Big5 (o ya eran Big4, no me acuerdo) tomé prestados otros documentos de normativa de otros proyectos para generar la normativa de seguridad definitiva.

Pasó el tiempo y, qué casualidad, que me encuentro por 2007 un Documento de Seguridad en un organismo de la Junta cuyas ‘directrices de seguridad’ me empiezan a sonar línea por línea.

Desempolvo CDs antiguos y, ¡voilá!, son los mismos que yo escribí / copié / adapté palabra por palabra. Por supuesto, la empresa que había hecho los trabajos no era para la que yo estaba trabajando entonces.

¿Y cómo llegó eso hasta ahí? Os estaréis preguntando… Pues por arte y gracia del ‘cutre-paste’.

Pero hay más, no sólo las directrices, todo el documento de seguridad ya me lo he encontrado igualito en otros organismos… Pero no porque se los pasen unos a otros, sino redactado por ¡diferentes empresas!

En fin, ahí os dejo el lunes desmotivador, con las palabras de Krusty, el payaso: “inventar, copiar… ¿qué más da?”.

En cualquier caso, tampoco es que haya que escribir todos los documentos desde cero, ya que para eso están las referencias y trabajos pasados que uno haya hecho.

Sin embargo, como nos decían en el colegio cuando pillaban a alguien copiando un trabajo.: “no lo hagáis letra por letra, tratad de entenderlo y escribirlo con vuestras propias palabras”. Y ya de paso, seguro que surgen ideas para mejorarlos.

Que desde el CCN se publiquen documentos y guías que aclaren y normalicen el cumplimiento del Esquema Nacional de Seguridad me parece cojonudo.

Sin embargo, que publiquen ‘herramientas’ de poca utilidad como son controles.jar y preguntas.jar, me parece algo patético.

En este post voy a comentar sobre la jarra de preguntas (ya podían darlas de cervezas).

Para empezar esta ‘herramienta’ no vale para nada, ya que no te deja poner comentarios, ni valorar las respuestas en un rango algo más amplio que ‘ok, no, parcial o n.a’. Luego visualmente sólo tiene una vista que no es muy acertada.

Herramienta de preguntas sobre requisitos del ENS

Herramienta de preguntas sobre requisitos del ENS

La exportación es a un fichero XML donde no aparecen las preguntas, por lo que tampoco sirve para nada. No se puede cortar y pegar ni se puede imprimir.

En fin, que para subsanar esta injusticia e incomodidad, he extraído las preguntas y os las paso en un formato más acorde, por si queréis hacer vuestras hojas de cálculo, incluir vuestros comentarios, generar gráficas o mejorarla.

Para los curiosos, la extracción la he hecho así. Primero descomprimís el fichero unzip preguntas.jar, luego un pequeño find nos dice dónde está lo que buscamos find . -type f -exec strings -e S \{\} \; -print | less. Parece que está en questions/ArbolPreguntas.class.

Ahora lo pasamos a un fichero strings -e S ArbolPreguntas.jar > preguntas.txt Y a partir de ahí, con algunos vim commands, llegamos a
este fichero. La codificación es UTF-8, por si alguno no lo ve bien.

Se aceptan comentarios sobre las preguntas, sobre la utilidad de las mismas, sobre las herramientas java del CCN, etc. o nuevas preguntas que se os ocurran. También se aceptan ficheros formateados para usar como cuestionario (compartidlo en googledocs con sevillasecandbeer y lo enlazamos desde aquí).