Security Art Work

Cuando planificamos y realizamos copias de seguridad de datos y servidores de nuestro negocio, no es raro que a menudo nos olvidemos de una parte no menos importante que la información alojada en los propios servidores y, a veces, vital: las bases de datos PIM (Personal Information Management) .

Sólo en el caso que dispongamos de terminales móviles tipo Blackberry, y que éstos estén sincronizados con un servidor BES (Blackberry Enterprise Manager), podemos sentirnos medianamente seguros que nuestros datos están replicados. Dependiendo de nuestra instalación, este servidor de sincronización puede estar compartido por la compañía telefónica que nos provee el servicio, o podemos tener uno propio dentro de nuestra infraestructura. Por esta razón, este sistema es uno de los más usados en las grandes organizaciones. Los terminales móviles tienen conexión permanente con el servidor BES, y la aplicación directamente absorbe los datos del propio servidor de correo/PIM (que puede ser un Microsoft Exchange o IBM Lotus Domino). Una de las opciones más interesantes de esta infraestructura es que, en el caso de pérdida de un terminal, el administrador del sistema puede borrar en remoto el contenido del dispositivo e incluso dejarlo inutilizable, aspecto que para empleados que gestionan información sensible puede ser tremendamente útil.

Dejando atrás las ventajas de Blackberry (les aseguro que no me llevo comisión), la mayoría de ustedes seguro que usan algún cliente de correo en sus ordenadores personales, que además integra una libreta de contactos, una agenda, gestión de tareas, etc. Y seguro que también habrán sido víctimas de una pérdida de datos de este tipo de información, lo que suele ser un auténtico desastre para el que la sufre. Es ya un clásico esa típica reinstalación del sistema operativo por razones de actualización del SO, o simple reubicación del equipo, en la que siempre solemos olvidar copiar la ruta escondida que alberga estos datos.

Uno de los recursos más usados para replicar esta información y evitar de esta manera la pérdida de datos es la sincronización con nuestros dispositivos móviles. Hoy en día, casi todos los móviles sincronizan con la mayoría de las aplicaciones a las que hacíamos referencia. Es una buena manera de tener siempre los datos disponibles estemos donde estemos y además, replicados.

Para esta replicación se usan múltiples vías. Lo más fácil y rápido es mediante la conexión USB, otros mantienen la réplica siempre activa por Bluetooth, y los más avezados usan sincronizaciones OTA (Over The Air). Por supuesto, lo más recomendable desde el punto de vista de la seguridad es instalar nuestro propio servidor de sincronización, pero la mayoría opta por soluciones Cloud Computing en servidores de terceros, que añaden la ventaja de una sincronización automática. No hay lugar para el olvido ni el descuido por nuestra parte, ya que nuestro terminal móvil sincroniza cada cierto tiempo con el servidor.

Como ejemplo, y por ser una de las soluciones más implantadas, podemos hacer referencia al protocolo SyncML, que es capaz de sincronizar casi todas las aplicaciones correo/PIM con la mayoría de dispositivos móviles. Hay todo tipo de aplicaciones que realizan esta función: Funambol, Anywr, Vufone, etc. Algunos son OpenSource y otras son soluciones comerciales; incluso Google o la propia Microsoft se han subido al carro, con su Microsoft Phone Data Manager aún en fase Beta.

Lo cierto es que cada vez más compañías telefónicas disponen de ofertas para conexiones 3G y ya se empiezan a encontrar tarifas planas (o casi) a precios antes impensables (o casi). Y si tenemos conexión permanente en nuestro terminal, ¿por qué no vamos a sincronizar su contenido? Y aquí llega la eterna disyuntiva. ¿Nos fiamos de por dónde pasan nuestros datos? ¿Nos fiamos de quien los aloja? Volvemos a poner en la balanza el dueto usabilidad vs. seguridad. ¿Son nuestras entradas de agenda y contactos lo bastante sensibles para no “volar” por servidores de terceros? ¿Qué pasa si perdemos nuestro móvil o se nos borra toda la información almacenada en él?

