Diseño de aplicaciones web siguiendo el concepto hack-resilient. Respuestas SiC

c. Santander, 101. Edif. A. 2º I E-08030 Barcelona (Spain) I Tel.: +34 93 305 13 18 I Fax: +34 93 278 22 48

Pº. de la Castellana, 164-166. Entlo. 1ª I E-28046 Madrid (Spain) I Tel: +34 91 788 57 78 I Fax: +34 91 788 57 01

[email protected] I www.isecauditors.com

Diseño de aplicaciones web siguiendo el concepto hack-resilient

Vicente Aguilera Díaz 21/06/2011 – Barcelona

Internet Security Auditors 22/06/2011 – Madrid

© I n t e r n e t S e c u r i t y A u d i t o r s • J u n i o 2 0 1 1 • P. 2

Diseño de aplicaciones web siguiendo

el concepto hack-resilient

Agenda

1. Concepto hack-resilient

2. La importancia de la seguridad en la capa de aplicación

3. Áreas clave en la seguridad de aplicaciones

4. Conclusiones y recomendaciones

5. Referencias




1│

Concepto hack-resilient







¿Qué entendemos como

software seguro?




2│

La importancia de la seguridad en

la capa de aplicación




¿Por qué ha cobrado tanta relevancia?

• Proliferación de modelos de negocio en la web.

• Las aplicaciones web resultan muy atractivas.

• Según Gartner:

• El 66% de las aplicaciones son vulnerables.

• El 75% de los ataques se focalizan en la capa de

aplicación.

• Nuevos requerimientos normativos.




¿Por qué ha cobrado tanta relevancia?




Todo es posible en la Web…




¿Qué podemos hacer para protegernos?

• Conocer las amenazas y las soluciones

• Definir niveles de riesgo/confianza

• Verificar los requerimientos de seguridad

• Adoptar una iniciativa de seguridad en el ciclo de vida




OWASP ASVS Application Security Verification Standard




3│

Áreas clave en la seguridad de

aplicaciones




Áreas con requerimientos de seguridad

1 Arquitectura de seguridad

2 Autenticación

3 Gestión de sesiones

4 Control de acceso

5 Validación de entradas

6 Codificación de salida

7 Criptografía

8 Gestión de errores y logging

9 Protección de datos

10 Seguridad en la comunicación

11 Seguridad en HTTP

12 Configuración de seguridad

13 Búsqueda de código malicioso

14 Seguridad interna




A1. Arquitectura de seguridad

• Thinking Evil™

• Establecer un conjunto de principios y máximas de

seguridad.

• Contemplar los aspectos de seguridad en la

documentación.




A2. Autenticación

• Autenticación de múltiples factores.

• Negar el acceso a procesos automáticos.

• Utilizar controles anti-fraude y monitorizar las alertas.

• Controles de autenticación centralizados.

• No relajar los controles (operativas de gestión de

cuentas).

• Informar del último acceso.




A3. Gestión de sesiones

• No reinventar la rueda.

• No confiar en los identificadores de sesión recibidos.

• Establecer un tiempo de vida (inactividad, absoluto).

• Destruir las sesiones en la desconexión (logout).

• Proteger y regenerar los identificadores de sesión.

• Asociar los identificadores de sesión con otro token.

• Utilizar atributos de seguridad en las cookies.




A4. Control de acceso

• Recoger los requerimientos en la política de seguridad.

• Elaborar una matriz de control de acceso.

• Limitar el acceso a los recursos en función de la

identidad del usuario y su rol.

• Evitar que el mecanismo sea sobrepasado.

• Restricciones sobre las operativas de administración.




A5. Validación de entradas

• Sistema centralizado.

• Canonicalización de forma previa a la validación.

• En caso de fallo, rechazar los datos de entrada.

• Establecer el charset (como UTF-8).

• Validaciones de seguridad siempre en la parte del

servidor.

• Firewall de aplicación.




A6. Codificación de salida y escape

• Conocer el contexto.

• Los controles deben implementarse en la parte del

servidor.

• Escapar/codificar los caracteres inseguros.




A7. Criptografía

• Política explícita de gestión de claves.

• Utilizar módulos criptográficos aprobados y validados

contra estándares (FIPS 140-2).

• Almacenar contraseñas de forma segura.




A8. Gestión de errores y logging

• Gestión de errores estructurada vs funcional.

• Mensajes de error no detallados.

• En caso de fallo, ir a un estado seguro.

• Sincronizar los componentes de logging.

• Los eventos relevantes deben ser registrados.

• Proteger los logs.

• Apoyarse en herramientas de auditoría de log para su

análisis.




A9. Protección de datos

• Establecer una política que defina como controlar el

acceso.

• Eliminar la información tras el tiempo de retención de

datos.

