Gripe A

Acabo de volver de vacaciones y, sinceramente, me ha sorprendido la cantidad de información que ha ido apareciendo en los medios —tanto generales como especializados— acerca de la gripe A (el ya famoso virus H1N1) y su impacto previsto en la sociedad a todos los niveles. Dejando a un lado los sensacionalismos propios de algunos medios (habría que recordar a ciertos “periodistas” que pandemia no significa que muera la mayor parte de la población mundial, como parecen hacernos creer), me parece interesante que en nuestro blog dediquemos al menos una entrada a este tema, ya que ciertamente la gripe puede ser un elemento decisivo en la continuidad de nuestro negocio, y por tanto en nuestra seguridad.

El Ministerio de Sanidad y Consumo español ha elaborado una guía, bastante coherente bajo mi punto de vista, acerca de la actuación recomendada frente a la gripe A para las empresas, de cara a asegurar la continuidad del negocio y la salud laboral en caso de pandemia. En esta guía, de lectura más que recomendable, se establecen una serie de medidas a valorar y, si corresponde, adoptar en los centro de trabajo; estas medidas se pueden agrupar en tres familias: de formación e información (hacia el personal y con terceros), de minimización del impacto (en la empresa, en su personal y en terceros -clientes, proveedores…-) y de contingencia en caso de que se materialice la amenaza.

Desde el punto de vista de los riesgos a los que está sometida una organización, la gripe A es un riesgo muy similar al de la gripe estacional —la de toda la vida, para entendernos—, pero con unos niveles de probabilidad e impacto superiores. Mayor probabilidad porque, si en una gripe epidémica se ve afectado un porcentaje que ronda el 15% de la población, en una gripe pandémica este nivel se incrementa en mayor o menor medida (en función de muchos factores), y adicionalmente los grupos de riesgo se ven modificados, y mayor impacto porque el daño causado por la pandemia en una organización es superior al producido durante una gripe normal: personas que no pueden desarrollar su actividad a causa de la gripe (fallecidos, hospitalizados, aislamiento, atención a familiares…), mayor tiempo de convalecencia, etc.

Bajo mi punto de vista, en nuestras organizaciones debemos efectuar un análisis inicial para valorar en primera instancia los riesgos derivados de la gripe A y su impacto en la continuidad de nuestro negocio; independientemente del resultado de este análisis, debemos establecer las medidas de prevención habituales -sin llevarlas a ningún extremo, por supuesto- y, si el análisis realizado nos indica que el riesgo de vernos afectados por la pandemia es considerable, debemos aplicar las salvaguardas correspondientes para mitigar el impacto en nuestra organización, desde el teletrabajo a la ubicación alternativa del personal, en función de los resultados obtenidos previamente. Vamos, lo habitual: tampoco estamos descubriendo nada ahora; pero sobre todo, creo que debemos huir del alarmismo que se ve en los medios ya que, hasta que datos fiables me digan lo contrario, creo que de esta pandemia no vamos a morirnos todos.

Seguridad de los procesos de negocio

Hace años, los que nos dedicábamos de una u otra forma a seguridad solíamos hablar mucho de la seguridad informática: aspectos exclusivamente lógicos, que aglutinaban contraseñas, cortafuegos, sistemas de detección de intrusos, permisos de archivos… importando poco o nada lo que hubiera por encima (usuarios, instalaciones físicas, organizaciones…). Tiempo después pasamos a hablar de la seguridad de los sistemas de información, que venía a ser muy similar pero ya era un concepto en el que se introducía la palabra “información” (un buen avance, ya que la seguridad per se es difícilmente defendible). Con el paso del tiempo, nos fuimos dando cuenta de que lo que que realmente importaba proteger era la información —no exclusivamente los sistemas que la tratan—, tanto desde el punto de vista de lógico como desde otros muchos puntos de vista (humano, organizativo, seguridad del papel…), y dejamos de hablar de seguridad de los sistemas para pasar a hablar de seguridad de la información, algo que se mantiene casi hasta la actualidad.

De un tiempo a esta parte, estamos empezando a dejar de hablar de seguridad de la información para hablar de seguridad de los procesos de negocio, intercalando en muchos casos el adjetivo “integral”. El resumen es muy sencillo: las organizaciones actuales están —o suelen, o deberían estar— orientadas al proceso de negocio, y así una organización ejecutará unos determinados procesos para poder sobrevivir. Si alguno de estos procesos falla de forma considerable, sin importar el porqué, se degrada la seguridad global y la organización se somete a un riesgo determinado, también global. De esta forma, el riesgo global de la organización, R, puede definirse como el sumatorio ponderado de los diferentes riesgos a que están sometidos sus procesos.

¿Y cuáles son los riesgos de estos procesos, y por extensión, los de la propia organización? Cada proceso, para ser ejecutado de forma correcta, completa y continua (esto es, que funcione tal y como debe hacerlo y de forma continuada en el tiempo), necesita de una gestión determinada (riesgo organizativo) para que unas personas de la organización (riesgo humano) puedan ejecutarlo satisfactoriamente con una técnica —o tecnología— concreta (riesgo técnico) y bajo unas condiciones de contorno establecidas (riesgo físico y riesgo legal); por encima de estos tipos de riesgos, tenemos riesgos adicionales, no englobados en ninguna de las categorías anteriores —por ejemplo, el riesgo semántico—, muchas veces fuera del control de la organización pero que puede degradar de forma significativa no sólo su imagen o marca, sino también su capacidad de operación. Así, el riesgo que afecta a un determinado proceso no es más que el sumatorio ponderado de los riesgos anteriores.