Para ustedes, ¿qué riesgo es más asumible?

Gran parte de los esfuerzos del área de seguridad a la hora de establecer medidas de protección se basan en el aprendizaje de las técnicas utilizadas por los atacantes. Con este propósito, uno de los pilares fundamentales del personal dedicado a la seguridad está enfocado a la recopilación de información para su posterior análisis, para poder aplicar y reforzar las medidas de seguridad en la organización en función de las conclusiones obtenidas.

Pero, ¿qué información se recopila en este proceso y de qué forma? Existen muchas fuentes de información conocidas como pueden ser los informes de nuevas vulnerabilidades de aplicaciones concretas, estudios de analistas independientes, nuevas técnicas de ataque, o incluso información obtenida del último ataque sufrido sobre un recurso corporativo. Igual que en las novelas de contraespionaje o en las películas de “James Bond”, no es difícil imaginar técnicas de obtención de información que estén basadas en la implantación de señuelos o trampas en forma de aplicaciones, cuyo propósito es registrar la actividad sospechosa de los potenciales atacantes, para que éstos actúen sin darse cuenta de que su comportamiento está siendo realmente estudiado. Así nos lo cuenta Clifford Stoll en su libro “The Cuckoo’s Egg: Tracking a Spy Through the Maze of Computer Espionage” (N.d.E. Un libro que nadie interesado en seguridad debería dejar de leer).

Este es el funcionamento básico de los denominados honeypots: aplicaciones que simulan, de una forma más o menos interactiva, servicios o aplicaciones que registran la actividad sospechosa que un atacante pueda realizar sobre ellos. Al conjunto de honeypots que presentan una arquitectura lógica de red simulando un conjunto de sistemas, servicios y aplicaciones relacionadas, se le denomina honeynet. Por supuesto, en este tipo de entornos simulados no existe información real sensible ni relativa a la organización, pero si información aparentemente interesante que motive al atacante y le haga “perder” tiempo, al mismo tiempo que proporciona información sobre técnicas y métodos de ataque.

En esta línea existe un proyecto dedicado a aunar esfuerzos y desarrollar pautas para la creación, gestión y divulgación de estos sistemas, denominado el HoneyNet Project. En su web es posible encontrar tanto papers con información técnica como referencias a los denominados chapters de cada país relacionados con el proyecto.

En cualquier caso, en este tipo de entornos es recomendable no olvidar que estamos tratando con sistemas que interactúan con potenciales intrusos, y que los clasificamos como honeypots porque tanto la información que se expone como los sistemas que puedan verse “comprometidos” no interfieren de forma negativa en el proceso de negocio de la organización. Como habrán supuesto, el interés de estos sistemas y entornos es doble.

Por una parte, el registro de la actividad del atacante que interactúa con el honeypot o la honeynet muestra nuevas técnicas o tendencias de ataques de los que podemos aprender, y por lo tanto, permite planificar e implantar las medidas de seguridad oportunas a corto, medio e incluso a largo plazo para paliar posibles futuros ataques sobre los sistemas productivos de la empresa. Al mismo tiempo, la existencia de sistemas intencionadamente vulnerables conviviendo con sistemas de producción convenientemente securizados (aunque como saben, nunca lo suficiente) proporciona una forma muy efectiva de dirigir la atención del atacante lejos de los sistemas de negocio. Es importante, no obstante, que el entorno vulnerable esté adecuadamente aislado, evitando que pueda servir de puente hacia otros sistemas internos, y por tanto convirtiendo una herramienta en un problema.

Una vez disponemos de toda la información, ¿cómo podemos recopilar, analizar y aprovechar todos los datos que se van generando? Para ello existen correladores de información que ofrecen una integración bastante sencilla con la mayoría de honeypots existentes, y que a su vez son lo suficientemente flexibles como para adaptarlos al sistema en el que deba implantarse. El resultado de este análisis puede plasmarse en una serie de informes de actividad periódicos que representen el histórico y evolución de la actividad registrada, algo que veremos más adelante en esta serie.

