Programa COOPERA

El pasado mes de mayo el Servicio de Protección y Seguridad de la Guardia Civil (SEPROSE) puso en marcha el programa COOPERA. Este programa pretende mejorar el Plan General de Colaboración vigente desde 2006, potenciando la cooperación con el sector de la seguridad privada a través del intercambio de información operativa de interés en los ámbitos de competencia que afecten a ambos colectivos, con el objetivo de integrar los servicios de seguridad públicos y privados y potenciar así las capacidades de ambos, en beneficio directo de la seguridad global. Dentro de este programa, al que como Departamento de Seguridad legalmente constituido nos hemos adscrito, se va a intercambiar de forma bidireccional y directa información de interés para todas las partes, a través de web, correo electrónico, SMS… a dos niveles diferenciados: directivo (SEPROSE) y operativo (Comandancias). Además del intercambio habitual, se han conformado diferentes grupos de coordinación sectoriales (banca, infraestructuras críticas…) e incluso se van a establecer modelos de formación comunes para Guardia Civil y Seguridad Privada.

Esta excelente iniciativa pone de manifiesto, una vez más, algunos aspectos de seguridad que ya hemos comentado en diferentes posts de este blog: en primer lugar, los referentes al intercambio de información, al information sharing del que tanto hablan los anglosajones y que, por fin, parece empezar a calar en España. Como en repetidas ocasiones hemos defendido desde aquí, esta tendencia debe ser en la actualidad la tónica general en seguridad, con las debidas garantías y con las relaciones de confianza necesarias para que la información fluya en las direcciones en las que debe hacerlo, permitiendo así reducir los riesgos de todos los actores y repercutiendo por tanto en un beneficio directo para todos. No ahondaremos más en los beneficios del information sharing -de momento, porque seguro que hablaremos más del tema- para que no nos llameis pesados :)

En segundo lugar, otro aspecto muy destacable del programa COOPERA es la colaboración entre seguridad pública y privada; de la misma forma que hace casi treinta años existía un grave problema de seguridad bancaria relacionado con el número y las consecuencias de los atracos a sucursales, y por tanto se hizo necesaria la creación de la Comisión Nacional de Seguridad (Directores de Seguridad de Cajas de Ahorros Confederadas) para reducir este problema, mediante la colaboración tanto entre entidades como con Seguridad Pública, en la actualidad existe otra tipología de amenazas, diferente de aquella, que hace necesario reforzar una vez más la colaboración entre Seguridad Pública (en este caso, Guardia Civil) y Privada, incrementando la complementariedad y reduciendo la subordinación que, aún en ocasiones, existe. A fin de cuentas, todos trabajamos en lo mismo, y si todos arrimamos el hombre, a todos nos irá mejor; además, no es de recibo que en muchas ocasiones la colaboración entre empresa privada y FFCCSE sea más personal (conozco a fulanito en la Comandancia o en la Jefatura Superior y le llamo para que me eche una mano, para compartir información, o para tomar una cerveza) que institucional y, sin descuidar la primera (seguiré tomándome una cerveza con quien me parezca :), formalizar las vías de cooperación creo que nos interesa a todas las partes.

Un tercer y último gran aspecto que queremos comentar en este blog es la convergencia reflejada en la iniciativa de la Guardia Civil, que aglutina bajo un mismo paraguas a Departamentos de Seguridad de muy diversa índole y que trabajan en sectores a priori disjuntos y sin relación directa: desde explosivos a protección de la información, pasando por CRA o medioambiente. Esta convergencia de la que a todos nos gusta hablar se traduce ahora en acciones concretas, en vías de trabajo y formación que, con los diferentes puntos de vista que cada uno de nosotros puede aportar a los demás, contribuirán sin duda a mejorar nuestras visiones, casi siempre acotadas, de la seguridad. De nuevo, no seguiremos hablando de convergencia para que no nos llameis pesados…

En definitiva, y ya para acabar, nuestra más sincera enhorabuena a la Guardia Civil, y en especial al SEPROSE, por la puesta en marcha de este programa; confiemos en que dé sus frutos, cumpliendo sus objetivos y estableciendo líneas de comunicación y colaboración robustas entre diferentes actores, públicos y privados, que permitan mejorar de forma global -más allá de empresas, departamentos, grupos…- la seguridad. Y por supuesto, que cunda el ejemplo y que salgan a la luz iniciativas similares o se mejoren las actuales; creo que, a fin de cuentas, la seguridad es algo que a todos nos afecta, por lo que debemos ser los primeros interesados en colaborar…

IDS en el cortafuegos

A la hora de hablar de detección de intrusos, un modelo dentro de los NIDS que no es muy habitual es la detección en el cortafuegos (o en los cortafuegos) corporativo; digo que no es muy habitual -al menos por mi experiencia- y no sé muy bien por qué, ya que bajo mi punto de vista se trata de algo bastante sencillo de implantar en la mayor parte de firewalls, con un mantenimiento simple y, sobre todo, con una tasa muy baja de falsos positivos. Además, creo que le ahorraría bastante trabajo a los sistemas de detección ubicados en las redes internas, algo que en el caso de seguridad pasiva (IDS) se traduce directamente en un ahorro de costes en el personal dedicado a revisar las alertas de un SNORT o similar.

Un cortafuegos suele manejarse muy bien con las cabeceras de los paquetes y menos bien (o simplemente, muy mal) con los campos de datos; así, para hablar de detección en el cortafuegos, podemos centrarnos en los ataques -o en las anomalías, por no hablar aún de ataques- de dichas cabeceras. ¿Y qué información hay en los campos de cabecera de protocolos como TCP o IP? Direcciones origen y destino, puertos origen y destino, información del protocolo, bits URG, FIN, etc. Un montón de información que, correctamente analizada, permitirá bloquear tráficos anómalos que tratan de entrar en nuestra red y nos proporcionará información útil de eventos cuanto menos sospechosos.

