Seguridad sectorial (I): banca

2 de junio de 2009 Por

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

27 de mayo de 2009 Por

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

15 de mayo de 2009 Por

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)

11 de mayo de 2009 Por

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

27 de abril de 2009 Por

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

16 de marzo de 2009 Por

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.

Basureo

5 de marzo de 2009 Por

En los últimos tiempos han venido surgiendo noticias en medios generales en relación a las “investigaciones” que diferentes ayuntamientos realizan o se plantean realizar para detectar y multar a ciudadanos que no reciclan su basura; la idea es simple: se revisan las bolsas del contenedor en busca de aquellas que contienen residuos de varios tipos (es decir, las correspondientes a los que no reciclan), y en esas mismas bolsas se busca información que pueda dar indicios sobre el vecino que no ha reciclado (recibos del banco con datos personales, facturas, publicidad…). Una vez localizado dicho vecino, se le multa.

Este tipo de noticias plantean serias dudas en materias de seguridad; en primer lugar, tenemos un problema legal: ¿quién está legitimado para buscar en mi basura? Según unos, nadie (mi basura es mía y sólo yo puedo mirarla), y según otros (los ayuntamientos), una vez se deposita la bolsa en el contenedor, la basura ya no es nuestra, sino que es pública (o algo así). Personalmente no entro a valorar este aspecto legal (lo desconozco, y aprovecho para pedir, si alguien entre nuestros lectores conoce el tema, más información al respecto), pero sí que me preocupa la posible violación de la confidencialidad que se produce al revisar basuras ajenas (dicen por ahí que es posible conocer a cualquier persona analizando su basura). Por lo que a mí respecta, trato siempre de destruir o separar cualquier cosa que permita detectar al “propietario” (en este caso yo) de la basura, sobre todo, y para matar varios pájaros de un tiro, los papeles que amablemente me envían los bancos para recordarme la enorme cantidad de dinero que tengo en mis cuentas en Suiza, los pocos recibos que tengo que pagar al mes con todo ese dinero, y la ridícula hipoteca en la que me metí hace un tiempo :)

La segunda gran duda que plantea este método es la fiabilidad del mismo; todos sabemos que el correo no es precisamente el medio más seguro de envío de información, y que en muchas ocasiones es muy fácil acceder a la correspondencia de cualquier vecino (metiendo la mano en su buzón o simplemente esperando a que por error metan su correspondencia en el nuestro). No hace falta ser muy listo para imaginar a ese vecino que todos tenemos hurgando en nuestro buzón, sacando nuestras cartas, depositándolas en una bolsa de basura sin separar y sentándose a esperar para ver cómo la Policía Local nos multa por malos ciudadanos. Apañados estamos.

Hace unos años el basureo (trashing) era una técnica habitual en cualquier auditoría de seguridad que se preciara; la información que se podía obtener en una papelera o un cubo de basura era impresionante: nombres de usuario y contraseñas, datos financieros, ofertas, datos de los empleados… Un método mucho más rápido que andar buscando vulnerabilidades en un firewall, por supuesto. Hoy en día todos nos hemos acostumbrado a utilizar estupendas destructoras de papel —algún día hablaremos de ellas— que siempre usamos para destruir cualquier tipo de información interna (¿verdad?), por lo que estos métodos de auditoría no se utilizan tanto como hace unos años; quizás noticias como esta hagan que el trashing se vuelva a poner de moda entre los equipos de auditoría.

En cualquier caso, dos consejos: no tiréis a la basura ningún dato que pueda considerarse confidencial y, por supuesto, reciclad :)

* * *

(N.d.E.) Esta semana la encuesta está relacionada con la cuestión que planteaba Toni arriba: la basura que generamos, ¿es nuestra durante todo “su ciclo de vida”, o por el contrario deja de serlo cuando sale por nuestra puerta? Les planteamos además un par de opciones adicionales que pueden ser interesantes:

[poll id=”7″]

