Análisis de Vulnerabilidades y Arquitectura de Seguridad

Patching
Encontrar y parchear vulnerabilidades es parte del proceso contínuo de la seguridad IT. Parte integral de lo anterior es la implementación de un mecanismo de actualización regular y automático de todos los sistemas a cargo del sysadmin (WSUS en servidores/clientes Windows, updates regulares vía CRON en Linux/*nix, etc.). Eso incluye servidores, máquinas cliente, electrónica de red y también cualquier dispositivo pasible de ser actualizado, típicamente sistemas embebidos (cámaras IP - wifi o no - lectores de tarjetas, lectores RFID, etc.).

Claro, esta la disyuntiva de que un agresor solo necesita acertar una sola vez y puede equivocarse (relativamente) muchas veces; el sysadmin se encuentra en el caso exactamente inverso.

El modo correcto de verificar la seguridad de un sistema es demostrarla de hecho. Ello implica realizar auditorías de seguridad, en particular con respecto a las vulnerabilidades de sistemas, se debe realizar análisis de vulnerabilidades (vulnerability assessment).


Nessus
Aunque en la actualidad, el análisis de vulnerabilidades es un proceso altamente automatizado, todavía puede encontrarse excelentes herramientas manuales, una de las mejores es Nessus.

Soporta los sistemas operativos Linux, FreeBSD, Solaris, MacOSX y Windows. Una vez instalada es de simple uso; se basa en realizar ataques simulados intentando explotar vulnerabilidades conocidas, y luego informar. Después solo queda parchear la/s vulnerabilidades encontradas.

Nessus agrupa la vulnerabilidades en tres clasificaciones:
- Agujeros de Seguridad
- Avisos de Seguridad
- Notas de Seguridad

Luego cada resultado clasificado recibe una valuación según su riesgo (Crítica, Seria, Alta, Media, Baja, ninguna). Finalmente se llega a la etapa de intervención, donde el analista valora subjetivamente los riesgos informados con respecto a la organización y su arquitectura particular.

Cada vulnerabilidad encontrada puede incluir links al BugTraq ID, el número CVE (Common Vulnerabilities and Exposures), y el ID Nessus. Cada uno puede proporcionar información adicional sobre las vulnerabilidades (por ejemplo si existe un parche o no para ella, y cual es el nivel/fecha/srv.pack que la cierra).

El análisis de los informes de Nessus es tedioso, pero esencial.Nessus genera informes en HTML, y es una recomendación añadir notas al mismo para posteriores revisiones.


Debilidades en la Arquitectura de Seguridad
Solucionar la/s vulnerabilidades no termina en parchear/actualizar el sistema. Una vulnerabilidad puede no mostrar una debilidad en la estrategia general de seguridad:

* Una política de firewalling deficiente (un puerto/protocolo abierto, protocolos baneados cerrados desde "afuera" pero que pueden iniciar sesiones desde "adentro" por ejemplo)

* Una política de filtrado capa 7 muy abierta (sesiones/túneles/conexiones SSL que pueden transmitir/recibir (GBs) datos durante tiempo tiempos muy prolongados, cuando no hay una VPN SSL disponible por ejemplo)

* Una política de ruteo permisiva en capa 3 (no se puede llegar a un server "B" desde una red XX.XX.XX.XX, pero con acceso por X protocolo - HTTP,FTP,SSH,etc. - sí se llega a otro server "A" y éste puede llegar a "B"),

* Una política de capa 2 permisiva (hosts innecesariamente visibles entre VLANs, etc.)

* Una relación conflictiva entre la política de capa 3 y capa 2,

* Servicios con configuraciones por defecto (banners, etc.) y/o con configuraciones muy abiertas con funcionalidades que no se utilizan en la organización (por ejemplo un servidor de mensajería con plugins de enlace a servicios Yahoo, MSN, o similares, prohibidos por la política de la organización pero (mal) permitidos en la política de firewalling/filtrado).

* Un servidor en producción, no depurado desde el testing con "restos" (servicios, puertos, etc.),

* IDS/IPS con cientos de entradas de logs de falsos positivos derivados del uso regular y constante de alguna herramienta/funcionalidad desde alguna IP/MAC que no debería ser monitoreada en ese puerto/protocolo/servicio/rango horario,etc.; dificultando seriamente el trabajo de los analizadores de logs y/o el análisis manual, etc.etc.

Una auditoría de seguridad debería ser el trabajo de un equipo y/o de un experto con eximias capacidades y experiencia (en lo posible), sino podemos quedarnos con verificaciones mera y técnicamente perimetrales.