Security Art Work

(Este artículo fue publicado previamente por José Rosell en la revista Economia3)

Es un hecho, y por tanto no vamos a extendernos en su justificación en estas líneas, que los procesos de negocio son altamente dependientes de la tecnología y que cada vez lo son más y no solo de la tecnología en sí misma, sino del uso que hacemos de ella.

En los últimos años hemos asistido asombrados al nacimiento y desarrollo vertiginoso de las redes sociales en el mundo. La rapidez de su expansión y su intensidad de uso, así como su importancia en todos los campos de nuestra sociedad, están obligando a organizaciones de todo el mundo a tomar cartas en el asunto. Por si fuera poco, la reciente proliferación de dispositivos móviles, “smartphones” y tabletas, que nos permiten un acceso ubicuo a la información, ha terminado de complicar el panorama desde el punto de vista de la gestión y el control de la información.

En 2008 el 45% de los internautas eran usuarios de redes sociales mientras que en 2011 lo son el 91%, de los que el 55% usan las redes sociales a través de dispositivos móviles. (Fuente: Observatorio de redes sociales del BBVA. IV Oleada. Abril de 2012)

Un factor adicional que hace más complicado el análisis del uso de las redes sociales y su impacto en nuestras organizaciones son los continuos vaivenes de su tipología y forma de uso, como se desprende del citado informe. Cuando empezamos a entender sus implicaciones y diseñamos una tímida pauta de actuación en esta materia, nos podemos encontrar con que su uso haya cambiado o “mutado” hasta el punto de dejar nuestras medidas obsoletas. No hay más que ver que, según el mismo estudio, en 2008, el uso de twitter entre los internautas apenas alcanzaba el 1% mientras que en 2011 la cifra de usuarios activos de twitter alcanzaba el 32%, cifra que se incrementa hasta el 51% si contamos usuarios que no se consideran especialmente activos en la red social.

[Read more…]

Los Indicadores de Compromiso (IOCs) (de los que ya hablamos en el informe Detección de APTs) son una tecnología que está teniendo un gran auge en los últimos años y que consiste en utilizar XML Schemas para describir las características técnicas de una amenaza por medio de las evidencias de compromiso que la misma deja en el equipo comprometido tras la infección: procesos, entradas de registro, ficheros descargados, etc.

La empresa Mandiant ha desarrollado un framework open-source, llamado OpenIOC que nos permite a través de dos tools (IOC Editor e IOC Finder), desde describir de forma semántica el comportamiento del malware/APTs por medio de ficheros XML (IOC Editor) hasta utilizar los mismos para buscar signos de infección en una máquina sin necesidad de llegar a realizar un análisis exhaustivo de la misma para identificar el tipo de amenaza (IOC Finder).

Con IOC Editor podemos definir una gran cantidad de características y además posee una interfaz de edición muy intuitiva para crear nuestros ficheros IOC:

De lo que se trata al definir un fichero IOC es de buscar por ejemplo localizaciones específicas en el sistema de ficheros, registro u otras partes del SO que habitualmente sean usadas por malware, buscar rastros que pudieran haber dejado herramientas usadas por los atacantes, señales de actividad de los intrusos sobre los sistemas que indiquen movimientos laterales que muestren un comportamiento anormal del usuario…etc. Lo ideal es buscar datos muy concretos para evitar falsos positivos. En definitiva, la definición de IOCs permite a las organizaciones definir piezas de inteligencia de amenazas de una manera estandarizada. Los ficheros IOC al estar definidos bajo un mismo estándar son más fáciles de intercambiar para compartir información entre la comunidad. Así, sitios como http://iocbucket.com/, http://ioc.forensicartifacts.com/ o los propios foros de Mandiant pueden sernos de gran ayuda para encontrar determinados IOCs o compartir los que nosotros hayamos creado.

Un extracto de una fichero IOC (elaborado por AlientVault) sería por ejemplo el que muestra la siguiente figura correspondiente a la APT Red-October. Con esta plantilla y con la ayuda de IOC Finder se podría localizar indicios del Red-October en nuestras máquinas.

Con IOC Finder, a través del parámetro “collect” se recopilará un conjunto de datos (procesos, entradas de registro,etc.) en el equipo sospechoso y los irá almacenando en forma de ficheros XML (crea hasta 50) en un directorio que crea “audits” para tal fin. Así si ejecutamos en el equipo por ejemplo:

>mandiant_ioc_finder.exe collect -o /INDICADORES

Nos generará los ficheros XML correspondientes (proceso que puede tardar horas) y los copiará en la ruta /INDICADORES que le indicamos con el parámetro -o (para más información sobre los parámetros ver guía del usuario de IOC Finder). Una vez este proceso ha finalizado a través del parámetro “report” procederemos al procesamiento de esos ficheros XML por el que se buscarán los patrones de infección que queremos localizar con ayuda de los ficheros IOC de los que dispongamos o hayamos definido. Así por ejemplo si ejecutamos:

>mandiant_ioc_finder.exe report -s ./INDICADORES/audits -i FICHEROXML.ioc -t html

nos indica que la fuente de nuestros datos (-s) está en la ruta /INDICADORES/audits, que buscamos los patrones de infección definidos en FICHEROXML.ioc y que el informe de resultados nos lo muestre en formato html (-t). Un ejemplo de uno de esos informes de salida extraído de este artículo de Mandiant se muestra a continuación:

