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
II
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: Santana Santana Katherine Fiallos Lalama Steve Pietro
REVISOR: Ing. Manuel Reyes Wagnio MBA.
INSTITUCIÓN: Universidad de Guayaquil
FACULTAD: Facultad de Ciencias Matemáticas y 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: SI NO
CONTACTO CON AUTORES/ES:
Teléfono: 0968161114 0939304395
E-mail: [email protected] [email protected]
CONTACTO EN LA INSTITUCIÓN:
Nombre: Ab. Juan Chávez Atocha
Teléfono: 2307729
E-mail: [email protected]
X
III
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
IV
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
V
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
VI
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
VII
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
VIII
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
IX
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
X
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
XI
Í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 -
XII
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 -
XIII
RECOMENDACIONES ..................................................................... - 114 -
BIBLIOGRAFÍA ................................................................................. - 115 -
ANEXOS .......................................................................................... - 116 -
XIV
Í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 -
XV
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 -
XVI
Í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 -
XVII
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 -
XVIII
ABREVIATURA
UML Lenguaje unificado de modelado SDLC Ciclo vital del desarrollo/diseño de sistemas CAPEC Enumeración y Clasificación de Patrones de ataques
comunes CORAS Sistema de Análisis de Riesgo Objetivo Consultivo OCTAVE Evaluación de amenazas, activos y vulnerabilidad
operacionalmente crítica
XIX
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.
XX
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.
- 1 -
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.
- 2 -
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.
- 3 -
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,
- 4 -
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
- 5 -
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:
- 6 -
Tabla 1 Causas y Consecuencias del problema
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia
Causas Consecuencias
Hay ausencias en las
etapas de desarrollo de
software.
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.
Se encuentran escasos
atributos de
seguridades y
protección.
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.
Ausencia de contexto y
limitación del sistema a
desarrollar no se
encuentra puntualizada.
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.
Poca importancia en las
técnicas o métodos
para implementar
seguridades en los
sistemas
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
Carencia de
confiabilidad del caso
de uso de ingreso de
datos a la plataforma.
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.
- 7 -
DELIMITACIÓN DEL PROBLEMA
Tabla 2. Delimitación del problema
Campo Área Aspecto Tema
Desarrollo
de Sistemas
Diseño del
software
Casos de Abusos
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.
- 8 -
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.
- 9 -
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).
- 10 -
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”.
- 11 -
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.
- 12 -
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.
- 13 -
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.
- 14 -
• 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.
- 15 -
• 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.
- 16 -
• 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.
- 17 -
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.
- 18 -
“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:
- 19 -
Tabla 3. Metodología Cualitativa
TIPO DESCRIPCIÓN CARACTERÍSTICAS
Preparatorita
Reflexión: se concreta o
detalla un marco teórico
conceptual
✓ Conocimiento
✓ Experiencia
Diseño: define ejecución
todas aquellas actividades
a considerarse
✓ Creación
Trabajo de
Campo
obtención de datos
verídicos
✓ Habilidad
✓ Paciencia
✓ Visión
✓ Flexibilidad
✓ Adaptabilidad
✓ persistencia
✓ meticulosidad
preparación teórica
Analítica
está conformada por una
serie de operaciones o
tareas, que permite
realizar la Reducción de
datos
✓ Categorizar la data
recolectada
✓ Codificar la data
recolectada
✓ transformar datos
✓ crear diagramas y
matrices
Informativa
se obtiene una mayor
comprensión del estudio
realizado y se comparte
dicha información
✓ 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:
- 20 -
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
- 21 -
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
- 22 -
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).
- 23 -
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).
- 24 -
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.
- 25 -
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.
- 26 -
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
- 27 -
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
- 28 -
“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.
- 29 -
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.
- 30 -
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.
- 31 -
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.
- 32 -
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.
- 33 -
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
- 34 -
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.
- 35 -
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.
- 36 -
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,
- 37 -
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.
- 38 -
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.
- 39 -
b) Distribución de copias sin restricciones alguna.
c) Estudio y modificación del programa (Requisito: código fuente
disponible).
d) Publicación del programa mejorado (Requisito: código fuente
disponible).
LEY ORGÁNICA DE EDUCACIÓN SUPERIOR, LOES
CAPÍTULO 2
PATRIMONIO Y FINANCIAMIENTO DE LAS INSTITUCIONES
DE EDUCACIÓN SUPERIOR
Art. 20.- Del Patrimonio y Financiamiento de las instituciones del sistema
de educación superior. - En ejercicio de la autonomía responsable, el
patrimonio y financiamiento de las instituciones del sistema de educación
superior estará constituido por:
a) Los bienes muebles e inmuebles que al promulgarse esta Ley sean de
su propiedad, y los bienes que se adquieran en el futuro a cualquier título,
así como aquellos que fueron ofertados y comprometidos al momento de
presentar su proyecto de creación;
b) Las rentas establecidas en la Ley del Fondo Permanente de Desarrollo
Universitario y Politécnico
(FOPEDEUPO);
- 40 -
c) Las asignaciones que han constatado y las que consten en el
Presupuesto General del Estado, con los incrementos que manda la
Constitución de la República del Ecuador;
d) Las asignaciones que corresponden a la gratuidad para las
instituciones públicas;
e) Los ingresos por matrículas, derechos y aranceles, con las
excepciones establecidas en la
Constitución y en esta Ley en las universidades y escuelas politécnicas
públicas;
f) Los beneficios obtenidos por su participación en actividades productivas
de bienes y servicios, siempre y cuando esa participación no persiga fines
de lucro y que sea en beneficio de la institución;
g) Los recursos provenientes de herencias, legados y donaciones a su
favor;
h) Los fondos autogenerados por cursos, seminarios extracurriculares,
programas de posgrado, consultorías, prestación de servicios y similares,
en el marco de lo establecido en esta Ley;
i) Los ingresos provenientes de la propiedad intelectual como fruto de sus
investigaciones y otras actividades académicas;
j) Los saldos presupuestarios comprometidos para inversión en desarrollo
de ciencia y tecnología y proyectos académicos y de investigación que se
encuentren en ejecución no devengados a la finalización del ejercicio
económico, obligatoriamente se incorporarán al presupuesto del ejercicio
fiscal siguiente;
k) Los recursos obtenidos por contribuciones de la cooperación
internacional; y,
l) Otros bienes y fondos económicos que les correspondan o que
adquieran de acuerdo con la Ley.
- 41 -
Art. 3.- Recursos Públicos.- Para efecto de esta Ley se entenderán por
recursos públicos, todos los bienes, fondos, títulos, acciones,
participaciones, activos, rentas, utilidades, excedentes, subvenciones y
todos los derechos que pertenecen al Estado y a sus instituciones, sea
cual fuere la fuente de la que procedan, inclusive los provenientes de
préstamos, donaciones y entregas que, a cualquier otro título realicen a
favor del Estado o de sus instituciones, personas naturales o jurídicas u
organismos nacionales o internacionales.
Los recursos públicos no pierden su calidad de tales al ser administrados
por corporaciones, fundaciones, sociedades civiles, compañías
mercantiles y otras entidades de derecho privado, cualquiera hubiere sido
o fuere su origen, creación o constitución hasta tanto los títulos, acciones,
participaciones o derechos que representen ese patrimonio sean
transferidos a personas naturales o personas jurídicas de derecho
privado, de conformidad con la ley.
Ley de Propiedad Intelectual
TÍTULO I: DE LOS DERECHOS DE AUTOR Y DERECHOS
CONEXOS CAPÍTULO I: DEL DERECHO DE AUTOR
Art. 4. Se reconocen y garantizan los derechos de los autores y los
derechos de los demás titulares sobre sus obras.
Art. 5. El derecho de autor nace y se protege por el solo hecho de la
creación de la obra, independientemente de su mérito, destino o modo de
expresión.
- 42 -
Se protegen todas las obras, interpretaciones, ejecuciones, producciones
o emisión radiofónica cualquiera sea el país de origen de la obra, la
nacionalidad o el domicilio del autor o titular. Esta protección también se
reconoce cualquiera que sea el lugar de publicación o divulgación.
El reconocimiento de los derechos de autor y de los derechos conexos no
está sometido a registro, depósito, ni al cumplimiento de formalidad
alguna. El derecho conexo nace de la necesidad de asegurar la
protección de los derechos de los artistas, intérpretes o ejecutantes y de
los productores de fonogramas.
- 43 -
SECCIÓN II OBJETO DEL DERECHO DE AUTOR
Art. 8. La protección del derecho de autor recae sobre todas las obras del
ingenio, en el ámbito literario o artístico, cualquiera que sea su género,
forma de expresión, mérito o finalidad. Los derechos reconocidos por el
presente título son independientes de la propiedad del objeto material en
el cual está incorporada la obra y su goce o ejercicio no están
supeditados al requisito del registro o al cumplimiento de cualquier otra
formalidad. Las obras protegidas comprenden, entre otras, las siguientes:
a) Libros, folletos, impresos, epistolarios, artículos, novelas, cuentos,
poemas, crónicas, críticas, ensayos, misivas, guiones para teatro,
cinematografía, televisión, conferencias, discursos, lecciones, sermones,
alegatos en derecho, memorias y otras obras de similar naturaleza,
expresadas en cualquier forma;
b) Colecciones de obras, tales como antologías o compilaciones y bases
de datos de toda clase, que por la selección o disposición de las materias
constituyan creaciones intelectuales, sin perjuicio de los derechos de
autor que subsistan sobre los materiales o datos;
c) Obras dramáticas y dramático musicales, las coreografías, las
pantomimas y, en general las obras teatrales;
d) Composiciones musicales con o sin letra;
e) Obras cinematográficas y cualesquiera otras obras audiovisuales;
f) Las esculturas y las obras de pintura, dibujo, grabado, litografía y las
historietas gráficas, tebeos, comics, así como sus ensayos o bocetos y las
demás obras plásticas;
- 44 -
g) Proyectos, planos, maquetas y diseños de obras arquitectónicas y de
ingeniería; h) Ilustraciones, gráficos, mapas y diseños relativos a la
geografía, la topografía, y en general a la ciencia;
i) Obras fotográficas y las expresadas por procedimientos análogos a la
fotografía;
j) Obras de arte aplicada, aunque su valor artístico no pueda ser
disociado del carácter industrial de los objetos a los cuales estén
incorporadas;
k) Programas de ordenador; y,
l) Adaptaciones, traducciones, arreglos, revisiones, actualizaciones y
anotaciones; compendios, resúmenes y extractos; y, otras
transformaciones de una obra, realizadas con expresa autorización de los
autores de las obras originales, y sin perjuicio de sus derechos.
Sin perjuicio de los derechos de propiedad industrial, los títulos de
programas y noticieros radiales o televisados, de diarios, revistas y otras
publicaciones periódicas, quedan protegidos durante un año después de
la salida del último número o de la comunicación pública del último
programa, salvo que se trate de publicaciones o producciones anuales, en
cuyo caso el plazo de protección se extenderá a tres años.
- 45 -
SECCIÓN V
DISPOSICIONES ESPECIALES SOBRE
CIERTAS OBRAS
PARÁGRAFO PRIMERO
DE LOS PROGRAMAS DE ORDENADOR
Art. 28. Los programas de ordenador se consideran obras literarias y se
protegen como tales. Dicha protección se otorga independientemente de
que hayan sido incorporados en un ordenador y
cualquiera sea la forma en que estén expresados, ya sea en forma legible
por el hombre (código fuente) o en forma legible por máquina (código
objeto), ya sean programas operativos y programas aplicativos,
incluyendo diagramas de flujo, planos, manuales de uso, y en general,
aquellos elementos que conformen la estructura, secuencia y
organización del programa.
Art. 29. Es titular de un programa de ordenador, el productor, esto es la
persona natural o jurídica que toma la iniciativa y responsabilidad de la
realización de la obra. Se considerará titular, salvo prueba en contrario, a
la persona cuyo nombre conste en la obra o sus copias de la forma usual.
Dicho titular está además legitimado para ejercer en nombre propio los
derechos morales sobre la obra, incluyendo la facultad para decidir sobre
su divulgación.
El productor tendrá el derecho exclusivo de realizar, autorizar o prohibir la
realización de modificaciones o versiones sucesivas del programa, y de
programas derivados del mismo.
- 46 -
Las disposiciones del presente artículo podrán ser modificadas mediante
acuerdo entre los autores y el productor.
PREGUNTA CIENTÍFICA A CONTESTARSE
¿De qué manera ayudaría crear un modelo de especificación de
requerimientos de seguridad para evitar los casos de abuso de un caso
de uso?
¿Cuál sería el resultado de la implementación de la técnica y modelo
desarrollada para evitar los casos de abuso?
DEFINICIONES CONCEPTUALES
Casos de Uso:
“Un caso de uso describe un conjunto de secuencias, en las cuales cada
secuencia representa la interacción de cosas fuera del sistema (actores)
con el sistema (y sus abstracciones clave). Estos comportamientos son
funciones a nivel del sistema que acostumbra visualizar, especificar,
construir y documentar en la fase de obtención y análisis de los
requerimientos. Un caso de uso representa un (o más) requerimiento
funcional completo del sistema”
- 47 -
Caso de Uso
Ilustración 1 Caso de Uso Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama
Fuente: Proyecto FCI
Caso de Abuso:
Tradicionalmente los aspectos de seguridad de un sistema han sido
tratados a través de modelos matemáticos, los cuales no son fáciles de
entender ni interpretar por desarrolladores inexpertos en temas de
seguridad y aún más difíciles para los usuarios. Por este motivo se han
diseñado los casos de abuso que son mucho más fáciles de entender y
que al igual que los conocidos casos de uso de UML, sirven como una
eficaz herramienta de comunicación entre desarrolladores y usuarios.
- 48 -
Caso de Abuso
Ilustración 2 Caso de Abuso Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama
Fuente: Proyecto FCI
Seguridad Informática:
Podemos definir la seguridad informática como cualquier medida que
impida la ejecución de operaciones no autorizadas sobre un sistema o red
informática, cuyos efectos puedan con llevar daños sobre la información
- 49 -
Seguridad Informática
Ilustración 3 Seguridad Informática Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama
Fuente: Proyecto FCI
CASOS DE MAL USO:
Sindre nos define en su artículo publicado en el año 2000 conjuntamente
con Opdahl, que los casos de uso indebido como un "tipo especial de
caso de uso, describiendo el comportamiento que el propietario del
sistema / entidad no desea que ocurra"
- 50 -
Caso de Mal Uso
Ilustración 4 Caso de Mal Uso Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama
Fuente: Proyecto FCI
UML
Según Fowler y Scott, en su libro UML gota a gota (pag, 1), define que
UML es un lenguaje de modelado mas no un método. La mayor parte de
los métodos consisten, al menos en principio, en un lenguaje y en un
proceso para modelar. El lenguaje modelado es la notación de que se
valen los métodos para expresar los diseños. El proceso es la orientación
que nos dan sobre los pasos a seguir para hacer el diseño.
- 51 -
UML
Ilustración 5 UML Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama
Fuente: Proyecto FCI
INGENIERÍA DE SOFTWARE
Según Sommerville, en su publicación del 2005 (Pag, 6), nos indica que la
ingeniería de software es una disciplina de la ingeniería que comprende
todos los aspectos de la producción de software desde las etapas iniciales
de la especificación del sistema, hasta el mantenimiento de este después
de que se utiliza.
Ingeniería de Software
Ilustración 6 Ingeniería de Software Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama
Fuente: Proyecto FCI
- 52 -
MODELADO DE DATOS
Según Sommerville, en su publicación del 2005 (Pag, 157), Los modelos
de flujos de datos son una forma intuitiva de mostrar como los datos son
procesados por un sistema. A nivel de análisis, deberían usarse para
modelar la forma en que los datos son procesados en el sistema
existente. Según el libro de DeMarco (DeMarco, 1978). Sobre el análisis
de sistemas estructurados.
Modelado de Datos
Ilustración 7 Modelado de Datos Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama
Fuente: Proyecto FCI
- 53 -
CAPÍTULO III
PROPUESTA TECNOLÓGICA
En este proyecto se plantea analizar el módulo “RECOLECCIÓN DE
DATOS” como una solución al momento de analizar y diseñar un modelo
de especificaciones de seguridad con la intención de obtener un buen
manejo al instante de realizar un software.
Análisis de factibilidad
Con la presente investigación lograremos desarrollar técnicas que
permitan crear un análisis de requerimientos de seguridad en un caso de
uso, algunos modelos a pesar de que cumplen con los requerimientos
funcionales del sistema no consideran otros de vital importancia al
momento del desarrollo para que cumpla con todas las exigencias
necesarias, una vez determinado estas razones podemos decir que el
proyecto a desarrollarse es viable.
Factibilidad Operacional
En vista de que no se cuenta con un modelo, guía o estructura de la
elaboración de los casos de abuso, se encuentra esta necesidad, puesto
que la importancia de la elaboración del mismo, nos podrá ayudar a la
identificación de las falencias o de los puntos frágiles dentro de nuestro
sistema, lo que nos puede con llevar a una brecha para la vulneración
hacia nuestro sistema o para pérdida de data.
- 54 -
Factibilidad técnica
El desarrollo del proyecto fue realizado en un ambiente local, mediante la
utilización de los equipos, cuyas características son:
HARDWARE
A continuación, se detalla las características de los equipos
físicos, utilizados para realizar de desarrollo del proyecto.
LAPTOP
• Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz 2.59 GHz
• Memoria RAM de 8 GB
• Disco Duro de 1000 GB
• Sistema Operativo Windows 10 Home 64 bits
• Tarjeta de red
LAPTOP
• Intel(R) Core (TM) i5-5200 CP @ 2.20GHz (4 CPUs), ~2.2
GHz
• Memoria RAM de 4 GB
• Disco Duro 500 GB
• Sistema Operativo Windows 7 Ultimate x64 bits
• Tarjeta de red
Factibilidad Legal
Este proyecto es factible legalmente, ya que no infringe ninguna
ley establecida por las autoridades de nuestro país, como está
determinado en el capítulo II, es decir que no incurre en
infracciones y puede ponerse en práctica.
- 55 -
Factibilidad Económica
Se detalla a continuación los costos del desarrollo del proyecto
Tabla 4.Recurso de Software
Recurso de Hardware
Cantidad Recursos Descripción Costo del
Proyecto
2 Laptop Proyecto de
Titulación $ 895
Total $ 1.790
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia
Tabla 5. Gastos Generales
Gastos Generales
Cantidad Recursos Descripción Costo del
Proyecto
2 transporte Proyecto de Titulación $ 200
2 Alimentación Proyecto de Titulación $300
- Internet Proyecto de Titulación $150
- Material de
Oficina Proyecto de Titulación $ 100
Total $ 750
Elaborado por: Katherine Santana Santana, - Steve Fiallos Lalama Fuente: Elaboración Propia
- 56 -
Tabla 6. Costo Total del Proyecto
Costo Total del Proyecto
Descripción Costo
Recurso Humano $ 300
Recurso de Hardware $1790
Gastos Generales $ 750
Total $ 2.840
Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama
Fuente: Elaboración Propia
57
ETAPAS DEL DESARROLLO PARA LA CONSTRUCCIÓN DEL
MODELO DE CASOS DE ABUSO
Ilu
str
ació
n 8
Seguridad e
n e
l C
iclo
de v
ida d
el S
oftw
are
Ela
bo
rad
o p
or:
Kath
erine S
anta
na S
anta
na -
Ste
ve
Fia
llos L
ala
ma
Fu
en
te:
Pro
yecto
FC
I
DE
SA
RR
OL
LO
DE
L M
OD
EL
O
58
El objetivo del presente trabajo es un modelo para las diferentes prácticas
de seguridad a introducir en el SDLC en las fases de requisitos y diseño,
por una organización al objeto de obtener software más seguro, confiable,
que presente un mínimo de vulnerabilidades y sea resistente a los
ataques provenientes del entorno interior como del exterior.
Se puede definir la seguridad del software, como:
El conjunto de principios de diseño y buenas prácticas a implantar en el
SDLC, para detectar, prevenir y corregir los defectos de seguridad en el
desarrollo y adquisición de aplicaciones, de forma que se obtenga
software de confianza y robusto frente ataques maliciosos, que realice
solo las funciones para las que fue diseñado, que esté libre de
vulnerabilidades, ya sean intencionalmente diseñadas o accidentalmente
insertadas durante su ciclo de vida, de forma que se asegure su
integridad, disponibilidad y confidencialidad.
El desarrollo de software seguro y confiable requiere la adopción de un
proceso sistemático o disciplina que aborde la seguridad en cada una de
las fases de su ciclo de vida. Se debe integrar en el mismo dos tipos de
actividades de seguridad la primea es el seguimiento de unos principios
de diseño seguro (mínimo privilegio, etc.) y la segunda la inclusión de una
serie de buenas prácticas de seguridad (especificación requisitos
seguridad, casos de abuso, análisis de riesgo, análisis de código, pruebas
de penetración dinámicas, etc.).
1.- Modelado de Ataque
Para la construcción del modelo el cual es el objetivo principal de este
trabajo de titulación se debe siempre tener en consideración la
59
elaboración de un modelado de ataque ya que mediante el cual se puede
reducir los puntos focales de las vulneraciones de nuestro sistema.
La siguiente ilustración muestra las etapas a realizar para la respectiva
elaboración, validación e implementación para el desarrollo de un
software seguro.
Las cuales se detallarán a continuación:
1. Modelado de ataque
2. Casos de abuso.
3. Ing. de requisitos.
4. Análisis de riesgos
5. Patrones de diseño.
6. Pruebas basadas en riesgo.
7. Revisión de código.
8. Configuración Segura.
9. Test penetración.
10. Operaciones seguridad.
11. Revisión externa.
60
Ilu
str
ació
n 9
Modela
do d
e A
taques
Ela
bo
rad
o p
or:
Kath
erine S
anta
na S
anta
na -
Ste
ve
Fia
llos
Lala
ma
Fu
en
te:
Pro
yecto
FC
I
Mo
dela
do
de
ata
qu
es
61
Defensor
El equipo trabaja para construir un software con las
propiedades de seguridad necesarias para que sea más
resistente a los ataques y minimizar las debilidades y
vulnerabilidad
El principal objetivo de la seguridad del software es el mantener sus
propiedades de seguridad frente a los ataques realizados por personal
malicioso sobre sus componentes y reducir al mínimo posible sus
vulnerabilidades explotables. Para conseguir que el desarrollo de una
aplicación posea las propiedades y principios de diseño del software
seguro, se necesita que el personal de diseño y desarrollo desarrollen dos
perspectivas:
PERSPECTIVAS DE MODELADO DE ATAQUES
Ilustración 10 Perspectivas de Modelado Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama
Fuente: Proyecto FCI
La perspectiva del atacante se suele modelar de las siguientes dos
formas, que desarrollamos en párrafos posteriores:
» Patrones de ataque
» Árboles de ataque
El equipo se esfuerza por comprender la naturaleza exacta de la
amenaza a la que el software es probable que se enfrente con el fin
de concentrar los esfuerzos defensivos
Atacante
62
El uso combinado de patrones de ataque y árboles de ataque, captura la
probabilidad de cómo los ataques se pueden combinar y secuenciar, esto
proporciona una serie de datos que nos pueden ayudar a diseñar en el
software una serie de respuestas encaminadas a mitigarlos.
1.1 Patrones de ataque
Dentro de él modelado de ataque se debe considerar que tenemos para
este trabajo de titulación dos etapas, una de las cuales es el patrón de
ataque, siendo este un mecanismo que conlleva al ciberatacante a
intentar o lograr vulnerar el sistema.
Se debe tomar los siguientes patrones para prevenir un ataque:
• Utilizar un antivirus que analice todas las descargas
• Mantener el sistema operativo y el navegador actualizados
• Cuidar las contraseñas
• Confiar en la web, pero sin ser ingenuo
• No hacer click en los enlaces que resulten sospechosos
• Tener cuidado con lo que se descarga
• Desconfiar de los correos de remitentes desconocidos
• No abrir ficheros adjuntos sospechosos
• Pensar muy bien antes de publicar información personal
(gustos, preferencias, imágenes, etc.)
• Conocer los riesgos asociados al uso del internet
Un ataque aprovecha una vulnerabilidad de una aplicación mediante un
exploit, para obtener un beneficio del sistema como escalada de
privilegios, robo y modificación de datos, modificaciones del
funcionamiento, denegación de servicio, etc.
63
EXPLOIT: Del inglés to exploit, explotar o aprovechar. Es una pieza de
software, fragmento de datos o secuencia de comandos y/o acciones,
utilizada con el fin de aprovechar una vulnerabilidad de seguridad de un
sistema de información para conseguir un comportamiento no deseado
del mismo. Los patrones de ataque constituyen un mecanismo o medio
para capturar y representar la perspectiva y conocimiento del
ciberatacante con el suficiente detalle acerca de cómo los ataques se
llevan a cabo los métodos más frecuentes de explotación (exploit) y las
técnicas usadas para comprometer el software.
En definitiva, constituyen una clasificación de los ataques y una
representación estructurada del pensamiento del atacante, para que el
equipo de diseño y desarrollo obtengan el conocimiento necesario y los
pasos a realizar para mitigar con mayor probabilidad las acciones de los
ciberatacante, reducir su impacto y seleccionar las políticas de seguridad
más convenientes. Derivan del concepto de patrones de diseño aplicado
en un contexto más destructivo que constructivo y están generados a
partir de un análisis en profundidad de determinados ejemplos de exploit
del mundo real.
Un catálogo de patrones de ataques, que proporciona un conjunto de
definiciones comunes, una taxonomía de clasificación, un esquema de
patrones de ataque y un conjunto de ellos reales, la constituye la iniciativa
del MITRE Common Attack Pattern Enumeration and Classification
(CAPEC).
Dependiendo del nivel de detalle que describe y su nivel de abstracción, los
patrones de ataque constituyen un recurso que proporciona valor al conjunto
64
del SDLC, dado que puede tener diferentes utilidades en sus diferentes fases.
En la tabla siguiente se muestra un resumen de los usos de los patrones de
ataques en las diferentes fases del SDLC.
Tabla 7 Aplicación patrones de ataque a las diferentes fases del SDLC
Fase Utilidad
Especificación
de requisitos
» Ayuda a identificar requisitos.
» Ayuda a identificar los riesgos a los que hará frente el
software.
» Ayuda a definir el comportamiento del sistema para prevenir o
reaccionar ante un tipo específico de ataque probable.
Diseño y
arquitectura
» Proporciona ejemplos de ataques que aprovechan las
vulnerabilidades de la arquitectura elegida.
» Proporcionan el contexto de las amenazas al que el software
se va a enfrentar, de forma que permite diseñar arquitecturas
seguras.
Codificación » Específica debilidades aprovechadas por los ataques,
orientando que técnicas o prácticas de seguridad de desarrollo
evitan estas deficiencias.
Pruebas
» Pueden ser utilizados para orientar las pruebas de seguridad
del software en un contexto práctico y realista identificando
debilidades concretas para generar casos de prueba para cada
componente.
Operación » Permitirá la selección de políticas de seguridad y
configuraciones acordes a las amenazas obtenidas de los
patrones de ataque.
Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama Fuente: Proyecto FCI
65
Un patrón de ataque, como mínimo, debe describir ampliamente el
incidente, las habilidades y recursos necesarios para ejecutarlo con éxito,
en qué contextos es aplicable y proporcionar información suficiente para
permitir a los defensores evitar o mitigar eficazmente las acciones del
atacante. En la tabla siguiente se muestran los ítems de información de
los que consta un patrón de ataque obtenido de CAPEC
66
Tabla 8 Alcance de información de un patrón de ataque Ítem Descripción
Nombre » Identificador descriptivo del patrón de ataque.
Severidad
» En una escala aproximada típica (muy bajo, bajo, medio,
alto, muy alto) de la gravedad del ataque.
Descripción
» Descripción detallada del ataque incluyendo la cadena de
acciones tomadas por el atacante. Descripciones más
pormenorizadas podría incluir árboles de ataque.
Prerrequisitos del
ataque
» Describe las condiciones que deben existir o
funcionalidades y características que el software de destino
debe tener y comportamiento que debe exhibir para que un
ataque de este tipo tenga éxito.
Probabilidad
típica del exploit
» Es una escala aproximada (Muy Bajo, Medio Bajo, Alto,
Muy Alto). Este campo se utiliza para capturar un valor
global promedio típico para este tipo de ataque, teniendo en
cuenta que no será completamente exacta para todos.
Métodos de
ataque
» Describe el mecanismo de ataque utilizado por este
patrón. Con el fin de ayudar en la normalización y
clasificación, este campo comprende una selección de una
lista enumerada de definidos vectores. Este campo puede
ayudar a definir la superficie de ataque requerida por este
ataque.
Ejemplos
» Contiene ejemplos explicativos o casos demostrativos de
este ataque. Pretende ayudar al lector a comprender la
naturaleza, el contexto y la variabilidad de la agresión en
términos más prácticos y concretos.
Conocimiento y
habilidades
requeridas del
» Describe el nivel de habilidad o conocimiento específico
requerido por un agente malicioso para ejecutar este tipo de
ataque. Se codifica con una escala aproximada (bajo, medio,
67
atacante alto), así como un detalle de contexto.
Recursos
requeridos
» Este campo describe los recursos (ciclos de CPU,
direcciones IP, herramientas, etc.) requeridos por un
atacante para ejecutar con eficacia este tipo de ataque.
Métodos de
prueba
» Describe las técnicas normalmente utilizadas para
investigar y reconocer un blanco potencial, determinar la
vulnerabilidad y prepararse para este tipo de ataque.
Indicadores de un
ataque
» Describe las actividades, eventos, condiciones o
comportamientos que podrían servir como indicadores de
que un ataque de este tipo es inminente, está en progreso o
ha ocurrido.
Soluciones y
mitigaciones
» Describe acciones o enfoques que pueden potencialmente
prevenir o mitigar el riesgo de este tipo de ataque. Estas
soluciones y mitigaciones están dirigidas a mejorar la
resistencia, reduciendo la probabilidad de éxito del ataque o
para mejorar la capacidad de recuperación del software
objetivo, reduciendo el impacto del ataque si tiene éxito.
Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama Fuente: Proyecto FCI
68
Tabla 9 Alcance de información de un patrón de ataque # 2
Ítem Descripción
Motivación y
consecuencias
del ataque
» Comprende una selección de una lista enumerada de
motivaciones definidas o consecuencias. Esta información es
útil para la alineación de patrones de ataque a los modelos de
amenaza y para la determinación si son relevantes para un
contexto dado.
Descripción del
contexto
» Describe el contexto en el que este patrón es relevante y
aporta más antecedentes para el ataque. Esta información es
útil para una mejor comprensión de la naturaleza de este tipo
de ataque.
Vector de
inyección
» Describe, lo más exactamente posible, el mecanismo y el
formato de un ataque. Debe tener en cuenta la gramática de un
ataque, la sintaxis aceptada por el sistema, la posición de
varios campos, y los rangos de datos que son aceptables.
Payload
» Describe los datos de código, configuración u otros a ejecutar
o activar, como parte de un ataque con un vector de inyección
de este tipo.
Zona de
activación
» Describe el área dentro del software de destino que es capaz
de ejecutar o activar de otro modo la carga útil del vector
inyección de un ataque de este tipo. La zona de activación es
donde la intención del atacante se pone en acción, puede ser
un intérprete de comandos, un código de máquina activa en un
buffer, un navegador cliente, una llamada API del sistema, etc.
Impacto de
activación del
payload
» Descripción de los efectos que la activación de la carga útil
que un ataque de este tipo tendría típicamente en la
confidencialidad, integridad o disponibilidad del software
solicitado.
69
Impacto CIA
» Describe el impacto de este patrón de ataque en las
características de seguridad estándar confidencialidad,
integridad y disponibilidad.
Este campo se utiliza para capturar un valor global promedio
típico para este tipo de ataque, teniendo en cuenta de que no
será completamente exacta para todos los ataques.
Vulnerabilidade
s relacionadas
» Qué vulnerabilidades o debilidades puede el ataque explotar.
Se referencia estándar de la industria CWE. Esta lista debe
incluir no solo a las debilidades que están directamente
afectados por el ataque, sino que también aquellas cuya
presencia pueda directamente aumentar la probabilidad de
éxito del ataque o el impacto si tiene éxito.
Requisitos de
seguridad
relevantes
» Identifica los requisitos de seguridad específicos que son
relevantes para este tipo de ataques y son lo suficientemente
generales como para ofrecer oportunidades de reutilización.
Principios de
seguridad
relacionados
» Identifica los principios de diseño de seguridad que son
relevantes para identificar o mitigar este tipo de ataques.
Guía
relacionadas
» Identifica las directrices de seguridad existentes que son
relevantes para la identificación o mitigar este tipo de ataque.
Referencias
» Enumera los recursos de referencia que se utilizaron para
elaborar la definición de este patrón de ataque y los que
podrían ser de utilidad para ampliar la información sobre este
ataque.
Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama Fuente: Proyecto FCI
70
1.2 Árboles de ataque
Se debe también tener en consideración que otra de las maneras para
realizar un ataque puede ser por medio de los árboles de ataque ya que
mediante de este se puede identificar las falencias del sistema en
mención.
Un árbol de ataque se puede definir como:
En un árbol de ataque, el objetivo del atacante se coloca en la parte
superior del árbol, documentándose las posibles alternativas de ataque en
los diferentes recorridos del árbol, por los nodos de nivel inferior del árbol
que contienen objetivos intermedios, hasta llegar al nivel inferior que
contiene los diferentes métodos o técnicas de ataque. Cada camino a
través de un árbol de ataque representa un tipo de ataque único. Para
cada alternativa, se puede añadir recursivamente otras precursoras que
alcancen diversos objetivos parciales que, en conjunto logran el objetivo
principal del atacante.
Mediante el examen de diferentes ramas del árbol de ataque, el analista
puede identificar todas las posibles técnicas o métodos que podrían ser
utilizados para comprometer la seguridad del sistema.
Básicamente:
» Captura los pasos realizados en ataques con éxito.
» Captura métodos generales y específicos del sistema de ataque,
propiedades del sistema y otras condiciones previas que hacen, lo hacen
posible.
71
» Se enfoca en las causas de las vulnerabilidades, pero no identifica las
contramedidas.
» Representan de forma gráfica y textual de directrices de codificación
segura, patrones de seguridad.
En la representación de la estructura de un árbol de ataque se realiza
conforme a los dos siguientes tipos:
» Textual: sigue una estructura de esquema numérico, el nodo raíz, o la
meta, representada en el primer nivel sin sangría y cada objetivo de nivel
inferior se enumeran con sangría de una unidad por nivel de
descomposición.
» Grafica o semántica: se construye generalmente con el nodo raíz, o la
meta, en la parte superior, al descender por las ramas del árbol se
obtienen sub objetivos hasta que se llega al nivel inferior donde están los
métodos de ataque. Un nodo se descompone como:
Descomposición «AND»: Un conjunto de objetivos de ataque de nivel
inferior, que tienen que ser alcanzados para que el ataque tenga éxito.
Descomposición «OR»: Una serie de objetivos de ataque de nivel
inferior, cualquiera de los cuales puede lograrse para que el ataque tenga
éxito.
72
2.- Análisis del Casos de abuso
El análisis realizado al modelo de caso de uso, nos dio como resultado
que el caso de uso no contemplaba los parámetros necesarios para que
se pueda cumplir con la respectiva creación del caso de abuso.
Los diagramas de casos de uso constituyen unas buenas prácticas para la
obtención de los requisitos funcionales de una aplicación, sin embargo,
para la obtención de requisitos de seguridad no lo son, sobre todo los no
funcionales o requisitos negativos referidos a actividades que no debería
realizar el sistema. Para solucionar lo anterior se ha creado un tipo
especializado de casos de uso que se utilizan para analizar y especificar
las amenazas de seguridad, caso de abuso, Guttorm, A. y Opdahl, L.
(2001) los definen como:
Un caso de abuso es la inversa de un caso de uso, es decir, una función que el
sistema no debe permitir o una secuencia completa de acciones que resulta en una
pérdida para la organización.
73
Ilu
str
ació
n 1
1 C
asos d
e A
bu
so
Ela
bo
rad
o p
or:
Kath
erine S
anta
na S
anta
na
- S
teve
Fia
llos L
ala
ma
Fu
en
te:
Pro
yecto
FC
I
CA
SO
S D
E A
BU
SO
74
Los casos de abuso, o casos de mal uso, son un instrumento que puede
ayudar a pensar de la misma forma que lo hacen los atacantes. Pensando
más allá de los aspectos normativos y funcionales y también estudiando
eventos negativos o inesperados, los
profesionales de seguridad de software entienden mejor cómo crear
software seguro, pues permiten obtener una mejor comprensión de las
áreas de riesgo del sistema a través de (Redwine, 2006):
» Identificación los objetivos de seguridad que debe cumplir el software.
» Identificación de las amenazas de seguridad a ser neutralizadas por el
software.
» Identificación de los puntos en el software susceptibles de ser atacados.
» Definición de restricciones, o requisitos negativos, necesarios para
alcanzar las contramedidas necesarias y los objetivos de seguridad.
» Obtener requisitos de seguridad que garanticen que el software aplica
las restricciones necesarias.
Los casos de abuso constituyen un excelente medio de análisis de las
amenazas que debe afrontar el software. Son apropiados para el análisis
y especificación de restricciones, o requisitos negativos, ya que se basan
en el uso indebido del sistema. Establecen la base para otros casos de uso
de seguridad que proporcionan los medios para contrarrestar o mitigar las
amenazas capturadas en los mismos y una manera altamente reutilizable
de organizar, analizar y especificar los requisitos de seguridad de los
mismos.
75
Los casos de abuso describen lo que el software no debe hacer en
respuesta al uso incorrecto o malintencionado del mismo por un agente
malicioso. Para cada caso de uso funcional, el desarrollador debería
explorar las formas en que esa función podría ser deliberadamente mal
utilizada. El desarrollador tiene que identificar todas las posibles
relaciones entre casos de uso de seguridad y casos abuso, para
especificar restricciones y requisitos de seguridad para evitar un mal uso o
abuso de las funcionalidades del software. En la figura siguiente se
muestra la relación entre el caso de uso de seguridad y el de abuso
asociado (Donald, 2003).
76
Ilu
str
ació
n 1
2 R
ela
ció
n e
ntr
e e
l caso d
e u
so
de
seguridad y
el de a
buso a
socia
do
Ela
bo
rad
o p
or:
Kath
erine S
anta
na
Sa
nta
na
- S
teve
Fia
llos L
ala
ma
Fu
en
te:
Pro
yecto
FC
I
RE
LA
CIÓ
N E
NT
RE
EL
CA
SO
DE
US
O D
E S
EG
UR
IDA
D Y
EL
DE
AB
US
O A
SO
CIA
DO
77
En la siguiente tabla se resume las diferencias entre los casos de uso de
seguridad y los casos de abuso (Donald, 2003):
Tabla 10 Diferencias entre los casos de uso de seguridad y los casos de abuso
Característica Casos de Abuso Casos Uso Seguridad
Uso Analiza y especifica las
amenazas a la seguridad
Analiza y especifica los
requisitos de seguridad
Criterio de éxito Éxito del atacante Éxito de la aplicación
Producido Equipo de seguridad Equipo de seguridad
Usado Equipo de seguridad Equipo de requisitos
Actor externo Atacantes y usuarios Usuarios
Conducido por Análisis de vulnerabilidades de
activos y amenazas
Casos de abuso
Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama Fuente: Proyecto FCI
3. Ingeniería de requisitos de seguridad
Se debe contemplar en la fase de requerimientos iniciales, todos los
atributos de seguridad necesarios, ya que, si estos no son especificados
al momento de su elaboración, nos llevara a un retraso y desgaste mayor
de esfuerzo.
Gran parte de la mayoría de las vulnerabilidades y debilidades del
software tienen su origen en unos requisitos inadecuados, inexactos e
incompletos, principalmente debido a la falta o debilidad de la
especificación de los mismos, que no determinan las funciones,
restricciones y propiedades no funcionales del software que hacen que
este sea previsible, confiable y resistente.
78
Defectos en los requisitos cuestan 10 a 200 veces más para corregir
durante la ejecución, que si se detectan durante la especificación de los
mismos. Además, es difícil y costoso mejorar significativamente la
seguridad de una aplicación después de que esté en su entorno de
producción.
La fase de ingeniería de requisitos cubre todas las actividades y tareas
que deben realizarse antes de iniciar el diseño, su principal resultado es la
especificación de los requisitos que definen los aspectos funcionales y no
funcionales del software.
79
Ilu
str
ació
n 1
3 Ingenie
ría d
e r
equis
itos d
e s
egu
rid
ad
Ela
bo
rad
o p
or:
Kath
erine S
anta
na S
anta
na -
Ste
ve F
iallo
s L
ala
ma
Fu
en
te:
Pro
yecto
FC
I
Ing
en
ierí
a d
e r
eq
uis
ito
s d
e s
eg
uri
dad
80
Los requisitos de seguridad deben ser considerados simultáneamente
junto con los demás requisitos, incluidos los relativos a funcionalidad,
rendimiento, facilidad de uso, ya que normalmente los «requisitos de
seguridad» a menudo entran en conflicto con ellos, se hace necesario, por
tanto:
Los requisitos de las funcionalidades o servicios de seguridad del sistema
o el software a menudo se confunden con los requisitos de software
seguro:
» Requisitos servicios de seguridad. Incluye la especificación de
funciones que implementan una política de seguridad, como control de
acceso, autenticación, autorización, cifrado y gestión de claves. En la
siguiente figura se muestra un alcance completo de este tipo de
requisitos:
REQUISITOS SERVICIOS DE SEGURIDAD
Ilustración 14 Requisitos servicios de seguridad Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama
Fuente: Proyecto FCI
81
Deben especificar:
Propiedades que el software debe exhibir, ejemplo: el software debe tener
un comportamiento correcto y predecible y disponer de capacidades de
recuperación frente a ciberataques.
Nivel requerido de seguridad y salvaguardas de riesgo de las funciones de
seguridad. Los controles y normas que rigen los procesos de desarrollo,
implementación y operación del software.
» Requisitos de software seguro. Requisitos que afectan directamente a la
probabilidad de que el software sea seguro. Estos abarcan principalmente
los no funcionales, los que garanticen que el sistema seguirá siendo
confiable, incluso cuando esa confianza se vea amenazada.
Vista de alto nivel de las tareas y artefactos involucrados
en la fase de requisitos
Ilustración 15 Vista de alto nivel de las tareas y artefactos involucrados en la fase de requisitos Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama
Fuente: Proyecto FCI
82
Es fundamental que los requisitos de seguridad del software sean:
» Completos.
» Precisos.
» Coherentes.
» Trazables.
» Verificables.
Existen, provenientes de ingeniería de software, una serie de herramientas
que permiten mantener la trazabilidad y gestión de los requisitos de
seguridad de sistemas complejos y críticos. Entre ellas tenemos:
» Praxis High Integrity Systems’ REVEAL.
» Telelogic’s DOORS.
» ChiasTek’s REQTIFY.
» Safeware Engineering’s SpecTRM.
Uno de los problemas típicos relacionados con la ingeniería de software
es el análisis de requisitos o bien no se realiza en absoluto (los requisitos
identificados se especifican directamente sin ningún análisis o modelado)
o se limita a los requisitos funcionales, haciendo caso omiso de las
exigencias de calidad y otras limitaciones, como la arquitectura, el diseño,
implementación y pruebas.
4.- Análisis de riesgo. Arquitectónico
Según estudios y estadísticas disponibles se sabe que aproximadamente
un 50 % de los defectos de seguridad se deben a errores en la fase de
diseño denominados «debilidades» o «flaws» en idioma Ingles.
Identificando el riesgo y después con la gestión del mismo se pueden
mitigar gran parte de los problemas de seguridad de un software.
83
Ilu
str
ació
n 1
6 A
nális
is d
e r
iesgos
Ela
bo
rad
o p
or:
Kath
erine S
anta
na S
anta
na -
Ste
ve F
iallo
s L
ala
ma
Fu
en
te:
Pro
yecto
FC
I
AN
ÁL
ISIS
DE
RIE
SG
OS
84
En la figura anterior, se puede observar que el análisis de riesgos está a
caballo entre la fase análisis de requisitos, donde se obtienen los
requisitos de seguridad, se modelan ataques y realizan casos de abuso, y
la fase de la fase de arquitectura y diseño. Sigue en importancia a la
revisión de código, si bien este hecho puede variar dependiendo de las
características de la organización, de sus tipos de sistemas, cantidad de
software, etc.
En la fase de análisis al obtener los requisitos de seguridad se han
obtenido bastantes conclusiones acerca de los activos del sistema y del
impacto que los posibles ataques pueden causar, pero es en la fase de
diseño de la arquitectura del sistema donde se especifican todos los
activos porque se obtienen todos los componentes hardware y software
del sistema, se configura la arquitectura y se deciden las salvaguardas
concretas que van a protegerlo, en función de los requisitos de seguridad
y los casos de abuso.
Un análisis de riesgo riguroso implica un exhaustivo entendimiento del
impacto sobre el negocio u objetivos de la organización, que puede
requerir un conocimiento de leyes y regulaciones tanto como del modelo
de negocio soportado por el software. También, los desarrolladores y
diseñadores habrán llegado a ciertas suposiciones sobre su sistema y los
riesgos que este afronta.
Un acercamiento a un prototipo de análisis y gestión de riesgo típico
implica varias actividades principales que a menudo incluyen un número
de actividades básicas:
85
» Leer y entender las especificaciones, documentos de arquitectura, y
otros documentos de diseño.
» Discutir sobre el objetivo de análisis con el grupo: brainstorming.
» Determinar los límites del sistema y datos sensibles y críticos.
» Probar el software si ya existe algún prototipo.
» Estudiar el código y otros componentes de software incluyendo el
empleo de herramientas de análisis de código.
» Identificar las amenazas y las fuentes relevantes de ataque. Esta tarea
se deriva fácilmente si se ha hecho previamente la obtención de casos de
abuso y los requisitos de seguridad del sistema.
» Identificar vulnerabilidades posibles, aprovechando el uso de
herramientas y documentación sobre vulnerabilidades comunes.
» Discutir las posibles modificaciones o parches para corregir
vulnerabilidades.
» Determinar la probabilidad de riesgo.
» Planificar escenarios de ataque para explotación de las
vulnerabilidades.
» Determinar el posible impacto sobre los activos y objetivos de negocio.
» Clasificar los riesgos.
» Desarrollar una estrategia de mitigación.
» Recomendar las salvaguardas para mitigar los riesgos.
» Informe de conclusiones.
» Proporcionar la información básica en cuanto a dónde emplear recursos
de mitigación limitados.
86
Un análisis de riesgos es un proceso sistemático que tiene como
propósito estimar la magnitud y probabilidad de los riesgos a los que
podría estar expuesta una organización y saber qué decisión tomar ante
una posible eventualidad. Este proceso aplicado el desarrollo y diseño del
software se denomina «Modelado de Amenazas». Constituye una
herramienta válida para evaluar los riesgos inherentes a una aplicación
durante su desarrollo, principalmente en la etapa de diseño, y que puede
ser utilizada por equipos de desarrollo que no cuenten con expertos en
seguridad.
Existen varios métodos o metodologías de Modelado de Amenazas que
se pueden aplicar al desarrollo de software:
Tabla 11 Metodologías de análisis de riesgos
Metodologías
1 CORAS (Consultative Objective Risk Analysis System) and SECURIS
(Research Council of Norway-funded Model-Driven Development and
Analysis of Secure Information Systems).
Herramienta
2 CIGITAL's architectural risk analysis process.
3 OCTAVE (Operationally Critical Threat, Asset, and Vulnerability
Evaluation). SEI de la Universidad Carnegie Mellon
4 PTA Technologies Calculative Threat Modeling Methodology (CTMM).
5 Trike. Metodología de evaluación de amenazas.
6 MTAM (Microsoft Threat Analysis and Modeling).
7 PASTA (Process for Attack Simulation and Threat Analysis).
Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama Fuente: Proyecto FCI
- 87 -
5.- Patrones de diseño
Según se define en el documento de referencias (McGraw, 2005) los
patrones de diseño son:
Una solución general repetible a un problema de ingeniería de software
recurrente, que está expresamente destinado a contribuir al diseño de
software menos vulnerable, más resistente y tolerante a los ataques.
- 88 -
Ilu
str
ació
n 1
7 P
atr
ones d
e d
iseño
Ela
bo
rad
o p
or:
Kath
erine S
anta
na S
anta
na -
Ste
ve F
iallo
s L
ala
ma
Fu
en
te:
Pro
yecto
FC
I
Patr
on
es d
e d
iseñ
o
- 89 -
El concepto de patrones es más familiar en ingeniería de software,
relacionados principalmente con la arquitectura de los sistemas o
soluciones para el diseño de los mismos. Se han desarrollado patrones de
diseño de seguridad para casi todas las fases del SDLC: requerimientos,
análisis, diseño, codificación, etc. El uso adecuado de estos patrones
conduce a la remediación de los principales fallos de seguridad, como, por
ejemplo, uno que tuvo un efecto significativo fue un «validador» que
construía un modelo de validación de entrada para defenderse contra los
ataques de inyección SQL, otros ejemplos son los construidos para los
lenguajes de programación en C y / o C + +.
Etapas de la metodología del proyecto
La metodología Scrum es la elegida para llevar a cabo el desarrollo.
Sin embargo, hay que tomar en cuenta lo siguiente: esta investigación
es una secuencia de un proyecto FCI, se tomó la parte que
corresponde a la fase de recolección de información.
Reunión del Scrum Diario
En esta reunión se necesita establecer los requerimientos de
seguridad los cuales no son contemplados en el caso de uso de
recolección de información:
• Se visualiza que no posee un proceso registro de usuario.
• Se visualiza que no posee un proceso de inicio sesión.
• No se visualiza proceso de bloqueo de duplicidad de usuario o
registro.
• No se percibe un proceso de encriptamiento de mensaje.
- 90 -
Para esto se debe implementar dentro del modelo seleccionado para este
estudio, los requisitos antes definidos se dividirán en Sprint en donde
cada uno tendrá que analizar y resolver cada iteración.
Scrum Diario
Para el seguimiento y control de las actividades se usará el servicio de
mensajería multiplataforma WhatsApp, una vez realizado los
requerimientos se establecen las tareas a ejecutarse y el tiempo estimado
para la culminación de la misma, para este trabajo de titulación.
Dentro del mismo se revisarán los resultados del scrum anterior para
optimizar o mejorar los resultados y el tiempo de culminación.
Roles
En esta parte se definen los roles de los interesados en el proyecto.
Tabla 12 Roles Scrum
Integrantes Cargo
Ing. Tania Peralta Guaraca, M. Sc. Líder del proyecto/ Scrum Máster
Ing. Jimmy Sornoza Moreira M. Sc. Product Owner (Profesional
Delegado)
Steve Pietro Fiallos Lalama Estudiante de Titulación
Katherine Santana Santana Estudiante de Titulación
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia
En la tabla N. 12 podemos observar a los interesados, el Scrum Máster es
la persona encargada de gestionar el proyecto, el Product Owner es el
dueño del producto, gestiona el proyecto, revisa y prioriza los ítems del
Backlog, los Estudiantes de titulación son los encargados de realizar el
desarrollo del proyecto de titulación.
- 91 -
Burndown chart
El Burndown chart es una gráfica donde se contrasta las horas estimadas
frente a las horas reales de trabajo para conocer el progreso del proyecto
como se muestra en la tabla.
Product Backlog
El Product Backlog está conformado por 3 historia de usuario y 3 sprint
que se detallarán en los siguientes cuadros.
Reuniones
Las reuniones se efectuarán los días miércoles y tendrán una duración de
dos horas, en esta participarán el Scrum Máster ye el equipo de alumnos,
se presentarán avances del estudio realizado.
Lista de Sprint
Los Sprint son un conjunto de tareas que se deben cumplir en cada fase
del proyecto. Al finalizar cada Sprint los resultados se presentan al dueño
del producto para que este apruebe el avance o sugiera cambios en el
mismo.
Trabajo de Desarrollo del Sprint
Para esto se añadió las funcionalidades que no se tomaron en
consideración.
Revisión del Sprint
Se inspeccionó lo planteado anteriormente y compararemos con el
modelo que tendremos como resultado.
Retrospectiva del Sprint Se entrega el caso de uso con las mejoras
realizada.
- 92 -
Ilu
str
ació
n 1
8 M
odelo
de C
aso d
e U
so
Ela
bo
rad
o p
or:
Kath
erine S
anta
na S
anta
na -
Ste
ve F
iallo
s L
ala
ma
Fu
en
te:
Pro
yecto
FC
I
CR
ITE
RIO
S D
E V
AL
IDA
CIÓ
N D
E L
A P
RO
PU
ES
TA
Para
vali
dar
el
caso
de a
bu
so
se h
an
co
nsid
era
do
s ju
icio
s d
e e
xp
ert
os
Mo
delo
de
Caso
de
Uso
Re
co
lecc
ión
- 93 -
Tabla 13 HISTORIA DE USUARIO N.1
Historias de usuario
Número: 1 Usuario: Líder de proyecto
Nombre de la Historia: Introducción de proyecto a realizar
Prioridad en negocio: Alta
Riesgo en desarrollo: Baja
Puntos estimados: 1 Iteración asignada: 1
Responsable: Steve Fiallos Lalama – Katherine Santana Santana
Descripción: Se toma el caso de uso de la “PLATAFORMA TECNOLÓGICA PARA CONTRIBUIR LA PLANEACIÓN URBANA DE LA CIUDAD DE GUAYAQUIL DIRIGIDO A LA TRANSPORTACIÓN”. Del módulo de Recolección para poder realizar el estudio de caso de abuso, se buscará información sobre los casos de abusos.
Observación:
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia
Dentro de este modelo se pudo observar que el modelo de caso de uso
de recolección de datos no posee la implementación de la seguridad
debidamente implementada donde se puede recibir el daño potencial las
cuales pueden ser:
- Suplantación de Usuario
- Duplicidad de registros
- Información en claro (Sin método de cifrado).
Por lo que en este trabajo se realiza la respectiva implantación de la
seguridad que necesita el caso y uso.
- 94 -
Tabla 14 Burndown chart Sprint N. 1
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama
Fuente: Elaboración Propia
Tabla 15. ESTIMACIÓN DE TIEMPO SPRINT N. 1
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia
Burndown chart Sprint N. 1
Ilustración 19 Burndown chart Sprint N. 1 Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama
Fuente: Elaboración Propia
Estimado día 1 día 2 día 3 día 4 día 5 Total,
horas
Tarea 1 24 5 5 5 5 4 24
Tarea 2 24 5 5 5 5 4 24
Tarea 3 18 3 3 3 3 6 18
Tarea 4 18 3 3 3 3 6 18
Horas Reales
84 71 58 42 26 10 0
Horas estimadas
84 68 52 36 20 4 0
- 95 -
Tabla 16. Sprint N.1
N° Tareas del Sprint #1
1
2
3
4
Introducción de proyecto a realizar Horas
• Seleccionamos el caso de uso de la “PLATAFORMA
TECNOLÓGICA PARA CONTRIBUIR LA
PLANEACIÓN URBANA DE LA CIUDAD DE
GUAYAQUIL DIRIGIDO A LA TRANSPORTACIÓN”.
Del módulo de Recolección.
• Verificar si cumple con las condiciones necesarias
para proceder a realizar su estudio.
• Comprobar la inexistencia del caso de abuso en
el caso a estudiar.
• Analizar la factibilidad del estudio a realizar dentro
del caso seleccionado.
24
24
18
18
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia
- 96 -
Guayaquil 20 de febrero del 2019
SR(a)
Presente. -
Tengo el agrado de dirigirme a Usted, para saludarlo cordialmente y a la
vez manifestarle que, conocedores de su trayectoria académica y
profesional, molestamos su atención al elegirlo como JUEZ EXPERTO
para revisar el contenido del instrumento que pretendemos utilizar en la
Tesis.
Titulada
“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”
Para optar el título de Ingenieros en Sistemas Computacionales, por la
Facultad de Ciencias Matemáticas y Físicas, Carrera de Ingeniería en
Sistemas Computacionales de la Universidad de Guayaquil. El
instrumento tiene como objetivo:
Elaborar técnicas que permitan desarrollar un estudio sobre el caso
de abuso con respecto al desarrollo de software y la necesidad de
implementar algunas técnicas que permitan mejorar la seguridad, a
través de un caso de uso de requerimientos de información de una
plataforma tecnológica.
Por lo que, con la finalidad de determinar la validez de su contenido,
solicitamos marcar con una X el grado de evaluación a los indicadores
para los ítems del instrumento, de acuerdo a su amplia experiencia y
conocimientos
- 97 -
1. Muy Bajo (0% - 25%)
2. Bajo (26% - 50%)
3. Alto (51% - 75%)
4. Muy Alto (76% - 100%)
Si considera necesario, señálelo en la casilla de observaciones.
DOCENTE
CC.
Validación
INDICADORES ÍTEMS 1 2 3 4
SESIÓN ¿Cuál es la importancia de tener un inicio de sesión seguro?
REGISTRO ¿Usted considera necesario validar duplicidad de registros?
MENSAJE ¿La consideración de encriptamiento para los mensajes en
un caso de uso que tan transcendental creé usted que es?
SEGURIDAD ¿Usted considera que se deba incluir casos de seguridad en
el diagrama de los casos de uso?
ACCESOS
¿Usted con qué importancia creé que se debe limitar los
registros de datos tanto de usuario, como datos a ingresar en
los diagramas de casos de uso?
DISEÑO
¿Cuál es la importancia que nos brinda los casos de
seguridad establecidos en el diagrama de casos de uso en
una aplicación?
TOTAL
OBSERVACIONES
- 98 -
Ilu
str
ació
n 2
0 M
odelo
de C
aso d
e U
so Im
ple
menta
ndo S
eg
urid
ad
Ela
bo
rad
o p
or:
Kath
erine S
anta
na S
anta
na -
Ste
ve F
iallo
s L
ala
ma
Fu
en
te:
Ela
bora
ció
n P
ropia
Mo
delo
de
Caso
de
Uso
Im
ple
men
tan
do
Seg
uri
dad
- 99 -
Tabla 17. HISTORIA DE USUARIO N.2
Historias de usuario
Número: 2 Usuario: Líder de proyecto
Nombre de la Historia: Implementación de Seguridad
Prioridad en negocio: Alta
Riesgo en desarrollo: Alta
Puntos estimados: 1 Iteración asignada: 1
Responsable: Steve Fiallos Lalama – Katherine Santana Santana
Descripción: Se implementará la seguridad en el caso de uso para la “PLATAFORMA TECNOLÓGICA PARA CONTRIBUIR LA PLANEACIÓN URBANA DE LA CIUDAD DE GUAYAQUIL DIRIGIDO A LA TRANSPORTACIÓN”. Del módulo de Recolección. Realizar el Cuestionario para el Juicio de experto.
Observación:
Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama Fuente: Proyecto FCI
En el anexo 2 se proporciona el respaldo del juicio de experto realizado
por el Ing. Jimmy Sornoza en el cual, nos corresponde como justificativo
para las diferentes evaluaciones tales como son el Caso de Uso General
y el Caso de Uso con implementación de Seguridad.
En este anexo se puede observar de mejor manera el caso de uso con su
respectiva implementación de seguridad necesaria para esta plataforma,
que posteriormente nos servirá de base o punto de partida para aplicación
la de los casos de abuso y su ejecución.
- 100 -
Tabla 18. Burndown chart Sprint N. 2
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama
Fuente: Elaboración Propia
ESTIMACIÓN DE TIEMPO SPRINT N. 2
COMPARACIÓN DE HORAS REALES Y HORAS ESTIMADAS SPRINT N. 2
Tabla 19. ESTIMACIÓN DE TIEMPO SPRINT N. 2
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama
Fuente: Elaboración Propia
Burndown chart Sprint N. 2
Ilustración 21 Burndown chart Sprint N. 2
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia
Estimado día 1 día 2 día 3 día 4 día 5 Total,
horas
Tarea 1 12 3 3 3 3 0 12
Tarea 2 12 3 3 3 3 0 12
Tarea 3 12 3 3 3 3 0 12
Tarea 4 14 3 3 3 3 2 14
Tarea 5 120 24 24 24 24 240 120
Tarea 6 6 2 2 2 0 0 6
Horas Reales 176 157 138 119 100 81 62 43 24 5
0
Horas estimadas 176 157 138 119 100 81 62 43 24 5 0
- 101 -
Tabla 20. Sprint N. 2
N° Tareas del Sprint #2
1
2
3
4
5
6
Implementación de Seguridad Horas
• Verificación de inexistencia de seguridad en el
caso de estudio.
• Análisis y comprobación de puntos focales del
caso a estudiar.
• Análisis del impacto a provocar dentro del modelo
estudiado.
• Lluvia de ideas bajo la supervisión del scrum
master.
• Implementación de la seguridad por parte del
team de estudiantes de titulación.
• Desarrollo de cuestionario para respectiva
validación de juicio de experto.
12
12
12
14
120
6
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia
- 102 -
Guayaquil 20 de febrero del 2019
SR(a)
Presente. -
Tengo el agrado de dirigirme a Usted, para saludarlo cordialmente y a la
vez manifestarle que, conocedores de su trayectoria académica y
profesional, molestamos su atención al elegirlo como JUEZ EXPERTO
para revisar el contenido del instrumento que pretendemos utilizar en la
Tesis.
Titulada
“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”
Para optar el título de Ingenieros en Sistemas Computacionales, por la
Facultad de Ciencias Matemáticas y Físicas, Carrera de Ingeniería en
Sistemas Computacionales de la Universidad de Guayaquil. El
instrumento tiene como objetivo:
Elaborar técnicas que permitan desarrollar un estudio sobre el caso
de abuso con respecto al desarrollo de software y la necesidad de
implementar algunas técnicas que permitan mejorar la seguridad, a
través de un caso de uso de requerimientos de información de una
plataforma tecnológica.
Por lo que, con la finalidad de determinar la validez de su contenido,
solicitamos marcar con una X el grado de evaluación a los indicadores
para los ítems del instrumento, de acuerdo a su amplia experiencia y
conocimientos
- 103 -
1. Muy Bajo (0% - 25%)
2. Bajo (26% - 50%)
3. Alto (51% - 75%)
4. Muy Alto (76% - 100%)
Si considera necesario, señálelo en la casilla de observaciones.
DOCENTE
CC.
Validación
INDICADORES ÍTEMS 1 2 3 4
SESIÓN ¿Cuál es la importancia de tener un inicio de sesión seguro?
REGISTRO ¿Usted considera necesario validar duplicidad de registros?
MENSAJE ¿La consideración de encriptamiento para los mensajes en
un caso de uso que tan transcendental creé usted que es?
SEGURIDAD ¿Usted considera que se deba incluir casos de seguridad en
el diagrama de los casos de uso?
ACCESOS
¿Usted con qué importancia creé que se debe limitar los
registros de datos tanto de usuario, como datos a ingresar en
los diagramas de casos de uso?
DISEÑO
¿Cuál es la importancia que nos brinda los casos de
seguridad establecidos en el diagrama de casos de uso en
una aplicación?
TOTAL
OBSERVACIONES
- 104 -
Ilu
stra
ció
n 2
2 I
mp
lem
enta
ció
n d
el A
buso
en
Mo
del
o C
aso
de
Uso
Ela
bo
rad
o p
or:
Kat
her
ine
San
tan
a S
anta
na
- S
tev
e F
iall
os
Lal
ama
Fu
en
te:
Ela
bora
ció
n P
ropia
Imp
lem
en
tació
n d
el
Ab
uso
en
el M
od
elo
de
Caso
de
Uso
- 105 -
Tabla 21. HISTORIA DE USUARIO N.3
Historias de usuario
Número: 3 Usuario: Líder de proyecto
Nombre de la Historia: Abuso en el Módulo de Recolección
Prioridad en negocio: Alta
Riesgo en desarrollo: Alta
Puntos estimados: 1 Iteración asignada: 1
Responsable: Steve Fiallos Lalama – Katherine Santana Santana
Descripción: Se realizará el Abuso en el caso de uso de “PLATAFORMA TECNOLÓGICA PARA CONTRIBUIR LA PLANEACIÓN URBANA DE LA CIUDAD DE GUAYAQUIL DIRIGIDO A LA TRANSPORTACIÓN”. Del módulo de Recolección
Observación:
Elaborado por: Katherine Santana Santana - Steve Fiallos Lalama Fuente: Elaboración Propia
En el anexo 3,4,5, se proporciona el respaldo del juicio de experto
realizado por los ingenieros expertos en ambiente de seguridad los cuales
son Ing. Alfredo Arrese, Ing. Johana Trejo, Ing. Carlos Corral como
justificativo para la evaluación del Caso de Uso con implementación de
Seguridad y Caso de Abuso.
Dichos anexos son respaldo del caso de uso ya implementado su
seguridad y abuso, en el grafico 9 se puede observar el caso de uso final
que debe ser considerado como caso de uso a desarrollarse, por medio
del cual nos ayudara a tener una plataforma que cumpla con el objetivo
principal de este trabajo de titulación.
- 106 -
Tabla 22. Burndown chart Sprint N. 3
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia
Tabla 23. ESTIMACIÓN DE TIEMPO SPRINT N. 3
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia
Burndown chart Sprint N. 3
Ilustración 23 Burndown chart Sprint N. 3
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia
Estimado día 1 día 2 día 3 día 4 día 5 Total,
horas
Tarea 1 10 2 2 2 2 2 10
Tarea 2 24 5 5 5 5 4 24
Tarea 3 120 24 24 24 24 24 120
Tarea 4 6 1 2 1 1 1 14
Horas Reales 160 142 124 106 88 70 52 34 16 0 0
Horas estimadas 160 144 128 112 96 80 64 48 32 16 0
- 107 -
Tabla 24. Sprint N. 3
N° Tareas del Sprint #3
1
2
3 4
Abuso en el Módulo de Recolección Horas
• Comprobación del caso a estudiar cumpla con los
requisitos necesarios para la respectiva
implementación de abuso.
• Análisis del impacto a provocar dentro del modelo
estudiado.
• Desarrollo del caso de abuso en el caso de
estudio de este trabajo de titulación.
• Entrevista a los expertos seleccionados y
realización de cuestionario para respectiva
validación de juicio de experto.
10
24
120
6
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia
- 108 -
Guayaquil 20 de febrero del 2019
Sr(a)
Presente. -
Tengo el agrado de dirigirme a Usted, para saludarlo cordialmente y a la
vez manifestarle que, conocedores de su trayectoria académica y
profesional, molestamos su atención al elegirlo como JUEZ EXPERTO
para revisar el contenido del instrumento que pretendemos utilizar en la
Tesis.
Titulada
“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”
Para optar el título de Ingenieros en Sistemas Computacionales, por la
Facultad de Ciencias Matemáticas y Físicas, Carrera de Ingeniería en
Sistemas Computacionales de la Universidad de Guayaquil. El
instrumento tiene como objetivo:
Elaborar técnicas que permitan desarrollar un estudio sobre el caso
de abuso con respecto al desarrollo de software y la necesidad de
implementar algunas técnicas que permitan mejorar la seguridad, a
través de un caso de uso de requerimientos de información de una
plataforma tecnológica.
Por lo que, con la finalidad de determinar la validez de su contenido,
solicitamos marcar con una X el grado de evaluación a los indicadores
para los ítems del instrumento, de acuerdo a su amplia experiencia y
conocimientos.
- 109 -
DOCENTE
CC.
1. Muy Bajo (0% - 25%)
2. Bajo (26% - 50%)
3. Alto (51% - 75%)
4. Muy Alto (76% - 100%)
Si considera necesario, señálelo en la casilla de observaciones.
Validación
INDICADORES ÍTEMS 1 2 3 4
SESIÓN
¿Es recomendable realizar una verificación de la
confiabilidad del software bajo posibles condiciones de
intromisiones o ataques?
REGISTRO
¿Considera usted importante verificar el comportamiento
seguro y cambios de estados confiables al momento de
ingresar datos al sistema?
MENSAJE ¿Qué tanto se debe considerar la precaución de los datos
con referencia a la entrada y estructura de los mismos?
SEGURIDAD ¿Usted considera que se deba incluir casos de seguridad en
el diagrama de los caso de uso?
DAÑOS ¿En qué medida de gravedad considera Ud. que el abuso en
un caso de uso pueda afectar el diseño de su sistema?
DISEÑO
¿En qué medida considera Usted que una guía de casos de
Abuso ayudaría a elaborar los casos de seguridad de un
diagrama caso de uso?
TOTAL
OBSERVACIONES
- 110 -
Tabla 25. Pila del Proyecto
Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama Fuente: Elaboración Propia
Entregables del proyecto
Se entregará el modelo ya implementado los casos de abuso de
seguridad y el caso de seguridad los cuales deben ser tomados en
consideración, para su respectiva implementación en el proyecto
inicial.
Identificador de la
Historia Descripción Estado Prioridad
1
Introducción de proyecto a
realizar
Hecho Alta
2
Implementación de Seguridad
Hecho Alta
3
Abuso en el Módulo de
Recolección
Hecho Alta
- 111 -
CAPÍTULO IV
Criterios de aceptación del producto o Servicio
A continuación, se adjunta la carta de aceptación del producto aprobada
por el líder del proyecto de la “Plataforma Tecnológica Para Contribuir La
Planeación Urbana De La Ciudad De Guayaquil Dirigido A La
Transportación”, de la cual se realizó un análisis con su respectiva
elaboración del modelo para el caso de seguridad y caso de abuso del
Módulo de Recolección para su posterior implementación ya que los
modelos entregados pueden servir de ayuda para evitar ataques y
violaciones al momento de desarrollar un sistema.
Estos modelos son entregados como pauta para realizar el estudio de los
demás módulos que se encuentran en la plataforma ya que mediante
ellos se podrá obtener un mejor funcionamiento del sistema antes
mencionado.
- 112 -
Guayaquil, 18 de marzo del 2019.
A C E P T A C I O N D E L P R O D U C T O
Certifico que los estudiantes SANTANA SANTANA KATHERINE Y
FIALLOS LALAMA STEVE, cumplen con el proceso de evaluación de
desempeño en la elaboración del caso de seguridad y caso de abuso para
su posterior implementación, sobre el caso de uso denominado
“RECOLECCIÓN DE INFORMACIÓN” de la “PLATAFORMA
TECNOLÓGICA PARA CONTRIBUIR LA PLANEACIÓN URBANA DE
LA CIUDAD DE GUAYAQUIL DIRIGIDO A LA TRANSPORTACIÓN”.
Los estudiantes en mención estuvieron a cargo de la creación del
MODELO DE CASO DE ABUSO Y SU RESPECTIVA SEGURIDAD
sobre el CASO DE USO EXISTENTE, obteniendo el 100% del
cumplimiento de sus alcances asignados.
Ing. Jimmy Sornoza Moreira
CC. 092043376-0
LÍDER DE PROYECTO FCI.
- 113 -
CONCLUSIONES
Para el Modulo de Recolección de la “Plataforma Tecnológica Para
Contribuir La Planeación Urbana De La Ciudad De Guayaquil Dirigido A
La Transportación” y el estudio de casos de abuso se consideraron las
siguientes conclusiones:
Se determinó las debilidades del caso de uso del Módulo de
Recolección, lo que conllevó a las respectivas mejoras para cumplir
con el objetivo propuesto, proporcionado a la plataforma una solución.
Se establecieron las etapas respectivas para crear un modelo de caso
de abuso que permitan guiar en el módulo de recolección las
seguridades necesarias para evitar ataques u otros tipos de violación
a un sistema.
Se realizaron los modelos de caso de seguridad, caso de abuso que
permiten que el sistema cumpla con los parámetros necesarios en
cuanto a seguridad que debe ser considerado para nuevas fases en la
“Plataforma Tecnológica Para Contribuir La Planeación Urbana De La
Ciudad De Guayaquil Dirigido A La Transportación”
- 114 -
RECOMENDACIONES
Se debe considerar realizar el caso de uso de seguridad y casos de
abuso de los demás módulos con los que cuenta la plataforma, ya
que este estudio se basó en el módulo de recolección y no se
encuentra implementado en los restantes.
Crear análisis más profundo de herramientas que permitan
implementar de manera sistémica los casos de seguridad y los
casos de mal uso.
El modelo que aquí se plantea puede ser utilizado en otros
sistemas, ya que se detallan las etapas para la construcción de
casos de abuso.
El trabajo realizado en esta tesis de grado puede servir como guía
para investigaciones posteriores relacionadas al tema puesto que,
las herramientas utilizadas tienen mucho por ser exploradas aun y
el tema central involucra el beneficio de todo el país.
- 115 -
BIBLIOGRAFÍA
Darío Correal, N. L. (13 de 03 de 2016). Obtenido de
https://profesores.virtual.uniandes.edu.co/~isis3702/dokuwiki/lib/exe/fetch
.php?media=principal:isis3702-securityperspective.pdf
Darío Correal, Nicolás López. (s.f.). Obtenido de
https://profesores.virtual.uniandes.edu.co/~isis3702/dokuwiki/lib/exe/fetch
.php?media=principal:isis3702-securityperspective.pdf
Gregorio Rodríguez Gómez,Javier Gil Flores,Eduardo García Jiménez. (1996).
METODOLOGIA DE LA INVESTIGACION CUALITATIVA.
METODOLOGIA DE LA INVESTIGACION CUALITATIVA. Granada ,
Granada , España: Ediciones Aljibe.
Ferrer, J (I.U.T.A. 2010). Sección 02 de higiene y seguridad industrial.
Obtenido de
http://metodologia02.blogspot.com/p/operacionalizacion-de-variables.html
De los Reyes, D. (2009). Incorporando la seguridad al proceso de desarrollo de
software. Obtenido de
https://www.securityartwork.es/2009/10/23/incorporando-la-seguridad-al-
proceso-de-desarrollo-de-software/
Salazar, L. (2012). Casos de Abuso. Obtenido de
http://www.gazafatonarioit.com/2012/09/casos-de-abuso-parte-4.html
McDermott, J – Fox C. (1999). Using Abuse Case Models for Security
Requirements Analysis. Obtenido de
http://www.andrew.cmu.edu/course/95-750/docs/CaseModels.pdf
SOLUS S.A. (2000-2019). Tutorial UML 2.3. Obtenido de
http://www.sparxsystems.com.ar/resources/uml2_tutorial.html
- 116 -
ANEXOS
- 117 -
Anexo 1
Cronograma de Proyecto de Titulación.
- 118 -
- 119 -
Anexo 2 Respaldo de juicio de experto referente al
Ing. Sornoza Moreira Jimmy MSc.
- 120 -
- 121 -
Anexo 3 Respaldo de juicio de experto referente al
Ing. Corral Espinoza Carlos Msc.
- 122 -
- 123 -
Anexo 4 Respaldo de juicio de experto referente al
Ing. Trejo Alarcon Johana MSc.
- 124 -
- 125 -
Anexo 5 Respaldo de juicio de experto referente al
Ing. Arrese Vilche Alfredo Msc.
- 126 -
- 127 -
Anexo 6 Reunión Equipo Trabajo
- 128 -
Integrantes: Steve Fiallos – Katherine Santana
- 129 -
Anexo 7 Carta de Aceptación del Producto
- 130 -
Top Related