Para empezar, lo obvio: de una determinada zona de red -interna o externa- no puede llegar tráfico con dirección origen otra zona de red. Así, si nuestra red de usuarios tiene un direccionamiento 192.168.1.0/24, desde esa red no debería llegar nunca un paquete con origen en otro direccionamiento -al menos, en condiciones normales-, por lo que podemos definir reglas que acoten qué direcciones origen pueden provenir de cada zona de red. Y seguimos con más cosas obvias: hay puertos que deben estar filtrados sí o sí (o casi sí), y cualquier actividad con destino dichos puertos puede ser a priori considerada sospechosa. ¿Quién utiliza hoy en día el protocolo UUCP? ¿Y gopher? ¿Alguien conoce algún uso lícito y habitual de chargen? ¿Y de finger? Si en mi cortafuegos veo tráfico hacia esos puertos, lo más probable es que me encuentre ante un ataque -típicamente un barrido de puertos, un information gathering o incluso malware-, por lo que me va a interesar bloquear y registrar este tráfico. Algunos puertos interesantes para enterarnos de estas acciones -sin menoscabo, por supuesto, de que todo lo no explícitamente autorizado esté cortado en nuestro firewall- pueden ser discard, daytime, chargen, gopher, finger, pop2, biff, r-* o uucp, por citar sólo unos cuantos. En el caso de puertos utilizados por malware, algunos muy conocidos son 12345 (NetBus) o 31337 (BackOrifice), y de la misma forma podemos bloquearlos y registrar su uso con cualquier cortafuegos (ejemplo para ipf, Solaris 10):


block in log quick on hme0 from any to any port = 31337
block in log quick on hme0 from any to any port = 12345
block in log quick on hme0 from any to any port = 70
block in log quick on hme0 from any to any port = 79
block in log quick on hme0 from any to any port = 540
...

Más cosas a considerar; en el RFC 3330 se definen unos rangos de direcciones IP “especiales” -no asignadas, privadas, bucle local…-, direcciones que no deben encontrarse en determinadas patas de nuestro cortafuegos; así, por ejemplo, en la pata de conexión con Internet nunca deberemos ver tráfico -salvo configuraciones excepcionales- que provenga de estas direcciones, y si lo vemos, al menos deberemos prestarle atención:


block in log quick on hme0 from 192.168.0.0/16 to any
block in log quick on hme0 from 0.0.0.0/8 to any
block in log quick on hme0 from 172.16.0.0/12 to any
block in log quick on hme0 from 198.18.0.0/15 to any
...

Seguimos: violaciones de protocolo o uso de protocolos fuera de lo habitual. Por definición de los protocolos TCP e IP, existen ciertas combinaciones de bits que no pueden encontrarse, en situación normal, en las cabeceras de los paquetes; así, no es correcto que un paquete TCP tenga activos los bits FIN y SYN de forma simultánea, ya que eso violaría el protocolo (estaríamos solicitando un inicio de conexión y a la vez un cierre, algo no coherente), ni tampoco está aceptado que una trama IP tenga activos al mismo tiempo los bits DF (Don’t Fragment) y MF (More Fragments). Si vemos tráfico con estas violaciones, se trata de una anomalía -lo de antes, por no llamarle ataque directamente- que nos interesa conocer, ya que los ataques de fragmentación IP o los barridos de puertos en base a violaciones del protocolo TCP son el pan nuestro de cada día (una herramienta como nmap implementa diferentes técnicas de este tipo). Adicionalmente, podemos encontrarnos tramas válidas según protocolo pero no habituales, y que por lo tanto puede ser necesario registrar. Algunas reglas más para ipf (podemos encontrar auténticos recopilatorios en Internet, y escoger las que más nos interesen):


block in log proto tcp all with short
block in log quick on hme0 all with opt lsrr
block in log quick on hme0 all with opt ssrr
block in log quick on hme0 proto tcp all flags FUP
block in log quick on hme0 proto tcp all flags FUP/FUP
block in log quick on hme0 proto tcp all flags /FSRPAU
block in log quick on hme0 proto tcp all flags FSRPAU
block in log quick on hme0 proto tcp all flags SF/SFRA
block in log quick on hme0 proto tcp all flags /SFRA
block in log quick on hme0 proto tcp all flags F/SFRA
block in log quick on hme0 proto tcp all flags U/SFRAU
block in log quick on hme0 proto tcp all flags P
block in log quick on hme0 proto tcp all flags FUP/WEUAPRSF
block in log quick on hme0 proto tcp all flags WEUAPRSF/WEUAPRSF
block in log quick on hme0 proto tcp all flags SRAFU/WEUAPRSF
block in log quick on hme0 proto tcp all flags /WEUAPRSF
block in log quick on hme0 proto tcp all flags SR/SR
block in log quick on hme0 proto tcp all flags SF/SF
block in log quick on hme0 proto tcp all flags /S

Con estas líneas y algunas más tenemos de forma sencilla un mini sistema de detección de intrusos implantado en nuestro firewall ipf (en todos los cortafuegos habituales podemos hacer cosas parecidas), sistema que obviamente puede ser mejorado por todas partes pero que, de momento, será capaz de alertarnos ante tráficos sospechosos; las líneas anteriores, aparte de bloquear el tráfico, generarán un log en tiempo real (man ipmon), log que puede ser tratado con cualquier script para integrarlo en nuestro esquema de detección de intrusos global, que más allá del NIDS habitual debería recoger y procesar los registros todos los sistemas de detección que tengamos implantados, tanto a nivel de host como a nivel de red, para proporcionar información correlada en base a todos los datos de los diferentes IDS. Esto, por supuesto, sin entrar en técnicas que ya se alejan de lo que sería un NIDS en el cortafuegos, como utilizar return-rst en nuestro ipf para “contaminar” los resultados del atacante (útil frente a barridos de puertos) o ejecutar ciertas órdenes del sistema ante tráficos anómalos detectados, que ya es material para otro post :)

Seguridad sectorial (VIII): espectáculos de masas

Sin duda este fin de semana, en el que los amantes del deporte -ente los que no me incluyo- están disfrutando de los mundiales de Sudáfrica y de campeonato de Fórmula I en Valencia, es un momento inmejorable para aportar un nuevo post a la serie sobre seguridad sectorial, en este caso para hablar de los aspectos de seguridad en espectáculos de masas: competiciones deportivas, conciertos, actos políticos o sindicales, concentraciones de todo tipo…

Como en cualquier libro sobre seguridad podemos ver, toda actividad que implica grandes concentraciones de personas tiene implícitas amenazas como las avalanchas, el vandalismo, las agresiones o el terrorismo, por citar unas cuentas; sin duda la última de ellas, el terrorismo, es la más preocupante tanto para los organizadores como para la sociedad en general, ya que la simple amenaza puede causar un grave daño reputacional y cuantiosas pérdidas económicas -imaginemos un estadio que hay que “vaciar” en pleno partido por una amenaza de bomba-, por no hablar de los casos en los que la amenaza se materializa, añadiendo a los problemas anteriores daños materiales y contra la integridad física de las personas. Por ello, cualquier acto con una gran afluencia de personas debe disponer obligatoriamente de determinadas medidas de seguridad, que pueden ir desde el control de acceso -técnico o humano- a los recintos hasta un número concreto de vigilantes o policías; esto es especialmente necesario en aquellos actos en los que la amenaza pueda ser mayor, como los mítines políticos, eventos con una elevada concentración de personalidades o encuentros deportivos de los denominados “de alto riesgo”.