• Tecnologías de cifrado, tokenización, firewalls de base

de datos.

• Conocer las normativas de cumplimiento (PCI DSS,

LOPD, PII, HIPAA, etc.)




A10. Seguridad en la comunicación

• Establecer conexiones TLS y no permitir conexiones

inseguras.

• Autenticar las conexiones a sistemas externos

(principio de mínimo privilegio).

• Los errores en las conexiones TLS (backend) deben

ser registrados.

• Seguir un estándar en las implementaciones TLS.




A11. Seguridad en HTTP

• Analizar los usos de las cabeceras HTTP.

• No transmitir información innecesaria.

• No utilizar la cabecera HTTP «Referer» en validaciones

de seguridad.

• Únicamente habilitar métodos HTTP seguros.

• Utilizar tokens asociados a las cookies de sesión.




A12. Configuración de seguridad

• Almacenar en una ubicación protegida.

• Sin el acceso a la configuración no permitir el acceso a

la aplicación.

• Registrar los cambios en la configuración.




A13. Búsqueda de código malicioso

• Verificar la integridad del código.

• Emplear tecnologías que permitan detectar malware.




A14. Seguridad interna

• Interfaces simples.

• Ofrecer protección sobre los recursos compartidos.

• Proteger la información y políticas utilizadas por los

controles de acceso.




4│

Conclusiones y recomendaciones




Conclusiones

• Necesitamos crear software seguro.

• Aplicación segura ≠ código seguro.

• Debemos conocer todos los riesgos y cómo mitigarlos.

• Incrementar la inversión en la protección de la capa de

aplicación.




Recomendaciones

• Clasificar las aplicaciones y definir requerimientos

mínimos de seguridad.

• Verificar el cumplimiento de los requerimientos de

seguridad.

• Crear el software pensado en los casos de abuso.

• Huir de la solución «todo en uno».

• Seguir el principio de defensa en profundidad.




Recomendaciones

• Identificar los marcos regulatorios. Ayudar a su

cumplimiento.

• Otorgar a los requerimientos de seguridad la misma

prioridad que a los requerimientos funcionales.

• Mantenerse informado sobre las amenazas existentes.

• Consultar las soluciones tecnológicas sin menospreciar

las open-source.

• Potenciar la cultura de la seguridad en la organización.




5│

Referencias




Referencias

• Improving Web Application Security:

• Business Models on the Web:

• OWASP Application Security Verification Standard:

https://www.owasp.org/index.php/Category:OWASP_Application_S

ecurity_Verification_Standard_Project

http://msdn.microsoft.com/en-us/library/ff649874.aspx

http://digitalenterprise.org/models/models.html

• PCI Data Security Standard

https://www.pcisecuritystandards.org

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project

https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project







https://www.pcisecuritystandards.org/




Referencias

• Controles técnicos de seguridad para la protección de

aplicaciones web (SIC, nº 94. 04/2011):

http://www.isecauditors.com/downloads/prensa/downloads/prensa/

SIC94_Seguridad_Aplicaciones_OWASP.pdf

• Servicio Vigilancia Anti-Malware (SIC, nº 83. 02/2009)

http://www.isecauditors.com/downloads/prensa/SIC-

83_Servicio_Vigilancia_Anti_Malware.pdf

• Fundamentos de tokenización y su aplicación en el

cumplimiento de PCI DSS (Red Seguridad, nº 49. 11/10)

http://www.isecauditors.com/downloads/prensa/RedSeguridad_49_

Tokenizacion.pdf

http://www.isecauditors.com/downloads/prensa/SIC-83_Servicio_Vigilancia_Anti_Malware.pdf

http://www.isecauditors.com/downloads/prensa/downloads/prensa/SIC94_Seguridad_Aplicaciones_OWASP.pdf

http://www.isecauditors.com/downloads/prensa/downloads/prensa/SIC94_Seguridad_Aplicaciones_OWASP.pdf




http://www.isecauditors.com/downloads/prensa/RedSeguridad_49_Tokenizacion.pdf

http://www.isecauditors.com/downloads/prensa/RedSeguridad_49_Tokenizacion.pdf




?

dudas / comentarios / sugerencias

¡Muchas gracias!




Su Seguridad es Nuestro Éxito

Vicente Aguilera Díaz Director Departamento Auditoría

Internet Security Auditors [email protected]

c/ Santander, 101. Edif. A. 2º

E-08030 Barcelona (Spain)

Tel.: +34 93 305 13 18

Fax: +34 93 278 22 48

Pº. de la Castellana, 164-166. Entlo. 1ª

E-28046 Madrid (Spain)

Tel.: +34 91 788 57 78

Fax: +34 91 788 57 01

www.isecauditors.com

Technology

Diseño de aplicaciones web siguiendo el concepto hack-resilient. Respuestas SiC