Recopilación de información (Information gathering) sobre Logs de Proxy (I)

Uno de los elementos principales a la hora de gestionar el tráfico de una red es mediante la implantación de un proxy. De manera muy simple podemos considerarlo como un sistema que hará de “intermediario” entre clientes y servidores. Es decir, el cliente no accederá directamente a Internet, sino que a la hora de visitar un sitio web, realizará una petición al proxy y será éste el que navegue hacia el sitio web y le reenvíe la respuesta al cliente.

Tener implantado un proxy implica que todo el tráfico de los clientes que accedan a Internet, pasará a través de él y (por tanto) estará siendo monitorizado. Podemos pensar que la implantación de un proxy en una organización tiene como objeto llevar un control de la navegación de los usuarios, y aunque en parte puede ser cierto (lo que tiene sus implicaciones legales que no vamos a tratar aquí), también hay que decir que mediante una configuración adecuada de éste se puede evitar que los empleados accedan a sitios no permitidos, ya sea porque no sean recursos necesarios para el desempeño correcto de su trabajo o porque conlleven un peligro para la seguridad de la infraestructura de la organización.

Debemos recordar que con el simple hecho de acceder a un sitio web, si éste está contaminado y alberga un kit de exploits para diferentes navegadores y versiones, el cliente puede quedar automáticamente infectado en el caso de que su navegador o alguno de sus plugins posea alguna vulnerabilidad no parcheada. Lo que, como todos sabemos, es más frecuente de lo deseable.

Entremos en materia. Imaginemos que hace unos días, a partir de una revisión rutinaria del log del proxy, se detectó que varios empleados de la empresa estaban haciendo un consumo de decenas de gigabytes diarios cada uno. Lógicamente, esta revisión no se hace de manera manual y para ello existen diferentes alternativas que podremos usar para tener la información del proxy categorizada y ordenada. En este y el siguiente post veremos tres aplicaciones de análisis de logs para squid. Para llevar a cabo las pruebas se ha utilizado Kali sobre la que se han desplegado las aplicaciones. El objeto de este post no es detallar el proceso de instalación por lo que este paso queda como ejercicio para el lector (ejercicio sencillo, en cualquier caso).

LightSquid

LightSquid se trata de un conjunto de cgi y scripts en perl que se despliegan en el servidor web, y aunque a priori no ofrezca una interfaz muy moderna ni elegante, se trata de un buen aliado por rapidez y sencillez.

Si accedemos al día en particular nos aparecerá un listado con los usuarios.

Una funcionalidad interesante de lightsquid es que muestra una tabla con las horas de navegación de cada usuario.

La aplicación también mantiene listados de sitios navegados por mayor número de usuarios, ficheros de mayor tamaño descargado, así como listados de usuarios que han visitado determinado sitio. Lamentablemente es una aplicación sin desarrollo actualmente.

SquidAnalyzer

SquidAnalyzer es otro analizador de logs de squid hecho en perl, con mayores funcionalidades que el anterior y con una interfaz más elegante y cuidada (que vale, eso tampoco es muy difícil). Una vez seleccionado el periodo, nos aparecerá una pantalla resumen de la actividad durante el mismo.

En la parte superior, tendremos un menú en el que se nos mostrarán estadísticas de usuarios, URLs, dominios, recursos (agrupados por mimetype).

Una de las características más interesantes de este analizador es que es capaz de agrupar las peticiones por segmento de red, con lo que obtendremos un punto más de granularidad a la hora de hacer estadísticas de uso.

Accediendo a través de las subredes, obtendremos un listado de actividad de usuarios, tiempos de navegación, peticiones realizadas…

Una vez seleccionado el usuario, nos mostrará en detalle la actividad del mismo.

Aparte, podemos obtener estadísticas de tipo de ficheros mas descargados.

Por último podremos tener una vista general de sitios web con mayor actividad.

En la próxima entrada veremos SARG (Squid Analysis Report Generator) y analizaremos cómo encaja todo esto con el mundo de la seguridad.

Análisis de un OLE File con oledump.py

En esta entrada vamos a ver de una manera muy rápida como hacer un análisis de un fichero OLE y analizar los streams que contenga (en este caso se trata de una macro) con la herramienta y reglas de Didier Stevens. El documento no es muy complejo pero nos sirve para ilustrar cómo utilizar esta herramienta.