Por fortuna, a pesar de ser la de mayor impacto, el terrorismo no es la amenaza más probable en las concentraciones de masas. Las minorías extremistas o enfervorizadas suelen ser, más allá del terrorismo, el caldo de cultivo ideal para materializar otras amenazas propias de las grandes concentraciones, como las agresiones o el vandalismo; esto es especialmente frecuente en los encuentros deportivos -fútbol sobre todo-, en los que los grupos “ultra” deben ser controlados no sólo durante el encuentro, sino también antes y después de éste para evitar enfrentamientos con otros hinchas. También la actividad de estas minorías puede ser el origen de avalanchas humanas, aunque esta última amenaza puede ser causada de forma fortuita, simplemente por el elevado movimiento de personas en un determinado lugar (todos recordamos los problemas de seguridad que año tras año se producen en la peregrinación musulmana a La Meca).

Para evitar estos -y otros- problemas, en todas las actividades que implican una gran concentración de personas debe disponer, como hemos dicho, de personal de seguridad pública y privada y de medios técnicos suficientes para prevenir y detectar cualquier amenaza, así como para minimizar el impacto en caso de que ésta se materialice (vías de evacuación, Plan Integral de Seguridad, planes de emergencia…). Los organizadores del evento tienen una serie de obligaciones bien definidas desde el punto de vista de seguridad, que en caso de no ser cumplidas pueden acarrear sanciones más o menos duras (tema por otra parte muy discutible, ya que en ocasiones hay casos claros de incumplimiento y las sanciones aplicables son irrisorias).

Para hacernos una idea de la importancia de la seguridad en este tipo de eventos, simplemente unos datos que leía en el número de este mes de Security Management, la revista de ASIS, relativos al mundial de fútbol de Sudáfrica: SAPS (South African Police Service) ha renovado buena parte de su equipamiento de cara a la celebración del evento, incluyendo desde helicópteros a cañones de agua, ha reforzado su personal con 55.000 nuevos oficiales, y 8.500 policías del cuerpo han realizado un curso ad hoc de un año de duración en Francia, cuya Gendarmería tiene experiencia en la seguridad de estos eventos desde el mundial celebrado en 1998 en el país galo. Todo esto son simples números, sin hablar de las medidas organizativas o técnicas implantadas para el evento: perímetros de seguridad alrededor de los estadios, protección especial de altos cargos, control de acceso al país con conexión directa a bases de datos de INTERPOL, etc. Como vemos, desde el punto de vista de seguridad, la celebración de un mundial es mucho más compleja de lo que nos parece a los simples espectadores (y eso sin profundizar en protección de la información, que evidentemente también requieren estos eventos).

Habilitaciones, titulaciones… y todo lo demás

Leía esta mañana en BELT una noticia que hacía referencia a la falta de habilitación profesional del Director de Seguridad del Barça: esto es, no tiene un TIP en vigor que lo habilite como Director de Seguridad por el Ministerio del Interior. En España, las figuras contempladas en el ámbito de la seguridad privada vienen definidas en la Ley 23/1992, de 30 de julio, de Seguridad Privada (LSP), y entre ellas encontramos al Director de Seguridad, al Jefe de Seguridad, al Escolta Privado o al Guarda Particular del Campo, por citar unas cuantas… todo lo que se salga de ahí, no está reconocido a día de hoy en España. Caso aparte es cómo las empresas de seguridad, sobre todo las que trabajan -o trabajamos- principalmente en seguridad de la información, denominen a su personal: CISO, CSO, CRO… son denominaciones que se utilizan con mayor o menor fortuna en cada caso, pero que desde luego no están oficialmente contempladas (ojo, hasta donde yo sé, y que alguien me corrija si me equivoco). Debate aparte es si es lícito, o ético, que una empresa utilice para su personal cargos que se corresponden con titulaciones oficiales si dicho personal carece de éstas, argumentando siempre que se trata de responsabilidades internas en la organización, no de atribuciones reconocidas oficialmente.

Más allá del hecho de que el Director de Seguridad del Barça tenga o no la habilitación correspondiente, esta noticia viene a plantearnos algunas cuestiones. La primera es relativa a la (necesaria, IMHO) regularización del personal de seguridad; como hemos dicho, todo lo que se salga de la LSP en España no está reconocido, y no debemos olvidar que el negocio de la seguridad de la información al que se dedican -o nos dedicamos- muchas empresas no deja de ser Seguridad Privada… pero sin legislar. Para ser Vigilante de Seguridad o Escolta Privado debes poseer una habilitación, pero para ser técnico de, consultor de o responsable de, no necesitamos nada… Volvemos a insistir en cosas ya comentadas en este mismo blog: ¿no sería necesario que se ampliaran las figuras del personal de seguridad reconocidas en la Ley de Seguridad Privada? Esta ley no se ha movido significativamente desde hace dieciocho años -una eternidad si hablamos de seguridad-, por lo que muchos creemos que ya va siendo hora de que se revise la ley y podamos empezar a hablar de otras figuras, como comentaba en mi post sobre la Ley Ómnibus. Así, todos tendríamos claro cuáles son las figuras oficialmente reconocidas con nuestra perspectiva actual de seguridad (convergencia, PIC, etc.), y quién está capacitado para dirigir un departamento de seguridad, para pertenecer a él o simplemente para desarrollar ciertos trabajos dentro del ámbito de la seguridad privada… más allá de la vertiente “clásica”.

Otra cuestión es qué pasa actualmente con estos puestos de seguridad privada “no oficial”… se trata de roles tan habituales que nadie se plantea sus implicaciones, pero lo cierto es que únicamente están reconocidos dentro de una organización, no más alla; un Director de Seguridad o un Ingeniero en Informática es eso mismo aquí y en la China Popular (como diría alguien), mientras que un “Ingeniero de Seguridad Perimetral” o un “Responsable de Riesgos” no tienen sentido fuera de la organización que les ha asignado esa categoría. Volvemos al tema de las atribuciones profesionales, al quién puede hacer qué; “Director de Seguridad” es una habilitación propia del Ministerio del Interior, mientras que “Director de Seguridad de la Información” -el famoso CISO-, o “Consultor de Seguridad” no es ninguna titulación oficial, con lo que cualquiera puede adjudicarse este papel en su tarjeta de visita… De nuevo lo de siempre: ¿quién puede firmar una auditoría? ¿quién puede dirigir un departamento de seguridad que trabaje en protección de la información? Ahora mismo no existe regulación alguna más alla de la LSP (que por supuesto no toca seguridad de la información como tal), por lo que cada organización hace de su capa un sayo; yo puedo decir que tal persona es Técnico de Seguridad, Consultor de Seguridad o Ingeniero Jefe de Seguridad… ¿y? Sólo dependerá del buen criterio -o del mal criterio- de cada empresa el titulito que se asigne a su personal de seguridad…

