Análisis de casos de abuso e implementación del modelo de especificación de software para requerimientos de seguridad en un caso de uso

Texto completo

(1)UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES. ANÁLISIS DE CASOS DE ABUSO E IMPLEMENTACIÓN DEL MODELO DE ESPECIFICACIÓN DE SOFTWARE PARA REQUERIMIENTOS DE SEGURIDAD EN UN CASO DE USO. PROYECTO DE TITULACIÓN Previa a la obtención del título de:. INGENIERO EN SISTEMAS COMPUTACIONALES AUTOR (ES): SANTANA SANTANA KATHERINE MARIUXI FIALLOS LALAMA STEVE PIETRO. TUTOR: Ing. Tania Peralta Guaraca, M. Sc. GUAYAQUIL – ECUADOR 2019.

(2) REPOSITORIO NACIONAL EN CIENCIA Y TECNOLOGÍA FICHA DE REGISTRO de tesis TÍTULO Y SUBTÍTULO: “ANÁLISIS DE CASOS DE ABUSO E IMPLEMENTACIÓN DEL MODELO DE ESPECIFICACIÓN DE SOFTWARE PARA REQUERIMIENTOS DE SEGURIDAD EN UN CASO DE USO” AUTOR/ES: REVISOR: Santana Santana Katherine Ing. Manuel Reyes Wagnio MBA. Fiallos Lalama Steve Pietro INSTITUCIÓN: Universidad de FACULTAD: Facultad de Ciencias Matemáticas y Guayaquil Físicas CARRERA: Carrera de Ingeniería en Sistemas Computacionales FECHA DE PUBLICACIÓN: N. DE PAGS: 150 ÁREAS TEMÁTICAS: Seguridad, Ingeniería de Software PALABRAS CLAVE: Casos de Abuso, Robustez, Seguridad RESUMEN: El presente proyecto propuesto se orienta en la importancia de la elaboración de un modelo de especificaciones de software para requerimiento de seguridad en un caso de uso con finalidad de apoyar y dar solución en la prevención de ataques maliciosos de la denominada “PLATAFORMA TECNOLÓGICA PARA CONTRIBUIR LA PLANEACIÓN URBANA DE LA CIUDAD DE GUAYAQUIL DIRIGIDO A LA TRANSPORTACIÓN”, se tomará como modelo para el siguiente estudio el caso de uso de recolección de datos, mediante el cual se reveló una inexactitud en este ejemplo, por qué no contaba con la implementación de los respectivos caso de seguridad en dicho caso de uso específico, no obstante la inexistencia del mismo nos da un lugar a una seguridad inconsistente, ya que puede ser utilizado por diversos agentes maliciosos o hackers, que tienen objetivos variados tales como pueden ser, apoderarse desde la extracción de la información, manipulación de la misma , hasta la inoperatividad de la plataforma en mención, para poder evitar estos posibles ataques o abusos sobre la plataforma en los distintos modelos de caso de uso, se realiza minuciosamente la respectiva implementación del caso de seguridad sobre el módulo de recolección de datos ya antes mencionado del cual se encontró que no cumplía con las especificaciones de seguridades necesarias en donde nace el caso de abuso dentro de la plataforma con una o varias vulnerabilidades, esto con lleva a que disminuya su vulnerabilidad ante la presencia de atacantes maliciosos, esto nos llevara al a correcta implementación del modelo de especificaciones de software de la plataforma SEGURA y ROBUSTA, el cual es el objetivo primordial de este trabajo de titulación. N. DE REGISTRO N. DE CLASIFICACIÓN: DIRECCIÓN URL (tesis en la web): ADJUNTO URL (tesis en la web): ADJUNTO PDF: CONTACTO CON AUTORES/ES:. CONTACTO EN LA INSTITUCIÓN:. X SI NO Teléfono: E-mail: 0968161114 [email protected] 0939304395 [email protected] Nombre: Ab. Juan Chávez Atocha Teléfono: 2307729 E-mail: [email protected]. II.

(3) APROBACIÓN DEL TUTOR. En mi calidad de Tutor del trabajo de investigación, "ANÁLISIS DE CASOS. DE. ABUSO. E. IMPLEMENTACIÓN. DEL. MODELO. DE. ESPECIFICACIÓN DE SOFTWARE PARA REQUERIMIENTOS DE SEGURIDAD EN UN CASO DE USO" elaborado por la Srta. Santana Santana Katherine Mariuxi y el Sr. Fiallos Lalama Steve Pietro, Alumnos no titulado de la Carrera de Ingeniería en Sistemas Computacionales, Facultad de Ciencias Matemáticas y Físicas de la Universidad de Guayaquil, previo a la obtención del título de Ingeniero en Sistemas Computacionales, me permito declarar que luego de haber orientado, estudiado y revisado, la Apruebo en todas sus partes.. Atentamente,. Ing. Tania Peralta Guaraca, M. Sc. TUTOR. III.

(4) DEDICATORIA A Dios por permitirme llegar a este momento tan especial en mi vida, ser mi inspiración, motor en todo momento, a mis padres por guiarme, darme su apoyo incondicional, pilar fundamental que me impulsan a salir adelante diariamente, a dos personas muy importantes en mi vida Kenia Vinces Moreno y Steve Fiallos Lalama con las cuales empecé este recorrido que es la educación universitaria, para concluir a una pequeña angelita que pronto llegara a mi vida para ellos todo este esfuerzo y la satisfacción de cumplir una meta más. Santana Santana Katherine Mariuxi. A Dios primeramente por permitirme cumplir esta meta propuesta en mi vida, mis fuerzas en todo momento, a mis dos madres que me forjaron en lo que hoy en día soy, a mi padre el cual me enseña del inmenso amor que Dios nos brinda a todos, a mis tres padres en general por darme ese apoyo incondicional, el cual se convirtió en mi pilar fundamental que me impulsa a salir adelante diariamente, a dos personas primordiales en mi vida Katherine Santana Santana y Kenia Vinces Moreno con las cuales empecé mi educación universitaria y me ayudaron en varios momentos de falencias que tuve, para concluir y no menos importantes a mis dos hermosos y bellos hijos Pietro Santiago Fiallos Chero y Kaitlyn Aísha Fiallos Santana que llenan mi vida de felicidad y me dan esa fuerza a seguir adelante, para ellos todo este esfuerzo y la satisfacción de cumplir una meta más. Fiallos Lalama Steve Pietro. IV.

(5) AGRADECIMIENTO. Agradezco principalmente a Dios, mis familiares por su apoyo brindado en el transcurso de mi carrera y muy especialmente a la Ing. Tania Peralta Guaraca, M. Sc. Ya que fue mi guía y supo transmitir sus conocimientos para el desarrollo de nuestro trabajo de titulación, no solo como docente sino también como amiga, consejera por su paciencia, dedicación y apoyo.. Santana Santana Katherine Mariuxi. Agradezco a Dios, mis familiares, a las personas que siempre me apoyaron en todo momento, muy especialmente a la Ing. Tania Peralta Guaraca, M. Sc.. Por. ser. mi. guía. y. transmitirme. sus. conocimientos para el desarrollo de nuestro trabajo de titulación, no solo como docente sino también como amiga, por su paciencia, y apoyo a pesar de los percances presentados durante este periodo.. Fiallos Lalama Steve Pietro. V.

(6) TRIBUNAL PROYECTO DE TITULACIÓN. Ing. Gustavo Ramírez Aguirre, M.Sc. DECANO DE LA FACULTAD CIENCIAS MATEMÁTICAS Y FÍSICAS. Ing. Inelda Martillo Alcívar, Mgs. DIRECTOR DE LA CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES. Ing. Manuel Reyes Wagnio MBA. PROFESOR REVISOR DEL ÁREA TRIBUNAL. Ing. Tania Peralta Guaraca, M. Sc. PROFESOR TUTOR DEL PROYECTO DE TITULACIÓN. Ab. Juan Chávez Atocha, Esp. SECRETARIO. VI.

(7) DECLARACIÓN EXPRESA. “La responsabilidad del contenido de este Proyecto de Titulación, me corresponden exclusivamente; y el patrimonio intelectual de la misma a la UNIVERSIDAD DE GUAYAQUIL”. _____________________________ SANTANA SANTANA KATHERINE MARIUXI. _____________________________ FIALLOS LALAMA STEVE PIETRO. VII.