Obviamente, el escenario ideal sería llegar a nuestra oficina y ver el nivel de riesgo R; si es bajo, asumible, podemos ir a tomar un café. Si es medio, debemos ver qué proceso puede degradar nuestra seguridad y, si corresponde, tomar acciones al respecto, y si es alto, preocupémonos de forma inmediata. Pensemos que al Director General de una organización le importa que sus procesos comerciales, de facturación, de operación… funcionen bien (sean seguros); si se degradan, probablemente le dará igual que sea por culpa de un pirata informático, de un servidor caído, de un butronero o de la caída de la bolsa: en cualquier caso, el negocio está en riesgo y hay que tomar acciones para mitigarlo.

Ahora la pregunta del millón: ¿cómo podemos cuantificar cada riesgo que afecta a un determinado proceso? Se admiten ideas (yo os pasaré las mías en otro post :)

La seguridad de los passwords

passCuando estamos realizando proyectos de seguridad, desde cualquier punto de vista, casi siempre hablamos, en uno u otro momento, con el departamento de Sistemas, Explotación, Informática Interna, o como en cada caso se llame el grupo de personas que gestionan los sistemas y comunicaciones internos a una organización (servidores, aplicaciones, routers…). Este grupo de trabajo —llamémosle Sistemas, para aclararnos— es el que, total o parcialmente, dispone de las contraseñas de acceso privilegiado al entorno tecnológico de la organización, y por tanto es responsable de la custodia y protección de estos passwords.

Los passwords en cualquiera de sus modalidades y con cualquiera de sus restricciones (OTP, envejecimiento…) tienen como objetivo proteger el acceso a la información y a los sistemas que la tratan mediante algo que el usuario sabe. Resulta comprensible, pero chocante, que para estos departamentos la información más sensible de la empresa sea, en la mayor parte de ocasiones, el fichero de contraseñas privilegiadas de las máquinas corporativas. Casi todos utilizan —utilizamos— sistemas cifrados para su gestión (Password Safe, Password Gorilla…), con unas restricciones de acceso en muchos casos durísimas y reservadas únicamente al personal del grupo en cuestión (como debe ser, dicho sea de paso).

Obviamente, me parece muy bien que las contraseñas que dan privilegios totales en los sistemas estén almacenadas de forma segura y el acceso a las mismas esté estrictamente controlado, pero bajo mi punto de vista, en muchos casos nos olvidamos de lo que realmente protegen esos passwords: la información corporativa, que es lo que tiene valor para la organización. En ocasiones no somos conscientes de que las claves no dejan de ser una mera llave para el acceso a esa información, pero que mucho más importante que esta llave es lo que ésta custodia. Por tanto, quería hacer un par de reflexiones acerca de la seguridad que le damos a las claves para conocer vuestra opinión. Ahí van:

La primera de estas reflexiones es preguntarme por qué todos usamos cifrado para las contraseñas de acceso a las máquinas, pero muy pocos la usamos para proteger la información que hay en esas mismas máquinas (por ejemplo cifrando a nivel de volumen o de archivo). Lo que conseguimos si no protegemos datos a diferentes niveles es un modelo binario: o tienes la clave de “root” y accedes a todo, o no la tienes y por tanto no accedes. Debemos cifrar la información si queremos protegerla de forma adecuada, porque si no lo hacemos, demasiada gente tendrá acceso a ella —incluidos todos los administradores de sistemas—.

La segunda hace referencia también a un modelo binario de acceso: el departamento de Sistemas al completo suele tener acceso a todas las claves de una forma demasiado sencilla: o eres del área y accedes, o no eres y no accedes. ¿Por qué el último que entra al departamento de sistemas tiene acceso total a las contraseñas? Esta situación, desde el punto de vista de seguridad, me parece una aberración; dentro de un grupo de Sistemas hay personas de diferente nivel de confianza en la organización, por lo que no todos deben acceder a todo. Yo puedo tener confianza ciega en el responsable de sistemas (por ejemplo), pero no tengo por qué tenerla en una persona que acaba de incorporarse al departamento. ¿Es realmente necesario darle todas las claves a esta persona? Bajo mi punto de vista deben establecerse círculos de confianza dentro del grupo, y únicamente facilitar las contraseñas necesarias a cada persona para que desarrolle correctamente su trabajo en el día a día.

Siempre he opinado que un password debe protegerse de forma adecuada, especialmente los de usuarios privilegiados, pero también he pensado siempre que ese mismo password se cambia en un segundo, mientras que la planificación estratégica de la empresa no. Proteger mis contraseñas es, IMHO, correctísimo, pero no debemos olvidarnos de lo que a su vez protegen esas contraseñas.

NOTA: Actualizamos la entrada (¡diez años después!) para incluir el nuevo enlace de Password Safe y aprovechamos para enlazar un post de Bill Hess relativo a la reutilización de contraseñas, en PixelPrivacy. Thank you for the update, Bill!!

