Software security assurance Software seguro desde el origen

Transcripción

1 Software security assurance Software seguro desde el origen RISI, Walter Director IT Advisory, KPMG MANAVELLA, Nicolás Gerente IT Advisory, KPMG

2 Qué sucedería si los autos fuesen construidos por desarrolladores de software?

3 Qué sucedería si los autos fuesen construidos por desarrolladores de software? El 70% de los autos sería construido sin seguir el diseño original... el otro 30% ni siquiera tendría diseño.

4 Qué sucedería si los autos fuesen construidos por desarrolladores de software? El diseño del auto asumiría que la seguridad es una cuestión que debe ser resuelta por la ruta y que todos los conductores son considerados, están sobrios y son expertos al volante.

5 Qué sucedería si los autos fuesen construidos por desarrolladores de software? Los autos no tendrían airbags, espejos, cinturones de seguridad, puertas, barras anti-vuelco o seguros de puertas porque nadie los pidió.

6 Qué sucedería si los autos fuesen construidos por desarrolladores de software? Las pruebas de seguridad asumirían solamente un choque frontal no se probarían vuelcos, estabilidad, frenos, choques laterales, etc.

7 Qué sucedería si los autos fuesen construidos por desarrolladores de software? Muchas características originalmente incluidas en el diseño serían luego eliminadas de la versión final del auto para que no reduzcan la performance.

8 Qué sucedería si los autos fuesen construidos por desarrolladores de software? El único indicador de precaución del auto sería una gran cantidad de humo y llamas en la cabina.

9 Qué sucedería si los autos fuesen construidos por desarrolladores de software? Solamente habría una empresa de seguros para cada auto, sería extremadamente cara, requeriría un re-chequeo completo del auto y no aceptaría reclamos.

10

11 Cuándo fue la última vez que descubrió un problema de seguridad en una aplicación?

12 Las respuestas que en general más oímos En un Penetration Test En un Accidente En un Ataque

13 Cuántos pliegos de licitación de software incluyen requerimientos de Seguridad? Cuántas proyectos de desarrollo contemplan requerimientos de Seguridad?

14 Muy pocos! Y cuándo los incluyen, no son mucho más que El software debe cumplir con los estándares de seguridad de la compañía. El software debe ser seguro.

15 Cuántos arquitectos de software están formados en Seguridad?

16 Cuántas personas en el departamento de Seguridad Informática poseen conocimiento de desarrollo de software?

17 pero además Cuántos servicios / fábricas / áreas de QA realizan pruebas relacionadas con Seguridad antes de permitir el pasaje a producción de un software?

18 En general, pocos

19 El resultado No se contemplan requerimientos de seguridad. No se desarrolla contemplando necesidades de seguridad específicas (y en general, ninguna) No se realizan pruebas de seguridad durante el desarrollo. Los problemas de seguridad se descubren muy tarde.

20 El costo de corregirlo Dónde estaría el Pen Test periódico?

21 1. When first tested, more than half of all applications fail to meet acceptable security quality, and more than 8 out of 10 web applications fail OWASP Top Cross-site scripting prevalence remains constant over time, while SQL injection is trending slightly down 3. Finance and Software industries lead the charge on holding software suppliers accountable; Aerospace and Defense are following suit 4. Most developers are in dire need of additional application security training and knowledge 5. The software industry, including security products and services, have significant gaps in their security posture Source: Veracode, SOSS Report April 2011 Survey of 4,835 applications

22 En 2012, KPMG UK realizó un workshop con clientes para relevar el estado del arte y las mejores prácticas.

23 Desafíos y Recomendaciones Políticas y Awareness

24 Desafíos: Políticas y Awareness Si bien la mayoría de las organizaciones tiene políticas de seguridad aún existe el desafío de llegar a políticas usables en el contexto de desarrollo de software. Otro gran desafío es lograr conciencia respecto de la seguridad más allá de las obligaciones normativas. Los Desafíos y Recomendaciones aquí descritos parten de los descritos en el estudio Secure Software Development: KPMG s recommendations for prudent practice ( 2012 KPMG UK), adaptados y enriquecidos en base a experiencias de KPMG Argentina.