En relación con la encuesta de la semana pasada, los resultados se muestran debajo, dando como resultado que la mayor parte de los lectores se decantan por informar del error y no dar ningún detalle; es también esa la opción escogida por David, la persona que planteaba la encuesta. En segundo lugar, cuatro lectores apoyaban la idea de dar toda la información posible, cuestión que desaconsejo por el riesgo de proporcionar información sensible al posible atacante (versiones, rutas, usuarios, etc.). De hecho, creo preferible enmascarar el error completamente (3 usuarios). Por último, felicitar a esos tres usuarios que no tienen, no saben que tienen, o prefieren no saber que tienen errores en sus aplicaciones.

[poll id=”6″]

Nada más; S2 Grupo se muda de oficinas este fin de semana, con todo lo que ello implica. La semana que viene les pondré alguna foto del nuevo emplazamiento, por simple narcisismo. Pasen en cualquier caso un buen fin de semana. Nos vemos el lunes, más y mejor.

CCTV

16 de febrero de 2009 Por

Un sistema de circuito cerrado de televisión (CCTV) es un mecanismo de seguridad que dispone de elementos o subsistemas de captación (cámaras), de reproducción (monitores), de grabación (videos), de transmisión (cableado), de sensorización (sensores de movimiento, de condiciones ambientales, de fuego…) y de control (rotores de cámaras, switchers…). Estos sistemas constituyen un elemento muy importante a considerar en casi cualquier instalación de seguridad, ya que permiten obtener imágenes de buena calidad (diurnas y nocturnas), proporcionando un elevado nivel de control (por ejemplo en procesos industriales), incrementando la seguridad (como medida disuasoria) y permitiendo obtener evidencias fiables de forma sencilla y efectiva, por ejemplo ante incidentes graves.

Las ventajas de utilizar la videovigilancia son muchas, desde la protección de vidas humanas o activos de todo tipo hasta el control de zonas donde se realizan trabajos peligrosos. No obstante, estos mecanismos de seguridad (como cualquier otro) tienen contraprestaciones que es necesario evaluar a la hora de implantarlos; sin duda, el tema más espinoso es legal, y se deriva de la protección de datos de carácter personal, en especial en aquellas instalaciones donde sea necesario disponer de cámaras en el exterior de las instalaciones.

En el ámbito estricto de la seguridad física, la videovigilancia mediante CCTV presenta dos problemas importantes; el primero de ellos, en aquellos casos en los que se captan imágenes de forma permanente y en gran volumen, es la limitación en la capacidad de reacción ante incidentes, por una cuestión de volumen. Si pensamos en las horas de imágenes de cajeros que cualquier banco puede tener a diario, en la dificultad para detectar automáticamente ciertas activides anómalas en dichos cajeros (es muy dificil, con un programa de procesamiento de imagen, determinar si alguien saca dinero de forma legítima o está poniendo un lazo libanés), y en la imposibilidad de analizar por parte de un humano dichas imágenes, podemos hacernos una idea de esta limitación a la que hacíamos referencia (en la práctica, las imágenes de cajeros obviamente no se visualizan salvo problemas detectados por otros medios, y si no los ha habido, se destruyen pasada una semana desde la grabación).

El segundo problema importante en temas de CCTV suele producirse por la dependencia en un vigilante de seguridad para el control de las cámaras, un vigilante que obviamente puede o no ser efectivo y reaccionar a tiempo; esta dependencia se produce especialmente en horarios de mínimos, cuando el número de personas “visualizando” imágenes es más reducido, en ocasiones demasiado, y podemos no detectar un problema simplemente porque el encargado de ver las imágenes se ha levantado a por un café.

Finalmente, es necesario indicar que los sistemas clásicos de CCTV se están sustituyendo en algunas organizaciones por sistemas de cámaras web, mucho más económicas, pero también con mayores problemas de seguridad; se trata de cámaras con conexión TCP/IP, e incluso accesibles en ocasiones desde Internet (por una mala configuración, un descuido, o simplemente por desinterés), que pueden comprometer gravemente nuestra seguridad a todos los niveles: legal, físico, lógico… Como siempre, es necesario estar muy al tanto de las amenazas que este tipo de cámaras introducen en nuestra organización, garantizando que un elemento que debe incrementar nuestra seguridad no acaba rompiéndola por completo. Y para muestra, un botón: si os aburrís, buscad “index of /webcam” en Google.

De charlas va el tema

6 de febrero de 2009 Por

