PELIGRO. Software en construcción! Maximiliano Alonzo! Buenas Prácticas para la construcción de software seguro.

Tamaño: px

Comenzar la demostración a partir de la página:

Download "PELIGRO. Software en construcción! Maximiliano Alonzo! malonzo@tib.com.uy. Buenas Prácticas para la construcción de software seguro."

Agustín Vicente Ferreyra Rey
hace 8 años
Vistas:

1 PELIGRO Software en construcción Buenas Prácticas para la construcción de software seguro. Maximiliano Alonzo

2 Quién soy? Especialista en Seguridad Informática en CERTuy. Consultor en Seguridad de la Información en TIB. Docente de la asignatura Secure Coding en Universidad Católica. Miembro del Capítulo Uruguay de OWASP. Miembro del Comité de Educación ISACA Montevideo.

Docente de la asignatura Secure Coding en Universidad Católica.

3 De que se trata esta charla? Que no nos pase esto. Casos de problemas conocidos Seguridad en el ciclo de desarrollo Buenas practicas Preguntas?

4 Que no nos pase esto

5 Que no nos pase esto

6 Casos de problemas de software conocidos

7 Hackers aprovechan vulnerabilidades

8 Apagón para 50 millones 14 de agosto de 2003, un apagón en ocho estados de Estados Unidos y Canadá afectadas 50 millones de personas. La causa fue un bug en el código el cual hizo caer el sistema de control dejando 256 plantas de energía fuera de línea.

La causa fue un bug en el código el cual hizo caer el sistema de control dejando 256

9 Terapia de radiación En 1985, Una maquina de terapia de radiación Therac-25 de Canadá falló y entregó dosis letales de radiación a los pacientes. La causa fue debido a un Bug en el código del software, el cual permitía a un técnico configurar accidentalmente Therac-25 de modo que el haz de electrones que despida sea en el modo de alta potencia sin la protección adecuada de los pacientes.

La causa fue debido a un Bug en el código del software, el cual permitía a un técnico configurar accidentalmente

10 Seguridad en el ciclo de desarrollo

11 Vulnerabilidad de seguridad típicas en el software

12 Seguridad en el ciclo de desarrollo Fuente: Gary McGraw, Software security, Security & Privacy Magazine, IEEE, Vol 2, No. 2, pp , 2004.

13 Costo de corrección de defectos en cada etapa de desarrollo de software Source: Gary McGraw, Software security, Security & Privacy Magazine, IEEE, Vol 2, No. 2, pp , 2004.

14 Costo de corrección de defectos en cada etapa de desarrollo de software Mayor costo de corrección Menor costo de corrección Source: Gary McGraw, Software security, Security & Privacy Magazine, IEEE, Vol 2, No. 2, pp , 2004.

costo de corrección Source: Gary McGraw, Software

15 Invertir en conocimientos produce siempre los mejores beneficios. Benjamin Franklin

16 Conocimiento, Capacitación y Cultura Establecer una cultura de seguridad de la información, de manera que se exista conciencia de la seguridad. Mantener a los integrantes del equipo de diseño y desarrollo capacitado. Es recomendable que la persona con mayor conocimiento de la temática este a la cabeza del diseño y revisión de la seguridad del sistema.

Mantener a los integrantes del equipo de diseño y desarrollo capacitado.

17 Aquel que quiera construir torres altas, deberá permanecer largo tiempo en los fundamentos. Anton Bruckner

18 Análisis de arquitectura Es una actividad que se realiza sobre las especificaciones de diseño. Ejemplo de riesgo: Pobre segmentación y protección de los datos críticos. La seguridad a nivel de diseño de la arquitectura debe ser coherente. Se debe realizar la identificación y la documentación de forma clara de los posibles ataques. (DFD, STRIDE, Arboles de ataque, DREAD).

La seguridad a nivel de diseño de la arquitectura debe ser coherente.

19 Análisis de arquitectura Cubrir y valorar los defectos de seguridad a nivel de la arquitectura y como estos deben ser mitigados. Los problemas de seguridad que no sean tenidos en cuenta en esta etapa pueden incurrir en problemas de difícil y costosa solución mas adelante en el ciclo de desarrollo. Siempre pueden surgir nuevos riesgos durante las etapas del desarrollo, por eso es necesario ser constante con las actividades de gestión de riesgos.

Los problemas de seguridad que no sean tenidos en cuenta en esta etapa pueden incurrir en problemas de difícil

20 A fuerza de construir bien, se llega a buen arquitecto. Aristóteles

21 Revisión de código Es una actividad que se realiza sobre el código. Ejemplo de riego: Buffer overflow Todo desarrollo produce al menos un artefacto, el código. Tiene como foco identificar los bugs introducidos durante la implementación. Las herramientas de análisis de código estático son especiales para revisar el código para descubrir posibles vulnerabilidades. (Ej. Fortify, Sonar, etc.)

22 Revisión de código mejora la seguridad del software pero no es suficiente. solo puede identificar errores a nivel de código. solo puede detectar el 50% de los problemas de seguridad.

23 Revisión de código Es necesario un enfoque coherente de la seguridad del software el cual debe incluir tanto una Revisión de Código como un Análisis de Arquitectura.

24 Test de penetración Actividad que se realiza sobre el Sistema en producción Ejemplo de riesgo: Pobre manejo de los errores en la aplicación web. Actividad extremadamente útil. Es importante que se base en el análisis de riesgos de la arquitectura (ARA). Brinda un conocimiento de la situación del software implementado en ambiente de producción.

25 Test de penetración Los test que no contemplen al software probablemente no cubran nada de interés. Una aplicación que falle un test de caja negra con una herramienta automatizada es una aplicación realmente insegura. Test de penetración de red es distinto de test de penetración de aplicación.

26 Resumiendo

27 Preguntas?

Documentos relacionados

Curso: (62612) Diseño de aplicaciones seguras

Curso: (62612) Diseño de aplicaciones seguras Fernando Tricas García Departamento de Informática e Ingeniería de Sistemas Universidad de Zaragoza http://webdiis.unizar.es/~ftricas/ http://moodle.unizar.es/