Existe un refrán que dice “Para aprender, perder…”. En la serie de posts que se publicarán más adelante veremos como es posible aprender mucho y perder poco.

(Entrada escrita en colaboración con Alberto Segovia, co-autor de la serie)

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

Muy importantes

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

[Read more…]

Tras los dos artículos previos sobre el TOP 10 de OWASP, en esta ocasión el artículo del top 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en la vulnerabilidad conocida como pérdida de autenticación y gestión de sesiones. Esta vulnerabilidad, desde mi punto de vista, demuestra lo poco que suele preocupar la seguridad a los usuarios. Aunque en la primera clasificación del año 2004 estaba situada como la tercera más encontrada, en la clasificación el año 2007 destacaba por haber descendido hasta el séptimo puesto. Sin embargo, tres años después, en esta nueva clasificación, se vuelve a observar un repunte en la localización de este tipo de vulnerabilidades que la vuelve a colocar en la tercera posición dejando como anécdota la anterior mejora.

Las vulnerabilidades relacionadas con la pérdida de autenticación y gestión de sesiones son críticas en la seguridad de las aplicaciones y en especial de las aplicaciones WEB, ya que permiten a un atacante suplantar la información de un determinado usuario, pudiendo llegar a obtener una cuenta de administración que le permita sabotear los controles de autorización y registro de la aplicación. Esta situación podría ocasionar un acceso no autorizado a cualquier tipo de información que se encuentre almacenada en el servidor o los servicios que han sido comprometidos.

Existen multitud de situaciones en las que nos podemos encontrar ante una aplicación vulnerable a este tipo de ataque, pero la mayor parte de las veces se encuentran en la gestión de las contraseñas, la expiración de sesiones o el proceso de cierre de sesión. Además, debe prestarse especial atención a las procesos que permiten la recuperación de los valores del usuario de forma automática como pueden ser los servicios de pregunta secreta, de actualización de cuenta o de “Recordar contraseña”.

De nuevo, igual que ocurría en la vulnerabilidad explicada en el primer post de la serie de inyecciones, hay multitud de ejemplos que podrían demostrar el uso de esta vulnerabilidad, por lo que vamos a introducir únicamente un grupo reducido de ejemplos que permitan ilustrar la situación, y en caso de que sea necesaria alguna aclaración sobre cualquiera de los aspectos no considerados esperamos que nos lo hagan saber a través de los comentarios.

Veamos el siguiente ejemplo como demostración del tipo de situaciones en las que podemos encontrar un ataque de este tipo: sea una aplicación que dispone de un frontal web en el que un usuario autenticado puede consultar una serie de artículos de una determinada categoría. Navegando por cada uno de los artículos accede a uno que le interesa y que quiere compartir con sus amigos, por lo que accede a la url que tiene en su navegador del tipo:

A continuación cierra su navegador y postea en una red social este enlace para que todos puedan acceder a este curioso artículo. Como el servidor en el que se encuentra el artículo no cierra la sesión del usuario salvo que sea por petición de éste, cualquiera de sus “amigos” que acceda a dicho enlace aparecerá registrado en la aplicación como el usuario autenticado con el consecuente acceso a sus datos.

Del mismo modo, es posible encontrar un ejemplo de autenticación realizada a través de medios no confiables. Pensemos que esta misma aplicación utiliza un servicio de autenticación seguro a través de https. De esta forma, la comunicación viaja cifrada y no es posible interceptar el tráfico para capturar la contraseña del usuario. Como sucede en muchas páginas, el proceso de autenticación proporciona la posibilidad de “recordar” al usuario al marcar un check, de forma que se almacena en local una cookie de la página con el nombre de usuario y contraseña introducidos en el formulario de autenticación.

Aunque durante el proceso de autenticación manual el servicio utiliza una configuración segura a través de https, el proceso de autenticación automático utiliza una configuración a través de http.