Cámaras en las calles

cctvEl uso de cámaras de seguridad en lugares de pública concurrencia siempre ha despertado posiciones enfrentadas; mientras que una parte de la población está a favor de su uso, por el supuesto incremento en la seguridad ciudadana que proporcionan, otro porcentaje está completamente en contra, argumentando que las cámaras causan una pérdida de privacidad en sus vidas. Frente a esto, el hecho cierto es que en muchas calles de nuestros pueblos y ciudades, y cada vez con mayor frecuencia, se están instalando cámaras de videovigilancia.

¿Por qué se instalan cada vez más cámaras? Las cámaras de seguridad tienen dos objetivos básicos: por un lado, la disuasión (si alguien se siente vigilado, es menos probable que cometa un delito), y por otro, la recopilación de evidencias para demostrar la comisión de delitos, por ejemplo en un juicio. Con estos dos objetivos en la mente, y considerando los niveles de inseguridad ciudadana que existen en determinadas zonas, se motiva que en ellas se instalen cámaras, tratando así de incrementar la seguridad de viandantes y vecinos.

La Ley Orgánica 4/1997, de 4 de agosto, regula la utilización de videocámaras por parte de las FFCCSE en lugares públicos, y deja muy claro que dichas cámaras deben utilizarse para asegurar la convivencia ciudadana, la erradicación de la violencia y prevenir la comisión de delitos, entre otros; si alguien utiliza las grabaciones con cualquier objetivo menos ético —por ejemplo, vigilar a su pareja—, comete un delito y por tanto puede ser sancionado. Partiendo siempre de que su uso sea el correcto (como el uso de cualquier control de seguridad), personalmente estoy a favor de la utilización de las videocámaras, siempre y cuando se demuestre con datos objetivos que incrementan la seguridad ciudadana, bien porque se cometen menos delitos, bien porque se consigue identificar —y procesar— a quien los comete de una forma más rápida y sencilla gracias a las cámaras. Si una cámara no logra su objetivo, bajo mi punto de vista no tiene sentido mantenerla activa (con el coste que ello supone a los ciudadanos), ya que no está aportando nada a la sociedad y es preferible invertir esos recursos en otro tipo de controles.

Cuando se instala una cámara de videovigilancia, mucha gente cree que monitorizando dicha cámara hay de forma permanente personas listas para actuar en cuanto vean algo sospechoso; por supuesto, esto es falso: las grabaciones únicamente se visionan si se considera que puede haber existido delito (por ejemplo, si presentamos una denuncia), borrándolas en un plazo razonable en caso contrario, de forma similar a lo que se hace con las cámaras de seguridad de los bancos. Así, es raro que determinados delitos o faltas, como el menudeo o el hurto, puedan ser frenados gracias a videocámaras: por un lado, no se suelen denunciar -o al menos no con datos concretos que permitan hacer un seguimiento a través de grabaciones-, y por otro, quienes los cometen saben que no van a ser sancionados de forma considerable, por lo que las FFCCSE tampoco van a invertir grandes recursos en perseguirlos. Por tanto, estos delitos rara vez serán frenados de forma considerable con una cámara. En el otro extremo, delitos como el atraco, la violación, el vandalismo… sí que pueden ser por un lado prevenidos (recordemos el efecto disuasorio) y por otro perseguidos gracias a las cámaras de seguridad en las calles.

¿Y qué hay de mi privacidad? Estamos en la calle, se nos informa de que estamos en zonas videovigiladas, las grabaciones no se visionan salvo que exista un motivo justificado, el uso de las cámaras está perfectamente regulado… para mí, eso no es ninguna invasión relevante en mi privacidad, y si, como he dicho, las cámaras incrementan de forma efectiva la seguridad ciudadana, no tengo ningún problema en que se instalen (y si no la incrementan, que se quiten, pero principalmente por un tema de costes). Ojo, esto es una opinión, tan buena o mala como el resto, así que les invito a dejar la suya en los comentarios.

(Imagen por Christian Nold)

Seguridad sectorial (I): banca

dineroCon este post me gustaría comenzar una serie sobre seguridad (problemas, situación, etc.) en sectores específicos de negocio: telcos, museos, espectáculos deportivos… Para empezar, he elegido el sector financiero por varios motivos: en primer lugar, es un sector que creo conocer -más o menos- debido a diferentes proyectos en los que he participado, de problemáticas y tipos diversos (seguridad lógica, convergencia, consultoría…). En segundo lugar, considero que el sector bancario -y por tanto su seguridad- es algo que nos afecta a todos y cada uno de nosotros: el que no sea cliente de un banco o caja, vaya de vez en cuando a una sucursal, saque dinero de un cajero, o acceda a sus cuentas a través de internet, que tire la primera piedra.