Los IOCs representan una manera eficiente y rápida para identificar y definir amenazas avanzadas que de otra forma resultarían muy complejas de evidenciar y que, en algunos casos, pasarían inadvertidas por sistemas AV o HIDS. Hay que considerar por tanto su uso para analizar equipos que muestren comportamientos extraños como por ejemplo aquellos que presentan patrones de tráfico poco comunes.

Si adquirimos soltura definiendo IOCs pueden ser de gran efectividad en el ciclo de vida de una investigación ante un incidente de seguridad.

El proceso sería el siguiente: tras una evidencia inicial de un equipo/s comprometidos se investiga vía análisis forense cual es el IOC de la intrusión y se crea. Una vez creados se despliega en nuestros sistemas o redes objetivo para buscar la existencia de este IOC en otros sitios. Si se identifican nuevos sistemas sospechosos se recolectarán estas nuevas evidencias que tras analizarlas nos ayudarán a identificar más en profundidad la intrusión, descartar falsos positivos,etc, que nos ayudarán a refinar y crear nuevos IOCs de forma que volvemos a iniciar el círculo hasta que creamos haber recopilado toda la información necesaria.

Este proceso puede ser muy lento si tenemos que ir equipo por equipo ejecutando el IOC Finder así que dependiendo de la infraestructura que haya o diseño de la red podemos pensar en automatizar este proceso ayudándonos de ciertas infraestructuras.

Por ejemplo, imaginemos que nuestras máquinas forman parte de un Active Directory (AD) por el cual podemos administrar los inicios de sesión en los equipos conectados a la red, establecer políticas por ejemplo a determinadas Unidades Organizativas (OU), grupos de usuarios, desplegar programas en muchos equipos, etc. Podríamos valernos de diversos métodos que podemos implementar con dicho AD para automatizar el proceso de recolección de IOCs en varios equipos.

Así pues, supongamos un escenario ficticio en el que tenemos un Controlador de Dominio “midominio”, del que forman parte varias OU (Departamento 1, Departamento 2, etc). Dentro de esas OU tenemos varios equipos y usuarios sobre los que podemos realizar de manera centralizada ciertas acciones (lo recomendable es tener equipos y usuarios en OU diferentes pero para comodidad de las pruebas lo he establecido así):

Supongamos por ejemplo que dentro de mi Departamento 1 se ha encontrado una máquina comprometida, la he analizado y he creado mi IOC y quiero comprobar en todas las máquinas de ese mismo departamento si hay alguna otra que presenta ese mismo IOC valiéndome del IOC Finder.

Con el AD podemos hacer, entre otras acciones, lo siguiente:

• Asignar vía GPO scripts de inicio y apagado del equipo: Cada vez que el equipo se encienda/apague se ejecutarán los scripts que le hayamos asignado. Lo hará con privilegios de la cuenta System.
• Asignar vía GPO scripts de inicio y cierre de sesión del usuario: Cada vez que el usuario inicie/cierre sesión se ejecutarán los scripts que le hayamos asignado. Se ejecutará con los permisos del usuario en cuestión, por lo que habitualmente habría que darle permisos de Administrador.
• Asignar directamente al perfil del usuario/s el script que queramos que se ejecute al inicio. Lo hará con los privilegios que cuente el usuario, por tanto habría que darle permisos de Administrador normalmente.

Así pues supongamos que —por poner un ejemplo— podemos crearnos un vbscript, recolector.vbs que nos llame a nuestro mandiant_ioc_finder.exe y al cual le indicamos que nos copie todos los ficheros XML resultados en una ubicación compartida a la que los usuarios/equipos lleguen y tengan permiso de escritura. Habitualmente en muchas organizaciones se puede utilizar por ejemplo el servidor del AV —al que los equipos tienen acceso para actualizaciones y similares— creando una carpeta para tal fin, yo he llamado “indicadores” a esta carpeta. Grosso modo, de manera muy simple, nuestro vbscript podría ser contener líneas similares a las siguientes:

