SOFTWARE DIGNO DE CONFIANZA Manuel Dávila Sguerra mdavila@uniminuto.edu Bogotá
Contenido Estrategia de software de los EEUU para el 2015 Metodologías para el desarrollo de software Modelo de software seguro Perdida de la calidad - Genichi Taguchi
Estrategia 2015 Origen del estudio SOFTWARE 2015: A NATIONAL SOFTWARE STRATEGY TO ENSURE U.S. SECURITY AND COMPETITIVENESS Report of the 2nd National Software Summit Center for National Software Studies
Estrategia 2015 Importancia Las naciones son altamente dependientes de las tecnologías de la información El punto central es el software Se encuentra en todos los elementos de la vida cotidiana EEUU es una nación bajo riesgo de consecuencias inaceptables por las fallas del software
Estrategia 2015 Riesgos Fallas en la Infraestructura Pérdidas económicas inesperadas Pérdida de vidas Pérdida de la confianza pública Pérdida de identidad y de liderazgo
Estrategia 2015 Oportunidades (1) Direccionar esfuerzos para lograr un software seguro y de calidad que sea digno de confianza trustworthiness. Trustworthiness significa: Digno de confianza para cumplir con los requerimientos necesarios en cualquiera de los componentes de software, aplicación, sistema o red Tiene atributos de seguridad, garantía, confianza, fiabilidad, rendimiento, supervivencia en un amplio espectro de adversidades y compromisos. Se requiere en el hardware, el software, las comunicaciones, componentes de potencia asi como en los Desarrolladores y los que hacen el mantenimiento
Estrategia 2015 Oportunidades (2) Las características del software como una industria intensiva en trabajo requiere que su fuerza de trabajo sea educada y que exista una estructura salarial competitiva Una investigación y desarrollo bien orientada ofrece la oportunidad de mejorar el desarrollo del estado del arte en software entre la industria y la academia La industria orientada hacia la aplicación y la academia hacia objetivos de largo plazo Contribución del gobierno a través de laboratorios y soporte como el de National Science Foundation. Hay un reto para sostenerse en un liderazgo relacionado con la innovación
Estrategia 2015 La estrategia nacional de software Para convertir las oportunidades en soluciones reales es hora de elevar el software a un asunto de política nacional en compañía del estado, la industria y la academia. La visión se orienta a dos logros: adquirir la habilidad de desarrollar y liberar productos y sistemas de software Digno de confianza (trustworthy) de manera rutinaria y asegurar la continuidad de la competitividad de los EEUU en la industria del software Los 4 programas de la estrategia son: A. Mejorar el mecanismo de producir software Digno de confianza (trustworthy) B. Educar y caracterizar la fuerza de trabajo en el software C. Re energizar la investigación y el desarrollo D. Enfrentar la innovación dentro de la industria del software
Estrategia 2015 A. Mejorar el mecanismo de producir software trustworthy (2) Seguridad: Muchos productos están expuestos a problemas de seguridad no intencionada por mala Ingeniería de software y malas prácticas en la programación O codigo malicioso y malintencionado como virus, Troyanos, puertas traseras Hay demasiada pérdida de tiempo en el control de virus, spam que podría utilizarse en tareas productivas Confianza: El software no debe hacer daño a las personas ni a la propiedad: aviación, medicina, exploración espacial, banca, transporte Fiabilidad: No debe afectar a los actores por fallas a gran escala en defensa, telecomunicaciones, energía, espacio y sistemas financieros Supervivencia: Debe mantener un continuo funcionamiento aun en situaciones Adversas y no solo en ambientes benignos.
Metodologias Proceso tradicional en el desarrollo de software Complejidad del software = N*I*(O elevado a la potencia p) N = Tipo de programa I = Nro de entradas O = Nro de salidas p = una potencia
Metodologias Modelo Construir y mejorar 1950 1960 Utilizado por la Volskwagen en la producción y venta de sus vehículos Úselo, informe fallas que nosotros lo mejoramos! El más usado en el desarrollo de software aunque de pena admitirlo!
Metodologias Método en cascada 1970 La época en que Edsger Dijkstra prohibió el go to al margen de la creación de la programación estructurada Funciona si cada fase está perfectamente desarrollada lo cual nunca es verdad!
Metodologias Modelo Prototipo Rápido Basado en el modelo de las plantas piloto de los Ingenieros Químicos. Produce un programa que realiza funciones esenciales que se mejora en el transcurso del desarrollo en la medida en que el usuario lo acepta
Metodologias Modelo Incremental Mezcla del modelo en cascada y del prototipo Rápido Reconoce que los pasos en el desarrollo no son discretos y va creando construcciones paulatinas Tiene el peligro que el proceso de aprendizaje exceda al de la productividad y se de el síndrome de la investigación
Metodologias Modelo Extreme Programming 1996 Basado en el desarrollo del sistema de nómina de Chrysler El cliente se coloca en el asiento del chofer... Basado en su discurso él es parte del desarrollo el cual se hace de manera incremental
Metodologias Modelo Round Tripping Se soporta en generadores de código basado en diseño de patrones Muy orientado a Programación orientada a objetos
Modelo Iterativo RUP El más realista de los modelo tradicionales Hace seguimiento entre cada estado y el anterior Metodologias
Modelo de software seguro Metodologias
Metodologias 7 Puntos de análisis (1) 1. Revisión de código con herramientas Artefacto: código Ejemplo de riesgo encontrado: Buffer overflow en la linea 10 Comentario: Es el análisis estático del código que ayuda en parte, no en todo, a descubrir instruccones no seguras 2. Análisis de riesgo de la arquitectura Artefacto: Diseño y especificación Ejemplo de riesgo encontrado: pobre protección de datos críticos, fallas en web services al autenticar código Comentario: los diseñadores, arquitectos y analistas deben documentar las asunciones e identificar los posibles ataques 3. Pruebas de penetración Artefacto: Sistema y ambiente Ejemplo de riesgo encontrado: manejo pobre del interfaz de web Comentario: las pruebas de penetración en la red no son suficientes mecanismos de seguridad. El software debe pasar pruebas de cajas negras fabricadas por otras aplicaciones
7 Puntos de análisis (2) 4. Test de seguridad basado en riesgos Artefacto: Unidades y sistema Ejemplo de riesgo encontrado: Comentario: asegurarse que no pasen cosas malas. Pensar como un atacante 5. Casos de abuso Artefacto: Requerimientos y casos de uso Ejemplo de riesgo encontrado: Suceptibilidad a intentos de ataques bien conocidos Comentario: descripción del comportamiento del sistema bajo ataque 6. Requerimientos de seguridad Artefacto: Requerimientos Ejemplo de riesgo encontrado: No hay descripción explícita de protección de datos Comentario: los requerimientos de seguridad deben cubrir seguridad funcional por ejemplo ciframiento de los datos, y características emergentes 7. Operaciones seguras Artefacto: sistema en funcionamiento Ejemplo de riesgo encontrado: Insuficiente datos de bitácora para perseguir un ataque conocido Comentario: La seguridad de la red ayuda en este caso. Los ataques se darán inevitablemente. La experiencia de ataques anteriores ayuda a la seguridad.
Aspectos a tener en cuenta (1) Los problemas de la seguridad: defectos como buffer overflow, mal manejo de detección de errores Conectividad, ubicuidad, web services y Soa saben que se han publicadp muchas aplicaciones no diseñadas para trabajar en red como servicios web (Citrix) Plataformas antiguas que no soportan ssl Integración middleware en que la autenticación y los protocolos del nivel de aplicación no están alineados. Sistemas que tienen código móvil a través de APIS como los plugins de los navegadores, los Web services y SOA Complejidad en software de grandes extensiones en donde no es posible abolir los bugs
Aspectos a tener en cuenta (2) La seguridad hoy en día se trabaja más al nivel de la red con firewalls, ssl, ids's etc Está en manos de expertos operativos en la red más no en los desarrolladores de software La noción de defender el perímetro no es suficiente ya que si bien los firewalls intentan proteger el sistema del exterior no sirve cuando hay tunneling y el software del exterior entra inpunemente 3 Pilares: administración del riesgo, touchpoints o mejores prácticas que deben ir en todo el ciclo de desarrollo y Conocimiento Memo de Bill Gates Enero 15 del 2002: En los años anteriores hemos aclarado que asegurar que la plataforma.net sea Digna de confianza es más importante que cualquier parte de nuestro trabajo La computación Digna de confianza es aquella que está disponible, es fiable y segura como los servicios de agua, energía eléctrica teléfono Digno de confianza va más allá que seguridad Entre añadir funcionalidades al software y hacerlo seguro, preferimos hacerlo seguro
Pérdida de la calidad La metodología de Taguchi (1) Dr Genichi Taguchi, 1924, Japón: Departamento de astronomía e Instituto de Navegación del Imperio Japonés Ministerio de Salud Pública y bienestar social Instituto de estadísticas matemáticas Ministerio de educación Pérdida de calidad: Quality loss Pérdida llevada por el producto a la sociedad desde el momento en que es empaquetado Incluye pérdidas por costo de reproceso, mantenimiento, fallas, reclamos, rendimiento, fiabilidad Función cuadrática de pérdida con desviación de su finalidad Un acercamiento al objetivo tiende a decrecer la pérdida e incrementar reducción en variabilidad la calidad
Pérdida de la calidad Otra vez Taguchi: Robustez: un estado en donde el rendimiento de la tecnología, producto o proceso es mínimamente sensitivo a factores que causen variabilidad al menor costo unitario de manufactura Señal: es lo que un producto debe mostrar por las características de sus funcionalidades Ruido: factores que causan variaciones externo, interno y entre productos Ruido en software: uso errático por parte del usuario, ataques, virus y gusanos, huecos de seguridad, poca documentación, entrenamiento inadecuado, malos procedimientos o malos usos, acceso no autorizado, sometimiento del sistema a usuarios para los cuales no fue diseñado
Pérdida de la calidad La metodología de Taguchi (2) Control de calidad fuera de linea: Diseño del sistema: lluvia de ideas, investigación y metodologías Diseño de parámetros: permiten hacer control sobre variables sensibles de aspectos que producen ruido Diseño tolerante: se aplica cuando los parámetros no son suficientes para fijarlos Bajar la variación sobre el objetivo Métodos de Taguchi: La pérdida de calidad se debe más a fallas después de ventas. La robustez de un producto depende más de la etapa de diseño que del control en linea. No libere nada que no cumpla los estándares (Parapremisa del método) No use medidas de calidad basadas en el usuario Los productos robustos producen una señal fuerte sin importar el ruido externo y con un mínimo de ruido interno
Pérdida de la calidad Deming el Padre del movimiento de la calidad moderna Voz del usuario o consumidor, reducción de la variación, medidas estadísticas, ganancia de confianza, respeto por los co trabajadores, continua mejora en el proceso. La esencia de los puntos de Deming: Constancia en el propósito Evitar dependencia de las inspecciones construyendo calidad desde el principio Entrenamiento permanente Liderazgo más que supervisión Eliminar incentivos por cuotas y cambiarlas por liderazgo Eliminar administración por objetivos cuantificados y cambiarlos por liderazgo Eliminar los premios por méritos anuales cambiarlo por administración por objetivos Educación y auto mejoramiento
Pérdida de la calidad La razón (SN) señal a ruido de Taguchi: Debe evaluar la robustez de la funcionalidad de un producto Representa la razón de sensibilidad a la variabilidad Se refiere a la transformación en energía, potencia, información,imagen, datos etc Para un dispositivo eléctrico: S/N = Conversión de energía eléctrica para obtener una función mecánica deseada/ Conversión de energía resultante en funcionalidades costosas = Conversión de energía en torque útil / Conversión de energía resultante en calor, vibraciones, roces etc = Conversión de energía para obtener funcionalidades deseadas/ Transformación de energía en funcionalidades indeseadas En software se trata de transformar información, datos, imágenes etc QLF: Quality loss function L = D*D*C En donde D= Desviación del objetivo C= Costo de contra medidas para que el rendimiento del producto esté dentro de los objetivos
El dominio de la Ingeniería de sistemas (1) Consideraciones
El dominio de la Ingeniería de sistemas (2) Consideraciones
Bibliografia Center for National software studies. (2005, Abril). Final report: 2015 A National Software Strategy to Ensure U.S.. Security and Competitiveness. Consultado el 31 de Mayo de 2009 en http://www.cnsoftware.org/nss2report/nss2finalreport04-29-05pdf.pdf [1] Jayaswal K, Patton. Design for trustworthy software. Prentice Hall Pearson Education, 2007. 798 pp. [2] McGraw G. Software security. Addison-Wesley Softwar security series. 2006. 408 pp.