Según se han ido sucediendo las noticias relativas al atentado de la Maratón de Boston y las averiguaciones posteriores no he podido evitar la tentación de establecer una analogía entre los hechos de Boston (o el terrorismo en general) y las APTs informáticas. Y la pregunta que surge a continuación es clave: ¿Es válido ese paralelismo? Y si fuera así... Podrían realimentarse ambos mundos?
Analicemos el paralelismo. Para empezar, el punto de partida de una APT es un "troyano" que conseguimos introducir en el sistema de la víctima. En el mundo físico, el sistema objetivo sería el entorno a atacar, en este caso Boston (o EEUU, cada uno que lo interprete como quiera). Las personas serían las aplicaciones que corren en ese sistema, y por lo tanto tendríamos dos formas de "infectar" el sistema: introduciendo directamente un software malicioso tipo "virus" (terrorista proveniente del exterior) o "troyanizando" una aplicación del sistema ("convirtiendo a la causa" a un ciudadano local, al más puro estilo homeland).
Al igual que en el mundo informático, los países están preparados para proteger el perímetro de la red (frontera) y controlar las entradas (firewalls), pero la capacidad de detección de terroristas externos que tienen estos sistemas es muy limitada, ya que generalmente se limita a firmas (identidades específicas que se chequean) y heurística básica (análisis de los datos del propio viaje -origen, destino, motivos del mismo, y cosas así). El resultado es que los "virus" sencillos se pueden llegar a detectar, pero las APTs más sofisticadas (personas "troyanizadas" o incluso malware durmiente con puertas traseras) suelen colarse. Además, al igual que en los sistemas de información, no sólo podemos infectarnos por la red. Los pendrives (inmigración ilegal o no controlada, cuerpos diplomáticos, etc.) también pueden llevar alguna aplicación maliciosa en su interior, consciente o inconscientemente.
En el mundo TIC se suelen poner sistemas IDS en la red interna, para tratar de detectar ataques que hayan podido superar la protección perimetral. Sin embargo, en el mundo físico no hay (oficialmente) demasiados recursos destinados al "espionaje" interno, más allá de la labor policial habitual. En cualquier caso, normalmente un IDS tampoco suele ser capaz de detectar la actividad de una APT...
Las APTs son difíciles de detectar porque su actividad es esporádica. Suelen ser aplicaciones "durmientes", que realizan una actividad aparentemente normal (o ninguna) hasta que, por un motivo determinado, activan su payload malicioso y lo ejecutan, realizando la fechoría en cuestión. Este funcionamiento es muy similar al de cualquier célula terrorista, y la dificultad de su detección estriba en identificar el detonante para su activación, que potencialmente puede ser cualquier cosa. Las autónomas pueden activarse con una cuenta atrás, un hito específico, una fecha, etc., mientras que otras dependen de la recepción de una orden externa desde un nodo de comando y control (C&C). Estas son algo más detectables, pero también mucho más flexibles, ya que pueden ser reprogramadas. En cualquier caso, esas comunicaciones llevadas al mundo físico son prácticamente imposibles de detectar, dada la infinidad de medios existentes y la poca capacidad de supervisión de los mismos.
Y por último, las APTs actúan. Roban la información, hacen estallar la bomba... Este suele ser el momento en el que son detectadas, cuando el incidente se materializa. El problema es que en este momento ya no sirve de nada, su acción no ha podido ser evitada. En ese momento es cuando empieza la "desinfección"... si es que han sido detectadas. Si no es así, podrán continuar con su actividad.
Hasta aquí la exposición. Ahora vuelvo a lanzar la pregunta, para la que no tengo respuesta. ¿Puede servir el conocimiento adquirido en cualquiera de ambos mundos para mejorar la lucha contra amenazas físicas y cibernéticas? Hay algún tipo de iniciativa de colaboración en este sentido? Seguro que un buen guionista sabe cómo hacerlo...
Mostrando entradas con la etiqueta Seguridad técnica. Mostrar todas las entradas
Mostrando entradas con la etiqueta Seguridad técnica. Mostrar todas las entradas
02 mayo 2013
22 enero 2013
La caza del Octubre Rojo
No voy a hablar de la película cuyo título se corresponde con el de este post, por mucho que Sean Connery sea uno de mis actores preferidos, pero he de reconocer que el "virus" descubierto públicamente estos últimos días, bautizado como "Octubre Rojo", me ha recordado a la película por más motivos que por la simple coincidencia en el nombre: el papel de las instituciones gubernamentales, la capacidad del "virus" para permanecer sumergido en los sistemas... Un material que bien podría servir como argumento para una típica peli de espías hollywoodense.
Sin embargo, mi intención no es analizar las características de la película ni sus coincidencias con este malware en particular, sino hacer una pequeña reflexión acerca de este tipo de malware avanzado, forma tangible de las cada vez más conocidas APTs (Advanced Persistent Threats, o amenazas persistentes avanzadas).
En el fondo, todas las APTs funcionan de la misma forma. Un pequeño malware llega al destinatario, consigue ser ejecutado (por utilización de alguna vulnerabilidad del equipo o simplemente engañando al usuario) y se instala en el equipo de la víctima. A partir de ese momento, ese pequeño malware se dedica a conectarse periódicamente a una serie de servidores en Internet, los centros de control (conocidos como C&C, o Command and Control), desde los que se reciben las órdenes de las actividades maliciosas a llevar a cabo y/o a los que se envía la información recopilada.
En primer lugar me gustaría hacer una observación acerca del papel de los antivirus frente a este tipo de ataques. Obviamente, el software anti-malware es de propósito general, y su objetivo no es identificar ataques dirigidos y personalizados, como suelen ser (en distinto grado) las APTs. No obstante, el comportamiento básico de este tipo de malware es bastante similar en todos los casos, y se basa en actuar como puerta trasera. ¿No sería posible hacer un esfuerzo especial en identificar este tipo de patrón de funcionamiento? Siendo consciente de la dificultad que puede suponer, creo que este es uno de los ámbitos en los que más se puede incidir en un futuro cercano.
Creo que también es destacable una de las características del "Octubre Rojo": el nivel de personalización (más allá de los destinatarios) del vector de infección (unos archivos en excel y word) era bastante bajo. O dicho de otro modo: esos mismos archivos podrían haber ido dirigidos a cualquiera. ¿Es la sociedad consciente de la existencia de esos ataques?
Redundando en la pregunta anterior, creo que también es destacable que el objetivo potencial del "Octubre Rojo" era prácticamente todo tipo de información que tuviera el usuario. ¿Somos conscientes de que TODA la información que tenemos en nuestro equipo es objetivo potencial de un atacante?
Por último, creo que también es destacable la modularidad del "Octubre Rojo", y su capacidad para cargar, ejecutar y eliminar de forma dinámica diferentes módulos con finalidades diversas, una vez realizas las acciones correspondientes. Me temo que ese planteamiento va a estar cada vez más extendido entre el malware moderno, de modo que cada vez será más complicado su identificación. Está preparado el mercado antimalware para hacer frente a software malicioso de estas características?
En definitiva, creo que la caza del Octubre Rojo puede ser una de las primeras batallas que tenga que lidiar la industria del antimalware a los ojos de la luz pública, y posiblemente sus resultados nos sirvan para hacernos una idea de la capacidad real de la sociedad para hacer frente a este tipo de amenazas. ¿Conseguirán cercar y dar caza al Octubre Rojo? ¿O conseguirán sus tripulantes alcanzar sus objetivos (si no lo han hecho ya)?
Sin embargo, mi intención no es analizar las características de la película ni sus coincidencias con este malware en particular, sino hacer una pequeña reflexión acerca de este tipo de malware avanzado, forma tangible de las cada vez más conocidas APTs (Advanced Persistent Threats, o amenazas persistentes avanzadas).
En el fondo, todas las APTs funcionan de la misma forma. Un pequeño malware llega al destinatario, consigue ser ejecutado (por utilización de alguna vulnerabilidad del equipo o simplemente engañando al usuario) y se instala en el equipo de la víctima. A partir de ese momento, ese pequeño malware se dedica a conectarse periódicamente a una serie de servidores en Internet, los centros de control (conocidos como C&C, o Command and Control), desde los que se reciben las órdenes de las actividades maliciosas a llevar a cabo y/o a los que se envía la información recopilada.
En primer lugar me gustaría hacer una observación acerca del papel de los antivirus frente a este tipo de ataques. Obviamente, el software anti-malware es de propósito general, y su objetivo no es identificar ataques dirigidos y personalizados, como suelen ser (en distinto grado) las APTs. No obstante, el comportamiento básico de este tipo de malware es bastante similar en todos los casos, y se basa en actuar como puerta trasera. ¿No sería posible hacer un esfuerzo especial en identificar este tipo de patrón de funcionamiento? Siendo consciente de la dificultad que puede suponer, creo que este es uno de los ámbitos en los que más se puede incidir en un futuro cercano.
Creo que también es destacable una de las características del "Octubre Rojo": el nivel de personalización (más allá de los destinatarios) del vector de infección (unos archivos en excel y word) era bastante bajo. O dicho de otro modo: esos mismos archivos podrían haber ido dirigidos a cualquiera. ¿Es la sociedad consciente de la existencia de esos ataques?
Redundando en la pregunta anterior, creo que también es destacable que el objetivo potencial del "Octubre Rojo" era prácticamente todo tipo de información que tuviera el usuario. ¿Somos conscientes de que TODA la información que tenemos en nuestro equipo es objetivo potencial de un atacante?
Por último, creo que también es destacable la modularidad del "Octubre Rojo", y su capacidad para cargar, ejecutar y eliminar de forma dinámica diferentes módulos con finalidades diversas, una vez realizas las acciones correspondientes. Me temo que ese planteamiento va a estar cada vez más extendido entre el malware moderno, de modo que cada vez será más complicado su identificación. Está preparado el mercado antimalware para hacer frente a software malicioso de estas características?
En definitiva, creo que la caza del Octubre Rojo puede ser una de las primeras batallas que tenga que lidiar la industria del antimalware a los ojos de la luz pública, y posiblemente sus resultados nos sirvan para hacernos una idea de la capacidad real de la sociedad para hacer frente a este tipo de amenazas. ¿Conseguirán cercar y dar caza al Octubre Rojo? ¿O conseguirán sus tripulantes alcanzar sus objetivos (si no lo han hecho ya)?
08 septiembre 2011
Certificados y confianza
La noticia de que una nueva entidad de certificación, DigiNotar, ha sido comprometida ha acrecentado las dudas acerca del sistema PKI y, por ende, acerca de los elementos sobre los que se fundamenta la seguridad hoy en día. ¿Podemos seguir confiando en el SSL, en el "candadito" del navegador? Ayer mismo Hispasec publicaba, en su una-al-dia, una breve pero clara relación de los incidentes de seguridad más importantes sufridos por el sistema PKI en los últimos tiempos, con un mensaje preocupante al final: esto sólo acaba de empezar. ¿La situación es realmente tan preocupante como parece?
En cualquier caso, creo que no estaría de más hacer un pequeño análisis de los últimos incidentes. Del correspondiente a GlobalSign todavía no se sabe mucho, ya que está bajo investigación. También lo está el de DigiCert, pero en este caso tenemos un análisis bastante interesante sobre la intrusión, muy instructivo y recomendable. Del primero de ellos no hay un análisis tan detallado, pero se puede resumir en que el atacante entró en la RA (autoridad de registro) a través de internet, y en ella estaban almacenadas las claves necesarias para emitir los certificados contra la CA (autoridad de certificación).
Viendo los hechos, a mi me parece claro un aspecto: el nivel de automatización y ejecución on-line de todo el proceso es excesivamente alto. Por un lado, porque no se requiere autenticación fuerte basada en token físico (tarjeta criptográfica) para la emisión de un certificado. Por otro, porque tampoco da la sensación de que se requiera la intervención humana expresa para proceder a dicha emisión. Y por último, porque un equipo que sólo actúa una vez al año (como mucho) como es una CA raíz jamás debería estar no ya conectado a la red, sino siquiera encendido.
Dicho esto, no creo que el sistema PKI esté en peligro... pero sí que me parece necesaria una migración rápida a soluciones SSL-EV. Para los profanos, los certificados SSL-EV son los que "colorean de verde" la barra del navegador. El EV significa "validación extendida", o dicho de otra forma, verificación rigurosa de la identidad del solicitante antes de emitir el certificado. Por tanto, no es un cambio tecnológico, sino procedimental: las RAs tienen la obligación de emitir "manualmente" los certificados, ya que se deben verificar un montón de datos para autenticar fehacientemente al solicitante del certificado antes de emitirlo.
Obviamente, siempre será imprescindible cumplir las especificaciones de seguridad que contienen las normas que regulan el mundo de las PKIs... y más si se está certificado en ellas por una tercera parte confiable. Esa tercera parte, que acredita el correcto cumplimiento, es quien garantiza la viabilidad de todo el sistema, y desde mi punto de vista debería ser a quien se exijan responsabilidades si se demuestran incumplimientos importantes no identificados. Es cierto que esto supone una gran responsabilidad para los auditores, pero... ¿Acaso no es ésa su función?
En cualquier caso, creo que no estaría de más hacer un pequeño análisis de los últimos incidentes. Del correspondiente a GlobalSign todavía no se sabe mucho, ya que está bajo investigación. También lo está el de DigiCert, pero en este caso tenemos un análisis bastante interesante sobre la intrusión, muy instructivo y recomendable. Del primero de ellos no hay un análisis tan detallado, pero se puede resumir en que el atacante entró en la RA (autoridad de registro) a través de internet, y en ella estaban almacenadas las claves necesarias para emitir los certificados contra la CA (autoridad de certificación).
Viendo los hechos, a mi me parece claro un aspecto: el nivel de automatización y ejecución on-line de todo el proceso es excesivamente alto. Por un lado, porque no se requiere autenticación fuerte basada en token físico (tarjeta criptográfica) para la emisión de un certificado. Por otro, porque tampoco da la sensación de que se requiera la intervención humana expresa para proceder a dicha emisión. Y por último, porque un equipo que sólo actúa una vez al año (como mucho) como es una CA raíz jamás debería estar no ya conectado a la red, sino siquiera encendido.
Dicho esto, no creo que el sistema PKI esté en peligro... pero sí que me parece necesaria una migración rápida a soluciones SSL-EV. Para los profanos, los certificados SSL-EV son los que "colorean de verde" la barra del navegador. El EV significa "validación extendida", o dicho de otra forma, verificación rigurosa de la identidad del solicitante antes de emitir el certificado. Por tanto, no es un cambio tecnológico, sino procedimental: las RAs tienen la obligación de emitir "manualmente" los certificados, ya que se deben verificar un montón de datos para autenticar fehacientemente al solicitante del certificado antes de emitirlo.
Obviamente, siempre será imprescindible cumplir las especificaciones de seguridad que contienen las normas que regulan el mundo de las PKIs... y más si se está certificado en ellas por una tercera parte confiable. Esa tercera parte, que acredita el correcto cumplimiento, es quien garantiza la viabilidad de todo el sistema, y desde mi punto de vista debería ser a quien se exijan responsabilidades si se demuestran incumplimientos importantes no identificados. Es cierto que esto supone una gran responsabilidad para los auditores, pero... ¿Acaso no es ésa su función?
11 enero 2011
Hacking legal
Hoy sencillamente quiero referenciar un artículo de Jorge Bermúdez, un fiscal especialista en delitos informáticos, en el que nos explica un "hack legal" (no recuerdo dónde ví este término, pero la verdad es que me gustó) que permite la realización de hacking ético de manera legal dentro del nuevo código penal, en vigor desde finales del año pasado y que considera el hacking como un comportamiento delicitivo (simplificando).
Por tratar de explicarlo, el artículo 197, apartado 3º viene a decir que cualquiera que vulnere las medidas de seguridad de un sistema informático y acceda a sus datos o programas sin el permiso de sus dueños puede acabar en la cárcel. La clave parece estar en el concepto de sistema informático, válida tanto para servidores u ordenadores personales como para software, aplicaciones o incluso servicios tipo SaaS, y en el permiso de los dueños, que muchas veces no queda claro quiénes son. Normalmente los pen-test se suelen llevar a cabo con el permiso (y normalmente petición expresa) de los dueños, pero la labor de investigación y búsqueda de vulnerabilidades en general suele ser más proactiva, normalmente llevada a cabo por los usuarios "afectados" sin informar de ella al responsable de la aplicación o servicio salvo en caso de que el resultado sea fructífero. Y es aquí donde pueden surgir los problemas.
En el artículo se plantea como solución al problema la invocación de una norma legal presente en el Código Civil denominada "cuasicontrato de gestión de negocios ajenos" (vaya nombrecito, eh?), que podría amparar este tipo de actividades. ¿Que en qué consiste? Os animo a leer la explicación en el artículo original, que yo no soy jurista y prefiero no equivocarme al tratar de explicarlo...
Por tratar de explicarlo, el artículo 197, apartado 3º viene a decir que cualquiera que vulnere las medidas de seguridad de un sistema informático y acceda a sus datos o programas sin el permiso de sus dueños puede acabar en la cárcel. La clave parece estar en el concepto de sistema informático, válida tanto para servidores u ordenadores personales como para software, aplicaciones o incluso servicios tipo SaaS, y en el permiso de los dueños, que muchas veces no queda claro quiénes son. Normalmente los pen-test se suelen llevar a cabo con el permiso (y normalmente petición expresa) de los dueños, pero la labor de investigación y búsqueda de vulnerabilidades en general suele ser más proactiva, normalmente llevada a cabo por los usuarios "afectados" sin informar de ella al responsable de la aplicación o servicio salvo en caso de que el resultado sea fructífero. Y es aquí donde pueden surgir los problemas.
En el artículo se plantea como solución al problema la invocación de una norma legal presente en el Código Civil denominada "cuasicontrato de gestión de negocios ajenos" (vaya nombrecito, eh?), que podría amparar este tipo de actividades. ¿Que en qué consiste? Os animo a leer la explicación en el artículo original, que yo no soy jurista y prefiero no equivocarme al tratar de explicarlo...
31 agosto 2010
El riesgo de los PenDrives
Ya hace más de 2 años que se publicaba un estudio alertando sobre la peligrosidad de los PenDrives (memorias USB, memory sticks, unidades flash USB o como se quieran llamar). En él, se ponían de manifiesto la gran cantidad de datos "sensibles" que se almacenaban en pendrives, así como la gran predisposición de las personas a "curiosear" el contenido de cualquier pen-drive que se encontrasen. En definitiva, ya en 2008 eran uno de los principales focos de riesgo en las organizaciones.
A día de hoy creo que la situación ha cambiado más bien poco. Las memorias USB son uno de los principales focos de infección de los PCs, y aunque no he sido capaz de encontrar estudios actuales al respecto, estoy prácticamente seguro de que el uso de memory sticks cada día es más habitual, y no creo que la sensibilidad de los datos almacenados en ellos haya disminuido (de hecho, lo más probable es que haya aumentado). Tanto la capacidad de almacenamiento como la fiabilidad de estos dispositivos ha crecido, a la vez que su precio ha disminuido enormemente, de forma que cada vez es más habitual encontrarse con este tipo de dispositivos. Y la verdad es que no es de extrañar, ya que su utilidad es enorme, dado que son ultraportables y accesibles de forma prácticamente universal.
Desde el punto de vista de la seguridad tampoco tiene que ser mala esta proliferación. Estamos maximizando la disponibilidad de la información almacenada en ellos, lo cual es positivo. El mayor problema es que su uso puede provocar una disminución de la confidencialidad (que suele ir asociado habitualmente al aumento de disponibilidad, pero que en este caso supone una disminución adicional por el importante potencial de pérdida que tienen estos dispositivos) y también una diminución de la integridad (como siempre que se generan copias de una información y no la "sincronizamos" apropiadamente). Algo habitual en esto de la seguridad (sería genial que se inventaran soluciones capaces de maximizar los 3 factores simultáneamente, verdad?), pero que en general no se suele gestionar de manera eficiente.
Es cierto que en el mercado existen productos que tratan de solucionar el tema de la confidencialidad mediante la introducción de cifrado nativo, con control de acceso autenticado bien mediante password o bien mediante autenticación biométrica. Pero también es cierto que el uso de este tipo de soluciones es bastante residual, y normalmente limitada a entornos corporativos. ¿Está justificado el elevado precio de este tipo de soluciones, normalmente muy superior al de los dispositivos sin ellas? Si los precios de ambos productos fueses equivalentes seguramente se conseguiría mejorar enormemente la seguridad de la información en toda la sociedad... ¿Merecería la pena subvencionarlos?
A diferencia que para el caso de la confidencialidad, el mercado no ha buscado soluciones específicas para solucionar los problemas de integridad asociados al uso de los PenDrives. Es cierto que existen multitud de herramientas que pueden resolver estos problemas, pero curiosamente no suelen ser funcionalidades que se integren de manera nativa en los productos de gestión de memorias USB. Parece como si, por una vez, la integridad de la información fuese un problema secundario, cuando "de siempre" ha sido el parámetro más cuidado (y quizás por ello también el que menos nos preocupa, ya que suele ser el más transparente).
En definitiva, desde 2008 se han incrementado bastante las soluciones disponibles para los problemas ocasionados por las memorias flash USB, pero ni su evolución ha sido todo lo buena que se podría haber esperado ni sobre todo su adopción se ha extendido tanto como hubiera sido deseable. En la actualidad nos encontramos con un panorama en el que los riesgos derivados del uso de las memorias USB, cuya expansión continúa siendo imparable, aumenta lenta pero progresivamente. ¿Responderá finalmente la industria de la seguridad con soluciones apropiadas para los riesgos a los que nos enfrentamos? ¿Será capaz la sociedad de madurar en la adopción de soluciones de seguridad apropiadas? Me temo que a los profesionales del sector todavía nos queda mucho trabajo por hacer...
A día de hoy creo que la situación ha cambiado más bien poco. Las memorias USB son uno de los principales focos de infección de los PCs, y aunque no he sido capaz de encontrar estudios actuales al respecto, estoy prácticamente seguro de que el uso de memory sticks cada día es más habitual, y no creo que la sensibilidad de los datos almacenados en ellos haya disminuido (de hecho, lo más probable es que haya aumentado). Tanto la capacidad de almacenamiento como la fiabilidad de estos dispositivos ha crecido, a la vez que su precio ha disminuido enormemente, de forma que cada vez es más habitual encontrarse con este tipo de dispositivos. Y la verdad es que no es de extrañar, ya que su utilidad es enorme, dado que son ultraportables y accesibles de forma prácticamente universal.
Desde el punto de vista de la seguridad tampoco tiene que ser mala esta proliferación. Estamos maximizando la disponibilidad de la información almacenada en ellos, lo cual es positivo. El mayor problema es que su uso puede provocar una disminución de la confidencialidad (que suele ir asociado habitualmente al aumento de disponibilidad, pero que en este caso supone una disminución adicional por el importante potencial de pérdida que tienen estos dispositivos) y también una diminución de la integridad (como siempre que se generan copias de una información y no la "sincronizamos" apropiadamente). Algo habitual en esto de la seguridad (sería genial que se inventaran soluciones capaces de maximizar los 3 factores simultáneamente, verdad?), pero que en general no se suele gestionar de manera eficiente.
Es cierto que en el mercado existen productos que tratan de solucionar el tema de la confidencialidad mediante la introducción de cifrado nativo, con control de acceso autenticado bien mediante password o bien mediante autenticación biométrica. Pero también es cierto que el uso de este tipo de soluciones es bastante residual, y normalmente limitada a entornos corporativos. ¿Está justificado el elevado precio de este tipo de soluciones, normalmente muy superior al de los dispositivos sin ellas? Si los precios de ambos productos fueses equivalentes seguramente se conseguiría mejorar enormemente la seguridad de la información en toda la sociedad... ¿Merecería la pena subvencionarlos?
A diferencia que para el caso de la confidencialidad, el mercado no ha buscado soluciones específicas para solucionar los problemas de integridad asociados al uso de los PenDrives. Es cierto que existen multitud de herramientas que pueden resolver estos problemas, pero curiosamente no suelen ser funcionalidades que se integren de manera nativa en los productos de gestión de memorias USB. Parece como si, por una vez, la integridad de la información fuese un problema secundario, cuando "de siempre" ha sido el parámetro más cuidado (y quizás por ello también el que menos nos preocupa, ya que suele ser el más transparente).
En definitiva, desde 2008 se han incrementado bastante las soluciones disponibles para los problemas ocasionados por las memorias flash USB, pero ni su evolución ha sido todo lo buena que se podría haber esperado ni sobre todo su adopción se ha extendido tanto como hubiera sido deseable. En la actualidad nos encontramos con un panorama en el que los riesgos derivados del uso de las memorias USB, cuya expansión continúa siendo imparable, aumenta lenta pero progresivamente. ¿Responderá finalmente la industria de la seguridad con soluciones apropiadas para los riesgos a los que nos enfrentamos? ¿Será capaz la sociedad de madurar en la adopción de soluciones de seguridad apropiadas? Me temo que a los profesionales del sector todavía nos queda mucho trabajo por hacer...
20 abril 2010
Nos gusta el riesgo
Según parece, la mayor parte de los problemas de pérdida de datos en las empresas se debe a conductas de riesgo de los usuarios. O al menos éso es lo que reflejan algunos estudios, según indica el artículo referenciado. Como no he podido acceder a los datos de partida del informe (parece que la empresa que lo ha realizado sólo ha publicado algunas notas de prensa, pero no los resultados estadísticos de dicho estudio), el único dato que tenemos es el del titular: un 78% de las pérdidas de datos en las empresas se deben a:
- Errores humanos
- Pérdida de hardware
- Robo de hardware
- USB personal infectado
- Desactivación del antivirus
De ellos, los dos primeros no creo que se deban estrictamente a conductas de riesgo (un "despiste" lo puede tener hasta el más paranoico), y el tercero tampoco tiene por qué estar relacionado con ellas (podría ser que con tu conducta vayas "provocando" a los ladrones, pero lo más habitual es que el robo se deba más a "despistes" y casualidades). Por tanto, me gustaría quedarme con las dos últimas, que sí que creo que son en sí mismas conductas de riesgo en las empresas.
En relación al uso de pendrives personales, creo que hay dos aspectos que habría que analizar: su uso para fines personales y su uso para fines profesionales. Sobre todo porque en este segundo caso (el primero queda regulado por cada organización una vez que se estipulen los usos y comportamientos permitidos en la organización, ya que puede ser una conducta de riesgo o una conducta incluso no permitida) habría que tener en cuenta si la propia empresa proporciona a sus empleados los medios necesarios (en este caso, pendrives) para que puedan realizar su trabajo. A partir de ahí, una buena solución sería la integración de un sistema de control de periféricos, de esos que permiten definir políticas de uso de medios removibles, para poder controlar qué pendrives se conectan a los equipos.
En cuanto a la desactivación del antivirus, la primera duda sería conocer por qué los usuarios tienen capacidad de desactivarlo (puede que no requieran ese tipo de permisos), y a partir de ahí preguntarnos el motivo por el cuál lo han hecho. Es cierto que algunos usuarios esgrimen la ralentización del equipo como argumento para desactivarlo (aunque muchas veces sea el propio malware que les infecta por tenerlo desactivado el que les ralentiza el equipo), pero también puede que una mala integración de estas soluciones o un incorrecto dimensionamiento de los equipos para soportarla puedan causar problemas reales con la plataforma antivirus.
Con esto quiero señalar que a veces puede ser la propia organización la que puede establecer acciones para corregir ciertas conductas de riesgo, ya que a veces el propio celo de los usuarios por realizar adecuadamente su trabajo puede conducirles a caer en dichas conductas. Más allá de las clásicas acciones de concienciación, adoptar ciertas precauciones con las herramientas y normativas de uso asociadas que homologamos en la organización puede ser un aspecto tanto o más importante que la propia concienciación a la hora de limitar las conductas de riesgo. Sobre todo si nos enfrentamos a soluciones que, por simplificarle la vida al usuario, le limitan la posibilidad de saber si está utilizando un protocolo de navegación seguro...
05 febrero 2009
Discos duros cifrados
Hoy he leído una noticia que curiosamente tengo la sensación de que ha pasado bastante desapercibida incluso en este mundillo, y la verdad es que me ha parecido bastante interesante. Parece que los principales fabricantes de discos duros han cerrado las especificaciones de un estándar de cifrado de discos duros y otro tipo de unidades de almacenamiento. Y según indica el citado artículo dicho cifrado vendrá incorporado "de serie" en los dispositivos, vía firmware, y permitirá el cifrado completo de los discos.
A falta de conocer más detalles acerca de las características del estándar, quiero pensar que las técnicas de cifrado seleccionadas serán robustas y contrastadas. En realidad no tendría mucho sentido, desde el punto de vista empresarial, exponerse a implementar una solución de cifrado no contrastada que sea vulnerable y correr el resgo de aparecer en los medios. Así que, pese a no haber investigado la noticia, voy a presuponer que la solución definida es robusta.
A partir de ese planteamiento, la verdad es que me parece un avance muy importante. Estandarizar una solución de cifrado de discos garantiza, tal y como dice el artículo, una reducción de los costes asociados a su implementación, y por tanto facilita una adopción más amplia de este tipo de soluciones. Y disponer de una referencia estandarizada también anima a los fabricantes de equipos a utilizar discos que implementen esta funcionalidad, ya que no corren el riesgo de seleccionar soluciones no contrastadas que luego puedan ocasionar apariciones en prensa no deseadas. Por tanto, creo que es una noticia muy importante para contribuir a la mejora de la seguridad en equipos portátiles.
Y por último, no olvidar que, en última instancia, la solución de cifrado dependerá de una clave de usuario, y por tanto este tipo de soluciones serán completamente ineficaces si no conseguimos que los usuarios de este tipo de dispositivos se conciencien de que deben utilizar claves robustas...
A falta de conocer más detalles acerca de las características del estándar, quiero pensar que las técnicas de cifrado seleccionadas serán robustas y contrastadas. En realidad no tendría mucho sentido, desde el punto de vista empresarial, exponerse a implementar una solución de cifrado no contrastada que sea vulnerable y correr el resgo de aparecer en los medios. Así que, pese a no haber investigado la noticia, voy a presuponer que la solución definida es robusta.
A partir de ese planteamiento, la verdad es que me parece un avance muy importante. Estandarizar una solución de cifrado de discos garantiza, tal y como dice el artículo, una reducción de los costes asociados a su implementación, y por tanto facilita una adopción más amplia de este tipo de soluciones. Y disponer de una referencia estandarizada también anima a los fabricantes de equipos a utilizar discos que implementen esta funcionalidad, ya que no corren el riesgo de seleccionar soluciones no contrastadas que luego puedan ocasionar apariciones en prensa no deseadas. Por tanto, creo que es una noticia muy importante para contribuir a la mejora de la seguridad en equipos portátiles.
Y por último, no olvidar que, en última instancia, la solución de cifrado dependerá de una clave de usuario, y por tanto este tipo de soluciones serán completamente ineficaces si no conseguimos que los usuarios de este tipo de dispositivos se conciencien de que deben utilizar claves robustas...
02 febrero 2009
Seguridad en el desarrollo
La seguridad en el desarrollo de aplicaciones es uno de los mayores caballos de batalla dentro de este mundillo. Sobre todo teniendo en cuenta la creciente complejidad de dichos desarrollos y los decrecientes márgenes de actuación que suelen tener los desarrolladores, sobre todo en plazos.
Hace un par de semanas se publicó una noticia en la que un estudio alertaba sobre los peores 25 errores de programación, orientada a identificar las prácticas de programación con mayores riesgos desde el punto de vista de la seguridad. En el artículo me llama la atención que primero se afirme que "la mayor parte de los errores podrían ser evitados si los programadores fueran más cautelosos con su trabajo", y más adelante se diga que "la mayoría de los errores de la lista son relativamente desconocidos entre los propios programadores y no forman parte de los estudios de los desarrolladores". Es decir, que apuntan a la falta de cautela y a la insuficiente profundidad de conocimientos al respecto como dos de las principales causas de estos graves errores.
No quiero entrar a valorar estas posibles causas, y si realmente las presiones empresariales tienen más o menos peso que las que indica el artículo. No obstante, sí que quiero prestar algo de atención a la posibilidad de que los conocimientos de los programadores respecto de estos errores puedan ser insuficientes. En este otro artículo se enumeran cuáles son en concreto estos 25 errores, agrupados en 3 categorías:
Hace un par de semanas se publicó una noticia en la que un estudio alertaba sobre los peores 25 errores de programación, orientada a identificar las prácticas de programación con mayores riesgos desde el punto de vista de la seguridad. En el artículo me llama la atención que primero se afirme que "la mayor parte de los errores podrían ser evitados si los programadores fueran más cautelosos con su trabajo", y más adelante se diga que "la mayoría de los errores de la lista son relativamente desconocidos entre los propios programadores y no forman parte de los estudios de los desarrolladores". Es decir, que apuntan a la falta de cautela y a la insuficiente profundidad de conocimientos al respecto como dos de las principales causas de estos graves errores.
No quiero entrar a valorar estas posibles causas, y si realmente las presiones empresariales tienen más o menos peso que las que indica el artículo. No obstante, sí que quiero prestar algo de atención a la posibilidad de que los conocimientos de los programadores respecto de estos errores puedan ser insuficientes. En este otro artículo se enumeran cuáles son en concreto estos 25 errores, agrupados en 3 categorías:
- Interacción insegura entre componentes
- Administración inadecuada de los recursos del sistema
- Técnicas de "defensa" mal utilizadas o ignoradas
¿Creéis que realmente puede haber un insuficiente conocimiento al respecto acerca de estos errores? ¿Conocéis algún programa de estudios que contemple de forma explícita estos tres ámbitos?
No obstante, creo que el mayor problema de la inseguridad en los desarrollos es, más allá de la problemática técnica, la ausencia de responsabilidades en torno al software. Prácticamente nadie se hace responsable de los fallos que pueda tener el software que desarrolla ni de las consecuencias que puedan tener dichos fallos. Sí, es cierto que en el mercado de software actual esto parece impensable, pero... ¿No es precisamente esta falta de asunción de responsabilidades la que nos ha llevado a que a un PC no se le puedan exigir las mismas garantías que a un coche? Y no obstante hay PCs que controlan sistemas mucho más sensibles para la vida humana que un coche...
En definitiva, creo que la solución a la inseguridad en el desarrollo tiene una muy difícil solución, y no por los problemas que provoca el propio mercado, la atención o la formación, sino porque en dicho mercado prácticamente no hay nadie dispuesto a asumir formalmente los riesgos derivados de vender un software que pueda tener errores de seguridad. Que se conozcan cuáles son los mayores errores no garantiza que se vayan a querer subsanar, si el esfuerzo no merece la pena en términos económicos...
07 enero 2009
Publicada la norma BS 25777:2008 sobre continuidad TIC
El pasado Diciembre se publicaba la norma BS 25777:2008, un código de buenas prácticas sobre gestión de la continuidad TIC. Una norma que, emparentada con la ya conocida BS 25999 sobre continuidad de negocio, define un código de buenas prácticas sobre continuidad centrado en las infraestructuras TIC de las organizaciones, a sabiendas de que en la actualidad una gran parte de la continuidad del negocio de muchas organizaciones se basa en la continuidad de sus infraestructuras TIC.
La aparición de una norma de estas características me parece muy importante por dos motivos. El primero de ellos es que va a servir para separar formalmente la continuidad TIC de la continuidad de negocio, de modo que a nadie le den gato por liebre cuando hablemos de esta última. La continuidad del negocio es algo más que la continuidad de los servicios TIC, aunque tengan mucha interrelación. Por eso yo a veces prefiero el término "continuidad de la actividad comercial" que he visto utilizado en algunos sitios, porque aunque pueda ser un término menos exacto sí que da la sensación de que la informática no es lo fundamental. Que se caiga nuestro sistema CRM no equivale a que nuestros comerciales dejen de vender, y lo importante para el negocio es esto último. La continuidad de negocio debe estar orientada hacia los procesos de negocio, valga la redundancia, hacia los servicios prestados a cliente final y las actividades productivas, y el hecho de que dichas actividades utilicen en mayor o menor medida infraestructuras TIC sólo debería determinar la forma de abordar el problema. ¿De qué serviría tener garantizada la continuidad de nuestros sistemas informáticos si no tenemos garantizada la continuidad del know-how asociado a su uso y explotación? En el fondo, la gestión de la continuidad del negocio tiene mucho más que ver con la gestión del conocimiento que con la gestión TIC, y sin embargo es muy habitual que, al hablar de ella, la cantidad de veces que se mencione esta última sea abrumadoramente superior al número de veces que se habla de la primera...
El segundo motivo por el que me alegro de la aparición de esta norma es porque plantea un marco mucho más definido de actuación en materia de continuidad TIC. Obviamente, al querer entender la BS 25999 como una referencia para la continuidad de los sistemas nos encontrábamos con muchas vaguedades y conceptos excesivamente amplios que luego era necesario acotar y "traducir" artificialmente. En cambio, creo que con esta nueva norma, centrada en el ámbito tecnológico, estaremos en condiciones de disponer de una referencia mucho más útil a la hora de hablar de continuidad en entornos TI.
Por último, creo que otro de los aspectos a los que habrá que prestar atención a partir de ahora es a los movimientos en el sector en torno a esta nueva norma. Sobre todo porque, siguiendo la filosofía clásica de las normas BS, se prevé que para finales de este año aparezca la parte 2 de la norma, que ya será una especificación de los mínimos necesarios para desarrollar un Sistema de Gestión de la Continuidad TIC, y por tanto un esquema certificable específico para la continuidad TIC, con el interés que estos temas pueden despertar. Y tampoco sería descabellado pensar en que BSI pueda publicar una traducción oficial en castellano de estas normas, como ya hizo en su momento con la BS 25999, con el fin de incrementar el nivel de penetración en el mercado hispano-hablante...
La aparición de una norma de estas características me parece muy importante por dos motivos. El primero de ellos es que va a servir para separar formalmente la continuidad TIC de la continuidad de negocio, de modo que a nadie le den gato por liebre cuando hablemos de esta última. La continuidad del negocio es algo más que la continuidad de los servicios TIC, aunque tengan mucha interrelación. Por eso yo a veces prefiero el término "continuidad de la actividad comercial" que he visto utilizado en algunos sitios, porque aunque pueda ser un término menos exacto sí que da la sensación de que la informática no es lo fundamental. Que se caiga nuestro sistema CRM no equivale a que nuestros comerciales dejen de vender, y lo importante para el negocio es esto último. La continuidad de negocio debe estar orientada hacia los procesos de negocio, valga la redundancia, hacia los servicios prestados a cliente final y las actividades productivas, y el hecho de que dichas actividades utilicen en mayor o menor medida infraestructuras TIC sólo debería determinar la forma de abordar el problema. ¿De qué serviría tener garantizada la continuidad de nuestros sistemas informáticos si no tenemos garantizada la continuidad del know-how asociado a su uso y explotación? En el fondo, la gestión de la continuidad del negocio tiene mucho más que ver con la gestión del conocimiento que con la gestión TIC, y sin embargo es muy habitual que, al hablar de ella, la cantidad de veces que se mencione esta última sea abrumadoramente superior al número de veces que se habla de la primera...
El segundo motivo por el que me alegro de la aparición de esta norma es porque plantea un marco mucho más definido de actuación en materia de continuidad TIC. Obviamente, al querer entender la BS 25999 como una referencia para la continuidad de los sistemas nos encontrábamos con muchas vaguedades y conceptos excesivamente amplios que luego era necesario acotar y "traducir" artificialmente. En cambio, creo que con esta nueva norma, centrada en el ámbito tecnológico, estaremos en condiciones de disponer de una referencia mucho más útil a la hora de hablar de continuidad en entornos TI.
Por último, creo que otro de los aspectos a los que habrá que prestar atención a partir de ahora es a los movimientos en el sector en torno a esta nueva norma. Sobre todo porque, siguiendo la filosofía clásica de las normas BS, se prevé que para finales de este año aparezca la parte 2 de la norma, que ya será una especificación de los mínimos necesarios para desarrollar un Sistema de Gestión de la Continuidad TIC, y por tanto un esquema certificable específico para la continuidad TIC, con el interés que estos temas pueden despertar. Y tampoco sería descabellado pensar en que BSI pueda publicar una traducción oficial en castellano de estas normas, como ya hizo en su momento con la BS 25999, con el fin de incrementar el nivel de penetración en el mercado hispano-hablante...
18 diciembre 2008
No seas vulnerable
Seguro que ya lo sabes. Probablemente, ya estés actualizado. Quizás ni siquiera lo necesites porque no utilizas Internet Explorer. Pero por si acaso se te ha pasado, recuerda que se ha descubierto una vulnerabilidad de Internet Explorer que permite que la ejecución arbitraria de código sin necesidad de interacción con el usuario con sólo visitar una página web preparada para aprovecharse de esa vulnerabilidad, y que está siendo activamente explotada. Y que Microsoft ya ha publicado un parche extraordinario que soluciona la citada vulnerabilidad. Así que ya no hay excusa para seguir siendo vulnerable, sólo tienes que instalarlo. ¿Que no tienes tiempo? Luego no digas que no te avisé... ;-)
¿Que tú eres de los que no ha necesitado el aviso? Así me gusta. No esperaba menos de vosotros!
Para todos vosotros (sí, también para los del párrafo de arriba)...
- ZORIONAK, ETA URTE BERRI ON -
- FELIZ NAVIDAD Y PRÓSPERO AÑO 2009 -
Nos vemos el año que viene (o quizás antes).
04 noviembre 2008
Transacciones seguras
La semana pasada leí una reseña sobre un dispositivo para asegurar las transacciones bancarias que me gustó. El dispositivo en cuestión es un llavero USB cuyo cometido básico es establecer un canal de comunicación seguro entre el propio dispositivo y el banco, a través del cual se visualizan y validan manualmente las transacciones que realicemos, si realmente la información visualizada se corresponde con la transacción que queremos realizar.
Me gusta el planteamiento por varios motivos. El primero de ellos es que coincido con el planteamiento de partida, que supone la utilización, en el extremo del usuario, de un recurso proporcionado por la entidad bancaria que permite garantizar la seguridad de las transacciones. El hecho de que sea la entidad bancaria la que trate de garantizar la seguridad extremo a extremo me parece algo fundamental, ya que supone un incremento en la responsabilidad que el banco está dispuesto a asumir en términos de la seguridad global del servicio proporcionado.
El segundo motivo es que este planteamiento sigue la premisa de que la forma de garantizar esa seguridad extremo a extremo sea mediante el uso de un elemento seguro "per se" y que proporciona toda la funcionalidad necesaria para esa seguridad. En este caso estamos ante un dispositivo hardware externo, pero el mismo planteamiento sería válido con otro tipo de módulo de usuario que fuese capaz de ofrecer las mismas garantías: ser un entorno cerrado y sólo accesible en un extremo por el canal de comunicaciones seguro y en el otro por el usuario. Esto supone, sencillamente, que sea el propio interfaz de usuario el que incorpore todas las funcionalidades de seguridad precisas y que además dicha interfaz sea cerrada al resto de elementos que intervienen en la comunicación, ya que en este caso el equipo de usuario es un simple elemento de comunicación sobre el que opera el dispositivo.
Y el tercero de los motivos es que este planteamiento supone una nueva forma de afrontar este tipo de problemas. Se puede estar o no de acuerdo en si la mejor forma de asegurar una transacción electrónica es validarla manualmente, pero al menos supone una forma distinta de afrontar este problema. Además, en este caso tenemos la ventaja de que no es necesario utilizar un canal de comunicación alternativo como puede ser la telefonía móvil para llevar a cabo esta tarea de validación, lo cual creo que favorece la penetración de esta solución.
En definitiva, un dispositivo interesante. A diferencia del autor del post no tengo muy claro el futuro de su implantación generalizada, aunque al menos espero que sirva de inspiración a los diseñadores de soluciones de seguridad en este tipo de entornos para empezar a pensar en otro tipo de soluciones que realmente sean capaces de resolver de forma más efectiva todas las problemáticas que deben resolver este tipo de soluciones.
Me gusta el planteamiento por varios motivos. El primero de ellos es que coincido con el planteamiento de partida, que supone la utilización, en el extremo del usuario, de un recurso proporcionado por la entidad bancaria que permite garantizar la seguridad de las transacciones. El hecho de que sea la entidad bancaria la que trate de garantizar la seguridad extremo a extremo me parece algo fundamental, ya que supone un incremento en la responsabilidad que el banco está dispuesto a asumir en términos de la seguridad global del servicio proporcionado.
El segundo motivo es que este planteamiento sigue la premisa de que la forma de garantizar esa seguridad extremo a extremo sea mediante el uso de un elemento seguro "per se" y que proporciona toda la funcionalidad necesaria para esa seguridad. En este caso estamos ante un dispositivo hardware externo, pero el mismo planteamiento sería válido con otro tipo de módulo de usuario que fuese capaz de ofrecer las mismas garantías: ser un entorno cerrado y sólo accesible en un extremo por el canal de comunicaciones seguro y en el otro por el usuario. Esto supone, sencillamente, que sea el propio interfaz de usuario el que incorpore todas las funcionalidades de seguridad precisas y que además dicha interfaz sea cerrada al resto de elementos que intervienen en la comunicación, ya que en este caso el equipo de usuario es un simple elemento de comunicación sobre el que opera el dispositivo.
Y el tercero de los motivos es que este planteamiento supone una nueva forma de afrontar este tipo de problemas. Se puede estar o no de acuerdo en si la mejor forma de asegurar una transacción electrónica es validarla manualmente, pero al menos supone una forma distinta de afrontar este problema. Además, en este caso tenemos la ventaja de que no es necesario utilizar un canal de comunicación alternativo como puede ser la telefonía móvil para llevar a cabo esta tarea de validación, lo cual creo que favorece la penetración de esta solución.
En definitiva, un dispositivo interesante. A diferencia del autor del post no tengo muy claro el futuro de su implantación generalizada, aunque al menos espero que sirva de inspiración a los diseñadores de soluciones de seguridad en este tipo de entornos para empezar a pensar en otro tipo de soluciones que realmente sean capaces de resolver de forma más efectiva todas las problemáticas que deben resolver este tipo de soluciones.
24 septiembre 2008
Estas seguro de que estas seguro?
El juego de palabras del título puede parecer divertido, pero plantea una pregunta con mucha miga. ¿Puedes garantizar la seguridad de tus sistemas en este mismo instante? Esa es la pregunta que plantea Sebastián Bortnik en su post Cómo sé si estoy seguro.
La verdad es que es una pregunta con trampa. Si la seguridad completa es imposible de conseguir, nunca podremos asegurar al 100% nuestra seguridad. Eso quiere decir que ese % de riesgo residual se puede traducir en un % de certeza residual acerca de nuestra seguridad plena. ¿Se puede estar un 95% seguro de que los sistemas de información no han sido violados? Eso es precisamente lo que habría que garantizar en términos estadísticos.
Y el artículo continúa con un check-list de elementos a verificar para poder garantizar esa seguridad de los sistemas. Un check-list interesante, sobre todo, para plantearnos cuál es el nivel de supervisión que tenemos sobre nuestra seguridad. ¿Cuántos de estos ítems aparecen en nuestro cuadro de mando de seguridad? ¿En qué parámetros nos basamos para responder a preguntas sobre nuestra seguridad? Vemos la lista:
La verdad es que es una pregunta con trampa. Si la seguridad completa es imposible de conseguir, nunca podremos asegurar al 100% nuestra seguridad. Eso quiere decir que ese % de riesgo residual se puede traducir en un % de certeza residual acerca de nuestra seguridad plena. ¿Se puede estar un 95% seguro de que los sistemas de información no han sido violados? Eso es precisamente lo que habría que garantizar en términos estadísticos.
Y el artículo continúa con un check-list de elementos a verificar para poder garantizar esa seguridad de los sistemas. Un check-list interesante, sobre todo, para plantearnos cuál es el nivel de supervisión que tenemos sobre nuestra seguridad. ¿Cuántos de estos ítems aparecen en nuestro cuadro de mando de seguridad? ¿En qué parámetros nos basamos para responder a preguntas sobre nuestra seguridad? Vemos la lista:
- Identificadores de usuario (no) autorizados.
- Servicios corriendo (no) conocidos.
- Fecha (des)actualizada y/(o) (des)sincronizada.
- Sistemas (no) desarrollados bajo normativas y estándares, incluyendo los de seguridad.
- Vulnerabilidades conocidas (no) parcheadas.
- Actividad del administrador (no) autorizada.
- (No) Ausencia de alertas en los sistemas de seguridad -Antimalware, IDS/IPS, SIM, etc.-.
- Parámetros de funcionamiento de los servidores (in)controlados -carga, ocupación, etc.-.
- (No) Ausencia de tráfico inusual en la red -firewall, routers, etc.-.
- Anti-malware (des)actualizado.
- (No) Ausencia de intentos fallidos de log-on.
- (No) Ausencia de errores en los logs de los sistemas y aplicaciones.
- (No) Ausencia de accesos físicos no autorizados.
- Caídas de los sistemas (no) justificadas.
Seguro que a todos se nos ocurren más apartados a controlar, pero la pregunta es... ¿Cuántos de ellos controlamos? ¿Sobre cuántos somos capaces de responder adecuadamente? Y en última instancia... ¿Qué argumentos tenemos, en realidad, para poder asegurar con bastante certeza que nuestros sistemas son seguros? Porque no olvidemos que hay dos motivos para no registrar incidentes de seguridad: que no los tengamos o que no nos enteremos de que suceden.
21 mayo 2008
En quién confiar?
Poco a poco parece que se van calmando los ánimos después del bombazo informativo que supuso la noticia de que las claves criptográficas SSL de debian eran vulnerables. Después de que nos contaran la noticia y de que nos aclarasen algunas dudas al respecto, probablemente todos habremos actualizado ya nuestras claves y respiraremos tranquilos tras comprobar que nadie ha utilizado la vulnerabilidad para hacerse con nuestros sistemas.
Y ahora, cuando ya ha pasado la ola, es cuando algunos pueden empezar a notar la resaca. Debian era una distribución reconocida, de prestigio. ¿Sigue siéndolo después de este incidente? ¿Se puede seguir confiando en debian? ¿Existen alternativas más confiables? Es posible que este tipo de preguntas le hayan surgido a más de uno (de hecho, en los comentarios de esta versión de la noticia tenemos un buen ejemplo).
Mi punto de vista es que este hecho, o cualquier otro de caracter similar, no debería suponer prácticamente ningún cambio en la opinión que teníamos de un determinado producto software. Que aparezca una vulnerabilidad crítica no es algo excepcional, y que sea explotable remotamente tampoco es tan raro. Ni más ni menos de lo que lo era antes. La probabilidad de ocurrencia existe, no sólo en debian sino en cualquier producto software, y que haya ocurrido una vez no cambia nada. Cualquier código tiene fallos, independientemente de que estén o no publicados. La probabilidad de que existan fallos de esta gravedad depende principalmente del propio producto, de su complejidad, tamaño, características y proceso de "fabricación". Que se publiquen tiene tanto de negativo como de positivo, pero no afecta a la "seguridad" del propio producto, sino a la probabilidad de que se intente explotar.
¿En conclusión? Que si queremos valorar la seguridad de debian, o de cualquier otra cosa, nos olvidemos del incidente de moda. Era tan probable que se incendiase un rascacielos antes de que se quemara el Windsor como después. No debemos dejarnos llevar por nuestra percepción del riesgo. Si hasta el incidente habíamos confiado en ese producto, sería por algo, no? Habrá que pensar en ese motivo, y analizar si sigue siendo válido. Y ojo, que la estadística suele jugar malas pasadas. Que no haya salido un 6 en ninguna de las tiradas de dados que hemos hecho no quiere decir que en la siguiente no pueda salir, ni tampoco que salga una de cada seis veces...
Y ahora, cuando ya ha pasado la ola, es cuando algunos pueden empezar a notar la resaca. Debian era una distribución reconocida, de prestigio. ¿Sigue siéndolo después de este incidente? ¿Se puede seguir confiando en debian? ¿Existen alternativas más confiables? Es posible que este tipo de preguntas le hayan surgido a más de uno (de hecho, en los comentarios de esta versión de la noticia tenemos un buen ejemplo).
Mi punto de vista es que este hecho, o cualquier otro de caracter similar, no debería suponer prácticamente ningún cambio en la opinión que teníamos de un determinado producto software. Que aparezca una vulnerabilidad crítica no es algo excepcional, y que sea explotable remotamente tampoco es tan raro. Ni más ni menos de lo que lo era antes. La probabilidad de ocurrencia existe, no sólo en debian sino en cualquier producto software, y que haya ocurrido una vez no cambia nada. Cualquier código tiene fallos, independientemente de que estén o no publicados. La probabilidad de que existan fallos de esta gravedad depende principalmente del propio producto, de su complejidad, tamaño, características y proceso de "fabricación". Que se publiquen tiene tanto de negativo como de positivo, pero no afecta a la "seguridad" del propio producto, sino a la probabilidad de que se intente explotar.
¿En conclusión? Que si queremos valorar la seguridad de debian, o de cualquier otra cosa, nos olvidemos del incidente de moda. Era tan probable que se incendiase un rascacielos antes de que se quemara el Windsor como después. No debemos dejarnos llevar por nuestra percepción del riesgo. Si hasta el incidente habíamos confiado en ese producto, sería por algo, no? Habrá que pensar en ese motivo, y analizar si sigue siendo válido. Y ojo, que la estadística suele jugar malas pasadas. Que no haya salido un 6 en ninguna de las tiradas de dados que hemos hecho no quiere decir que en la siguiente no pueda salir, ni tampoco que salga una de cada seis veces...
31 marzo 2008
Este mensaje se auto-destruirá en: 5 - 4 - 3 - 2...
Últimamente parece que los ingenieros de algunas empresas han rescatado del baúl de los recuerdos los comics de Mortadelo y Filemon y han vuelto a leer alguna de las historietas. Porque parece que se ha puesto de moda eso de la "audotestrucción" de la información, al más puro estilo agente secreto. Si hace un mes nos contaban la noticia del portátil que se autodestruye en caso de robo, este fin de semana tenemos un nuevo caso de autodestrucción, en concreto el de la música que se "autodestruye" al finalizar el periodo de suscripción. ¿Pensamiento "convergente", o nueva moda? Aunque quizás sólo sea un caso de periodista fan de la TIA...
Sea lo que sea, si realmente la solución es tan efectiva como la de los comics (en ellos, el mensaje secreto como mínimo explotaba estrepitosamente), el método de salvaguarda de la información es realmente útil. Sin embargo, si seguimos pensando en los comics, esta solución nunca es totalmente efectiva. ¿Dónde "escuchamos" el mensaje secreto? ¿Estamos seguros de que no hay "malos" alrededor que se hayan enterado? Porque en el comic ese era el detonante de muchas de las desventuras de sus protagonistas... Y lo que es peor: ¿hemos "entendido" realmente el "mensaje secreto"? Porque si se ha destruido completamente, nadie puede recuperarlo, ni siquiera nosotros. ¿Estamos seguros de que la información que se ha destruido no vamos a volver a necesitarla?
Como alternativa menos drástica, siempre tenemos las a veces odiadas plataformas de gestión de derechos digitales (DRM). Hablo de plataformas, y no de tecnologías, porque para su aplicación práctica es necesario algo más que una tecnología de identificación de usuarios y asignación de derechos y privilegios sobre objetos digitales: es necesaria una completa plataforma de gestión de identidades, capaz de vincular personas, identificadores digitales, permisos y contenidos, capaz de gestionarlos de forma eficiente y que sea sencilla tanto de utilizar como de administrar. ¿O alguien cree que el DRM no es más que cifrado y gestión de permisos y claves? La alternativa a la autodestrucción es más potente, sí, pero también mucho más exigente en cuanto a "madurez" y sensibilización de todos sus usuarios. ¿Qué opción es la más apropiada? Dependerá del caso, porque tecnología hay para todos los gustos... Pero sea cual sea vuestra opción, sed conscientes de lo que implica. Porque siempre hay usuarios que quieren recuperar la grabación que ha explotado, y usuarios que no se fian aunque sobre la cinta haya pasado una apisonadora.
Sea lo que sea, si realmente la solución es tan efectiva como la de los comics (en ellos, el mensaje secreto como mínimo explotaba estrepitosamente), el método de salvaguarda de la información es realmente útil. Sin embargo, si seguimos pensando en los comics, esta solución nunca es totalmente efectiva. ¿Dónde "escuchamos" el mensaje secreto? ¿Estamos seguros de que no hay "malos" alrededor que se hayan enterado? Porque en el comic ese era el detonante de muchas de las desventuras de sus protagonistas... Y lo que es peor: ¿hemos "entendido" realmente el "mensaje secreto"? Porque si se ha destruido completamente, nadie puede recuperarlo, ni siquiera nosotros. ¿Estamos seguros de que la información que se ha destruido no vamos a volver a necesitarla?
Como alternativa menos drástica, siempre tenemos las a veces odiadas plataformas de gestión de derechos digitales (DRM). Hablo de plataformas, y no de tecnologías, porque para su aplicación práctica es necesario algo más que una tecnología de identificación de usuarios y asignación de derechos y privilegios sobre objetos digitales: es necesaria una completa plataforma de gestión de identidades, capaz de vincular personas, identificadores digitales, permisos y contenidos, capaz de gestionarlos de forma eficiente y que sea sencilla tanto de utilizar como de administrar. ¿O alguien cree que el DRM no es más que cifrado y gestión de permisos y claves? La alternativa a la autodestrucción es más potente, sí, pero también mucho más exigente en cuanto a "madurez" y sensibilización de todos sus usuarios. ¿Qué opción es la más apropiada? Dependerá del caso, porque tecnología hay para todos los gustos... Pero sea cual sea vuestra opción, sed conscientes de lo que implica. Porque siempre hay usuarios que quieren recuperar la grabación que ha explotado, y usuarios que no se fian aunque sobre la cinta haya pasado una apisonadora.
25 marzo 2008
Seguridad y teléfonos móviles
La seguridad en relación a los teléfonos móviles no es un tema nuevo, pero la verdad es que cada vez da más que hablar (y lo que le queda). Si el mes pasado publicaban como noticia los resultados de un estudio sobre seguridad en telefonía móvil realizado por un fabricante de antivirus, en el que nos alertaban de la preocupación generalizada de los usuarios de esta tecnología en relación a la seguridad, hace unos días nos contaban que, en realidad, esa preocupación es excesiva, y está motivada por el alarmismo que crean interesadamente las compañías de seguridad para vender más productos.
No voy a entrar a valorar el sensacionalismo ni los intereses que mueven cada una de las dos noticias (eso lo dejo en manos de los muchos lectores con espíritu crítico que deseo que tenga el blog), pero sí que voy a comentar algunas de las conclusiones que se desprenden de ambos informes, que más allá de los intereses creo que pueden ser de provecho.
Estoy de acuerdo en que el interés de los usuarios de la telefonía móvil por la seguridad es creciente, aunque creo que es un factor que sobre todo se da en entornos corporativos, en los que ya la conciencia por alguna de las versiones de la seguridad (la privacidad, por ejemplo) está bastante despierta. Pero la verdad es que todavía no consigo ver esa preocupación en otros tipos de usuarios, como los adolescentes, por ejemplo.
Es entendible que la mayor preocupación de los usuarios en torno a la seguridad sean los riesgos que pueden afectar directamente a su bolsillo. Al fin y al cabo parece uno de los riesgos más probables, sobre todo si tenemos en cuenta el ánimo de lucro de los posibles "atacantes". Sin embargo, es curioso ver cómo las protecciones de seguridad que incorporan los teléfonos móviles normalmente no van dirigidas contra este tipo de riesgos, sino contra los "tradicionales" (virus, principalmente) en el mundo del PC.
Probablemente esta sea la causa de la divergencia existente entre ambos informes. Actualmente los riesgos derivados de virus que afecten a teléfonos móviles no son excesivamente altos, y aunque a futuro seguro que van a ser más importantes, a día de hoy son fenómenos prácticamente anecdóticos si los comparamos con el mundo del PC. Si es conveniente o no aumentar a día de hoy la carga de procesamiento de un móvil con un antivirus es algo que cada usuario debería valorar teniendo en cuenta el riesgo real al respecto. Sin embargo, sí que es cierto que el usuario se encuentra desprotegido frente a otras amenazas como las de suscripción a servicios de facturación abusiva, recepción de mensajes no deseados, tarificación abusiva, ... Riesgos que los usuarios sí que perciben, y sufren en mayor medida, pero contra los que a día de hoy no existe protección efectiva. ¿No se podrían desarrollar una especie de servicios y/o productos "anti-phishing", "anti-dialers", de "control de contenidos", etc. para teléfonos móviles? Por qué no esforzarse en desarrollar soluciones a los problemas actuales del mundo de la telefonía móvil?
Esta última pregunta, creo, es la que se hacen la mayor parte de los usuarios encuestados, y su solución también aparece en los resultados: que sea la propia compañía de telefonía móvil la que proporcione los servicios de seguridad. Porque en este caso no sólo controla la red, sino que modifica y distribuye los terminales. Tiene el control de la mayor parte de los elementos sobre los que se pueden implementar funciones de seguridad. Entonces, por qué no se esfuerzan?
La pregunta tiene multitud de respuestas, pero creo que la clave es que no ven el negocio en ofrecer esos "servicios de seguridad" (no voy a entrar en si obtienen o no beneficios de permitir esos "servicios" abusivos). A día de hoy, los clientes que más ven el riesgo de la confidencialidad son los corporativos, mientras que los que más ven (sufren) el riesgo económico podríamos decir que son mayoritariamente los "residenciales". Dos mercados distintos, en el que fundamentalmente son los primeros los que están dispuestos a pagar un sobreprecio por la protección que puede "vender" un antivirus. ¿Cuántos nuevos clientes "residenciales" sería capaz de atraer una compañía de telefonía móvil por ofrecer servicios de seguridad que minimicen los riesgos directamente económicos? ¿Compensa el esfuerzo necesario en desarrollar esos servicios? Esa es la cuestión... Y mientras tanto, seguirá habiendo estudios para todos los gustos.
No voy a entrar a valorar el sensacionalismo ni los intereses que mueven cada una de las dos noticias (eso lo dejo en manos de los muchos lectores con espíritu crítico que deseo que tenga el blog), pero sí que voy a comentar algunas de las conclusiones que se desprenden de ambos informes, que más allá de los intereses creo que pueden ser de provecho.
Estoy de acuerdo en que el interés de los usuarios de la telefonía móvil por la seguridad es creciente, aunque creo que es un factor que sobre todo se da en entornos corporativos, en los que ya la conciencia por alguna de las versiones de la seguridad (la privacidad, por ejemplo) está bastante despierta. Pero la verdad es que todavía no consigo ver esa preocupación en otros tipos de usuarios, como los adolescentes, por ejemplo.
Es entendible que la mayor preocupación de los usuarios en torno a la seguridad sean los riesgos que pueden afectar directamente a su bolsillo. Al fin y al cabo parece uno de los riesgos más probables, sobre todo si tenemos en cuenta el ánimo de lucro de los posibles "atacantes". Sin embargo, es curioso ver cómo las protecciones de seguridad que incorporan los teléfonos móviles normalmente no van dirigidas contra este tipo de riesgos, sino contra los "tradicionales" (virus, principalmente) en el mundo del PC.
Probablemente esta sea la causa de la divergencia existente entre ambos informes. Actualmente los riesgos derivados de virus que afecten a teléfonos móviles no son excesivamente altos, y aunque a futuro seguro que van a ser más importantes, a día de hoy son fenómenos prácticamente anecdóticos si los comparamos con el mundo del PC. Si es conveniente o no aumentar a día de hoy la carga de procesamiento de un móvil con un antivirus es algo que cada usuario debería valorar teniendo en cuenta el riesgo real al respecto. Sin embargo, sí que es cierto que el usuario se encuentra desprotegido frente a otras amenazas como las de suscripción a servicios de facturación abusiva, recepción de mensajes no deseados, tarificación abusiva, ... Riesgos que los usuarios sí que perciben, y sufren en mayor medida, pero contra los que a día de hoy no existe protección efectiva. ¿No se podrían desarrollar una especie de servicios y/o productos "anti-phishing", "anti-dialers", de "control de contenidos", etc. para teléfonos móviles? Por qué no esforzarse en desarrollar soluciones a los problemas actuales del mundo de la telefonía móvil?
Esta última pregunta, creo, es la que se hacen la mayor parte de los usuarios encuestados, y su solución también aparece en los resultados: que sea la propia compañía de telefonía móvil la que proporcione los servicios de seguridad. Porque en este caso no sólo controla la red, sino que modifica y distribuye los terminales. Tiene el control de la mayor parte de los elementos sobre los que se pueden implementar funciones de seguridad. Entonces, por qué no se esfuerzan?
La pregunta tiene multitud de respuestas, pero creo que la clave es que no ven el negocio en ofrecer esos "servicios de seguridad" (no voy a entrar en si obtienen o no beneficios de permitir esos "servicios" abusivos). A día de hoy, los clientes que más ven el riesgo de la confidencialidad son los corporativos, mientras que los que más ven (sufren) el riesgo económico podríamos decir que son mayoritariamente los "residenciales". Dos mercados distintos, en el que fundamentalmente son los primeros los que están dispuestos a pagar un sobreprecio por la protección que puede "vender" un antivirus. ¿Cuántos nuevos clientes "residenciales" sería capaz de atraer una compañía de telefonía móvil por ofrecer servicios de seguridad que minimicen los riesgos directamente económicos? ¿Compensa el esfuerzo necesario en desarrollar esos servicios? Esa es la cuestión... Y mientras tanto, seguirá habiendo estudios para todos los gustos.
05 marzo 2008
Navegantes en la red
Hace unos días, la Asociación para la Investigación de Medios de Comunicación publicó los resultados de su 10ª encuesta a usuarios de Internet. Algunos de los resultados más destacables de dicha encuesta son los siguientes:
- Aparte del acceso a Internet a través del PC, casi el 60% de los encuestados acceden a Internet desde un ordenador portátil, y más del 30% lo hace desde pequeños dispositivos móviles (teléfonos móviles y PDAs). Son ratios a tener en cuenta dada las amenazas específicas a las que están sujetos estos equipos.
- Uno de cada cinco encuestados accede a Internet a través de redes WiFi distintas a la del trabajo o casa (a priori poco confiables).
- Entre los mayores problemas de Internet considerados por los encuestados podemos encontrar las infecciones por virus o spyware, con casi un 54%, la propia seguridad con más de un 43%, y la falta de confidencialidad con un 24% de los encuestados. Dentro del ranking de mayores preocupaciones en Internet se encuentran en el 3º, 5º y 7º puesto respectivamente, según los resultados de la encuesta.
- El 25% de los encuestados ya posee un certificado digital de firma electrónica.
- El 75% de las personas que han respondido a la encuesta hace uso de software de bloqueo de pop-ups. Algo superior es el dato de personas que cuentan con filtros anti-spam, y pese a ello el 58,9% de los encuestados dice recibir más de 10 correos basura a la semana.
- Más del 67% de los encuestados tiene un antivirus actualizado, y casi la mitad dice no haberse visto nunca infectado por un virus en el último año.
Parecen unos resultados bastante positivos, aunque hay que tener en cuenta que la encuesta no es un estudio estadístico, sino que está basada en las contestaciones voluntarias de usuarios de Internet de perfil medio-alto de conocimientos. De todos modos, creo que constituye un buen comienzo para pensar en positivo en relación al fomento de la preocupación por la seguridad en Internet entre todos sus usuarios.
21 enero 2008
Pantalla limpia
Conozco a algunos responsables de seguridad con verdadera obsesión por las políticas de escritorio y pantalla limpias, y a otros que prácticamente no se preocupan en absoluto por ello. Mismo control, distinta implementación. ¿Quién tiene razón? Posiblemente, los dos. Al fin y al cabo, el control trata de prevenir que alguien pueda ver, accidentalmente, información que no debería conocer. Estar a salvo de miradas indiscretas. ¿Cómo nos podemos proteger?
Para los más paranoicos existen tecnologías muy potentes. Por ejemplo, hay sistemas que, basados en tecnología de localización indoor mediante UWB, son capaces de identificar si alguien se acerca al perímetro de seguridad de un equipo, y bloquear automáticamente la pantalla si no es su usuario autorizado. Una solución muy efectiva, con múltiples posibilidades, y muy cara (aunque hay situaciones en que el valor de la información a proteger de dichas miradas indiscretas justifica la inversión). Si no nos queremos gastar tanto dinero, existen gadgets más baratos y menos vistosos, pero también efectivos, como este. Sencillamente, un filtro para el monitor que sólo permite ver correctamente la pantalla desde el frente, y que por tanto evita las miradas indiscretas "laterales".
Qué otras opciones hay? Aparte de un "dispositivo" que no he sido capaz de encontrar, y que consistía en un pasamontañas cosido a un tubo de tela que se enganchaba al perímetro de la pantalla, para que sólo el que lo llevara puesto pudiera verla (os prometo que había una foto muy divertida), existe también la posibilidad de no usar nada. Sencillamente, organizando los puestos de trabajo de forma que no sea necesario protegerse de miradas indiscretas porque cualquier posible mirada nunca lo será. Es decir: separando al personal en salas de modo que todos los de la misma sala tengan acceso a la misma información (por ejemplo, por áreas). ¿Parece una medida excesiva? Despachos para ciertas cargos dentro de la empresa ha habido toda la vida, y uno de los motivos esgrimidos para su utilización ha sido precisamente la necesidad de confidencialidad (aparte de los motivos de status u otros que no vienen al caso). ¿Y cuántas empresas conoceis que estén departamentalizadas físicamente (al menos, en parte)?
En resumen, existen muchas formas de "implementar" los controles de pantalla limpia, y en función de la solución que adoptemos, y de la casuística de nuestra organización (quizás es más interesante para nuestro negocio fomentar el trabajo inter-disciplinar que evitar que el personal comercial vea información del departamento técnico, por ejemplo), dependerá que nuestro responsable de seguridad se tenga que preocupar o pueda no hacer caso al cumplimiento de las políticas corporativas de pantalla limpia. Y menos mal que es así, porque... ¿cuantos escritorios plagados de montañas de papeles de toda índole conoceis?
ACTUALIZACIÓN: Al final me han pasado (gracias, Carlos) la referencia al "dispositivo" físico del que os hablaba: la capucha de privacidad , o algo así (imágenes 5/6 y 6/6). Alguno lo compraría?
Para los más paranoicos existen tecnologías muy potentes. Por ejemplo, hay sistemas que, basados en tecnología de localización indoor mediante UWB, son capaces de identificar si alguien se acerca al perímetro de seguridad de un equipo, y bloquear automáticamente la pantalla si no es su usuario autorizado. Una solución muy efectiva, con múltiples posibilidades, y muy cara (aunque hay situaciones en que el valor de la información a proteger de dichas miradas indiscretas justifica la inversión). Si no nos queremos gastar tanto dinero, existen gadgets más baratos y menos vistosos, pero también efectivos, como este. Sencillamente, un filtro para el monitor que sólo permite ver correctamente la pantalla desde el frente, y que por tanto evita las miradas indiscretas "laterales".
Qué otras opciones hay? Aparte de un "dispositivo" que no he sido capaz de encontrar, y que consistía en un pasamontañas cosido a un tubo de tela que se enganchaba al perímetro de la pantalla, para que sólo el que lo llevara puesto pudiera verla (os prometo que había una foto muy divertida), existe también la posibilidad de no usar nada. Sencillamente, organizando los puestos de trabajo de forma que no sea necesario protegerse de miradas indiscretas porque cualquier posible mirada nunca lo será. Es decir: separando al personal en salas de modo que todos los de la misma sala tengan acceso a la misma información (por ejemplo, por áreas). ¿Parece una medida excesiva? Despachos para ciertas cargos dentro de la empresa ha habido toda la vida, y uno de los motivos esgrimidos para su utilización ha sido precisamente la necesidad de confidencialidad (aparte de los motivos de status u otros que no vienen al caso). ¿Y cuántas empresas conoceis que estén departamentalizadas físicamente (al menos, en parte)?
En resumen, existen muchas formas de "implementar" los controles de pantalla limpia, y en función de la solución que adoptemos, y de la casuística de nuestra organización (quizás es más interesante para nuestro negocio fomentar el trabajo inter-disciplinar que evitar que el personal comercial vea información del departamento técnico, por ejemplo), dependerá que nuestro responsable de seguridad se tenga que preocupar o pueda no hacer caso al cumplimiento de las políticas corporativas de pantalla limpia. Y menos mal que es así, porque... ¿cuantos escritorios plagados de montañas de papeles de toda índole conoceis?
ACTUALIZACIÓN: Al final me han pasado (gracias, Carlos) la referencia al "dispositivo" físico del que os hablaba: la capucha de privacidad , o algo así (imágenes 5/6 y 6/6). Alguno lo compraría?
12 diciembre 2007
De todo un poco
Hoy tenía pensado hablar un poco de la "continuidad" ligada a las personas, y en particular comentar este artículo. Pero como veo que Javier Cao se ha adelantado :-) prefiero no ser repetitivo y comentar otras dos referencias.
La primera debería ser conocida, y sin embargo tengo la sensación de que no todo el mundo se pasea por la web de RedIRIS (¿quizás porque es un poco "gris"?). En ella, bajo el título de definición de una política de seguridad, dan un repaso bastante completo a la gestión de la seguridad de la información en términos globales. No es específicamente una guía de implantación de un SGSI, pero precisamente por éso me gusta. Contempla todos los aspectos de la seguridad desde un punto de vista práctico, pero sin encorsetarse a una norma específica. Una fantástica referencia para todos aquellos que realmente se interesen por la seguridad pero estén un poco "escaldados" con las normas.
Y la segunda referencia, que no tiene nada que ver con la anterior, es una pequeña introducción al origen y necesidades que resuelven los dispositivos UTM (Unified Threat Management, o gestión unificada de amenazas). Para los que no los conozcan, y espero que sean una minoría, son un tipo de dispositivos (creo que el término tecnología no es adecuado aquí) que aúnan en un solo dispositivo distintas funcionalidades de protección perimetral de red (Firewall, Antivirus, VPN, IPS, ...) en tiempo real y con gestión unificada de todas ellas. Creo que estos dispositivos tienen un futuro muy prometedor, sobre todo desde el punto de vista de la sencillez que supone la administración unificada de la seguridad perimetral. Seguro que tienen sus detractores, sobre todo entre aquellos que opinan que es mejor un equipo dedicado para cada función de seguridad, pero desde mi punto de vista la superior usabilidad de estos equipos terminará decantando la balanza a favor de la unificación. Y que no se preocupen aquellos que piensan que puede haber problemas de rendimiento o throughput, que si hay negocio los fabricantes ya se preocuparán de dar solución a este aspecto, que en realidad no es tan crítico a día de hoy.
Y por hoy, eso es todo...
La primera debería ser conocida, y sin embargo tengo la sensación de que no todo el mundo se pasea por la web de RedIRIS (¿quizás porque es un poco "gris"?). En ella, bajo el título de definición de una política de seguridad, dan un repaso bastante completo a la gestión de la seguridad de la información en términos globales. No es específicamente una guía de implantación de un SGSI, pero precisamente por éso me gusta. Contempla todos los aspectos de la seguridad desde un punto de vista práctico, pero sin encorsetarse a una norma específica. Una fantástica referencia para todos aquellos que realmente se interesen por la seguridad pero estén un poco "escaldados" con las normas.
Y la segunda referencia, que no tiene nada que ver con la anterior, es una pequeña introducción al origen y necesidades que resuelven los dispositivos UTM (Unified Threat Management, o gestión unificada de amenazas). Para los que no los conozcan, y espero que sean una minoría, son un tipo de dispositivos (creo que el término tecnología no es adecuado aquí) que aúnan en un solo dispositivo distintas funcionalidades de protección perimetral de red (Firewall, Antivirus, VPN, IPS, ...) en tiempo real y con gestión unificada de todas ellas. Creo que estos dispositivos tienen un futuro muy prometedor, sobre todo desde el punto de vista de la sencillez que supone la administración unificada de la seguridad perimetral. Seguro que tienen sus detractores, sobre todo entre aquellos que opinan que es mejor un equipo dedicado para cada función de seguridad, pero desde mi punto de vista la superior usabilidad de estos equipos terminará decantando la balanza a favor de la unificación. Y que no se preocupen aquellos que piensan que puede haber problemas de rendimiento o throughput, que si hay negocio los fabricantes ya se preocuparán de dar solución a este aspecto, que en realidad no es tan crítico a día de hoy.
Y por hoy, eso es todo...
30 noviembre 2007
Apuntes técnicos
La verdad es que últimamente el trabajo me consume bastante tiempo, y no puedo dedicarle tanto como me gustaría al blog. Así que hoy, en lugar de postear algo muy denso, me voy a limitar a dejar un par de referencias técnicas que me parecen bastante interesantes:
- La primera es esta, una seria y bastante profunda descripción de tecnologías anti-malware. Muy aconsejable para todo aquél que quiera profundizar a un nivel medianamente serio sobre el estado del arte en este mundo.
- La segunda, que no tiene nada que ver con la anterior, es esta otra. Es un documento que diserta sobre qué criterios utilizar a la hora de seleccionar un producto VPN SSL. Obviando la parte comercial del documento, que le hace perder puntos, me parece una reflexión interesante, aunque no sea excesivamente profunda, sobre temas en los que pensar antes de elegir un producto que implementa una tecnología, desde mi punto de vista, muy interesante y con mucho futuro.
Y por esta semana, eso es todo. Que paseis un buen fin de semana...
28 agosto 2007
Gadget de seguridad
Después de descubrir lo fácil y rápido que se puede copiar una tarjeta, está bien que alguien le haya sacado una aplicación beneficiosa a dicha posibilidad. En concreto, hablo de un nuevo aparatito que he visto referenciado en algunos blogs. Se trata de un pequeño dispositivo compuesto de una tarjeta "virgen" con banda magnética y un lector/grabador de tarjetas con algunas funciones adicionales (pantalla, unos botones y un lector de huellas dactilares).
La idea es que, tras autenticarte a través de tu huella, ese aparato puede guardar en su memoria una "copia" de todas tus tarjetas, y grabar sobre la tarjeta virgen una réplica de aquella que necesites en cada momento (seleccionable a través de los botones y la pantalla). Luego, al volver a guardar la tarjeta dentro del dispositivo, los datos almacenados se borran.
A priori parece un dispositivo interesante. Sobre todo, porque según afirman en la web, también sirve para copiar tarjetas que funcionen con códigos de barras (que luego se visualizan en la pantalla) y tarjetas sin contacto. Vamos, que bastante completito. Pero claro, algunos detalles quizás se podrían mejorar...
El primero es el lector de huellas. Mis experiencias con ordenadores portátiles que incorporan dispositivos de ese tipo no son demasiado buenas. POr otra parte, existen cantidad de "tretas" para burlar este tipo de lectores biométricos... (y por lo que parece, funcionan). Por lo tanto, dos problemas: que el lector de huellas no funcione correctamente (indisponibilidad) o que alguien falsifique nuestra huella (no me paro a analizar los peligros de que te corten el dedo). Y claro, es el único control de acceso que se ha habilitado... Acaso es tan complicado la incorporación de un teclado numérico y el uso de un PIN como control de acceso adicional? Al fin y al cabo, todas nuestras tarjetas están almacenadas en ese dispositivo...
La segunda pega es, precisamente, el hecho de que todos los datos estén almacenados en un único dispositivo. Evidentemente, el riesgo de que te roben "todas" las tarjetas aumenta, ya que sólo tienen que robar un único aparato. Pero lo que me preocupa es que por el momento no he sido capaz de encontrar ningún dato que afirme que la memoria del dispositivo es segura. No vaya a ser que si el ladrón accede físicamente a la memoria del aparato sea capaz de leer la información almacenada...
Y la tercera es que, si nos ponemos quisquillosos, sería interesante que la tarjeta fuese una tarjeta inteligente, y contase con un chip de contacto programable. Al fin y al cabo, es una tecnología que en ciertos ámbitos se está extendiendo cada vez más, sobre todo en formato de tarjeta monedero.
Y por último, una duda. Más de una vez he tenido problemas con las bandas magnéticas de mis tarjetas, que por estar demasiado rayadas no se podían leer. Si esta tarjeta va a ser la única que utilicemos en todos los casos... cuántas veces al cabo del día va a ser leída? Cuál es la vida útil de la tarjeta virgen? Quiero pensar que habrán tenido este dato en cuenta, y que el aparato incluirá más de una...
La idea es que, tras autenticarte a través de tu huella, ese aparato puede guardar en su memoria una "copia" de todas tus tarjetas, y grabar sobre la tarjeta virgen una réplica de aquella que necesites en cada momento (seleccionable a través de los botones y la pantalla). Luego, al volver a guardar la tarjeta dentro del dispositivo, los datos almacenados se borran.
A priori parece un dispositivo interesante. Sobre todo, porque según afirman en la web, también sirve para copiar tarjetas que funcionen con códigos de barras (que luego se visualizan en la pantalla) y tarjetas sin contacto. Vamos, que bastante completito. Pero claro, algunos detalles quizás se podrían mejorar...
El primero es el lector de huellas. Mis experiencias con ordenadores portátiles que incorporan dispositivos de ese tipo no son demasiado buenas. POr otra parte, existen cantidad de "tretas" para burlar este tipo de lectores biométricos... (y por lo que parece, funcionan). Por lo tanto, dos problemas: que el lector de huellas no funcione correctamente (indisponibilidad) o que alguien falsifique nuestra huella (no me paro a analizar los peligros de que te corten el dedo). Y claro, es el único control de acceso que se ha habilitado... Acaso es tan complicado la incorporación de un teclado numérico y el uso de un PIN como control de acceso adicional? Al fin y al cabo, todas nuestras tarjetas están almacenadas en ese dispositivo...
La segunda pega es, precisamente, el hecho de que todos los datos estén almacenados en un único dispositivo. Evidentemente, el riesgo de que te roben "todas" las tarjetas aumenta, ya que sólo tienen que robar un único aparato. Pero lo que me preocupa es que por el momento no he sido capaz de encontrar ningún dato que afirme que la memoria del dispositivo es segura. No vaya a ser que si el ladrón accede físicamente a la memoria del aparato sea capaz de leer la información almacenada...
Y la tercera es que, si nos ponemos quisquillosos, sería interesante que la tarjeta fuese una tarjeta inteligente, y contase con un chip de contacto programable. Al fin y al cabo, es una tecnología que en ciertos ámbitos se está extendiendo cada vez más, sobre todo en formato de tarjeta monedero.
Y por último, una duda. Más de una vez he tenido problemas con las bandas magnéticas de mis tarjetas, que por estar demasiado rayadas no se podían leer. Si esta tarjeta va a ser la única que utilicemos en todos los casos... cuántas veces al cabo del día va a ser leída? Cuál es la vida útil de la tarjeta virgen? Quiero pensar que habrán tenido este dato en cuenta, y que el aparato incluirá más de una...
Suscribirse a:
Entradas (Atom)