(8) UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES. ANÁLISIS DE CASOS DE ABUSO E IMPLEMENTACIÓN DEL MODELO DE ESPECIFICACIÓN DE SOFTWARE PARA REQUERIMIENTOS DE SEGURIDAD EN UN CASO DE USO. Proyecto de Titulación que se presenta como requisito para optar por el título de INGENIERO EN SISTEMAS COMPUTACIONALES. Autores: SANTANA SANTANA KATHERINE MARIUXI C.I.095060421-5. FIALLOS LALAMA STEVE PIETRO C.I.092843771-4. Tutor: Ing. Tania Peralta Guaraca, M. Sc. Guayaquil, Noviembre del 2018. VIII.

(9) CERTIFICADO DE ACEPTACIÓN DEL TUTOR. En mi calidad de Tutor del proyecto de titulación, nombrado por el Consejo Directivo de la Facultad de Ciencias Matemáticas y Físicas de la Universidad de Guayaquil.. CERTIFICO: Que he analizado el Proyecto de Titulación presentado por los estudiantes SANTANA SANTANA KATHERINE MARIUXI Y FIALLOS LALAMA STEVE PIETRO, como requisito previo para optar por el título de Ingeniero en Sistemas Computacionales cuyo título es:. “ANÁLISIS DE CASOS DE ABUSO E IMPLEMENTACIÓN DEL MODELO DE ESPECIFICACIÓN DE SOFTWARE PARA REQUERIMIENTOS DE SEGURIDAD EN UN CASO DE USO”. Considero aprobado el trabajo en su totalidad.. Presentado por:. Autor: Santana Santana Katherine Mariuxi. CC N° 095060421-5 Autor: Fiallos Lalama Steve Pietro. CC N° 092843771-4 Tutor: Ing. Tania Peralta Guaraca, M. Sc.. Guayaquil, Noviembre del 2018. IX.

(10) UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES. Autorización para Publicación de Proyecto de Titulación en Formato Digital 1. Identificación del Proyecto de Titulación Nombre Alumno: SANTANA SANTANA KATHERINE MARIUXI Dirección: Coop. Carlomagno Mz. 2320 Sl.10 Teléfono: 0968161114 E-mail: [email protected] Nombre Alumno: FIALLOS LALAMA STEVE PIETRO Dirección: Coop. El Limonal Mz. 5 V.12 Teléfono: 0939304395 E-mail: [email protected] Facultad: Ciencias Matemáticas y Físicas Carrera: Ingeniería en Sistemas Computacionales Proyecto de titulación al que opta: Ingeniero en Sistemas Computacionales Profesor guía: Ing. Tania Peralta Guaraca, M. Sc. Título del Proyecto de titulación: “ANÁLISIS DE CASOS DE ABUSO E IMPLEMENTACIÓN DEL MODELO DE ESPECIFICACIÓN DE SOFTWARE PARA REQUERIMIENTOS DE SEGURIDAD EN UN CASO DE USO” Tema del Proyecto de Titulación: ANÁLISIS DE CASOS DE ABUSO 2. Autorización de Publicación de Versión Electrónica del Proyecto de Titulación A través de este medio autorizo a la Biblioteca de la Universidad de Guayaquil y a la Facultad de Ciencias Matemáticas y Físicas a publicar la versión electrónica de este Proyecto de titulación. Publicación electrónica: Inmediata X Después de 1 año. Santana Santana Katherine. Fiallos Lalama Steve. CC N° 095060421-5. CC N° 092843771-4. 3. Forma de envío: El texto del proyecto de titulación debe ser enviado en formato Word, como archivo .Doc. O .RTF y Puf para PC. Las imágenes que la acompañen pueden ser: .gif, .jpg o .TIFF. DVDROM. CDROM x. X.

(11) ÍNDICE GENERAL ÍNDICE GENERAL .................................................................................. XI ÍNDICE DE TABLAS .............................................................................. XIV ÍNDICE DE ILUSTRACIONES ............................................................... XVI ABREVIATURA ................................................................................... XVIII RESUMEN ............................................................................................. XIX ABSTRACT ............................................................................................ XX INTRODUCCIÓN .................................................................................. - 1 CAPÍTULO I.......................................................................................... - 3 PLANTEAMIENTO DEL PROBLEMA............................................ - 3 UBICACIÓN DEL PROBLEMA EN UN CONTEXTO ..................... - 4 SITUACIÓN CONFLICTO NUDOS CRÍTICOS .............................. - 5 CAUSAS Y CONSECUENCIAS DEL PROBLEMA ........................ - 5 DELIMITACIÓN DEL PROBLEMA ................................................ - 7 FORMULACIÓN DEL PROBLEMA ............................................... - 7 EVALUACIÓN DEL PROBLEMA ................................................... - 7 OBJETIVOS ....................................................................................... - 10 OBJETIVO GENERAL ................................................................ - 10 OBJETIVOS ESPECÍFICOS ....................................................... - 10 ALCANCES DEL PROBLEMA .................................................... - 11 JUSTIFICACIÓN E IMPORTANCIA .................................................... - 12 METODOLOGÍA DEL PROYECTO .................................................... - 13 -. XI.

(12) MODELO SCRUM....................................................................... - 13 ¿CÓMO FUNCIONA? ................................................................. - 13 METODOLOGÍA CUALITATIVA .................................................. - 17 MARCO TEÓRICO ............................................................................. - 25 ANTECEDENTES DEL ESTUDIO ............................................... - 25 FUNDAMENTACIÓN TEÓRICA .................................................. - 26 Ingeniería de software ................................................................. - 26 Qué es un caso de uso ............................................................... - 33 Caso de Abuso ............................................................................ - 34 FUNDAMENTACIÓN LEGAL ............................................................. - 36 PREGUNTA CIENTÍFICA A CONTESTARSE .................................... - 46 DEFINICIONES CONCEPTUALES .................................................... - 46 CAPÍTULO III...................................................................................... - 53 PROPUESTA TECNOLÓGICA ................................................... - 53 Análisis de factibilidad ................................................................. - 53 Factibilidad Operacional .............................................................. - 53 Factibilidad técnica ...................................................................... - 54 Factibilidad Legal ........................................................................ - 54 Factibilidad Económica ............................................................... - 55 Entregables del proyecto .................................................................. - 110 CAPÍTULO IV ................................................................................... - 111 Criterios de aceptación del producto o Servicio ......................... - 111 -. XII.

(13) RECOMENDACIONES ..................................................................... - 114 BIBLIOGRAFÍA ................................................................................. - 115 ANEXOS .......................................................................................... - 116 -. XIII.

(14) ÍNDICE DE TABLAS. Tabla 1 Causas y Consecuencias del problema ............................... - 6 Tabla 2. Delimitación del problema .................................................. - 7 Tabla 3. Metodología Cualitativa .................................................... - 19 Tabla 4.Recurso de Software ......................................................... - 55 Tabla 5. Gastos Generales ............................................................ - 55 Tabla 6. Costo Total del Proyecto .................................................. - 56 Tabla 7 Aplicación patrones de ataque a las diferentes fases del SDLC ................................................................................................................64 Tabla 8 Alcance de información de un patrón de ataque .....................66 Tabla 9 Alcance de información de un patrón de ataque # 2 ...............68 Tabla 10 Diferencias entre los casos de uso de seguridad y los casos de abuso ..................................................................................................77 Tabla 11 Metodologías de análisis de riesgos .....................................86 Tabla 12 Roles Scrum .................................................................... - 90 Tabla 13 HISTORIA DE USUARIO N.1 .......................................... - 93 Tabla 14 Burndown chart Sprint N. 1.............................................. - 94 Tabla 15. ESTIMACIÓN DE TIEMPO SPRINT N. 1 ....................... - 94 Tabla 16. Sprint N.1 ....................................................................... - 95 Tabla 17. HISTORIA DE USUARIO N.2 ......................................... - 99 Tabla 18. Burndown chart Sprint N. 2........................................... - 100 -. XIV.