25 Recomendaciones: Políticas y Awareness Reformular estándares de Seguridad de la Información para hacerlos aplicable al desarrollo y adquisición de software. Entrenar en Seguridad de la Información a los profesionales de software. Realizar actividades de concientización a fin de llevar la Seguridad de la Información al trabajo diario de los profesionales de software. Los Desafíos y Recomendaciones aquí descritos parten de los descritos en el estudio Secure Software Development: KPMG s recommendations for prudent practice ( 2012 KPMG UK), adaptados y enriquecidos en base a experiencias de KPMG Argentina.

26 Desafíos y Recomendaciones Evaluación de Riesgos

27 Desafíos: Evaluación de Riesgos El conocimiento sobre evaluación de riesgos (inherentes al producto) es bajo o nulo en los equipos de desarrollo de software. Por otro lado, el conocimiento sobre desarrollo de software suele ser bajo en los equipos de Seguridad de la Información y/o Riesgo. Los Desafíos y Recomendaciones aquí descritos parten de los descritos en el estudio Secure Software Development: KPMG s recommendations for prudent practice ( 2012 KPMG UK), adaptados y enriquecidos en base a experiencias de KPMG Argentina.

28 Recomendaciones: Evaluación de Riesgos Entrenar a los equipos de desarrollo en metodologías de modelado de amenazas y análisis de riesgo, a fin de incorporar elementos preventivos en los requerimientos, arquitectura y testing de las aplicaciones. Los Desafíos y Recomendaciones aquí descritos parten de los descritos en el estudio Secure Software Development: KPMG s recommendations for prudent practice ( 2012 KPMG UK), adaptados y enriquecidos en base a experiencias de KPMG Argentina.

29 Desafíos y Recomendaciones Arquitectura Empresarial

30 Desafíos: Arquitectura Empresarial Si bien marcos de referencia de Arquitectura Empresarial (como TOGAF) han soportado tradicionalmente la Seguridad de la Información, los mismos han tenido una adopción limitada. Desarrollar arquitecturas de referencia o adoptar marcos como los mencionados requiere un nivel importante de inversión, esfuerzo y tiempo que puede incluso ser prohibitivo. Los Desafíos y Recomendaciones aquí descritos parten de los descritos en el estudio Secure Software Development: KPMG s recommendations for prudent practice ( 2012 KPMG UK), adaptados y enriquecidos en base a experiencias de KPMG Argentina.

31 Recomendaciones: Arquitectura Empresarial Adoptar un conjunto de patrones de diseño seguros, así como building blocks (diseños, componentes, casos de prueba) que capturen las prácticas deseadas. Los mismos podrían no solamente utilizarse en forma in house, sino también a proveedores de desarrollo como componentes de base. Los Desafíos y Recomendaciones aquí descritos parten de los descritos en el estudio Secure Software Development: KPMG s recommendations for prudent practice ( 2012 KPMG UK), adaptados y enriquecidos en base a experiencias de KPMG Argentina.

32 Desafíos y Recomendaciones Herramientas

33 Desafíos: Herramientas Si bien existen gran cantidad de herramientas para realizar assessments de seguridad, las mismas suelen usarse en forma tardía muchas veces previo al pasaje a producción. Por otro lado, las herramientas suelen generar una cierta cantidad de falsos positivos que deben ser interpretados y filtrados por profesionales entrenados en seguridad y desarrollo de software. Los Desafíos y Recomendaciones aquí descritos parten de los descritos en el estudio Secure Software Development: KPMG s recommendations for prudent practice ( 2012 KPMG UK), adaptados y enriquecidos en base a experiencias de KPMG Argentina.

34 Recomendaciones: Herramientas Las herramientas pueden aprovecharse más si se utilizan en forma más temprana y como parte integral del proceso de desarrollo, que contemple requerimientos de seguridad y pruebas / verificaciones asociadas. La aplicación adecuada de las herramientas requiere, además, entrenamiento y definiciones de uso. Los Desafíos y Recomendaciones aquí descritos parten de los descritos en el estudio Secure Software Development: KPMG s recommendations for prudent practice ( 2012 KPMG UK), adaptados y enriquecidos en base a experiencias de KPMG Argentina.

35 Desafíos y Recomendaciones Penetration Testing