A continuación les muestro las presentaciones de dos charlas realizadas por Antonio Villalón, la primera de ellas ayer mismo en la jornada “La Seguridad y Fiabilidad Informática Factor Clave para el Crecimiento de las Empresas” organizada por el Instituto Tecnológico de Informática de la Universidad Politécnica de Valencia, y la segunda el pasado 18 de diciembre, en el ciclo de charlas técnicas del chapter ISACA de Valencia. Espero que les resulten interesantes. En cualquier caso, buen fin de semana a todos.

[Read more…]

CSIRT-CV

19 de enero de 2009 Por

Como todos los que leemos habitualmente este blog sabemos, en los últimos años han aparecido en el panorama nacional diferentes centros de respuesta ante incidentes de seguridad informática (CSIRT, Computer Security Incident Response Team); seguramente los más conocidos son CCN-CERT e INTECO-CERT, ambos ya operativos y que se unen a los clásicos esCERT e IrisCERT, creados éstos a mediados de la década de los 90. A todos estos centros se unen otros equipos de grandes empresas, como La Caixa (e-LC CSIRT) o de administraciones autonómicas, como la andaluza, la catalana y la valenciana.

Dentro de este ámbito, el autonómico, en la Comunidad Valenciana está operativo desde hace meses CSIRT-CV, el Centro de Seguridad TIC de la Comunidad Valenciana; como se indica en su propia página, se trata de un centro contemplado en el Plan Estratégico de Comunicaciones Avanzadas de la Generalitat (AVANTIC) que tiene como objetivo la prevención, detección, asesoramiento, seguimiento y coordinación necesarios para hacer frente a incidentes de seguridad informática.

El funcionamiento del centro, plenamente operativo en estos momentos, se rige por tres grandes líneas de actuación:

  • Prestación de servicios de información, como los servicios de alertas sobre nuevas amenazas y vulnerabilidades.
  • Prestación de servicios de soporte y coordinación para la resolución de incidentes.
  • Realización de labores de investigación, formación y divulgación de seguridad de la información.

A través de la página web del centro, de sus foros, y de sus boletines periódicos y extraordinarios se puede acceder a todos estos servicios, principalmente orientados a Generalitat Valenciana, pero extensibles a ciudadanos de toda la comunidad. Desde el reporte de incidencias de seguridad, a la suscripción a alertas de los fabricantes más habituales (Cisco, Sun Microsystems, Oracle…), pasando por el acceso a documentación relativa a seguridad desde diferentes puntos de vista. También es importante la colaboración del centro con empresas privadas, administraciones, FFCCSE, grupos de interés… relacionadas con seguridad, colaboración e intercambio de información que hoy en día se hace imprescindible siempre que hablamos de seguridad.

Evidentemente, se trata de un primer paso -fundamental- hacia un centro de seguridad global para nuestra Comunidad; aunque la mayor parte del camino está por recorrer, CSIRT-CV se encuentra, como hemos dicho, plenamente operativo y ofreciendo los servicios anteriormente citados. Para nosotros, cualquier iniciativa que trate de potenciar la seguridad de una u otra forma (técnicamente, a nivel informativo, etc.) siempre es bienvenida; especialmente en el ámbito de la Administración Pública, en la que a diario se maneja información privada de todos nosotros y que por tanto a todos nos interesa que sea protegida adecuadamente. Ójala cunda el ejemplo que en este caso han dado algunas administraciones -entre ellas la valenciana- en el resto de autonomías, y que se potencie de la mejor forma tanto la seguridad en estos ámbitos, como el intercambio de información y la colaboración entre centros de seguridad similares.

Para acabar, un apunte dirigido a los más susceptibles; como todos sabeis, en este blog tratamos de no hacer nunca publicidad de empresas o de servicios (ni propios ni mucho menos de la competencia), pero consideramos que el caso de CSIRT-CV, aún a riesgo de parecer publicidad del centro (aunque no sea una empresa sino administración pública, obviamente), bien merece un post como reconocimiento al trabajo que se está realizando en este ámbito.

PD Sabemos que el personal de CSIRT-CV es lector asiduo de nuestro blog, así que desde aquí los animamos a que amplien la información que hemos proporcionado y nos mantengan a todos al tanto de los avances o cambios de interés que se vayan produciendo en el centro (y que se puedan contar, obviamente). ¡Venga, animaos! :)