Hash del fichero cazado en un correo:

e4e46f746fffa613087bba14666a3ceec47e145f  Transferencia_Interbancaria.doc

Paso 1: Lanzamos yara con nuestra reglas:

[Read more…]

¿Te cuento un secreto?

Hace unos meses, llegó a España la aplicación Secret, tanto para Android como para iOS. Y eso ¿de qué va? Para quien no la conozca, las bases de esta aplicación son muy sencillas: puedes publicar mensajes cortos (similar a Twitter) con la peculiaridad de que nadie sabrá que los has escrito tú. Y claro, tampoco sabrás quién escribe las cosas que lees.

Una vez que has incorporado un cierto número de amigos (usando los contactos de tu móvil y tus amigos de redes sociales), podrás ver si las publicaciones que lees son de un amigo o del amigo de un amigo. Con eso se protege el anonimato de tus amigos (si sólo tienes 5 y lees una publicación de uno de ellos, es probable que adivines de quién se trata). También puedes ver las publicaciones de desconocidos sabiendo únicamente su localización.

Contado así no suena mal ¿no? De hecho, en las preguntas frecuentes de la propia aplicación ensalzan que el anonimato que ofrecen permite que la gente se muestre tal y como es y exprese sus verdaderos pensamientos. Incluso dan unas pequeñas indicaciones a sus usuarios para que se sientan libres de expresar lo que piensan, siempre respetando a los demás. Todo muy idílico.

[Read more…]

Alternate Data Stream: ADS – Flujo de datos alternativos en NTFS

Un flujo de datos alternativo (ADS – Alternate Data Stream) es una característica del sistema de ficheros NTFS que consiste en incluir metainformación en un fichero. Podríamos decir que son ficheros secundarios “ocultos” guardados dentro de otros ficheros. El objetivo inicial es almacenar información extra acerca del fichero principal, pero esta técnica también fue muy usada para propagar virus de forma transparente para el usuario.

Aclarar que en este artículo me voy a centrar sólo en el sistema de ficheros NTFS sobre Windows 8 en concreto. En otros sistemas de ficheros existen técnicas similares; el símil con sistemas de ficheros como ext3, ext4, JFS, HFS+, etc., serían los atributos extendidos (EAs – Extended Attributes). La limitación de los EAs es que no se puede incluir una imagen o un archivo ejecutable como sí puede almacenarse en los ADS. Pero como he comentado, en este artículo sólo nos centraremos en NTFS y los ADS.

Hay que tener en cuenta algunas consideraciones de los flujos de datos alternativos:

  • Una aplicación de escritorio solo leerá el flujo principal de un archivo. Es decir, mediante el explorador de Windows sólo se abrirá el fichero que pertenezca al flujo principal. Los flujos alternativos sólo se pueden ejecutar mediante consola de comandos.
  • De igual forma, con el explorador de Windows solo se verá el flujo alternativo, incluso, solo se mostrará el tamaño del fichero perteneciente al flujo principal. Si hay un vídeo de 100MB por ejemplo, éste tamaño no se verá reflejado en el tamaño del fichero.
  • Los flujos de datos alternativos se pueden ver y abrir mediante la consola de comandos.

La finalidad de los flujos de datos alternativos es asociar ficheros o información que pueda ser confidencial, a ficheros de forma que queden ocultos a usuarios. Pero de la misma forma se puede usar esta técnica para alguna actividad maliciosa.

Como particularidad, mencionar que cuando descargamos un fichero de Internet, lleva asociado un flujo alternativo llamado “Zone.Identifier”, que indica la zona desde donde se ha descargado el fichero. Windows después utiliza dicho valor para abrir o ejecutar los ficheros. El significado de los valores es:

Después de la introducción, vamos a ver un ejemplo de cómo crear y ver el contenido de un flujo de datos alternativo. Para el ejemplo vamos a tomar dos ficheros:

  • principal.pdf, lo trataremos como fichero del flujo principal
  • img_oculta.jpg, lo trataremos como fichero del flujo alternativo

Ejecutamos dir para el contenido de la carpeta. Importante, fijaos en los tamaños de los ficheros:

Creamos ahora el flujo de datos alternativo, el comando sería el siguiente:

type img_oculta.jpg > principal.pdf:img_oculta.jpg

¿Qué ocurre si volvemos a hacer un dir? Aparentemente nada ha cambiado…

Se puede observar que el tamaño del fichero principal.pdf no ha cambiado absolutamente nada. Ejecutemos ahora el comando dir /r:

Como se ve en la imagen, el fichero principal.pdf tiene un flujo alternativo identificado como :img_oculta.jpg. Este flujo de datos alternativo coincide en tamaño con el original img_oculta.jpg, de hecho éste se podría eliminar, pero el flujo de datos alternativo seguiría existiendo. También, como ya hemos comentado antes, el tamaño del fichero principal.pdf tampoco se ha alterado.

Para abrir el contenido del flujo de datos alternativo utilizaríamos el comando:

Nombre_de_la_aplicacion fichero.extension:alternativo.extension

En nuestro caso vamos a abrir la imagen oculta con el editor de imágenes de Windows Paint:

mspaint principal.pdf:img_oculta.jpg

En sistemas operativos antiguos como Windows XP, la ejecución de un flujo de datos alternativo se hacía mediante el comando start, pero a partir de Windows 7 esto no está permitido, por lo que se cambió a invocar directamente la aplicación para abrir el fichero.

Supongo que ya os habréis hecho la pregunta: ¿qué ocurre si añado un “.exe” como flujo alternativo? En este caso, nos encontramos con que a partir de Windows 7 no está permitido (por motivos de seguridad) ejecutar un “.exe” como flujo alternativo. Veamos un ejemplo.

Vamos a asociar a un fichero llamado principal.txt la calculadora de Windows:

type c:\Windows\System32\calc.exe > principal.txt:calc.exe

Ahora ejecutamos mediante el comando start:

start .\principal.txt:calc.exe

Y el resultado es un mensaje de error que dice “Windows no puede encontrar el archivo”. Tal y como esperábamos, no podemos ejecutar un fichero “.exe” en un flujo de datos alternativo. Pero como esperábamos, eso no es del todo cierto. Para saltarnos esta medida vamos a crear un script en Python, y mediante este script llamaremos al ejecutable. Por cambiar un poco del típico ejemplo, he decidido iniciar una instancia Google Chrome.

Creamos un fichero llamado script_py.txt con el siguiente contenido:

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys, string, os			
os.system('"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"')

Ahora asociamos el fichero como flujo de datos alternativo de un fichero de texto llamado principal.txt.

type script_py.txt > principal.txt:script_py.txt

Para ejecutar el script de Python lo haremos mediante la sentencia:

C:\Python27\python.exe principal.txt:script_py.txt

Si todo ha ido bien, con esto lograremos ejecutar un fichero “.exe” a partir de un flujo alternativo. En este caso, se abrirá una nueva instancia del navegador Google Chrome.

Esta técnica era muy utilizada por atacantes para insertar malware en flujos alternativos. Aunque hemos visto que en los sistemas operativos actuales no se puede hacer directamente, sí se puede de forma indirecta, por lo que sigue siendo un aspecto a tener en cuenta para garantizar la seguridad.

Aunque no se ha visto en el artículo, existen herramientas para ver los flujos de datos alternativos en modo gráfico. Una herramienta es AlternateStreamView de Nirsoft, la cual te permite escanear carpetas en busca de ficheros alternativos.

Sin lugar a dudas, hay que tener en cuenta los flujos de datos alternativos para garantizar la seguridad de los sistemas, y no ejecutar código malicioso que permanezca oculto. Además, este tema resulta muy interesante a la hora de realizar un análisis forense para una pericial, ya que podríamos obtener información relevante que a simple vista no está accesible.

Los sistemas de control aislados o el móvil perpetuo de primera especie

Existen ideas que se resisten a desaparecer. Y entre ellas hay un tipo especial, las que se basan en la confusión entre los propios deseos y la realidad. En ocasiones estas ideas se convierten en entes que sobreviven a su propia refutación. Durante siglos el ser humano ha ambicionado construir una máquina que sea capaz de funcionar continuamente, produciendo trabajo y sin aportes energéticos del exterior. Tanto la ha buscado que tiene hasta nombre: el móvil perpetuo de primera especie.