El departamento de Seguridad de un banco o caja debe enfrentarse a una problemática muy diversa, que va desde la seguridad del papel moneda o la protección del efectivo a la seguridad en la documentación (cheques, órdenes de pago…), pasando por la seguridad informática, en nuevos canales, en medios de pago, la protección de edificios y personas o el blanqueo de capitales. El sector bancario está además fuertemente regulado en materias de seguridad; a diferencia de otros sectores, en banca es obligatoria, por ejemplo, la figura del Director de Seguridad en cada entidad con la responsabilidad, entre otras, de canalizar las relaciones de la entidad con FFCCSE. De la misma forma, son de obligado cumplimiento diferentes normas relativas a cajas de caudales, cámaras acorazadas o blanqueo de capitales que en otros sectores -con excepciones- ni siquiera nos planteamos.

Con el paso del tiempo, el panorama de la seguridad en banca ha cambiado de forma radical, seguramente más de lo que ha cambiado la seguridad en otros sectores. Hasta los años ochenta,el principal problema de las entidades eran los atracos, en una época dura a todos los niveles (salíamos de una transición, las actividades terroristas eran abundantes y virulentas…); con el tiempo -y el esfuerzo de mucha gente de los departamentos de seguridad de los bancos y cajas- este problema se ha minimizado, y hoy en día me atrevería a decir que un atraco, por supuesto siempre que no haya víctimas, no deja de ser uno más de los problemas de seguridad de la banca, pero no el principal. Bajo mi punto de vista, en la actualidad son mucho más preocupantes los delitos relacionados con blanqueo, medios de pago (skimming, lazos…) o nuevos canales (phishing, pharming…), entornos que pueden causar más perjuicios (tanto en dinero robado como en imagen) a cualquier entidad.

Tanto las amenazas e impactos a considerar en el sector, definiendo riesgos que de una forma u otra debemos mitigar y que afectan al negocio desde puntos muy diferentes, como la situación actual de la seguridad en bancos y cajas, motivan que nos encontremos ante un panorama que hace de la banca un sector en el que la seguridad debería converger por uebos. No obstante, esto no siempre se consigue, y solemos encontrarnos tres situaciones en cuanto a convergencia en las entidades españolas:

  1. Seguridad global, en la que se gestionan todos los ámbitos de la protección del negocio por igual, delegando evidentemente cada operativa particular en grupos de trabajo determinados.
  2. Seguridades aisladas, en las que diferentes grupos se preocupan únicamente por los problemas que les afectan de forma directa; dicho de otra forma, Nuevos Canales no considera que un atraco sea un problema para ellos, y Medios de Pago no quiere ni oir hablar de los problemas de la banca por Internet.
  3. Seguridades colaborativas: diferentes “áreas de seguridad” con responsables independientes, pero con un paraguas común a todas ellas, por ejemplo un subdirector general que es capaz de aglutinar a dichas áreas bajo su mando.

Sin duda, el primer punto es -IMHO- el deseable y al que todos tratamos o tratan de llegar; no obstante, las cosas no se suelen hacer de hoy para mañana y, como siempre que se habla de convergencia, nos encontramos barreras muchas veces insalvables: guerras de Taifas en la organización, sensaciones de pérdida de control, estructuras rígidas que no pueden ser modificadas… problemas que sin duda se acabarán resolviendo, pero que motivan que en banca muchas veces se hable de “miniseguridades” y no de Seguridad.

(Imagen original de Roby© en Flickr)

Seguridad en tiempos de crisis

En estos meses, en los que la crisis (o la desaceleración) planea sobre nuestras cabezas, y a diario vemos cómo empresas de todos los sectores realizan ajustes de plantilla, abren expedientes de regulación de empleo, o incluso echan el cierre, la seguridad juega un papel fundamental para garantizar que el negocio -o lo que quede de él- sobrevive a las vacas flacas… IMHO, la seguridad debe ser una de las cosas en las que el presupuesto de una organización no se reduzca, o se reduzca lo mínimo posible, para garantizar la protección del negocio; de todos es sabido que cuando las cosas van mal, la delincuencia aumenta, y por tanto debemos protegernos mejor. La probabilidad de que en esta época que corremos tengamos un empleado que nos roba información, a la competencia viéndonos como un enemigo a eliminar -en el sentido figurado-, o a una mafia tratando de hacernos un phishing, es muy alta, con lo cual no podemos descuidar nuestra seguridad; es más, yo trataría de incrementarla.

No obstante, cuando una empresa tiene que ajustar al máximo su presupuesto global, la partida destinada a seguridad tiende a reducirse a una mínima expresión. ¿Y qué es esa mínima expresión? Como siempre, depende… Volviendo al post de la Pirámide de Maslow de la Seguridad, la mínima expresión de la seguridad consistirá, posiblemente, en mantenerse en el nivel en el que nos encontrábamos con anterioridad. Nada de mejorar, nada de incrementar nuestros niveles… supervivencia pura y dura. Es más, en muchas ocasiones, si no retrocedemos en el nivel que teníamos, ya podemos estar contentos… Pero, ¿qué es preferible en estos tiempos, tratar de avanzar, o reforzar lo que hemos conseguido? Creo que depende de muchos factores, y en el equilibrio está la virtud… Bajo mi punto de vista, no tiene sentido tratar de avanzar si no podemos reforzar lo que vamos consiguiendo; así, la seguridad sería una especie de galería minera: mucho más importante que alargar el túnel es apuntalar lo que ya hemos avanzado, para evitar un derrumbe. Ojo, con esto no quiero decir -sigan leyendo- que no tratemos de mejorar permanentemente nuestra seguridad con la excusa de la crisis; simplemente que lo hagamos con cabeza (más de la habitual), sabiendo dónde invertimos nuestros recursos, y por supuesto -ahora más que nunca- sin dejar de mirar para atrás, garantizando que la galería está bien apuntalada. Innovemos y busquemos soluciones creativas a nuestros problemas.