36 Desafíos: Penetration Testing El Pen Test es una técnica difundida, sobre todo por ser requerida por auditorías y regulaciones. Si embargo, el Pen Test se realiza mayormente en forma disociada del proceso de desarrollo y normalmente, tardía. Finalmente, cualquier forma de testing permite descubrir síntomas (no defectos) y no garantiza la ausencia de errores. Los Desafíos y Recomendaciones aquí descritos parten de los descritos en el estudio Secure Software Development: KPMG s recommendations for prudent practice ( 2012 KPMG UK), adaptados y enriquecidos en base a experiencias de KPMG Argentina.

37 Recomendaciones: Penetration Testing Sin dejar de realizar los Pen Tests periódicos (con foco organizacional), la incorporación de Pen Tests focalizados en el proceso de desarrollo, así como otras formas de verificación (revisión de código semi automáticas, pruebas de caja blanca) permitirían encontrar defectos en forma más temprana y resolverlos más económicamente. Los Desafíos y Recomendaciones aquí descritos parten de los descritos en el estudio Secure Software Development: KPMG s recommendations for prudent practice ( 2012 KPMG UK), adaptados y enriquecidos en base a experiencias de KPMG Argentina.

38 Desafíos y Recomendaciones Seguridad y Métodos Ágiles

39 Desafíos: Seguridad y Métodos Ágiles Aún cuando se diseñen diferentes etapas de verificación de seguridad para cada fase del ciclo de vida de desarrollo la realidad es que el ciclo de vida en cascada está en declive. Las prácticas modernas de desarrollo favorecen métodos ágiles, donde las diferentes actividades (análisis, desarrollo, testing) se realizan en forma concurrente dificultando los enfoques de verificación por cada etapa. Los Desafíos y Recomendaciones aquí descritos parten de los descritos en el estudio Secure Software Development: KPMG s recommendations for prudent practice ( 2012 KPMG UK), adaptados y enriquecidos en base a experiencias de KPMG Argentina.

40 Recomendaciones: Seguridad y Métodos Ágiles Incorporar estándares de seguridad en el equipo de desarrollo y revisiones continuas (manuales y automáticas). Incorporar a especialistas en seguridad al equipo (de desarrollo). Despertar conciencia de seguridad en los Product Owners, a fin de facilitar la emergencia de User Stories relacionadas con seguridad en las conversaciones con clientes. Los Desafíos y Recomendaciones aquí descritos parten de los descritos en el estudio Secure Software Development: KPMG s recommendations for prudent practice ( 2012 KPMG UK), adaptados y enriquecidos en base a experiencias de KPMG Argentina.

41 Y algunas recomendaciones

42 para empezar mañana mismo Involucrar a Seguridad de la Información en la etapa de análisis de requerimientos. Involucrar a Seguridad de la Información en la elaboración de pliegos de licitación. Definir un conjunto mínimo de estándares y pruebas de seguridad.

43 Conclusiones

44 Conclusiones El foco de la seguridad en el software sigue estando en etapas tardías en relación al desarrollo. Llevar la seguridad a etapas más tempranas permitiría una resolución más económica. En la ruta hacia la solución definitiva, participar a Seguridad de la Información en el inicio de los proyectos de desarrollo puede ser un buen comienzo.

45 Antes de irnos

46 Antes de irnos - Hola, llamamos de la escuela de su hijo estamos teniendo cierto problema informático

47 Antes de irnos - Oh rompió algo? - Sí, de alguna manera.

48 Antes de irnos - Realmente el nombre de su hijo es Robert ; DROP TABLE Students;? - Oh sí, le decimos pequeño Bobby Tables.

49 Antes de irnos -Bueno, hemos perdido los registros de los alumnos de este año. Espero que esté contenta. - Y yo espero que hayan aprendido a sanitizar sus inputs de base de datos!

50 Thank You Presentation by Walter Ariel Risi Nicolás Manavella

51 2013 KPMG, una sociedad civil argentina y firma miembro de la red de firmas miembro independientes de KPMG afiliadas a KPMG International Cooperative ( KPMG International ), una entidad suiza. Derechos reservados. Tanto KPMG, el logotipo de KPMG como "cutting through complexity" son marcas comerciales registradas de KPMG International Cooperative ( KPMG International ).