(15) Tabla 19. ESTIMACIÓN DE TIEMPO SPRINT N. 2 ..................... - 100 Tabla 20. Sprint N. 2 .................................................................... - 101 Tabla 21. HISTORIA DE USUARIO N.3 ....................................... - 105 Tabla 22. Burndown chart Sprint N. 3........................................... - 106 Tabla 23. ESTIMACIÓN DE TIEMPO SPRINT N. 3 ..................... - 106 Tabla 24. Sprint N. 3 .................................................................... - 107 Tabla 25. Pila del Proyecto .......................................................... - 110 -. XV.

(16) ÍNDICE DE ILUSTRACIONES Ilustración 1 Caso de Uso ............................................................. - 47 Ilustración 2 Caso de Abuso ......................................................... - 48 Ilustración 3 Seguridad Informática ............................................... - 49 Ilustración 4 Caso de Mal Uso ...................................................... - 50 Ilustración 5 UML .......................................................................... - 51 Ilustración 6 Ingeniería de Software .............................................. - 51 Ilustración 7 Modelado de Datos ................................................... - 52 Ilustración 8 Seguridad en el Ciclo de vida del Software ....................57 Ilustración 9 Modelado de Ataques ....................................................60 Ilustración 10 Perspectivas de Modelado ...........................................61 Ilustración 11 Casos de Abuso ..........................................................73 Ilustración 12 Relación entre el caso de uso de seguridad y el de abuso asociado .......................................................................................76 Ilustración 13 Ingeniería de requisitos de seguridad ..........................79 Ilustración 14 Requisitos servicios de seguridad ................................80 Ilustración 15 Vista de alto nivel de las tareas y artefactos involucrados en la fase de requisitos .......................................................81 Ilustración 16 Análisis de riesgos .......................................................83 Ilustración 17 Patrones de diseño ................................................. - 88 Ilustración 18 Modelo de Caso de Uso ......................................... - 92 Ilustración 19 Burndown chart Sprint N. 1 ..................................... - 94 Ilustración 20 Modelo de Caso de Uso Implementando Seguridad - 98 XVI.

(17) Ilustración 21 Burndown chart Sprint N. 2 ................................... - 100 Ilustración 22 Implementación del Abuso en Modelo Caso de Uso- 104 Ilustración 23 Burndown chart Sprint N. 3 ................................... - 106 -. XVII.

(18) ABREVIATURA UML SDLC CAPEC CORAS OCTAVE. Lenguaje unificado de modelado Ciclo vital del desarrollo/diseño de sistemas Enumeración y Clasificación de Patrones de ataques comunes Sistema de Análisis de Riesgo Objetivo Consultivo Evaluación de amenazas, activos y vulnerabilidad operacionalmente crítica. XVIII.

(19) UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES. ANÁLISIS DE CASOS DE ABUSO E IMPLEMENTACIÓN DEL MODELO DE ESPECIFICACIÓN DE SOFTWARE PARA REQUERIMIENTOS DE SEGURIDAD EN UN CASO DE USO Autores: SANTANA SANTANA KATHERINE FIALLOS LALAMA STEVE Tutor: Ing. Tania Peralta Guaraca, M. Sc.. RESUMEN El presente proyecto propuesto se orienta en la importancia de la elaboración de un modelo de especificaciones de software para requerimiento de seguridad en un caso de uso con finalidad de apoyar y dar solución en la prevención de ataques maliciosos de la denominada “Plataforma Tecnológica Para Contribuir La Planeación Urbana De La Ciudad De Guayaquil Dirigido A La Transportación”. Se tomará como modelo para el siguiente estudio el caso de uso de recolección de datos, mediante el cual se reveló una equivocación en este ejemplo, por qué no contaba con la implementación de los respectivos caso de seguridad en dicho caso de uso específico, no obstante la inexistencia del mismo nos da un lugar a una seguridad inconsistente, ya que puede ser utilizado por diversos agentes maliciosos o hackers, que tienen objetivos variados tales como pueden ser, apoderarse desde la extracción de la información, manipulación de la misma, hasta la inoperatividad de la plataforma en mención, para poder evitar estos posibles ataques o abusos sobre la plataforma en los distintos modelos de caso de uso, se realiza minuciosamente la respectiva implementación del caso de seguridad sobre el módulo de recolección de datos ya antes mencionado del cual se encontró que no cumplía con las especificaciones de seguridades necesarias en donde nace el caso de abuso dentro de la plataforma con una o varias vulnerabilidades, esto conlleva a que disminuya su vulnerabilidad ante la presencia de atacantes maliciosos, y permitirá la correcta implementación del modelo de especificaciones de software de la plataforma segura y robusto, el cual es el objetivo primordial de este trabajo de titulación. Palabras Clave: Robusto, SDLC, UML, Caso de Uso, Caso de Abuso, Duplicidad, Seguridad, Vulnerabilidad, CAPEC.. XIX.

(20) UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES. ANALYSIS OF CASES OF ABUSE AND IMPLEMENTATION OF THE MODEL OF SOFTWARE SPECIFICATION FOR SECURITY REQUIREMENTS IN A CASE OF USE Autores: SANTANA SANTANA KATHERINE FIALLOS LALAMA STEVE Tutor: Ing. Tania Peralta Guaraca, M. Sc.. ABSTRACT This proposed project is oriented on the importance of developing a model of software specifications for security requirements in a use case in order to support and provide a solution in the prevention of malicious attacks of the so-called "Technological Platform To Contribute The Urban Planning Of The City Of Guayaquil Aimed At Transportation ", the case of the use of data collection will be taken as a model for the following study, through which an inaccuracy was revealed in this example, because it did not have the implementation of the respective security case in this case of specific use, despite the lack of it gives us a place to an inconsistent security, as it can be used by various malicious agents or hackers, which have various objectives such as, take over from the extraction of the information, manipulation of it, until the inoperability of the mentioned platform, in order to avoid these possible attacks or abuses on the platform in the different models of use case, the respective implementation of the security case is performed carefully on the aforementioned data collection module which was found not to comply with the specifications of necessary securities where the abuse case is born within the platform with one or more vulnerabilities, this leads to the reduction of its vulnerability in the presence of malicious attackers, and will allow the correct implementation of the software specification model of the safe platform and robust, which is the primary objective of this degree work.. Keywords: Robust, SDLC, UML, Use Case, Case of Abuse, Duplicity, Security, Vulnerability, CAPEC.. XX.

(21) INTRODUCCIÓN Al momento de diseñar el sistema el analista del mismo deberá tener en consideración la elaboración de los casos de abuso por cada caso de uso, sobre todo en la aplicación para crear un sistema confiable y poder cumplir con los estándares internacionales de calidad de un sistema, por ello la presente investigación y aplicación mostrará la manera en que un sistema no cumple con los lineamientos de seguridad y robustez.. En el capítulo I, presenta el planteamiento del problema que muestra el contexto en el que se desarrollan los casos de abuso, nudos críticos del trabajo, las causas y consecuencias del problema manifestados a través de un cuadro, la formulación que muestra una incógnita del tema de forma general y evaluación del problema de los aspectos que se van a considera; los objetivos tanto general como específico, los alcances planteados con el fin de cumplir cada objetivo específico y justificación del tema a desarrollar.. El capítulo II se describe los antecedentes de la investigación mencionando otros tipos de investigaciones que han sido parte de la investigación, la elaboración del marco teórico donde se respaldan todos los conceptos o nociones literarias que permitan fortalecer el contexto de la situación a la que se enfrenta la investigación, fundamentación legal. Este capítulo reúne definiciones y conceptos más relevantes para el correcto desarrollo de este proyecto.. -1-.

(22) El capítulo III, consiste en desarrollar el modelo, realizando la descripción en cada una de sus etapas, además de las herramientas utilizadas, la metodología bajo la cual se desarrolla, los entregables y criterios de validación del proyecto.. Finalmente, en el capítulo IV, se plantea la conclusión y recomendaciones con su respectiva bibliografía y anexos empleado en este proyecto.. Debemos tomar en cuenta que esta adaptación es parte fundamental para poder obtener un producto que cumpla con todos los requisitos que necesitamos para lograr obtener la satisfacción de nuestros usuarios.. -2-.