En este momento, cualquier atacante de la aplicación que se encuentre controlando el tráfico que intenta acceder la aplicación de catálogo dispondrá del nombre de usuario y su contraseña por no haber utilizado un sistema de comunicación seguro.

Existen diferentes formas de proteger la aplicación desarrollada de este tipo de vulnerabilidades, pero requieren decisiones a nivel de diseño. En primer lugar, la gestión de contraseñas nunca puede almacenarse en texto plano, aspecto que aunque a ustedes les parezca obvio, es más común de lo que piensan. Esto provocaría que un atacante que tuviese acceso a la tabla o al fichero en el que se almacena la información de los usuarios tendría automáticamente acceso a cualquier recurso de la aplicación que desease, independientemente de las medidas de control que pudiésemos plantear. Además, deben utilizarse los servicios que utilicen información sensible a través de canales seguros, como puede ser una conexión sobre SSL, de forma que se evite la posibilidad de que un atacante se interponga en la comunicación de esta información entre nuestro cliente y el servidor de la aplicación de datos.

Por último, una serie de indicaciones generales sobre la forma de gestionar las sesiones:

• Añadir la comunicación cifrada en en el proceso de acceso a la aplicación.
• Eliminar, en la medida de lo posible, la utilización de mecanismos de autenticación del tipo “Recordar Contraseña” puesto que, generalmente, esta contraseña se almacena para poder ser utilizada y la sustracción de ésta valor podría ocasionar la suplantación de usuarios. Por supuesto, en este punto entramos en el equilibrio entre seguridad y funcionalidad.
• Ofrecer un enlace en todas las páginas de la aplicación para que el usuario pueda cerrar la sesión.
• Gestionar de forma adecuada la caducidad de las sesiones ante un período de inactividad.
• Gestionar de forma adecuada el tratamiento de la información cuando se introduzca un identificador de sesión caducado o no válido.

Y hasta aquí todo lo referente a las vulnerabilidades de pérdida de autenticación y gestión de Sesiones, de momento. Como saben, si quieren extenderse en la materia, más allá de los innumerables recursos de la red, pueden acudir a la web de OWASP, donde encontrarán mucha información de utilidad. Como siempre, si tienen interés en que demos más detalles sobre alguna de las vulnerabilidades mostradas, o no les ha quedado clara la explicación, no tienen más que indicarlo en los comentarios y estaremos encantados de ampliar la información.

Hace unos días, después de realizar una instalación de una red de detección de intrusos dedicada, nos quedamos unos cuantos compañeros hablando sobre temas de seguridad. Durante la charla, hubo un apartado acerca de los scripts con bit suid y cómo, mientras en Solaris con la shell ksh se permitía la ejecución de un script suidado, el núcleo de Linux evitaba la ejecución de un script con suid. Antes de continuar con la entrada en el blog, es recomendable conocer el funcionamiento del bit suid. Veámoslo brevemente:

[Read more…]

Habitualmente, todos los profesionales que nos dedicamos en mayor o menor medida a la seguridad nos vemos en la necesidad de gestionar incidentes de seguridad; para ello, nuestra mayor fuente de información suelen ser los registros o logs de los sistemas implicados, tanto a nivel de comunicaciones (routers, cortafuegos, IDS, etc) como a nivel de sistema (Unix, Windows, Linux, etc.) y de aplicación (servidor web, servidor de correo, etc.). Desgraciadamente, es habitual que cuando el potencial cliente ha contactado con nosotros, su personal técnico, siempre con buena intención, haya realizado acciones que invalidan parcial o incluso totalmente los registros y con ello cualquier vía de investigación: formateo de servidores, borrado de logs, limpieza manual de entradas, etc. Como es natural, esto limita sensiblemente la información del incidente que se puede obtener, por lo que es imprescindible que no se lleven a cabo acciones que puedan modificar “la escena del crimen”, casi de la misma manera que puede verse en una película policíaca. No obstante, dejemos eso para una entrada sobre análisis forense y pasemos al análisis de los registros.