Durante siglos mentes por lo demás lúcidas han luchado contra la implacable realidad construyendo modelos que, una y otra vez, han fallado en el momento de ponerlos a prueba. Pero claro, sería tan maravilloso que semejante máquina pudiese existir… Tal vez con esta o aquella mejora pudiese funcionar. Hay que pulir esto y esto, refinar aquello. Todo en aras de la promesa de la liberación energética. Pero no. Es imposible una máquina tal en nuestro universo porque su mera existencia violaría una ley esencial del mismo: el primer principio de la termodinámica. Ante esta evidencia la Academia Nacional de las Ciencias de Paris decidió en 1775 que no aceptaría más proyectos de móviles perpetuos. Tal era el grado de consolidación de la termodinámica entonces que se adoptó como criterio infalible, ahorrando la necesidad de poner a prueba una y otra vez los dispositivos surgidos de la mente de gente con más buena intención que conocimientos físicos.

El caso es que hoy en día nos encontramos ante un caso similar. Cuando se trata de auditar la ciberseguridad de un sistema de control industrial, no importa el propietario, la tecnología o su propósito, en un gran número de casos acabamos topando con un ente al que podríamos denominar ‘el móvil perpetuo de los sistemas de control’ pero que se conoce habitualmente como ‘el sistema de control industrial aislado’. Y es que, efectivamente, si mi sistema de control estuviese efectivamente aislado y funcionase produciendo trabajo sin intercambiar información con el exterior, no tendría que preocuparme por su ciberseguridad, ¿no es cierto? Estaría asegurada de forma intrínseca.

Una y otra vez los ‘móviles perpetuos de los sistemas de control’ no resisten una investigación en profundidad. En el caso de los sistemas físicos basta definir un volumen de control en torno a nuestro móvil perpetuo y verificar si existe intercambio de energía con el exterior a través de esa frontera. En el caso de los sistemas industriales el concepto es el mismo, pero lo que buscamos son intercambios de información, de un tipo u otro. Siempre los hay: permanentes o temporales, síncronos o asíncronos, cableados o no, tontos (pendrives) o inteligentes (portátiles de mantenimiento). Y es que, ¿para qué sirve un sistema con el que no me puedo comunicar y que no puedo modificar de forma alguna?

La refutación caso por caso supone un importante gasto de energía desde el principio mismo del proyecto. Sería bastante útil que se adoptase un criterio equivalente al de la Academia de las Ciencias de Paris. De esta forma podríamos rechazar a priori cualquier reivindicación de aislamiento y podríamos ponernos a trabajar desde el principio.

Aunque, por otra parte, si configurase mi sistema de esa manera quizá entonces… sí, quizá…

Nota: la ilustración reproduce el ‘recipiente de flujo continuo’ de Robert Boyle. A nuestros ojos modernos puede producir hasta risa, que sin duda se tornará en sonrojo al pensar la opinión que tendrán los humanos del futuro al rememorar como en el siglo XXI se podía intentar defender el concepto de ‘sistema de información digital aislado’ (IMHO).

La seguridad de nuestra privacidad

Vivimos en un mundo “conectado” digitalmente, en el que se distinguen distintos tipos de habitantes, principalmente aquellos que lo vieron “nacer” y los que han nacido como “ciudadanos digitales”.

Pero bien sea en el caso de los primeros por la forma en que se han relacionado habitualmente entre ellos o, en el caso de los segundos por esa confianza infundada de ser nativos, la cuestión está en que en muchas ocasiones se expone lo privado, propio y ajeno, ante el público en general, sin ser conscientes de estar haciéndolo o, peor aún, con indiferencia por el riesgo que entraña.

En la “prehistoria digital”, la gente más abierta se juntaba en parques mientras los niños o las mascotas jugaban, en bares para tomar una copa y poder departir con otros tertulianos, en asociaciones ya fueran culturales o de otra índole y allí, en un foro controlado, compartían historias sobre hechos acaecidos propios o de la familia y amigos. Había una “exposición” pública de la privacidad, pero con un alcance, que normalmente no era un problema, más allá de que a partir de ese momento podía ponerse en marcha la maquinaria de los chismosos y cotillas y, salvo que la historia tuviese meollo, raro era que llegase a más de tres pueblos de distancia. No es que no se obviase ya la privacidad propia, o que no se estuviese faltando a la privacidad ajena sin permiso del interesado, pero digamos que los riesgos eran en cierta manera “controlados” por el propio límite físico de la comunicación.

