NIST: Security Controls for Information Systems

“…Through the process of risk management, leaders must consider risk to US interests from adversaries using cyberspace to their advantage and from our own efforts to employ the global nature of cyberspace to achieve objectives in military, intelligence, and business operations… “

“…For operational plans development, the combination of threats, vulnerabilities, and impacts must be evaluated in order to identify important trends and decide where effort should be applied to eliminate or reduce threat capabilities; eliminate or reduce vulnerabilities; and assess, coordinate, and deconflict all cyberspace operations…”

“…Leaders at all levels are accountable for ensuring readiness and security to the same degree as in any other domain…"

-- THE NATIONAL STRATEGY FOR CYBERSPACE OPERATIONS

OFFICE OF THE CHAIRMAN, JOINT CHIEFS OF STAFF, U.S. DEPARTMENT OF DEFENSE

De esta guisa están los americanos en lo que a seguridad en los sistemas de la información respecta. Hace unos días el NIST publicó un interesante documento (NIST Special Publication 800-53) que describe a grandes rasgos los principales controles de seguridad que empresas de todos los sectores (banca, salud, defensa, etc.) deberían implementar en sus sistemas de información si quieren eliminar o mitigar las múltiples amenazas que su uso generan. La publicación de este paper me llama particularmente la atención ya que apenas hace 3 meses Obama anunciaba a bombo y platillo la comisión de un cuerpo militar especializado para el ciberespacio liderado por el "cyberzar" (si bien el NIST lleva muchos años publicando documentos de Seguridad, este en concreto parece enfocado para los Estados Unidos).

El paper habla y habla sobre controles de seguridad, sus clases (técnicos, operacionales, de gestión, mixtos), a que familia se pueden asociar (a mi me ha dado la impresión de que eran subfamilias de los 11 grandes dominios de la ISO 17799 - ISO 27000), habla de la calidad de los controles, su ciclo de vida, su gestión e indicadores así como las tareas de día a día a las que hay que dar especial relevancia para que el “proceso de la seguridad” no se nos quede atrás:

- Evaluación de lo que los controles nos aportan (o nos dejan de aportar).

- Requisitos de seguridad cambiantes.

- Nuevas amenazas, vulnerabilidades y vectores de ataque.

- Nuevas tecnologías.

Todo ello con un único objetivo, gestionar el riesgo. Para ello proponen un proceso muy familiar:

Que incluye un punto bastante interesante, “la autorización de los sistemas de información”, esto significaría que no permitiríamos entrar en producción sistemas que carecen de controles de seguridad o que representan un nivel de riesgo no aceptable. Si, esto es tan lógico que no se cumple en casi ninguna organización, por eso me llama la atención.

En resumen un documento al que merece la pena echar un vistazo, si eliminamos los Anexos son apenas 60 folios y de los anexos los más interesantes son:

- Anexo F: Catálogo de Controles de Seguridad (amplísimo)

- Anexo I: Controles en Sistemas Industriales (controles de seguridad para sistemas SCADA, recomendable también)

Lecturas para la playita :)

Firewall Suizo

Jamon de York, mantequilla, un firewall y pan de molde, eso sí es un buen sándwich.

Respuesta: Sólo si el firewall es Suizo.

Hoy vamos a hablar de una tecnología nueva en el mundo de la Seguridad de la Información, concretamente en el capítulo de “Seguridad de las comunicaciones”.  Exacto, vamos a hablar de los Firewall (y no, no me refiero a la película de Harrison Ford). ¿Por qué digo nueva? Bueno, principalmente por que considero que estos dispositivos tienen que estar al día siempre. Un firewall tiene que ser tan nuevo como los servicios de nuestra empresas, o mejor dicho, sus políticas de seguridad.

Repasemos, un cortafuegos sirve (a muy grosso modo) para separar redes distintas dejando tan solo los flujos de comunicación que consideremos legítimos o válidos. Por ejemplo, el firewall que nos separe del mundo Internet tendrá prohibido todo el tráfico de entrada, excepto algún servicio que publiquemos al mundo, llámese mi página Web. Lo mismo ocurrirá con los flujos de salida. Estos filtrados pueden hacerse de muchas formas dependiendo del nivel al que trabaje el cortafuegos:

1.- Filtrado de paquetes (1ª generación): Analiza los paquetes de entrada y ver si hay alguna regla definida que los deje pasar (suponemos que todo se rechaza por defecto). Vulnerables a IP Spoofing. Nivel 3 OSI.

2.- Filtrado por estado (2ª generación): Estos cortafuegos mantienen “en memoria” el rastro de cada conexión que se permite, detectando comportamientos anómalos o sospechosos como un ataque DOS. Pueden llegar al Nivel 7 OSI.