(23) CAPÍTULO I PLANTEAMIENTO DEL PROBLEMA El desarrollo de un sistema de software demanda de una serie de requisitos, procedimientos y tiempos determinados para su creación, cuyas inobservancias conllevan a que los modelos a crearse no cumplan con. las garantías básicas necesarias para su comercialización,. constituyéndose claramente que la no implementación de los casos de abusos en su creación, situación. que causa retrasos en el tiempo. estipulado para su desarrollo, además de desfase en la planificación, con consecuencias monetarias, pérdida de mercado y repercusión negativa de imagen.. Se llama caso de abuso al hecho de que para la creación de un software se. realicen. acciones. sin. contemplar. el. cumplimiento. de. los. procedimientos y requisitos para la operatividad del sistema, con el desconocimiento de los casos de abuso, nos da una brecha en la cual no podemos determinar si al momento que se realiza una acción no permitida, dentro de nuestro sistema nos conlleva a la pérdida significativa de data o inoperatividad de nuestro sistema.. En cuestiones de seguridad informática, en los últimos años, se han desarrollado multitud de aplicaciones web que acceden a bases de datos, -3-.

(24) al estar disponibles a través de la web, son más propensas a recibir ataques que permitan acceder o modificar la base de datos, es por ello que el tema de seguridad es de especial interés ya que las ausencias de ella en nuestros sistemas nos conllevan a situaciones críticas por lo que no se están tomando las medidas necesarias.. Cayendo en la recursividad de la no contemplación de requisitos necesarios para cubrir con los atributos básicos para que dicho sistema sea seguro, ya que los procesos se deberían particionar en diferentes programas por razones de seguridad.. UBICACIÓN DEL PROBLEMA EN UN CONTEXTO Es de conocimiento que el analista de sistemas al momento de diseñar el modelo de especificaciones de seguridad en un software, contemplará el proceso en los casos de uso a fin de cumplir con los requisitos especificados por el cliente o el usuario del sistema, uno de los inconvenientes que se presentan en esta fase es no contar con la implementación de los modelos de casos de abuso.. Lo que conllevaría en lo posterior a que la operatividad del sistema se vea afectada o colapse, problema de los casos de uso la falta de control de la seguridad, situación que este proyecto busca dar solución mediante la precautelación.. Encontramos entonces dentro del proceso de diseño de Casos de uso, la falta de implementación de un diseño de seguridad y protección de los casos de uso y esto, ocasiona que nuestra descripción y decisión con -4-.

(25) respecto a los requerimientos funcionales del sistema, colapse o se vea afectada.. Por otra parte, como no existe un acuerdo entre el usuario y analista de sistemas no se pueden definir los límites del mismo, provocando la inestabilidad y que no contemple todas las especificaciones necesarias para conseguir un sistema cuente con las seguridades necesarias y el acceso al mismo permitiendo la escalabilidad y a su vez la robustez.. SITUACIÓN CONFLICTO NUDOS CRÍTICOS Para los casos de abuso en los casos de uso de seguridad podemos observar a continuación los siguientes nudos críticos: ✓ Inconsistencia en las etapas del desarrollo del sistema. ✓ No se contemplan seguridades en la etapa de desarrollo. ✓ No se definen límites para el desarrollo del sistema. ✓ Pocos sistemas con implementación de casos de abuso. ✓ Desconocimiento de técnicas para la elaboración de casos de abuso.. CAUSAS Y CONSECUENCIAS DEL PROBLEMA El siguiente cuadro describe las causas y consecuencias que en la investigación se pudieron observar en cuanto al caso de uso del Módulo de Recolección de la plataforma antes mencionada:. -5-.

(26) Tabla 1 Causas y Consecuencias del problema. Causas Hay ausencias en las etapas de desarrollo de software.. Se encuentran escasos atributos de seguridades y protección.. Ausencia de contexto y limitación del sistema a desarrollar no se encuentra puntualizada. Poca importancia en las técnicas o métodos para implementar seguridades en los sistemas. Carencia de confiabilidad del caso de uso de ingreso de datos a la plataforma.. Consecuencias No se están llevando lineamientos para evitar inconsistencias en los casos de uso y por ende existirán puntos de inseguridad en los mismos. Si no se definen las protecciones o seguridades en el proceso de desarrollo del sistema, esto provoca un desfase de carácter crítico teniendo como resultado la propagación de información con responsabilidad de las instituciones o empresas de los clientes. Los límites no definidos nos provocan una brecha la cual es en algunos casos imperceptible por el analista de sistema provocándonos un punto crítico en nuestro sistema. La carencia de técnicas o métodos, nos traslada a un gran error el cual provoca un des lineamiento dentro del proceso del ciclo de vida del software de nuestro sistema, lo que arrastra un retraso al momento de su desarrollo. No contemplan actividades en la seguridad El desconocimiento de esta adaptación, nos conlleva a la deficiencia de seguridad de nuestro sistema, provocando que nuestra credibilidad como compañía desarrolladora se vea reflejada o afectada con un aspecto no apropiado ante los clientes.. Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia. -6-.

(27) DELIMITACIÓN DEL PROBLEMA Tabla 2. Delimitación del problema. Campo. Área. Desarrollo. Diseño del. de Sistemas. software. Aspecto. Casos de Abusos. Tema. Desarrollo. Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia. FORMULACIÓN DEL PROBLEMA ¿Cuál es el beneficio que brindará el análisis de casos de abuso e implementación. del. modelo. de. especificación. de. software. para. requerimientos de seguridad en un caso de uso de recolección de Datos?. EVALUACIÓN DEL PROBLEMA Delimitado:. En el Desarrollo de nuestro sistema se debe delimitar los procesos que se verán afectados con la correcta implementación del caso de abuso, ya que si no existe esta delimitación podemos poner en riesgo nuestro sistema.. -7-.

(28) Claro:. Nuestro tema a tratar se puede comprender de manera clara ya que la no implementación de los casos de abuso podría afectar de carácter crítico a nuestro sistema.. Evidente:. Hoy en día podemos encontramos un sin número de sistemas a los cuales, no se les implementaron los respectivos casos de abuso por ende han sido víctimas de abuso, en estas brechas que causo la no implementación de los mismo.. Relevante:. Dentro de un aspecto educativo, podemos definir que la importancia del estudio de esta adaptación y la correcta implementación al momento del desarrollo de nuestro sistema nos brindara como resultado un sistema confiable y seguro.. Original:. La presente investigación con relevancia a nuestro tema nos confirma que en la actualidad no todos los sistemas cumplen con los requisitos indispensables para poder ser catalogados como sistemas con una confiabilidad impecable sin embargo con el correcto estudio, desarrollo e implementación del mismo nos brindara el fin deseado.. -8-.

(29) Factible:. Para tal efecto si el desarrollo de los casos de abuso es considerado en la planificación del sistema, nos brindara la factibilidad en la implementación, ayudara a determinar posibles brechas que se estaban omitiendo involuntariamente.. Identifica los productos esperados:. Si bien es cierto la utilización de nuestro estudio nos traslada a la creación de un modelado de amenazas, donde el sistema es puesto bajo un abuso ya sea este voluntario o involuntario, y sobre el mismo se podrán realizar las correcciones pertinentes si estas las ameritan.. Susana Viale del Carril, (2005) indica que “Delimitar el tema quiere decir poner límite a la investigación y especificar el alcance de esos límites. En la delimitación del tema no basta con identificar una rama de la ciencia, pues tales ramas cubren variada gama de problemas. Es preferible señalar, de acuerdo a las propias inclinaciones y preferencias, un tema reducido en extensión.”. La factibilidad, indica la posibilidad de desarrollar un proyecto, tomando en consideración la necesidad detectada, beneficios, recursos humanos, técnicos, financieros, estudio de mercado, y beneficiarios. (Gómez, 2000, p. 24).. -9-.

(30) Donde se desea obtener lo siguiente: -. Caso de Uso con implementación de seguridad. -. Caso de Uso con implementación de seguridad y Caso de Abuso.. OBJETIVOS OBJETIVO GENERAL Implementar técnicas que permitan desarrollar un estudio sobre el caso de abuso con respecto al desarrollo de software y la necesidad de ajustar las técnicas necesarias que permitan mejorar la seguridad, a través de un caso de uso de requerimientos de información de la plataforma tecnológica. llamada. “PLATAFORMA. TECNOLÓGICA. PARA. CONTRIBUIR LA PLANEACIÓN URBANA DE LA CIUDAD DE GUAYAQUIL DIRIGIDO A LA TRANSPORTACIÓN”.. OBJETIVOS ESPECÍFICOS •Identificar y clasificar, las interacciones que los casos de uso deben realizar para crear un sistema robusto y seguro. •Crear un modelo de la construcción de casos de abuso a través de técnicas para el desarrollo de software y como proteger la data. •Implementar las técnicas y el modelo para mejorar la seguridad en el caso de uso de recolección de datos en el sistema denominado “Plataforma Tecnológica Para Contribuir La Planeación Urbana De La Ciudad De Guayaquil Dirigido A La Transportación”.. - 10 -.