Set WshShell = WScript.CreateObject(“WScript.Shell”)
WshShell.run(“mandiant_ioc_finder.exe collect -o //10.0.0.3/indicadores”)

En este caso incluiremos el mandiant_ioc_finder.exe en la misma ubicación que recolector.vbs.

Si optamos por la opción de crear una GPO vinculada a mi OU=Departamento 1 para que recolector.vbs sea ejecutado al inicio de sesión del usuario los pasos a seguir serían los siguientes (para asignar el script al inicio/apagado del equipo los pasos son similares, he escogido por comodidad que se ejecutara al inicio de sesión del usuario):

1. Dejo mandiant_ioc_finder.exe y recolector.vbs en el recurso compartido NETLOGON de mi controlador de dominio u otra carpeta compartida de dominio.

2. Me sitúo sobre la OU sobre la que quiero aplicar la directiva en cuestión, en este caso Departamento 1, y presiono boton derecho del ratón para desplegar el cuadro de diálogo de Propiedades, en el que me dirigiré a la pestaña Directiva de grupo y pulsando en Nuevo crearé un vínculo de objeto de directiva de grupo al que le he llamado “Recolección de IOCs”:

Una vez nombrada, presionamos en Editar para su configuración:

Como vemos en la imagen anterior podemos aplicar la configuración específica sobre el equipo “Configuración del equipo”, o sobre el usuario “Configuración de usuario”. Para asignar un script al inicio de sesión del usuario, nos dirigimos a Configuración de usuario>Configuración de Windows>Secuencia de comandos(inicio de sesión/cierre de sesión) —de igual forma para asignar un script al inicio/apagado del equipo iriamos a Configuración del equipo>Configuración de Windows>Secuencia de comandos—. Una vez en este punto, elegimos en este caso la ejecución del script al inicio de sesión del usuario, y pulsamos en Agregar para cargar el/los script/s que queramos asignar al inicio:

Si pulsamos en Examinar nos lleva a la ubicación en la que tenemos que dejar nuestros ejecutables:

Y seleccionamos nuestro .vbs:

Una vez hecho esto la directiva ya estaría creada y cada vez que los usuarios iniciaran sesión en los equipos de Departamento 1 ejecutarían el recolector.vbs, con lo que en la carpeta indicadores comenzarían a llegar nuestros primeros resultados (podemos probar en un equipo de prueba que funciona forzando una actualización de las directivas con el comando gpupdate /force e iniciando sesión). Una vez en destino los ficheros podrían procesarse. Podría incluso pensarse en automatizar también este proceso.

Si no queremos aplicar una directiva de grupo podemos recurrir a asignar el script directamente como secuencia de inicio de sesión, seleccionado en nuestro AD el usuario/s que queramos, botón derecho > Propiedades y en Perfil podemos introducir directamente el script que deseamos que se ejecute al inicio de sesion de esos usuarios escogidos:

Comentar que el comportamiento de los scripts puede perfilarse mediante algunas políticas que se sitúan en el apartado Plantillas Administrativas (grupo que contiene todas las configuraciones de políticas basadas en el registro de Windows Server), por ejemplo ejecutar la secuencia de comandos de inicio de sesión de forma síncrona/asíncrona, tiempo de espera máximo para secuencias de comandos de directivas de grupo, etc.

Probablemente hayan soluciones mucho más elaboradas, lo que dependerá también de cada infraestructura, de la carga de la red (igual al inicio de sesión o arrancado del equipo la ejecución de este script ralentice mucho la máquina y haya que programar esta tarea para otra hora, o conviene hacerlo al final del día…etc, importante probarlo todo primero en PREPRODUCCIÓN y junto a los administradores y expertos en AD de la organización), del objetivo de los investigadores, del administrador del dominio, etc. En cualquier caso mi objetivo es dar unas pinceladas genéricas de como podría pensar hacerse este despliegue en un AD para automatizar este proceso. Agradecería cualquier aportación o sugerencia al respecto.

Nota: documentación sobre implementación y gestión de AD hay mucha y muy variada, con grandes libros y foros de ayuda ya que es una tecnología muy extendida, como por ejemplo este PDF sobre Administración avanzada de Windows Server 2008 R2. Yo realicé las pruebas implantando un controlador de dominio sobre un Windows Server 2003 y con Windows 7 como equipos de usuarios.

(Este artículo fue publicado previamente por José Rosell en la revista Economia3)

Wikipedia define ingeniería social como “la práctica de obtener información confidencial a través de la manipulación de usuarios legítimos”. Cuando nos referimos al uso de esta técnica relacionada con los Sistemas de Información y Comunicaciones podemos decir que “es una técnica usada para obtener información, acceso o privilegios en sistemas de información que les permitan realizar algún acto que perjudique o exponga la persona u organismo comprometido a riesgo o abusos”. O sea, vulgarmente podemos decir que la ingeniería social consiste en el uso de todo tipo de triquiñuelas para engañar a una persona, aparentemente confiada, para que permita el acceso, sin darse cuenta, a su ordenador y por tanto en la red de su casa, o de su empresa, o del organismo donde desarrolle su actividad. Una vez dentro de la red el “ingeniero social” no tendrá más que extender sus tentáculos en la red y dedicarse a localizar al objetivo realmente deseado que, normalmente, no tiene por qué coincidir con el destino del ataque inicial.

La ingeniería social se compone por tanto de técnicas de engaño de todo tipo, tanto en el mundo físico como en el virtual que, desgraciadamente, están muy de moda hoy en día, sobre todo en su faceta relacionada con las TIC. Actualmente la ingeniería social es uno de los vectores de ataque más peligroso y que más se está utilizando para tomar posiciones de privilegio en redes ajenas obteniendo acceso a la información de las mismas a través de los empleados de las propias organizaciones.

¿Con qué fin? Muy sencillo. Con el fin de causar un daño. Ya sea porque trabajamos en una organización que tiene algún interés económico o de otro tipo para el atacante. Ya sea porque simplemente quieren robarnos o porque quieren información que tiene un valor en el mercado. Lo que quiere este tipo de “ciberdelincuentes” modernos, como cualquier otro tipo de delincuente, es apropiarse de forma ilícita de cualquier cosa que tengamos que merezca la pena en nuestra organización: nuestros resultados de investigación y desarrollo, el diseño de los procesos industriales, nuestra cartera comercial, nuestra lista de precios y sus márgenes, la fórmula de un producto, nuestra estrategia de cara al mercado en los próximos años, una lista de personas con números de cuenta, el listado de los enfermos que han pasado por un Hospital, nuestros planes de expansión, etc…

Aunque este tipo de ataques son muy antiguos, en el mundo TIC fueron popularizados por un famoso “hacker”, según se autodefine él mismo, conocido con el pseudónimo de “Cóndor”, Kevin D. Mitnick ,que contó sus experiencias y su historia personal en su libro “The Art of Deception: Controlling the Human Element of Security” (ver el post al respecto en Microsiervos) escrito en el año 2002, y que acabó, por cierto, en la cárcel en el año 1995 tras múltiples juicios.

Esta técnica se sustenta en el principio de que el punto más débil de cualquier sistema de defensa somos las personas. Mitnick defiende que un buen ataque de ingeniería social se diseña teniendo en cuenta cuatro principios básicos de las relaciones humanas:

• Todos queremos ayudar.
• El primer movimiento es siempre de confianza hacia el otro.
• No nos gusta decir No.
• A todos nos gusta que nos alaben.

En el mundo TIC este vector de ataque tiene especial relevancia en el ámbito profesional desde hace unos años ya que hemos asistido a la caída de las fronteras digitales de las compañías a una velocidad de vértigo. Hace poco discutíamos si debíamos o no considerar dentro del perímetro de la seguridad de las organizaciones lugares como los domicilios de determinados empleados y hoy nos encontramos con que la frontera ya no son los espacios físicos, ni las máquinas, ni siquiera las redes. Hemos desdibujado las fronteras. La frontera actual somos nosotros, las personas, que con un sinfín de dispositivos móviles de todo tipo hemos puesto en jaque alguno de los principios establecidos hasta la fecha de la ciberseguridad.

En estas condiciones es muy fácil, hoy por hoy, lanzar un ataque de ingeniería social y tener éxito. De hecho, S2 Grupo ha tenido durante muchos años como norma no hacer este tipo de pruebas porque el éxito de las mismas estaba garantizado. Hoy en día hemos cambiado totalmente nuestra estrategia porque el objetivo no es comprobar si podríamos tener éxito, sino enseñar a nuestros clientes, a través de simulaciones de este tipo de ataque, a protegerse de los mismos.

Imagínense ustedes en un ascensor de un edificio público o de oficinas que dejamos en el suelo una llave USB con una etiqueta que pone CONFIDENCIAL. ¿Qué creen que pasará con esa llave USB? ¿Cuánto tiempo creen que pasará hasta que una persona pinche esa llave USB en un ordenador de una red? ¿Qué creen que pasaría si en esa llave USB hubiese un fichero llamado “nominas2012.xls” o “reestructuración gobierno.doc”?

Pasaría lo que pasa siempre. Alguien, más temprano que tarde, sin ninguna mala intención, introduciría la llave USB en un ordenador de una red y alguien, movido por una curiosidad natural en el ser humano, abriría alguno de los ficheros contenidos en la llave USB. A partir de ese momento, el fichero adjunto nos permitiría desplegar en el equipo, y posteriormente en la red, algún tipo de malware que nos permitiría tomar privilegios en la red y desarrollar nuestra actividad delictiva a nuestro antojo.

Pero no se crean ustedes que hace falta usar el truco de la llave USB en la oficina. Al fin y al cabo podríamos argumentar que ese ataque requiere un acceso físico al edificio. Este tipo de ataques nos pueden venir a través del envío de un correo electrónico a personas escogidas de la organización (spear phishing) simulando un simple correo electrónico de una agencia de viajes, con la que nuestra empresa trabaja habitualmente, informando sobre ofertas especiales para empleados de la compañía en un adjunto, que por supuesto estaría convenientemente infectado con algún tipo de malware, o suplantando la identidad de un compañero del departamento de RRHH que nos remite supuestamente un fichero pdf con nuestra nómina que lleva un troyano.

Son muchas las variantes que podemos encontrar de ataques de ingeniería social, desde ataques genéricos en los que “caen” pocos individuos (un “phishing” masivo para obtener contraseñas bancarias), hasta los ataques perfectamente estudiados y dirigidos en los que hay que ser realmente desconfiado para no “caer” en la trampa (como el “spear phishing” comentado anteriormente). Tengan ustedes en cuenta que a poco que seamos habilidosos con las búsquedas en Internet, seremos capaces de averiguar, de algunas personas, su DNI, su teléfono, su dirección, el apartamento que tiene, su correo electrónico, el último viaje que ha hecho publicado por su hija en twitter, incluso el nombre de su gato sacado de facebook o el de su vecino de arriba que ha puesto una denuncia por un aparato de aire acondicionado que hace mucho ruido. La información está en la red. Solo hay que saber encontrarla.

Para combatir esta amenaza se diseñan servicios de inteligencia social orientados a la protección de la información frente al “factor humano”, orientados a mitigar el riesgo de sufrir, directa o indirectamente, ataques de ingeniería social. Estos servicios empiezan por analizar las organizaciones para detectar posibles objetivos de ataques de ingeniería social y se encargan, entre otras cosas, de entrenar a la organización para que esté atenta ante este tipo de amenaza. De forma periódica y controlada, equipos expertos contratados a tal fin lanzan oleadas de distintos tipos de ataques orientados a medir el grado de protección de las organizaciones ante este tipo de amenaza y con el fin de que sirvan como píldoras de concienciación para todos los miembros de la organización.

Estos ejercicios deben enmarcarse en los programas de concienciación globales en materia de ciberseguridad y son de vital importancia de cara a garantizar la seguridad de las organizaciones en el futuro. Así lo recogen las agendas digitales y las estrategias de ciberseguridad que se están publicando en el mundo y que inciden en que uno de los factores clave para el uso de las TIC en la sociedad y en los negocios es el fomento de la seguridad a través de la concienciación.

Probablemente muchos de vosotros habréis caído en la cuenta de la falta completa de información referente a la seguridad en desarrollo web que se suele impartir en universidades, o específicamente, en cursos o másteres de desarrollo. De toda la gente a la que he preguntado, a nadie le han enseñado técnicas de desarrollo seguro en su formación universitaria. Sólo una persona, que acabó recientemente la carrera, me comentó que había una asignatura referente a seguridad, muy en general, y era de libre elección. Y no sólo en la formación. En cualquier libro técnico sobre introducción al desarrollo web, tampoco hacen mucha mención a la necesidad de filtrar parámetros de entrada, o cifrar las comunicaciones de un formulario de login.

¿Y por qué menciono yo esto? ¿Por qué es tan importante que un desarrollador tenga conocimientos de desarrollo seguro? Porque ahorra tiempo y dinero. Se estima que el coste en euros de solucionar una vulnerabilidad detectada en producción es 15 veces más que si se hubiera arreglado en la fase de desarrollo. Muchos sabréis de primera mano lo tedioso que es subir una nueva versión a producción: pruebas en pre, ventana de mantenimiento para detener la aplicación, litros de café y plegarias para que nada explote.

Mi idea al escribir este post es recopilar lo esencial de lo esencial, como base para aprender en qué momentos es necesario tomar ciertas medidas de seguridad. Por suerte, todo lo que he considerado de imprescindible lectura está disponible libremente en la web de OWASP. Por supuesto, hay muchísimo más, aunque me he centrado en comentar los proyectos de OWASP por ser recursos desarrollados por la comunidad.

El primero de todos, la guía de desarrollo seguro de OWASP. Este documento explica las vulnerabilidades web más comunes y su forma de evitarla. Actualmente la versión publicada es del año 2005, aunque la información sigue siendo hoy día perfectamente válida. La mayoría de ejemplos están descritos en Java. Además de los temas conocidos como validación de datos de entrada, gestión de sesiones, mecanismos de autenticación o autorización, toca temas como webservices, phising, o buenas prácticas en el manejo de errores. Es un recurso que todo desarrollador web debería conocer, y tener a mano para consultar, para que al menos, aunque no recuerde cómo implementar de forma segura cierta funcionalidad, si que al menos sepa que lo que está programando implica una posible vulnerabilidad y que es necesario desarrollarlo con cuidado.

Otra lectura muy recomendable es la guía de revisión de código. Aplicable tanto para el personal dedicado a la fase de test de un proyecto, como a los pentesters que realizan test de intrusión de caja blanca, con acceso al código fuente. Se definen una serie de controles y muestra en qué hay que fijarse para detectar una posible vulnerabilidad. Enseña tanto errores comunes como buenas prácticas.

Por último, Application Security Verification Standard (ASVS) son una serie de controles, que a modo de CheckList, puede sernos muy útil usarlo en la fase de testing. Está categorizado por el tipo de vulnerabilidades a revisar y además catalogados en tres niveles, dependiendo del nivel de exigencia a cumplir. Actualmente la versión 2.0 está en fase de borrador con muchas mejoras, como la simplificación de niveles y nuevas categorías, como desarrollo para aplicaciones móviles. Un recurso muy valioso tanto para el desarrollador como para el jefe del proyecto.

Y por supuesto, no me puedo dejar como fuente de información este blog ;) Sobre todo muy interesantes los post de nuestros compañeros David, Guillermo, y Nedim.