Creo que una regulación del personal de seguridad sería muy conveniente tanto para nuestra profesión como para nuestros clientes, que por fin podrían saber quién les puede realizar determinados proyectos o prestar ciertos servicios, y en base a qué; y por supuesto, si llegamos al punto en que el personal de seguridad se regula correctamente más allá de la seguridad tradicional, no olvidemos que dicho personal tendrá una serie de obligaciones y responsabilidades -no como sucede ahora en seguridad de la información-; en el momento en el que alguien puede retirarme mi habilitación como Director de Seguridad si hago mal mi trabajo, impidiéndome desempeñar ese puesto en un futuro, me pensaré dos veces el entregar un informe o el resultado de un análisis de riesgos, por poner un ejemplo.

Para acabar, un último apunte: no empecemos ahora con que si para dirigir, auditar o implantar hace falta un CISSP, un SANS, un CISA, un CISO o un CASI, que me entra la risa… estas -y otras- certificaciones son títulos de una “academia” concreta (ISACA, ISC2, SANS…), y por muy reconocidos que estén o dejen de estar, hasta donde yo sé no son oficiales, al menos de momento; otra cosa es si demuestran o no conocimiento, o simplemente demuestran tiempo y dinero… pero para empezar a discutir quién puede hacer qué en seguridad, prefiero hacerlo por titulaciones oficiales o por habilitaciones propias del Ministerio del Interior, nos gusten más o menos…

Monitorizando usuarios en Solaris

Como llevo algunas noches de insomnio me ha dado por refrescar, tras algunos años olvidados en un cajón, aspectos de monitorización de usuarios en Solaris (Solaris 10, para ser exactos); y la verdad es que de lo que conocía -dejé de administrar máquinas Solaris “en serio” en su versión 7- a lo que me he encontrado en las nuevas versiones del operativo, hay alguna que otra diferencia que sorprende gratamente, y es que a pesar de que ahora sea un producto de Oracle, Solaris sigue siendo Solaris :)

Como siempre, para generar trazas “en serio” de la actividad de los usuarios podemos utilizar el Basic Security Module, habilitado mediante bsmconv(1M) y que nos dirá hasta qué usuario pestañea demasiado delante de la consola :) ¿Problemas? Alguno que otro… para empezar, requerimos reiniciar el sistema, cosa que ya de por sí a nadie le gusta mucho… y para continuar, tenemos el problema histórico del volumen de datos que generamos: por muy bien que configuremos el módulo de auditoría, incluso si lo hacemos por usuario, la cantidad de registros que se almacenan en la máquina no deja de ser considerable… y lo peor de todo: la marcha atrás tras habilitar BSM en nuestro sistema implica de nuevo detener servicios (la orden bsmunconv hay que lanzarla en runlevel 1).

Aunque BSM es la solución correcta y definitiva si necesitamos un registro de auditoría al detalle, me ha sorprendido en Solaris 10 DTrace, un framework que permite monitorizar en tiempo real y sin parada de sistema determinados aspectos tanto del núcleo como del espacio de usuario; este framework incorpora un lenguaje de programación propio (“D”), que nos permite registrar, de forma sencilla, actividad en el sistema de cara a detectar problemas, a “tunear”, o simplemente a monitorizar determinada actividad en la máquina (accesos a un fichero, cambios en inodos, etc.). Por supuesto, para esto último no es tan completo como BSM -que insisto, es la solución correcta-, pero nos puede servir para sacarnos de más de un apuro en cuanto a conocer qué hacen nuestros usuarios.

Un ejemplo de monitorización sencilla: ¿qué órdenes ejecuta un determinado usuario? Mediante dtrace(1M), es trivial obtener esta información: ponemos “vigilantes”, generadores de información, en las llamadas al sistema exec() y familia, y la condición de que el UID del usuario que usa estas llamadas – que pasaremos como argumento al programa- sea uno en concreto; si esto se cumple, imprimimos la información que nos interesa:

# cat t.d
syscall::exec:return, syscall::exece:return
/ uid==$1 /
{
printf("%s %-20Y %S\n", probefunc, walltimestamp, curpsinfo->pr_psargs);
}
# dtrace -s prueba.d 100
dtrace: script 'prueba.d' matched 2 probes
CPU ID FUNCTION:NAME
0 108 exece:return exece 2010 Jun 9 18:54:17 ls
0 108 exece:return exece 2010 Jun 9 18:54:28 more prueba.d
#

Seguro que el código se puede mejorar, ya lo sé :) Más cosas que nos pueden interesar de la actividad de un usuario: archivos abiertos, conexiones de red…todo esto es bastante sencillo obtenerlo mediante dtrace(1M), sus probes y las condiciones adecuadas; podemos poner todo junto, y en bonito (para que nos muestre la información más legible, básicamente) en un script que invocaremos desde línea de órdenes:

# cat luser.d
#pragma D option quiet
/*
* Ejecucion de ordenes
*/
syscall::exec:return, syscall::exece:return
/ uid==$1 /
{
printf("%s %-20Y %S\n", probefunc, walltimestamp, curpsinfo->pr_psargs);
}
/*
* Acceso a FS
*/
syscall::open:entry, syscall::creat:entry,
syscall::open64:entry, syscall::creat64:entry,
syscall::unlink:entry, syscall::rename:entry
/ uid==$1 && strstr(stringof(copyinstr(arg0)), "/proc") == NULL /
/* Nos quitamos de la condicion el acceso a procfs */
{
printf("%s %Y %s\n", probefunc, walltimestamp, stringof(copyinstr(arg0)));
}
/*
* Acceso a red / TCP
*/
::tcp_send_data:entry
{
self->lport=((unsigned int) args[0]->tcp_tcph->th_lport[0] < <8) + (unsigned int) args[0]->tcp_tcph->th_lport[1];
dig1=(unsigned int) args[0]->tcp_tcph->th_fport[0];
dig2=(unsigned int) args[0]->tcp_tcph->th_fport[1];
dig1=dig1< <8; self->rport=((unsigned int) args[0]->tcp_tcph->th_fport[0] < <8) + (unsigned int) args[0]->tcp_tcph->th_fport[1];
srcaddr=(unsigned int) (args[0]->tcp_ipha->ipha_src);
dstaddr=(unsigned int) (args[0]->tcp_ipha->ipha_dst);
self->octect[0]=srcaddr>>3*8 & 0xFF;
self->octect[1]=srcaddr>>2*8 & 0xFF;
self->octect[2]=srcaddr>>1*8 & 0xFF;
self->octect[3]=srcaddr>>0*8 & 0xFF;
self->octect[4]=dstaddr>>3*8 & 0xFF;
self->octect[5]=dstaddr>>2*8 & 0xFF;
self->octect[6]=dstaddr>>1*8 & 0xFF;
self->octect[7]=dstaddr>>0*8 & 0xFF;
self->ok=1;
}
::tcp_send_data:entry
/ self->ok && uid==$1 /
{
printf("%s %Y %d.%d.%d.%d:%d -> %d.%d.%d.%d:%d\n", probefunc,walltimestamp,self->octect[0],self->octect[1],self->octect[2],self->octect[3], self->lport,self->octect[4],self->octect[5],self->octect[6],self->octect[7],self->rport);
self->ok=0;
}
#