En la actualidad y, con el auge de todo tipo de redes sociales, las cosas han cambiado y mucho. Se tiende a publicar, sin ni siquiera controlar el alcance con el que se hace, todo tipo de detalles propios. Y lo que es peor, se publica información que atañe a terceros sin una mera consulta previa para ver si el interesado está por la labor. Está claro que ese ansia de ser “reportero” de tabloide es algo innato a muchos humanos, que se afanan por crear toda una serie de noticias sociales, más o menos interesantes, sobre el resto de mortales y de aderezarlas con la correspondiente información propia para mejorar la “calidad” de sus publicaciones.

Pongamos por caso ese afable amigo que nos hace una foto en una cena del grupo de antiguos alumnos y que luego, sin más, la sube a su perfil de Facebook. Y no contento con ello, nos etiqueta en la misma para que todavía sea mayor la probabilidad de que no se pierda entre la jungla de posts que a diario se publican en la red. A ver, que sí, que uno es consciente de que le han hecho una foto. Y que posiblemente, hasta esté agradecido si la misma se la hacen llegar por correo electrónico para poder tener un recuerdo de la ocasión. Pero ¿en qué momento ha autorizado que se le exponga públicamente en la red?

Este tema de publicar fotos de ajenos para la contemplación pública es algo que, al menos yo, no había visto tan extendido como en la actualidad. Con la salvedad de aquellos casos, en que los “amigos” de una pareja se dedicaban a colgar fotos de la misma por los postes del pueblo, indicando que se casaban y otras lindezas. Sinceramente, creo que esto de “colgar” fotos ajenas parece una moda que se nos ha ido de las manos. Parece como, si con el auge de los dispositivos que incorporan una cámara digital, la facilidad de uso de la misma y el coste insignificante de obtener capturas, todo el mundo se hubiese infundido de cierto “espíritu Cartier-Bresson”.

Quizá es necesaria una nueva asignatura en las escuelas y colegios, una asignatura en donde se complemente la enseñanza del uso de las nuevas tecnologías, con la enseñanza de la responsabilidad que supone el uso de las mismas y la necesidad del respeto a uno mismos y a los demás. Quizá sea necesaria la expedición de un carnet de ciudadano digital, que nos reconozca el conocimiento de lo que tan sólo debiera de ser usar el sentido común, y que sin el cual, no se nos permita transitar por este mundo digital.

PFsense: firewall perimetral (V)

En este quinto capítulo sobre Pfsense (ver I, II, III y IV) se explicará la instalación y configuración de Snort, con el fin de incluir un NIDS en nuestro firewall.

Para instalar Snort en system > packages


Una vez instalado, en services > snort, se procede a su configuración:

-= Pestaña iface settings =-

Es donde se elige el lugar en el que Snort va a esnifar. wlan0 en caso de querer que actúe entre internet y la entrada del firewall, o ya si se quiere algo mas interno seria en opt1 para la DMZ o LAN para la red interna. En este caso para ver todo el tráfico hacia Internet lo mejor es elegir wlan0.

Respecto a la variable home_net y external_net se pueden dejar por defecto ya que home_net englobará a todas las direcciones IP internas y external_net a todas las que sean diferentes de home_net.

-= Pestaña WAN barnyard2 =-

Barnyard2 permite procesar los log de Snort e insertarlos en una base de datos externa:

En el apartado “MYSQL Database Output settings” es donde se configura el servidor MySQL externo, donde barnyard2 insertará los Log de Snort. Previamente en este servidor externo se debe crear la base de datos snort y dar permisos al usuario snort y a la dirección IP de Pfsense (192.168.1.2) para que pueda acceder a la bbdd:

mysql -u root -p

CREATE DATABASE  snort;

grant INSERT,SELECT,UPDATE,CREATE,DELETE,EXECUTE on snort.* to snort@192.168.1.2
Set password for snort@192.168.1.2=PASSWORD('snortpass');
flush privileges;