Continuando con el ciclo de diseño y desarrollo de los sistemas de tratamiento de la información, una vez tenemos desarrollados los programas que habrán sido probados por los programadores, y las corrientes de trabajos, montadas igualmente por los programadores o por los encargados de la planificación y explotación de sistemas, será necesario ejecutar ciclos de pruebas del producto obtenido, antes de proponer su aceptación por parte del cliente. Para ello, es muy conveniente disponer de un conjunto de datos de prueba, lo más completo posible, que abarque el máximo de transacciones diferentes y de los casos descritos en la primera etapa del proyecto “Toma de Requerimientos” para verificar que los resultados son los deseados, especialmente en aquellas transacciones más complejas y conflictivas que pudieran darse.

Para preparar las pruebas, y conseguir un buen set de datos de prueba (en mis tiempos les llamábamos un “juego de ensayos”), es muy conveniente tener la colaboración del usuario más experto posible, es decir de quién de verdad trabaja sobre el sistema y pelea diariamente con la información. Ello puede ser problemático si el usuario se siente amenazado por la implantación del sistema (hay que ser psicólogo en este asunto), o si tal vez está tan ocupado que es difícil conseguir su participación en esta etapa. Lo mejor es tenerlo previsto y planteado en los primeros pasos del proyecto como una necesidad que el cliente debe atender y tal vez no solo en las pruebas, sino también en la previa definición detallada de los procesos.

