Seguridad del Software - PDF

ÍNDICE Introducción............................................................................................................................................. 5 UNIDAD I: Sistemas de Información..................................................................................................... 6 1.1.- Componentes de un Sistema........................................................................................................... 6 1.2.- Sistema de Información................................................................................................................... 7 1.3.- Sistema Informático......................................................................................................................... 8 1.4.- Analista de Sistemas....................................................................................................................... 9 UNIDAD II: Proceso de desarrollo de software.................................................................................. 11 2.1.- Introducción................................................................................................................................... 11 2.2.- Software........................................................................................................................................ 11 2.3.- Ingeniería de Software................................................................................................................... 13 2.4.- Proceso de construcción del software............................................................................................ 14 2.5.- Metodologías de desarrollo de software......................................................................................... 16 2.6.- Metodologías prescriptivas............................................................................................................ 16 2.7.- Metodologías ágiles....................................................................................................................... 18 UNIDAD III: Calidad del software........................................................................................................ 22 3.1.- Introducción................................................................................................................................... 22 3.2.- Calidad.......................................................................................................................................... 22 3.3.- Calidad del Software...................................................................................................................... 22 3.4.- El dilema de la calidad del software............................................................................................... 24 3.5.- Calidad y Seguridad del Software.................................................................................................. 24 3.6.- Revisiones: un enfoque recomendado........................................................................................... 25 3.7.- Revisiones ágiles........................................................................................................................... 27 UNIDAD IV: Seguridad del software................................................................................................... 29 4.1.- Introducción................................................................................................................................... 29 4.2.- Propiedades del software seguro................................................................................................... 29 4.3.- Principios de diseño seguro de aplicaciones.................................................................................. 30 4.4.- Controles proactivos OWASP........................................................................................................ 32 4.5.- Metodologías de desarrollo de software seguro............................................................................. 32 UNIDAD V: Prueba del software.......................................................................................................... 36 5.1.- Introducción................................................................................................................................... 36 5.2.- Enfoque estratégico para la prueba de software............................................................................ 36 5.3.- Pruebas de caja blanca................................................................................................................. 38 5.4.- Pruebas de caja negra................................................................................................................... 38 5.5.- Integración continua....................................................................................................................... 39 5.6.- Pruebas especializadas para la movilidad..................................................................................... 39 Bibliografía recomendada...................................................................................................................... 47 Seguridad del Software | 2 REFERENCIAS DE ÍCONOS Seguridad del Software | 3 Mensaje de Bienvenida La materia SEGURIDAD DEL SOFTWARE, tiene como objetivo principal presentar y lograr relacionar los conceptos más importantes de la seguridad del software, con las actividades que forman parte del proceso de desarrollo de productos software, apli- caciones que se encuentran presentes en casi todos los aspectos de la vida coti- diana. La seguridad en el ámbito de la tecnología es un aspecto fundamental y prioritario. Por lo tanto, aplicar criterios oportunos de seguridad en cada fase del desarrollo de software, se vuelve cada vez más importante dada la creciente complejidad de las soluciones de software actuales. Esta asignatura forma parte del segundo semestre de segundo año de la carrera TECNICATURA UNIVERSITARIA EN SEGURIDAD INFORMÁTICA, y sus conteni- dos mínimos incluyen conceptos de software, proceso de desarrollo de software como también los desafíos de seguridad que pueden surgir durante las etapas de las distintas metodologías de desarrollo de software. Los aportes que se puedan brindar a la sociedad a través del desarrollo de productos y servicios software son cada vez más relevantes. Estos productos software ya se encuentran incorporados en la vida laboral, personal, académica, familiar, entre otros aspectos de cada uno de nosotros. Por lo tanto, colaborar en la formación integral de los alumnos en el entendimiento general de lo que implica el proceso de desarrollo de estos productos, junto a la seguridad en las etapas de construcción de los mismos, resulta fundamental en el rol de esta materia. El desarrollo de software seguro es un desafío profesional que involucra una forma- ción continua, y a través de esta asignatura esperamos colaborar en esa formación y que los alumnos puedan crecer en uno de los perfiles informáticos más requeridos del mercado laboral actual. Seguridad del Software | 4 Introducción Dentro del contenido que tendrá esta materia, y aportando al enfoque que presentan las demás asignaturas que la acompañan en la carrera, es importante que el alumno pueda adentrarse en los aspectos del desarrollo de software, los perfiles informáticos que participan de estos procesos, la relevancia indiscutible que tiene la seguridad durante las fases de construcción de estos productos y servicios, y la participación en equipos de trabajo. Las diferentes unidades que componen el programa de esta asignatura, irán llevando al alumno a incorporar conceptos básicos desde qué es un sistema de información, a qué nos referimos cuando hablamos de software y de su proceso de desarrollo, hasta abarcar conceptos de seguridad, calidad y prueba que son los pilares de esta materia. Seguridad del Software | 5 UNIDAD I: Sistemas de Información Un sistema es un conjunto de partes interrelacionadas entre sí, que trabajan juntas para un objetivo en común. En un sistema, los componentes del mismo cuando tra- bajan de manera conjunta producen un resultado superior a la simple agregación de los elementos de manera individual. Según la Teoría General de Sistemas (TGS) es el estudio de los sistemas en general, desde una perspectiva interdisciplinaria teniendo como objetivo identificar los diver- sos elementos que componen un sistema, como así también sus interrelaciones. Se- gún la TGS, un sistema se define como una entidad autónoma dotada de cierta per- manencia en el tiempo, formada por elementos relacionados que forman subsistemas estructurales y funcionales; que evoluciona dentro de ciertos límites gracias a regu- laciones internas que le permiten adaptarse a su entorno específico. Ludwig von Ber- talanffy (1901-1972). 1.1.- Componentes de un Sistema Un sistema está formado por los siguientes elementos: - Entradas: inputs o insumos del sistema, formados por aquellos procesos que incor- poran información o materia al sistema, provenientes desde el exterior. - Salidas: outputs o productos del sistema, son el resultado obtenido mediante el fun- cionamiento del sistema y que en general, salen del sistema hacia el medio exterior. - Procesos: throughput o transformaciones del sistema, son los mecanismos a través de los cuales el sistema produce cambios o convierte las entradas en salidas. - Retroalimentación: capacidad del sistema para convertir sus salidas en nuevas en- tradas. - Medio ambiente: entorno o contexto del sistema, compuesto por todo lo que rodea al sistema y existe fuera de él, lo cual a su vez constituye un sistema dentro de otro, y así sucesivamente. A partir del contexto del sistema, se pueden clasificar en: - Sistemas abiertos: son aquellos que comparten información libremente con su me- dio ambiente. - Sistemas cerrados: son aquellos que no comparten información de ningún tipo con su medio ambiente, es un concepto ideal. - Sistemas semiabiertos o semicerrados: son aquellos que comparten la menor infor- mación posible con su medio ambiente. ENFOQUE SISTÉMICO: Es el abordaje de un objeto o situación bajo las reglas de un sistema, es decir, manteniendo una perspectiva de sistema, determinando los elementos que lo componen, las relaciones entre ellos, entradas y salidas de infor- mación respecto al su contexto. De esta manera, una organización puede ser conceptualizadacomo un sistema para lograr objetivos predeterminados por medio de personas y otros recursos. Los prin- cipios de sistemas permiten adentrarse en la manera en la que las organizaciones trabajan; todos los sistemas que forman la organización están relacionados y son interdependientes y cuando cambia o desaparece alguno de ellos existe una reper- cusión en el resto. Seguridad del Software | 6 Figura 1.1.- La Organización como Sistema 1.2.- Sistema de Información Un sistema de información está formado por un conjunto de recursos humanos, ma- teriales, financieros, tecnológicos, normativos y metodológicos, organizado para brin- dar, a quienes operan y a quienes adoptan decisiones en una organización, la infor- mación que requieren para desarrollar sus respectivas funciones. Por lo tanto, un sistema de información está bien diseñado solo si provee la informa- ción adecuada, en cuanto a su tipo, calidad y oportunidad, haciéndolo de manera eficiente. Cuando se dice que la información debe ser eficiente, estamos buscando que para obtener esa información se utilice la mejor combinación posible de todos los recursos, al menor costo posible, para alcanzar el objetivo buscado. Las características que buscamos en la información son las siguientes: - Económica: el costo de producir la información no debe ser superior al beneficio esperable de su utilización. - Oportuna: la información debe estar disponible en el momento que se la requiera. - Útil: toda información producto de un sistema debe satisfacer una necesidad. - Comparable: la información debe ser comparable en el espacio, tiempo y alcance. - Clara: la información debe ser entendible a nivel técnico e intelectual de su destina- tario. - Confiable: la información debe ser lo suficientemente confiable como para que se puedan tomar decisiones basadas en ella. Como se puede ver, la información es el valor más importante de un sistema de in- formación. Se debe estudiar muy bien el contexto del mismo para ir descubriendo la necesidad de información de los diferentes actores. El responsable de descubrir, en- tre otras cuestiones, el contexto del negocio y la información que se necesita es el analista de sistemas. Además, debemos detectar si estamos frente a un sistema de información o a un sistema informático. Seguridad del Software | 7 1.3.- Sistema Informático Un sistema informático es un sistema de información al cual se le suman dos compo- nentes fundamentales que hacen a su naturaleza informática, y ellos son el hardware y el software. En la actualidad, prácticamente todos los contextos y organizaciones cuentan con sistemas informáticos, es decir sistemas que buscan proveer de informa- ción adecuada a quienes toman decisiones, pero a través de medios informáticos. Por lo tanto, los componentes de un sistema informático, los cuales se vinculan entre sí, son los siguientes: Figura 1.2.- Sistema Informático - Hardware: Es el componente físico de la informática, el hardware incluye las compu- tadoras de los operadores, dispositivos móviles, equipos servidores, redes de da- tos, impresoras, etc. - Software: Es el componente lógico e intangible de la informática, son los programas de computación que se ejecutan y permiten que las computadoras realicen tareas. Además, el software incluye documentos que acompañan el desarrollo de estos programas y cómo se usan como así también las estructuras de los datos que se manipulan para lograr estas funciones. Sobre este tema en particular, se abordará en la próxima unidad. - Procedimientos: Son los manuales y normas que explican cómo se hacen las cosas en esa organización, son las políticas que explican cómo se realizan los procesos que se llevan a cabo como parte de ese entorno. - Documentos: Es el registro documental de la operatoria del sistema. Son los com- probantes de las transacciones, facturas, remitos, actas, etc. - Base de datos: Es el conjunto de los datos operativos de la empresa, sin importar el soporte físico de los mismos, pueden ser ficheros físicos o digitales. - Personas: Es el personal de la organización que interactúan con el sistema, de ma- nera directa o beneficiándose con la información que éste provee. Seguridad del Software | 8 1.4.- Analista de Sistemas Cuando estamos frente a una organización y se debe analizar su entorno o contexto para descubrir sus componentes; entender cómo funcionan cada uno y de manera conjunta y proponer ajustes o mejoras que permitan obtener información útil a la toma de decisiones mediante un sistema informático, entra en juego un rol fundamental que se conoce como “analista de sistemas”. Esta persona será quien se volverá experta en ese contexto, tiene como principal responsabilidad el estudio detallado de ese contexto, a los fines de poder valorar la manera en que funcionan los componentes de esa organización examinando las en- tradas, procesamiento de datos y las salidas de información con el objetivo de mejo- rar los procesos organizacionales. El analista de sistemas debe ser un profesional solucionador de problemas, con ca- pacidades como la comunicación eficiente, el trabajo en equipo, la mirada sistémica, automotivado, auto disciplinado, entre otras actitudes que serán clave para quien ejerza este rol lo haga de una manera eficiente. Además, cuando está involucrado en el contexto de un sistema informático, el ana- lista de sistemas debe ser capaz de interactuar tanto con los usuarios del sistema informático, como también con aquellos profesionales que serán los responsables de desarrollarlo. Figura 1.3.- Analista de Sistemas Seguridad del Software | 9 ACTIVIDAD EN EL FORO Foro de debate: Sistema Informático En el foro de debate llamado “Sistema Informático” habilitado en la plataforma, se busca que los alumnos compartan ejemplos concretos de lo solicitado en la consigna de trabajo, para que se puedan obtener conclusiones al respecto. Consigna de trabajo Para una organización conocida en el medio, indicar algún sistema informático im- plementado en este contexto y describir los 6 componentes que lo forman. Para cada componente explicar brevemente en qué consiste el mismo dentro de la organización y si es posible, acompañe de ejemplos concreto cada uno de ellos. Evaluación Este trabajo se evalúa mediante la participación en el foro y la puesta en común con los demás compañeros. Seguridad del Software | 10 UNIDAD II: Proceso de desarrollo de software 2.1.- Introducción En esta unidad se va a presentar el proceso de desarrollo de software, en qué con- siste este procedimiento de construcción, sus principales actividades y el valor de su aplicación para desarrollar productos o servicios software. Es vital comprender el concepto de software, en qué consiste este producto que se obtiene como resultado de aplicar un proceso o marco de trabajo para su desarrollo. Comprender el proceso a través del cual se desarrolla el software, ayudará a enten- der la importancia de cada etapa, cuáles son las más determinantes, el vínculo que existe con el equipo de trabajo en este proceso de construcción y cómo ir aplicando buenas prácticas en cada paso. El software es el foco de esta materia y de cada una de las unidades de aquí en adelante, se irá presentando cada aspecto del mismo en su relación con la seguridad, y para ello es fundamental entender este producto desde su concepción. Figura 2.1.- Software 2.2.- Software Los sistemas informáticos están compuestos por hardware y software, como sus prin- cipales componentes. El hardware es aquel componente físico compuesto por computadoras, dispositivos móviles, periféricos, servidores, redes de datos, entre otros artefactos que hacen a lo tangible dentro del sistema informático. El software, en cambio, es aquel componente lógico e intangible conocido como los programas que se ejecutan en las computadoras y permiten que éstas ejecuten fun- ciones que hacen a las necesidades o requerimientos de quienes las operan. Es de- cir, que el software condiciona el comportamiento del hardware. Sin embargo, los programas de computadoras son solo una parte del software. El software está compuesto por tres partes, que son las siguientes: - Instrucciones ejecutables: código de programación ejecutable que proporciona la función y el comportamiento deseado. Seguridad del Software | 11 - Estructuras de datos: son las formas en que se organizan los datos, para facilitar a los programas manipular adecuadamente la información. - Documentación: son aquellos documentos que describen la construcción del soft- ware, su configuración y el uso del mismo. Son documentos técnicos orientados a quienes construyen software y también documentos de uso orientados a quienes operan el software. Figura 2.2.- Componentes del Software Características principales del software: - El software se desarrolla, no se fabrica. - El software no se desgasta con su uso, se vuelve obsoleto. - La mayoría del software es a medida. El software está presente en innumerables aplicaciones de la vida cotidiana, y de acuerdo al ámbito en el cual se aplique, se puede clasificar en las siguientes catego- rías: - Software de sistemas: son los llamados sistemas base, como ser los sistemas ope- rativos, los motores de base de datos, entre otros. Son software que necesitan otros sistemas para poder desarrollarse y utilizarse. - Software de gestión: quizás el que más utilizamos en la vida cotidiana, es aquel software destinado a brindar apoyo a las diferentes actividades de una organización o contexto. Por ejemplo, el software de facturación de una empresa, de atención a usuarios de una telefonía, de inscripción de alumnos de una institución, de gestión de expedientes de una entidad gubernamental, de gestión de productos de un em- prendimiento de ventas, entre otros. - Software científico: software desarrollado específicamente para dar apoyo científico como ser de simulación, de cálculos complejos, etc. - Software empotrado: es aquel que se encuentra asociado al hardware que lo con- tiene de manera inmersa. Es el software que forma ya parte de aparatos Seguridad del Software | 12 electrónicos como Smart TV, lavarropas, Smart Watch, microondas, etc. y que ge- neralmente no se pueden reprogramar. - Software de utilitarios: son aquellos destinados principalmente a tareas de ofimá- tica, de diseño de nuevos objetos, como pueden ser el Autocad, paquete de MS Office, etc. - Software de IA: software experto que apoya tareas mediante la aplicación de técni- cas de aprendizaje automatizado, entre otras ramas de la IA. Según el momento en que el software registra los hechos, se puede clasificar en: - Software por lote: el registro de los hechos se realiza en un único momento, por ejemplo, al finalizar la jornada, un registro detrás del otro. Se aplica bajo criterios prácticos, como ser la actualización masiva de base de datos, backups, etc. - Software en línea: los hechos que modela el software se registran en el sistema en el mismo instante en que ocurren. Por ejemplo, las ventas por Internet, o el proceso de facturar una operación, o la reserva de un ticket, etc. - Software en tiempo real: son aquellos que cumplen con las siguientes característi- cas: a) Son de respuesta extremadamente rápida y b) sus respuestas modifican el contexto donde están operando. Por ejemplo, un piloto automático de avión o de auto autónomo. 2.3.- Ingeniería de Software El software se desarrollaba desde sus orígenes, de una manera muy artesanal, ya que construcción era muy individualista, espontanea, se utilizaban las mismas herra- mientas y por lo tanto, estas formas solo fueron útiles en los primeros tiempos de poca complejidad y de poca demanda del mismo. A medida que el software se volvió más complejo, cada vez más requerido y cada vez más exigente en cuanto a las funcionalidades que ofrecía, fue necesario comen- zar a aplicar principios de la ingeniería a este proceso de construcción, y es así como nace la ingeniería de software. La ingeniería de software es el “establecimiento y uso de principios fundamentales de ingeniería orientados a obtener software de manera económica, que sea fiable y funcione eficientemente sobre máquinas reales” [Fritz Bauer - 1969] Según la IEEE - 1993, la ingeniería de software es la “aplicación de un enfoque sis- temático, disciplinado y cuantificable, al desarrollo, operación y mantenimiento de software”. Por lo tanto, la ingeniería de software está constituida por al menos los siguientes elementos, como conceptos fundamentales que se apoyan como capas unos a otros. - Procesos: son las actividades pilares y de apoyo necesarias en todo proyecto. - Métodos: son las estrategias que se pueden seguir para resolver el proyecto. - Herramientas: con los instrumentos manuales o automatizados junto a las técnicas asociadas. - Compromiso con la calidad: el enfoque de la mejora continua es parte de todo pro- yecto. Seguridad del Software | 13 Figura 2.3.- Elementos de la Ingeniería de Software 2.4.- Proceso de construcción del software Para construir software se necesita analizar el problema hasta comprender total- mente el desafío a abordar, diseñar el sistema software que cumpla las expectativas, programarlo, probarlo y mantenerlo hasta que se decida su retiro. Por lo tanto, se aplican los conceptos y pasos claves del proceso de resolución de problemas, por el que atraviesa la mente humana cuando quiere resolver un conflicto, los cuales son los siguientes. Figura 2.4.- Proceso de resolución de un problema De esta manera, lo que se busca es encontrar un proceso que permita transformar un problema o necesidad, en un producto software, el cual sería la solución automa- tizada que satisface esa necesidad. Figura 2.5.- Proceso de construcción del software Seguridad del Software | 14 Cuando se construye o desarrolla el software, comienzan a convivir dos conceptos, los cuales se van a encontrar muy conectados entre sí, estos son el proceso y el producto. El proceso software es un conjunto de actividades interrelacionadas a través de al- guna estrategia, a través de las cuales se construye un resultado. El producto software, resultado de aplicar un proceso, va atravesando por diferentes estados durante su construcción hasta llegar a un estado en el que puede ser imple- mentado. A continuación, se presenta un esquema que muestra cómo se van relacionando las actividades generales de un proceso software con la transformación por la que va atravesando el producto software, por lo que es importante saber que al construir software se ponen en juego ambas miradas simultáneamente, el enfoque del proceso y el enfoque del producto. Figura 2.6.- Proceso y Producto Software En esta mirada conjunta, es importante destacar que el ciclo de vida del proceso de desarrollo de software, más allá de la estrategia que se elija, se cumple o termina cuando el producto construido se logra desarrollar y se pone en funcionamiento. Esto quiere decir, que cuando el proceso de desarrollo logra construir el producto software buscado, el proceso termina. Sin embargo, el ciclo de vida del producto software comienza simultáneamente cuando comienza su desarrollo, pero termina cuando después de haberse logrado su construcción y puesta en funcionamiento, se mantiene su uso en el tiempo hasta que se vuelve obsoleto y pasa a retiro. Es allí, donde el ciclo de vida del producto recién termina. Seguridad del Software | 15 Para ilustrar este vínculo, se presenta el siguiente esquema. Figura 2.7.- CV del Proceso y CV del Producto 2.5.- Metodologías de desarrollo de software Desde hace varios años, han surgido diferentes marcos de trabajo que proponen diferentes estrategias para el proceso de desarrollar software. Estas metodologías de desarrollo van desde las más antiguas y ya casi obsoletas en el mercado actual, hasta las más actuales y eficientes en el mundo del software de hoy. Todas las metodologías de desarrollo de software han aportado ventajas para ciertos momentos o para ciertos contextos, incluso algunas han propuesto actividades que se siguen incluyendo en las metodologías más modernas. Se pueden clasificar en metodologías prescriptivas y metodologías ágiles, siendo las primeras de ellas, las que tienen un enfoque muy guiado a la hora del desarrollo, mientras que las últimas, las metodologías ágiles ya proponen adaptaciones durante el proceso según el avance del desarrollo. A continuación, se presentan sólo algunas de las metodologías más relevantes den- tro del grupo de las prescriptivas, y el marco de trabajo más utilizado dentro del grupo de las ágiles. Por supuesto, no son los únicos existentes o que están siendo usados en el mercado del desarrollo del software, pero sí los más conocidos y utilizados. 2.6.- Metodologías prescriptivas 2.6.1.- Ciclo de Vida Clásico Dentro de las metodologías prescriptivas, se presenta a continuación el ciclo de vida clásico, el cual propone el desarrollo del software a través de una secuencia orde- nada de transiciones de una fase a la otra según un orden lineal. Como se puede observar en la figura, solo permite regresar a la actividad o fase inmediatamente an- terior y no a fases superiores en caso de necesitar ajustes. Esta propuesta no se adapta a entornos cambiantes y complejos, demora mucho tiempo en descubrir ajustes o falencias en alguna fase del desarrollo anterior, no in- volucra de manera protagonista al usuario, entre otros aspectos que hoy en día son innegociables en un marco de trabajo moderno. Seguridad del Software | 16 Sin embargo, para aquellos contextos que no presentan cambios y además son sen- cillos, es un marco de trabajo que se puede aplicar sin demasiados inconvenientes. Figura 2.8.- Ciclo de Vida Clásico 2.6.2.- Ciclo de Vida de Prototipo Como un gran avance al ciclo de vida clásico, surge el ciclo de vida de prototipo, entendiendo la industria del software la imperiosa necesidad de involucrar al usuario y la retroalimentación que éste brinda como parte del proceso de desarrollo. Además, a partir del surgimiento de este marco de desarrollo, también se comienza a desarro- llar software en iteraciones que van brindando entregables del producto, pequeños resultados a lo largo del proceso, lo cual permite ir ajustando el producto a medida que se lo va construyendo. Como se puede ver en la gráfica que ilustra este ciclo de vida, las fases comienzan con una primera etapa donde se pone la atención en recolectar y descubrir las nece- sidades de lo que será el primer prototipo, no de todo el sistema software a construir, luego se hace un diseño rápido de esa porción, se construye efectivamente el proto- tipo, se lo pone a disposición del usuario para su evaluación, y en base a la retroali- mentación recibida por parte de nuestro usuario se lo refina, es decir, se ajusta y se corrige lo necesario para determinar si ya está listo como producto final o pasamos a una iteración más de este proceso y así continúa hasta su finalización. Figura 2.9.- Ciclo de Vida Prototipo Seguridad del Software | 17 2.6.3.- Ciclo de Vida de Proceso Unificado Una de las metodologías prescriptivas de desarrollo de software que se encuentra aún vigente en el mercado y se utiliza con frecuencia en algunos contextos actuales, es el Proceso Unificado de Desarrollo de Software. Este marco de trabajo introdujo el con- cepto de caso de uso, siendo esta herramienta la guía de todo el proceso. Las princi- pales características de esta metodología es que se encuentra dirigida por los casos de uso, centrada en la arquitectura y es una metodología iterativa e incremental. Un caso de uso es una porción de funcionalidad que se espera que provea el software y que le sea útil a algún actor de mi sistema. Con este concepto pone a los usuarios, en sus diferentes roles dentro del contexto, como factores claves ya que todo el pro- ceso está dirigido por las funcionalidades que el software debe contemplar para ellos. Continúa aplicando un proceso iterativo, como lo hace el marco de trabajo de proto- tipo, sumando además el incremento esperado en cada una de estas iteraciones. Es una metodología muy clara, que propone herramientas muy útiles para cada fase de su desarrollo, las especificaciones que se logran son muy completas y propone al desarrollador de software un camino muy guiado. Sin embargo, es una metodología que propone una documentación demasiado excesiva en cada una de las fases, y la construcción propiamente dicha del software se demora en comenzar. Si bien incluye como parte de su proceso actividades de gestión, configuración el entorno y otros aspectos que metodologías anteriores no tenían en cuenta, en am- bientes muy cambiantes donde el usuario espera contar con funcionalidades en el corto plazo, no sería el marco de trabajo más recomendable. Figura 2.10.- Proceso Unificado de Desarrollo de Software 2.7.- Metodologías ágiles En el año 2001, referentes de la industria del software, se reunieron en Utah, EEUU para tratar sobre procesos de desarrollo de software y encontrar nuevos modelos de trabajo, ya que los que existían hasta ese momento eran muy rígidos y tenían una Seguridad del Software | 18 dependencia demasiado pesada a las planificaciones detalladas previas al desarrollo del software, para lo que el mercado y los usuarios necesitaban. Como resultado de ese encuentro se definieron principios y valores ágiles, los cuales deben ser considerados siempre que se aplique este marco de trabajo, más allá de la metodología o estrategia específica dentro de lo que el mundo ágil ofrece. La parte más importante del manifiesto expresa lo siguiente: “Estamos descubriendo formas mejores de desarrollar software tanto por nues- tra propia experiencia como ayudando a terceros. A través de este trabajo he- mos aprendido a valorar: Individuos e interacciones sobre procesos y herramientas Software funcionando sobre documentación extensiva Colaboración con el cliente sobre negociación contractual Respuesta ante el cambio sobre seguir un plan Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda.” https://agilemanifesto.org/iso/es/manifesto.html El primer valor pone énfasis en que las personas y las interacciones entre ellas, como así también el trabajo en equipo es clave y determinante para el éxito o el fracaso de un producto software, más allá de los procesos y herramientas que se elijan para su construcción. En el mundo del software es muy importante que los profesionales es- tén capacitados en procesos, técnicas y herramientas para construir software, pero es igual de valioso que lo estén en trabajo en equipo, liderazgo, negociación, objeti- vos, etc. El segundo valor nos demuestra que los usuarios y clientes valoran mucho más el software funcionando qué documentación excesiva sobre ese producto software. La documentación es fundamental, y por lo tanto no hay que confundir o mal interpretar este valor, pero se debe documentar lo necesario para ir construyendo software que funcione para el cliente y que éste pueda usar y hacer recomendaciones al respecto. El software se debe construir en etapas, y cada etapa debe entregar software funcio- nando no sólo documentación. El tercer valor brinda mayor importancia a que el avance en el desarrollo se haga junto al cliente, teniendo en cuenta la retroalimentación que nos brinde y negociando el alcance del producto con el cliente, no fijando de manera rígida una negociación sin evaluar el avance a medida que se construye. Por último, el cuarto valor nos incentiva a que debemos estar preparados para adap- tarnos a los cambios durante el proceso de desarrollo, los sistemas software se cons- truyen para ambientes cambiantes y por lo tanto debemos saber que los cambios son parte de ese proceso, no una excepción. Estar preparados para adaptar nuestro avance es fundamental. Tener un plan es muy importante y no debe faltar nunca, pero ese plan debe ser trabajado desde el primer momento con la suficiente capaci- dad de adaptación para que pueda llevarnos a un resultado exitoso. 2.7.1.- Scrum SCRUM es una metodología ágil desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco de trabajo, con el objetivo de maximizar las relaciones Seguridad del Software | 19 interpersonales entre los miembros de un equipo para que éste logre su máximo nivel de productividad posible. Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 20 años. Está especialmente indicada para proyectos con un rápido cam- bio de requisitos. El progreso de los proyectos se realiza y verifica en una serie de iteraciones de du- ración fija, denominadas sprints, de duración corta. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. El enfoque de cada iteración es en un 100% abocada a entregar valor al cliente. El desarrollo se inicia desde la visión general de producto, dando detalle solo a las funcionalidades que, por ser las de mayor prioridad para el negocio, se van a desa- rrollar en primer lugar, y pueden llevarse a cabo en un periodo de tiempo breve (la duración de las iteraciones se recomienda entre 1 y 4 semanas). Cada uno de los ciclos de desarrollo, la iteración o sprint, produce un incremento terminado y operativo del producto. Estas iteraciones son la base del desarrollo ágil, y Scrum gestiona su evolución a través de reuniones breves de seguimiento en las que todo el equipo revisa el trabajo realizado desde la reunión anterior y el previsto hasta la reunión siguiente. 2.7.2.- Marco de Trabajo Scrum Figura 2.11.- Marco de Trabajo SCRUM Los roles fundamentales son: - ProductOwner o Responsable del Producto. - Scrum Master o Coach del Equipo. - Team o Equipo (se refiere al equipo de desarrollo de software). Las reuniones claves durante el desarrollo son: - Product Planning Meeting o Reunión Inicial. - Sprint Planning Meeting o Reunión de planificación del sprint. Seguridad del Software | 20 - Sprint o Iteración. - Sprint Review o Revisión de la iteración. - Sprint Retrospective o Retrospectiva de la iteración. Los artefactos más importantes que se desarrollan son: - Product Backlog. - Mapa de Historias. - Sprint Backlog. - Incremento (software funcionando). - Burndown o gráfico de seguimiento. ACTIVIDAD INDIVIDUAL Tarea: Software y su clasificación En la tarea llamada “Software y su clasificación” habilitada en la plataforma, se busca que los alumnos clasifiquen los productos software del listado propuesto, en las ca- tegorías que crean convenientes. Consigna de trabajo Para el listado de productos software que se propone, el cual contiene sistemas y aplicaciones de software conocidas en el mercado, se solicita que se los agrupe en una clasificación de productos software de acuerdo a lo que el alumno considere apropiado. Explicar los criterios que se tuvieron en cuenta para la clasificación pro- puesta. Evaluación Este trabajo se evalúa mediante la presentación de la tarea y la puesta en común con los demás compañeros. Seguridad del Software | 21 UNIDAD III: Calidad del software 3.1.- Introducción Se empezó a hablar de calidad de software, recién cuando el software comenzó a ser parte de la vida cotidiana y lo empezamos a encontrar cada vez más integrado en todos los ámbitos de nuestro día a día. A fines de los 90 muchas empresas em- pezaron a reconocer que perdían mucho dinero en software que no ofrecía las ca- racterísticas o funcionalidades que prometía, y con mucha más preocupación cuando ese software presentaba fallas que podía paralizar procesos, lo que provocaba aún más costos a afrontar. La mala calidad del software provocada por el apuro en poner en el mercado produc- tos software que no han tenido las suficientes pruebas, aún sigue siendo una gran preocupación en la industria del software. Por lo tanto, existen aspectos muy relacionados en este sentido, que son la calidad, la seguridad y la prueba del software. En esta unidad nos enfocaremos en la calidad del software y sus aspectos más relevantes. 3.2.- Calidad Cuando se trata de definir la calidad, la respuesta no es tan simple, ya que si bien sabemos identificar la calidad cuando la vemos, no podemos definirla con simpleza. Según David Garvin (1984) de la Escuela de Negocios de Harvard, la calidad es un concepto complejo y multifacético, que puede describirse desde cinco puntos de vista diferentes. La vista trascendental alega que la calidad es algo que se puede reconocer de in- mediato, pero que no se puede definir de manera explícita. La vista del usuario ve la calidad en términos de las metas específicas de un usuario final, entonces si un producto cumple con esas metas, exhibe calidad. La vista del fabricante define la calidad en términos de la especificación original del producto. Si este se conforma de acuerdo a la especificación, exhibe calidad. La vista del producto sugiere que la calidad puede enlazarse a las características inherentes de un producto. Por último, la vista basada en el valor mide la calidad en base a cuánto está dispuesto a pagar un cliente por un producto. Estas son solo algunas de las vistas que comprende la calidad. La calidad es importante, pero si el usuario no está satisfecho con el producto, en realidad no importa tanto y quizás los usuarios estén dispuestos a tolerar problemas ocasionales, siempre que este producto de software les provea un beneficio consi- derable. 3.3.- Calidad del Software En un sentido muy general, se puede definir la calidad del software, en relación a su proceso de desarrollo; ya que si un proceso de software efectivo, aplicado de una forma crea un producto útil, que ofrezca un valor cuantificable para quienes lo produ- cen y quienes lo utilizan, entonces estamos frente a un software de calidad. En otro acercamiento a la definición de calidad de software, podemos mencionar la definición que presenta el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) en Seguridad del Software | 22 1990, que dice lo siguiente: “la calidad del software es el grado con el que un sistema, componente o proceso cumple los requerimientos especificados y las necesidades o expectativas del cliente o usuario”. También, se puede analizar la calidad del software, teniendo en cuenta la calidad del producto en sí, como también la calidad del proceso de construcción del mismo, siendo éstas dos miradas complementarias de la calidad que se busca en el software. Desde el punto de vista del producto, buscaremos entonces que el producto que se entrega sea útil y que provea el contenido, funciones y características que el usuario final desea, pero también que entregue los activos de una forma confiable y libre de errores. Un producto útil satisface los requerimientos que las partes interesadas han declarado de manera explícita, y también satisface un conjunto de requerimientos im- plícitos, como la facilidad de uso que se espera de todo software de calidad. Cuando analizamos la calidad del producto, también podemos hacerlo desde la mirada del desarrollador de ese producto software, quien evaluará la calidad del producto depen- diendo de la cantidad y calidad de los fallos o errores que pueda contener. Desde el punto de vista del proceso, se debe considerar la búsqueda de la calidad desde las primeras etapas de desarrollo, priorizando establecer la infraestructura que apoya cualquier esfuerzo para crear un producto software de alta calidad. Se debe evitar un caos en el proyecto, y permitir analizar el problema, diseñando una solución que sea robusta y sólida, imprescindibles para crear un producto de calidad. Por úl- timo, como parte de la calidad en el proceso, las actividades de revisión son funda- mentales de implementar. El modelo de calidad ISO 25010 define dos modelos de calidad. El modelo de calidad en el uso describe cinco características que son apropiadas a la hora de considerar el uso del producto en un contexto específico. El modelo de calidad del producto describe ocho características que se enfocan en las naturalezas dinámica y estática de los sistemas informáticos. Modelo de calidad en el uso: - Efectividad: la precisión y exactitud con que los usuarios logran sus metas. - Eficiencia: los recursos que se gastan para lograr las metas de los usuarios de ma- nera completa y con la precisión deseada. - Satisfacción: utilidad, confianza, placer y comodidad. - Liberación del riesgo: mitigación de los riesgos económicos, de la salud, de seguri- dad y ambientales. - Cobertura del contexto: plenitud y flexibilidad. Modelo de calidad del producto: - Idoneidad funcional: completo, correcto y apropiado. - Eficiencia en el rendimiento: sincronización, uso de recursos y capacidad. - Compatibilidad: coexistencia e interoperabilidad. - Facilidad de uso: adecuación, facilidad de aprendizaje, operabilidad, protección de errores, estética y accesibilidad. - Confiabilidad: madurez, disponibilidad, tolerancia a fallos y capacidad de recupera- ción. - Seguridad: confidencialidad, integridad, rendición de cuentas y autenticidad. - Facilidad de mantenimiento: modularidad, reutilización, capacidad de modificación y facilidad de prueba. - Portabilidad: adaptabilidad, capacidad de instalación y facilidad de reemplazo. Seguridad del Software | 23 El modelo de calidad en el uso ayuda a enfatizar la importancia de la satisfacción del cliente en la evaluación de la calidad del software. El modelo de calidad del producto señala la importancia de evaluar los requerimien- tos funcionales y no funcionales para el producto software. 3.4.- El dilema de la calidad del software Bertrand Meyer explicó lo que se conoce como el dilema de la calidad: “Si producimos un sistema de software que tenga una calidad terrible, perdemos ya que nadie querrá comprarlo. Si, por otro lado, invertimos un tiempo infinito, un esfuerzo extremada- mente grande y enormes cantidades de dinero para crear la pieza de software abso- lutamente perfecta, entonces tardará demasiado tiempo en completarse y será tan costoso de producir que nuestro negocio se arruinará de todas formas. Por lo tanto, la gente de la industria trata de llegar a ese mágico término medio en donde el pro- ducto es lo bastante bueno como para que lo rechazen de inmediato”. Está bien que los profesionales del desarrollo de software se esfuercen por producir sistemas de alta calidad, aplicando las prácticas recomendadas al intentar eso. Pero, la situación descrita por Meyer es real y representa lo que se conoce como el dilema de la calidad del software, y cuando nos enfrentamos a ese dilema es muy importante tratar de encontrar y lograr un equilibrio: el suficiente esfuerzo para producir una ca- lidad aceptable sin enterrar el proyecto. A su vez, es importante ser conscientes del impacto de los sistemas, y del presu- puesto destinado a su construcción. El modelo de proceso del software debe proveer criterios claros para orientar a los desarrolladores a determinar lo que es en realidad “suficientemente bueno” para el dominio de la aplicación previsto. Entonces, se debe actuar con cuidado y con prudencia cuando aplique lo “suficientemente bueno” para la calidad del software que esté desarrollando. 3.5.- Calidad y Seguridad del Software Como se mencionó al principio de la unidad, calidad y seguridad del software son dos trabajan en conjunto. La seguridad del software es una actividad de aseguramiento de la calidad que se enfoca en la identificación y evaluación de riesgos potenciales que pueden afectar al software de manera negativa y provocar la falla del sistema. Es más fácil penetrar en el software que no exhibe una alta calidad, y como conse- cuencia, el software de baja calidad puede incrementar de manera indirecta el riesgo de seguridad con los costos y problemas que lo acompañan. Por lo tanto, para asegurar la calidad, debemos analizar los potenciales riesgos de nuestro software. 3.5.1.- Análisis de Riesgos Un riesgo en el software es un evento potencial que, si sucede, tiene un impacto negativo en mi sistema. Este impacto de los riesgos está relacionado a cuáles son las implicaciones tanto técnicas como operativas al momento de producirse el inci- dente, y qué tan crítica puede ser la consecuencia que produzca. El impacto puede ser bajo, situación que no afecta de manera significativa el producto y puede solucio- narse fácilmente e ir avanzando hasta un nivel de impacto alto, donde la materializa- ción de ese tipo de riesgo puede causar problemas muy graves impidiendo o retra- sando de manera muy considerable la solución o arreglo del producto. Seguridad del Software | 24 La probabilidad del riesgo es la probabilidad de materialización de ese riesgo y se debe analizar qué tan factible es que ocurra para poder conjugar este valor con el impacto y poder así obtener la criticidad del mismo. La criticidad del riesgo se define a partir de una matriz de probabilidad y de impacto del riesgo, por lo tanto, se puede proponer la siguiente matriz para tener una referencia. Matriz de probabilidad del impacto Impacto Probabilidad Bajo Medio Alto Frecuente Medio Crítico Crítico Probable Bajo Medio Crítico Posible Bajo Medio Medio Improbable Bajo Bajo Medio Figura 3.1.- Matriz de probabilidad del impacto A partir de este análisis, se puede obtener la prioridad de cada riesgo, y a continua- ción se debe proponer para cada uno de ellos, un plan de contingencia, es decir una estrategia a seguir cuando estos riesgos ocurran, que permita tomar decisiones de manera oportuna para evitar la propagación del riesgo, disminuir el daño, retraso y demás inconvenientes que puedan impactar en el producto. Para gestionar los riesgos, se proponen las siguientes etapas: 1.- Identificación de los riesgos: Como parte de la gestión del proyecto se identifican y definen los riesgos potenciales que pueden influir negativamente en un proceso o en el producto software que se está desarrollando. 2.- Proyección del riesgo: Cada riesgo se evalúa más a fondo, determinando la pro- babilidad general de ocurrencia del riesgo combinada con su consecuencia ge- neral, es decir, con el impacto del mismo. 3.- Planeación del riego: Durante este paso, el equipo evalúa los riesgos más altos y desarrollan un plan para aliviarlos utilizando controles de riesgo específicos, es decir, se especifica un plan de contingencia para ellos. 4.- Monitoreo del riesgo: Se debe hacer un seguimiento de los riesgos y del plan ge- neral para monitorear y rastrear continuamente los riesgos nuevos y existentes. 3.6.- Revisiones: un enfoque recomendado Las revisiones son un “filtro” para el flujo de trabajo del proceso de software. Si son muy pocas, el flujo es “sucio”. Si son demasiadas, el flujo se ralentiza de manera drástica. Las revisiones se aplican en varios puntos durante el proceso y sirven para descubrir errores y defectos. Estas revisiones “purifican” los productos de trabajo, incluyendo los modelos de requerimientos y diseño, el código y la prueba de datos. Un error es un problema de calidad que se descubre antes de liberar el software a los usuarios finales. Un defecto es un problema de calidad que se descubre después de liberar el soft- ware a los usuarios finales. Los errores y los defectos tienen impactos económicos, de negocios, psicológicos y humanos muy diferentes. Los desarrolladores de software deben esforzarse por Seguridad del Software | 25 encontrar y corregir tantos errores como sea posible antes de que el cliente o el usua- rio final los encuentren. Entre los profesionales del software, el consenso general es que los defectos y erro- res, fallas y bugs son sinónimos, es decir, que el punto en el tiempo en el que se encontró el problema no influye en el término usado para describir el problema. 3.6.1.- Revisiones Técnicas Formales Una revisión técnica formal (RTF) es una actividad de control de calidad del software que realizan los ingenieros del software y demás integrantes del equipo. Los objetivos de la RTF son: 1.- Descubrir errores en la función, lógica o implementación de cualquier represen- tación del software. 2.- Verificar que el software bajo revisión cumpla sus requerimientos. 3.- Asegurar que el software se haya representado de acuerdo a los estándares predefinidos. 4.- Lograr que se desarrolle de una manera uniforme. 5.- Hacer que el proyecto sea más manejable. Además, la RTF sirve para el entrenamiento de los desarrolladores junior que pueden observar los distintos enfoques del software, para promover el respaldo y continui- dad, ya que varias personas del equipo pueden familiarizarse con parte del software que tal vez no hubieran podido ver de otra forma. Cada RFT se lleva a cabo como una reunión y tendrá éxito solo si se planea, controla y atiende de manera apropiada. Los lineamientos para realizar las revisiones técnicas formales deben establecerse por adelantado, distribuirse a todos los revisores, todos deben aceptarlos y todos deben acatarlos. A continuación, se enumeran un conjunto mínimo de estos linea- mientos: 1.- Revisar el producto, no el productor. 2.- Establecer una agenda y mantenerla. 3.- Limitar el debate y la refutación. 4.- Enunciar las áreas problemáticas, pero no tratar de resolver todos los problemas señalados. 5.- Tomar notas por escrito. 6.- Limitar el número de participantes e insistir en la preparación de todos por ade- lantado. 7.- Desarrollar una lista de comprobación para cada producto que posiblemente se vaya a revisar. 8.- Asignar recursos y tiempo de programación para cada RTF. 9.- Realizar una capacitación coherente para todos los revisores. 10.- Revisar las revisiones anteriores. En un ambiente ideal, todo producto de desarrollo de software se someterá al menos a una revisión técnica formal. En el mundo real del desarrollo de software, los recursos son limitados y el tiempo es corto. Como consecuencia, por lo general se omiten las revisiones, aun cuando se reconoce su valor como mecanismo de control de calidad. Seguridad del Software | 26 3.7.- Revisiones ágiles Si no se detectan los defectos lo antes posible, puede ser costos en términos de tiempo y recursos. Ignorar la deuda técnica no hace que desaparezca. En el marco de trabajo ágil Scrum, hay varios lugares donde se realizan revisiones formales e informales. De todos ellos, vamos a destacar dos, que son determinantes para el éxito del producto. La reunión de revisión del producto es una reunión que se realiza al finalizar cada iteración, y sigue lineamientos similares a los presentados en la sección anterior. En esta reunión se presentan las funcionalidades de software funcionando a los usuarios y se evalúan de acuerdo a si cumplen con lo esperado, calidad y utilidad entre otros aspectos. Se registran las sugerencias de los usuarios, se definen ajustes y se nego- cia el próximo alcance. Es una reunión muy valiosa donde se ponen en juego muchos de los valores ágiles, y es fundamental para que el producto desarrollado sea el es- perado, se entregue en tiempo y forma, con calidad y seguridad. La reunión de retrospectiva del equipo es una reunión que se realiza al finalizar también cada iteración, que consiste en la revisión de cómo trabajaron en equipo los integrantes del grupo de trabajo asignado al desarrollo del software. Se revisan as- pectos que salieron bien durante esa iteración y que deben continuar aplicando, como también aquellos que no salieron bien y cómo mejorarlos o cambiarlos. Es una reunión que intenta aportar a la mejora continua como equipo. También se realizan otras revisiones, como ser en la reunión de planificación de cada iteración, cuando se revisan las historias de usuario que se van a incluir y se las ordena de acuerdo a su prioridad, la reunión diaria que es una forma informal de asegurar que todos los miembros del equipo estén trabajando en las mismas priori- dades y se puedan detectar los defectos a tiempo, entre otros momentos de revisión durante el proceso. ACTIVIDAD EN EL FORO Foro de debate: Calidad del software Identificar aspectos de calidad en un producto software y evaluarlos desde el punto de vista del usuario. Consigna del trabajo Para dos atributos de calidad del producto que usted elija, buscar y mencionar al menos un sistema software (web o app) que SI los contemple desde el punto de vista de usuario y al menos un sistema software (web o app) que NO los contemple. Ex- plique los criterios por los cuales usted considera que se tuvieron o no en cuenta estos atributos de calidad, y la experiencia que como usuario tiene en ambas situa- ciones. Evaluación Este trabajo se evalúa mediante la participación en el foro y la puesta en común con los demás compañeros. Seguridad del Software | 27 ACTIVIDAD INDIVIDUAL Tarea: Riesgos y Revisiones del Producto Aplicar análisis de riesgos y/o revisión técnica de producto para un caso práctico ele- gido por el alumno. Consigna de trabajo Para la construcción o desarrollo de algún producto en el que esté participando, puede ser software o no, elegir la realización de esta tarea según prefiera apli- car Análisis de Riesgo o Revisión Técnica Formal. Para aquellos alumnos que elijan la opción de RTF (Revisión Técnica Formal), de- berán presentar una RTF del producto en desarrollo. Este documento debe incluir la planificación de la revisión, que contemple al menos los siguientes aspectos: - Fecha, hora, lugar planificado de la reunión. - Aspectos a validar o áreas con potenciales problemas a revisar. - Validaciones propuestas. - Anotaciones de las validaciones. - Conclusiones de las comprobaciones realizadas. - Pasos a seguir para una próxima reunión. Puede realizar la reunión junto a otros revisores, caso en el cual debe incluir esta situación en su informe. Para aquellos alumnos que elijan la opción de Análisis de Riesgos, deberán pre- sentar el análisis de al menos 5 (cinco) riesgos potenciales del producto en desarrollo. Este documento debe incluir al menos los siguientes aspectos: - Identificación de los riesgos. - Breve descripción de cada uno. - Impacto de los riesgos, nivel del impacto y justificación. - Probabilidad de ocurrencia. - Prioridad de los mismos, en base a impacto y probabilidad. - Plan de contingencia de los riesgos. Evaluación Este trabajo se evalúa mediante la presentación individual de la tarea y la puesta en común con los demás compañeros. Seguridad del Software | 28 UNIDAD IV: Seguridad del software 4.1.- Introducción La necesidad de desarrollar aplicaciones seguras y, por lo tanto, tener en cuenta la seguridad en las metodologías de desarrollo es tan importante como tenerla en cuenta para la construcción de edificios o barcos. Desarrollar aplicaciones sin consi- derar la seguridad del producto que se está desarrollando, es como construir un edi- ficio sin las medidas necesarias para evitar una catástrofe como puede ser que se caiga en caso de un temblor. La interdependencia entre los sistemas de información en un contexto global como el actual, sugiere desde ya la necesidad de una aproximación global, y eso hace que la confiabilidad en la tecnología sea un concepto de aplicación universal y no parti- cular a un campo específico de aplicación. A pesar de ello, se ha demostrado que la tecnología actual no ha alcanzado aun el grado de madurez y seguridad requerido, pues es vulnerable a una gran cantidad de amenazas. Según estudios realizados, cerca del 90% de los incidentes de seguridad del software están causados por atacantes que han explotado fallos conocidos en él. Además, también se mostró que el 70% de los fallos del software en un conjunto de aplicaciones vinculadas al negocio electrónico, estaban relacionados con el diseño. Como se ha visto también en unidades anteriores, el software se degrada con el tiempo, se va volviendo obsoleto, por lo tanto, lo que vale en un momento en concreto puede no tener valor al cabo de seis meses. En este sentido, la ingeniería de software de desarrollo seguro es una disciplina de la ingeniería de software en la que se busca proporcionar garantías objetivas res- pecto a la seguridad del software desarrollado. Partiendo del axioma que indica que la seguridad absoluta no es alcanzable, el software seguro es capaz de minimizar el impacto de la mayoría de los ataques, tolerar aquellos que no pueda resistir, y recu- perarse rápidamente y con el menor impacto de aquellos otros que no pueda tolerar. Uno de los retos actuales para la aplicación de cualquier técnica orientada a mejorar la calidad y la seguridad del software es el cambio de mentalidad en el desarrollador, así como, en muchos casos, la compleja integración de estas técnicas en los proce- sos ya existentes, con los costos que esto conlleva. Por lo tanto, la seguridad del software es más que software operacional seguro con contraseñas sólidas y cifrado. Es el desarrollo de software aplicando modelos y téc- nicas para desarrollar software seguro. Los hechos nos demuestran que resulta urgente mejorar los procesos de ingeniería de software en pro de desarrollar sistemas de información más robustos y seguros que aporten la confianza necesaria a la sociedad. 4.2.- Propiedades del software seguro Si bien con las metodologías y los estándares relacionados con el desarrollo de soft- ware se busca mantener altos niveles de confiabilidad y control de la solución infor- mática, la seguridad informática y sus principios de diseño seguro no suelen ser una parte obligatoria de dichos estándares. Cuando una aplicación transmite o almacena información confidencial, la aplicación es responsable de garantizar que los datos almacenados y transferidos estén cifrados Seguridad del Software | 29 y no puedan obtenerse, alterarse o divulgarse fácilmente de forma ilícita. El objetivo fundamental de la seguridad informática se basa en preservar los siguientes puntos: - Confidencialidad: el software debe asegurar que cualquiera de sus características, los activos que administra y su contenido son accesibles sólo para las entidades autorizadas e inaccesibles para el resto. El acceso a la información está limitado a usuarios autorizados. Los datos deben protegerse de la observación o divulgación no autorizada tanto en tránsito como almacenada. - Integridad: el software y los activos del sistema solo pueden ser modificados por usuarios autorizados. Esta propiedad se debe preservar durante el desarrollo del software y su ejecución. Los datos deben protegerse al ser creados, alterados o borrados maliciosamente por atacantes no autorizados. - Disponibilidad: el software debe estar operativo y ser accesible a los usuarios au- torizados siempre que se requiera, y debe desempeñarse con una performance adecuada para que los usuarios puedan realizar sus tareas de forma correcta y dar cumplimiento a los objetivos de la organización que lo utiliza. - Trazabilidad: todas las acciones relevantes relacionadas con la seguridad de una entidad que actúa como usuario se deben registrar y trazar con el objetivo de disponer de datos para la realización de auditorías; de esta forma, la trazabilidad debe ser posible tanto durante la ocurrencia de las acciones registradas como a posteriori. - No repudio: constituye la habilidad de prevenir que una entidad que actúa como usuario desmienta o niegue la responsabilidad de acciones que han sido ejecutadas. 4.3.- Principios de diseño seguro de aplicaciones Los efectos de vulnerar la seguridad del software se pueden describir en términos de los efectos sobre las propiedades mencionadas en el apartado anterior. A continua- ción, se sugieren una serie de principios orientados al diseño seguro de aplicaciones: 1.- Minimizar el área de la superficie de ataque Cada característica que se añade a una aplicación incrementa su complejidad y au- menta también el riesgo de la aplicación en su conjunto. Una nueva característica implica un nuevo punto de ataque. Uno de los factores claves para reducir el riesgo de una aplicación recae en la reducción de la superficie de ataque. Pueden eliminarse posibles puntos de ataque si se deshabilitan módulos o componentes innecesarios para la aplicación, por lo que, si se detecta una vulnerabilidad de seguridad en ese módulo, la aplicación no se verá amenazada. 2.- Seguridad por defecto Del lado de los desarrolladores, constituye una práctica habitual utilizar opciones de configuración de seguridad reducidas para evitar que dichas configuraciones compli- quen el desarrollo. Si, para su implementación, la aplicación requiere de característi- cas que obligan a reducir o cambiar la configuración de seguridad predeterminada, se recomienda estudiar sus efectos y consecuencias, para lo que hay que realizar pruebas específicas de auditorías de seguridad. 3.- Privilegios mínimos Según el principio del mínimo privilegio, se recomienda que las cuentas de usuarios tengan la mínima cantidad de privilegios necesarios. Asimismo, se aconseja que los procesos se ejecuten únicamente con los privilegios necesarios para completar sus tareas. De esta manera, se limitan los posibles daños que podrían producirse si se ve comprometido el proceso. Seguridad del Software | 30 Si un atacante llegase a tomar el control de un proceso en un servidor o comprome- terse una cuenta de usuario, los privilegios concedidos determinarán, en gran me- dida, los tipos de operaciones que podrá llegar a realizar dicho atacante; por ejemplo, si cierto servidor solo requiere acceso de lectura a la tabla de una base de datos, bajo ninguna condición deberían darse privilegios administrativos a los usuarios si no resultan necesarios. 4.- Validación de datos de entrada Se debe garantizar que la aplicación sea robusta ante todas las posibles formas de entrada de datos, ya sean proporcionados por el usuario, por la infraestructura, por entidades externas o por base de datos. Una premisa fundamental reside en no confiar en los datos que el usuario pueda intro- ducir, ya que este tiene todas las posibilidades de manipularlos. La debilidad de segu- ridad más común en aplicaciones es la falta de validación apropiada de las entradas del usuario o del entorno. Esta debilidad origina casi todas las principales vulnerabili- dades de las aplicaciones, tales como inyecciones de código, inserción de secuencia de comandos, ataques al sistema de archivos o desbordamiento de memoria. Las aplicaciones deben validar todos los datos introducidos por el usuario antes de realizar cualquier operación con ellos. La validación podría incluir el filtrado de carac- teres especiales o el control de la longitud de los datos introducidos. Esta medida preventiva protege a la aplicación de usos incorrectos accidentales o de ataques de- liberados por parte de los usuarios. 5.- Defensa en profundidad Con defensa en profundidad nos referimos a definir una estrategia de seguridad es- tándar en la que se establezcan varios controles de defensa en cada una de las capas y subsistemas de la aplicación. Estos puntos de control ayudan a garantizar que solo los usuarios autenticados y autorizados puedan obtener el acceso a la siguiente capa y sus datos. 6.- Control seguro de errores Es necesario controlar las respuestas cuando se produce algún error y no mostrar en ellas información que pudiera ayudar al atacante a descubrir datos acerca de cómo ha sido desarrollada la aplicación o cómo funcionan sus procedimientos. La informa- ción detallada de los errores producidos no debería ser mostrada al usuario, sino que tendría que ser enviada al fichero de log correspondiente. 7.- Separación de funciones Un punto importante consiste en la separación de funciones entre los distintos perfiles de la aplicación. Por otra parte, determinados roles deben contar con un nivel de con- fianza más elevado que los usuarios normales, como es en caso del administrador, que posee privilegios avanzados, como administrar el reto de usuarios del sistema o configurar política de contraseñas, así como definir parámetros de la aplicación. 8.- Evitar seguridad por oscuridad La seguridad de una aplicación no debería depender del secreto o confidencialidad de su diseño o implementación. Si se intentan ocultar secretos mediante el uso de nombres de variables engañosos o de ubicaciones de archivos no habituales, no se estará mejorando la seguridad. La seguridad basada en la oscuridad es un control de Seguridad del Software | 31 seguridad débil, especialmente si se trata del único control. Esto no significa que mantener secretos constituya una mala idea; significa que la seguridad de los siste- mas claves no debería basarse, exclusivamente, en mantener detalles oscuros. La seguridad ha de fundamentarse en políticas de contraseñas, diseño de una arqui- tectura sólida tanto a nivel aplicación como a nivel de comunicaciones de red reali- zando controles de auditoría de manera periódica. 4.4.- Controles proactivos OWASP OWASP (Open web Application Security Project) es un proyecto de código abierto dedicado a determinar y combatir las causas que hacen que el software sea inseguro. Este proyecto provee de una serie de recursos basados, sobre todo, en guías y he- rramientas, para que los proyectos web sean lo más seguros posible, tanto desde el punto de vista de desarrollo como de la evaluación de la seguridad de estos. Para los desarrolladores y auditores de seguridad, ofrece una gran cantidad de re- cursos para ayudar a llevar a cabo un S-SDLC (Secure Software Development Life Cycle), es decir, un ciclo de vida de desarrollo de software seguro. El objetivo del proyecto es intentar ayudar a los desarrolladores de software a com- prender qué, por qué, cuándo, dónde y cómo probar aplicaciones web. Los desarro- lladores pueden usar este framework como plantilla para construir sus propios pro- gramas de prueba o para evaluar los procesos de otros desarrolladores. Esta organización presenta cada año los 10 riesgos más comunes, entre los que se pueden destacar para el año 2022, los siguientes: - Desbordamiento del búfer: no validar el tamaño de la información que se recibe en una función con manejo de memoria. - Cross-site scripting (XSS): inyección de código malicioso en páginas web del lado del cliente. - SQL injection: inyección de código SQL malicioso para acceder a la BD. - Validación de entradas incorrectas: no validar los datos de entrada, tipos de datos, etc. - Autenticaciones incorrectas: no validar permisos de acceso. - Code injection: inyección de código fuente malicioso en la aplicación para su ejecución. Los principales controles proactivos que OWASP recomienda y que deberían incluirse en cada proyecto de desarrollo de software, se pueden destacar los siguientes: - Verificación de la seguridad desde las primeras etapas de desarrollo. - Validación de las entradas del cliente. - Desbordamiento del búfer. - Gestión de sesiones. - Implementación de controles de acceso. - Implementación de controles de identidad y autenticación. - Autenticación por múltiples factores. - Manejo de errores y excepciones. 4.5.- Metodologías de desarrollo de software seguro La seguridad ha pasado de ser un requerimiento no funcional, que podría implemen- tarse como parre de la calidad del software, a un elemento primordial de cualquier aplicación. Para hacer frente a atacantes y expertos en explotar vulnerabilidades de las aplicaciones, se necesita la implementación de metodologías que contemplen en Seguridad del Software | 32 su proceso de desarrollo de software la inclusión de la seguridad como elemento básico en la arquitectura de cualquier aplicación o producto de software. La clave de un software seguro es el proceso de desarrollo utilizado. Muchos de los defectos relacionados con la seguridad del software se pueden evitar si los desarro- lladores conocieran mejor las técnicas que los atacantes utilizan para reconocer las implicaciones de su diseño y las posibilidades de implementación desde el punto de vista de la seguridad, así como los riesgos que originan dicha implementación. Una metodología de desarrollo de software, que incorpore mejoras en el sentido de incluir la seguridad en el ciclo de desarrollo, debe proporcionar un marco integrado que permita promover la seguridad del software a lo largo de todo el ciclo de vida de desarrollo. Existen varias metodologías que establecen una serie de pasos en búsqueda de un software más seguro y capaz de resistir ataques. Entre ellas, se pueden mencionar Correctness by Construction (CbyC) y Security Development Life Cycle (SDLC). 4.5.1.- Security Development Life Cycle - SDLC La mayoría de las vulnerabilidades en el software se pueden solucionar en la fase de desarrollo de los procesos de desarrollo de las aplicaciones. Con la metodología Se- curity Development Life Cycle (SDLC), es posible desarrollar software de calidad desde el primer momento del propio proyecto disponiendo de iteraciones que deben ser ejecutadas durante la vida del propio software. Obtener un 100% de seguridad resulta imposible, pero estamos poniendo los cimientos para reducir notablemente el número de vulnerabilidades que puedan llegar a producir en un proceso de desarrollo de aplicaciones o productos software. Uno de los mejores métodos para evitar que aparezcan errores de seguridad en las aplicaciones de producción reside en mejorar el ciclo de vida de desarrollo, al incluir seguridad en cada una de sus fases. Un SDLC es una estructura impuesta en el desarrollo de artefactos de software. En la figura que se muestra a continuación, se presenta un modelo SDLC genérico. Figura 4.1.- Fases de la metodología SDLC SDLC es un proceso para mejorar la seguridad de software propuesto por Microsoft, formado por 7 fases y 16 actividades enfocadas a mejorar la seguridad del desarrollo de un producto de software. Seguridad del Software | 33 Las prácticas que propone SDLC van desde una etapa de entrenamiento sobre te- mas de seguridad, pasando por análisis estático, análisis dinámico y testing del có- digo, hasta conseguir un plan de respuesta a incidentes. Existen dos versiones del SDLC: la versión que utiliza metodologías tradicionales y la orientada al desarrollo ágil. La primera resulta más apropiada para aquellos equi- pos de desarrollo y proyectos más grandes que no sean susceptibles a cambios du- rante el proceso. La segunda desarrolla el producto de manera incremental y en la frecuencia de la ejecución de las actividades para el aseguramiento de la seguridad, la versión ágil sería recomendable utilizarla para desarrollo de aplicaciones web. A continuación, se presentan las 7 fases propuestas por SDLC: Figura 4.2.- Flujo de las fases de SDLC Las 7 fases y 16 actividades que componen dicha metodología se pueden resumir en la siguiente tabla: Figura 4.3.- Fase y actividades de SDLC La reducción de las debilidades explotables comienza con la especificación de los requerimientos de seguridad del software, junto a los requisitos que pueden haber sido pasados por alto. El software que incluye requerimientos de seguridad, tales como restricciones de seguridad sobre las conductas del proceso y la resistencia y tolerancia de fallos intencionados, presenta más probabilidades de ser diseñado para permanecer fiable y seguro ante los ataques. Al integrar la seguridad en cada fase del SDLC, permite un enfoque holístico de la seguridad de las aplicaciones, la cual aprovecha los procedimientos que ya existen en la organización. Se debe tener en cuenta que, si bien los nombres de las diversas Seguridad del Software | 34 fases pueden cambiar dependiendo del modelo SDLC que se utilice en cada organi- zación, cada fase conceptual incluye definir, diseñar, desarrollar, implementar y man- tener la aplicación. La formación en pruebas de seguridad también ayuda a los desarrolladores a adquirir la mentalidad adecuada para probar una aplicación desde la perspectiva de un ata- cante, esto permite que cada organización considere los problemas de seguridad como parte de sus responsabilidades. ACTIVIDAD EN EL FORO Título: Seguridad: Accesos, Roles y Permisos Objetivo: Identificar y describir los riesgos para la seguridad del software, debido a la gestión de los usuarios que acceden al mismo, sus roles y permisos. Consigna: Indicar al menos dos riesgos que se puedan presentar para un producto software, si no se cuenta con una buena configuración de accesos, roles y usuarios. Para cada riesgo, explicar brevemente en qué consiste el mismo dentro del producto software de una organización y si es posible, acompañe de ejemplos concretos cada uno de ellos. Cada alumno debe abrir un tema en el foro, con su nombre y el producto software analizado. Seguridad del Software | 35 UNIDAD V: Prueba del software 5.1.- Introducción La prueba consiste en un conjunto de actividades que pueden planearse por adelan- tado y realizarse de forma sistemática, con el objetivo de descubrir errores. En el caso del software, se busca descubrir errores que se cometieron sin querer a la hora de diseñarlo y construirlo. Por esta razón, se recomienda definir una plantilla de prueba del software, en la cual se definirán un conjunto de pasos en los que se colocarán técnicas específicas de diseño de los casos de prueba y métodos de prueba, para el proceso del software. Las pruebas de software representan el mayor porcentaje de esfuerzo técnico en el proceso del software. Sin importar el tipo de software que se construya, una estrate- gia de planificación, ejecución y control de pruebas sistemáticas comienza por con- siderar los elementos pequeños de software y avanza hacia el software como un todo. Algunas de las recomendaciones fundamentales para realizar la prueba son las si- guientes: - Para realizar una prueba efectiva, es necesario llevar a cabo revisiones técnicas. Al hacer esto se eliminarán muchos errores antes de que comience la prueba. - La prueba comienza a nivel de componente y progresa “hacia afuera” en torno a la integración de todo el sistema software. - Existen diversas técnicas de prueba apropiadas a cada enfoque de desarrollo de software y en distintos momentos del tiempo del proceso. - Las pruebas las realizan el desarrollador del software y para proyectos de mediana a gran envergadura un grupo de pruebas independiente. - La prueba y la depuración son actividades diferentes, pero la depuración debe aco- modarse en cualquier estrategia de prueba. Los casos de prueba deben poder rastrearse hasta los requerimientos del software. El objetivo principal del diseño de los casos de prueba es derivar un conjunto de pruebas que tengan la mayor probabilidad de descubrir errores en el software. Para lograr este objetivo, se usan dos categorías diferentes de técnicas de diseño de casos de prueba, las cuales son las pruebas de caja blanca y las pruebas de caja negra, las cuales se describen en secciones posteriores. 5.2.- Enfoque estratégico para la prueba de software Una estrategia para la prueba del software incorpora un conjunto de tácticas que acomodan las pruebas de bajo nivel necesarias para verificar que un pequeño seg- mento de código fuente se haya implementado en forma correcta, además de prue- bas de alto nivel que validen las funciones principales del sistema respecto a los requerimientos del cliente. Debido a que los pasos de la estrategia de prueba ocurren en un momento en que la presión del plazo de entrega comienza a aumentar, el progreso debe ser medible y los problemas deben salir a la superficie lo antes posible. La prueba de software a su vez tiene que ver con los conceptos de verificación y validación. La verificación se refiere al conjunto de tareas que aseguran que el soft- ware implemente una función específica de forma correcta. La validación se refiere Seguridad del Software | 36 a un conjunto distinto de tareas que aseguran que el software que se creó pueda identificarse con los requerimientos del cliente. De otra forma, podrían referirse de la siguiente manera: Verificación: “¿Estamos creando el producto de manera correcta?” Validación: “¿Estamos creando el producto correcto?” No se puede probar para introducir calidad. Si la calidad no está ahí antes de comen- zar la prueba, tampoco estará ahí cuando uno termine de probar. La calidad se in- corpora al software mediante el proceso de ingeniería de software; las pruebas no pueden aplicarse como una corrección al final del proceso. La apropiada aplicación de métodos y herramientas, las revisiones técnicas y un proceso sólido de gestión y medición: todo esto conduce a una calidad que se confirma durante el proceso de pruebas. El desarrollador de software siempre es responsable de probar las unidades indivi- duales o componentes del programa, para asegurar que cada una desempeñe la función o exhiba el comportamiento para el cual se diseñó. En muchos casos, el di- señador también realiza la prueba de integración de la arquitectura del software de manera completa. El rol de un grupo de pruebas independiente (ITG) es eliminar los problemas inhe- rentes asociados al hecho de que el constructor pruebe lo que construyó. El desarro- llador y el ITG trabajan de manera coordinada durante el proyecto de software para asegurar que se realicen pruebas minuciosas y que el desarrollador esté disponible para corregir los errores que se descubran. Como panorama general, se puede ver el proceso de desarrollo del software como el espiral que se muestra en la figura 5.1 y se lo recorre hacia adentro, comenzando con la ingeniería de sistema hasta llegar a la codificación. Figura 5.1.- Estrategia de Prueba Una estrategia para las pruebas de software también puede verse en el contexto de la figura anterior. Las pruebas unitarias comienzan en el vórtice de la espiral y se concentran en cada unidad o componente del software según su implementación en código fuente. Las pruebas siguen avanzando hacia afuera a lo largo de la espiral hasta las pruebas de integración, en donde el enfoque está en el diseño y la cons- trucción de la arquitectura del software. Si damos otra vuelta hacia afuera por la es- piral, nos encontramos con las pruebas de validación, en donde se validan los Seguridad del Software | 37 requerimientos establecidos como parte del modelado de requerimientos contra el software que los creó. Por último, llegamos a las pruebas de sistema, en donde el software y otros elementos del sistema se evalúan en conjunto. 5.3.- Pruebas de caja blanca Las pruebas de caja blanca, algunas veces conocidas como pruebas de caja de cris- tal o pruebas estructurales, son una filosofía de diseño de casos de prueba que utiliza la estructura de control de los componentes para derivar casos de prueba que garan- ticen que todas las rutas independientes dentro de un módulo se hayan usado al menos una vez, que se ejecuten todas las decisiones lógicas en sus lados verdaderos y falso, que se ejecuten todos los ciclos en sus límites y dentro de sus límites opera- cionales y que se empleen las estructuras de datos internas para asegurar su validez. Es por ello, que las pruebas de caja blanca se realizan con el código fuente. Las pruebas de caja blanca de software se basan en un examen minucioso de los detalles de implementación procedimentales y de implementación de las estructuras de datos. Las rutas lógicas a través del software y las colaboraciones entre los com- ponentes son el enfoque de las pruebas de integración de caja blanca. Algunas pruebas de caja blanca son por ejemplo las pruebas de ruta base y las prue- bas de estructura de control. A primera vista pareciera que unas pruebas de caja blanca muy minuciosas lograrían obtener programas de software 100% correctos, pero las pruebas exhaustivas pre- sentan ciertos problemas de logística, ya que el número de rutas posibles para pro- gramas incluso pequeños puede ser muy grande, y es por ello que se recomienda que se tomen las rutas más lógicas importantes. 5.4.- Pruebas de caja negra Las pruebas de caja negra, conocidas también como pruebas de comportamiento o funcionales, se enfocan en los requerimientos funcionales del software. No son una alternativa a las pruebas de caja blanca, sino son un enfoque complementario que probablemente descubra una clase distinta de errores que los métodos de caja blanca. Las pruebas de caja negra se basan en los requerimientos especificados en la etapa de análisis del software a evaluar. Las pruebas de caja negra tratan de encontrar errores en las siguientes categorías: - funciones incorrectas o faltantes - errores de interfaz - errores en las estructuras de datos o en el acceso a base de datos externas - errores de comportamiento o rendimiento - errores de inicialización y terminación Una de las pruebas de caja negra más frecuentes y útiles son las pruebas de inter- faz, las cuales se usan para comprobar que el componente del programa acepte la información que recibe en el orden y formato de datos apropiados. En general, se consideran parte de las pruebas de integración, puesto que la mayoría de los com- ponentes no son programas independientes, y que, por lo tanto, es importante ase- gurar que, cuando se integre el componente en el programa en evolución, no se in- terrumpa su compilación. Seguridad del Software | 38 5.5.- Integración continua La integración continua es la práctica de combinar componentes en el incremento del software evolutivo una o más veces cada día. Esta es una práctica común para equi- pos que siguen prácticas de desarrollo ágil como XP o DevOps. Las pruebas de in- tegración deben llevarse a cabo con rapidez y eficiencia sin que un equipo intente tener siempre un programa funcional preparado como parte de una entrega continua. Las pruebas de humo son un enfoque de pruebas de integración que pueden usarse cuando un equipo ágil desarrolla software de un producto mediante el uso de tiempos de compilación en incrementos cortos. Este enfoque de las pruebas de humo incor- pora las siguientes actividades: 1.- Los componentes de software que se hayan traducido en código se integran a una compilación, la cual incluye todos los archivos de datos, bibliotecas, módulos reutilizables y componentes requeridos para implementar una o más funciones del producto. 2.- Se diseñan una serie de pruebas para exponer los errores que eviten que la compilación desempeñe su función de manera adecuada. La intención es des- cubrir los errores graves que tengan la mayor probabilidad de retrasar el proyecto de software. 3.- La compilación se integra con otras compilaciones y se realiza a diario la prueba de humo de todo el producto en su forma actual. La frecuencia diaria ofrece una evaluación realista del proceso de pruebas de integración. El objetivo principal de este tipo de pruebas es asegurar que los componentes recién agregados no interfieran en el comportamiento de los componentes existentes que se probaron previamente. 5.6.- Pruebas especializadas para la movilidad El mismo sentido de urgencia que impulsa los proyectos de aplicaciones móviles (Mobile-App) domina también todos los proyectos de movilidad. A las partes intere- sadas les preocupa perderse una ventana de mercado y presionan para introducir la App en su mercado objetivo. Las actividades técnicas que ocurren a finales del pro- ceso, como las pruebas de rendimiento y seguridad, algunas veces se recortan. Las pruebas de facilidad de uso, que deben ocurrir durante la fase de diseño, pueden terminar diferidas hasta justo antes de la entrega. Estos errores pueden ser catastró- ficos. Para evitar esta situación, los miembros del equipo deben asegurarse de que cada producto de trabajo exhiba una alta calidad, o los usuarios cambiarán a un pro- ducto de la competencia. 5.6.1.- Lineamientos de las pruebas móviles Las Mobile Apps que se ejecutan por completo en un dispositivo móvil pueden pro- barse mediante el uso de los métodos de prueba tradicionales, ya descritos en sec- ciones anteriores. También, pueden probarse mediante el uso de emuladores que se ejecuten en computadoras personales. En general, los usuarios esperan que las Mobile Apps sean conscientes del contexto y ofrezcan experiencias de usuario personalizadas en base a distintos criterios como por ejemplo la ubicación física del dispositivo. Se espera que las Mobile Apps ofrezcan gran parte de la compleja funcionalidad y confiabilidad que encontramos en aplicaciones de escritorio, pero residen en Seguridad del Software | 39 plataformas móviles con recursos relativamente limitados. Los siguientes lineamien- tos proveen la base para las pruebas de aplicaciones móviles: - Entender el panorama de redes y dispositivos antes de las pruebas para identificar cuellos de botella. - Realizar pruebas en condiciones de prueba reales no controladas. - Seleccionar la herramienta de automatización de pruebas adecuada. - Usar herramientas para ponderar las plataformas de dispositivos para identificar la combinación de hardware y software más crítica que debemos probar. - Revisar el flujo funcional de un extremo a otro en todas las plataformas posibles, al menos una vez. - Realizar pruebas de rendimiento, de GUÍA y de compatibilidad mediante el uso de dispositivos reales. - Medir el rendimiento en cuestiones realistas de tráfico inalámbrico y carga de usua- rios. 5.6.2.- Estrategias de prueba Las estrategias para probar aplicaciones móviles adoptan los principios básicos para todas las pruebas de software. Sin embargo, la naturaleza única de las Mobile Apps exige la consideración de varios aspectos especializados: - Pruebas de experiencia de usuario: los usuarios participan en las primeras etapas del proceso de desarrollo para asegurar que la Mobile App esté a la altura de las expectativas en cuanto a la facilidad de uso y accesibilidad de las partes interesadas en todos los dispositivos soportados. - Pruebas de compatibilidad de dispositivos: los encargados de las pruebas verifican que la Mobile App funcione de manera correcta en todas las combinaciones reque- ridas de hardware y software. - Pruebas de rendimiento: los encargados de las pruebas revisan los requerimientos no funcionales exclusivos para dispositivos móviles, por ejemplo, tiempos de des- carga, velocidad del procesador, capacidad de almacenamiento, disponibilidad de energía, entre otros. - Pruebas de conectividad: los encargados de las pruebas se aseguran de que la Mobile App pueda acceder a las redes o servicios web necesarios y pueda tolerar un acceso lento o interrumpido a la red. - Pruebas de seguridad: los encargados de las pruebas se aseguran de que la Mobile App no comprometa los requerimientos de seguridad o privacidad de sus usuarios. - Pruebas en estado salvaje: la aplicación de prueba bajo condiciones realistas en dispositivos de usuarios reales, en una variedad de entornos de red de todo el mundo. - Pruebas de certificación: los encargados de las pruebas se aseguran de que la Mo- bile App cumpla con los estándares establecidos por las tiendas de aplicaciones que la distribuirán. La tecnología por sí sola no basta para garantizar el éxito comercial de una Mobile App. Los usuarios abandonan las Mobile Apps con rapidez si no funcionan bien o no cumplen las expectativas. Para desarrollar una estrategia de pruebas de Mobile Apps se requiere un entendi- miento de las pruebas de software y de los desafíos que hacen de los dispositivos móviles y su infraestructura de red único. Además de un conocimiento detallado de los enfoques de prueba convencionales, el que prueba una Mobile App debe tener una buena comprensión de los principios de telecomunicaciones y estar consciente de las diferencias y capacidades de las plataformas de sistemas operativos móviles. Seguridad del Software | 40 5.6.3.- Aspectos de las pruebas de experiencia de usuario En un mercado saturado de productos que proveen la misma funcionalidad, los usua- rios elegirán la Mobile App más fácil de usar. La interfaz de usuario y sus mecanismos de interacción son visibles para los usuarios, por lo tanto, es muy importante probar la calidad de la experiencia del usuario que proporciona la App para asegurar que cumpla con sus expectativas. Hay mucho más en la creación de una buena interfaz de usuario de una Mobile App que el simple hecho de reducir el tamaño de una interfaz de usuario proveniente de una aplicación de escritorio o web ya existente. Algunos de estos aspectos son los siguientes: - Pruebas de gestos multitáctiles como deslizar, acercar, desplazarse, seleccionar, etc. - Entrada de teclado virtual. - Entrada y reconocimiento de voz. - Alertas y condiciones extraordinarias. Por lo tanto, las pruebas de movilidad se enfocan en los elementos de calidad como contenido, función, estructura, usabilidad, uso del contexto, facilidad de navegación, rendimiento, gestión de energía, compatibilidad, interoperabilidad, capacidad y segu- ridad. Seguridad del Software | 41 ACTIVIDAD INDIVIDUAL Título: Pruebas de caja negra Tarea: Armar un plan de pruebas, formado por casos de prueba de caja negra, es decir, desde el punto de vista de la funcionalidad para un usuario, para un producto software elegido por el alumno. Consigna del trabajo Para un producto software elegido por el alumno, se solicita armar un Plan de Prue- bas, compuesto por casos de prueba de caja negra, es decir, desde el punto de vista del usuario, para probar funcionalidad del producto software. Puede utilizar la siguiente plantilla, completando al menos 10 (diez) casos de prueba, o un modelo similar. Puede acompañar los casos de prueba con más información o con capturas de pantalla para mejor ilustración. En caso de no poder realizar efectivamente la prueba de las funcionalidades, com- pletar sólo las columnas que hagan referencia a la planificación de los casos, inclu- yendo resultados esperados. PLAN DE PRUEBAS - MÓDULO/SISTEMA Descripción Valores Resultados Resultados Resultado Responsable Fecha Id Funcionalidad de la prueba entrada esperados obtenidos de la prueba Prueba realización 1 Ingreso de número Probar el ingreso de 25123123 El DNI ingresado no El DNI ingre- Exitoso Juan Perez 21/3/2023 de documento un número de docu- existe. sado no existe mento inexistente 2 Ingreso de número Probar el ingreso de 25..123123 El valor ingresado Error en la pan- Rehacer Juan Perez 21/3/2023 de documento un número de docu- no tiene el formato talla mento con formato esperado. Por favor, incorrecto ingrese nuevamen- te. 3 Segu

Seguridad del Software - PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue