ARC309 - Security is a feature

Vale... no debería decir esto pero.... vaya tostón de sesión que fue esa.

Seguramente la culpa no fue del ponente, quizá fue que mis expectativas al respecto de la sesión no se correspondieron a la realidad.
Antes que nada, los que sepáis catalán pasaros por el blog que hicimos en raona cuando asistimos al Enterprise Architect Summit 2005. Una vez estéis allí le dais a Ctrl+F y buscais "Workshop: Developing and Enforcing Security Policies" y iréis a parar un post mío sobre una sesión de seguridad que se dio en el EAS2005. Pues bien, el 80% de la sesión del EAS2005 se repitió en esta del tech·ed. La verdad es que salí con una sensación de deja-vu (y buscando paredes que no existían), hasta que recordé donde había oído antes lo mismo (o algo muy parecido).

La sesión versaba sobre 10 consejos para mejorar la seguridad, siempre teniendo el principio que daba título a la sesión: como la seguridad no es un añadido si no una funcionalidad debe pensarse sobre ella en el tiempo de análisis.

Consejo 1. Analizar los posibles ataques
Basarse en el modelo STRIDE de ataques. Este modelo determina los siguientes tipos de ataques:

• Spoofing identity
• El atacante quiere ser alguien que no es (puede ser client spoofing para acceder a recursos de un servidor o server spoofing para obtener datos de clientes).
• Mitigación: Mecanismos de autenticación fuertes. Alternativas a login/pwd
  
• Tampering with data
• El atacante modifica los datos de la aplicación
• Mitigación: Usar firmas digitales, hash codes y canales seguros de comunicación
  
• Repudiation
• El atacante puede negar acciones que haya hecho
• Mitigación: Logs de auditoría, firmas digitales y timestamps
  
• Information disclosure
• El atacante puede acceder a datos confidenciales
• Mitigación: Obscuración, encriptación, control de acceso, autenticación fuerte
  
• Denial of Service
• El atacante puede generar DoS debido a males diseños
• Mitigación: Aumentar disponibilidad y fiabilidad. Diseñar medidas preventivas.
• Escalation of Privilege
• El atacante obtiene privilegios que no le corresponden (generalmente por inyección de código).
• Mitigación: Validar todas las entradas.
  

Consejo 2: Protección, detección y reacción
Protección al 100% para todos los problemas es imposible. Por ello no sólo es importante la detección de todos los problemas sinó también la reacción tomada cuando son detectados.

Consejo 3: All input is evil
Una de las máximas de seguridad: Toda entrada provenga de donde provenga es susceptible de generar problemas de seguridad (generalmente por ataques de inyección). Debe validarse toda entrada de datos.

Consejo 4: No reinventar la rueda
Basarse en tecnologías conocidas y probadas antes que en tecnologías propias. P.ej. no desarrollar nuestros protocolos de seguridad o encriptación.

Consejo 5: Usar siempre el mínimo privilegio necesario
Ejecutar las aplicaciones siempre con el privilegio mínimo. La mayoría de aplicaciones no requieren privilegios de administrador.
Bueno, aquí tengo una nota personal: muchas aplicaciones de windows están mal diseñadas y requieren privilegios administrativos cuando no deberían. Ello, junto con que windows mismo exige privilegios administrativos para ejecutar muchas acciones han hecho que la mayoría de usuarios sean (seamos) administradores locales. La tecnología UAC de Vista va precisamente en este camino: ejecutar las aplicaciones sin privilegios administrativos y sólo darlos bajo determinadas circunstancias de forma controlada.
Por otro lado en .NET existe la posibilidad de que una aplicación se reduzca a si misma los privilegios de seguridad, aunque el usuario y la configuración de la máquina le den más privilegios. Este camino es muy interesante.

Consejo 6: Criptografía NO garantiza seguridad
Pues eso. De nada sirve encriptar todos nuestros mensajes si las claves generadas son débiles, o no están bien guardadas o son intercambiadas por canales no seguros.
Además debe tenerse presente de que la criptografía no garantiza la integridad de los datos.

Consejo 7: Firewalls NO garantizan seguridad
Un firewall protege la red, pero las aplicaciones requieren ser accedidas (por lo que el firewall no las protege)... y más del 70% de las vulnerabilidades de seguridad están a nivel de aplicación.

Consejo 8: Secure defaults & failure modes
No habilitar nada por defecto que pueda suponer un problema de seguridad. P.ej. la instalación por defecto de IIS7 no instala ningún módulo susceptible de ser atacable (comparar eso con versiones de hace algunos años...)

Consejo 9: Usar herramientas
No solucionan todo, pero ayudan.
Realizar tests de penetración y revisión de código. Si es necesario, externalizarlos.

Consejo 10: Sentido común
Seguramente el primero en importancia ;-)

En fin, eso fue lo que dio de si esta sesión... que seguramente no fue mala, pero para mis expectativas demasiado básica (lo reconozco: yo esperaba una sesión sobre lo que ofrece .NET 3.0 y Vista a nivel de seguridad).