Al invocarlo mediante dtrace(1M), la salida que obtendremos será similar a la siguiente -con muchos más datos que habrá que filtrar, no estoy ahora para pulir el código que, insisto, es un simple ejemplo y tendrá N fallos y mejoras-):

tcp_send_data 2010 Jun 9 19:00:37 192.168.1.2:22 -> 192.168.1.5:37963
tcp_send_data 2010 Jun 9 19:00:38 192.168.1.2:22 -> 192.168.1.5:37964
tcp_send_data 2010 Jun 9 19:00:38 192.168.1.2:22 -> 192.168.1.5:37963
exece 2010 Jun 9 19:00:38 cat /home/toni/fbsd-como\0
open 2010 Jun 9 19:00:38 /var/ld/ld.config
open 2010 Jun 9 19:00:38 /lib/libc.so.1
open 2010 Jun 9 19:00:38 /platform/SUNW,Ultra-5_10/lib/libc_psr.so.1

Así, mediante dtrace(1M), y de una forma muy sencilla, estamos en disposición de monitorizar muchísimas acciones -en este caso de un usuario concreto- que pueden servirnos para incrementar considerablemente la seguridad de nuestros sistemas Solaris desde el punto de vista de monitorización de la actividad (aparte de para resolver algún problema en las máquinas). Por supuesto, con un ratito de búsqueda en Google tendremos acceso a un montón de ejemplos de programas en D que podemos adaptar y aprovechar para crear un luser.d en condiciones :)

En definitiva, dtrace(1M) es una herramienta que no conocía más que de oídas y que, a poco que he empezado a tocarla, me ha sorprendido muy gratamente (tanto por su capacidad como por su sencillez) para la monitorización de ciertas actividades concretas del sistema o de nuestros usuarios, sin necesidad de meternos en el “gran” BSM… además, puede ser muy útil en aquellos casos en los que BSM no esté habilitado de antemano, por ejemplo si nos enfrentamos a un análisis forense de una Solaris comprometida… en fin, que seguiremos informando :) Por cierto, ¿alguien se anima a explicarnos algo similar en Linux, Windows, AIX, etc.? Sé que Dtrace se ha migrado -o se está migrando- a BSD, pero no sé si tenemos algo de capacidades similares en otros entornos (es que ya no soy técnico :)

La Ley Ómnibus…¿y?

El pasado día 26 la Unidad Central de Seguridad Privada (Cuerpo Nacional de Policía) hacía llegar una nota informativa acerca de las implicaciones de la conocida como Ley Ómnibus (Ley 25/2009, de 22 de diciembre, de modificación de diversas leyes para su adaptación a la Ley sobre el libre acceso a las actividades de servicios y su ejercicio) en el régimen de autorización, inspección y sanción en materia de Seguridad Privada.

El resumen de la situación es sencillo: hasta este momento, sólo las empresas de seguridad privada (esto es, las autorizadas por el Ministerio del Interior con arreglo al artículo 5 de la Ley 23/1992, de 30 de julio, de Seguridad Privada) estaban capacitadas para la instalación y mantenimiento de aparatos, dispositivos y sistemas de seguridad; con la disposición que introduce la Ley Ómnibus, se liberaliza el servicio, permitiendo la venta, entrega, instalación y mantenimiento de los equipos o sistemas de seguridad a los que se hace referencia por parte de particulares o empresas distintas a las de Seguridad Privada, siempre que la instalación no implique una conexión a CRA o CECON, por lo que -con ciertas salvedades- ya no es necesario recurrir a empresas autorizadas por el Ministerio para la instalación o manejo de estos dispositivos (por ejemplo, en el caso de soluciones de videovigilancia), y por supuesto siempre que el prestador no se dedique a otras actividades de Seguridad Privada establecidas legalmente.

Las implicaciones de esta ley están generando muchos comentarios en el ámbito de la seguridad; de un lado, están las empresas de Seguridad Privada “clásicas” que ven cómo se liberaliza una parte de su nicho de mercado, hasta ahora fuertemente regulado y restringido a unos pocos, y por otra están las empresas de servicios que ven cómo se eliminan las barreras a ese negocio que hasta ahora tenían vetado. Como siempre, no ha llovido a gusto de todos, y cada uno defiende sus intereses como buenamente puede.

Más allá de apoyos y rechazos, de buenos y malos, de problemas y soluciones… en los que no voy a entrar esta vez (cada uno tiene sus razones y todas, hasta cierto punto, parecen razonables), y por supuesto más allá de las implicaciones -y lagunas- que esta Ley pueda introducir con respecto a otras (seguro que los compañeros de Consultoría van a preparar próximamente un post sobre la Ley Ómnibus y sus implicaciones en videovigilancia -por poner un ejemplo- en relación a la LOPD), para mí, la Ley Ómnibus no ha hecho más que poner el dedo en la llaga de un problema mucho más serio que muchos venimos señalando desde hace años: la necesaria remodelización al completo de la Ley de Seguridad Privada. Nos cansamos -todos- de decir que la seguridad ha cambiado mucho en los últimos años (11S, inteligencia, information sharing, terrorismo, convergencia…) y, sin embargo, en España la regulamos con una ley que está a punto de cumplir la mayoría de edad…