Si el sistema va a trabajar contra una base de datos que ya existía y para las pruebas se decide obtener una copia de aquella, es muy importante tener la autorización por escrito del responsable de esa base de datos para poder copiarla, máxime en el caso de contener datos de carácter personal (LOPD) y además será necesario dotar a esta copia de las medidas de seguridad exigidas por la citada ley y su Reglamento y destruirla tan pronto como no se justifique su existencia.

Si el sistema va a trabajar sobre una base de datos nueva, un proceso de migración de datos será necesario, a no ser que se parta del punto de crearla desde cero, cosa poco frecuente. Para realizar dicha migración, se tendrán que preparar programas específicos que cumplan las condiciones equivalentes a las definidas para la entrada de datos al sistema, quiero decir que probablemente se requieran parámetros y valores de control nuevos que no existen en el diseño antiguo a sustituir, y que tanto como sea posible, deben ser introducidos de forma automatizada en la nueva base de datos, y si esto no es posible, tendrán que ser posteriormente introducidos a mano en un proceso de validación manual de la misma.

Siempre se deberá tener en cuenta el balance de coste y dedicación contra el beneficio de obtener una base de datos depurada contra el hecho de que se depure después en el tiempo. Obviamente es preferible obtener datos ya limpios y completos, pero como esto no siempre es posible, en algunos casos, conviene prevenir un “estado” de los registros de la base de datos que indique su situación de “Validado” o “Pendiente de validar”, aparte de otros tal vez más comunes como “Bloqueado para proceso” o “Cancelado”. Probablemente habrá otros estados de datos que dependerán de las características de la información y del proceso a realizar, pero los dos primeros indicarán el estado natural de una nueva información, “Validado” es un registro con información contrastada y depurada, mientras que “Pendiente de validar” serían las entradas de datos que no han podido validarse por completo y por lo tanto, los diferenciaremos para poder revisarlos y ajustar sus contenidos posteriormente. Idealmente, programas específicos para localizar estas entradas deberían estar disponibles, con el fin de completar su revisión o validación en el menor plazo de tiempo posible, pero esto conlleva un coste adicional que no es fácilmente asumible, aunque mantener datos erróneos o incompletos, a la larga suele tener mayor coste.

