universidad de guayaquil - ugrepositorio.ug.edu.ec/bitstream/redug/39902/1/b... · fiallos lalama...

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

mailto:[email protected]



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,


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


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


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:


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




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


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




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


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


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.

http://searchsoftwarequality.techtarget.com/definition/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


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


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


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


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


- 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


- 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


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


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


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.


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.


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


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


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


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


- 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


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:


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


Tabla 15. ESTIMACIÓN DE TIEMPO SPRINT N. 1


Burndown chart Sprint N. 1

Ilustración 19 Burndown chart Sprint N. 1 Elaborado por: Katherine Santana Santana, Steve Fiallos Lalama


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


- 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


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



Nombre de la Historia: Implementación de Seguridad


Riesgo en desarrollo: Alta



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:


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



ESTIMACIÓN DE TIEMPO SPRINT N. 2

COMPARACIÓN DE HORAS REALES Y HORAS ESTIMADAS SPRINT N. 2





Ilustración 21 Burndown chart Sprint N. 2



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


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


- 102 -


SR(a)

Presente. -





Tesis.

Titulada

“ANÁLISIS DE CASOS DE ABUSO E IMPLEMENTACIÓN DEL MODELO


SEGURIDAD EN UN CASO DE USO”













conocimientos

- 103 -

1. Muy Bajo (0% - 25%)

2. Bajo (26% - 50%)

3. Alto (51% - 75%)

4. Muy Alto (76% - 100%)


DOCENTE

CC.

Validación


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?


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



Nombre de la Historia: Abuso en el Módulo de Recolección


Riesgo en desarrollo: Alta



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





Ilustración 23 Burndown chart Sprint N. 3



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


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


- 108 -


Sr(a)

Presente. -





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”













conocimientos.

- 109 -

DOCENTE

CC.

1. Muy Bajo (0% - 25%)

2. Bajo (26% - 50%)

3. Alto (51% - 75%)

4. Muy Alto (76% - 100%)


Validación


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?


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


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 -


Ing. Corral Espinoza Carlos Msc.

- 122 -

- 123 -


Ing. Trejo Alarcon Johana MSc.

- 124 -

- 125 -


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 -

universidad de guayaquil - ugrepositorio.ug.edu.ec/bitstream/redug/39902/1/b... · fiallos lalama...

Documents