La LSP, bajo mi punto de vista, necesita no una disposición adicional sexta como la introducida por la Ley Ómnibus (y podemos discutir si es buena o mala), sino un lavado de cara completo, que defina nuevos roles en materia de Seguridad Privada (¿la hora del “auditor” junto al “inspector”? ¿la hora del “cibervigilante” junto al “vigilante”?), que marque nuevos requisitos de formación para el personal de seguridad privada (no es admisible, bajo ningún concepto, que el Director de Seguridad de una entidad financiera considere, como alguno me ha llegado a decir, que el phishing no es un problema de seguridad para él… imagino que porque no sabe combatirlo con una pistola) y que actualice las regulaciones, requisitos y demás que contempla la Ley -y por extensión, el Reglamento de Seguridad Privada- para trabajar en el ámbito de la seguridad.

Y es que, con todas los cambios que a diario surgen en el ámbito de la seguridad, creo que estas legislaciones son, cuanto menos, obsoletas; ojo, no hablo de eliminarlas, sino simplemente de adaptarlas, incluyendo una visión mucho más amplia de lo que es en la actualidad la Seguridad Privada y el rol que tiene en nuestra sociedad. Para ser Vigilante de Seguridad o Director de Seguridad Privada hacen falta unos requisitos perfectamente definidos por el Ministerio del Interior (seguramente mejorables, pero definidos). Para trabajar en otros ámbitos de la seguridad, como el de la seguridad de la información, no hace falta nada. ¿Quién puede hacer una auditoría de ISO 28000 o de ISO 27002? ¿Un ingeniero? ¿Un abogado? ¿Un CISA? ¿Todos? ¿Nadie? ¿Por qué para proteger un supermercado del robo de productos se exigen unos requisitos, y para proteger la información de un VIP no?

Hasta que no regulemos (o desregulemos, ¿por qué no?) de alguna forma estos aspectos -y si empezamos a regularlos, seguramente discutiremos, pero eso es bueno- seguiremos pegándonos por los detalles. Como los de la Ley Ómnibus.

GOTO VII: privacidad vs. todo lo demás

De vez en cuando surgen noticias -casi siempre, muy sensacionalistas- acerca de nuevas medidas de seguridad que suponen una “importante” violación de nuestra privacidad: desde la videovigilancia en las calles (un lugar especialmente privado por definición :) hasta la necesidad de descalzarnos en los aeropuertos (desde luego, una humillación a la que sólo unos pocos sobreviven). Qué quieren que les diga: frente a los que claman al cielo, yo suelo estar de acuerdo con estas medidas. ¡Toma GOTO! :)

Maticemos en primer lugar el “suelo estar”; mi opinión es que casi cualquier medida que aporte seguridad suele tener inconvenientes de uno u otro tipo, pero si “compensa” (es decir, si el incremento de seguridad efectivo es superior a las molestias causadas por esos inconvenientes) y entra dentro de lo “normal” (de lo razonable, aunque esto suela ser subjetivo), vale la pena implantarla. ¿Qué problema hay entonces? Bajo mi punto de vista, la discusión habría que trasladarla a tres asuntos: el primero, el de la eficacia -no me atrevo a hablar de eficiencia- (si la medida aporta realmente seguridad); el segundo, el del grado de abuso (el mal uso o abuso que se pueda hacer de la información recopilada con fines que nada tienen que ver con su objetivo principal, como espiar a tu pareja, curiosear, molestar al vecino, chantajear…) y, el tercero y último, el de la aceptabilidad, esa normalidad subjetiva a la que hacía referencia.

De esta forma, cuando surge una nueva salvaguarda de esas que son polémicas, debemos plantearnos en primer lugar si la medida es efectiva. ¿Evitan atentados los registros minuciosos en los aeropuertos? ¿Evita la delincuencia una videocámara en las calles? ¿Minimiza el riesgo un perfil psicológico de una persona? Yo creo que muchas de las medidas, por no decir todas, más impopulares de los últimos años (desde la videovigilancia en las calles a temas como ECHELON o CARNIVORE) sí que son relativamente efectivas, nos gusten o no, y por eso se implantan. No nos engañemos: a ningún gobierno, servicio de inteligencia, FFCCSE, etc. a título global les interesan, en general, nuestros correos electrónicos, nuestros paseos por el centro, o nuestras retiradas de efectivo para hacer la compra (eso no implica que a personas individuales, dentro de esas organizaciones, pueda interesarles, como se comenta en el punto siguiente). Así, mi opinión es que si un delincuente puede robar un coche en plena calle, y posteriormente una videocámara ayuda a identificarlo -o incluso antes de que se cometa el delito actúa de forma disuasoria-, bienvenida sea.

A continuación, pensemos en el uso o abuso de la información recopilada con estas técnicas “intrusivas”; por muchas precauciones que se tomen a la hora de elegir al personal, por mucho control interno, por mucha disuasión… no podemos evitar que, en última instancia, una persona con acceso a los registros guardados, pueda hacer un mal uso de ellos; contra esto, sin menoscabo de medidas de prevención y detección, yo creo que lo más efectivo es la respuesta contundente cuando se demuestra un mal uso de la información (este tema daría para un post entero :). Si se demuestra que un administrador de sistemas usa la información de seguridad para publicar debilidades de sus compañeros, que un vigilante de seguridad usa la videocámara de un cajero para controlar a su vecino o que un policía se dedica a espiar a su novia gracias a las cámaras en la calle, deberían ser automáticamente despedidos, para empezar, y establecer un marco legislativo duro que les haga pensarse más de dos veces el mal uso de las medidas de seguridad. Pero al final, una de las máximas de la seguridad, nos dice que tenemos que acabar confiando en alguien o algo -eso es indiscutible- y, sin ese mínimo confiable, todo lo demás se desmorona; por tanto, estamos obligados a confiar -la discusión podría ser “de quién me fío”-. También es importante la capacidad de abuso que tiene la información almacenada: no es lo mismo un video de nuestro paseo dominical, que un historial clínico completo o un perfil comercial realizado ad hoc, y por tanto la forma de acceso a los datos y los tipos de personas que pueden acceder en cada caso a esos registros deben ser diferentes.

Para acabar, el concepto más subjetivo: el de “normalidad” de las medidas, esto es, el del grado de intromisión en nuestra intimidad, el grado de aceptabilidad (muy ligado al grado de abuso al que hemos hecho referencia). Creo que ninguna de las medidas impopulares que saltan a los medios de comunicación es, para mí, especialmente inaceptable; ¿quitarme el cinturón o los zapatos en el aeropuerto? no me parece lo peor que me haya pasado en mi vida, ni de lejos. ¿Que el gobierno espía mi correo electrónico? Lo dudo, pero si lo hicieran, que se diviertan. ¿Que para entrar en Estados Unidos me exigen firmar nosecuántos documentos con pelos y señales de mi vida? Son libres de decidir quién entra en su territorio y cómo, y como a mí nadie me obliga a ir allí, si no estoy de acuerdo con sus medidas me voy de viaje a Salamanca, donde no me piden ningún dato, no violan mi privacidad ni mancillan mi honor y, sobre todo, seguro que es más bonita y tiene mejores tapas que cualquier ciudad de los USA :) Otra cosa sería que, como medida de seguridad, nos obligaran a todos los ciudadanos a presentarnos diariamente en un juzgado: aquí la aceptabilidad -insisto, subjetiva- me parece nula, por lo que una medida de este tipo para mí sería incorrecta (eso sin entrar en temas de eficacia).