Para el propósito de realizar las pruebas más completas del sistema, es conveniente elegir un set de datos completamente validado, e incluir en dichas pruebas los programas de migración de datos. Analizar la base de datos de pruebas obtenida, antes de empezarlas, nos evitará después quebraderos de cabeza al comprobar los resultados de las mismas.

Normalmente, si los programas se desarrollaron con un buen conocimiento del proceso (análisis técnico o detallado) y una documentación adecuada, y también han sido probados individualmente con conjuntos de datos validados, lo normal es que las pruebas den resultados satisfactorios desde el primer momento, habiendo siempre cosas que corregir y ajustar, pero de poca envergadura y no surgirán errores de interpretación sobre la naturaleza y detalle del proceso y sobre todo errores de la funcionalidad del mismo, que con bastante frecuencia pueden dar al traste con el proyecto y tener que revisarlo por completo.

Por tanto “casques” de procesos y resultados imprevistos no deberían aparecer una vez depurados los programas y cadenas de trabajos individualmente, y solo errores de codificación y ajuste del sistema deberían ser objeto del trabajo en esta etapa.

Una vez el usuario experto da por buenos los resultados, es hora de presentarlo a los responsables del proyecto para requerir su aceptación, y de planificar la etapa siguiente con la implantación o despliegue del sistema en el entorno de producción del cliente.

El preprocesador reputacional de Snort no es algo nuevo; de hecho, apareció en agosto de 2011 con la versión 2.9.1. Hasta aquel momento, la única forma de manejar listas negras de direcciones IP era a través de reglas con el motor de detección, creando una regla con una lista de direcciones IP, como las utilizadas en el conjunto BotCC (emerging-botcc.rules).

alert tcp $HOME_NET any -> [103.6.207.37,106.187.42.91,106.187.48.236,107.20.73.183,
108.170.20.73,108.170.56.211,108.61.240.240,108.61.26.189,109.109.228.186,109.111.79.4,
109.163.233.16,109.163.233.22,109.196.130.50,109.228.25.175,109.234.106.53, 109.74.194.110,
112.175.124.170] any (msg:"ET CNC Shadowserver Reported CnC Server TCP (group 1)"; flags:S; 
reference:url,doc.emergingthreats.net/bin/view/Main/BotCC; reference:url,www.shadowserver.org; 
threshold: type limit, track by_src, seconds 3600, count 1; classtype:trojan-activity; 
flowbits:set,ET.Evil; flowbits:set,ET.BotccIP; sid:2404000; rev:3259;)

Esta forma tenía una limitación por lo que se creaban listas interminables de reglas relacionadas con una lista negra separadas en grupos teniendo alertas del estilo “ET CNC Shadowserver Reported CnC Server UDP (group 49)” o “ET COMPROMISED Known Compromised or Hostile Host Traffic UDP (43)”.