(31) ALCANCES DEL PROBLEMA En el presente estudio se realizará en la “Plataforma Tecnológica Para Contribuir La Planeación Urbana De La Ciudad De Guayaquil Dirigido A La Transportación”. Por medio del cual se ejecutará la identificación y clasificación en el Módulo de Recolección, de las interacciones que los casos de uso deben realizar para crear un sistema robusto y seguro se puede puntualizar los siguientes que se encuentra incluido:. 1. Realizar un estudio acerca de los casos de uso y su contraparte los casos de abuso para poder lograr la identificación de las interacciones dentro de los casos de uso.. 2. Analizar las técnicas de seguridad que deben de implementar los casos de usos según los requerimientos del usuario.. 3. Reconocer el comportamiento del caso de uso de recolección de datos y establecer la falta de seguridad en los mismos ya que esta falencia puede perjudicar nuestro sistema.. 4. Crear el modelo de casos de abuso el cual contenga las técnicas para evitar los casos de abuso.. 5. Implementar el modelo desarrollado.. 6. Señalar las técnicas recomendadas para el mismo.. - 11 -.

(32) JUSTIFICACIÓN E IMPORTANCIA En muchas ocasiones usamos solo los requisitos que están consignados en casos de uso para realizar la estimación del proyecto, para considerar tiempos y recursos, para definir la arquitectura del software y para diseñar el sistema.. Solo cuando ya es muy tarde alguien recuerda que hay otras funcionalidades a diseñar e implementar y que posiblemente afecten no solo la arquitectura del sistema, sino también los tiempos y los recursos necesarios para terminar el producto, es por ello necesario realizar una investigación sobre los casos de abuso y como afectan a un sistema.. Un sistema confiable debe ser capaz de cumplir con los atributos de un software de calidad, cuya parte fundamental en la elaboración de un sistema es su diseño, y la forma en cómo se desarrollan los procesos; por lo que es importante establecer un tipo de interacción completa entre un sistema y uno más actores, donde el resultado de la interacción es perjudicial para el sistema, uno de los actores o uno de los stakeholders del sistema.. No podemos definir que haya integridad solo si decimos que existen transacciones correctas entre los actores y el sistema. En vez de ello, definimos un abuso en términos de interacciones que resultan en algún daño real; esto lo estudian los casos de abuso, por lo que es importante conocer de qué manera evitar que un sistema no cuente con las seguridades requeridas. - 12 -.

(33) METODOLOGÍA DEL PROYECTO En este proyecto utiliza un conjunto de metodologías, tal como se detalla a continuación:. MODELO SCRUM El prototipo que se va a desarrollar se verá apoyado a través del modelo Scrum que es utilizado para el desarrollo de software, por ser ágil, flexible y sobre todo en ser fácil de entender. Scrum permite llevar a cabo los avances de la aplicación por medio de la asignación y desglose de cada tarea que realiza el equipo de trabajo, el nivel de su detallado y perspectiva, supera en mucho al que pueda hacer un arquitecto o analista funcional en casos de uso siendo minucioso mediante un reporte también conocido como sprint, con la finalidad de poder cumplir el proyecto en el tiempo estipulado. Según (Barbosa, Silva, & Moraes, 2016)nos dice que es el marco de trabajo ágil más popular, que se concentra especialmente en cómo gestionar las tareas dentro de un entorno de desarrollo basado en equipos de trabajo.. ¿CÓMO FUNCIONA? Con el uso de esta metodología el cliente se compromete con el proyecto, el cual ira tomando forma con cada iteración que se realice, lo que facilitara realizar el alineamiento del software con los requerimientos acordes a las necesidades. Los beneficios que ofrece Scrum: •. Flexibilidad con respecto a cambios. - 13 -.

(34) •. Reducción de riesgos.. •. Alcanza una mayor productividad.. •. Se obtiene un software de alta calidad.. •. Predicciones de tiempo.. Sprint es el corazón del scrum nos permite tomar medidas sobre las propuestas. a. realizarse. mediante. una. perspectiva:. tecnológica,. metodológica, organizativa para que el desarrollo del proyecto tenga una buena iniciación y mejor terminación, consiste en definir las características y funcionalidades con el mayor número de detalles posibles Componentes Scrum Roles Scrum. Según (Sims & Johnson, 2011):. Scrum Máster •. Encargado de gestionar el proyecto.. •. Es considerado gerente de proyecto o líder de proyecto.. •. Responsable de la promulgación de valores y practicas Scrum.. •. Su principal trabajo es mitigar o eliminar los impedimentos en el desarrollo del proyecto.. El Scrum Team (El equipo Scrum) •. Equipo está conformado típicamente por 5 o 6 personas.. •. Funcionalidad. cruzada. (control. de. calidad,. programadores,. diseñadores). •. Los miembros deben trabajar a tiempo completo en el equipo. - 14 -.

(35) •. El equipo es auto organizado.. Product Owner (Dueño de producto) •. Sabe lo que debe construirse.. •. Tradicionalmente es el cliente.. •. Típicamente un gerente de producto.. Actividades del proceso Scrum. Según (Schwaber & Sutherland, 2016):. Reunión de inicio del proyecto •. Reunión entre el propietario del producto y el Scrum Máster. •. Su objetivo es crear el Backlog del producto. Reunión de planificación de Sprint •. Reunión entre el propietario del producto, Scrum Máster y Scrum Team.. •. Su objetivo es crear el Sprint Backlog.. Sprint •. Conocido también como la unidad básica de desarrollo de trabajo en Scrum. - 15 -.

(36) •. Es un proceso contiguo con una iteración que sigue inmediatamente a la siguiente sin pausa.. •. Ninguna influencia externa puede interferir con el Team Scrum durante el desarrollo del Sprint.. •. Cada día al iniciar un Sprint se comienza con la reunión diaria de Scrum.. Reuniones de Scrum •. Es una reunión corta de 15 minutos de duración, que se realiza todos los días antes de que el Team Scrum comience a trabajar.. •. En la reunión participan el Scrum Máster y el Scrum Team.. •. No es una sesión para la resolución de problemas ni tampoco para recopilar información sobre quién está atrasado en el programa.. •. Es una reunión en la que los miembros del equipo se comprometen entre sí y con el Scrum Máster.. •. Es una buena manera para que un Scrum Máster esté al tanto del progreso del equipo.. Reunión de revisión de Sprint •. Se lleva a cabo al final de cada Sprint.. •. Se demuestra al propietario del producto la funcionalidad del proceso de negocio que se creó durante el Sprint.. - 16 -.

(37) Artefactos Scrum. Según (Layton, 2015):. Product Backlog •. Son los requerimientos para un sistema, expresados como una lista priorizada.. •. Es gestionado y propiedad del Product Owner. •. Por lo general se crea durante la reunión de inicio del proyecto. •. Se puede cambiar y priorizar antes de cada Sprint.. Sprint Backlog •. Es un subconjunto de tareas que define el trabajo a realizar en un Sprint.. •. Es creado solo por los miembros del Team Scrum.. •. Cada tarea tiene su propio estado.. •. Debe actualizarse todos los días.. METODOLOGÍA CUALITATIVA Se denomina metodología cualitativa a esta técnica, ya que se realiza de manera meticulosa, busca ser explicativo y exploratorio, podemos enfatizar que los resultados obtenidos son representativos, pero no pueden ser proyectados.. - 17 -.

