5 de diciembre de 2009

Trusted Network Connect

Cuando a principios de Octubre hablamos de Trusted Execution / Trusted Plataform dentro del marco de arquitectura de procesadores segura dimos alguna pincelada de un término que a día de hoy es crucial en toda corporación, Trusted Network Connect.

Actualmente la ubicación del puesto de trabajo es dinámica, y cada vez lo es mucho más. Nuestro personal está sentado en sus oficinas, pero también está desplazado en un cliente y requiere conectividad contra servicios y recursos que tiene en su puesto de trabajo, también viaja y probablemente tanga una BlackBerry o similares con la que necesita revisar el correo corporativo, esto es solo la punta del iceberg: No todos los empleados son iguales, hay desarrolladores, gente de sistemas, comerciales, jefes, gerentes y directores. Becarios recién contratados y externos, muchos externos, ya que también hacemos Outsourcing. Este personal ajeno también necesita conectividad para dar su servicio, es más, probablemente lo hará todo desde sus propias oficinas o quizás tengamos un hueco para ellos en nuestra empresa.

El perímetro de la organización es maleable y se corre el riesgo de que no se puede dar una solución de acceso a sistemas y servicios segura y robusta. En definitiva, un problemón para los arquitectos de red y el personal de seguridad que requiere de soluciones. Es aquí cuando entran en juego los accesos de confianza.

El Trusted Computing Group da una serie de directrices genéricas independientes de la tecnología para orientarnos un poco en como deben ser esos accesos.

Network Access Control

Este concepto simplificado al extremo trata de que un “cualquiera” que llegue a tu organización no sea capaz de enchufarse a tu red bien, por que ahí hay una roseta vacía o bien por que la Wifi está abierta a invitados. Esto hoy en día es sencillamente intolerable, pero el NAC va mucho más allá definiéndose como un conjunto de medidas de seguridad que nos aseguren que solo accederá a nuestra red aquel que tenga los correspondientes permisos y cumpla con un mínimo de políticas de seguridad, NAC es:
  • 802.1X
  • DHCP
  • VPN
  • Cumplimiento GpO.
  • Actualizaciones y parches del Sistema Operativo.
  • Antivirus actualizado y homologado.
Pero esto no es todo, debemos ser capaces de proveer u
na infraestructura de acceso que a parte de cumplir con todo lo anterior sea capaz de dar acceso a los recursos necesarios según el perfil / rol del usuario, esto se debe apoyar de forma indudable en una arquitectura de red segura (con todo lo que implica a nivel de VLANs, firewall, routing, etc.). Además los permisos de acceso deben ir alineados con los recursos accedidos, probablemente una persona de desarrollo necesite ser administrador en su equipo y trabajar en un entorno aislado alejado de producción, de igual forma se debe evitar que un administrador de BBDD sea capaz de modificar los datos que gestiona, siendo esta capacidad exclusiva de sus usuarios (esto creo que lo llamaban segregación de funciones).

Ahora bien, todo esto no es nuevo, las conexiones de confianza pueden llegar mucho más lejos y alcanzar a todos los dispositivos de mi red, impresoras, telefonía VoIP, cámaras de seguridad, etc. cuya actividad también deberá estar regulada. De manera adicional se instalarán sondas, IDS/IPS que controlen y detecten la actividad de los dispositivos / usuarios en la red, aquí es cuando surge un elemento adicional, el IF-MAP (Interface Metadata Access Point) Para no perdernos echemos un ojo a la siguiente imagen:


En la misma tenemos nuestros clientes “de confianza”, seguridad a nivel de red 802.1x, switches, routers, radius, firewalls, Policy Decision Point y, como capa adicional antes de llegar a los controles de seguridad aparece IF-MAP, ¿Qué es esto?, Con IF-MAP tenemos un protocolo cliente – servidor basado en XML y que utiliza SOAP + HTTPS. Su misión principal es recolectar datos de los dispositivos de red, metadatos que nos den una idea de quien es, a qué accede, que está solicitando y haciendo, etc. La estructura de los mensajes que maneja es la siguiente:
  • ip-adddress (v4 or v6)
  • mac-address
  • identity aik-name:
  1. dns-name
  2. email-address
  3. kerberos-principal
  4. trusted-platform-module
  5. username
  6. sip-uri
  7. tel-uri
  8. other (vendor defined)
  • access-request
  • device
Como imagináis esto abre un abanico de posibilidades a la hora de controlar los accesos a la red que delega en el Metadata Access Point controles de seguridad que en tiempo real detectan accesos inapropiados, dispositivos que tratan de acceder a recursos que no deben, alarmas (falsas o no) alineadas con el resto de dispositivos, etc. No han sido pocos los fabricantes que se han subido al carro del IF-MAP, en esta pequeña diapositiva se pueden ver algunos de ellos.

El paradigma de acceso a la red seguro con un servicio de confianza está cambiando continuamente, hay mucha tela para cortar aquí ya que estamos hablando de confianza extremo a extremo, multitud de capas de acceso, ingeniería de conocimiento y redes bayesianas para decidir cómo actuar sobre un dispositivo, etc. Por suerte hay mucha información disponible en la red, herramientas Open Source como FreeRadius, OpenSea 802.1X, el proyecto libTNC, etc.

Precaución, amigo conductor (happy bridge).

Salu2!

1 de diciembre de 2009

Black Screen Of Death

Hay días -muy pocos por suerte- en que es peor el remedio que la enfermedad. Esto también se aplica en el mundo de la Informática y concretamente en el Software no puede ser obviado. Parece ser que el último boletín de parches de Microsoft provoca un Black Screen,,, pero sin death (BlSoD), es decir si el usuario hace Ctrl + Alt + Sup puede acceder al administrador de tareas y ejecutar algunas acciones. Esto obviamente puede ser un dolor de cabeza para los técnicos de microinformática, administradores, etc.

Al parecer en la publicación de parches de seguridad del 10 de Noviembre se modifican reglas ACL de Windows que impiden el acceso al registro e invalidan determinadas entradas del mismo, estos parches tenían como objetivo corregir la vulnerabilidad MS09-065 donde se detectaba un bug en el kernel de Windows (XP, Vista, 7, Server 2003, Server 2008), ahora bien el parche provoca el temido BlSoD en algunos equipor por lo que llega el eterno dilema, ¿actualizar o no actualizar?, ¿tapamos unos agujeros para que nos salga un fuego?

Está claro que la única solución es alcanzar un equilibrio aristotélico, asumimos los riesgos durante un pequeño periodo de tiempo equivalente a probar las actualizaciones en un entorno aislado, comprobar que no existen incompatibilidades con nuestro software, etc. Después parcheamos y carretera.

Si por casualidad habéis tenido este problema la empresa que lo denunció (Prevx) ha publicado un pequeño parche que lo soluciona (¡antes que Microsoft!), yo no lo he probado (quizás no actualizo tan a menudo :-( ) pero si os animáis está aquí.

Adjunto imagen del comentado BISOD, no confundir con las típicas postales de “Cuenca de noche” o “Tenerife de noche” -->

Salu2!

NdA: Como habréis visto a través de meneame parece ser que al final la "culpa" de estos pantallazos no la tenían las actualizaciones, tal y como relata la gente de Prevx tiene que ver con la manera en que Windows almacena los Strings en el registro de Windows, requiriendo un carácter Null para finalizar el string, si ese carácter no aparece pueden surgir errores al leer los datos y no poder determinar cuando finaliza la cadena, de ahí el BlSoD. Las actualizaciones no están directamente relacionadas, lo que no significa que cierto software que acceda de forma incorrecta al registro provoque estos errores, lo que sí se ha demostrado es que el parche de Prevx funciona,,, en SysInternals tenéis un programa-demo de este error.