En resumen, cuando leamos una noticia sensacionalista, y surjan las voces de siempre clamando por nuestra privacidad a toda costa y la violación de nuestros derechos y blablabla, creo que deberíamos plantearnos en frío, con respecto a la medida que se quiere aplicar, los tres puntos comentados aquí: su eficacia, su grado de abuso y su aceptabilidad -este más sujeto a discusión-. Y fijarnos dónde pone cada uno su nivel de aceptabilidad, que al final, nos guste o no, es el factor que decide en ocasiones la implantación de la salvaguarda en cuestión.

I Encuentro Internacional CIIP: Taller de gestión de riesgos

Siguiendo la línea de entradas sobre el I Encuentro Internacional CIIP para la Ciberseguridad y Protección de Infraestructuras Críticas, organizado por el CNPIC (Centro Nacional para la Protección de las Infraestructuras Críticas) y realizado en Madrid los días 18 y 19 de febrero, vamos a comentar los resultados del Taller II, “Gestión de Riesgos: identificación y clasificación de riesgos, amenazas y vulnerabilidades”, coordinado por José Antonio Mañas. Más allá de anécdotas, comentarios y discusiones, todos los asistentes al taller coincidimos en plantear, como resumen del trabajo, las siguientes conclusiones:

Muy importantes

  • Hay que profundizar más en la seguridad de sistemas de control, electrónica industrial, SCADAs y similar… Con demasiada frecuencia desconocemos los riesgos que introducen en nuestras organizaciones, algo que en el caso de la infraestructura crítica nacional es más que preocupante.
  • La comunidad de inteligencia debería “bajar” al mundo real de vez en cuando. Suele haber una importante diferencia entre lo que se plantea desde un centro de seguridad, incluso en ocasiones muy estratégico y poco operativo, y la realidad del día a día en una presa, un banco o un puerto, por poner ejemplos concretos.
  • Existen incoherencias entre el deber de transparencia y el deber de secreto que existe en las infraestructuras críticas nacionales, y dichas incoherencias deben ser resueltas. A modo de ejemplo, una central nuclear debe facilitar su análisis de riesgos al ayuntamiento del municipio en el que se encuentra, pero esa obligación… ¿no puede suponer en sí misma un peligro para la seguridad de la central? ¿no debería considerarse secreto dicho análisis? ¡Aclarémonos!
  • Se deben gestionar correctamente las expectativas con todos los ciudadanos. La protección de infraestructura crítica nacional está muy en boga, pero ¿hasta qué punto es crítica, importante, muy importante… o una tontería? Sin duda, el grueso de la ciudadanía lo desconoce, y puede llegar a ver esto como un gasto innecesario, y más en estos tiempos.

[Read more…]

Riesgo humano

Hace ya unos meses, en este mismo blog, comentábamos la seguridad de los procesos de negocio y de los diferentes factores de riesgo (legal, técnico…) que pueden degradar dichos procesos; hablábamos en ese post del riesgo humano, ya que las personas son un activo crítico de las organizaciones y, como tal, pueden introducir riesgos en éstas, riesgos que como siempre debemos tratar de forma adecuada. Pero el paso previo al tratamiento de riesgos es, como siempre, su análisis, y para analizar estos riesgos debemos ser capaces de determinar amenazas, probabilidades e impactos que pueden causar las pesonas en la organización.

Bajo mi punto de vista, las amenazas derivadas del factor humano son claras: todas las englobadas bajo el paraguas de amenazas corporativas (errores), las derivadas de actividades sociales (accidentes) y las derivadas de actividades antisociales (delitos); incluso rizando el rizo, podríamos hablar del factor humano en las amenazas de origen industrial y, siendo todavía más retorcidos, en las de origen natural. De la misma forma, los impactos asociados a estas amenazas también suelen estar más o menos claros, y estarán —con toda probabilidad— en la parte más alta de la escala de impactos que queramos utilizar en nuestro análisis. ¿Dónde está entonces lo que más nos interesa? En la medida de la probabilidad, como casi siempre…

Para analizar probabilidades a la hora de hablar del riesgo humano, una aproximación que me gusta mucho —adaptándola a nuestras circunstancias, por supuesto— es la presentada en [1]. La idea resumida y simplificada es que cualquier persona está modelizada por una serie de perfiles que la definen, perfiles afectados además por una serie de condiciones de contorno (relaciones, privilegios, motivaciones…) y de eventos externos o internos a la organización que pueden provocar cambios sustanciales en el perfil de una persona (un cambio de estado civil, un ERE, la muerte de un familiar…). Si somos capaces de monitorizar esto, de una u otra forma, seremos capaces de establecer controles cuando sea necesario, y por tanto de mitigar los riesgos humanos no asumibles en la organización.

¿Cuáles son los perfiles que definen a las personas? Según el trabajo anterior, son los siguientes (existe un último perfil identificado en el trabajo, el de utilización de recursos informáticos, bajo mi punto de vista demasiado ad hoc para la detección de insiders y no tan apropiado para la modelización del riesgo humano en general):

  • Perfil económico (estabilidad, actividades sospechosas…).
  • Perfil social (estado civil, personas dependientes, hobbies…).
  • Perfil psicológico (adicciones, comportamientos anómalos, falta de carácter…).
  • Perfil profesional (inteligencia, satisfacción, implicación, reconocimiento…).
  • Perfil legal (antecedentes penales, procesos pendientes, sanciones…).
  • Perfil ideológico (implicaciones políticas, religiosas…).

Si somos capaces entonces de crear estos perfiles, y lo que es más importante, de monitorizarlos en el tiempo para detectar cambios sustanciales que puedan introducir riesgos en nuestra organización, habremos dado un paso importante para reducir los riesgos derivados del factor humano. Ahora la pregunta del millón: ¿cómo monitorizar todo esto? Lo ideal sería, como siempre, hacerlo todo de forma automática, con sensores que nos avisan en tiempo real de cambios potencialmente peligrosos en la modelizacion de una persona. Para empezar, esto no es siempre posible (¿cómo diseño un sensor que detecte comentarios sospechosos durante la hora del café? ¿y rasgos faciales que puedan implicar falta de interés o cansancio?) y, cuando lo es, no suele ser fácil; seguramente para el gobierno estadounidense puede ser trivial controlar en tiempo real las transacciones económicas o los antecedentes de sus ciudadanos, pero desde luego, para nosotros (pobres mortales) ni es fácil ni muchas veces sería legal.