y posteriormente crear el esquema de esta base de datos (se puede descargar desde aquí):

mysql -D snort -u root -p < ./schemas/create_mysql

-= Pestaña Global Settings =-

Las reglas de detección del IDS tienen un papel importante y en este apartado es donde se configuran. Para incluir las reglas VRT se debe incluir un código, que se consigue al registrarse en la web de Snort.

Al registrarse envían un correo con el enlace para entrar logeado en la web de snort.org, luego en nuestro perfil conseguimos el oinkcode.

-= Pestaña updates =-

Por último en la pestaña updates se procede a la descarga de las reglas:


-= Pestaña Suppress =-

Al igual que en el fichero threshold.conf de Snort, es aquí donde se puede limitar las alertas, por origen, destino,o por el numero de coincidencias en un determinado tiempo. Veamos un ejemplo:

Se tiene primero que buscar el sig_id (identificador único de cada regla), para poder limitar las alertas (para el ejemplo “1852”):

  • No alertar cuando el origen sea 192.168.3.0/24.
  • No alertar cuando el destino sea 192.168.1.10 y 192.168.1.11:
    suppress gen_id 1, sig_id 1852, track by_src, ip [192.168.3.0/24] 
    suppress gen_id 1, sig_id 1852, track by_dst, ip [192.168.1.10,192.168.1.11]
  • Suprimir directamente toda la regla:
    suppress gen_id 1, sig_id 1852
  • Solo alertar de una de las alertas de la firma cada 3600 segundos:
    event_filter gen_id 1, sig_id 1852, type limit, track by_src,  count 1, seconds 3600
  • Suprimir cualquier regla para un origen concreto:
    suppress gen_id 1, sig_id 0, track by_src, ip [192.168.1.1]

Para mas información sobre las configuraciones, se puede visitar el siguiente link.

-= Pestaña Pass list y Blocked =-

En el caso de que Snort también funcione como IPS, es decir no solo alerte, sino que pueda bloquear, en estas dos pestañas se elige qué direcciones están exentas de bloqueo o cuáles bloquear. Por defecto las direcciones WAN, los gateway, servidores DNS, VPN, etc. están en la lista de no bloqueo.

Dentro de Services > snort > snort interfaces se edita (botón a la derecha con la letra “e”) en la pestaña WAN Categories:

Se pueden escoger qué reglas usar como se muestra en la imagen.

En la siguiente y última entrada de la serie sobre Pfsense veremos el tema de Squid como proxy HTTP. Espero que os haya parecido interesante.

INES: Informe Nacional del Estado de Seguridad

Desde este post quiero presentar un poco más en detalle a una de las amigas de mi compañero Toni: INES.

INES es el acrónimo de Informe Nacional del Estado de Seguridad, pero más que un informe, se trata de una plataforma telemática que proporciona a las Administraciones Públicas un conocimiento más rápido e intuitivo de su nivel de adecuación al Esquema Nacional de Seguridad. INES, junto con la Guía CCN-STIC 824, Informe del Estado de Seguridad [PDF] servirán para elaborar el Informe Nacional del Estado de Seguridad.

Tal y como se indica en el propio manual de la plataforma, el encargado de acceder a la plataforma es el “Responsable de Seguridad”, por lo que todas las Administraciones Públicas deberían tener nombrado al correspondiente Responsable de Seguridad, para poder realizar las gestiones en la plataforma. Esta frase daría para otro post: ¿tienen todas las Administraciones Públicas un Responsable de Seguridad que ejerza realmente como tal?

El objetivo de la plataforma es doble. Por un lado sirve para que cada Administración Pública tenga un “sitio” donde pueda ir albergando, validando y analizando la información de seguridad propia de su organismo y consolidada a nivel de Administración Pública. Por otro lado, la herramienta permite que el CCN tenga acceso a través de un repositorio común a toda la información que ponen a su disposición todas las Administraciones Públicas, con lo que se da cumplimiento al artículo 35 que señala: “El Comité Sectorial de Administración Electrónica articulará los procedimientos necesarios para conocer regularmente el estado de las principales variables de la seguridad en los sistemas de información a los que se refiere el presente real decreto, de forma que permita elaborar un perfil general del estado de la seguridad en las Administraciones públicas“.