A la hora de analizar estos logs nos encontramos principalmente dos problemas. El primero es su fiabilidad ya que ante un sistema comprometido, es inevitable preguntarse: ¿cómo de fiables son nuestros registros?, puesto que probablemente hayan sido alterados o borrados. El segundo problema tiene mucho que ver con la correlación temporal de la información contenida en los registros implicados en el incidente, generando preguntas del tipo: ¿las fechas de los diferentes sistemas se encuentran sincronizadas? ¿Qué sucedió antes y qué después? ¿De qué volumen de logs del incidente dispongo? ¿Hasta cuándo puedo retroceder?

Para el primero de los problemas la opción más habitual es contar con un sistema syslog que reciba los registros de los diferentes sistemas y dispositivos de red distribuidos por la organización, ubicado en un servidor que haya sido convenientemente securizado, limitando el número de servicios que ofrece y controles de acceso, entre otros. Esto permite tener la relativa seguridad de que la información que estamos manejando en la gestión de incidente es veraz. Además, tener los registros duplicados en el sistema de origen y en el servidor syslog permite a posteriori comparar ambos, y detectar así posibles modificaciones que proporcionen información sobre el atacante. Aunque este tipo de configuraciones son relativamente comunes en entornos donde hay mayoría de sistemas Unix/Linux, es raro encontrarlas en entornos Wintel, aunque las ventajas son similares.

En relación con la correlación de registros en el análisis del incidente, es vital que podamos determinar el orden de los acontecimientos, razón por la que el objetivo de control 10.10 Monitorización de la norma ISO 27001 requiere la existencia de un servidor NTP de sincronización que asegure que las fechas de los registros guardan un orden real; de lo contrario, en un entorno que los sistemas y dispositivos de red están no sincronizados en un rango de unos pocos minutos, la reconstrucción puede ser para volverse loco. También para este aspecto un sistema syslog es muy útil, ya que ordena de manera automática los mensajes recibidos de los distintos agentes.

Si no se dispone de un servidor syslog (o éste se limita a recibir la información de los dispositivos de red, dejando fuera los sistemas) y el volumen de información es reducido, la correlación de eventos se puede llevar a cabo de forma manual, aunque lo habitual es usar herramientas de correlacion de logs o alertas que nos permitan obtener información concreta en el menor tiempo posible, aspecto crítico en la gestión de incidentes. Esto no evitará que tengamos que revisar los logs con más detalle posteriormente, ya que aparte de obtener información adicional podría ser necesario presentar una denuncia antes las autorizades competentes, pero sí que facilita y acelera la puesta en marcha de las acciones necesarias para reducir el impacto del incidente en los primeros momentos. Con sistemas automatizados de detección, correlación y alerta, sería posible según los patrones configurados y por lo tanto, potencialmente detectables, anticiparnos al incidente; por ejemplo, pensemos en un ataque externo ocasionado por un nuevo gusano, cuyos patrones de conducta están reportados y de los que existen reglas para detectarlo o filtrarlo en nuestros sistemas (IDS/IPS).

Una visión global de estos aspectos es la que proporciona el proyecto Dshield junto con el Internet Storm Center de Sans Institute. A través de este proyecto, es posible enviar los logs de nuestros sistemas para detectar patrones globales de ataques futuros, formando de este modo un sistema de detección de intrusos distribuido a nivel global, que categoriza las amenazas en 4 niveles: verde, amarillo, naranja y rojo, dependiendo de su impacto potencial. Para evitar proporcionar información sensible al proyecto, como podrían ser las direcciones IP que están siendo atacadas, lo cual podría ocasionar posibles pérdidas para las empresas objetivos del ataque (daño a la imagen corporativa, desconfianza de clientes, etc), dependiendo del tipo de sistema, es posible enmascarar dichas direcciones, de forma que se puede ocultar total o parcialmente la dirección IP. El proyecto dispone de un gran listado de sistemas que soportan el envío de logs al sistema de correlación de forma más o menos automatizada, entre los cuales podemos encontrar dispositivos de grandes fabricantes como Cisco o CheckPoint. Una vez analizados y correlados los logs recibidos, es posible obtener las alertas generadas por el Storm Center, como por ejemplo un listado de direcciones IP potencialmente atacantes, para filtrarlas en nuestros sistemas.

