Manuel Dávila Sguerra Bogotá SOFTWARE DIGNO DE CONFIANZA.

Presentación del tema: "Manuel Dávila Sguerra Bogotá SOFTWARE DIGNO DE CONFIANZA."— Transcripción de la presentación:

1 Manuel Dávila Sguerra mdavila@uniminuto.edu Bogotá SOFTWARE DIGNO DE CONFIANZA

2 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 Consideraciones para Colombia

3 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

4 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

5 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

6 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

7 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

8 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

9 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. Estrategia 2015

10 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 Proceso tradicional en el desarrollo de software Metodologias

11 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 ! Modelo Construir y mejorar 1950 – 1960 Metodologias

12 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

13 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

14 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

15 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

16 Modelo Round Tripping Se soporta en generadores de código basado en diseño de patrones Muy orientado a Programación orientada a objetos Metodologias

17 Modelo Iterativo RUP El más realista de los modelo tradicionales Hace seguimiento entre cada estado y el anterior Metodologias

18 Modelo de software seguro Metodologias

19 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 auntenticar código Comentario: los diseñadores, asquitectos 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 Metodologias

20 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.

21 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 instrucciones no seguras Tom Gilb http://www.gilb.com (Vínculo)Vínculo Nombre del procedimiento: Análisis estático Requiere evaluación humana. No es perfecto. Falsos negativos: el programa tiene bugs no detectados Falsos positivos: el análisis destecta bugs en el programa que no son verdaderos Herramientas: ITS4, http://www.cigital.com /its4 RATS, http://www.securesoftware.com (Perl, php, Python, OpenSSL) FLAWFINDER, http://www.dwheeler.com/flawfinder Trata de buscar instrucciiones que no se debennusar como strcpy()por ejemplo Grep de Linux Deben tener en cuenta las reglas de léxico y semántica de cada lenguaje Expresiones regulares

22 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 auntenticar código Comentario: los diseñadores, arquitectos y analistas deben documentar las asumnciones e identificar los posibles ataques Identificar riesgos de manera explícita y clasificarlos Estructura de administración de riesgos de Cigital Tomado del libro Software Security – Gary McGraw

23 Teminología: Asset (Activo): los objetos de los esfuerzos de protección: Archivos, datos, componentes, sistema completo Risk (Riesgo): la probabilidad de que un activo sufra un evento de impacto negativo. Riesgo = probabilidad x Impacto Threat (Amenaza): el actor o el agente que es fuente del peligro. Sql injection, TCP/IP SYN, buffer overflow, denial of service. Vulnerability (Vulnerabilidad): Defecto o debilidad en los procedimientos de seguridad, diseño, implementación, o controles internos que resulten en violación de las políticas de seguridad Countermeasures or safeguards (Tácticas o medidas preventivas): controles técnicos de un sistema de información para proteger integridad, confidencialidad, y disponibilidad de un sistema Impactt (Impacto): el impacto sobre la organización. Monetario, reputación, ilegalidad, normas contractuales Probability (Probabilidad): la posibilidad de que un evento ocurra. Alto, medio, bajo Ver el bosque no los árboles. Usar gráficos como el UML para especificaciones El diseño no es el código fuente Cálculo de riesgos: ALE = SLE x ARO ALE = Expectativa de pérdida anual SLE = Expectativa de una pérdida simple ARO = Frecuencia predecible de ocurrencias Ej: ALE = $ 150, ARO = 100, ALE = $ 15.000

24 Principios de seguridad en arquitectura: Comenzar haciendo preguntas: Preocupaciones: que puede s estar mal, qué protegemos, quién nos puede atacar, qué debilidades tenemos para la defensa Recursos: librerías, código reusable, estándares Software: autenticación, usuarios legales, número de usuarios y su crecimiento, ambientes de trabajo web o lan Logros propios: impacto, usuarios afectados por medidas de seguridad, apoyo de las directivas Seleccionar un destino concreto: como el arquitecto de una casa que define los aspectos vivenciales del usuario ¿Qué tanta seguridad es la suficiente?: debe existir una relación entre seguridad y presupuesto Usar técnicas de Ingeniería estándares: diseño, aspectos de orden humano y social, malas prácticas de código fuente Identificar las asunciones: uso de recursos como memoria o disco, determinar si los usuarios son seres humanos o máquinas, intenciones de los usuarios conectados Pensar en el uso de la seguridad desde el principio: evitar los compromisos de último minuto Entender y respetar la cadena de los niveles de confianza: no llamar programas inseguros desde programas seguros, no pasar la “antorchas a programas fuera de las propias políticas de seguridad, no delegar responsabilidades Restringir los privilegios: por ejemplo si un archivo es de lectura no lo abra de escritura, usar los principios del menor privilegio