En junio de 2014 el Observatorio de Administración Electrónica elaboró una nota técnica sobre el seguimiento de la adecuación a los Esquemas Nacionales de Seguridad (ENS) y de Interoperabilidad (ENI). En ésta destaca el esfuerzo notable que han hecho las AA.PP para adaptarse a dichos esquemas como suele decirse, “con la que está cayendo”. También se resalta que pese al carácter voluntario de la incorporación de los datos por parte de las AAPP, ha habido una buena respuesta, especialmente por parte de la Administración General del Estado, seguida de las Comunidades Autónomas, Diputaciones y Ayuntamientos.

Según el informe, las Administraciones Públicas que han ofrecido sus datos voluntariamente están bastante avanzados en los aspectos relacionados con protección de instalaciones e infraestructuras, la protección de datos de carácter personal, la identificación de personas, las copias de seguridad, la política de seguridad y la identificación de Responsables de Seguridad y Sistemas. A la vista de los resultados, donde más “pinchan” es en los aspectos relacionados con la concienciación y la formación. El informe insiste en que es esencial que haya un Plan de Adecuación, un Responsable de Seguridad nombrado, se haya realizado una Categorización de los Sistemas y que se realice un Análisis de Riesgos.

No podemos acabar este post sin hacer algunas referencias. La primera a CLARA, otra de las amigas de Toni. CLARA es una herramienta creada por el CCN para analizar las características de seguridad técnica definidas en el Esquema Nacional de Seguridad. Dicho análisis de cumplimiento está basado en las normas de seguridad que han sido proporcionadas a través de la aplicación de plantillas de seguridad, según las guías CCN-STIC de la serie 800: 850A, 850B, 851A y 851B. La segunda referencia es a PILAR, una vieja conocida en el sector de la seguridad, que incorpora desde hace tiempo soporte para el ENS y mediante la que es posible realizar la valoración del cumplimiento de cada medida del Anexo II del ENS.

Acabaré diciendo que espero que el proyecto de modificación del ENS, cuya admisión de comentarios se cerró el pasado lunes 9 de febrero, no contradiga mucho de lo que he escrito. Si así fuese, me comprometo a explicar los cambios en un futuro post.

RAM Scraping en TPV’s

¿Qué es el RAM Scraping?

RAM Scraping es una técnica utilizada por cierto tipo de malware que permite leer directamente de la memoria principal, consiguiendo así acceso a información potencialmente sensible. Esta técnica es actualmente empleada para realizar ataques contra los conocidos como TPV (Terminal Punto de Venta) y tiene como objetivo el robo de información de las tarjetas de crédito asociadas a las ventas que gestiona dicho TPV.

Desde las primeras detecciones en 2009, el número de ataques de este tipo ha aumentando notablemente, siendo los Estados Unidos el país que presenta el mayor número de afectados. Quizás los casos más llamativos sean los ocurridos entre 2013 y 2014 sobre las conocidas cadenas de venta norteamericanas ‘Home Depot‘ y ‘Target‘, de cuyos sistemas se estima que se extrajeron alrededor de 150 millones de números de tarjeta en total.

[Read more…]

Cómo proteger la información en tránsito

Para hoy tenemos una entrada de Toni Grimaltos, Licenciado en Informática e integrante del Servicio de seguridad de la información DGTI de la Generalitat Valenciana.

Pocas veces una organización de la envergadura de un gobierno autonómico hace un cambio de la magnitud que supone trasladar de sede a 2500 trabajadores de diferentes organismos. En este artículo vamos a abordar la problemática de trasladar los sistemas de información y el Sistema de Gestión de la Seguridad de la Información (SGSI) de uno de los organismos implicados en ese traslado, y seguir cumpliendo con los controles que la norma ISO 27002 establece, todo ello sin vulnerar ningún artículo de la Ley Orgánica de Protección de Datos (LOPD).

Lo primero que necesitamos para que esta acción tenga éxito, es la “IMPLICACIÓN DE LA DIRECCIÓN”. Ahora bien, este ideal, ¿cómo lo traducimos a una serie de acciones reales?

[Read more…]