Para finalizar, debemos tener en cuenta que ni el proyecto Dshield, ni el ISC de Sans, ni una correcta gestión de registros garantizan la protección de nuestra red, pero sí que constituyen mecanismos adicionales de reducción de riesgos. Y ya saben que todo suma.

(Entrada elaborada conjuntamente con Manuel Benet)

Hace algunos días mientras un amigo y compañero de trabajo revisaba el estándar ISO27002, se dio cuenta y comentó un detalle que cuanto menos nos pareció a todos curioso. El apartado “i” del control 9.2.1 sobre Emplazamiento y protección de equipos, dice:

Como habréis pensado el comentario vino a raíz de esa última palabra: “emanación”, la cual nos hizo pensar en si realmente la habían utilizado de forma correcta bajo el contexto en el que estábamos hablando. Dándole vueltas alguien recordó que había leído algo sobre la posibilidad de la captación de datos mediante el análisis de señales por emanación electromagnética, un fenómeno que desde luego parece más bien sacado de una serie de ciencia ficción, pero que no está para nada desencaminado de la realidad. Hoy vamos a hablar de los ataques TEMPEST.

[Read more…]

(Aprovechando que estamos en Fallas, hoy les traemos una entrada sobre seguridad en Fallas, con su toque lúdico-festivo)

Hace unos años durante una de las “Mascletàs” que se producen todos los días del mes de fallas a las 14h en la plaza del ayuntamiento de Valencia, unos delincuentes atracaron un banco cercano a la misma plaza, utilizando obviamente el ruido y las vibraciones producidos por la mascletà para camuflar el ruido producido por la alarma del banco (hay una leyenda urbana que dice que las oficinas bancarias de la zona desactivan sus alarmas durante la mascletà) y sus propias armas.

Es poco probable que exista una alarma, sonora o silenciosa, que sea capaz de diferenciar entre una mascletà y un tiroteo; las alarmas de vibración quedan inutilizadas por las explosiones pirotécnicas y dado el gentío que se aglutina en la zona es fácil escabullirse entre la gente y pasar desapercibido.

Aunque las entidades bancarias hayan incluido mecanismos para dificultar los atracos, como cajas con apertura retardada y cajeros blindados, es imposible que se pudiera evitar un robo como ese; estoy convencido que las entidades bancarias simplemente confían en la estadísticas… y en cerrar a las 13h durante la “semana fallera” :-) para evitar los robos.

Otra de las cosas que trae el mes de fallas a Valencia son las calles cortadas pero cortadas de verdad; no es que alguien ponga una valla amarilla a la entrada de la calle, no. Es que además de las vallas amarillas, la calle tiene en el medio un monumento fallero, un escenario para las verbenas, dos churrerías y un casal fallero, así como varias decenas o centenas de vecinos disfrutando, cada uno a su manera, de la falla y de la fiesta.

[Read more…]

Como ya hemos comentado en anteriores entradas, el pasado 18 de febrero S2 Grupo estuvo presente en el 1er Encuentro Internacional CIIP para la Ciberseguridad y Protección de Infraestructuras Críticas, organizado por el CNPIC, Centro Nacional para la Protección de las Infraestructuras Críticas.

Como parte de la agenda participé en el Taller “Gestión de Incidentes y Sistemas de detección preventiva / alerta temprana”, orientado a la implantación de las medidas de detección y alerta de incidentes, que permitan monitorizar toda aquella actividad TIC ilícita que pueda suponer un riesgo para las infraestructuras críticas. Al respecto, he de expresar mi descontento con la manera en que se enfocó el taller, compartido por la mayoría de presentes, ya que consistió principalmente en la presentación de un producto comercial, algo para lo cual existen lugares y oportunidades mejores. Esto provocó que el contenido “útil” del taller fuese muy inferior al de otros talleres.