(38) “Mejía Navarrete (2002) indica que la investigación cualitativa busca comprender la realidad en todas sus cualidades, es una estructura dinámica.”. “Estudia la realidad en su contexto natural, tal y como sucede, intentando sacar sentido de, o interpretar los fenómenos de acuerdo con los significados que tienen para las personas implicadas. La investigación cualitativa implica la utilización y recogida. de. una. gran. variedad. de. materiales—entrevista,. experiencia personal, historias de vida, observaciones, textos históricos, imágenes, sonidos – que describen la rutina y las situaciones problemáticas y los significados en la vida de las personas”. (Pag, 32). (Gregorio Rodríguez Gómez, Javier Gil Flores, Eduardo García Jiménez., 1996).. Mediante el método cualitativo se recopila información basados en los casos de usos ya que por medio de esta se construirá el conocimiento y comportamiento del mismo ante un caso de abuso, además se tendrá que tomar en consideración que para la práctica de la investigación cualitativa se resume en cuatro fases elementales que son:. FASES DE LA METODOLOGÍA CUALITATIVA. Para presentar este apartado se ha realizado un cuadro en el que se expone el tipo de metodología cualitativa la característica de cada una:. - 18 -.

(39) Tabla 3. Metodología Cualitativa. TIPO. DESCRIPCIÓN Reflexión: se concreta o detalla un marco teórico conceptual Preparatorita Diseño: define ejecución todas aquellas actividades a considerarse. Trabajo de Campo. Analítica. Informativa. obtención de datos verídicos. CARACTERÍSTICAS ✓ Conocimiento ✓ Experiencia ✓ Creación. ✓ ✓ ✓ ✓ ✓ ✓ ✓. está conformada por una serie de operaciones o tareas, que permite realizar la Reducción de datos. ✓. se obtiene una mayor comprensión del estudio realizado y se comparte dicha información. ✓ ✓ ✓ ✓ ✓. ✓ ✓ ✓. Habilidad Paciencia Visión Flexibilidad Adaptabilidad persistencia meticulosidad preparación teórica Categorizar la data recolectada Codificar la data recolectada transformar datos crear diagramas y matrices Analítico Impresionista Fundamentado Literario Crítico. Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia. Técnicas de investigación. Las técnicas de investigación son herramientas que se utilizan para recopilar datos”.. A continuación, se describirá las herramientas más. utilizadas para trabajos de investigación: - 19 -.

(40) Cuestionarios Tipos de cuestionarios • Cuestionarios cerrados. Los cuestionarios cerrados son probablemente el tipo con el que está más familiarizado. Este tipo de cuestionario se utiliza para generar. estadísticas. en. investigación. cuantitativa.. Estos. cuestionarios siguen un formato establecido, y la mayoría se pueden escanear directamente en un scanner para facilitar el análisis pueden producir mayores números (Balnaves & Caputi, 2001). • Cuestionarios abiertos. Los cuestionarios abiertos se utilizan en la investigación cualitativa, aunque algunos. investigadores. cuantificarán. las respuestas. durante la etapa de análisis.. El cuestionario no contiene casillas para marcar, sino que se deja una sección en blanco para el que el encuestado pueda escribir una respuesta. Como no hay respuestas estándar a estas preguntas, el análisis de datos es más complejo (Corral, 2010). • Cuestionarios mixtos Los cuestionarios mixtos tienden a usar una combinación de preguntas abiertas y cerradas. De esa manera, es posible averiguar cuántas personas usan un servicio y qué piensan de ese servicio en el mismo formulario. Muchos cuestionarios comienzan - 20 -.

(41) con una serie de preguntas cerradas, con casillas para marcar o escalas para clasificar, y luego terminan con una sección de preguntas abiertas para una respuesta más detallada. Estos cuestionarios son difundidos generalmente por internet y se paga a los encuestados (Balnaves & Caputi, 2001).. Entrevistas. Tipos de entrevistas • Entrevistas no estructuradas Las entrevistas no estructuradas, es cuando el investigador intenta lograr una comprensión holística del punto de vista o situación de los entrevistados. En este tipo de entrevista el participante es libre de hablar sobre lo que considere importante, con poca influencia del investigador.. Las personas por lo general asumen que este tipo de entrevista es la más fácil. Los investigadores tienen que poder establecer una buena relación con el participante. Las entrevistas no estructuradas pueden producir una gran cantidad de datos que pueden ser difíciles. de. analizar. (Díaz-Bravo,. Torruco-García,. Martínez-. Hernández, & Varela-Ruiz, 2013). • Entrevistas semiestructuradas La entrevista semiestructurada es el tipo más común de entrevista utilizada en la investigación cualitativa. En este tipo de entrevista, el investigador quiere conocer información específica, que puede - 21 -.

(42) compararse y contrastarse con la información obtenida en otras entrevistas. Para hacer esto, se deben hacer las mismas preguntas en cada entrevista. Para este tipo de entrevista, el investigador produce una lista de preguntas específicas o una lista de temas a discutir” (Meneses & Rodríguez, 2015). • Entrevistas estructuradas Las entrevistas estructuradas se utilizan con frecuencia en estudios de mercado. El entrevistador le hace una serie de preguntas y marca las casillas con su respuesta. Las entrevistas estructuradas se utilizan en la investigación cuantitativa y se pueden realizar personalmente, en línea o por teléfono” (Dawson, 2009). • Grupos focales Los grupos focales se pueden llamar también grupos de discusión o entrevistas grupales. Se les solicita a varias personas que se reúnan en un grupo para discutir un tema determinado. La discusión está dirigida por un moderador o facilitador que presenta el tema, hace preguntas específicas, controla las digresiones y detiene las conversaciones. Él se asegura de que ninguna persona domine la discusión mientras trata de asegurarse de que cada uno de los participantes haga una contribución. La discusión puede ser grabada (Dawson, 2009).. - 22 -.

(43) Técnica de validación. El juicio de expertos es un método de validación útil para verificar la fiabilidad de una investigación que se define como “una opinión informada de personas con trayectoria en el tema, que son reconocidas por otros como expertos cualificados en éste, y que pueden dar información, evidencia, juicios y valoraciones” (Escobar-Pérez y Cuervo-Martínez, 2008:29).. La evaluación mediante el juicio de expertos, método de validación cada vez más utilizado en la investigación, “consiste, básicamente, en solicitar a una serie de personas la demanda de un juicio hacia un objeto, un instrumento, un material de enseñanza, o su opinión respecto a un aspecto concreto” (Cabero y Llorente, 2013:14). Se trata de una técnica cuya realización adecuada desde un punto de vista metodológico constituye a veces el único indicador de validez de contenido del instrumento de recogida de datos o de información (Escobar Pérez, 2008); de ahí que resulte de gran utilidad en la valoración de aspectos de orden radicalmente cualitativo. Por ejemplo:. Al evaluar si los formularios de prueba son de dificultad similar, se pueden utilizar los juicios de expertos en un estudio para determinar la equivalencia. en. las. áreas,. complejidad. del. código,. complejidad. cognoscitiva y demanda comunicativa. Deberíamos tratar de proporcionar evidencias sobre la mayor cantidad de estos niveles que podamos (Weir, 2005:251). - 23 -.

(44) Validez y fiabilidad son los dos criterios de calidad que debe reunir todo instrumento de medición tras ser sometido a la consulta y al juicio de expertos con el objeto de que los investigadores puedan utilizarlo en sus estudios. Técnicas Aplicadas Para el presente estudio del proyecto se realizó un juicio de experto, aplicando a varios docentes de la carrera de Ingeniería en Sistemas Computacionales y Networking un cuestionario sobre el tema Casos de Abuso.. - 24 -.

(45) CAPÍTULO II MARCO TEÓRICO ANTECEDENTES DEL ESTUDIO Este trabajo de tesis tomará como ejemplo de estudio el caso de uso de recolección de datos de la “Plataforma Tecnológica Para Contribuir La Planeación Urbana De La Ciudad De Guayaquil Dirigido A La Transportación”, cuyo estudio previo no posee y el desarrollo del mismo es relacionado en trabajos.. Este capítulo se fundamentará completamente según un estudio realizado por docentes de la Universidad de los Andes, del Departamento de Sistemas, denominan a los casos de abuso como una adaptación de los casos de mal uso, nos sirve para la decisión y la documentación de Cuál sería su comportamiento o flujo del sistema y reacción ante el uso ilegitimo, como lo señalan (Correal & López, 2007, pág.111).. Según los pioneros de los casos de abuso, esta podría estar definida en “una especificación de un tipo de interacción completa entre un sistema y uno o más actores, donde los resultados de la interacción son perjudiciales para el sistema, uno de los actores o uno de las partes interesadas en el sistema” (John McDermott y Chris Fox - 1999). Estos casos fueron una adaptación del resultado de una técnica probada de modelado orientado a objetos, dentro de los casos de uso, para su interpretación y respectiva selección de requisitos de seguridad.. - 25 -.