¿Qué hacer entonces? Mientras trabajamos en monitorización automática de personas para calcular probabilidades cambiantes que puedan aumentar los niveles de riesgo (¡toma ya!), podemos conformarnos con realizar manualmente una modelización de las personas de nuestra organización, teniendo en cuenta los perfiles anteriores —u otros cualesquiera que nos sean útiles — y por supuesto con las consideraciones legales oportunas. En base a este análisis, y pensando un poco, seguramente no hará falta ser psicólogo para darnos cuenta de posibles riesgos (en cualquiera de los ámbitos de la seguridad, desde un insider a un riesgo reputacional) que pueden existir derivados de las personas, y por supuesto cuando identifiquemos un nivel de riesgo no asumible, deberemos tomar medidas -aplicar controles- contra el mismo. Ojo, estos controles no tienen por qué ser ni caros ni complejos: como casi siempre en seguridad, simplemente hace falta pensar.

[1] Mitigating insider sabotage and espionage: a review of the United States Air Force’s current posture. Erika C. Leach, Air Force Institute of Technology. Marzo, 2009.

GOTO III: Análisis de riesgos

Dentro de la serie GOTO, comenzada recientemente en este blog, quería dedicar hoy un post a las metodologías de análisis de riesgos; personalmente he trabajado con algunas de ellas -con demasiadas- y, si les digo la verdad, ninguna me convence realmente. Las hay sencillas, las hay complejas (sí, estoy pensando en MAGERIT :), las hay mejores y las hay peores, pero en todas hay aspectos, bajo mi punto de vista, manifiestamente mejorables. Para empezar, y aunque quizás sea lo menos importante… ¿por qué no se ponen de acuerdo en la terminología? ¿Por qué Mosler habla de “bienes” y MAGERIT de “activos”, por poner un ejemplo? ¿Por qué a lo que en unas metodologías se le llama “amenazas” en otras se le llama “riesgos”? Sinceramente, este es un tema únicamente produce confusión… ¿tan difícil es ponernos de acuerdo?

Hablando ya de cosas más serias, una cosa que me toca las narices es que en ninguna metodología (ni fuera de las mismas) me he encontrado un catálogo de amenazas decente. A día de hoy, que a todos se nos llena la boca hablando de seguridad integral, holística, global o como le queramos llamar, aún no he visto un catálogo de amenazas integral de verdad, que cubra todos los posibles problemas de una organización, sin focalizarse en aspectos físicos o lógicos en exclusiva… Creo que hasta que esto no exista, mal vamos a la hora de analizar riesgos desde el punto de vista de la protección del negocio: únicamente haremos análisis parciales, y deberemos realizar tres o cuatro visiones diferentes para hacernos una idea del mapa de riesgos de nuestra organización… Ojo, sé que es fácil criticar sin aportar alternativas y que cerrar un catálogo de este tipo es complejo, pero algún día habrá que hacerlo, ¿no? (yo estoy intentándolo, cuando consiga algo decente lo colgaré aquí… o no :).

Tampoco estoy muy de acuerdo con las medidas del impacto (o como le quieran llamar) que todas las metodologías incorporan; ¿por qué el método cuantitativo mixto, por poner un ejemplo, determina que algo es un desastre si nos causa un daño entre 150.000 y 1.500.000 euros, mientras que las consecuencias valoradas entre 75.000 y 150.000 euros son simplemente “muy serias”? Conozco más de una y de dos empresas para las que un daño de 149.999 euros significaría ya no un desastre, sino una catástrofe. ¿Quién es el señor cuantitativo mixto para decidir qué es para mí un impacto alto, muy alto o un épsilon alto? Bajo mi punto de vista, sería mucho más coherente ponderar estos valores en función del tipo de organización sobre la que se esté realizando el análisis, y no hablar -y calcular- en términos absolutos que, a la hora de la verdad, no representan más que una tabulación estándar del impacto: lo que para Telefónica puede ser una multita insignificante por incumplimiento de la LOPD, a cualquier autónomo le arruinaría la vida.

Los niveles de probabilidad, impacto o riesgo también son un tema discutible de las metodologías de análisis; ahora parece que lo más habitual es ubicar tres niveles (alto, medio y bajo, o 1, 2 y 3, por decir algo) frente a las metodologías que usan cinco. Este tema es muy discutible (¿cuál es la diferencia entre “alto” y “muy alto”?), pero cuando se trata de establecer una cuantificación, siempre he preferido -y esto es opinión personal, por supuesto- utilizar una escala con un número par de estados, para así evitar la tentación de “tirar” todo al punto medio. En cualquier caso, como siempre: ¿por qué no todos hablamos el mismo idioma? Ya sé que cada metodología es de su padre y de su madre, pero si los niveles son siempre iguales, podremos reaprovechar más el trabajo, y no empezar casi de cero si tenemos que cambiar de metodología.

Finalmente, las metodologías que tratan de cuantificar hasta el más mínimo detalle no son, para mí, muy acertadas -en especial cuando hablamos de protección de bienes intangibles-. Un análisis cuantitativo, donde se valore hasta el céntimo cada activo, cada décima de probabilidad, y cada euro de impacto, constituye un modelo matemático muy útil para explicar en la universidad, pero muy poco aplicable en el mundo real. ¿Qué impacto (en euros) tiene para una organización no tener la web levantada durante dos días? Probablemente, sabremos decir si es alto o muy alto, pero al que me diga que tiene un impacto de X euros (siendo X algo coherente), le invito a una cerveza :) Si nos tenemos que inventar -parcialmente- los datos de entrada, cualquier fórmula de cálculo del riesgo quedará muy bien en un Powerpoint, pero tendrá tanta validez como un billete de tres euros.

En resumen, ¿por qué no acordamos una metodología de análisis de riesgos global, que contemple todos los riesgos del negocio -y por tanto que nos sirva más eficaz y eficientemente para protegerlo- y que usemos todos de una forma más o menos igual? ¿Por qué no la flexibilizamos para hacerla operativa en cualquier tipo de organización -como a priori son las normas ISO-? Y si además la hiciéramos sencilla, ya sería la leche.

(N.d.E. Nos vemos, si quieren, el lunes que viene. En nombre del equipo de S2 Grupo, les deseamos una feliz nochevieja y próspero año nuevo a todos.)