En cualquier caso, uno de los aspectos más interesantes del taller residió en el análisis de la capacidad de las organizaciones para establecer un sistema o motor de correlación que permita aplicar una lógica avanzada a los flujos de información que tienen como origen los agentes de monitorización desplegados. En algunas ocasiones una entidad puede implantar sistemas de monitorización de intrusos, agentes de control de la disponibilidad de los servicios TIC o incluso herramientas de detección de vulnerabilidades, pero, ¿cómo poder obtener información que aporte un mayor valor de los datos cruzados de las diferentes sondas? Aquí es donde entra en acción el motor de correlación. Imaginemos una situación donde un agente de control de autenticación a nivel del SO detecta un acceso de un usuario A, pero no tenemos constancia de que el sistema de control de accesos físico o de acceso por red privada virtual haya detectado una entrada de A o una conexión remota. En este momento el motor de correlación podría deducir que existe, un robo o cesión de las credenciales de acceso al sistema o que simplemente el usuario A no ha pasado por el control de acceso físico, lo ha burlado.

Situaciones como la anterior otorgan un gran potencial a la correlación de eventos; tan sólo hay que identificar que agentes se tienen desplegados y echarle un poco de imaginación para establecer las reglas de correlación que deseemos. Por último, qué duda cabe que la información procesada por el motor de correlación debe tener como output un sistema de alertas capaz de trazar en todo momento el estado de la incidencia, permitiendo consultar toda aquella información aportada por las sondas de seguridad y que permita al gestor de incidentes aplicar las medias de actuación pertinentes.

(Para empezar la semana de Fallas, una entrada de uno de nuestros colaboradores habituales, Francisco Benet, en la que introduce dos posibles alternativas al control del flujo de la información en una organización)

Uno de los problemas con los que se encuentran hoy en día las organizaciones es el control de la información en todo el ciclo de vida de ésta. Como es natural una organización suele disponer de más de un sistema que alberga información, además de los propios puestos de usuario, los dispositivos móviles y la posibilidad de extraer la información por medios electrónicos; así la información puede ir cambiando de entorno y modificándose, dejando ‘huella’ en varios entornos, resultando al final muy difícil concretar dónde esta residiendo la información realmente y, aspecto mas critico, quien esta siendo capaz de verla. ¿Por qué sucede esto? Básicamente porque los métodos de control de acceso a la información son barreras individuales que residen en cada uno de los sistemas en los que la información está dispersa, y no se trata por tanto de una barrera global que valide si tenemos o no tenemos acceso a ésta.

De hecho lo que realmente está sucediendo en la mayoría de organizaciones es lo siguiente: se dispone de N fuentes de información, las cuales utilizan los usuarios para 2 acciones básicamente: mantener esa información actuando sobre ella (operatoria diaria) y extraer esa información, interpretarla y enriquecerla con información de otras fuentes (información de ‘negocio’). La primera parte del uso de la información estará controlada en más o menos medida, pero es menos importante que la segunda pues requiere de un conocimiento de la acción ejecutada. Sin embargo el segundo tipo de información ha sido elaborada y refinada, y aunque sea menos particular es más precisa sobre el negocio y por lo tanto mas ‘preciada’. Esa segunda información sufre un ciclo de vida mas extenso pero a su vez se le “mima” más y se pretende que menos personal tenga acceso. El problema reside en que ese acceso esta gobernado por varios sistemas de control de acceso NO sincronizados (léase directorios departamentales, equipos de los usuarios, correo electrónico, etc.), sino dependientes del sistema de información, por lo que en muchas de las ocasiones nos podemos encontrar personal autorizado a información privilegiada sin razón alguna.

[Read more…]