(46) Estos casos amplían de manera favorable a la notación UML para realizar el correspondiente modelaje del abuso en los sistemas, John McDermott realiza un diagrama de casos de uso y también paralelamente el diagrama de caso de abuso. Estos diagramas fueron diseñados para ser elaborados e interpretados de manera individual, ya que para estos últimos no se ha creado una terminología o simbología especial que nos permita su respectiva diferenciación.. Son implementados con la misma simbología que los casos de uso, pero estos deben mantenerse separados para que se nos pueda realizar un poco más fácil su identificación tanto del diagrama de caso de uso como el diagrama de casos de abuso y ninguno de estos aparezca o se mal interprete de manera errónea.. FUNDAMENTACIÓN TEÓRICA A continuación, se detalla una descripción de algunas definiciones y teorías basadas en la propuesta para dinamizar el argumento de este estudio.. Ingeniería de software. El desarrollo de software se ha transformado en una de las disciplinas más importantes en la actualidad, ya que el consumo de productos software es cada vez mayor y la necesidad de dar soluciones a - 26 -.

(47) dificultades cotidianas con la tecnología se vuelve necesaria. Está claro que las personas no podemos vivir sin el software debido a que nos ayuda con nuestras tareas, a optimizar tiempos y hacer la vida más fácil.. Por otra parte, al referirse a ella como un conjunto de etapas parcialmente ordenadas. En el que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos son transformados en diseño, el diseño implementado en código, el código es probado y documentado para su uso operativo con la intención de obtener un producto de software de calidad.. Si bien es cierto el desarrollo de software requiere un conjunto de conceptos, herramientas, una metodología y un lenguaje propio que se extiende a la programación que es el pilar fundamental al momento de crear una aplicación. A este proceso también se le llama el ciclo de vida del software, que comprende las etapas por las que pasa un proyecto de software desde que es concebido hasta que está listo para usarse.. A continuación, se describen conceptos de varios autores sobre lo que la Ingeniería de Software. “Ingeniería del Software es la aplicación. práctica del. conocimiento científico en el diseño y construcción de programas de computadora y la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como desarrollo de software o producción de software “- B. BOHEM - 27 -.

(48) “La ingeniería de software es una disciplina que se encarga de los aspectos del desarrollo de software en su totalidad, dentro de las cuales se incluye las actividades de ingeniería de requisitos, modelos de procesos y técnicas u modelos de estimación “- IAN SOMERVILLE, 2003, P.6-7. Un software se desarrolla a través de un proceso. No es algo que se fabrica a base de una materia prima ni se ensambla a partir de piezas más pequeñas, Según PRESSMAN (2006, p.4). Nos brinda enfoques solidos la ingeniería de software, lo cual no sirve para aumentar los medios de que los objetivos de un negocio se cumplan sobre las cuestiones tanto de tiempo como calidad y funcionabilidad, Según CAMPOS (2006, p.4).. Entre otras ciencias que se pueden comparan con la ingeniería de software podemos encontrar: a) Ciencias de la Computación Esta norma se ocupa del estudio de sistemas de cómputo incluyendo procesos algorítmicos y principios que involucran el diseño de software y hardware. Los profesionales en ciencias de la computación se encargan del diseño de algoritmos, lenguajes, herramientas y sistemas de software. Diseñan y construyen software, creando soluciones eficientes a problemas del mundo real en campos como la medicina, el comercio, la biología y los negocios. - 28 -.

(49) Según Denning, 2005, Describe a las ciencias de la computación como: “La disciplina de la computación es el estudio sistemático de procesos algoritmos que describen y transforman información: su teoría, análisis, diseño, eficiencia, implementación y aplicación. La pregunta fundamental subyacente en toda la computación es, “¿Qué puede ser (eficientemente) automatizarlo? “ Para quedar claro podemos señalar que la ingeniería de software y ciencias de la computación no son ciencias exactas idénticas sino más bien podemos destacar que ciencias de la Computación es el estudio de los sistemas informáticos, incluyendo los procesos algorítmicos y los principios que intervienen en el diseño de hardware y software mientras que la Ingeniería de Software es la práctica del diseño e implementación de software grande, confiable, eficiente y económica mediante la aplicación de los principios y prácticas de la ingeniería Como Somerville en el año 2005, en su libro (nombre del libro), P.7, “La ciencia de computación se toma como referencia a las teorías y métodos subyacentes a las computadoras y los sistemas de software, mientras que la ingeniería del software se refiere a los problemas prácticos de producir software “b) Ingeniería de software orientada a objetos UML Para al desarrollo de un software eficiente, sin realizar antes un proceso de modelado se tornaría algo casi imposible de realizar, esta técnica de modelado muy recomendada no académicamente hablando sino también dentro del ámbito profesional y como para ejemplo todos los modelos actuales que se identifican a los sistemas de software son elaborados a raíz de un lenguaje modelado. - 29 -.

(50) El lenguaje UML es un lenguaje en el cual podemos visualizar, especificar documentar y construir los ingenios de un software. El lenguaje unificado nos ofrece una guía estandarizada para detallar un plano del sistema, incorporando también material conceptual como procesos y funciones de un sistema, y también encontramos expresiones de lenguajes de programación, componentes de software reutilizables y esquemas de base de datos. El lenguaje unificado se tornó en un estándar de ayuda para la construcción de un software orientado a objeto, dentro de este estándar podemos acatar que tenemos 13 diagramas UML. El lenguaje UML nos sirve para definir el uso de un software, para determinar artilugios en el sistema, su documentación y construcción, este mismo lenguaje se utiliza para una gran variedad de formas para soportar una metodología de desarrollo, pero no se especifica la misma. UML se puede identificar en 13 tipos los cuales son diagramas básicos, cuyos tipos se encuentran divididos en dos grupos generalizados:. A) Diagramas de Modelado Estructurado Los diagramas estructurales nos definen e identifican la arquitectura estática de un modelo, estos son usados para modelar las formas u objetos que conforman uno o más modelos, tales como objetos, interfaces componentes de clases y físicos, estos también son implementados para las relaciones modelación y dependencias de componentes. 1. Diagrama de Paquetes: Se refieren a las interacciones entre paquetes a un nivel más alto, ya que este diagrama es usado para partir el modelo en contenedores lógicos o paquetes. - 30 -.

(51) 2. Diagramas Estructurales: También denominados diagramas de clases, son utilizados para la definición de los bloques o componentes lo cuales servirán para la elaboración básica de un modelo, estos pueden ser clases y tipos que se usan elaborar un modelo completo. 3. Diagramas de Objeto: Estos diagramas nos brindan una vista de las instancias de los elementos estructurales su relación y tiempo de ejecución. 4. Diagramas de Estructuras Compuestas: Estos diagramas facilitan medio para la estructuración de elementos y detalles, para su posterior creación y relaciones internas. 5. Diagramas de Componentes: Nos sirve este diagrama para formar estructuras de un nivel más alto o de carácter más complejo, las mismas que son construidas de una o varias clases, esto nos da como resultado una interfaz bien definida. 6. Diagrama. de. Despliegue:. Nos. enseña. dentro. de. una. configuración real la disposición de objetos significativos que tenemos.. - 31 -.

(52) B) Diagramas de Modelado de Comportamiento Estos diagramas obtienen las variedades de interacción y su estado inmediato dentro de un específico modelo sin importar que se encuentre ejecutando. 7. Diagramas de Casos de Uso: Estos se usan para definir las relaciones entre el usuario/sistema, los mismos que determinan los requisitos, restricciones y comportamientos ya sean estos escenarios o scripts. 8. Diagramas de Actividades: Estos diagramas tienen una variedad de uso muy amplio, pueden estar comprendidos desde el punto avanzado como el de captura de puntos de decisión y acciones dentro de un proceso generalizado, y desde la definición de un flujo de programa básico. 9. Diagramas de Máquina de Estados: Sirven para el sentido o entendimiento de una condición la cual dura momento a momento o cuando se ejecuta el estado de ejecución. 10. Diagramas de Comunicaciones: Dentro de una instancia de colaboración nos enseña la red, la secuencia de paquetes o mensajes de comunicaciones entre diversos objetos en tiempo de ejecución. 11. Diagramas de Secuencias: Su relación es directa con los Diagramas de Comunicación, cuyo resultado es la presentación de la secuencia de mensajes trasladados o intercambiados entre objetos usando para la comunicación de la misma una línea en tiempo vertical.. - 32 -.