Bajo mi punto de vista, uno de los principales errores que en tiempos de crisis todos tendemos a cometer, es limitarnos a aguantar el chaparrón… Si las cosas van mal, es posible que nuestro presupuesto -estemos o no de acuerdo- se reduzca, como el del resto de departamentos de la organización. Pero ese no suele ser el problema: en seguridad hay soluciones para casi todo, y es una obligación del Director de Seguridad obtener la mayor protección posible con el presupuesto del que dispone, innovando cuanto sea necesario, buscando siempre nuevas soluciones, incluso a los problemas de siempre, e identificando correctamente los riesgos asumidos. Hay un proverbio que viene a decir que cuando soplan huracanes, unos construyen refugios y otros construyen molinos. Apliquémoslo a la seguridad, y pensemos qué construimos ante la crisis… quizás nos demos cuenta que, con un presupuesto X en el bolsillo, tomamos unos caminos determinados (mejores o peores) simplemente porque son los habituales o los esperados por todos, sin llegar a plantearnos una alternativa. Para mí, esto es construir refugios, aguantar el chaparrón, y en este mundo si nos limitamos a eso, antes o después fracasaremos.

Finalmente, un apunte: si en nuestra organización estamos notando la crisis… ¿no es un riesgo que deberíamos haber considerado en nuestro último análisis? Llegar a una situación como la actual no es algo que suceda de la noche a la mañana, de forma imprevista, sino que es la consecuencia de múltiples factores económicos, sociales, organizativos…¿Teníamos esta posibilidad contemplada? ¿Teníamos planificado cómo actuar, o en estos momentos nos guiamos por intuición -y presupuesto-? Tengámoslo en cuenta, si no lo hemos hecho ya, para la próxima ocasión (y no duden que la habrá).

Honeytokens

Los sistemas de decepción de intrusos siempre me han parecido muy interesantes de cara a garantizar la seguridad de una organización; si bien los más complejos, las honeynets, no suelen implantarse con frecuencia salvo en entornos grandes y/o especialmente concienciados en temas de seguridad (digamos que los beneficios obtenidos del sistema no suelen cubrir el coste asociado a la implantación y al mantenimiento del mismo), los sistemas sencillos, los honeypots, tienen, bajo mi punto de vista, una buena relación coste/beneficio.

Dentro de los honeypots, los sistemas más triviales son los honeytokens: elementos que simplemente por “tocarlos”, por acceder a ellos, generan una alarma que puede proporcionar información muy valiosa a la organización: intentos de intrusión, intentos de robo de información, etc. Este subconjunto es particularmente interesante, porque a cambio de una inversión mínima —existen honeytokens muy sencillos, y su mantenimiento una vez implantados es casi inexistente— obtenemos una información de alto valor.

En la red existen multitud de honeytokens ya prediseñados y listos para ser “dejados caer” en los sistemas corporativos con una mínima parametrización; una vez implantados, nos indicarán que algo anómalo sucede con una tasa de falsos positivos casi igual a cero, lo cual es obviamente muy interesante (uno de los problemas de los sistemas de detección de intrusos basados en red es la tasa de falsos positivos que pueden llegar a generar, y el coste asociado a procesar toda la información que producen día a día). Aparte de los honeytokens ya prediseñados y que todo el mundo conoce, no es difícil diseñar alguno “ad hoc” para nuestra organización: un registro JFK, un fichero que no debe ser accedido, un puerto que no debe ser usado… Uno de estos sistemas, que IMHO es muy interesante y nos permite detectar usuarios “curiosos” (generalmente internos) que tratan de acceder a información a la que no deberían puede ser el siguiente:

– Creemos un fichero “DESPIDOS.DOC” en un recurso compartido por Samba, por ejemplo.

– Gracias a la API inotify (en Linux), y al paquete inotify-tools, podemos hacer un monitor que detecte diferentes accesos al sistema:

inotifywait -m -e access DESPIDOS.DOC | while read FILE ACTION; do ACCION done

– Generalmente, un acceso de un usuario a un fichero utilizando una aplicación se traduce internamente por N accesos; podemos utilizar un buffer intermedio que “limpie” los accesos espúreos. El monitor se complica ligeramente, pero no deja de ser trivial (y lo lanzamos pasándole como parámetro la ruta del fichero a monitorizar):

#!/bin/sh

MARGEN=60
LASTU=0
LASTT=0

# Accion a realizar ante un acceso
function action(){
echo "ACCESO de $USER a $FILE en modo $ACTION"
}

# Al realizar un acceso para el usuario, en ocasiones se traduce internamente
# por N accesos. Ponemos un tampon para registrar el ultimo y no realizar
# ninguna accion si el siguiente es del mismo usuario dentro de un margen de
# tiempo definido ($MARGEN)