3.-  Proxy – Firewall (3ª generación): Trabajando en la capa de aplicación estos dispositivos son capaces de inspeccionar el tráfico de protocolos y servicios que trabajan a este nivel, detectando posibles exploits, comandos no permitidos, etc.

4.- Kernel Proxy – Firewall (4ª generación): Incluyen inspección profunda de paquetes, tecnología de detección / prevención de intrusiones, etc.

 Independientemente de que generación sea nuestro firewall, tendrá una base de reglas que a buen seguro habrá que revisar periódicamente. Estas reglas deben basarse en unos pocos principios básicos:

-          Todo se rechaza por defecto.

-          Solo se autoriza tráfico para servicios reconocidos en la organización.

-          La regla debe ser tan restrictiva como sea posible, a nivel de puertos (conociendo los puertos que manejan los servicios) y a nivel de IP (conociendo quienes van a demandar estos servicios).

-          Si un servicio se da de baja o cambia, deben cambiar o darse de baja las reglas asociadas al servicio (llamémosle gestión de cambios controlada).

Si no trabajamos con estos principios, nos encontraremos con cositas como esta:

Tiene pinta de ser un FWSM suizo. 

En mi experiencia el principal problema que he encontrado ha sido el de reglas obsoletas, que cubren servicios inexistentes o para máquinas que han migrado o simplemente desaparecido. Una solución es establecer un periodo de caducidad para las reglas, de tal forma que una alerta te avise el día que estas caduquen, no obstante esto se puede volver inmanejable en organizaciones que tengan decenas de firewall y por tanto cientos de reglas. No es un problema de fácil solución, la caducidad es una buena idea ya que obliga a revisar lo implantado, ahora bien, ¿Cuáles revisar de todas las decenas que pueden caducar en un día sin que el  administrador se vuelva loco? Se me ocurre comenzar por aquellas reglas por las que no pasa tráfico, estableciendo mecanismos como la baja automática en aquellas que no se produce un “match” durante 3 meses, siendo ese periodo configurable según la criticidad de las redes que se separan, no es lo mismo una red de ofimática que una de gestión, ni cuanto menos una red de datos (y todo ello sin provocarte DOS).

Mantener unas políticas acordes a nuestra arquitectura de red es crítico para la seguridad de nuestras redes, establecer los controles para verificar que se cumplen las políticas, también. Es la única forma de que nuestro queso tenga los agujeros que necesita, ni uno más, ni uno menos.

Más info en:

http://www.conectronica.com/200812052004/Nuevos-enfoques-en-el-an%E1lisis-de-la-tecnolog%EDa-firewall-componente-esencial-para-la-seguridad-red.html

http://en.wikipedia.org/wiki/Firewall

Salu2!! (Y cuidado en la vuelta de vacas xD)

Rosillo Project (I)

¿Sabeis la diferencia entre un zombie de Resident Evil y un infectado de 28 dias después? Pues es la misma que la que hay entre un troyano y un "programa de monitorización remota", es más, si sois amantes de las herramientas de auditoría sabreis que todos los antivirus detectarán un troyano (u otros) en "Cain.exe" y similares.

A raíz de lo que yo bauticé como "el incidente", del cual os hablaré en próximas entradas, surgió el llamado Rosillo Project, el cual tenía como objetivo tener un paquete preparado con un troyano digamos "cómodo" de utilizar, indetectable para mi Windows Vista (y su antivirus) y que fuese incrustado en cualquier tipo de archivo de uso diario, lease .doc, .mp3, .ppt, etc.

Unas pocas horas más tarde tenía un completo listado de herramientas, de las disponibles para todo el mundo, y me encontraba configurando:

Con esto no se juega!!

Este troyano inverso, que no es más que un troyano donde el servidor se instala en "tus" clientes, y tu recibes la información que ellos te mandan, este en concreto incluye un keylogger, permite obtener las contraseñas de Windows por WSAM, y un montón más de cosas que os podeis imaginar, encima podeis tener ordenados todos vuestros "clientes" en un listado y observar en tiempo real su tráfico.

Configuración de las conexiones.

Como veis, un troyano para script kiddies, (por suerte esto lo sabemos, tu, yo y google). Llegado este punto ya tenemos la herramienta con que "monitorizar" todos nuestros equipos, sin embargo a poco que estéis terminando de bajaros el .rar, vuestro antivirus se iluminará más que Raccon City cuando Umbrella lanza el misil nuclear (por volver al tema de los infectados, perdon zombies), por suerte existen herramientas como...