(53) 12. Diagramas de Tiempos: Estos diagramas son una combinación entre los diagramas de secuencia y diagramas de estados, este diagrama nos ayuda a la observación de estado del objeto sin importar el tiempo en el cual se esté ejecutando y los mensajes que ayudan a la selección de este estado. 13. Diagramas de Descripción: se denomina a la unificación de los diagramas de actividades y secuencia, lo que nos con lleva a permitir que las partes de interacción sean fácilmente combinadas con los puntos y flujos de decisión.. Qué es un caso de uso Se puede denominar una secuencia de interacciones, las cuales se establecen entre un sistema y uno o más actores, en consecuencia, o respuesta a un evento que es provocada primordialmente sobre el propio sistema. Los diagramas de los casos de uso nos describen el correcto comportamiento o comunicación entre sistema y usuarios. Sin embargo, también puede ser un diagrama en donde se pueda observar o mostrar la correlación entre usuarios o actores, casos de uso en un mismo sistema. Debemos tener en cuenta que, una relación se debería definir como una conexión entre las partes o los elementos de un mismo modelo. Los casos de uso son representados en diagramas los cuales se definen como los diagramas de casos de uso y estos deben hacer referencia o ser utilizados para enseñar los requerimientos del sistema al proyectar los resultados los cuales serán la reacción a eventos que se producen en su ámbito o en el mismo. Estos casos son implementados o desarrollados en el proceso del modelado del sistema, iniciando del conocimiento o representación que - 33 -.

(54) nos bosqueja la muestra en la orientación de los objetos, y para ejemplo el análisis y diseño cuya orientación es hacia los objetos. Todo lo antes mencionado conforma parte del Lenguaje Unificado de Modelado (UML), cuyas siglas en ingles son Unified Modeling Languaje, siendo esta constituida con muchas otras herramientas como: Diagrama de Secuencia, Diagramas de Clase, Transición de Estados, Colaboración, Componentes, Diagramas de Actividad, Deployment entre varios más. Siendo estas usadas en el proceso o ciclo de vida del proceso de desarrollo. Su principal aplicación, es al momento del proceso de análisis y diseño, pero particularmente también en la definición de requerimientos del usuario. Considerada como una excelente herramienta de comunicación gracias a su sencillez de su creación, así como a la de su comprensión. “Enfoque que permite al analista trabajar con los usuarios para comprender la naturaleza de los procesos y las actividades, para posteriormente crear un solo fragmento de diagrama de flujo de datos “- KENNETH KENDALL Y JULIE KENDALL, 2005, P.207. Caso de Abuso ¿Qué es? Estos casos son encaminados en los requerimientos y casos de uso, se puede determinar que es una manera o una herramienta para podernos introducir en la mente del agente agresor, cabe recalcar que estos casos son sumamente similares a los casos de uso, y nos sirven para detallar, cual es el comportamiento del sistema bajo el uso no debido del mismo, y esto nos con lleva a identificar que se debe proteger, de quien debemos proteger y durante qué tiempo esto debe estar protegido. - 34 -.

(55) Ya que se debe tomar en cuenta que la seguridad en un software es una propiedad más no una característica, ya que tenemos la ventaja sobre nuestros atacantes o actores ya que se conoce mejor la funcionabilidad del software. Y esta ventaja debe ser utilizada para el beneficio deseado. Y una de sus principales virtudes y factibilidades es que nos ayuda a la obtención de decisiones y documentación de la reacción de nuestro sistema.. Características • Evidencia casos que no deberían suceder tales como situaciones negativas, amenazas relacionadas a las distintas situaciones que se nos pueden presentar. • Beneficia que se apuntemos en la seguridad desde el principio de los procesos de diseño, y evitamos tomar decisiones de diseño prematura. • Perfecciona. la. comunicación. entre. desarrolladores. y. clientes, permite llegar a un acuerdo cuando existe una situación crítica.. - 35 -.

(56) FUNDAMENTACIÓN LEGAL CCONSTITUCIÓN DE LA REPUBLICA DEL ECUADOR TÍTULO VII Capítulo Primero: Régimen del Buen Vivir Sección Octava: Ciencia, Tecnología, Innovación y Saberes Ancestrales Art. 385.- El sistema nacional de ciencia, tecnología, innovación y saberes ancestrales, en el marco del respeto al ambiente, la naturaleza, la vida, las culturas y la soberanía, tendrá como finalidad: 1. Generar, adaptar y difundir conocimientos científicos y tecnológicos. 2. Recuperar, fortalecer y potenciar los saberes ancestrales. 3. Desarrollar tecnologías e innovaciones que impulsen la producción nacional, eleven la eficiencia y productividad, mejoren la calidad de vida y contribuyan a la realización del buen vivir.. Art. 386.- El sistema comprenderá programas, políticas, recursos, acciones, e incorporará a instituciones del Estado, universidades y escuelas politécnicas, institutos de investigación públicos y particulares, empresas públicas y privadas, organismos no gubernamentales y personas naturales o jurídicas, en tanto realizan actividades de investigación, desarrollo tecnológico, innovación y aquellas ligadas a los saberes ancestrales. El Estado, a través del organismo competente, - 36 -.

(57) coordinará el sistema,. establecerá los objetivos y políticas,. de. conformidad con el Plan Nacional de Desarrollo, con la participación de los actores que lo conforman. Art. 387.- Será responsabilidad del Estado: 1. Facilitar e impulsar la incorporación a la sociedad del conocimiento para alcanzar los objetivos del régimen de desarrollo. 2. Promover la generación y producción de conocimiento, fomentar la investigación científica y tecnológica, y potenciar los saberes ancestrales, para así contribuir a la realización del buen vivir, al sumak kawsay. 3. Asegurar la difusión y el acceso a los conocimientos científicos y tecnológicos, el usufructo de sus descubrimientos y hallazgos en el marco de lo establecido en la Constitución y la Ley. 4. Garantizar la libertad de creación e investigación en el marco del respeto a la ética, la naturaleza, el ambiente, y el rescate de los conocimientos ancestrales. 5. Reconocer la condición de investigador de acuerdo con la Ley. Art. 388.- El Estado destinará los recursos necesarios para la investigación científica, el desarrollo tecnológico, la innovación, la formación científica, la recuperación y desarrollo de saberes ancestrales y la difusión del conocimiento. Un porcentaje de estos recursos se destinará a financiar proyectos mediante fondos concursables. Las organizaciones que reciban fondos públicos estarán sujetas a la rendición de cuentas y al control estatal respectivo.. - 37 -.

(58) TÍTULO VII INTEGRALIDAD CAPÍTULO 2: de la Tipología de Instituciones, y Régimen Académico Sección Tercera: Del Funcionamiento de las Instituciones de Educación Superior Art. 144.- Tesis Digitalizadas. - Todas las instituciones de educación superior estarán obligadas a entregar las tesis que se elaboren para la obtención de títulos académicos de grado y posgrado en formato digital para ser integradas al Sistema Nacional de Información de la Educación Superior del Ecuador para su difusión pública respetando los derechos de autor. 5. Integrar los espacios de participación previstos en la Constitución en el campo de la comunicación.. DECRETO N° 1014 DEL GOBIERNO ACERCA DEL USO DE SOFTWARE LIBRE Artículo 1: Establecer como política pública para las Entidades de la Administración Pública Central la utilización de Software Libre en sus sistemas y equipamientos informáticos. Artículo 2: Se entiende por Software Libre a los programas de computación que se pueden utilizar y distribuir sin restricción alguna, que permite el acceso a sus códigos fuentes y que sus aplicaciones pueden ser mejoradas. Estos programas de computación tienen las siguientes libertades: a). Utilización del programa con cualquier propósito de uso común.. - 38 -.