function buffer(){
if [ $USER -eq $LASTU ]; then
	DIFF=`expr $TIME \- $LASTT`
	if [ $DIFF -gt $MARGEN ]; then
		action
	fi
else action
fi
LASTU=$USER
LASTT=$TIME
}

if [ $# -ne 1 ]; then
	echo "Deteccion de acceso a ficheros"
	echo "USO: $0 fichero" 
	exit -1
fi

inotifywait -m -e access $1|while read FILE ACTION; do 
	USER=`ps -ef|grep $FILE|head -1|awk '{print $1}'`
	TIME=`date +%s`
	buffer 
done

– Si lo lanzamos en el arranque, invocándolo convenientemente, y sustituyendo en la función action() la orden echo por algo más elaborado (un evento, un mensaje a móvil, un correo electrónico…), conseguiremos detectar, como hemos dicho, a los usuarios que puedan ser más curiosos en la organización. No tenemos más que sentarnos a esperar nuestros eventos, SMS o lo que hayamos decidido enviar cuando se detecta un acceso :)

Ojo, el código anterior es fruto de veinte minutos de trabajo y por supuesto se puede mejorar por mil sitios, pero espero que sirva para hacernos una idea. Adicionalmente, yo provengo del mundo Unix y no conozco otros entornos con la profundidad necesaria para hacer algo parecido a esto, pero estoy seguro que en la mayor parte de sistemas (Windows, AS/400…) es posible —y no especialmente costoso— diseñar cosas parecidas que nos permitan detectar el interés de nuestros usuarios por acceder a información que no deberían ver…

Clasificación y tratamiento de la información (II)

Comenzaba el otro día Alberto su entrada sobre clasificación de la información comentando que éste suele ser un motivo habitual de incumplimiento. En efecto, cuando estamos trabajando en una organización y pedimos el procedimiento de clasificación y tratamiento de la información, en muchos casos nos miran con cara de póker y nos vienen a decir algo del tipo “¿Yesoqués?”.

Tener definido —e implantado— un procedimiento que nos diga cómo trabajar con la información corporativa es no sólo una buena práctica recogida en estándares como ISO 27.002 , sino en ocasiones incluso un requisito legal: la propia LOPD recoge restricciones diferentes en función del nivel de cada tratamiento declarado. No debemos olvidar que la información es sin duda uno de los activos más importantes de nuestra organización, y que muchos de los esfuerzos que a diario realizamos van orientados a proteger este activo, por lo que la clasificación y el tratamiento de la información son una pieza básica para garantizar la seguridad.

Un procedimiento de clasificación y tratamiento de la información debe ser acorde tanto a los requisitos del negocio (no implantemos unas restricciones propias de la NASA en una empresa que no las necesita, porque acabarán incumpliéndose) como a los requisitos legales (ojo a la LOPD y las restricciones que impone a los tratamientos declarados en función de su nivel). En mi opinión, un procedimiento de este tipo debe contemplar al menos los siguientes puntos:

— Clasificación.

¿Cómo clasificamos la información corporativa? ¿Qué diferencias hay entre SECRETO, CONFIDENCIAL o INTERNO? Si no sabemos clasificar de forma clara la información con la que trabajamos, difícilmente podremos protegerla.

— Restricciones de tratamiento, incluyendo difusión, copia, almacenamiento y transmisión.

¿Quién tiene o puede tener acceso a cada tipo de información? ¿Cómo debe tratarse, por ejemplo, cuando sea necesario sacarla fuera de las premisas de la organización? ¿Puedo utilizar un dispositivo USB sin cifrar para almacenar —o extraer— información confidencial? Debemos tener claro que no podemos hacer lo que nos venga en gana con la información, sino que debemos adecuarnos tanto a la legalidad como a la normativa interna definida en la organización.

— Marcado.

¿Qué marcas debe tener un soporte —físico o lógico— con información de cierto tipo? ¿Debo disponer de algo tan simple como un cuño con la leyenda “SECRETO”? La información que queramos proteger —esto es, probablemente, toda salvo la pública— debe marcarse de forma adecuada, garantizando así que quien la maneja sabe en todo momento con qué tipo de información está tratando (y por tanto puede aplicar correctamente las restricciones de tratamiento).

— Caducidad.

¿Cuándo pierde una información de cierta categoría su valor? ¿Pasa por defecto la información secreta a ser pública en algún momento? Si es así, ¿cuándo? El valor de la información cambia con el tiempo, y quizás debamos plantearnos —o no— tiempos de vida para nuestros datos.

— Destrucción.

¿Cómo destruyo cada tipo de información? ¿Utilizo un simple formateo para eliminar información secreta de un soporte, o por el contrario debo utilizar un borrado seguro? ¿Y si es confidencial? Los mecanismos de destrucción de la información, sin importar el tipo de soporte sobre el que se almacene, deben estar identificados de forma clara, garantizando que no es posible recuperar aquellos datos que creemos haber eliminado.

— Auditoría y control.

¿Qué salvaguardas aplico para garantizar que lo que he escrito en el procedimiento se cumple en la realidad? ¿Hago un muestreo de mesas limpias? ¿Registro las destrucciones de medios? Todo lo especificado en un procedimiento queda muy bien sobre el papel, pero debo garantizar su cumplimiento en la realidad y detectar en el menor tiempo posible cualquier desviación con respecto a lo definido.