[Read more…]

Últimamente, por desgracia, cada día finalizan multitud de relaciones laborales. En algunos casos, es el trabajador quien se da de baja voluntariamente (lo más normal es que haya encontrado un trabajo mejor) y en la mayoría, es la empresa quien despide a su empleado.

Pero ¿qué pasa cuando un trabajador deja de tener relación con su empresa? Obviamente, durante cada etapa laboral se adquieren muchos conocimientos de diversa índole y eso no se pierde al dejar de formar parte de la empresa (lo cual obliga a distinguir conocimientos e información: saber cómo implantar un SGSI es diferente a “llevarse” los modelos de procedimientos, aunque sea éste quien los hubiera desarrollado, siempre evidentemente en el marco de un acuerdo de confidencialidad) y se tiene acceso a determinada información con diferentes grados de confidencialidad.

En teoría, cuando concluye la relación laboral, el empleado (ex empleado ahora) deja de tener acceso a las instalaciones de la compañía, sus repositorios de información, su correo electrónico, en definitiva a sus sistemas de información. Ahora bien, ¿esta teoría se cumple siempre? ¿En qué plazos debería hacerlo? ¿Cómo de estrictos debemos ser con estos temas?

Nunca se puede generalizar, y en este tema en concreto conozco dos casos muy cercanos y completamente opuestos que, a primera vista, me parecen los dos extremos de cómo hacer mal las cosas. Por un lado, tenemos a una amiga que estaba realizando una sustitución por maternidad, por lo que la duración de su empleo estaba claramente establecida de antemano. Cuando llegó el último día a trabajar, no pudo acceder a las instalaciones porque habían desactivado su tarjeta. Y una vez dentro (cuando le abrieron la puerta sus compañeros), no pudo utilizar el ordenador porque le habían desactivado ya el usuario del dominio, el correo electrónico y el acceso a Internet. No podía hacer nada, pero tampoco la dejaban marcharse a casa.

En el caso completamente contrario, un amigo fue despedido por fin de proyecto y todo parecía ir con normalidad. Sin embargo, algo más de un año después del despido, su antiguo jefe le llamó para preguntarle “si recordaba la contraseña del panel de administración del cliente X”. Tras comunicarle la contraseña que utilizaba él en su día, la curiosidad le pudo y comprobó que la contraseña seguía siendo la misma.

¿Podemos decir que alguna de las dos empresas actuó 100% de forma correcta?

Vayamos por partes. En cuanto a la obligatoriedad de restringir los accesos del ex empleado, podemos remitirnos, además del sentido común, a la norma UNE-ISO/IEC 27002 que en su dominio de control “Seguridad ligada a los recursos humanos” contiene algunas consideraciones importantes.

Por ejemplo, establece que se debe completar la devolución de todos los activos de la empresa que posea al finalizar la relación laboral. Esto incluye desde portátiles, ordenadores y teléfonos móviles hasta documentos, manuales e información en soporte electrónico. También indica que si el empleado utiliza algún dispositivo personal con fines laborales, se debe asegurar que la información se transfiere a la organización y se borra de los equipos de forma segura.

Respecto a los derechos de acceso, indica que deberían retirarse al finalizar el empleo o contrato. Estos derechos incluyen tanto el acceso a las instalaciones (las llaves o tarjetas de acceso se deberían devolver junto con el resto de activos) como a la información corporativa (por ejemplo, si el trabajador ha tenido acceso a contraseñas de sistemas que siguen activos tras su marcha, deberían cambiarse). Sin embargo, si profundizamos un poco más en la norma, establece que los derechos de acceso deben reconsiderarse en función de los siguientes factores para determinar si han de retirarse antes de la finalización de la relación laboral:

• Si se trata de una baja voluntaria o ha sido decidido por la organización, así como los motivos.
• Responsabilidades actuales del trabajador.
• Valor de los activos a los que tiene acceso.

Es decir, no es lo mismo que se produzca la baja de un responsable de departamento que de un reponedor, ni es lo mismo que sea por una finalización de contrato que por faltas graves del empleado, etc.

Según esto, parece que el primer caso transcurrió conforme a la norma y el segundo no. Pero hay otras cosas a tener en cuenta. Por ejemplo ¿era necesario una retirada radical de accesos en su último día de trabajo? ¿Hubiera sido admisible esperar al día siguiente (o a última hora de ese día) para hacerlo? ¿Quién decide tener a una persona en su puesto de trabajo sin que pueda hacer absolutamente nada? ¿Qué sensación tiene esa persona en sus últimas horas de trabajo?

Además, hay otro aspecto importante a tener en cuenta. La norma dice “a la finalización del empleo”, pero el Estatuto de los trabajadores establece que, en caso de despido, se debe preavisar al empleado con 15 días. Entonces, durante ese tiempo ¿el empleado sabe que va a ser despedido y sigue teniendo acceso a todos los recursos de la empresa? Omito intencionadamente el caso de la baja voluntaria porque el empleado podría llevarse la información que quisiera antes de comunicar el preaviso establecido por su convenio colectivo.

