¡Descarga Diseño de software seguro y más Resúmenes en PDF de Sistemas Operativos solo en Docsity!
u n o
Diseño de software seguro
Manuel Dávila Sguerra
E
l software es un elemento cata- logado de seguridad nacional en los países que tienen un plan de desarrollo orientado hacia la sociedad del conocimiento. La preocu- pación en esos países se basa en el hecho de que la Ingeniería de software no ha logrado que los desarrollos de software cumplan con la característica denomina- da “trusworthy”, es decir, digno de con- fianza. Este artículo pretende recoger una serie de especificaciones que contribuyan a que se cumpla el desarrollo de software seguro. No es la seguridad perimetral la que preocupa en esta investigación, es el software en sí.
Para ello se ha consultado la estrategia de desarrollo de software de los Estados unidos para el 2015, se resumen los plan- teamientos de Gary McGraw, uno de los líderes en la propuesta de metodologías de software seguro, y se hace una pro- puesta para incluir en el ciclo de desarro- llo las etapas necesarias para lograr estos desarrollos.
Finalmente, haciendo uso de los refe- rentes de ACM e IEEE sobre los diseños curriculares para crear programas de Ingeniería de sistemas o afines, se pro- ponen algunos puntos importantes para incluir en los nuevos programas la for- mación en este tipo de competencias.
Palabras clave: Software seguro, trustwor- thy, diseño curricular, Ingeniería de sistemas.
- Introducción
En los países orientados a conformar so- ciedad del conocimiento y que tienen en el desarrollo de software un compromi- so como industria, se le considera a éste un producto de seguridad nacional. Es el caso de los Estados Unidos que en el reporte de la segunda cumbre del Centro Nacional de Software así lo presenta, en un documento llamado “Software 2015: A national software strategy to ensure U.S. Security and competitiveness” [1]
Consideran que su nación es altamen- te dependiente de las tecnologías de la información siendo el punto central el software, el cual se encuentra en todos los elementos de la vida cotidiana de las personas y las organizaciones. Determi- nan que su país es una nación bajo ries- go de consecuencias inaceptables por las fallas del software. Estas fallas pueden crear serios problemas en varios riesgos, enumerando específicamente la infraes- tructura nacional, la economía, la vida de las personas, la pérdida de confianza pública, de la identidad y liderazgo.
Si bien nuestros países no se comparan con la capacidad productiva de software
que tiene Estados Unidos, es de mucha utilidad conocer esos planes, pues de to- das maneras las tecnologías informáticas tienen carácter global. Siendo innegable la importancia del software, así como su penetración en la vida cotidiana se ve la necesidad de revisar el estado de la Inge- niería de software, la cual en sus 50 años de existencia aún no ha podido resolver el riesgo de que un avión se caiga por culpa de un overflow en una variable.
Vale la pena anotar que el nivel de segu- ridad que se necesita en el diseño de los programas va más allá de la tradicional seguridad perimetral, para entrar en el campo del diseño de las aplicaciones.
Este estudio ha contemplado las premi- sas de la estrategia de los Estados Uni- dos como referencia para entrar en una discusión de índole más local.
- Software digno de confianza o trustworthiness
Se introduce el término trusworthiness o la cultura sobre las características que debe cumplir el software para ser “trust- worthy” o sea, digno de confianza. Estas características se resumen en: seguridad, confianza, fiabilidad y supervivencia. El significado de cada una de estas caracte- rísticas se detalla a continuación.
Seguridad : se refiere a la exposición de los programas a peligros no intencio- nados en sus especificaciones; es decir, que no se dan por mala Ingeniería de software o malas prácticas en la pro- gramación, sino por aspectos de índole externo. Cabe hablar aquí de código ma- licioso y malintencionado como son los virus, troyanos, puertas traseras, spam lo que no sólo crea problemas reales de disminución de confianza, sino que ba-
jan la productividad porque el tiempo de control y revisiones de los daños es muy grande, pudiendo usarse en otras labores más productivas. Una persona que gaste una hora diaria en revisar estos proble- mas equivale a un mes laboral del año.
Confianza : la vida normal de las perso- nas transcurre con el uso de elementos o artefactos que dependen del software y que su uso debe generar confianza para una tranquilidad de índole social. El software inseguro puede llegar a ha- cer daño a las personas y a la propiedad en ambientes de uso cotidiano como la aviación, la medicina, la exploración es- pacial, la banca y en general el transpor- te. Obsérvese cómo en estas actividades está en peligro la vida de las personas, no sólo una funcionalidad con repercu- siones económicas.
Fiabilidad : en algunos casos el software participa de soluciones de gran escala que pueden afectar de manera masiva a la sociedad, como la defensa nacional, las telecomunicaciones, la energía, el es- pacio y los sistemas financieros. El hecho de utilizar satélites para las telecomuni- caciones y el transporte de los datos nos puede afectar.
Supervivencia: ese término se definió como una característica que asegure que el software se debe mantener en conti- nuo funcionamiento, aún en situaciones adversas y no sólo en ambientes benig- nos. El reciente drama del Japón con el terremoto y el tsunami dan que pensar en cuanto a lo que se puede catalogar una situación adversa, pues los centros de da- tos deben contemplar estas situaciones y el software mismo también.
Pasemos ahora a determinar una defini- ción formal para la palabra “Trustworthi-
Modelo prototipo rápido:
Se basa en el modelo de las plantas pilo- to de los Ingenieros Químicos y va pro- duciendo el programa con las funciones esenciales para ir mejorándolo, en la me- dida en que el usuario los acepta. Es de anotar la presencia del usuario un poco más involucrado en el proceso.
Modelo incremental:
Es una mezcla del modelo en cascada y del prototipo rápido y ya reconoce que los pasos en el desarrollo no son discretos, y va creando construcciones paulatinas, con el peligro de que el proceso de apren- dizaje exceda al de la productividad y se de el “síndrome de la investigación”.
Modelo Extreme Programming:
Se basa en el desarrollo del sistema de nómina de Chrysler y se involucra al usuario o cliente cuyo “discurso” es re- cibido en su lenguaje original y se toma como parte del desarrollo, el cual se hace de manera incremental. La Chrysler dice “se monta al usuario en el desarrollo” como una metáfora relacionada con mon- tarlo en el vehículo, pero que significa te- nerlo en cuenta de manera preferencial.
Modelo Round Tripping:
Se soporta en los generadores de código basado en diseño de patrones. Está muy orientado a la Programación orientada a objetos.
Modelo Iterativo RUP:
Se considera uno de los más realistas, pues hace seguimiento entre cada estado y el anterior.
El modelo tradicional, que envuelve a la gran mayoría de las metodologías, contempla los siguientes ciclos: especi- ficaciones o modelo funcional, diseño o arquitectura, programación, pruebas, documentación, entrenamiento y man- tenimiento. Se acostumbra a expresar la Complejidad del software como una fun- ción del tipo de programa ( N ), el número de entradas ( I ), el número de salidas ( O ), y una potencia p de tal manera que:
Complejidad = NI(O elevado a la po- tencia p) [3]
- Seguridad de las aplicaciones y seguridad perimetral
Hasta el momento la seguridad perime- tral ha seguido evolucionando cada vez con mayor fuerza. Las gerencias de in- fraestructura informática tienen más en cuenta la necesidad de incluir proxys y fi- rewall para filtrar el tráfico, tanto al nivel de las URL como de los puertos y servi- cios de la red. Estos profesionales tienen conocimientos sobre redes y algunos so- bre seguridad, ciframiento, certificados de seguridad, detección de intrusos, vi- rus, gusanos, troyanos y de más software intrusivo que llega a la red.
Sobre esto sólo se puede decir que se- guirá evolucionando como lo ha hecho, centrando su atención en la capa baja del modelo OSI. En la capa alta están las apli- caciones, a las cuales llegan los usuarios y a veces los intrusos que han logrado pasar los filtros de la seguridad perimetral.
Dice el libro “Computer Crime” de la edi- torial O’reilly que, en la gran mayoría de los casos, los intrusos entran no por com- plejos conocimientos de redes, sino por el simple hecho de haber podido atrapar las claves de seguridad de los usuarios. [4]
Cualquiera que sea el caso, surge la pre- gunta sobre la forma como se protegerá la aplicación a sí misma, bien sea por ade- cuados trabajos en la etapa de diseño, por fuertes procedimientos de escritura del código fuente o por adecuados análisis de riesgo en la interacción con la plataforma tecnológica. Lo anterior lleva a concluir que es necesario incluir dentro del ciclo de desarrollo del software, cualquiera que sea la metodología utilizada, tareas rela- cionadas con la seguridad, no ya perime- tral, sino de las aplicaciones mismas.
Un inconveniente es el hecho de que los profesionales de las redes y la seguridad de hoy en día, no son los mismos de la Ingeniería de software. Es claro que el diálogo se llevará a nivel de la capa de desarrollo, lo que necesita profesionales aceptados por quienes hacen las aplica- ciones; es decir, analistas, arquitectos, programadores y demás especialistas.
La formación de este tipo de profesional es nueva y puede surgir de una mezcla de las alternativas de formación que plantea la ACM y la IEEE en el computing curricu- la 2005. Este referente plantea cinco pro- cesos formativos que son: Ingeniería de computadores, Ciencia de computadores, Ingeniería de software, Sistemas de infor- mación y Tecnología de la información.
No está dentro de este estudio el análisis de este referente, pero basta con decir que
el perfil del profesional que se vislumbra para intervenir en el ciclo de desarrollo de software seguro puede estar en una mezcla bien diseñada curricularmente entre Ingeniería de software y Tecnolo- gía de la información.
Los diagramas de Computing Curricula de estas dos orientaciones se muestran a continuación, aclarando que el eje ho- rizontal indica nivel de conocimiento desde lo teórico (izquierda) a lo prácti- co (derecha), y el eje vertical va desde abajo a arriba indicando áreas de pro- fundización, es decir, desde el chip, la electrónica, la plataforma, el software, los lenguajes, las metodologías, hasta la implementación. Bajo esas consideracio- nes la ACM y la IEEE consideran cinco énfasis sobre los cuales se pueden formar los profesionales. Sin entrar en grandes detalles y dejando al lector la indagación de la lógica de estas gráficas, cada una de las cuales tiene un currículo sugerido, nos referiremos a: CE : Computer En- ginering. Forma profesionales que van a diseñar computadores. CS : Computer Science. SE : Software Engineering. IS : Information System. IT : Information Technology.
El gráfico abajo a la derecha sólo insi- núa que una Universidad puede diseñar el perfil de los profesionales dependien- do de sus objetivos, como una mezcla de estos énfasis.
Figura 1. Los énfasis de la Ingeniería de sistemas según ACM e IEEE [6]
- Pérdida de calidad
La calidad de los resultados es el objetivo final del desarrollo de software. Ésta tiene muchas definiciones y mecanismos para lograrla, sin embargo se expondrán los análisis de los autores Bijay K. Jakaswal y Peter C. Patton, autores del libro De- sign for Trusworthy software [7] basados en las teorías del Dr Genichi Taguchi, ja- ponés nacido en 1924, quien expuso su teoría sobre la pérdida de calidad (Quali- tyLoss), la que define como “La pérdida llevada por el producto a la sociedad des- de el momento en que es empaquetado”.
El concepto fundamental se basa en la idea de acercarse lo más posible al objeti- vo propuesto, de tal manera que la varia- ción del resultado final con respecto a él sea la mínima posible y que los niveles de variabilidad conllevan costos de reproce- so, mantenimiento, fallas, reclamos, ren- dimiento y fiabilidad. Se trata de medir este costo como una función cuadrática de la desviación con respecto a la fina- lidad. Y aplicar una metodología que in- cremente el control de variables externas a través de lluvia de ideas, investigación y metodologías formales. Insiste, el Doc- tor Taguchi, en la parametrización que permita ejercer control sobre variables sensibles y ser tolerantes en el sentido de permitir fijar valores a algunos paráme- tros sobre realidades comprobadas.
Para comprender el tema, el Dr Taguchi incluye una serie de definiciones en su lenguaje que ayudan a comprender sus postulados sobre la calidad como son:
Robuste z: “un estado en donde el rendi- miento de la tecnología, producto o pro- ceso 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”. Sonido en un radio, imagen en un televi- sor, funcionalidades comprobadas en un paquete de software. Ruido: “factores que causan variaciones externamente, internamente o entre productos”. Inter- ferencias en la imagen de un televisor o uso errático por parte del usuario de un paquete de software, ataques, virus, gu- sanos y huecos de seguridad, poca docu- mentación, entrenamiento inadecuado, malos procedimientos o malos usos del sistema, accesos no autorizados, some- timiento del sistema a usuarios para los cuales no fue diseñado.
Teniendo en cuenta estas definiciones Ta- guchi resume en algunas premisas el mé- todo: “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 durante su fun- cionamiento”; “no liberar nada que no cumpla los estándares”; “no usar 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”.
Se sabe que el Señor Deming, llamado el padre del movimiento de la calidad mo- derna, fue seguido por Taguchi en algu- nas de sus teorías y propone también una serie de premisas aplicables al desarrollo de software como estas: “atender la voz del usuario o consumidor, reducción de la variación, medidas estadísticas, ganan- cia de confianza, respeto por los cotraba- jadores, mejora continua en el proceso”.
Y la esencia de los puntos de Deming que también son aplicables al caso del software son: “constancia en el propósi- to”; “evitar dependencia de las inspec- ciones construyendo calidad desde el principio”; “entrenamiento permanen- te”; “ liderazgo más que supervisión ”;
“eliminar incentivos por cuotas y cam- biarlas por liderazgo”; “eliminar admi- nistración por objetivos cuantificados y cambiarlos por liderazgo”; “eliminar los premios por méritos anuales cambiarlo por administración por objetivos”; “edu- cación y auto mejoramiento”.
- Conclusiones
La experiencia vivida en esta inves- tigación he permitido ir creando una metodología formal para que al hacer un proyecto de desarrollo de software sea tenida en cuenta la seguridad en el software. Académicamente, nos permite transmitir a través de conferencias a los estudiantes estas tendencias. Es de espe- rarse que las asignaturas de Ingeniería de software le den más importancia, en las universidades, a estas innovaciones.
Se corrobora nuevamente que la Ingenie- ría de software requiere mejoras perma- nentes y que aún depende demasiado de las destrezas de los diferentes profesio- nales que actúan en un desarrollo de soft- ware. Nos deja las expectativas de ver cómo en los Estados Unidos se resolverá el problema de la Ingeniería de software y nos invita, a profundizar en el desarro- llo “digno de confianza”.
Dos experiencias se han podido concre- tar en resultados. Una, la de proponer una metodología basada en lo propuesto por Gary McGraw, otra el desarrollo de un
algoritmo que permite detectar intrusos, no en la red sino en la aplicación mis- ma, el cual ha sido implementado en la plataforma e-Genesis – El generador de sistemas de mi autoría y con el desarrollo de un método para hacer autodocumen- tación de software, temas que podrán ex- pandirse en otra publicación.
8. REFERENCIAS
[1] Report of the 2 nd^ National Software Summit, 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. Center for National software studies, Reston, 2005, pp.1-
[2] Córdoba G, La investigación tecnológica, Limusa Noriega Editores, pp 216,, 2005
[3] Patton P, Jayaswal B., Design for trustwor- thy Software, Prentice Hall, pp 7, 2006
[4] Icove D. VonStorch W., Computer Crime, O’Reilly and Associated Inc, pp51, 1995
[5] G. McGraw, “Software security Building security in”, 1er. ed., Addinson Wesley”, pp. 3-176, 2006
[6] ACM-IEEE, Computing Curricula, Snap- shots: Graphical Views of the Computing Dis- ciplines, ACM-IEEE, pp16,
[7] G. McGraw, “Software security Building security in”, 1er. ed., Addinson Wesley”, pp. 84, 2006
Manuel Dávila Sguerra. Ingeniero de Sistemas Uniandes, Director Departamento de In- formática y Electrónica Uniminuto, Coordinador Académico ACIS, Columnista de Com- puter World, eltiempo.com: 110 artículos publicados, Autor de e-Genesis- El Generador de sistemas, Mención especial en el Premio Colombiano de Informática 2006, Escogido entre los 25 IT Manager del año 2008 por la revista IT-Manager, Miembro Fundador de ACIS, de Indusoft hoy Fedesoft, de la Red de Decanos y Directores de Ingeniería de sistemas, REDIS, Autor de los libros “GNU/Linux y el software libre” y “Software libre una visión”.