— Régimen disciplinario.

¿Qué sucede si alguien de la organización incumple el procedimiento y se lleva un dispositivo USB con información secreta sin cifrar? ¿Y si usa un medio de destrucción incorrecto para la clasificación a eliminar? En el procedimiento debo identificar claramente qué sucede cuando alguien —en especial de forma consciente— incumple lo especificado.

Una buena referencia en la materia, algo antigua pero que nos puede aportar mucha información e ideas para definir la clasificación y el tratamiento de la información corporativa, es la directiva 5200.1 (y derivadas) del Departamento de Defensa estadounidense, disponibles desde http://www.dtic.mil/. Eso sí, tengamos presente que se trata de un estándar militar, y que por tanto no es de completa aplicación en la mayoría de organizaciones con las que habitualmente trabajamos (lo dicho antes: no matemos moscas a cañonazos, no nos pasemos a la hora de imponer restricciones, y hagamos bien nuestro trabajo de consultoría: definamos e implantemos controles adecuados a cada organización).

Peritajes informáticos

Cuando una organización sufre determinados incidentes de seguridad (por ejemplo, una intrusión), se plantea la realización de un análisis forense, en el que se tratan de obtener y presentar evidencias electrónicas del problema acaecido; adicionalmente, en ocasiones —no siempre, aunque si se ha producido un delito debería ser así—, es necesario efectuar una denuncia, y es entonces cuando surge la necesidad de realizar un peritaje informático por parte de un perito cualificado.

Un peritaje informático tiene como objeto dar respuesta técnica a una serie de cuestiones planteadas bien por una de las partes bien por el propio juez; dicha respuesta, por muy complejos que sean el desarrollo o las bases de la misma, debe ser concisa y sencilla (pensemos que la tienen que interpretar personas que no tienen por qué estar familiarizadas técnicamente con el objeto del informe). Así, siempre es conveniente incluir un apartado de “conclusiones” dentro de nuestro informe, en el que en base a todo lo desarrollado en el cuerpo del mismo, se muestren de forma resumida las respuestas a las cuestiones planteadas.

Para poder realizar y defender un informe pericial no es necesario, a priori, ningún requisito especial; no obstante, en la práctica suele ser positivo para que el informe sea tenido en cuenta por el juez, bien disponer de una titulación académica adecuada al objeto del informe, o bien disponer de una experiencia profesional en el campo al que el informe hace referencia. Dicho de otra forma, yo podría presentar un informe pericial acerca de los problemas de salud que un determinado individuo dice padecer y dar mi opinión acerca de si estos problemas han influido en la comisión de un delito, pero como no soy médico, mi informe sería poco más que papel mojado ante un tribunal. Por este motivo, cuando estamos tratando casos en los que entran en juego la informática o las telecomunicaciones, tanto el juez como las partes tratarán de buscar peritos Ingenieros Informáticos o de Telecomunicación. Las empresas de seguridad que tienen entre su catálogo de servicios, dentro de los aspectos de gestión de incidentes, los peritajes, disponen —o deben disponer— de Ingenieros cualificados para realizar estos informes; además, los Colegios Oficiales disponen en muchos casos de turnos de actuación profesional (algo equivalente al turno de oficio para los abogados) para aportar peritos en aquellos casos en los que se solicitan (por ejemplo, en la Comunidad Valenciana, el Colegio Oficial de Ingenieros en Informática dispone de este turno de actuación).

Los que hemos realizado y defendido informes periciales —tanto de parte como judiciales— ante un juez, nos hemos tenido que enfrentar en muchas ocasiones a los principales problemas que bajo mi punto de vista existen a la hora de emitir un informe; en este orden:

— Incapacidad técnica para la emisión del dictamen.

Si hay que realizar un informe acerca de un individuo que se ha roto una pierna, desde el juzgado buscarán a un traumatólogo, no a un neurocirujano, por muy médico que este sea. Obvio, ¿verdad? Pues cuando entra en juego la tecnología, esto no es tan obvio… exagerando un poco, si asesinan a alguien dándole golpes con un portátil, es fácil que se busque a un Ingeniero Informático para emitir el informe en cuestión. Ante casos de este tipo, el perito debe ser tajante: se rechaza la realización del informe por incapacidad técnica. Por muy perito informático que yo sea, rechazaré una pericia relacionada con el mal funcionamiento de un SAP, porque desconozco técnicamente su funcionamiento y no me siento capacitado para hablar con propiedad sobre este entorno —y más cuando delante tengo a gente que puede estar jugándose penas de cárcel—.

— Técnicamente, todo es posible.

Por muy obvia que para un técnico sea una cuestión, para un juez o un abogado no lo es tanto; así, si estamos realizando un informe en el que se indica que un individuo ha utilizado su ordenador para atacar sistemas de terceros, y al individuo en cuestión se le incauta un equipo lleno de herramientas de hacking (con sus correspondientes accesos directos en el escritorio), ficheros de contraseñas, logs de chats… el acusado siempre puede decir que todo eso “se lo han puesto por la WiFi” y que él no sabe nada. Y cuando nos pregunten si eso es técnicamente posible, tendremos que decir que sí (aunque insistamos en la baja probabilidad por N motivos). En función del juez que lleve el caso, se declarará al acusado inocente.