Así pues ¿cómo compatibilizamos el preaviso que se debe dar a un empleado antes de su despido con la retirada de los accesos del mismo? ¿Tiene sentido el despido “de hoy para mañana” para evitar una posible fuga de información? ¿Cuál sería un plazo razonable para cancelar los accesos protegiendo la información? ¿Qué es más importante, la información de la compañía o el trato a los empleados?

Un montón de incógnitas a las que los responsables de Recursos humanos y de TI se enfrentan a diario. ¿Qué opináis vosotros?

En la última entrada de David Cutanda nos dejamos por nombrar algunos de los requisitos deseables para este tipo de dispositivo en una PKI. Vamos con ellos:

• Mecanismos de autenticación y autorización para múltiples usuarios y factores: Dada la importancia y criticidad de los datos contenidos en el dispositivo, es habitual que la autenticación para el acceso al mismo no se base en un solo factor, ni se requiera de un solo usuario. Vayamos por partes, un factor es un método para validar a un usuario. Por ejemplo, un factor será una contraseña, ya que empleando únicamente una contraseña se podría acceder, por ejemplo, a una cuenta de correo electrónico. Cuando se implementan métodos de acceso basados en dos factores, se emplean dos métodos distintos, y sólo se accederá si y solo si se validan los dos factores aportados como correctos. Para ilustrar un poco esta explicación se identifican a continuación distintas clasificaciones:

• Algo que el usuario es: Huella digital, imagen de la retina, etc.
• Algo que el usuario tiene: Token, Tarjeta RFID, Teléfono móvil, etc.
• Algo que el usuario sabe: Contraseña, PIN, etc.
• Algo que el usuario hace: Reconocimiento de voz, firma, etc.

Para un uso profesional en una PKI, lo habitual es que el dispositivo HSM soporte autenticación por dos factores para permitir el acceso a las claves almacenadas en el dispositivo, habitualmente claves privadas de la CA (raíz y subordinadas); así como poder configurar que para el acceso se requiera la validación de dos usuarios simultáneos.

• Mecanismos y registros de auditoría completa: Se debe mantener registro de todas las acciones que se puedan realizar en el dispositivo. Esto es debido no solo a que la confidencialidad es importante en un entorno crítico como este, sino que también es determinante la trazabilidad, es decir, la capacidad de saber quién, cuándo y cómo realizó cualquier acción sobre los certificados de la cadena de confianza de la CA. Todos estos registros podrían ser empleados como evidencia si se produjera cualquier irregularidad en el tratamiento de las claves. Por lo tanto, de cara a control, investigación o como evidencia para emprender posibles acciones legales, se debe mantener un registro completo y seguro de actividad. A este respecto se debe registrar cualquier actividad realizada con las claves, tales como generación, archivo, respaldo, recuperación, uso, destrucción, compromiso, etc.
• Copias de seguridad de claves “segura”: El HSM deberá implementar mecanismos de backup que garanticen la seguridad de las claves almacenadas en la copia de seguridad del mismo modo que el propio HSM lo haría; la solución habitual es la más sencilla, mantener un segundo HSM como backup. De acuerdo, ¿pero cómo se realiza esa copia de forma segura? El proceso de copia habitual es el siguiente, de forma previa a realizar cualquier copia se deberá generar un certificado de backup, este certificado será el que se empleará para cifrar las copias de seguridad. El certificado de backup consiste en un par de claves asimétricas, similares a las que se emplean para cualquier certificado o firma digital. Este certificado se generará en el HSM de backup, que deberá estar configurado a tal efecto. El certificado generado se importará al HSM de producción, en el que se configurará como certificado de backup y se empleará para cifrar la copia. La propia copia, del mismo modo que la clave de backup en el intercambio inicial, se almacenará en un soporte compatible por el modelo de HSM que se trate (lo que puede ser una tarjeta, un dispositivo USB, etc.).

Como hemos comentado anteriormente, los dispositivos HSM no sólo se emplean en entornos de PKI, sino que se también se utilizan habitualmente distintos entornos con requerimientos criptográficos elevados.

Antes de finalizar esta entrada me gustaría detallar algunos ejemplos en los que, del mismo modo que en una CA, es habitual el uso de HSM:

• Sistemas de pago con tarjeta (Entorno bancario): Se suelen emplear dispositivos más simples que los empleados en el entorno de PKI, ya que se requieren menos tipos de operaciones. Se emplean habitualmente en terminales punto de venta, concretamente para cifrar el PIN de forma previa a su envío. También se emplean en servidores de verificación, en este caso para descifrar los bloques que contienen los PIN, intercambiar códigos PIN entre puntos de autorización, generación de datos a introducir en bandas magnéticas de las tarjetas, etc.
• Conexiones HTTPS/SSL: En entornos en los que se requiere una alta seguridad y se ven condicionados por elevadas cuotas de uso y tienen objetivos de optimización muy elevados; se puede considerar la utilización de dispositivos HSM como aceleradores criptográficos, ya que pueden generar claves SSL mucho más rápido y en unas condiciones de seguridad mejores que cualquier procesador (este entorno, a pesar de ser parecido, sería independiente del relacionado con un certificado digital que identificara el servicio en internet).

Con esto es todo, más sobre certificados y firma digital en próximas entradas. Muchas gracias por vuestra atención y como siempre quedo a la espera de vuestros comentarios.