25 Probar toda acción que se proponga contra las políticas de seguridad: los principios de una completa mediación. Parapremisa del método de Descartes es “siempre usar el método” Niveles apropiados de tolerancia a fallas: resistencia o capacidad de detectar ataques, reconocer los ataques, recuperación de los servicios, plan de continuidad, Manejo de errores apropiado: plan general (Arquitecto), reglas para la aplicación (Diseñador), capturar los errores (Programador), Políticas de operación (Operador por ejemplo parar procesos, restaurar etc. Degradación controlada: decidir qué hacer cuando ocurren los problema. Por ejemplo baja memoria, parar o procesar de forma degradad, Fallas seguras: por ejemplo si falla el firewall, parar? O procesar débilmente Escoger valores y acciones asumidos: muchas veces el sistema debe asumir condiciones no especificadas de manera explícita tanto en comportamiento como en valores Mantenerse en el dado simple de las cosas: Einstein decía: Sea lo más simple que se pueda pero no sea simplista” Modularizar: se deben diseñar y escribir funciones modulares tratando de separar aquella que tenga privilegios especiales No confiar en mecanismos que creen confusión: no es bueno creer que el manejo de secretos es un arma de defensa. La seguridad debe ser consistente y se debe pensar en el proceso de producción y mantenimiento de las aplicaciones Mantener un mínimo de retención de estado Adoptar mecanismos prácticos que los usuarios puedan adoptar: es el caso de diseñar interfaces colocándose en el lugar de los usuarios.

26 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 El sistema de pruebas está orientado a funcionalidad La pruebas de seguridad no pertenecen a este paradigma La mayoría de defectos y vulnerabilidades no pertenecen a funcionalidades de seguridad Pruebas de funcionalidades: pruebas por positivos Pruebas de seguridad: pruebas por negativos Se necesitan posiciones de sombrero blanco y de sombrero negro Es esencial pensar como un atacante Pasar las pruebas de seguridad no garantizan inmunidad El grupo de operaciones se ve involucrado en esta fase del ciclo de desarrollo A veces aparecen sorpresas por fallas en el nivel de diseño e implementación La pruebas de penetración cobran valor cuando se aplican en el ambiente operativo Lo debe desarrollar personal especializado que tenga las competencias No deben ser llevadas a cabo por quienes están motivados por no encontrar fallas de seguridad Hoy en día se correo el peligro que los que hagan las pruebas sepan de software pero no de seguridad de redes

27 Usar herramientas: http://immunitysec.com http://www.fortifysoftware.com http://www.spidynamics.com http://www.ieinspector.com/httpanalyser/

28 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

29 Crear responsabilidades: una arquitectura exitosa se asegura de crear responsabilidad en las acciones de parte de los actores. Cuentas personales no de grupos, dificultar que una persona suplante a otra, responsabilidad en el uso de los activos, como por ejemplo: ¿quién es el responsable de la integridad de una base de datos? Limite el consumo de los recursos: muchas veces los ataques tratan de consumir los recursos. Si esto se controla por ejemplo haciendo degradación controlada se logra un control de las situaciones

30 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 (1)‏

31 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 ” Aspectos a tener en cuenta (2)‏

32 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

33 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 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 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 objeti vo La metodología de Taguchi (2) Pérdida de la calidad

34 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

35 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

36 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 La razón (SN) señal a ruido de Taguchi: Pérdida de la calidad

37 Colombia - Estadística de nuevos estudiantes en Ingeniería de sistemas Consideraciones

38 El dominio de la Ingeniería de sistemas (1)‏ Consideraciones

39 El dominio de la Ingeniería de sistemas (2)‏ Consideraciones

40 Colombia - Actividad de ACIS en formación en Tecnologías de punta Acis – Cursos de tecnologias de punta Consideraciones

41 Colombia. El Banco de Innovación Tecnológica - BIT Diseñar, desarrollar y dar mantenimiento a un sistema de información, que permita administrar, impulsar y dar seguimiento a todos los proyectos de investigación que puedan ser conjuntamente ejecutados entre el sector empresarial de base tecnológica y el sector académico, a través de procesos de investigación aplicada, prácticas profesionales, pasantías u otras modalidades por parte de las universidades y los requerimientos y necesidades del sector productivo del software nacional. Consideraciones

42 Fortalecer la industria del software Aumentar la demanda en tecnologías de información Cerrar brechas en talento humano, administrativas y técnicas Sector Público Gobiern o en línea Tercerizació n funciones de TI Territorio s Digitales SECOP Comercio Electrónic o Sector Privado Mipym e Digital Fomento Comercio Electrónic o Líneas Crédit o Fomentar la inversión de empresas de base en TI Crear entorno que favorezca el desarrollo de la industria en TI, incluyendo desarrollo de parques tecnológicos Desarrollo sistema de información: Identificar actores y roles (definir claramente quien hace que), sistema de inteligencia competitiva y de vigilancia tecnológica (oficina de aviso temprano de nuevas tecnologías - Gartner,Forrester), sistema de talento humano (demanda y oferta) y capacitación Fomentar desarrollo de soluciones para sectores económicos estratégicos Gerencia en proyectos, estándares de calidad y gerenciales Identificar / desarrollar soluciones y empresas de talla mundial Fomentar la asociativida d y consolidació n Líneas Crédit o Foment o I&D Incentivo tributario Colciencia s Fondo capital riesgo Levantar línea base (empresas, soluciones, herramienta s desarrollo) Apoyar la exportación de soluciones y servicios Program a Proexpor t Fortalecer relación industria, universidad y centros de Investigació n (CDTs) ‏ Expertos en calidad, arquitectur a etc. Formació n formadore s Número egresados con competencias requeridas por la industria Fortalecer relación industria, universidad, centros de Investigació n y asociaciones Líneas crédito s ICETE X Formación formadores Fortalecer la asociación de empresarios Desarrollo proyecto de Ley para el Software Dónde pode- mos Jugar Fomento capacitación no formal y certificacione s Consideraciones

43 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 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.