— Contraposición de visiones: juristas y peritos.

Como hemos dicho antes, cuando realizamos un informe pericial debemos responder desde un punto de vista técnico a una serie de cuestiones que se nos plantean; es vital no incluir nunca opiniones personales no fundadas, y también es importante no entrar en el ámbito del abogado o del juez: un perito nunca puede decir, por muy obvio que técnicamente le parezca, que el acusado es culpable o inocente. Los aspectos jurídicos no entran de ninguna manera en el ámbito de actuación de un perito. De la misma forma, el perito no puede admitir —esto suele suceder en los informes de parte, no en los judiciales— opiniones legalistas que no se correspondan con la estricta realidad: si en nuestro informe decimos que algo es “altamente improbable” queremos decir sólo eso, que es altamente improbable, y no que es imposible (un término que seguramente para el abogado será mucho más directo y efectivo, y por tanto tratará que incluyamos en el informe, pero que técnicamente puede no ser cierto).

Finalmente, un problema que no es exclusivo de los peritos, sino que quizás es generalizado en el sistema judicial: para defender durante quince minutos nuestro informe, seguramente invirtamos toda una mañana en los juzgados. Ante esto, paciencia: es lo único que podemos hacer como peritos :)

Destructoras de medios

NIST-SP 800-88 [pdf], Guidelines for media sanitization, define cuatro tipos de “sanitización” (perdón por la traducción inventada, pero no quería decir “saneamiento” o algo así) de medios: la eliminación (no hacemos nada especial, simplemente nos deshacemos de la información, por ejemplo dejando el papel en un contenedor para reciclar), la limpieza (borrado de datos básico), el purgado (borrado avanzado) y la destrucción.

Centrándonos en el último de los anteriores tipos, las destructoras de medios físicos (papel, discos duros, tarjetas de crédito, DVDs…) constituyen un control de seguridad básico a día de hoy en organizaciones de todo tipo: desde una PYME o un autónomo, a las grandes multinacionales. Y es que, conforme la información adquiere cada vez más valor para nosotros, obviamente más preocupados estamos porque los soportes que contienen esta información no lleguen a manos ajenas.

Para la información en formato papel o plástico (esto incluye los diskettes, discos compactos y DVDs, entre otros), hoy en día casi todos disponemos de destructoras en nuestra oficina o incluso en nuestras casas (existen destructoras de papel por menos de cincuenta euros para uso doméstico… eso sí, ni se os ocurra meter ahí un DVD para destruir). A nivel profesional, es muy importante disponer de una destructura de este tipo, de gran capacidad y de corte fino o cruzado (las domésticas suelen tener el corte de papel más grueso, por lo que el documento es más fácil de recuperar; incluso en el caso de hojas de cálculo, es trivial por la coincidencia de los cortes con las filas y columnas).

Las alternativas a estas destructoras de medios suelen pasar, en especial en el caso del papel, por la contratación de servicios externos de recogida y destrucción: periódicamente nos dejan en la oficina una especie de buzones cerrados y precintados en los que depositamos toda la documentación sensible, y que posteriormente son recogidos y destruidos por la empresa que nos presta el servicio. A título personal (insisto, personal, así que por favor, que nadie que trabaje en este tipo de empresas ponga el grito en el cielo) siempre he preferido una salvaguarda que me garantice directa y técnicamente la destrucción de los medios que una salvaguarda que me garantice esto mismo de forma contractual. Llamadme desconfiado, pero es mi opinión.

El caso de destrucción de discos suele ser más peliagudo que el de otros medios; como todos sabemos, para eliminar la información de discos duros existen diferentes mecanismos: desde el borrado o la sobreescritura convencionales (con los problemas que esto implica, y que ya sabemos) hasta la desmagnetización o la destrucción física de los discos, métodos con más garantías pero que, por contra, no permiten la reutilización del medio. Poca gente dispone de destructoras de discos duros (haberlas haylas, pero son caras), por lo que al final en muchos casos se suele optar por diferentes métodos para proteger la información:

  • Formateo. Obviamente, aproximación incorrecta y que permite una recuperación relativamente sencilla de los datos.
  • Borrado seguro. Eliminación de los datos siguiendo algoritmos de borrado seguro, basados en secuencias concretas de sobreescritura de los sectores. Aproximación segura pero costosa en tiempo, por la lentitud de los algoritmos.
  • Destrucción “manual”. Simplemente desensamblamos el disco, destruímos la electrónica, lijamos (por poner un ejemplo bruto) los platos y los partimos en N trozos. Aproximación segura para el 99.999% de los mortales :)

Sea como sea, es crítico destruir convenientemente cualquier soporte de información; pero no únicamente destruirlo, sino también mantener su seguridad durante su tiempo de vida. Ya hemos hablado del cifrado de medios y de los problemas que podemos tener si “perdemos” un pendrive USB; si el soporte a desechar está cifrado, no tenemos por qué perder tiempo en su destrucción o purgado… pero por desgracia no siempre es posible cifrar todo.