En el Blog solemos hablar más de técnicas ofensivas que de técnicas defensivas. Aunque está claro que ambas son igual de importantes en caso de conflicto, las de ataque suelen ser más “divertidas”. Hoy sin embargo vamos a analizar una técnica de ingeniería de computadores destinada a mejorar su resistencia frente a ataques.
A la hora de diseñar un sistema informático crítico siempre se suele acudir a medidas que eviten la existencia de puntos únicos de fallo que puedan provocar un corte del servicio ofrecido.
La técnica de protección más habitual para esto es la Redundancia, que consiste en disponer de 2 o más sistemas similares para la realización de una misma tarea. De esta forma si uno de los sistemas falla, estarán listos otros para sustituirlo.
La Redundancia se puede aplicar duplicando equipos o duplicando los componentes hardware de los mismos. De esta forma ciertas partes del sistema pueden fallar sin que esto afecte al funcionamiento del mismo.
Hay diversas formas de distribución de equipos redundantes:
• En línea: Todos los equipos que forman el sistema redundante están activos y es el cliente del servicio el que elige cual utilizar.
• Balanceo de carga: Todos los equipos del sistema están activos, pero la carga de trabajo se reparte automáticamente entre ellos.
• En stand-by: Los equipos de reserva se encuentran inactivos y se activan cuando el equipo principal falla.
Cualquiera de estas alternativas es válida para garantizar la continuidad del servicio cuando hablamos de fallos “naturales”, pero puede que no sean suficientes cuando estamos hablando de fallos provocados por ataques intencionados.
En estos casos la Redundancia puede ser vulnerada. Por ejemplo si un atacante ha conseguido hacer caer un sistema principal ¿Qué le impide hacer lo mismo cuando entren en funcionamiento los equipos de reserva, si son iguales?
Por eso en seguridad de sistemas críticos además de medidas de Redundancia se suelen utilizar medidas de Duplicidad tecnológica.
Hablamos de Duplicidad tecnológica cuando se utilizan 2 o más sistemas diferentes (que utilizan tecnologías diferentes) para ofrecer el mismo servicio. Por ejemplo cuando tenemos 2 servidores Web que albergan las mismas páginas, pero que ejecutan software diferente.
La razón de utilizar 2 tecnologías diferentes es que si aparece una vulnerabilidad de software en una de ellas, esta no afectara a la otra.
Supongamos por ejemplo el caso de una red crítica, en la que tenemos 2 servidores de nombres DNS basados en Windows. Estos utilizan un diseño redundante que hace que cuando uno cae el otro toma su lugar, de forma que el servicio siempre esté disponible para el resto de equipos de la red. Pero por simplificar su gestión, ambos utilizan la misma versión de Windows y la misma configuración.
Si un día aparece una vulnerabilidad 0-day en Windows, ambos equipos podrían ser comprometidos mientras no se publicase el parche oficial. Y no existiría la opción de desconectarlos de la red ya que el resto de equipos se quedaría sin servicio.
Para esta situación, lo ideal sería tener un tercer equipo basado en Linux que pudiese dar un servicio de DNS equivalente. De esta forma si apareciese una vulnerabilidad en los sistemas Windows, estos podrían desconectarse de la red mientras son parcheados y el Linux ocuparía su función de forma segura.
El diseño en Duplicidad Tecnológica también es muy recomendable cuando se configura un sistema de protección (por ejemplo una barrera de cortafuegos). En estos diseños, lo ideal suele ser disponer de 2 capas de cortafuegos, una primera capa basada en tecnología de un fabricante y una segunda capa basada en tecnología de otro fabricante distinto.
De esta forma si se descubre una vulnerabilidad que permite saltarse los controles de seguridad del software de uno de los fabricantes, probablemente no afecte al otro.
Pero hay que tener cuidado con estas decisiones ya que algunos fabricantes utilizan tecnologías similares que si podrían ser vulnerables a los mismos ataques. Por ejemplo podríamos decidir utilizar 2 servidores Web, uno basado en Apache HTTP Server y otro basado en IBM HTTP Server, sin ser conscientes de que el segundo utiliza muchos componentes del primero.
La mayor pega de estos diseños es su alto coste. Ya que no solo aumentamos el coste de disponer de equipos adicionales, sino que al ser tecnologías diferentes probablemente tengamos que disponer de personal técnico diferente. Aunque de cara a la gestión de la seguridad esto también sería una ventaja.
Otra desventaja de tener 2 tecnologías diferentes es que tendremos el doble de probabilidades de que aparezcan vulnerabilidades (y el doble de trabajo de securización). Por eso cuando se aplica Duplicidad Tecnológica se recomienda trabajar con una distribución en stand-by, de forma que los equipos no activos se encuentren desconectados de la red para que no puedan ser atacados.
Blog colaborativo dedicado a compartir ideas sobre CiberGuerra, CiberTerrorismo, CiberInteligencia y Tácticas de Hacking.
jueves, 31 de marzo de 2011
Duplicidad Tecnológica
Artículo subido por
Ramon Pinuaga
1 comentarios
Enviar por correo electrónicoEscribe un blogCompartir con TwitterCompartir con FacebookCompartir en Pinterest
Etiquetas:
medidas de proteccion
miércoles, 30 de marzo de 2011
Estrategias militares en Ciberespacio II: Elegir el campo de batalla
En 490 a.C. fuerzas invasoras persas desembarcan en las cercanías de Maratón, a 32 kilómetros de Atenas. La historia habla de unos 100.000 persas, pero los historiadores cifran la cantidad de persas en 20.000-25.000 soldados. Los persas eligieron Maratón ya que estaban lo suficientemente lejos de Atenas como para poder desembarcar de forma ordenada, además la llanura de Maratón resultaba adecuada para la caballería persa que superaba a la ateniense.
A la hora de la batalla 10.000 atenienses y 1.000 platenses se enfrentaron a un ejército de al menos el doble de experimentados soldados. Entre un ejército y otro había apenas 1.500 metros, cuando los atenienses avanzaron rápidamente al ataque, las flechas persas pasaron por encima ya que estaban demasiado cerca, además debido a la estrechez del llano la caballería persa no pudo avanzar por los flancos como tenía previsto entorpecían las montañas por un lado y el mar por el otro. La batalla terminó con el increíble resultado de 203 muertos en el ejército atenienses (192 atenienses y 11 platenses) y 6.400 caídos persas, teniendo en cuenta que estos son datos de Heródoto un historiador griego. Al final el resultado de la batalla, exagerado o no, fue debido a una mala elección del campo de batalla por parte de los persas.
¿Puede afectar el concepto campo de Batalla a la ciberguerra?
Como siempre hago, pensemos en una posible situación. Un Tiger Team, diseña e implementa su nueva arma: un virus que explota una vulnerabilidad que nadie, solo ellos, conoce y que por lo tanto no está parcheada que además abre un camino para que los miembros de equipo entren en la red objetivo.
Con el mismo consiguen acceso a un servidor externo de la entidad atacada. Una vez dentro, aparecen los primeros problemas. Resulta que los sistemas internos no funcionan con sistemas operativos “estándar”, la red interna no es una red IPv4 al uso sino una red IPv6 o una red Novell (El caso de Novell lo digo por experiencia propia en el desarrollo de una auditoría de seguridad), las herramientas que tenemos preparadas para la metástasis interna no están adaptadas. Toca tomar una decisión: intentar ampliar la intrusión sacándose lo que se pueda, o una retirada estratégica esperando que no se den cuenta y poder volver en un futuro cercano.
En la situación anterior, ninguna de las opciones a tomar es buena, tanto una como con la otra existe la probabilidad de que nos detecten, además a la hora de hacer el análisis de la intrusión, puede que se detecte la vulnerabilidad 0 day que este Tiger Team tenía para introducirse en los sistemas “enemigos”. Desde mi punto de vista, una tragedia estratégica.
En otra situación, un equipo logra entrar en un sistema, tiene acceso a preciadas bases de datos con información crítica, por ejemplo, sobre el diseño de la red eléctrica de un país (información muy importante y útil a la hora de hacer unos bombardeos convencionales por ejemplo). Los ficheros de estas bases de datos pueden ser de un gran tamaño por la cantidad de información que tienen. A la hora de hacer un downloading de esta información, la velocidad de subida del objetivo es extremadamente baja y a cuanto más tiempo dura esa transmisión de información más probabilidades de que detecten este robo de información. Esto ya ha pasado, en el siguiente link se cuenta la historia de un troyano instalado en un ordenador de la oficina de la Canciller Angela Merkel y otros sistemas de miembros del gobierno alemán, el ataque se detectó cuando el troyano enviaba 160 Gigabytes de datos a una IP de China desde un PC de un ministro Alemán.
Otras situaciones lógicas es que en ciertos puntos estratégicos, los gobiernos o empresas introduzcan en sus detectores de intrusiones alerten del tráfico con dirección IP de destino u origen China (por ejemplo), o Irán, o Francia…..
Elegir bien
¿Qué se debería de buscar (en el mundo digital) a la hora de elegir un Campo de Batalla?
- Anonimato (o no….).
- Rapidez en las maniobras.
- Aprovechamiento al máximo de las herramientas y conocimientos que se poseen.
- Indetectabilidad del ataque (o no….).
En los términos que se habla normalmente, se piensa siempre en ataques cibernéticos que se realizan desde posiciones distantes gracias a que Internet nos acerca a todos. Mi planteamiento personal es que siempre cuanto más cerca mejor, con la idea clara de que los que realizan el ataque no puedan ser descubiertos o identificados a posteriori.
Mi primera idea es que si vamos a entrar en la red de una entidad de un país extranjero, si podemos situar un equipo en ese país perfecto. Si este equipo puede tener una conexión en el mismo proveedor que el objetivo mejor (siempre con una identidad falsa, claro). En muchas ocasiones, esto incluso puede facilitar el proceso de ataque sobre el objetivo, un caso sería en el que ya que estamos en el mismo proveedor hacernos con sus routers y por lo tanto con el tráfico a Internet del objetivo. Hay que tener en cuenta que esto también agiliza la investigación del caso por parte del afectado.
Además, seamos imaginativos, que mejor que en una intrusión obtener las contraseñas de las redes inalámbricas del objetivo (si es que no se pueden piratear de por si…), esto nos permitiría desde una posición cercana más velocidad y más capacidad de penetración en su red.
El uso de direcciones de Internet cercanas al rango del objetivo, puede hacer que el ataque pase algo más desapercibido, o al menos, el operador de turno dude un poco más en definir un tráfico extraño como un ataque. También al no usar direcciones extranjeras, permite ligeramente algo más de seguridad frente a la opción de que un detector de intrusiones salte al detectar envío de datos hacia un país extranjero.
También se ha de realizar un estudio del objetivo para ver que “terreno” nos vamos a encontrar una vez dentro de su red Interna, para ser algo ilustrativo he realizado unas pruebas con un posible objetivo. En este caso, he elegido la ahora desgraciadamente famosa Tepco (Tokyo Electric Power COmpany), la dueña de la central nuclear de Fukushima Daiichi. Ya en situaciones normales es un claro ejemplo de posible objetivo en una situación de ciberguerra.
Todos los expertos españoles y muchos extranjeros conocen la FOCA de Informática 64, vamos a ver que nos da sobre esta compañía:
Si examinamos todos los resultados encontraremos nombres de usuario, rutas internas, sistemas operativos y software usado internamente. Con esta información, al menos sabemos algunas de las cosas que tenemos dentro.
Otra forma para obtener información sobre lo que nos podemos encontrar la podemos sacar de los correos electrónicos de los empleados de la compañía objetivo, en las cabeceras de estos, podemos encontrar IP internas, los diferentes SMTPs por los que ha pasado el correo antes de llegar al destinatario, software y versión de los mismos en muchos casos, además se puede extraer el cliente de correo y versión de la cabecera X-Mailer de los que se puede deducir el sistema operativo usado. Lluis Mora, uno de los grandes en España en el mundo de la seguridad informática, ya presentó en 2007 una ponencia sobre esta técnica:
Existen numerosas formas de conseguir inteligencia sobre los sistemas y servicios que nos podemos encontrar más allá de los que se muestran a Internet.
Es importante resaltar que se ha de conocer donde atacar para conseguir tu objetivo, cualquier experto en seguridad sabe que atacar, por ejemplo, la página principal de FBI de nada sirve si no es que quieres cambiar la foto de Bin Laden por la de G.W. Bush, pero si quieres obtener información de su red interna, se tendría que entrar por otros sitios… Saber la IP por la que salen o entran los correos electrónicos por ejemplo:
Un estudio además puede reflejar las diferentes tecnologías que usa una entidad para conectarse entre sus diferentes centros y/o agentes, ya que pueden plantear un campo de batalla mejor como podrían comunicaciones vía satélite, comunicaciones móviles y los dispositivos que suelen usar.
Determinar previamente y concienzudamente, que sistemas atacar y desde donde es un requisito esencial para el éxito de una misión de ciberataque y entra perfectamente en la analogía de Campo de Batalla usado en la guerra convencional.
«Caballeros, examinen este territorio con cuidado, será un campo de batalla, y ustedes jugarán un papel en él».
Napoleon Bonaparte antes de la Batalla de Austerlitz
Artículo subido por
Leonardo Nve
2
comentarios
Enviar por correo electrónicoEscribe un blogCompartir con TwitterCompartir con FacebookCompartir en Pinterest
Etiquetas:
blitzkrieg,
campo de batalla,
ciberguerra,
estrategia,
inteligencia,
Tiger Team
viernes, 25 de marzo de 2011
Downgrade como Backdoor
Se conoce como “downgrade” (en español degradar, bajar de nivel) a la acción de sustituir un software por una versión anterior de sí mismo. Sería la acción contraria a un “upgrade” (actualización).
Este término es habitual del mundo de las video-consolas y es una técnica típica en el proceso de pirateo de las mismas ya que solo ciertas versiones de los firmwares son vulnerables a los ataques que permiten ejecutar código no original.
En el mundo de la seguridad informática “seria” este tipo de acciones ha sido considerado como poco importante y es raro encontrar menciones a las mismas, sin embargo pueden convertirse en una técnica muy efectiva para ocultar una backdoor (puerta trasera) o para burlar defensas basadas en listas blancas.
Los mecanismos de protección de ejecución basados en listas blancas se basan en controlar la ejecución de ciertos programas y prohibir la ejecución de cualquier binario a menos que este identificado en una lista de programas autorizados.
Un ataque basado en downgrade consistiría en utilizar versiones antiguas de programas autorizados por las listas blancas, pero que contienen vulnerabilidades conocidas que pueden ser explotadas.
De esta forma podemos ejecutar código indirectamente a través del exploit, pero el binario que se lanza inicialmente es legítimo.
Pero el uso más interesante de esta técnica es la creación de backdoors mediante el downgrade de binarios clave del sistema operativo.
Por ejemplo recordemos la famosa vulnerabilidad en el proceso de login (/bin/login) de los sistemas Solaris que permitía acceder al sistema como cualquier usuario sin conocer la contraseña.
Una forma sencilla de troyanizar el binario de login de un Solaris podría ser sustituir /bin/login por una versión antigua afectada por esta vulnerabilidad. De esta forma el intruso tendría un método fácil de acceder al sistema y el binario no resultaría excesivamente sospechoso:
• Una consulta al sistema de parches de Solaris (mediante el comando patchadd –p o mediante el comando showrev -p) no revelaría que el binario es vulnerable ya que inicialmente el parche que soluciona esta vulnerabilidad ya ha sido instalado.
• Un chequeo mediante la herramienta elfsign revelaría que el binario está firmado correctamente por el Solaris Cryptographic Framework.
• Una consulta a la Solaris Fingerprint Database también revelaría que el binario es original de Sun Microsystems y podría ser pasado por alto en un análisis forense.
Existiría el riesgo de que otro hacker utilizase también la vulnerabilidad para acceder al sistema, pero ¿Quién comprueba hoy en día vulnerabilidades tan antiguas?
Este término es habitual del mundo de las video-consolas y es una técnica típica en el proceso de pirateo de las mismas ya que solo ciertas versiones de los firmwares son vulnerables a los ataques que permiten ejecutar código no original.
En el mundo de la seguridad informática “seria” este tipo de acciones ha sido considerado como poco importante y es raro encontrar menciones a las mismas, sin embargo pueden convertirse en una técnica muy efectiva para ocultar una backdoor (puerta trasera) o para burlar defensas basadas en listas blancas.
Los mecanismos de protección de ejecución basados en listas blancas se basan en controlar la ejecución de ciertos programas y prohibir la ejecución de cualquier binario a menos que este identificado en una lista de programas autorizados.
Un ataque basado en downgrade consistiría en utilizar versiones antiguas de programas autorizados por las listas blancas, pero que contienen vulnerabilidades conocidas que pueden ser explotadas.
De esta forma podemos ejecutar código indirectamente a través del exploit, pero el binario que se lanza inicialmente es legítimo.
Pero el uso más interesante de esta técnica es la creación de backdoors mediante el downgrade de binarios clave del sistema operativo.
Por ejemplo recordemos la famosa vulnerabilidad en el proceso de login (/bin/login) de los sistemas Solaris que permitía acceder al sistema como cualquier usuario sin conocer la contraseña.
Una forma sencilla de troyanizar el binario de login de un Solaris podría ser sustituir /bin/login por una versión antigua afectada por esta vulnerabilidad. De esta forma el intruso tendría un método fácil de acceder al sistema y el binario no resultaría excesivamente sospechoso:
• Una consulta al sistema de parches de Solaris (mediante el comando patchadd –p o mediante el comando showrev -p) no revelaría que el binario es vulnerable ya que inicialmente el parche que soluciona esta vulnerabilidad ya ha sido instalado.
• Un chequeo mediante la herramienta elfsign revelaría que el binario está firmado correctamente por el Solaris Cryptographic Framework.
• Una consulta a la Solaris Fingerprint Database también revelaría que el binario es original de Sun Microsystems y podría ser pasado por alto en un análisis forense.
Existiría el riesgo de que otro hacker utilizase también la vulnerabilidad para acceder al sistema, pero ¿Quién comprueba hoy en día vulnerabilidades tan antiguas?
Artículo subido por
Ramon Pinuaga
2
comentarios
Enviar por correo electrónicoEscribe un blogCompartir con TwitterCompartir con FacebookCompartir en Pinterest
martes, 22 de marzo de 2011
OPSEC II: Redes Sociales, Libia y los Marines
En una de nuestras últimas entradas hablamos de OPSEC y de cómo internet ha cambiado la concepción tradicional de la seguridad de las operaciones y del personal. Veíamos como foros, blogs y redes sociales pueden ser utilizados por el adversario para recopilar información. No necesariamente tienen que exponerse directamente secretos, en ocasiones pequeños fragmentos de información pueden ir agregándose para completar una imagen más grande como si de un puzle se tratara.
Veamos un ejemplo, durante la evaluación de seguridad de operaciones "Purple Dragon" en la guerra de Vietnam se descubrió que los planes de vuelo de los bombarderos B-52 eran leídos por el enemigo y aprovechados para alertar de los inminentes ataques. Resulta que estos planes de vuelo desde Guam a Vietnam del Sur se presentaban al ARTCC de Saigón (Centro de Control de Tránsito Civil) en cumplimiento con las normas de la Organización Internacional de Aviación. Y como parte del procedimiento rutinario de la OACI, el ARTCC de Saigón retransmitía estos planes a su contraparte en Hanoi, Vietnam del Norte. Así varias horas antes de la B-52 llegaran a sus objetivos los movimientos de los bombarderos B-52 eran monitorizados a partir de los planes de vuelo. Si a esto añadimos los barcos espía que la URSS, aliado del Norte, tenía dispuestos cerca de las costas de Guam para interceptar las comunicaciones por radio, ciertamente Vietnam del Norte contaba con una importante ventaja estratégica.
Hoy en día para acceder a una información similar solo es necesario seguir en twitter a aficionados a la radioescucha que por todo el mundo están monitorizando el conflicto Libio y correlacionando esa información con la que aparece en medios de comunicación.
Este ejemplo, junto a la posibilidad de que los propios militares revelen inadvertidamente información son buenas muestras de cómo las redes sociales pueden llegar a tener un impacto sobre operaciones militares convencionales. Este mismo mes, en la revista SIGNAL de la AFECEA (Armed Forces Communications and Electronics Association) hemos podido saber hasta que punto algunos ejércitos están tomado en serio esta posibilidad y ya trabajan para minimizar la exposición de información en las redes sociales.
Se trata de un artículo titulado “U.S. Marines Creating Island for Network Defense” el General de Brigada Kevin Nally máximo responsable de Comando, Control, Computadoras y Comunicaciones (C4) del Cuerpo de Marines de los Estados Unidos expone los últimos retos en materia de tecnologías de la información a las que se enfrenta esta rama de las fuerzas armadas.
Según explica el mismo Nally, los Marines tienen un acuerdo informal con Facebook para eliminar cualquier página que viole la OPSEC, que revele información personalmente identificable de personal de los Marines o que intente suplantar a dicho personal. También informa que la oficina de relaciones públicas del Cuerpo de Marines monitoriza Facebook y en caso de necesidad tiene línea directa con la sede principal de la red social para solicitar la retirada inmediata de información.
Also in the information assurance realm, the Marines continue to refine their approach to social networking sites and other websites such as Wikileaks. Gen. Nally discloses that the Marines have an informal agreement with Facebook to remove any pages that violate operational security, reveal personally identifiable information on Marine Corps personnel or impersonate Marine Corps personnel for the purpose of scamming innocent users. The Marine Corps public affairs office monitors Facebook and can, if need be, contact Facebook staff to have a site removed. The Marines have held discussions with other social networking sites, but have not yet reached agreements with them. “We’ve partnered with Facebook so that if there are any operational security incidents that go on a Facebook account, we can contact Facebook headquarters, and they will pull that site immediately,” Gen. Nally says. “Social networking sites provide a morale value for our force, and it’s a great way for our forces to pass information back to their loved ones, but we also possess certain vulnerabilities that they need to be aware of—especially when it comes to operational security and personally identifiable information concerns.”
Según este mismo artículo, los Marines habrían estado en contacto con otras redes sociales para discutir acuerdos similares sin resultado por el momento. Podemos aventurar que quizá se trate de Twitter. Recordemos que recientemente Twitter se distinguió por su resistencia frente al gobierno norteamericano a entregar información de tres usuarios del sitio de microblogging que colaboraron con WikiLeaks.
Desde el punto de vista de los Marines sin duda ha sido un gran acierto conseguir este acuerdo con Facebook, pero visto desde el otro lado del atlántico también plantea varias interrogantes. ¿Acaso permitirá Facebook, una empresa estadounidense, un acuerdo similar con un gobierno o fuerzas armadas extranjeras, pongamos por caso España? ¿No están desprotegidos en este sentido nuestros militares en comparación con los militares norteamericanos? ¿Hasta qué punto podemos confiar nuestros datos en una red social que mantiene acuerdos “informales” con ramas de las fuerzas armadas de los EEUU?
Artículo subido por
Miguel A. Hernandez
1 comentarios
Enviar por correo electrónicoEscribe un blogCompartir con TwitterCompartir con FacebookCompartir en Pinterest
Etiquetas:
ciberinteligencia,
opsec,
redes sociales
sábado, 19 de marzo de 2011
Visitamos HOMSEC 2011
Esta semana se ha celebrado Homsec, el tercer salón internacional de tecnologías de seguridad y defensa. El equipo de Areópago 21 no podía dejar pasar esta oportunidad y nos hemos desplazado hasta IFEMA para ver las ultimas novedades del sector. Para quien no lo conozca Homsec es como describen sus organizadores “un salón específicamente dedicado a la aplicación de las tecnologías para la Defensa, Homeland Security y la Seguridad Publica”.
¿Qué encuentro en Homsec? Hagamos un pequeño repaso a lo que hemos podido ver:
Lo primero que llama la atención es que topamos cámaras de vigilancia de todo tipo, desde ocultas en mochilas, en forma de endoscopios para la exploración de lugares inaccesibles, lanzables como una pelota, FLIR (visión térmica) o de muy alta resolución para que no se escape ningún detalle y por supuesto instaladas en todo tipo de vehículos aéreos no tripulados. De estos aparatos UAV se podían admirar en todos los tamaños desde pequeñísimos helicópteros hasta otros más grandes como el ALO (Avion ligero de observación) de INTA.
No faltaban tampoco los vehículos blindados pensados para los retos actuales de las guerras asimétricas, diseñados para resistir minas, como el caso del Iveco LMV, y por supuesto dotados de estaciones de armas a control remoto para evitar exponer al tirador, presentes en las exposiciones de Navantia o KONGSBERG. Se notaba el interés planteado por el desafío de los explosivos tipo IED con la presencia del amplio stand del Centro de Excelencia Contra Artefactos Explosivos Improvisados o las cargas explosivas para el desminado presentadas por Santa Bárbara Sistemas/General Dynamics.
Encontramos también los equipos para respuesta a incidentes NRBQ (Nuclear, Radiológico, Biológico y Químico) , destacable la Red de Alerta Radiológica, presentada por Indra, sobre todo ante la situación que se está viviendo en estos momentos en Japón. Esta red está en servicio actualmente para la dirección general de protección civil y cuenta con 902 estaciones de medida radiológica repartidas por toda España.
Se vieron así mismo los más modernos equipos de radio comunicaciones, mientras que para aplicaciones policiales o de seguridad se planteaban principalmente soluciones basadas en TETRA como los presentados por Teltronic, los fabricantes del sector de la defensa, como Harris, optan más por sus propios protocolos o la compatibilidad con los estándares STANAG. En cuanto al cifrado se ofrecían tanto AES como cifrados específicamente militares OTAN o NSA Type I. En todos los casos se nota la tendencia hacia el uso enlaces IP como sistema estandarizado para las conexiones de datos.
También estaban presentes diversas unidades y ejércitos de nuestras fuerzas armadas, así como policía nacional y guardia civil, que presentaban los últimos sistemas con los que cuentan, ya fueran armas, vehículos, equipos o herramientas.
Como ya explicamos en nuestra entrada de presentación aunque aficionados a los temas de defensa, nuestro sector profesional es el de la seguridad informática desde nuestro particular punto de vista no podemos dejar de hacer algunos comentarios.
Hemos podido ver gran cantidad de sistemas basados en PC , ya fueran equipos normales, equipos portátiles rugerizados (pudimos ver mucho toughbook) y también equipos embebidos. En la práctica totalidad de los casos funcionan con versiones del sistema operativo Windows, aunque tenemos la excepción de Sainsel que presentaba su Sistema de Navegación Táctica WECDIS basado en Linux que según nos contaban sustituirá a las cartas en papel y al lápiz en los puentes de mando de los submarinos españoles.
Algo que nos llamo poderosamente la atención es que si uno miraba detenidamente los equipos expuestos, lo mismo daba que fuera un sistema de cámaras que la estación receptora de un UAV, se podía encontrar en más de una ocasión con un conector Ethernet. Por supuesto la tendencia hacia IP, interfaces web y protocolos abiertos hace a los equipos más operativos y fácilmente integrables. ¿Pero acaso no está también llevando una posible ventana de vulnerabilidad a equipos que tradicionalmente no serian atacables por medios informáticos? ¿Se habrán preocupado todos esos fabricantes de realizar un análisis de vulnerabilidades riguroso?
En cuanto a la temática de ciber ciertamente pudimos ver poca cosa, parece haber poca concienciación en el sector por las vulnerabilidades intrínsecas a las nuevas tecnologías. Únicamente en el stand de Thales se podían encontrar los folletos de su solución Cybels, mientras que en otro stand se hacia alguna mención a las ciberamenzas en uno de los videos promocionales que reproducían, curiosamente ilustrado por una imagen de un grupo personas de Anonymous (sin comentarios).
El apartado de formación era algo mejor, encontrándonos a AMETIC publicitando la V edición de su Máster en Dirección y Gestión de Seguridad de la Información , mientras que Grupo Atenea promocionaba su curso “Inteligencia Económica” que incluye un modulo sobre seguridad de la información. Estas propuestas son sin duda interesantes para niveles de mando, directivos, analistas, responsables de IT, etc. aunque quizá se queden algo cortos para personal digamos más técnico u operativo.
Estas pocas empresas que promocionaban ciberservicios enfocaban únicamente la parte de la protección y respuesta, ciertamente nos hubiera gustado que el sector de seguridad informática en su vertiente enfocada a defensa hubiera estado más representado y que se hubieran propuesto no solo capacidades de ciberprotección si no también ciberofensivas.
En el apartado de aplicaciones o soluciones específicas para inteligencia, tradicional o ciber, tampoco encontramos demasiada presencia, siendo únicamente reseñable el stand de i2, el fabricante de software para análisis y fusión de información, como el ampliamente usado por las fuerzas de seguridad Analyst Notebook.
En cuanto a las soluciones de control de acceso biométrico sobresale que los productos que encontramos empiezan a aplicar contramedidas contra las posibles suplantaciones, así Ganhertec exponía su sistema basado en reconocimiento de Iris que según explican mediante “la aplicación de la tecnología IR en camaras de alta definición evita cualquier intento de suplantación de identidad a través del uso de lentillas”. Saiwall Secure por su parte ofrece un sistema que captura una imagen del entramado de venas de la palma de la mano, lo que evita los rechazos de los sistemas basados en huella digital ocasionan con un pequeño porcentaje de usuarios, al tiempo que evitan ataques como los “falsos dedos de gelatina”.
Por último, antes de abandonar el salón no pudimos evitar comprobar si existían redes wifi , y para nuestra sorpresa entre múltiples wireless de la propia IFEMA, y unos típicos (y también anónimos) essid “dlink” o “linksys” nos encontramos con la red “LEON131” que se correspondía con la estación de comunicaciones móvil LEON , con ese mismo numero de vehículo, que se encontraba en el stand de la Unidad Militar de Emergencias.
En definitiva una muy interesante y entretenida visita, aunque nos vamos con la sensación de que todavía queda mucho por andar para cerrar la brecha entre el sector de defensa tradicional y las nacientes capacidades de ciberdefensa.
Artículo subido por
Miguel A. Hernandez
2
comentarios
Enviar por correo electrónicoEscribe un blogCompartir con TwitterCompartir con FacebookCompartir en Pinterest
Etiquetas:
ciberguerra,
ciberinteligencia,
defensa,
homsec
lunes, 14 de marzo de 2011
OPSEC en los tiempos de la web 2.0
En términos militares se conoce como OPSEC (Seguridad de las operaciones) al proceso que identifica si las acciones propias pueden ser observadas por los sistemas de la inteligencia del adversario, con el fin de determinar si la información obtenida que se podría interpretar de ella puede ser útil, y después determina las medidas que eliminan o reducen la explotación del adversario de la información propia.
El concepto moderno de OPSEC nació durante la guerra de Vietnam al observar las fuerzas armadas norteamericanas que algunas de sus operaciones no tenían el éxito esperado, por ejemplo cuando una zona iba a ser bombardeada o ocupada el enemigo desaparecía misteriosamente, era como si el Vietcong conociera de antemano las intenciones norteamericanas. Descartada la posibilidad de que el enemigo estuviera descifrando las comunicaciones o que contara con espías de suficiente nivel se llego a la conclusión de que deducía el lugar y momento de las operaciones de la información que las propias fuerzas revelaban de forma inadvertida. Dicho de otro modo, pequeños fragmentos de información aparentemente inocua eran combinados para predecir las operaciones militares. Un programa con nombre en código Purple Dragon confirmo esta posibilidad, implementadas las medidas recomendadas por dicho estudio la efectividad de las operaciones mejoro de forma sustancial. Por esta razón histórica las unidades militares dedicadas a OPSEC suelen utilizar un dragón purpura como parte de sus emblemas. (PURPLE DRAGON: The Origin and Development of the United States OPSEC Program)
Un ejemplo clásico de OPSEC consiste en, pongamos por ejemplo, determinar el estado una organización simplemente observando el parking si este es visible desde el exterior. Variables como si han aumentado el tiempo que las plazas permanecen ocupadas durante la jornada laboral o especialmente fuera de la misma durante la noche o días festivos, pueden revelar una situación de alerta o trabajo por encima de lo normal.
Un problema para la implementación de una política OPSEC es determinar qué datos resulta peligroso que sean expuestos y cuáles no, o cuales es inevitable que puedan ser observados. Normalmente se trata de información que no está clasificada y es muy difícil marcar el limite. Un excesivo secretismo, compartimentalización, etc. pueden en ocasiones ser perjudiciales en cuanto que ralentizan las operaciones, impiden los trabajos normales o obstaculiza la normal comunicación interna y externa de la organización.
Y esto nos lleva a nuestro actual mundo de redes sociales como twitter o facebook. Muchos miembros de fuerzas armadas, fuerzas y cuerpos de seguridad del estado, empleados del sector de la defensa, etc. participan en este tipo de sitios o en foros tradicionales, ya sean de temática general o de temática específicamente militar. La mayoría actúan siguiendo los principios de OPSEC cuando no de simple sentido común y no suelen revelar información critica, pero como hemos visto en ocasiones no es necesario descubrir directamente los secretos, un análisis cuidadoso de otros indicadores puede revelar información útil en el ámbito militar o de seguridad interior: ya sea en operaciones en marcha, o de capacidades de los sistemas propios.
Un perfecto ejemplo sería el caso de Dozerf22 , apodo usado en un foro de aviación por un teniente coronel y piloto de F22 , el más moderno caza furtivo de la USAF. Este militar fue investigado por haber realizado más de 300 post, respondiendo a preguntas de todo tipo sobre capacidades y funcionamiento del avión.
En una ironia del destino, un estudio interno de OPSEC sobre este caso, "CyberOPSEC: An F22 Case study", en el que se le ponía como ejemplo a no seguir, y que no estaba pensada para ser revelado públicamente, acabo publicado en internet.
Artículo subido por
Miguel A. Hernandez
0
comentarios
Enviar por correo electrónicoEscribe un blogCompartir con TwitterCompartir con FacebookCompartir en Pinterest
Etiquetas:
ciberinteligencia,
opsec,
redes sociales
domingo, 6 de marzo de 2011
BIX - Byte Information eXchange
Muchos tal vez perciban los temas que tratamos en este Blog como nuevos o novedosos. Pero lejos de la realidad, las bases de estos conceptos se gestaron hace muchos años en algunas comunidades online que ya casi nadie recuerda.
Hay muy poca literatura (especialmente en castellano) sobre estas comunidades primitivas, donde se empezó a plantear que la información y la informática podían ser a la vez una herramienta y un arma. Una de las más épicas fue BIX.
BIX, por sus siglas Byte Information eXchange, fue un servicio online (tipo BBS) creado en 1985 por la popular revista sobre informática Byte.
BIX era accesible originalmente solo mediante modem desde los Estados Unidos, pero con el tiempo también fue posible acceder a través de la red X.25 Tymnet. Esto la hizo muy popular entre gente que viajaba a menudo (diplomáticos, políticos, militares, empresarios, millonarios) ya que esta red tenia puntos de acceso repartidos por casi todo el mundo y era accesible también desde otras redes X.25 internacionales.
Desde sus espartanos menús de texto era posible acceder a las últimas noticias, a multitud de software y a unos foros muy activos, donde se podía charlar directamente con verdaderos gurús en materias técnicas punteras. El no va más para aquella época.
Se llego a definir a BIX con el lema "I have more information in one place than anybody in the world", frase atribuida al periodista y escritor de ciencia ficción Jerry Pournelle. Este autor casualmente ha escrito diversos estudios sobre estrategia y tecnología, proyectos tecnológicos y requisitos tecnológicos para la defensa.
Como podréis imaginar, debido a esta peculiar clientela, BIX se acabó convirtiendo rápidamente en el equivalente online al "Café de Rick" de la película Casablanca. Un lugar donde se reunían habitualmente buscavidas, espías y hackers, para intercambiar turbios secretos o para obtenerlos.
Sus foros fueron probablemente uno de los primeros sitios donde surgieron conceptos tales como ciber-inteligencia o ciber-guerra, aunque por aquella época ni siquiera se utilizasen estos términos.
Otro de los factores que determino su exclusividad fueron las caras tarifas de uso, que solo podían permitirse pagar los más adinerados o como no, intentar burlar algunos hackers.
Curiosamente BIX también esta asociada al origen del concepto de troyano (o caballo de troya) informático en 1985: "Durante ese año se empezaron a reportar en el BIX, la presencia de programas que ingresaban en forma subrepticia a los sistemas y por lo cual atinaron a denominarlos Troyan Horses (caballos de Troya), en alusión al episodio de la famosa obra épica griega."
Debido a la popularización de Internet, su utilidad disminuyo y la peculiar comunidad formada a su alrededor se acabó diseminando. Provocando su cierre definitivo en 2001. Pero la semilla ya estaba plantada.
Hay muy poca literatura (especialmente en castellano) sobre estas comunidades primitivas, donde se empezó a plantear que la información y la informática podían ser a la vez una herramienta y un arma. Una de las más épicas fue BIX.
BIX, por sus siglas Byte Information eXchange, fue un servicio online (tipo BBS) creado en 1985 por la popular revista sobre informática Byte.
BIX era accesible originalmente solo mediante modem desde los Estados Unidos, pero con el tiempo también fue posible acceder a través de la red X.25 Tymnet. Esto la hizo muy popular entre gente que viajaba a menudo (diplomáticos, políticos, militares, empresarios, millonarios) ya que esta red tenia puntos de acceso repartidos por casi todo el mundo y era accesible también desde otras redes X.25 internacionales.
Desde sus espartanos menús de texto era posible acceder a las últimas noticias, a multitud de software y a unos foros muy activos, donde se podía charlar directamente con verdaderos gurús en materias técnicas punteras. El no va más para aquella época.
Se llego a definir a BIX con el lema "I have more information in one place than anybody in the world", frase atribuida al periodista y escritor de ciencia ficción Jerry Pournelle. Este autor casualmente ha escrito diversos estudios sobre estrategia y tecnología, proyectos tecnológicos y requisitos tecnológicos para la defensa.
Como podréis imaginar, debido a esta peculiar clientela, BIX se acabó convirtiendo rápidamente en el equivalente online al "Café de Rick" de la película Casablanca. Un lugar donde se reunían habitualmente buscavidas, espías y hackers, para intercambiar turbios secretos o para obtenerlos.
Sus foros fueron probablemente uno de los primeros sitios donde surgieron conceptos tales como ciber-inteligencia o ciber-guerra, aunque por aquella época ni siquiera se utilizasen estos términos.
Otro de los factores que determino su exclusividad fueron las caras tarifas de uso, que solo podían permitirse pagar los más adinerados o como no, intentar burlar algunos hackers.
Curiosamente BIX también esta asociada al origen del concepto de troyano (o caballo de troya) informático en 1985: "Durante ese año se empezaron a reportar en el BIX, la presencia de programas que ingresaban en forma subrepticia a los sistemas y por lo cual atinaron a denominarlos Troyan Horses (caballos de Troya), en alusión al episodio de la famosa obra épica griega."
Debido a la popularización de Internet, su utilidad disminuyo y la peculiar comunidad formada a su alrededor se acabó diseminando. Provocando su cierre definitivo en 2001. Pero la semilla ya estaba plantada.
Artículo subido por
Ramon Pinuaga
1 comentarios
Enviar por correo electrónicoEscribe un blogCompartir con TwitterCompartir con FacebookCompartir en Pinterest
Suscribirse a:
Entradas (Atom)