APLICATIVO PARA LA GESTIÓN DE INCIDENTES DE SEGURIDAD DE ...
155
1 APLICATIVO PARA LA GESTIÓN DE INCIDENTES DE SEGURIDAD DE LA INFORMACIÓN EN APLICACIONES, BASADO EN LA NTC-ISO/IEC 27002- 27035. PARA EL CASO DE USO DE LA UNIVERSIDAD DISTRITAL FABIÁN ENRIQUE BOCANEGRA DÍAZ JEFFERSON SNEIDER ORDOÑEZ TOVAR UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA TECNOLOGÍA EN SISTEMATIZACIÓN DE DATOS BOGOTÁ D.C. 2015
Transcript of APLICATIVO PARA LA GESTIÓN DE INCIDENTES DE SEGURIDAD DE ...
1
APLICATIVO PARA LA GESTIÓN DE INCIDENTES DE SEGURIDAD DE LA
INFORMACIÓN EN APLICACIONES, BASADO EN LA NTC-ISO/IEC 27002-
27035. PARA EL CASO DE USO DE LA UNIVERSIDAD DISTRITAL
FABIÁN ENRIQUE BOCANEGRA DÍAZ
JEFFERSON SNEIDER ORDOÑEZ TOVAR
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
TECNOLOGÍA EN SISTEMATIZACIÓN DE DATOS
BOGOTÁ D.C.
2015
2
APLICATIVO PARA LA GESTIÓN DE INCIDENTES DE SEGURIDAD DE LA
INFORMACIÓN EN APLICACIONES, BASADO EN LA NTC-ISO/IEC 27002-
27035. PARA EL CASO DE USO DE LA UNIVERSIDAD DISTRITAL
FABIAN ENRRIQUE BOCANEGRA DIAZ
JEFFERSON SNEIDER ORDOÑEZ TOVAR
TUTOR:
SONIA ALEXANDRA PINZÓN
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
TECNOLOGÍA EN SISTEMATIZACIÓN DE DATOS
BOGOTÁ D.C.
2015
3
Tabla de contenido RESUMEN ................................................................................................................................................................................. 7
ABSTRACT ............................................................................................................................................................................... 8
INTRODUCCIÓN ...................................................................................................................................................................... 9
1. FASE DE INICIO, PLANEACIÓN, DEFINICIÓN Y ORGANIZACIÓN ........................................ 10
1.1 TÍTULO DEL PROYECTO ....................................................................................................... 10
1.2 TEMA ......................................................................................................................................... 10
1.3 PLANTEAMIENTO DEL PROBLEMA ................................................................................... 10
1.4 DESCRIPCIÓN DEL PROBLEMA ......................................................................................... 11
1.5 FORMULACIÓN DEL PROBLEMA ....................................................................................... 12
1.6 JUSTIFICACIÓN ...................................................................................................................... 13
1.7 OBJETIVOS .............................................................................................................................. 14
Objetivo General ....................................................................................................................14
Objetivos específicos ............................................................................................................14
1.8 ALCANCE ......................................................................................................................15
1.8.1 A nivel funcional ...........................................................................................................15
1.9 DELIMITACIONES ........................................................................................................16
Delimitación Temporal ..........................................................................................................16
Delimitación Geográfica ........................................................................................................16
Delimitación Técnica .............................................................................................................16
1.10 FACTIBILIDAD ..............................................................................................................17
Factibilidad Técnica ...............................................................................................................17
Factibilidad operativa ............................................................................................................17
Factibilidad económica .........................................................................................................18
Factibilidad Legal ...................................................................................................................21
1.11 MARCOS DE REFERENCIA .......................................................................................21
Marco Histórico ......................................................................................................................21
MARCO TEÓRICO ................................................................................................................22
Marco Conceptual. ................................................................................................................24
MARCO METODOLÓGICO ........................................................................................................36
1.12 CRONOGRAMA DE ACTIVIDADES ....................................................................................41
2. FASE DE ELABORACIÓN ..................................................................................................42
2.1 IDENTIFICACIÓN DE LA INFORMACIÓN ...............................................................42
4
2.2 REQUERIMIENTOS ......................................................................................................43
2.2.1 Requerimientos Funcionales ......................................................................................43
2.2.2 Requerimientos No Funcionales ................................................................................45
2.3 Definición de actores ..................................................................................................47
2.4 LISTA PRELIMINAR DE CASOS DE USO POR ACTOR ......................................48
2.5 Depuración de casos de uso por actor ..................................................................48
2.5.1 Descripción y Codificación de los casos de uso ..............................................................48
2.5.2 Documentación casos de uso ........................................................................................49
2.6 MODELO DE PROCESOS ..........................................................................................51
Reporte incidente ............................................................................................................51
3. FASE DE CONSTRUCCIÓN ...............................................................................................52
3.1 DIAGRAMAS DE SECUENCIA ..................................................................................................52
Diagrama de secuencia reporte evento ..........................................................................52
3.2 DIAGRAMAS DE ACTIVIDAD ..................................................................................................53
Diagrama de actividad de reporte de evento..................................................................53
3.3 DIAGRAMAS DE ESTADO .......................................................................................................54
Diagrama de estado reporte Incidente ...........................................................................54
3.4 Diagrama de análisis ..........................................................................................................55
3.5 Modelo Relacional ..............................................................................................................56
3.6 Arquitectura .......................................................................................................................58
4. FASE DE TRANSICIÓN .......................................................................................................59
4.1 Diagrama de componentes .......................................................................................59
4.2 Diagramas de paquetes .............................................................................................60
4.3 Diagrama de despliegue ............................................................................................61
4.4 Pruebas ..........................................................................................................................62
4.4.1 Prueba unitaria Reporte de evento ...........................................................................62
4.4.2 Prueba unitaria Clasificación Incidente .........................................................63
4.4.3 Prueba unitaria Reporte Vulnerabilidades.....................................................64
4.4.4 Prueba unitaria consulta eventos-incidentes ...............................................65
4.4.5 Prueba unitaria generación de informe ..........................................................66
CONCLUSIONES ..........................................................................................................................67
5
LISTA DE TABLAS
Tabla 1 Recursos Humanos……………………………………….……….….12
Tabla 2 Recursos Técnicos…………………………………………….….…..13
Tabla 3 Recursos de Software……………………………………….…….…14
Tabla 4 Presupuesto…………………………………………………..……….15
Tabla 5 Requerimientos funcionales……………………………….……......40
Tabla 6 Requerimientos no funcionales conexión a internet………….…..41
Tabla 7 Requerimientos no funcionales uso de navegadores..……….…..41
Tabla 8 Requerimientos no funcionales usuario y contraseña………........42
Tabla 9 Requerimientos no funcionales error en tiempo de ejecución......42
Tabla 10 Definición de actores….…………………………...………………..43
Tabla 11 Lista preliminar de casos de uso por actor……..…….………..…44
Tabla 12 Caso de uso ……………….…………………………………….….46
Tabla 13 pruebas unitarias reporte de evento………………………………58
Tabla 14 Pruebas unitarias clasificación de incidente………………..……59
Tabla 15 Pruebas unitarias consulta evento incidente…………………….60
Tabla 16 Pruebas unitarias reporte vulnerabilidad………… …………...61
Tabla 17 Pruebas unitarias Informes………………………………………...61
6
LISTA DE FIGURAS
Figura 1 Cronograma de actividades 1……………….……………………….37
Figura 2. Caso de uso reporte de evento…………….…………….…………45
Figura 3 modelo de procesos reporte incidente….……………………..…...47
Figura 4 Diagrama de secuencia reporte evento……..……….…….…..…..48
Figura 5 Diagrama de actividad reporte de evento…………………….…....49
Figura 6 Diagrama de estado reporte incidente…………………………......49
Figura 7 Diagrama de análisis…………………. …………...………...……...50
Figura 8 Modelo relacional………………………….………. ……..………....51
Figura 9 Modelo relacional.………………...…….........................................52
Figura 10 diagrama esquemático del sistema………….……………...……54
Figura 11 diagrama de componentes ………………..……..……………….55
Figura 12 diagrama de paquetes…………………..…………………………56
Figura 13 diagrama de despliegue………………..…………………………57
7
RESUMEN
El aplicativo IXION-UD encargado de la gestión de incidentes de seguridad de la
información según norma ISO 27035 para las aplicaciones web de la universidad
Distrital Francisco José de Caldas, permitirá a la oficina asesora de sistemas de la
Universidad (OAS) llevar un proceso de atención, seguimiento y solución a los
incidentes reportados que develan vulnerabilidades en el sistema que implica un
riesgo para el activo de información que maneja la universidad.
Para el diseño del aplicativo se siguieron las indicaciones normativas que indica la
familia de normas de la ISO 27000 para la seguridad de la información, haciendo
especial énfasis en la ISO 27035 y 27002 como el tratamiento para la gestión de
incidentes y la evaluación de controles de seguridad, respectivamente.
En el desarrollo de este aplicativo se implementó el paradigma de programación:
MVC (modelo, vista, controlador), que garantiza la calidad en el desarrollo,
haciendo que el sistema sea robusto, flexible y amigable para el usuario final. Para
la implementación de este paradigma se hizo la inclusión del framework Zend que
nos ofrecía una facilidad al momento del desarrollo.
El lenguaje de programación utilizado es PHP 5.2 con integración a motor de
base de datos Postgres 9.3 según indicación de (OAS), de igual manera que se
hace uso de metodología de desarrollo OPENUP/OAS ya que es una metodología
que de acuerdo a su propuesta de trabajo suple las necesidades de desarrollo,
diseño y despliegue, permitiendo alcanzar los objetivos propuestos.
8
ABSTRACT
The IXION-UD Manager application management Incident Information Security according to ISO 27035 for Web Applications of the University Francisco José de Caldas, allow the advisory office of the University System (OAS) Maintain UN Process Attention, tracking and resolution of reported incidents that reveal vulnerabilities in which UN System Risk implications for active information handled by the university. To design the application Indications regulations that indicates the family of standards ISO 27000 for Information Security, with special emphasis on the ISO 27035 and 27002 as standard treatment for Incident Management and evaluation of controls were followed Security respectively. In the development of this application programming paradigm implemented: MVC (Model View Controller), which guarantees the quality in development, making the system robust sea, for friendly flexibility and end user. For the implementation of paradigm inclusion of Zend Framework that offered us a facility at the time of development it was done. The programming language used is PHP 5.2 with integration of the motor base 9.3 Data Postgres as indicated by (OAS), just as USE Open UP Development Methodology / Becomes OAS since it is a methodology of Agreement, a Do Working proposal meets the needs of development, design and deployment, allowing achieve the objectives.
9
INTRODUCCIÓN
La oficina asesora de sistemas de la universidad distrital francisco José de caldas
actualmente está gestionando un proyecto en el que se sistematizara la gestión
de incidentes de seguridad de la información, como requisito que se exige para la
implementación de normas internacionales como la NTC-ISO/IEC 27002-27035,
por lo tanto se hace necesario llevar a cabo la sistematización de los procesos y
técnicas de seguridad que se desarrollan en la OAS.
Además de evidenciar una problemática en esta área, que es la manera en que se
hace el control y seguimiento de los diferentes eventos de seguridad llevados a
cabo por los integrantes de la mesa de ayuda, como lo son el manejo,
diligenciamiento y privacidad que se le da a los documentos.
Para poder encontrar las necesidades que se tienen en esta área, fue de vital
importancia la realización de la entrevista al ingeniero que lidera el proyecto este
dependencia, dejando como resultado un listado de requerimientos, que
permitieron encaminar el desarrollo a los intereses del usuario, la mesa de ayuda
de oas en la universidad.
De esta manera se propone una posible solución para suplir necesidades en este
departamento, como lo son la gestión de incidentes de seguridad de la información
en aplicaciones, consulta on-line, gestión de incidentes y eventos.
10
1. FASE DE INICIO, PLANEACIÓN, DEFINICIÓN Y ORGANIZACIÓN
1.1 TÍTULO DEL PROYECTO
APLICATIVO PARA LA GESTIÓN DE INCIDENTES DE SEGURIDAD DE LA
INFORMACIÓN EN APLICACIONES, BASADO EN LA NTC-ISO/IEC 27002-
27035. PARA EL CASO DE USO DE LA UNIVERSIDAD DISTRITAL.
1.2 TEMA
Para el desarrollo del proyecto se debe tener en cuenta el tema de aplicaciones
web, para mejorar los procesos de gestión de la información en oficina asesora de
sistemas de la Universidad Distrital Francisco José de Caldas, implementando
herramientas de programación como PHP, HTML, JavaScript, CSS y como gestor
de bases de datos Postgresql, además de la implementación del framework Zend
que permite el manejo de la arquitectura MVC (Modelo Vista Controlador).
1.3 PLANTEAMIENTO DEL PROBLEMA
Las posibilidades de daño y pérdida de información por causa de inseguridad
informática, se hacen cada vez más comunes, debido a que el explotar
vulnerabilidades que se pueda tener en el manejo de información sensible, es una
práctica que ha venido tomando cada vez más fuerza y contundencia en el terreno
informático, por lo que preocuparse por este tema toma gran relevancia hoy en día
y hace parte del mismo control que se debe hacer al desarrollo de la tecnología y
el uso que se le da.1
En la actualidad la información de la institución se ha reconocido como un activo
valioso y a medida que los sistemas de información apoyan cada vez más los
procesos de misión crítica se requiere contar con estrategias de alto nivel que
permitan el control y administración efectiva de los datos, los servicios web y red
de información enfrentan amenazas de seguridad que incluye entre muchas cosas
el fraude por computadora, espionaje, sabotaje, vandalismo y desastres naturales,
1 Mifsud, E. (2012, 26 de marzo). Introducción a la seguridad informática. . consultado el 20 de
febrero 2014, a partir de [http://recursostic.educacion.es/observatorio/web/es/software/software-
general/1040-introduccion-a-la-seguridad-informatica?showall=1]
11
la posibilidad de daño y perdida de información por causa de códigos maliciosos,
mal uso o ataques de denegación de servicio se hacen cada vez más comunes. 2
Dentro del sistema actual de la universidad distrital esta como propósito y
compromiso del plan maestro de telecomunicaciones diseñar, implementar,
mantener y mejorar un Sistema de Gestión de la Seguridad de la Información que
permita garantizar la confidencialidad, disponibilidad e integridad de la
información, y aumente su potencial aprovechamiento en la consecución de los
objetivos institucionales3, es así que la oficina asesora de sistemas en conjunto
con los integrantes de este proyecto se encuentran con la necesidad de realizar un
estudio y análisis de los diferentes servicios web que se encuentran dentro de la
universidad para identificar, documentar amenazas y riesgos potenciales que no
garanticen la confidencialidad, disponibilidad e integridad de la información y así
poder mitigar o dar solución posibles riesgos o amenazas .
1.4 DESCRIPCIÓN DEL PROBLEMA
Al igual que otras organizaciones de cualquier tipo es necesario que se piense en
la manera de documentar los posibles eventos que se pueden generar en la
seguridad de todas las áreas de trabajo y en el manejo de su activo de información
disminuyendo al mínimo su riesgo potencial de pérdida o robo de información. La
Universidad Distrital no cuenta con un proceso institucional y sistemático que le
permita gestionar de manera efectiva la documentación de los diferentes eventos
de seguridad de la información y esto ser inmensamente vulnerable a la pérdida o
robo de este activo.
La Institución hoy en día se plantea como hacer frente a este problema de la mejor
manera, cumpliendo con los requisitos internacionales sobre cómo hacerlo. De
esta forma se traza como objetivo del Sistema de Gestión de la Seguridad de la
Información (SGSI) cumpliendo con la norma ISO 27001, de crear en la
2 Política de seguridad universidad distrital OAS. (2012, 15de marzo). Consultado el 03 de abril de
2014, a partir de
[https://oasdes.udistrital.edu.co/CIT/documentos/NORMATIVIDAD/politica_seguridad/archivos/Politica_par
a_Seguridad_Informacion_Version_0.0.1.0.pdf]
3 COMITÉ DE INFORMÁTICA. (2012, 29 de octubre). Plan Maestro de Informática y
Telecomunicaciones 2012 – 2018-UD. Consultado el 10 de abril de 2014, a partir de [https://portalws.udistrital.edu.co/CIT/documentos/DOCUMENTOS_TRABAJO/PMIT-UD/archivos/PMITUD_2012-2018_Aprobado.pdf. 30-72p]
12
Universidad un aplicativo para la gestión de incidentes de seguridad de la
información en aplicaciones, tomando como referencia la NTC-ISO/IEC 27002-
27035. Siendo este el estándar internacional más reconocido y certificable a nivel
mundial.
La universidad hoy en día cuenta con un sistema de información dotado de
diferentes aplicativos institucionales que le brindan la capacidad de cubrir áreas
administrativas y académicas, manejando un gran volumen de información de vital
importancia para el funcionamiento de la misma. Teniendo en cuenta esto, en la
institución no existe una estructura para la gestión de la seguridad de la
información que garantice los principios básicos de integridad, confidencialidad y
disponibilidad, lo que imposibilita tener control y seguimiento de los eventos e
incidentes informáticos ocurridos en su sistema de información, haciéndola
vulnerable a posibles ataques de los cuales pueda ser objeto; y más, aun cuando
no tiene cómo hacer reporte de estos incidentes para mitigarlos y hacer los
ajustes pertinentes.
Teniendo en cuenta la vulnerabilidad del activo de información que se maneja y
que compromete el funcionamiento administrativo como académico de la
universidad, se concluye que el problema además de los ataques informáticos al
sistema de información, también corresponde a la capacidad de la universidad de
poder identificar, controlar y eliminar las fallas que se presenten y den pasó a un
incidente. Sin solucionar esto el sistema seguirá expuesto y sin poder minimizar su
riesgo potencial a ser víctima de un ataque informático.
Por tanto y de acuerdo al riesgo que representan no tener reportadas y
clasificadas los distintos tipos de amenazas e incidentes ocurridos, se hace
necesaria la creación de un aplicativo para la gestión de incidentes de seguridad
de la información en aplicaciones para reportar y clasificar los diferentes ataques
en incidentes ocurridos.
1.5 FORMULACIÓN DEL PROBLEMA
¿Cómo impacta un aplicativo web que permite reportar y evaluar la gestión de
incidentes de seguridad de la información basados en la NTC-ISO/IEC 27002-
27035 en un SGSI, Para el caso concreto de la Universidad Distrital?
13
1.6 JUSTIFICACIÓN
Teniendo en cuenta que la Universidad Distrital está expuesta a diferentes
amenazas que ponen en riesgo sus activos de información, se manifiesta la
preocupación por proteger sus activos de información, además de preservar la
integridad, confidencialidad y disponibilidad de los mismos. Dichos deseos y
preocupaciones se enmarcan en los retos que demanda la garantía de los
principios establecidos en la seguridad informática, a través de estándares
internacionales como la norma ISO 27002 e ISO 27035, la cual establece los
procesos a seguir para la implementación y documentación de los posibles
eventos en un sistema de gestión de seguridad de la información.
El que la Institución se trace como objetivo planear, diseñar, desarrollar, probar y
ejecutar dentro del SGSI un aplicativo que permita la documentación y gestión de
eventos de seguridad es un gran avance en el terreno informático y en el
desarrollo de su fin mismo, surge como una herramienta organizacional para
concienciar a cada uno de los miembros de una organización sobre la importancia
y la sensibilidad de la información que favorecen el desarrollo y el buen
funcionamiento de la organización4. Dado que la preservación de un activo como
la información siempre será de gran importancia en la actividad principal de la
organización.
Cumplir con lo propuesto en la norma ISO 27035 para la documentación y gestión
de eventos de seguridad de un SGSI, es cumplir con una serie de requisitos y
recomendaciones para garantizar la seguridad informática, recomendaciones que
van desde la simple actitud y manejo que se da por parte de los empleados hasta
los grandes procesos de auditorías, desarrollo de sistemas que mitiguen riesgos y
procesos que manejen información sensible para la organización, responde a
puntos específicos de la norma y es coherente con lo planteado en la política de
seguridad de la información de la institución.
4 Tecnología, seguridad y empresa Consulta: Viernes, 28 de febrero de 2014
[http://www.madrid.org/cs/Satellite?blobcol=urldata&blobheader=application%2Fpdf&blobkey=id&blobtable=MungoBlobs&blobwhere=1119155403921&ssbinary=true]
14
1.7 OBJETIVOS
Objetivo General
Desarrollar, implementar y validar un aplicativo web basado en el software libre,
que permita la gestión de incidentes de seguridad de la información en las
aplicaciones, basado en la norma NTC-ISO/IEC 27002-27035. Para el caso de uso
de la Universidad Distrital.
Objetivos específicos
● Definir los controles de las normas NTC-ISO/IEC 27002-27035, que respondan a
las necesidades actuales en cuanto a la gestión de incidentes de seguridad de la
información.
● Elaborar una estructura de gestión de incidentes, que permita reportar, evaluar y
gestionar los incidentes de seguridad de la información.
● Diseñar una base de datos de los controles de la norma ISO 27002-27035,
catalogados según la necesidad de la oficina asesora de sistemas.
● Generar informes de la gestión de incidentes de la seguridad de la información
encontrados en las aplicaciones.
15
1.8 ALCANCE
El proyecto será implementado para la gestión de incidentes de seguridad de la
información en aplicaciones para el caso de uso de la universidad distrital, contará
con la validación de un ingeniero de la oficina asesora de sistemas. Esto quiere
decir que no se entregan resultados de usos y en ningún caso se entrega el
aplicativo con informes de datos de la gestión de incidentes hechas en ambientes
reales de aplicaciones funcionales de la universidad, debido a las limitaciones de
propiedad legal que este tipo de actuaciones acarrearía.
1.8.1 A nivel funcional
1.8.1.1 Modulo de Reportes
Este módulo se basa en la necesidad misma por la que surge el aplicativo,
y es la de poder reportar los eventos, los eventos que se convierten en un
incidente con cierta prioridad y las posibles vulnerabilidades existentes en el
área informática. Es fundamental porque a partir de esto se puede hacer
una correcta gestión de seguridad y minimizar el riesgo que pueda existir.
1.8.1.2 Modulo de Consulta
La consulta de todo lo que se reporte a través del aplicativo es un módulo
porque permite tener a disposición de los usuarios encargados de hacer la
gestión de los eventos reportados para que según su rol este se encargue
de hacer la correspondiente revisión y acciones pertinentes.
1.8.1.3 Modulo de informes
El módulo de informes hace referencia al resultado de la gestión realizada
por las personas encargadas de la seguridad en la Universidad, a través del
16
aplicativo y de este último en general. Lo que ayuda a tener un indicativo
sobre la forma en que se aborda estos incidentes y la trazabilidad que
tienes por el área de sistemas de la Universidad.
1.9 DELIMITACIONES
Delimitación Temporal
El proyecto está destinado a desarrollarse en un lapso de 6 meses comprendidos
desde el 04 de agosto de 2014 al 31 de enero de 2015.
Delimitación Geográfica
Este proyecto será desarrollado en las instalaciones de la oficina asesora de
sistemas de la Universidad Distrital.
Adicionalmente se delimitará la implementación del aplicativo propuesto
únicamente a un escenario de prueba con expertos en seguridad informática.
Delimitación Técnica
Las tecnologías sobre las que se desarrollará este proyecto son:
Sistema operativo: Linux
Motor de Base de datos: Postgresql
Servidor de aplicaciones: Lamp
Servidor Web: Lamp
La solución propuesta se basa en reportar y evaluar la gestión de incidentes de
seguridad de las aplicaciones de la universidad distrital por parte de los
profesionales de sistemas. En este sentido la solución tiene en cuenta las
particularidades de este tipo de auditorías y los controles específicos que dicta las
normas ISO/IEC 27001-27002-27035, que las hacen distintas de cualquier otro
tipo de gestión de incidentes en el campo de la seguridad informática.
Para lograr el establecimiento de la funcionalidad del aplicativo se contará con la
técnica de validación basada en un experto. La cual implica que éste experto
expide una carta en la que expone su beneplácito por el desarrollo del software.
17
No necesariamente se deben desarrollar todas las funcionalidades que un experto
requiera, ya que la validación es a nivel prototipo, esto implica que el experto ve
en el aplicativo un potencial de uso si se perfeccionan dichas funcionalidades.
1.10 FACTIBILIDAD
Factibilidad Técnica
Las características esenciales de los dispositivos con los cuales se debe hacer uso de nuestro sistema de información, deberán poseer la mayoría de las tecnologías utilizadas dentro del desarrollo del sistema. El proyecto es factible porque cuenta con las siguientes herramientas: Características mínimas del computador, para que se pueda dar uso al sistema de información:
Procesador de 3.0 GHz de velocidad.
Memoria RAM de 2.00 GB
Espacio en disco de 512 Mb
Sistema Operativo Linux Ubuntu 14.04 LTS Recursos Adicionales:
Acceso a internet
Servidor web externo LAMP
Sistema de gestor de Bases de Datos PstgreSql.
Impresora
Factibilidad operativa
En el proyecto Sistema Web Para gestión de incidentes de seguridad de la
información en aplicaciones, basado en la NTC-ISO/IEC 27002-27035. Para el
caso de uso de la Universidad Distrital, se muestra a continuación el personal
requerido para la elaboración de este mismo. El sistema será manejado por los
funcionarios de la oficina asesora de sistemas encargados de cada facultad de la
Universidad Distrital.
18
Tutor de tesis: Responsable de supervisar y asesorar la elaboración de proyecto. Tutor de tesis OAS: Responsable de supervisar y asesorar la elaboración de proyecto. Funcionarios Oficina asesora de sistemas: Son los usuarios que tendrán las diversas necesidades que se deben tratar para hallar una solución. Analistas y desarrolladores: Captura, especificación y validación de requisitos, interactuando con el equipo de trabajo de la oficina asesora de sistemas mediante entrevistas y documentación que ellos suministren. Elaboración del modelo de análisis y diseño. Desarrollo del software basados en la
arquitectura base. Planear diseñar y evaluar las pruebas.
Factibilidad económica
Recurso Humano
Tipo Descripción Valor-Hora Cantidad Total
Tutor 1
Sonia
Alexandra
pinzón
Asesorías del tutor
para la realización
del proyecto,
referente a la
metodología a seguir
y las herramientas
con las que se
trabajará en la
realización del
proyecto.
$ 26.000 200
$ 5.200.000
Tutor 2
Jaider
Ospina
Asesorías del tutor
que nos guiara en el
trabajo con los
repositorios
distribuidos y la
adaptabilidad de los
ítems del proyecto.
$ 26.000 200 $ 5.200.000
19
Además, de la
metodología a seguir
y las herramientas
con las que
trabajaremos.
Fabián
Bocanegra
Analista y
desarrollador.
$ 9.000 850 $ 7.650.000
Jefferson
Ordoñez
Tovar
Analista y
desarrollador.
$ 9.000 850 $ 7.650.000
Total
Recursos
Humanos
$
25.700.000
Tabla 1 Recursos Humanos
Recursos Técnicos
Recurso Valor
Unitario
Cantidad Total
Servicios de
Electricidad
$ 5.000 2 $ 120.000
Computadores $ 1.100.000 2 $ 2.200.000
Impresiones y
papelería
$ 10.000 1 $ 600.000
Encuadernación
de Tesis
$ 65.000 2 $130.000
Transportes
para reunión con
grupo de trabajo
$10.000 2 $250.000
Otros $50.000 2 $1.000.000
Total Recursos
Técnicos
$4.300.000
Tabla 2 Recursos Técnicos
20
Recursos De Software
RECURSO CANTIDAD VALOR
UNITARIO
VALOR
Licencia
Windows
2 $ 450.000 $ 900.000
Licencia
PostgreSQL
2 0 0
2 0 0
Licencia PHP 5 2 0 0
Licencia HTML5 2 0 0
Licencia JQuery 2 0 0
Licencia
Netbeans 8.0.2
2 0 0
Licencia
ZendFramework2
2 0 0
Licencia SDK 2 0 0
Licencia Lamp 2 0 0
Total Recursos
Software
$900.000
Tabla 3 Recursos de Software
Presupuesto
A continuación se muestra el presupuesto total, requerido para nuestro sistema
web:
Recurso Valor
Recurso Humano $ 25’700.000
Recurso Técnico $ 4.300.000
Recurso de Software $ 900.000
TOTAL $ 30´900.000
Tabla 4 Presupuesto
21
Factibilidad Legal
Desde el punto de vista metodológico, el proyecto se ampara en metodologías
libres que no requieren de pagos a empresas por su implementación. Esto
garantiza de facto que la organización sistémica del proyecto cuente con
factibilidad legal desde el inicio.
De otra parte las herramientas usadas en el proyecto por estar amparadas con las
licencias GNU permiten el desarrollo de proyectos de alto, mediano y bajo alcance
sin la incursión de problemas jurídicos asociados a mal uso de estas herramientas
1.11 MARCOS DE REFERENCIA
Marco Histórico
Cada vez son más frecuentes los casos en los cuales tanto personas como
entidades son víctimas de delitos informáticos, constituyéndose éstos a través de
operaciones ilícitas realizadas por medio de ordenadores y del acceso a la
Internet. Mediante estas prácticas se vienen configurando delitos tradicionales,
tales como suplantaciones, robo, fraude, chantajes, amenazas, ataques a
sistemas, robo de bancos, violación de derechos de autor, pedofilia en internet,
destrucción de información, violación de información confidencial, entre otros.
La oficina asesora de sistemas de la universidad distrital se ha preocupado
siempre por aplicar tecnologías innovadoras en la solución por proteger sus
activos de información, además de preservar la integridad, confidencialidad y
disponibilidad de los mismos. Tanto así que dichos deseos y preocupaciones se
enmarcan en los retos que tienen como propósito y compromiso del plan maestro
de telecomunicaciones diseñar, implementar, mantener y mejorar un Sistema de
Gestión de la Seguridad de la Información que permita garantizar la
confidencialidad, disponibilidad e integridad de la información, y aumente su
potencial aprovechamiento en la consecución de los objetivos institucionales que
demanda la garantía de los principios establecidos en la seguridad informática, a
través de estándares internacionales los cuales establece los procesos a seguir
para la implementación.
Actualmente en Colombia pocas empresas han adoptado y certificado en la norma
ISO/IEC 27001 estableciendo Sistemas de Gestión de la Seguridad de la
22
Información y ninguna institución de educación superior se ha certificado5 , dentro
del proceso de establecer un SGSI se encuentran unos requisitos generales
establecidos por la norma en los cuales se define alcances y limites, políticas de
SGSI, valoración de riesgos, identificación de riesgos, seleccionar objetos de
control y controles para el tratamiento de los riesgos entre otros.
La norma específica que se debe planificar un programa de gestión de incidentes
de seguridad como también se debe definir un procedimiento documentado para
informar los resultados y mantener un registro de incidentes anteriores, en la
actualidad existen aplicaciones que adjuntan distintas herramientas para la
identificación de riesgos y vulnerabilidades en servicios WEB
MARCO TEÓRICO
Actualmente en Colombia pocas empresas han adoptado y certificado en la norma
ISO/IEC 27001 estableciendo Sistemas de Gestión de la Seguridad de la
Información y ninguna institución de educación superior se ha certificado6 , dentro
del proceso de establecer un SGSI se encuentran unos requisitos generales
establecidos por la norma en los cuales se define alcances y limites, políticas de
SGSI, valoración de riesgos, identificación de riesgos, seleccionar objetos de
control y controles para el tratamiento de los riesgos entre otros.
La norma específica que se debe planificar un programa de gestión de incidentes
de seguridad como también se debe definir un procedimiento documentado para
informar los resultados y mantener un registro de incidentes anteriores, en la
actualidad existen aplicaciones que adjuntan distintas herramientas para la
identificación de riesgos y vulnerabilidades en servicios WEB, esto se puede
evidenciar en una suite de herramientas para seguridad informática como las
siguientes:
BackTrack5: es una distribución GNU/Linux en formato LiveCD pensada y
diseñada para la auditoría de seguridad y relacionada con la seguridad informática
5 Empresas que han adquirido las certificaciones ISO/IEC 27001 Consulta: Miércoles, 12 de marzo de
2014[http://certificacion27001.blogspot.com/2010/09/empresas-certificadas-de-colombia.html]
6 Empresas que han adquirido las certificaciones ISO/IEC 27001 Consulta: Miércoles, 12 de marzo de
2014[http://certificacion27001.blogspot.com/2010/09/empresas-certificadas-de-colombia.html]
23
en general. Actualmente tiene una gran popularidad y aceptación en la comunidad
que se mueve en torno a la seguridad informática.7
Kali Linux: es una distribución basada en Debian GNU/Linux diseñada
principalmente para la auditoría y seguridad informática en general. Fue fundada y
es mantenida por Offensive Security Ltd. Mati Aharoni and Devon Kearns, ambos
pertenecientes al equipo de Offensive Security, desarrollaron la distribución a
partir de la reescritura de BackTrack, que se podría denominar como la antecesora
de Kali Linux.8
O-Saft (OWASP SSL Advanced Forensic Tool): es una herramienta fácil de usar
para analizar información sobre las conexiones SSL y los certificados SSL
proporcionados. Está diseñado para ser utilizado por pentesters, auditores de
seguridad o administradores de servidores.9
OWASP Zed Attack Proxy (ZAP): herramienta de fácil uso para encontrar
vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada tanto por
desarrolladores y probadores funcionales (que son nuevos en test de intrusión)
como por personas con una amplia gama de experiencia en seguridad. Permite
automatizar las pruebas y también facilita un número de herramientas para
hacerlas manualmente.
Estas son tan solo algunas de las herramientas más destacadas utilizadas en la
auditoria de servicios web, cada herramienta se encarga de un grupo de
vulnerabilidades específicas ya sea inyección de código a bases de datos,
explotación y detección de vulnerabilidades de tipo Cross Site Scripting (XSS) en
fin, una gran cantidad de vulnerabilidades conocidas.
7 BackTrack. (2014, 23 de enero). - Wikipedia, la enciclopedia libre. Consultado el 12 de
marzo de 2014, a partir de[http://es.wikipedia.org/wiki/BackTrack]
8 Kali Linux. (2013, 6 de septiembre). - Wikipedia, la enciclopedia libre. Consultado el 12 de marzo de 2014, a partir de [http://es.wikipedia.org/wiki/ Kali_linux]
9 Top 10 de las mejores herramientas de seguridad del 2013 de ToolsWatch : hackplayers.
(2013, 20 de diciembre). Top 10 de las mejores herramientas de seguridad del 2013 de ToolsWatch
: hackplayers. Consultado el 12 de marzo de 2014, a partir de
[http://www.hackplayers.com/2013/12/top10-mejores-herramientas-2013-toolwatch.html
24
Los sistemas desarrollados en plataformas Web o también conocido como "aplicaciones Web" son aquellos que están creados e instalados no sobre una plataforma o sistemas operativos (Windows, Linux). Sino que se alojan en un servidor en Internet o sobre una intranet (red local). Su aspecto es muy similar a páginas Web que vemos normalmente, pero en realidad los 'sistemas Web' tienen funcionalidades muy potentes que brindan respuestas a casos particulares. Los sistemas Web se pueden utilizar en cualquier navegador Web (chrome, Firefox, Internet Explorer, etc.) sin importar el sistema operativo. Para utilizar las aplicaciones Web no es necesario instalarlas en cada computadora ya que los usuarios se conectan a un servidor donde se aloja el sistema. Las aplicaciones Web trabajan con bases de datos que permiten procesar y mostrar información de forma dinámica para el usuario, esto nos brinda una gran ventaja al momento de la documentación y gestión de los diferentes eventos de seguridad ya que a diferencia de los formatos manuales se puede tener acceso a la información de manera virtual y no solamente física lo cual permite una gestión más rápida para los eventos que así lo requieran además de contribuir con el medio ambiente y el fácil acceso a la información.
Marco Conceptual.
Para el desarrollo del proyecto fue necesario tener en cuenta los conceptos de los
siguientes términos básicos que se utilizan a lo largo de este proyecto, con el fin
de comprender correctamente la explicación y desarrollo del mismo.
Normas ISO
La ISO (International Standarization Organization) es la entidad internacional
encargada de favorecer normas de fabricación, comercio y comunicación en todo
el mundo.
ISO/IEC 27001
es un estándar para la seguridad de la información (Information technology - Security techniques - Information security management systems - Requirements) aprobado y publicado como estándar internacional en octubre de 2005 por International Organization for Standardization y por la comisión International Electrotechnical Commission.
Especifica los requisitos necesarios para establecer, implantar, mantener y mejorar un sistema de gestión de la seguridad de la información (SGSI) según el conocido como “Ciclo de Deming”: PDCA - acrónimo de Plan, Do, Check, Act (Planificar, Hacer, Verificar, Actuar).
25
ISO/IEC 27002
anteriormente denominada ISO 17799 es un estándar para la seguridad de la información publicado por primera vez como ISO/IEC 17799:2000 por la International Organization for Standardization y por la Comisión Electrotécnica Internacional en el año 2000, con el título de Information technology - Security techniques - Code of practice for information security management. Tras un periodo de revisión y actualización de los contenidos del estándar, se publicó en el año 2005 el documento actualizado denominado ISO/IEC 17799:2005. El estándar ISO/IEC 17799 tiene su origen en el British Standard BS 7799-1 que fue publicado por primera vez en 1995.
GTC ISO/IEC 27035
La guía brinda orientación sobre la gestión de incidentes de seguridad de la
información para empresas grandes y medianas. Las organizaciones más
pequeñas pueden usar un conjunto básico de documentos, procesos y rutinas
descritos en la presente guía, de acuerdo con su tamaño y tipo de negocio, en
relación con la situación de riesgo de seguridad de la información. También brinda
orientación para organizaciones externas que prestan servicios de gestión de
incidentes de seguridad de la información.
La presente guía brinda un enfoque estructurado y planificado para:
detectar, reportar y evaluar incidentes de seguridad de la información.
responder a incidentes de seguridad de la información y hacer su gestión.
detectar, evaluar y gestionar las vulnerabilidades de seguridad de la
información.
mejorar continuamente la seguridad de la información y la gestión de
incidentes como resultado de la gestión de los incidentes y vulnerabilidades
de seguridad de la información.
Sistema de cómputo
Conjunto de elementos electrónicos que interactúan entre sí, (Hardware) para
procesar y almacenar información de acuerdo a una serie de instrucciones
(Software).
26
Sistema de información
Es un conjunto de elementos orientados al tratamiento y administración
de datos e información, organizados y listos para su uso posterior, generados para
cubrir una necesidad u objetivo.
El estudio de los sistemas de información surgió como una sub-disciplina de
las ciencias de la computación, con el objetivo de racionalizar la administración de
la tecnología dentro de las organizaciones. El campo de estudio fue avanzando
hasta pasar a ser parte de los estudios superiores dentro de la administración.10
Seguridad informática
Es el área de la informática que se enfoca en la protección de la infraestructura
computacional y todo lo relacionado con esta y, especialmente, la información
contenida o circulante. Para ello existen una serie de estándares, protocolos,
métodos, reglas, herramientas y leyes concebidas para minimizar los posibles
riesgos a la infraestructura o a la información. La seguridad informática comprende
software (bases de datos, metadatos, archivos), hardware y todo lo que la
organización valore (activo) y signifique un riesgo si esta información confidencial
llega a manos de otras personas, convirtiéndose, por ejemplo, en información
privilegiada.
Seguridad de la información
es el conjunto de medidas preventivas y reactivas de las organizaciones y de los
sistemas tecnológicos que permiten resguardar y proteger la información
buscando mantener la confidencialidad, la disponibilidad e integridad de la misma.
Integridad
La integridad es la propiedad que busca mantener los datos libres de
modificaciones no autorizadas. La violación de integridad se presenta cuando un
empleado, programa o proceso (por accidente o con mala intención) modifica o
borra los datos importantes que son parte de la información, así mismo hace que
su contenido permanezca inalterado a menos que sea modificado por personal
autorizado, y esta modificación sea registrada, asegurando su precisión y
confiabilidad.11
10 Sistema de información 27001 Consulta: Miércoles, 12 de marzo de 2014 [
http://definicion.de/sistema-de-informacion/]
11 La seguridad de la información 27001 Consulta: Jueves, 13 de marzo de 2014
[http://es.wikipedia.org/wiki/Seguridad_de_la_informaci%C3%B3n]
27
Confidencialidad.
Es la propiedad de la información, por la que se garantiza que está accesible
únicamente a personal autorizado a acceder a dicha información. La
confidencialidad ha sido definida por la Organización Internacional de
Estandarización (ISO) en la norma ISO/IEC 27002 como "garantizar que la
información es accesible sólo para aquellos autorizados a tener acceso" y es una
de las piedras angulares de la seguridad de la información
Disponibilidad.
La disponibilidad es la característica, cualidad o condición de la información de
encontrarse a disposición de quienes deben acceder a ella, ya sean personas,
procesos o aplicaciones. A groso modo, la disponibilidad es el acceso a la
información y a los sistemas por personas autorizadas en el momento que así lo
requieran.
Vulnerabilidad
Consistirá en cualquier debilidad que pueda explotarse para causar pérdida o
daño al sistema. De esta manera, el punto más débil de seguridad de un sistema
consiste en el punto de mayor vulnerabilidad de ese sistema.
Amenaza
Una Amenaza es la posibilidad de ocurrencia de cualquier tipo de evento o acción
que puede producir un daño (material o inmaterial) sobre los elementos de un
sistema, en el caso de la Seguridad Informática, los Elementos de Información.
Intrusión
Significa que alguna parte no autorizada logre acceso a un activo del sistema.
Esta parte no autorizada puede ser una persona, un proceso u otro sistema de
cómputo. Ejemplos de esto puede ser el copiado ilícito de programas lo archivos
de datos, o la intervención del canal para obtener datos sobre la red.12
Ataque informático
Consiste en aprovechar alguna debilidad o falla (vulnerabilidad) en el software, en
el hardware, e incluso, en las personas que forman parte de un ambiente
informático; a fin de obtener un beneficio, por lo general de índole económico,
12 La seguridad de la información, Problemática de la seguridad y conceptos básicos, capítulo 2, pág. 3
28
causando un efecto negativo en la seguridad del sistema, que luego repercute
directamente en los activos de la organización.13
Evento de seguridad informática
Un evento de seguridad informática es una ocurrencia identificada de un estado de
un sistema, servicio o red que indica una posible violación de la política de
seguridad de la información o la falla de medidas de seguridad (safeguards), o una
situación previamente desconocida que pueda ser relevante para la seguridad.
[ISO 18044] Por ejemplo: un usuario se conecta a un sistema, un intento fallido de
un usuario para ingresar a una aplicación, el firewall que permite o bloquea un
acceso, una notificación de un cambio de contraseña de un usuario privilegiado,
etc. Un Evento de Seguridad Informática no es necesariamente una ocurrencia
maliciosa o adversa.
Incidente de seguridad informática
Un incidente de seguridad informática es la violación o amenaza inminente a la
violación de una política de seguridad de la información implícita o explícita.
También es un incidente de seguridad un evento que compromete la seguridad de
un sistema (confidencialidad, integridad y disponibilidad).Un incidente puede ser
denunciado por los involucrados, o indicado por un único o una serie de eventos
de seguridad informática. [NIST800-61, ISO 18044].
Como ejemplos de incidentes de seguridad podemos enumerar:
Acceso no autorizado
Robo de contraseñas
Robo de información
Denegación de servicio
Impacto
Determina la importancia del incidente dependiendo de cómo éste afecta a los
procesos de negocio y/o del número de usuarios afectados.
13 Ataques informáticos27001 Consulta: Miércoles, 12 de marzo de 2014
[https://www.evilfingers.com/publications/white_AR/01_Ataques_informaticos.pdf]
29
Priorización de incidentes
Dar prioridad a los incidentes por el impacto en el negocio, tomando como base la
criticidad de los recursos afectados y el efecto técnico del incidente.
PHP
PHP es un lenguaje de secuencia de comandos de servidor diseñado específicamente para la web. Dentro de una página web puede incrustar código PHP que se ejecutará cada vez que se visite una página. El código PHP es interpretado en el servidor web y genera código HTML y otro contenido que el visitante verá. PHP fue concebido en 1994 y es fruto del trabajo de un hombre, Rasmus Lerdorf. Ha sido adoptado por otras personas de talento y ha experimentado tres transformaciones importantes hasta convertirse en el producto actual. En octubre de 2002, era utilizado por más de nueve millones de dominios de todo el mundo y su número crece rápidamente. PHP es un producto de código abierto, lo que quiere decir que puede acceder a su código. Puede utilizarlo, modificarlo y redistribuirlo sin coste alguno. Las siglas PHP equivalían inicialmente a Personal Home Page (Página de inicio
personal) pero se modificaron de acuerdo con la convención de designación de GNU
(del inglés, Gnu´s Not Unix, Gnu no es Unix) y ahora equivale a PHP Hipertext
Preprocessor (Procesador de Hipertexto PHP).14
¿Qué ventajas tiene usar un lenguaje de servidor? La principal ventaja es que, al ejecutarse el código en el servidor, todas nuestras
páginas van a poder ser vistas en cualquier ordenador, independientemente del
navegador que tenga. En cambio, el gran problema de que se ejecute el código en el
navegador es que muchos navegadores no son capaces de entender todo el código,
lo que presentaría errores al mostrar el resultado de las páginas.15
Bases de Datos
Las bases de datos, (BBDD) son estructuras en las que se almacena información siguiendo unas pautas de disposición y ordenación para el posterior procesado de los datos. Es una definición tan buena como cualquier otra. Seguramente, si usted lee cincuenta libros al respecto, encuentre otras tantas definiciones distintas, pero todas coincidirán en lo esencial. Como sistema de almacenamiento de datos, las BBDD son por mucho más eficientes que los archivos de texto que conocemos. Y esto por varias razones pero, principalmente, porque nos permiten un acceso
14 Luke Welling, Laura Thompson. Desarrollo web con PHP y MySQL. PHP. (2003):33
15 José López Quijado. Domine PHP y MySQL, programación dinámica en el lado del servidor.
Bases de datos.(2008):337
30
directo a los datos que necesitamos sin que sea preciso recorrer todo un fichero para encontrarlo. Además, los modernos sistemas de gestión de BBDD relacionales admiten el almacenamiento de muchos tipos de datos, no sólo texto plano. Hablamos de BBDD relacionales cuando podemos establecer relaciones entre las distintas informaciones que componen una base de datos. Por ejemplo, suponga que usted quiere guardar la lista de clientes de una empresa de servicios. Por otro lado, tiene una lista de los servicios que ofrece dicha entidad. Además conserva una relación histórica de los servicios empleados por cada cliente. A partir de ahí, mediante el uso de un Sistema De Gestión De Bases De Datos Relacionales (RDBMS, Relation Data Base Management System) puede sacar estadísticas u otro informes que le ayuden en la planificación u organización de su trabajo diario. Los motores de BBDD actuales (la parte que se encarga de gestionar la BBDD
fuera de la vista del usuario) están basados en el lenguaje SQL (Estructured
Query Language, Lenguaje estructurado de consulta).16
SQL
En los albores de la informática de gestión, allá por los tardíos 70 o primeros 80 del pasado siglo, las aplicaciones comerciales que manejaban ficheros de datos tenían sus propios formatos para almacenar y recuperar la información. Cada nuevo programa que se desarrollaba, normalmente bajo demanda y a medida en aquellos tiempos, grababa y recuperaba los datos en un formato específico, nativo de esa aplicación o del lenguaje en el que había sido escrita. Esto presentaba varios problemas. El usuario de un programa de, digamos, contabilidad que quisiera migrar a otro necesitaba reconvertir todos los datos, en ocasiones, volviendo a grabarlos. Además en una empresa mediana o grande (las únicas que, en aquellos días, podían permitirse tener sistemas informáticos), los datos de almacén podían no estar grabados en un formato compatible con los de facturación. Esto obligaba a grabar los pedidos en los dos departamentos. Cuando la información se graba por duplicado o triplicado en diferentes sistemas siempre pueden aparecer diferencias. Además, es posible que unos datos se actualicen en un sistema pero no en otro. Y, en muchas ocasiones, cuando había varias versiones de la misma información circulando por distintos departamentos de una misma empresa, no se sabía cuáles eran los datos más actualizados. Esto es lo que se llama inconsistencia de la información. Surgía la necesidad de tratar los archivos de datos de forma que todos presentarán un formato coherente, y que cualquier aplicación pudiera acceder a las mismas fuentes de información. El lenguaje SQL cubría estas necesidades. Por una parte encapsulaba los datos, interponiéndose entre estos y la aplicación, de modo que esta usaba instrucciones SQL y era él quien manejaba los datos. Así pues, bastaba con que una aplicación implementase SQL para que pudiera
16 José López Quijado. Domine PHP y MySQL, programación dinámica en el lado del servidor.
Lenguaje SQL .(2008):339
31
acceder a los datos de cualquier otra aplicación. Por otra parte, dado que está orientado a la gestión básica de los datos, SQL tiene, relativamente, pocas instrucciones, y es muy fácil de aprender y manejar con soltura. Aprendiendo SQL se integra así con los lenguajes de programación modernos, supeditado a ellos. Las instrucciones de SQL (llamadas genéricamente, consultas) se pueden
considerar divididas en dos grupos principales. Las estructurales, también
llamadas de definición de datos, o DLL y las de datos, también llamadas de
manipulación de datos o DML. Las primeras están destinadas a crear, modificar y
eliminar las BBDD y las estructuras de las tablas que la conforman así como los
índices. Las segundas se ocupan de incorporar nuevos registros a las tablas,
buscar determinados registros según los criterios necesarios, modificar los datos
grabados o eliminarlos, si procede.17
PostgreSQL.
PostgreSQL es un sistema de gestión de bases de datos objeto-relacional,
distribuido bajo licencia BSD y con su código fuente disponible libremente. Es el
sistema de gestión de bases de datos de código abierto más potente del mercado
y en sus últimas versiones no tiene nada que envidiarle a otras bases de datos
comerciales.
PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de multi-
hilos para garantizar la estabilidad del sistema. Un fallo en uno de los procesos no
afectará el resto y el sistema continuará funcionando.18
Modelo Vista-Controlador
El patrón Modelo- Vista- Controlador (MVC) es el patrón de diseño más adecuado y recomendado para aplicaciones interactivas que distribuyen las funcionalidades de dicha aplicación entre los distintos objetos que la componen, de manera que el grado de acoplamiento entre los objetos de la aplicación sea mínimo. MVC divide una aplicación interactiva en tres áreas: procesamiento, salida y entrada. Para esto utiliza las siguientes abstracciones: -Modelo: Encapsula la información que maneja el sistema, incluyendo la
información de negocio y las lógicas de acceso a los mismos. El modelo avisa a la
vista cuando se produce alguna modificación en los datos del modelo y le permite
consultar el estado de los mismos. También permite al controlador acceder a las
funcionalidades de la aplicación encapsuladas por el modelo. El modelo es
17 Jacobo Pavón Puertas. Creación de un portal con PHP y MySQL. MySQL.(2011):15
18 PostgreSQL. Guía PostgreSQL, introducción [En línea]
http://www.postgresql.org.es/sobre_postgresql [Consultado el 14 de enero de 2014]
32
independiente de cualquier representación de salido y/o comportamiento de
entrada.
-Vista: Es la interfaz de usuario, es decir, decide cómo se presenta la información del modelo al usuario, actualizando la interfaz cuando se produce alguna modificación de los mismos. La vista también reenvía la entrada del usuario al controlador. Pueden existir múltiples vistas del modelo. Cada vista tiene asociado un componente controlador. -Controlador: recibe las entradas, usualmente, como eventos que codifican los
movimientos o pulsación de botones del ratón, pulsaciones de teclas, etc.
Responde a dichos eventos modificando el modelo y pudiendo producir, por tanto,
cambios en la vista. Así pues, el controlador interpreta la entrada del usuario y la
correspondencia en acciones que serán llevadas a cabo por el modelo. Un
controlador escoge la siguiente vista a mostrar basándose en las interacciones del
usuario y los resultados de las operaciones de modelo.19
Zend Framework
Zend Framework es un framework open source para PHP desarrollado por Zend, empresa encargada de la mayor parte de las mejoras hechas a PHP, por lo que se podría decir que es el framework “oficial”. ZF implementa el patrón MVC, es 100% orientado a objetos y sus componentes tienen un bajo acoplamiento por lo que los puedes usar en forma independiente. Un punto importante es que nos brinda un estándar de codificación que deberíamos seguir en nuestros proyectos. A su vez, cuenta con soporte para internalización y localización de aplicaciones (construir sitios multi idioma, convertir formatos de fechas, monedas, etc. según la región. Algo importantísimo para crear aplicaciones con un enfoque global y llegar de la mejor manera a la mayor cantidad de gente posible). Facilita el setup de nuestro proyecto brindándonos herramientas para crear la estructura de directorios, clases, etc. por línea de comandos, integración con phpUnit por medio de Zend_Test para facilitar el testing de nuestra aplicación. ¿Todavía quieres más? Posee adapters para gran cantidad de tipos de bases de
datos diferentes; brinda componentes para la autenticación y autorización de
usuarios, envío de mails, cache en varios formatos, creación de web services,
etc.20
19 David Roldán Martínez, Pedro J. Valderas Aranda, Oscar Pastor López. “Aplicaciones web,
un enfoque práctico”. Modelo- Vista- Controlador. (2010): 137-138 p
20 Maestros del web. Guía Zend, introducción [En línea]
http://www.maestrosdelweb.com/editorial/guia-zend/ [Consultado el 14 de enero de 2014]
33
LampServer
LampServer es un entorno de desarrollo web para Linux en el cual se podrán crear
aplicaciones web con Apache, PHP y base de datos en MySQL (motor de base de
datos). LampServer ofrece a los desarrolladores herramientas necesarias para
realizar aplicaciones web de manera local, con un sistema operativo (Linux), un
manejador de base de datos (MySQL), un software de programación script web
PHP. Este software se caracteriza por que puede ser usado de forma libre es decir
no debemos de contar con alguna licencia el cual nos permita el uso de la misma,
ya que pertenece a la corriente de "open source".
UTILIDAD
Su utilidad es importante a la hora de desarrollar aplicaciones web, ya que
funciona al igual como si cuando trabajamos en un servidor web, ya que podemos
ejecutar estas aplicaciones de manera local y ver como sería el funcionamiento
antes de ser subidas a un hosting o servidor web.21
JavaScript
JavaScript es el lenguaje de secuencia de comandos (o scripts) en cliente más
utilizado actualmente en la Web. Su uso está muy extendido en tareas que van
desde la validación de los datos de formularios a las creación de complejas
interfaces de usuario. Sin embargo, el lenguaje tiene capacidades que muchos de
sus usuarios ni han descubierto todavía. Muy pronto, JavaScript se utilizará cada
vez más para manipular los documentos HTL reales e incluso los XML en los que
está contenido. Cuando finalmente logre este papel, se convertirá en una
tecnología Web en cliente de primera clase, de la misma importancia que HTML,
las hojas de estilo CSS y por último el XML. Como tal, será un lenguaje que
cualquier diseñador Web debería dominar.22
Fue originalmente creado por la empresa Netscape para añadir interactividad a las páginas web vistas con su navegador de internet. Actualmente JavaScript está integrado en otras aplicaciones y otros navegadores de Internet, y es unos de los lenguajes más utilizados en la red de redes para añadir interactividad a las páginas web. El código JavaScript se embebe en el código HTML de las páginas web añadiendo cierta “inteligencia” e interactividad de las mismas. La mayor parte de las páginas
21 Lampserver, definición [En linea] http://es.wikipedia.org/wiki/LAMP [consultado el 14 de
enero 2014]
22 Osborne Media. McGraw-Hill. Manual de referencia JavaScript. Introducción a JavaScript.
(2002): 15
34
web modernas incluyen algo de código JavaScript, bien sea para obtener ciertos efectos estéticos (cambiar una imagen al pasarle por encima, mover un gráfico por la pantalla…), bien para validar una entrada de datos, hacer cálculos, etc. Nuestros programas de JavaScript no generan ningún tipo de código compilado, sino que éste se interpreta en el navegador de internet una vez se descarga la página que lo contiene. A este tipo de lenguajes se les denomina lenguajes interpretados. JavaScript es un lenguaje muy sencillo que enseguida nos permitirá desarrollar
aplicaciones propias para internet23
HTML
HTML es el lenguaje que se emplea para crear páginas web. Un código escrito es este lenguaje es, básicamente, un texto que el navegador (Internet Explorer, Netscape Navigator, Opera o cualquier otro) mostrará en formato de página web. Este texto puede generar color, tamaño y fuente de letra, fondos, imágenes, hiperenlaces y entradas de datos, así como listas de selección, botones, etc..., determinados y configurados mediante los identificadores, también llamados tags. Un identificador o tag es una marca que permite fijar los atributos de tamaño, posición y comportamiento del texto y /o de las imágenes de la página web. Por regla general, los identificadores constan de una apertura (cuando se establecen sus características) y un cierre (cuando deben dejar de hacer efecto y restablecerse las características originales); sin embargo, por su propia naturaleza, algunos identificadores no tienen cierre.14 HyperText Markup Language, es decir, Lenguaje de Marcas de Hipertexto, que podría ser traducido como Lenguaje de Formato de Documentos para Hipertexto. Se trata de un formato abierto que surgió a partir de las etiquetas SGML (Standard Generalized Markup Language). Concepto traducido generalmente como “Estándar de Lenguaje de Marcado Generalizado” y que se entiende como un sistema que permite ordenar y etiquetar diversos documentos dentro de una lista. Este lenguaje es el que se utiliza para especificar los nombres de las etiquetas que se utilizarán al ordenar, no existen reglas para dicha organización, por eso se dice que es un sistema de formato abierto. EL HTML se encarga de desarrollar una descripción sobre los contenidos que aparecen como textos y sobre su estructura, complementando dicho texto con diversos objetos (como fotografías, animaciones, etc.). Es un lenguaje muy simple y general que sirve para definir otros lenguajes que tienen que ver con el formato de los documentos. El texto en él se crea a partir de etiquetas, también llamadas tags, que permiten interconectar diversos conceptos y formatos. Para la escritura de este lenguaje, se crean etiquetas que aparecen especificadas a través de corchetes o paréntesis angulares: < y >. Entre sus componentes, los
23 José Manuel Alarcón. Programación en JavaScript. Introducción a JavaScript.(2000): 21
35
elementos dan forma a la estructura esencial del lenguaje, ya que tienen dos propiedades (el contenido en sí mismo y sus atributos). Por otra parte, cabe destacar que el HTML permite ciertos códigos que se conocen como scripts, los cuales brindan instrucciones específicas a los navegadores que se encargan de procesar el lenguaje. Entre los scripts que pueden agregarse, los más conocidos y utilizados son JavaScript y PHP.24
CCS CSS son las siglas de Cascading Style Sheets - Hojas de Estilo en Cascada - que es un lenguaje que describe la presentación de los documentos estructurados en hojas de estilo para diferentes métodos de interpretación, es decir, describe cómo se va a mostrar un documento en pantalla, por impresora, por voz (cuando la información es pronunciada a través de un dispositivo de lectura) o en dispositivos táctiles basados en Braille. ¿Para qué sirve? CSS es una especificación desarrollada por el W3C (World Wide Web Consortium) para permitir la separación de los contenidos de los documentos escritos en HTML, XML, XHTML, SVG, o XUL de la presentación del documento con las hojas de estilo, incluyendo elementos tales como los colores, fondos, márgenes, bordes, tipos de letra..., modificando as la apariencia de una página web de una forma más sencilla, permitiendo a los desarrolladores controlar el estilo y formato de sus documentos. ¿Cómo funciona? El lenguaje CSS se basa en una serie de reglas que rigen el estilo de los elementos en los documentos estructurados, y que forman la sintaxis de las hojas de estilo. Cada regla consiste en un selector y una declaración, esta última va entre corchetes y consiste en una propiedad o atributo, y un valor separados por dos puntos.25
24 Definición, Definición de HTML. [En línea] http://definicion.de/html/ [consultado el 15 de
enero de 2014]
25 Masadelante. Definición de CSS. [En línea] http://www.masadelante.com/faqs/css
[Consultado el 15 de enero de 2014]
36
MARCO METODOLÓGICO La metodología requerida y sobre la cual se desarrolló este proyecto es la OpenUP/OAS de la oficina asesora de sistemas de la Universidad Distrital Francisco José de Caldas. OpenUP/OAS es un proceso unificado (de aplicación general) y ágil (se centra en el desarrollo rápido de sistemas) que involucra un conjunto mínimo de prácticas que ayudan a los equipos de trabajo a ser más efectivos en el desarrollo de sistemas software (u otros sistemas de ingeniería). El Proceso Unificado Abierto – llamado en adelante OpenUP, integra una filosofía pragmática y ágil que se centra en la naturaleza colaborativa del desarrollo de software. Es un proceso antiburocrático y agnóstico en cuanto a herramientas (IDE, lenguajes, sistemas operativos, etc.) que puede ser usado tal como lo ha definido la fundación Eclipse – de donde procede el OpenUP, o que puede ser expandido y adaptado de acuerdo a las especificados de cada proyecto.26 OpenUP/OAS persigue: Promover la colaboración (tanto interna como externa al equipo), alinear
intereses y compartir conocimientos. Ayudar al equipo a enfocarse en la arquitectura de forma rápida; de tal forma
que se minimicen los riesgos y se organice el desarrollo. Ayudar al equipo a balancear prioridades en conflicto para maximizar el valor
obtenido por los interesados en el proyecto. Ayudar al equipo en la evolución continua del producto para obtener
retroalimentación continua y fomentar el mejoramiento. Permitir a los administradores del proyecto realizar seguimientos a los avances
basados en metas e indicadores Permitir que los integrantes del equipo entiendan rápidamente como realizar el
trabajo para alcanzar los objetivos y metas proyectados. Los principios en que se enmarca el método de trabajo OPENUP/OAS son: a) Conocer a los Interesados: Se deben identificar, conocer a los grupos de
interés y trabajar de cerca con ellos para asegurarse que sus necesidades son claramente definidas e incrementalmente satisfechas a medida que se evoluciona en el desarrollo de la solución. Debe mantenerse una comunicación abierta y frecuente además de una colaboración entre ellos y el equipo de trabajo.
26 Oficina Asesora de Sistemas- Universidad Distrital Francisco José de Caldas, Proceso de
desarrollo metodología OpenUP/OAS [en línea]
http://www.udistrital.edu.co:8080/documents/276352/356568/Cap1GeneralidadesProcesoOpenu
p.pdf
37
b) Separar el Problema de la Solución: Se debe estar seguro que se conoce el problema (o una parte de él) antes de definir una solución (o una parte de ella). Al separar claramente el problema (que necesita el cliente - no que necesita el equipo de desarrollo) de la solución (el sistema que tiene que hacer), es fácil mantener un enfoque y encontrar vías alternativas para solucionar el problema.
c) Crear un conocimiento compartido del dominio: Se debe fomentar un ambiente de intercambio y trabajo en el que todos los involucrados puedan obtener constantemente la información adecuada para lograr tener una visión compartida de lo que se debe hacer, el por qué hacerlo y como se está haciendo.
d) Usar escenarios y casos de uso para capturar requerimientos: Hacer uso de escenarios y casos de uso para capturar los requerimientos funcionales del sistema permiten que los interesados alcancen rápidamente un consenso acerca de sus necesidades e intereses.
e) Establecer y mantener contratos de prioridades: Se deben priorizar los requisitos y requerimientos de implementación basada en un trabajo continuo con los grupos de interés y tomar decisiones que lleven a que el sistema siempre incremente los beneficios ofrecidos y reduzca los riesgos.
f) Realizar negociaciones que maximicen el beneficio obtenido: Las negociaciones costo beneficio dentro del proyecto no pueden ser independientes de la arquitectura. Los requisitos y requerimientos establecen los beneficios que se deben alcanzar al implementar el sistema mientras que la arquitectura es una medida base para calcular el costo del mismo. El costo asociado con un beneficio puede influenciar en gran medida la percepción del usuario acerca del valor real obtenido.
g) Gestionar el entorno: El cambio es inevitable, y aunque presenta oportunidades para mejorar los beneficios dados a los grupos de interés, un entorno incontrolado de cambios fácilmente de cantará en sistemas deficientes, sobredimensionados y que no satisfacen las necesidades reales de los clientes. Se debe gestionar los cambios manteniendo contratos específicos con los grupos de interés.
h) Conocer cuándo se debe parar: Sobre recargar de características un sistema no sólo es una pérdida de tiempo y recursos sino que conduce a sistemas innecesariamente complejos. El desarrollo debe parar cuando la calidad esperada del sistema se alcanza.
i) Mantenga un entendimiento común: Sea proactivo comunicando y compartiendo información con los participantes del proyecto y no asuma que todos y cada uno encontrarán justo lo que ellos necesitan saber o que cada persona tiene la misma comprensión del proyecto que todos los demás.
38
j) Aprender continuamente: Desarrolle continuamente sus habilidades técnicas e interpersonales, aprenda de los ejemplos de sus colegas, aproveche la oportunidad, tanto de ser un estudiante de sus colegas, así como maestro de ellos. Siempre incremente su habilidad personal para sobrellevar su propio antagonismo hacia otros miembros del equipo.
k) Organice alrededor de la arquitectura: La comunicación entre los miembros del
equipo empieza a ser compleja incrementalmente. Por consiguiente, organice el equipo alrededor de la arquitectura, el vocabulario y el modelo mental compartido del sistema.
l) Desarrolle su proyecto en iteraciones: Divida su proyecto en una serie de iteraciones encajadas en el tiempo y planee su proyecto iterativamente. Esta estrategia iterativa lo habilita para entregar capacidades incrementalmente, como un conjunto ejecutable, subconjunto utilizable de requisitos y requerimientos probados e implementados, que pueden ser evaluados por los interesados al final de cada iteración.
m) Gestione los riesgos: Ataque tempranamente los riesgos que atacarán el proyecto. Continuamente identifique y priorice los riesgos y entonces idee estrategias para mitigarlos.
n) Adopte y gestione el cambio: Adoptar los cambios ayuda a construir un sistema que se encamina a las necesidades de los interesados y manejar los cambios permite reducir costos y mejorar la predicción de estos cambios. Los cambios hechos tempranamente en el proyecto se pueden hacer usualmente a bajo costo. A medida que usted avanza en el proyecto, los cambios pueden empezar a incrementarse en términos de costos.
o) Mida el progreso objetivamente: Si no conoce objetivamente cómo su proyecto está progresando, no sabe si éste falla o tiene éxito. La incertidumbre y los cambios a un proyecto de software en progreso dificultan medirlo objetivamente, en tanto que las personas tienen una habilidad muy asombrosa para creer que todo está bien ante la catástrofe. 27
27 Oficina Asesora de Sistemas- Universidad Distrital Francisco José de Caldas, Guía rápida
proceso de desarrollo OPENUP/OAS [en línea]
https://udistrital.edu.co/files/dependencias/oas/GuiaRapidaOpenUPOAS.pdf
39
Fases de la metodología de desarrollo OPENUP/OAS
Fase de Inicio:
Primera fase del proceso, donde los interesados (stakeholders) y los integrantes del equipo de desarrollo, colaboran para determinar el ámbito del proyecto, sus objetivos y determinar si el proyecto es viable. Al final de esta fase, como mínimo, el proyecto:
Ha definido el ámbito
Tiene un estimado inicial de los costos y el cronograma
Ha definido y priorizado un conjunto inicial de requerimientos funcionales y no funcionales
Ha identificado un conjunto de riesgos y haya propuesto las estrategias de mitigación.
Ha identificado un conjunto de interesados.
Ha creado un bosquejo de arquitectura.
En este punto se recalca que la presente es una “guía rápida” que no describe los pormenores asociados con cada una de las tareas. Para guías específicas consultar el documento maestro del proceso. En el sitio web del proceso openup/oas se encuentran plantillas que deben ser utilizadas como base para la elaboración de los documentos especificados en las tareas.
Fase de Elaboración:
La segunda fase dentro del ciclo de vida del proyecto. En ella los riesgos significativos que influyen en la arquitectura son identificados y considerados. En esta fase:
• Se obtiene un entendimiento más detallado de los requerimientos y requisitos
• Se diseña, implementa valida y establece la línea base de la arquitectura. • Se mitigan los riesgos esenciales. • Se produce un cronograma detallado. • Se realiza una mejor estimación de costos.
Fase de Construcción: Esta es la tercera fase del proceso, se enfoca en detallar los requisitos y requerimientos, diseñar, implementar y probar el grueso del software y completar el desarrollo del sistema basado en la arquitectura. 1. Se describen los requisitos y requerimientos restantes
40
2. Se completan en detalles los diseños, la implementación y las pruebas del software.
3. Se libera la primera versión operativa del software (beta) del sistema. Las actividades de esta fase son
1. Planificación y gestión de la iteración 2. Identificar y refinar requisitos y requerimientos 3. Desarrollar un incremento de solución 4. Probar la solución construida
Fase de Transición Es la cuarta fase del proceso. Se enfoca en la transición del producto de software a la plataforma tecnológica del cliente logrando que los interesados convengan que el desarrollo del producto cumple con los requerimientos planteados. Los objetivos de esta fase son lograr:
La prueba beta valida que satisfaga las expectativas del usuario. Esto típicamente requiere algunas actividades de afinamiento, tales como depuración de errores y mejora del desempeño y la usabilidad.
El consentimiento de los interesados en que el desarrollo está completo.
Esto puede involucrar varios niveles de pruebas para la aceptación del producto, incluyendo pruebas formales e informales y pruebas beta.
Mejorar el desempeño en futuros proyectos a través de lecciones
aprendidas.
Documentar las lecciones aprendidas y mejorar el ambiente de los procesos y las Herramientas para el proyecto. 28
28 Oficina Asesora de Sistemas- Universidad Distrital Francisco José de Caldas, Guía rápida
proceso de desarrollo OPENUP/OAS [en línea]
https://udistrital.edu.co/files/dependencias/oas/GuiaRapidaOpenUPOAS.pdf
41
1.12 CRONOGRAMA DE ACTIVIDADES
Figura 1 Cronograma de actividades
42
2. FASE DE ELABORACIÓN
En esta fase del proyecto se identificaron los riesgos más significativos y
considerados que influyen dentro de la arquitectura, también se obtuvo un
entendimiento más detallado de los requerimientos y requisitos, además de que se
establece, se implementa y se valida la línea base de la arquitectura.
2.1 IDENTIFICACIÓN DE LA INFORMACIÓN
Para el proceso de identificación de la información, fue necesario realizar una
entrevista, como técnica de levantamiento de requerimientos y requisitos, que
dieron el entendimiento sobre el problema a tratar para la gestión de incidentes de
seguridad de la información en aplicaciones, basado en la NTC-ISO/IEC 27002-
27035. Para el caso de uso de la Universidad Distrital.
Esta entrevista se realizó a Ing. Jaider Ospina de la oficina asesora de sistemas, con el fin de conocer más a fondo los procesos que se llevan dentro de la OAS. Ver Anexo A Entrevista Ing. Jaider Ospina Oficina asesora de sistemas. Entrevista
Con las entrevistas realizadas se pudo llegar a las siguientes conclusiones:
Actualmente en el área de sistemas no se maneja un procedimiento para el
reporte de incidentes que se puedan presentar a nivel de seguridad en sus
aplicaciones de tal manera que les permita atender y llevar un procedimiento
correctivo y posteriormente preventivo.
* Actualmente en el área de área no se tiene un formato que permita la gestión de
incidentes, es decir, que un ingeniero atiende reportes según estos se puedan
reportar, pero no llevan ningún control de esto.
* Actualmente el área de sistemas no lleva un proceso que permita el control de
los reportes de eventos de seguridad informática.
* La aplicación IXION-UD deberá permitir a un ingeniero llevar un control más
definido y completo desde el reporte de un evento y la trazabilidad de este si se
convierte en incidente y la resolución y mitigación del impacto.
43
*El sistema SISBIUD - Psicología deberá generar informes de gestión que den
cuenta de las acciones efectuadas para disminuir el riesgo potencial de los
eventos presentados y las políticas desarrolladas para eliminar las
vulnerabilidades reportadas.
2.2 REQUERIMIENTOS
2.2.1 Requerimientos Funcionales
Código de
Requerimientos
Fecha Descripción del
requerimiento
Documento
referencia
1 21/10/2014 El sistema debe
permitir reportar un
evento teniendo en
cuenta si el usuario
final pertenece o no
a la institución.
Donde ponga la
fecha, hora, nombre
y correo de contacto
de quien reporta el
incidente.
Fabián Bocanegra
Jefferson Ordoñez
2 21/10/2014 El sistema debe
permitir realizar
informes de cuantas
eventos e incidentes
se atienden al día,
cada semana, al
mes y
semestralmente.
Fabián Bocanegra
Jefferson Ordoñez
3 21/10/2014 El sistema debe
permitir visualizar
los datos de todos
los perfiles activos.
Fabián Bocanegra
Jefferson Ordoñez
4 21/10/2014 El sistema debe
permitir visualizar el
estado de los
registros realizados
por los gestores
PoC .
Fabián Bocanegra
Jefferson Ordoñez
5 21/10/2014 El sistema debe
permitir consultar
antecedentes de
Fabián Bocanegra
Jefferson Ordoñez
44
incidentes
anteriores por los
gestores ISIRT .
6 21/10/2014 El sistema debe
permitir visualizar el
estado de los
registros de
incidentes
realizados por los
gestores ISIRT.
Fabián Bocanegra
Jefferson Ordoñez
7 21/10/2014 El sistema debe
permitir clasificar los
eventos por los
gestores PoC .
Fabián Bocanegra
Jefferson Ordoñez
8 21/10/2014 El sistema debe
permitir reportar
nuevas
vulnerabilidades.
Fabián Bocanegra
Jefferson Ordoñez
9 21/10/2014 El sistema debe
permitir gestionar
nuevos perfiles y
modificar los
existentes por el
administrador.
Fabián Bocanegra
Jefferson Ordoñez
10 21/10/2014 El sistema debe
permitir gestionar el
manejo de crisis y
enviar reportes a los
responsables para
la búsqueda de una
solución.
Fabián Bocanegra
Jefferson Ordoñez
Tabla 5 Requerimientos funcionales
45
2.2.2 Requerimientos No Funcionales
Para poder tener una completa interacción con el sistema Web es necesario tener
los siguientes requerimientos:
Nombre:
Conexión a internet
Tipo:
No necesario
Crítico:
No
Descripción:
Algunas APIS del sistema tienen componentes que funcionan a través de una
conexión a internet, lo que puede causar que el sistema se ponga un poco lento
pero no es algo crítico.
Criterios de aceptación:
El sistema no deja de trabajar, si no hay una conexión a internet de igual manera
todos sus componentes funcionan de manera un poco lenta.
Tabla 6 Requerimientos no funcionales conexión a internet Nombre:
Uso de navegadores
Tipo:
Necesario
Crítico:
Si
Descripción:
El sistema requiere, de algún tipo de navegador como Google Chrome, Mozilla
Firefox o Internet Explorer
Criterios de aceptación:
El sistema deja de trabajar, si no alguno de estos navegadores instalados en el
sistema ya que es un sistema web y hace uso de cualquiera de los anteriormente
dichos.
Tabla 7 Requerimientos no funcionales uso de navegadores
46
Nombre:
Usuario y contraseña
Tipo:
Necesario
Crítico:
Si
Descripción:
El sistema requiere, que el actor que ingrese al sistema tenga un usuario y
contraseña que lo posibilite como actor de dicho sistema de lo contrario este actor
no podrá hacer uso de las funcionalidades del sistema.
Criterios de aceptación:
El modulo administrativo del sistema genera un usuario y contraseña a la persona
encargada del módulo.
Tabla 8 Requerimientos no funcionales usuario y contraseña Nombre:
Error en tiempo de ejecución
Tipo:
Necesario
Crítico:
No
Descripción:
La aplicación Web, tendrá la capacidad de responder ante cualquier eventualidad
u error que se presente en tiempo de ejecución, presentando así un mensaje,
permitiéndole al usuario identificarlo, y poder corregir su falla.
Criterios de aceptación:
El sistema no dejara de trabajar mostrara un mensaje de error en caso de que falle
el tiempo de ejecución.
Tabla 9 Requerimientos no funcionales error en tiempo de ejecución
47
2.3 Definición de actores
Actor Descripción
Usuario final Es el encargado de detectar y reportar
eventos de seguridad de la
información, ya sea usuario interno o
usuario de terceras partes.
Gestor PoC Es el encargado de evaluar y
responder a eventos e incidentes de
seguridad de la información, para
determinar si los eventos de seguridad
llegan a ser incidentes.
Gestor ISIRT Es el encargado de gestionar los
incidentes de seguridad de la
información hasta su conclusión.
También de evaluar y tomar medidas
frente a vulnerabilidades detectadas
para evitar eventos. Así como de
identificar las lecciones aprendidas y
cualquier mejora al sistema y/o
seguridad en general que se requiera.
Administrador Es el encargado de garantizar la
funcionalidad del sistema en cuanto a
la actualización de base de datos,
perfiles y formatos que permitan
brindar una gestión óptima de los
incidentes a reportar.
Tabla 10 Definición de actores
48
2.4 LISTA PRELIMINAR DE CASOS DE USO POR ACTOR
CASO DE USO
ACTORES
Usuario Final
Gestor PoC
Gestor ISIRT Administrador
Reportar evento x X x x
Consultar eventos x x x x
Clasificación de eventos x x
Reportar incidente x x x
Consultar incidentes x x x x
Manejo de crisis x x
Reporte de nuevas vulnerabilidades x x
Agregar usuarios x
Modifica perfiles x
Elimina perfiles x
Genera informes de gestión x x x Ingreso al sistema x x x x Tabla 11 Lista preliminar de casos de uso por actor
2.5 Depuración de casos de uso por actor
2.5.1 Descripción y Codificación de los casos de uso En este documento se describen los casos de uso de los actores definidos anteriormente los cuales tienen unas y actividades definidas en el alcance de su perfil y en su función misma dentro del sistema de gestión de incidentes de seguridad de la información. La codificación de los casos de uso del sistema de gestión de incidentes de seguridad de la información, parte del área que se está trabajando, en este caso la seguridad de la información. Siendo así, para todos los casos de uso las cuatro primeras letras de la codificación serán referentes a la seguridad de la información (sinf), y las siguientes letras se refieren específicamente a la actividad del caso de uso, ej. Reporte de evento (re), para este caso la codificación seria de la siguiente forma (sinfre), acompañando del número que corresponde al orden dentro del diagrama del caso de uso.
49
2.5.2 Documentación casos de uso El siguiente es la descripción del caso de uso Reporte de evento. Para consultar la totalidad de los casos de uso que componen este apartado, por favor remitirse al ANEXO B digital, de acuerdo a la ley de medio ambiente.
Caso de uso reporte de evento
Figura 2. Caso de uso reporte de evento
IDENTIFICACION CASO DE USO ACTORES
Sinfre1 Reporte de evento Usuario Final, Gestor PoC, Gestor ISIRT, Admin
OBJETIVO
Reportar evento de seguridad de la información en el aplicativo
DESCRIPCION
En este caso de uso detalla la actividad que un usuario puede hacer cuando detecta un evento de seguridad de la información, al reportar el evento en el aplicativo.
Precondiciones El usuario debe haber ingresado al sistema para generar el reporte.
El usuario debe reportar solo eventos de seguridad ocurridos en las aplicaciones web de la Universidad.
El usuario debe asignar información sobre el evento para el control y seguimiento.
El usuario deberá asignar datos personales para que puede hacer seguimiento del evento
50
reportado.
Pos condiciones El sistema debe mostrarle al usuario opción para finalizar reporte.
Sistema muestra ventana emergente con número de ticket.
Alternativas y excepciones
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR RESPUESTA DEL SISTEMA
1. Usuario selecciona “Reportar Evento ”
3. Usuario digita datos solicitados para el reporte del evento.
4. Usuario selecciona “Guardar”.
6. Usuario confirma guardado.
9. Usuario Selecciona opción,
10. Usuario selecciona “Finalizar”
2. Sistema muestra el formato para reporte de nuevos eventos.
5. Sistema solicita verificación de datos y confirmar guardado.
7. Sistema muestra que los datos se guardaron satisfactoriamente en la BD.
8. Sistema muestra opción de “Finalizar”.
PUNTOS DE INTERRUPCION
• Usuario cancela acción
• Usuario no selecciona un campo obligatorio.
• No confirma guardado.
Tabla 11 Caso de uso
51
2.6 MODELO DE PROCESOS
En el siguiente modelo de procesos vemos el funcionamiento real del sistema y el
ciclo de vida que va de acuerdo a la acción a realizar. En este apartado
mostraremos el diagrama referente al reporte de un incidente. Para la consulta de
los demás diagramas de procesos del sistema, por favor consultar el ANEXO C
digital, de acuerdo a la ley de medio ambiente.
Reporte incidente
Figura 3 modelo de procesos reporte incidente
52
3. FASE DE CONSTRUCCIÓN
En esta fase del proceso, se enfocó en detallar los requisitos y requerimientos, diseñar, implementar y probar el grueso del software y completar el desarrollo del sistema basado en la arquitectura.
3.1 DIAGRAMAS DE SECUENCIA
A continuación se muestra el diagrama de secuencia empleado para reporte de evento, los demás diagramas de secuencia se puede consultar en el ANEXO D digital de acuerdo a la ley de medio ambiente.
Diagrama de secuencia reporte evento
Figura 4 Diagrama de secuencia reporte evento
53
3.2 DIAGRAMAS DE ACTIVIDAD
En estos diagramas se muestra de manera simplificada lo que ocurre en un proceso dentro del sistema. A continuación se muestra el diagrama de actividad reporte de evento, los demás diagramas de actividad se pueden consultar en el ANEXO E digital de acuerdo a la ley de medio ambiente.
Diagrama de actividad de reporte de evento
Figura 5 Diagrama de actividad reporte de evento
54
3.3 DIAGRAMAS DE ESTADO
En los diagramas de estado podemos evidenciar el comportamiento del sistema de acuerdo a un estado específico. A continuación se muestra el diagrama de estado reporte de incidente, los demás diagramas de estado se pueden consultar en el ANEXO F digital de acuerdo a la ley de medio ambiente.
Diagrama de estado reporte Incidente
Figura 6 Diagrama de estado reporte incidente
55
3.4 Diagrama de análisis
Figura 7 Diagrama de análisis
56
3.5 Modelo Relacional
57
58
3.6 Arquitectura La aplicación se implementara con un modelo cliente-servidor, debido a que se requiere una
estructura de hospedaje de la aplicación de la parte lógica e interacción de la aplicación y un
componente cliente que será a través de un navegador web ejecutado desde cualquier maquina
conectada a la red. Con estos dos componentes ya definidos es necesario preparar un sistema de
archivos donde se contempla el componente de persistencia de los datos de aplicación.
Siendo así el modelo se estructura de la siguiente manera: Estará compuesto por 3 niveles, de
presentación, de lógica y de persistencia de datos.
1. Presentación: este nivel se refiere a el modelo de interfaz de la aplicación con el que el
usuario final interactúa con la información contenida en la base de datos y le permite
desarrollar su rol en el sistema, ya sea reportando un incidente o en la gestión del mismo.
A través de cualquier navegador web que ejecute la interfaz del aplicativo.
2. Lógica: este es el nivel que se encarga de ejecutar todas las reglas del aplicativo las cuales
están basadas en el modelo de negocio y la solución al problema que se quiere generar, es
decir, la funcionalidad misma del aplicativo y de su acceso a los datos almacenados en la
base de datos correspondiente. Se ejecutara en un servidor WAMP, el cual contiene
servidor Apache, MySQL y PHP, y con la implementación del framework ZEND.
3. Persistencia: es este el nivel de almacenamiento de la información que estará disponible a
los requerimientos que se hagan de la parte lógica por medio de la presentación o interfaz
de la aplicación; además de almacenar la información que se genere de la utilización del
aplicativo. Considerando esto se implementara una base de datos relacional diseñada de
acuerdo a la necesidad del caso en el motor PostgreSQL.
Figura 10 diagrama esquemático del sistema
59
4. FASE DE TRANSICIÓN
En esta fase del desarrollo del software se encuentra la transición que debe existir
entre el producto obtenido y la implementación en el sistema según las
necesidades a las cuales responde. Así como evaluar el desempeño en un
ambiente de pruebas, viabilizando así su publicación en producción.
4.1 Diagrama de componentes
En el siguiente diagrama de componentes podemos observar los diferentes
elementos que componen el diseño del sistema, visualizando la estructura
general que tiene y el comportamiento de cada componente.
Figura 11 diagrama de componentes
60
4.2 Diagramas de paquetes
El siguiente diagrama de paquetes muestra la división del sistema de manera
lógica y las dependencias entre cada una de las agrupaciones, tanto en modelo y
la asignación de vista y controlador de acuerdo a cada módulo implementado
dentro del sistema.
Figura 12 diagrama de paquetes
61
4.3 Diagrama de despliegue
En el siguiente diagrama se puede observar la relación entre los nodos que
componen el sistema, como lo son un usuario que a través de internet realiza
solicitudes desde un determinado navegador, hacia un servidor web que contiene
el sistema web de gestión de incidentes, tiene acceso a los datos de una base de
datos desarrollada en Potsgres.
Figura 13 diagrama de despliegue
62
4.4 Pruebas
A continuación se mostrará las respectivas pruebas unitarias realizadas a cada
módulo del sistema, el resultado de cada una y las correcciones que se hicieron al
respecto.
4.4.1 Prueba unitaria Reporte de evento
Prueba unitaria - Formularios
Dirigida por: Asistente Estado
Fabián Bocanegra ok
Jefferson Ordoñez
Concepto
Probar el funcionamiento del módulo Eventos
Perfil de prueba Ingeniero Poc
Acción Ejecutada
Verificar que el formulario reporte de evento realice el respectivo registro en BD
Elementos de prueba
Formulario Reporte eventos
Resultado esperado
Permitir el registro del evento en la BD
Resultado obtenido
ok
Errores No se muestra errores en los campos
del formulario
Correcciones
Hacer arreglos en la gráfica del
formulario
Tabla 13 pruebas unitarias reporte de evento
63
4.4.2 Prueba unitaria Clasificación Incidente
Prueba unitaria - Formularios
Dirigida por: Asistente Estado
Fabián Bocanegra ok
Jefferson Ordoñez
Concepto
Verificar que el formulario Clasificación de incidente
realice el respectivo registro en BD
Perfil de prueba Ingeniero Isirt
Acción Ejecutada
Verificar que el formulario clasificación de incidente realice el respectivo registro
en BD
Elementos de prueba
Formulario clasificación de incidentes
Resultado esperado Permitir el registro del evento en la BD
Resultado obtenido
ok
Errores No se muestra errores en los campos
del formulario
Correcciones Hacer arreglos en la gráfica del
formulario
Tabla 14 pruebas unitarias clasificación de incidente
64
4.4.3 Prueba unitaria Reporte Vulnerabilidades
Prueba unitaria - Formularios
Dirigida por: Asistente Estado
Fabián Bocanegra Díaz ok
Jefferson Ordoñez
Concepto Verificar que el formulario registro de vulnerabilidad
realice el respectivo registro en BD
Perfil de prueba Ingeniero isisrt
Acción Ejecutada
Verificar que el formulario registro de vulnerabilidad realice el respectivo registro
en BD
Elementos de prueba
Formulario Registro de Vulnerabilidad
Resultado esperado Permitir el registro de la vulnerabilidad
en la BD
Resultado obtenido
ok
Errores No se muestra errores en los campos
del formulario
Correcciones Hacer arreglos en la gráfica del
formulario
Tabla 15 Pruebas unitarias reporte vulnerabilidades
65
4.4.4 Prueba unitaria consulta eventos-incidentes
Prueba unitaria - Formularios
Dirigida por: Asistente Estado
Fabián Bocanegra ok
Jefferson Ordoñez
Concepto
Verificar las consultas de los eventos e incidentes
registrados en la BD
Perfil de prueba Ing. Isirt/Poc/Ufinal/Invitado
Acción Ejecutada
Verificar que se realicen correctamente las consultas de eventos e incidentes en
el respectivo registro en BD
Elementos de prueba
Formulario de consulta eventos e
incidentes
Resultado esperado
Visualizar lo eventos e incidentes
registrados
Resultado obtenido
ok
Errores No se muestra errores en los campos
del formulario
Correcciones
Hacer arreglos en la gráfica del
formulario
Tabla 16 Pruebas unitarias consulta eventos-incidentes
66
4.4.5 Prueba unitaria generación de informe
Prueba unitaria - Formularios
Dirigida por: Asistente Estado
Fabián Bocanegra Incompleto
Jefferson Ordoñez
Concepto Verificar las consultas de los eventos e incidentes
registrados en la BD y exportar archivos pdf
Perfil de prueba Ing. isirt
Acción Ejecutada
Exportar mediante el módulo dompdf los diferentes tipos de consultas en los
formularios de reporte y clasificación de eventos e incidentes
Elementos de prueba
Módulo Dompdf y consultas de los
formularios informes
Resultado esperado Exportación de archivo pdf con la
información solicitada
Resultado obtenido falla
Errores Errores en la implementación del
módulo Dompdf
Correcciones Corregir implementación del Módulo
Dompdf.
Tabla 17 Pruebas unitarias Informes
67
CONCLUSIONES
A partir de un análisis de requerimientos, basados en entrevistas, formatos y normas
establecidas para la gestión de incidentes de seguridad de la información y teniendo como base las necesidades de la oficina asesora de sistemas de la universidad Distrital Francisco José de Caldas se estableció un completo diseño de base de datos que gestiona información necesaria, de esta manera se facilita el acceso y seguridad de los datos. Después de hacer el levantamiento de información y analizar las necesidades del cliente en este caso ingenieros de la OAS en el momento de diseñar e implementar la base de datos fue de gran ayuda utilizar el motor de base de datos PostgreSQL, ya que este cuenta con licencia Open Source y tiene buen rendimiento para tener un mejor control de la cantidad de información que maneja la oficina asesora de sistemas de la Universidad Distrital Francisco José de Caldas También se hace evidente que el manejo Bootstrap, originalmente creado por Twitter, permite crear interfaces web con CSS y JavaScript, cuya particularidad es la de adaptar la interfaz del sitio web al tamaño del dispositivo en que se visualice, Por otra parte el manejo de pestañas permite al usuario tener mejor control de los
datos a llenar y así puede diligenciarla en el orden que el crea preciso, se puede
realizar un diseño muy llamativo y entendible esto les da agilidad a la hora de
cargar y al adaptarse a otros dispositivos.
68
Anexos
69
ANEXO A
Universidad Distrital Francisco José de Caldas Facultad Tecnológica
Tecnología en Sistematización de datos
Entrevista a cargo de: Jefferson Ordoñez Tovar Fabián Bocanegra Díaz Objetivo: Realizar una entrevista con la cual se pueda conocer los procesos llevados a cabo para el caso concreto de incidentes de seguridad informática en la oficina asesora de sistemas de la Universidad distrital francisco José de Caldas. Alcance: Analizar dicha información, para poder definir los requerimientos y requisitos necesarios, para hacer ágil lo referente a la gestión de incidentes informáticos. ENTREVISTA: NOMBRE: Jaider Ospina CARGO: Ingeniero (OAS) Universidad Distrital Francisco José de Caldas. ACTIVIDAD: Entrevista
Pregunta 1: ¿Qué procesos hay establecidos para la gestión de incidentes de seguridad
de la información?
Respuesta:
La universidad tiene procesos manuales informales no sistematizados que no se basan en las normas internacionales para la gestión de incidentes, generalmente la oficina asesora de sistemas siente la necesidad tener un registro de incidentes reportados por los usuarios que usan las diferentes plataformas universitarias. Esto debido a que es necesario llevar un registro basado en las normas internacionales y así tener un control sistematizado de los evento e incidentes que se reportan diaria mente y dar rápidamente una clasificación y solución.
70
Pregunta 2: ¿Hay una plantilla para diligenciar esa información?
Sí, existen unos formatos manuales los cual se diligencian.
Pregunta 3: ¿Hay casos de incidentes que sean remitidos por ingenieros de la OAS?
Sí, hay casos que son remitidos de los ingenieros, pero este procedimiento casi nunca funciona debido a la falta de socialización entonces puede que el evento ya se haya solucionado y se vuelve a hacer todo el procedimiento por la falta de documentación. Pregunta 4: Con el sistema de información… Leyes y estándares. La universidad como tal tiene unas políticas de seguridad las cuales se deben seguir pero también existen estándares internacionales como la iso que tiene un modelo sobre el sistema de gestión de seguridad de la información y también sobre la gestión de incidentes de seguridad, por tanto nuestra plataforma del sistema de información debe basase con los diferentes estándares internacionales como la iso 27035, esto ayudara a tener la información disponible y en línea para los autorizados. Pregunta 5: ¿En dónde quedan archivados los documentos de cada evento? Los documentos quedan archivados en la oficina asesora de sistemas que hace el seguimiento de algunos eventos. Pregunta 6: ¿Quién puede tener acceso a esos documentos? Todas las personas que tengan acceso físico a la OAS puede tener acceso a esos documentos, pero lo ideal es que solo se tenga acceso a esta información una mesa de ayuda ya que tienen un carácter confidencial, y pueden llegar a explotarse diferentes tipos de vulnerabilidades en los sistemas de la universidad.
71
Pregunta 7: ¿Es importante que los usuarios que reportan los eventos tengan el resumen del evento y su solución? No, es importante porque casi nadie pide dichos resúmenes. O se da un resumen muy neutro y puntual del evento.
72
ANEXO B
Casos de uso, diagramas y descripción
1. Caso de uso reporte de evento
IDENTIFICACION CASO DE USO ACTORES
Sinfre1 Reporte de evento Usuario Final, Gestor PoC, Gestor ISIRT, Admin
OBJETIVO
Reportar evento de seguridad de la información en el aplicativo
DESCRIPCION
En este caso de uso detalla la actividad que un usuario puede hacer cuando detecta un evento de seguridad de la información, al reportar el evento en el aplicativo.
Precondiciones El usuario debe haber ingresado al sistema para generar el reporte.
El usuario debe reportar solo eventos de seguridad ocurridos en las aplicaciones web de la Universidad.
El usuario debe asignar información sobre el evento para el control y seguimiento.
El usuario deberá asignar datos personales para que puede hacer seguimiento del evento reportado.
Pos condiciones El sistema debe mostrarle al usuario opción para finalizar reporte.
Sistema muestra ventana emergente con número de ticket.
Alternativas y excepciones
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR RESPUESTA DEL SISTEMA
1. Usuario selecciona “Reportar Evento ”
3. Usuario digita datos solicitados para el reporte del evento.
4. Usuario selecciona “Guardar”.
6. Usuario confirma
2. Sistema muestra el formato para reporte de nuevos eventos.
5. Sistema solicita verificación de datos y confirmar guardado.
7. Sistema muestra que los datos se guardaron satisfactoriamente en la BD.
8. Sistema muestra opción de “Finalizar”.
73
guardado.
9. Usuario Selecciona opción,
10. Usuario selecciona “Finalizar”
PUNTOS DE INTERRUPCION
• Usuario cancela acción
• Usuario no selecciona un campo obligatorio.
• No confirma guardado.
2. Caso de uso Consultar Reporte
IDENTIFICACION CASO DE USO ACTORES
Sinfce3 Consultar Reportes Gestor PoC, usuario final, Gestor ISIRT, Admin
OBJETIVO
Usuario consulta incidente de seguridad filtrando la información de acuerdo a su necesidad.
DESCRIPCION
En este caso de uso se encarga de consultar reportes realizados de algún evento de seguridad de la información relacionada con las aplicaciones web de la universidad para su posterior gestión.
Precondiciones El reporte consultado debe existir.
Los gestores deben ingresar al sistema con su usuario y contraseña, para el control interno.
Usuario debe estar en el módulo de consultas.
Pos condiciones El sistema debe mostrar el reporte y la opción para finalizar consulta.
Sistema muestra opción de consultar de nuevo.
Alternativas y excepciones
El usuario no selecciona ninguna opción que muestra el sistema.
74
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR
RESPUESTA DEL SISTEMA
1. ingresar el ticket para realizar la consulta.
2. dar clic en el botón consultar.
7.selecciona alguna de las opciones
3. se realiza la consulta en la base de datos
4. muestra reporte consultado.
5. muestra opciones de imprimir y/o guardar
6. muestra opción finalizar
PUNTOS DE INTERRUPCION
• Usuario cancela acción
• Usuario no selecciona un campo obligatorio.
• No confirma guardado.
75
3. Caso de uso Clasificación de eventos
IDENTIFICACION CASO DE USO ACTORES
Sinfce4 Clasificación de eventos
Gestor PoC, Gestor ISIRT, Admin
OBJETIVO
Gestor clasifica evento después de consultar reporte con la debida información que detalle el caso.
DESCRIPCION
Es este caso de uso el gestor PoC podrá realizar la correspondiente clasificación del caso según sea un incidente o no.
Precondiciones Usuario debe haber ingresado al sistema con un usuario y contraseña propia del perfil.
El evento no debe estar clasificado
Pos condiciones Sistema muestra salida del aplicativo.
Muestra la posibilidad de consultar eventos recientes para su clasificación
Alternativas y excepciones
El usuario no selecciona ninguna opción que muestra el sistema.
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR
RESPUESTA DEL SISTEMA
1. ingresar a la clasificación de eventos.
3. dar clic en el botón guardar.
7.selecciona finalizar
2. muestra opciones guardar
4. se guardan los parámetros en la base de datos
5. pregunta si está seguro de guardar.
6. muestra opción finalizar
PUNTOS DE INTERRUPCION
• Usuario cancela acción
• Usuario no selecciona un campo obligatorio.
76
• No confirma guardado.
4. Reporte Incidente
IDENTIFICACION CASO DE USO ACTORES
Sinfcci8 Reporte de incidentes
Gestor PoC, ISIRT, Admin
OBJETIVO
Dependiendo de la información registrada sobre el evento de seguridad el usuario PoC determina en reportar el evento como un incidente de seguridad.
DESCRIPCION
En este caso de uso el gestor PoC podrá definir el caso como incidente y el gestor ISIRT podrá analizar y revisar información registrada sobre incidente, darle seguimiento de una forma investigativa de manera más avanzada para la gestión de control y resolución de la falla.
Precondiciones
Haber ingresado al sistema con el usuario y la contraseña del perfil correspondiente
Pos condiciones Sistema muestra salida del aplicativo.
Sistema muestra opciones propias de su perfil.
Alternativas y excepciones
El usuario no selecciona ninguna opción que muestra el sistema.
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR
RESPUESTA DEL SISTEMA
1. ingresa al reporte del incidente/ a la investigación(ISIRT)
3. dar clic en el botón enviar/
2. muestra opciones reporte
4. se guardan los parámetros en la base de datos
5. pregunta si está seguro de guardar.
77
selecciona la información levantada en la investigación.
7.selecciona finalizar
6. muestra opción finalizar
PUNTOS DE INTERRUPCION
• Usuario cancela acción
• Usuario no selecciona un campo obligatorio.
• No confirma guardado.
5. Caso de uso Consultar incidentes
IDENTIFICACION CASO DE USO ACTORES
Sinfci2 Consultar incidentes Usuario final, Gestor PoC, Gestor ISIRT, Admin
OBJETIVO
Usuario consulta incidente de seguridad filtrando la información de acuerdo a su necesidad.
DESCRIPCION
En este caso de uso se puede hacer una consulta a la base de datos acerca de los incidentes, su gestión y control.
Precondiciones El evento consultado debe existir.
Los gestores deben ingresar al sistema con su usuario y contraseña, para el control interno.
Usuario debe estar en el módulo de consultas.
Pos condiciones El sistema debe mostrarle al usuario opción para finalizar consulta de incidente.
Sistema muestra opción de consultar de nuevo.
78
Alternativas y excepciones
El usuario no selecciona ninguna opción que muestra el sistema.
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR
RESPUESTA DEL SISTEMA
1. ingresar el ticket para realizar la consulta.
2. dar clic en el botón consultar.
7.selecciona alguna de las opciones
3. se realiza la consulta en la base de datos
4. muestra reporte consultado.
5. muestra opciones de imprimir y/o guardar
6. muestra opción finalizar
PUNTOS DE INTERRUPCION
• Usuario cancela acción
• Usuario no selecciona un campo obligatorio.
• No confirma guardado.
6. Caso de uso Clasificación de incidentes
IDENTIFICACION CASO DE USO ACTORES
Sinfci4 Clasificación de incidentes
Gestor PoC, Gestor ISIRT, Admin
OBJETIVO
Gestor clasifica evento después de consultar reporte con la debida información que detalle el caso.
DESCRIPCION
Es este caso de uso el gestor ISIRT podrá realizar la correspondiente clasificación del caso según sea avance en la gestión correspondiente.
Precondiciones Usuario debe haber ingresado al sistema con un usuario y contraseña propia del perfil.
79
El incidente no debe estar clasificado
Pos condiciones Sistema muestra salida del aplicativo.
Muestra la posibilidad de consultar eventos recientes para su clasificación
Alternativas y excepciones
El usuario no selecciona ninguna opción que muestra el sistema.
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR
RESPUESTA DEL SISTEMA
1. ingresar a la clasificación de incidente.
3. dar clic en el botón guardar.
7.selecciona finalizar
2. muestra opciones guardar
4. se guardan los parámetros en la base de datos
5. pregunta si está seguro de guardar.
6. muestra opción finalizar
PUNTOS DE INTERRUPCION
• Usuario cancela acción
• Usuario no selecciona un campo obligatorio.
• No confirma guardado.
7. Caso de uso Manejo de crisis
IDENTIFICACION CASO DE USO ACTORES
Sinfmc11 Manejo de crisis Gestor ISIRT
OBJETIVO
Dar gestión inmediata a incidente según su prioridad
DESCRIPCION
Usuario ingresa al manejo de crisis después de evaluar incidente y clasificarlo si este es de urgencia y representa un riesgo para la información.
80
Precondiciones Usuario ingresa al manejo de crisis después de consultar antecedentes del incidente.
Ingresa al manejo de crisis cuando un incidente representa un grado de prioridad alta.
Pos condiciones Sistema muestra opción de envió de reporte de incidente al área encargada para su estudio y solución.
Alternativas y excepciones
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR RESPUESTA DEL SISTEMA
1. Usuario Ingresa al módulo “Manejo de crisis”.
3. Usuario Inserta datos de incidente.
4. Usuario selecciona “Guardar”.
6. Usuario confirma guardado de información.
9. Usuario selecciona dependencia y da clic en “enviar”.
11. Usuario selecciona “Finalizar”
2. Sistema Muestra formulario de crisis.
5. Sistema Solicita confirmación para guardar.
7. Sistema Guarda información.
8. Sistema muestra registro exitoso, y opción de enviar reporte de crisis a dependencia encargada.
9. Sistema muestra envió exitoso, y botón “Finalizar”
PUNTOS DE INTERRUPCION
• Usuario cancela acción
No confirma guardado de inserción.
81
8. Caso de uso Reportar Vulnerabilidades
IDENTIFICACION CASO DE USO ACTORES
Sinfrv12 Reportar nuevas vulnerabilidades
Gestor ISIRT
OBJETIVO
Reportar nuevas vulnerabilidades
DESCRIPCION
Usuario reporta nueva vulnerabilidad con la información necesaria para su debida gestión.
Precondiciones Usuario reporta vulnerabilidad cuando encuentra una distinta a las reportadas en la base de datos.
Pos condiciones Sistema muestra resultado de inserción de nueva vulnerabilidad.
Alternativas y excepciones
Vulnerabilidad a registrar ya existente en la base de datos.
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR
RESPUESTA DEL SISTEMA
1. Usuario Selecciona “Reportar Vulnerabilidades”.
3. Usuario digita los datos solicitados.
4. Usuario selecciona “Guardar”.
6.
Usuario confirma guardado.
2. Sistema muestra formulario de reporte de vulnerabilidades.
5. Sistema Solicita confirmación para guardar.
7. Sistema muestra registro exitoso, y botón “Finalizar”
82
7.
Usuario Selecciona “Finalizar”.
PUNTOS DE INTERRUPCION
• Usuario cancela acción.
• Usuario reporta vulnerabilidad existente.
• No confirma guardado de inserción.
9. Caso de uso Agregar Usuarios
IDENTIFICACION CASO DE USO ACTORES
Sinfap15 Agregar usuarios Administrador
OBJETIVO
Agregar perfil nuevo
DESCRIPCION
Permite al administrador agregar roles a un usuario nuevo que se crea en la base de datos.
Precondiciones Reportar necesidad eventual de un nuevo perfil.
Que perfil no exista.
Pos condiciones Sistema muestra ventana emergente con inserción exitosa.
Alternativas y excepciones
Salir del aplicativo
Perfil existente
Error al momento de insertar datos.
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR
RESPUESTA DEL SISTEMA
1. Usuario selecciona
botón “ agregar
2. Sistema muestra formulario para editar campos necesarios.
5. Sistema pide confirmación para guardar.
83
usuario” 3. Usuario digitas
campos solicitados.
4. Usuario pulsa botón “Guardar.” 5. Usuario
confirma guardado.
6. Usuario pulsa botón “Finalizar”
6. Sistema Guarda datos registrados en el formulario.
7. Sistema muestra guardado con éxito y botón Finalizar.
PUNTOS DE INTERRUPCION
Usuario cancela acción
No confirma guardado de inserción
10. Caso de uso Modifica Usuarios
IDENTIFICACION CASO DE USO ACTORES
Sinfap15 Modificar usuarios Administrador
OBJETIVO
Modificar usuario
DESCRIPCION
Permite al administrador modificar valores de los datos básicos guardados en la base de datos de cada usuario.
Precondiciones Reportar necesidad eventual de modificar un usuario.
Que perfil exista.
Pos condiciones Sistema muestra ventana emergente con update exitosa.
Alternativas y excepciones
Salir del aplicativo
Perfil existente
Error al momento de insertar datos.
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR
RESPUESTA DEL SISTEMA
1. Usuario 2. Sistema muestra campos para editar.
84
ingresa a modificar usuario. 3. Selecciona usuario que desea modificar. 5. Usuario edita nuevo valor en campo deseado. 6. Usuario da clic en botón Modificar. 8 usuario confirma acción
4. Sistema muestra datos básicos del usuario seleccionado que están en la base de datos.
7. sistema pide confirmar acción.
8. sistema muestra éxito en operación.
PUNTOS DE INTERRUPCION
Usuario cancela acción
No confirma actualización de información.
11. Caso de uso Elimina usuario
IDENTIFICACION CASO DE USO ACTORES
Sinfap15 Eliminar usuarios Administrador
OBJETIVO
Elimina usuario
DESCRIPCION
Permite al administrador eliminar la información relacionada en la base de datos de cada usuario.
Precondiciones Reportar necesidad eventual de eliminar un usuario.
Que perfil exista.
Pos condiciones Sistema muestra ventana emergente con delete exitoso.
85
Alternativas y excepciones
Salir del aplicativo
Perfil existente
Error al momento de insertar datos.
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR
RESPUESTA DEL SISTEMA
1. Usuario ingresa a eliminar usuario. 3. Selecciona usuario que desea eliminar de la BD. 6. Usuario da clic en botón eliminar de la BD. 8 usuario confirma acción
2. Sistema muestra lista de usuarios.
4. Sistema muestra datos básicos del usuario seleccionado que están en la base de datos.
7. sistema pide confirmar acción.
8. sistema muestra éxito en operación.
PUNTOS DE INTERRUPCION
Usuario cancela acción
No confirma eliminación.
12. Caso de Uso Generar de Informes
IDENTIFICACION CASO DE USO ACTORES
Sinfgi6 Generar de informes Gestor PoC, Gestor ISIRT, Administrador
OBJETIVO
Generar informes de gestión.
DESCRIPCION
Usuario determina mediante filtro de consulta en la base de datos según los requerimientos para la generación de un informe, periodo a informar, numero de eventos, incidentes, estados, etc.
Precondiciones Usuario debe haber ingresado al sistema con un usuario y contraseña propia del perfil.
86
Pos condiciones Generación de nuevo informe a partir de nueva consulta.
Alternativas y excepciones
Consultar informes.
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR RESPUESTA DEL SISTEMA
1. Usuario selecciona “Generar informes ”
3. Usuario digita datos de informe y realiza consultas en la DB para el mismo.
4. Usuario selecciona “Guardar”.
6. Usuario confirma guardado.
9. Usuario Selecciona opción,
11. Usuario selecciona “Finalizar”
2. Sistema muestra opciones para generar informe.
5. Sistema solicita verificación de datos y confirmar guardado.
7. Sistema muestra generación satisfactoria.
8. Sistema muestra opciones de enviar por correo, guardar e imprimir.
10. Sistema muestra opción de “Finalizar”.
PUNTOS DE INTERRUPCION
Cancelación de acción.
Datos erróneos.
No confirma guardado.
87
13. Caso de Uso Ingreso al Sistema
IDENTIFICACION CASO DE USO ACTORES
Sinfis7 Ingreso al sistema Gestor PoC, Gestor ISIRT, Administrador
OBJETIVO
Ingreso al sistema
DESCRIPCION
Usuario ingresa al sistema digitando usuario y contraseña correspondiente a su perfil.
Precondiciones Usuario debe solicitar usuario y contraseña de acuerdo a su perfil.
Pos condiciones El sistema muestra opciones al usuario dependiendo sus permisos.
Alternativas y excepciones
Datos Erróneos
CURSO NORMAL DE LOS EVENTOS
ACCION DEL ACTOR
RESPUESTA DEL SISTEMA
1. Usuario abre aplicativo.
3. Usuario Selecciona link de ingreso.
5. Usuario digita datos y selecciona “Login”
2. Sistema muestra página de bienvenida.
4. Sistema solicita ingresar usuario y contraseña.
6. Sistema muestra sección del aplicativo de acuerdo al perfil del usuario.
PUNTOS DE INTERRUPCION
Usuario cancela solicitud.
Datos erróneos
88
Diagramas de casos de uso por usuario
Usuario Final
89
Usuario PoC
90
Usuario ISIRT
91
Administrador
92
ANEXO C
MODELO DE PROCESOS
Reporte incidente
93
Consulta Evento
94
Genera informe
95
ANEXO D
DIAGRAMAS DE SECUENCIA
1. Inicio de sesión
2. Reporte Evento
96
3. Consulta de reportes
97
4. Clasificación de eventos
98
5. Reporte incidentes
99
6. Consulta incidentes
7. Consulta de antecedentes
100
8. Manejo de crisis
101
9. Reporte de Vulnerabilidad
10. Crear usuario
102
11. Modificar usuario
103
12. Eliminar usuario
104
13. Generación de informes
105
ANEXO E
DIAGRAMAS DE ACTIVIDAD
1. REPORTE DE EVENTO
106
2. CONSULTA DE EVENTOS
107
3. CLASIFICACION DE EVENTOS
108
4. REPORTE INCIDENTE
109
5. CONSULTA INCIDENTES
110
6. MANEJO DE CRISIS
111
7. REPORTE VULNERABILIDAD
112
8. inicio de sesión
113
9. CREAR USUARIO
114
10. MODIFICAR USUARIO
115
11. ELIMINAR USUARIO
116
12. GENERACION DE INFORMES
117
ANEXO F
DIAGRAMAS DE ESTADO
1. REPORTE EVENTO
118
2. CONSULTA EVENTO
3. CALSIFICACION DE EVENTO
119
4. REPORTE INCIDENTE
120
5. CONSULTA INCIDENTE
121
6. MANEJO DE CRISIS
122
7. REPORTE VULNERABILIDAD
123
8. INICIO DE SESION
9. USUARIO
124
12. GENERACION DE INFORMES
125
Anexo G
Diccionario de datos
1. facultades
Esta tabla registra las facultades de la universidad, lo que también sirve como referencia para el
reporte de eventos y la localización del incidente como tal.
Columna Tipo de Dato
PK NN Dominio AI FK Valor por Defecto
Descripción
Idfacultad serial X Es el Identificador de tabla, es de tipo auto incremental. Para cada registro nuevo se asigna automáticamente.
nombre character El nombre respectivo de cada facultad que se registra en la base de datos.
telefono Character varying
Número telefónico de la facultad en cuestión.
correo Character varying
Correo electrónico oficial de la facultad.
dirección character X Llave foránea referenciada de la tabla municipio.
126
2. dependencias
Tabla para el registro de las dependencias existentes en la universidad y en las cuales puede
ocurrir algún evento de seguridad de la información.
Columna Tipo de Dato
PK NN Dominio AI FK Valor por Defecto
Descripción
Iddependencia
serial X Es el Identificador de tabla, es de tipo auto incremental. Para cada registro nuevo se asigna automáticamente.
nombre character El nombre respectivo de cada dependencia que se registra en la base de datos.
telefono Character varying
Número telefónico de la dependencia en cuestión.
correo Character varying
Correo electrónico oficial de la dependencia.
3. clase
En esta tabla se encuentra registrada las clases de eventos que pueden ocurrir según lo estipula la
norma ISO 27035 para la gestión de incidente y seguridad de la información.
Columna Tipo de Dato
PK NN Dominio AI FK Valor por Defecto
Descripción
Idclase serial X Es el Identificador de tabla, es de tipo auto incremental. Para cada registro
127
nuevo se asigna automáticamente.
nombre character El nombre respectivo de cada clase que se registra en la base de datos.
descripción character Es una breve descripción de lo que es la clase a la cual hace referencia.
Identificador_clase character Corresponde a un valor que marca la prioridad de la clase respecto a otros.
4. categorización
Esta tabla registra información correspondiente a las categorías de eventos de seguridad de la
información que puede ocurrir, según lo estipula la norma ISO 27035.
Columna Tipo de Dato
PK NN Dominio AI FK Valor por Defecto
Descripción
idcategoria serial X Es el Identificador de tabla, es de tipo auto incremental. Para cada registro nuevo se asigna automáticamente.
nombre character El nombre respectivo de cada categoria que se registra en la base de datos.
descripcion character Es una breve descripción de lo que es la clase a la cual hace
128
referencia.
prioridad character Hace mención a la prioridad que puede tener un determinado evento en la organización.
idclase integer Llave foránea referenciada de la tabla clase.
5. usuarios
Es la tabla donde se registra los usuarios del aplicativo y los cuales son los encargados de hacer la
gestión de los eventos y posibles incidentes reportados, para lo cual se hace una distinción por
niveles de alcance para cada tipo de usuario según el perfil designado.
Columna Tipo de Dato
PK NN Dominio AI FK Valor por Defecto
Descripción
Idusuario Serial X Es el Identificador de tabla, es de tipo auto incremental. Para cada registro nuevo se asigna automáticamente.
documento Integer El número de identificación del usuario registrado.
nombre Charácter El nombre del usuario registrado.
apellido Character El apellido del usuario registrado.
telefono Character Telefono fijo o celular del usuario registrado.
129
usuario Character Usuario de logueo del usuario registrado.
contraseña Character Clave para el logueo del usuario registrado.
perfil Character Perfil de autenticación del usuario registrado en el aplicativo.
correo Character Email del usuario registrado
vinculacion serial X Muestra el tipo de vinculación con la universidad
6. evento
Es la tabla donde se almacena la información básica recogida en el reporte de cada nuevo evento
por cualquier persona.
Columna Tipo de Dato PK NN Dominio AI FK Valor por Defecto
Descripción
Idevento serial X Es el Identificador de tabla, es de tipo auto incremental. Para cada registro nuevo se asigna automáticamente.
fechevento date Fecha cuando ocurrio el evento de seguridad.
fechreporte date Fecha cuando se reporta el evento de seguridad.
fechclas date Registro de fecha en la que se hace la clasificación del
130
evento.
descripcion character Breve descripción de lo evidenciado por quien reporta evento
estado character Estado que se asigna de forma automática cuando se realiza reporte de evento.
finalizo character Indica si el evento de seguridad ya ha finalizado o continua activo
desfinalizo Carácter(30) Describe el por qué se considera que el evento está finalizado.
idusuario integer X Identificador de usuario quien reporta el evento
tipoevento Carácter(20) Indica de qué tipo de evento es el que reporta.
otros Character(100) Se registra cuando las categorías no recogen el evento ocurrido.
descate Character(50) Indica la descripción de porque se categoriza así.
idcate integer X Hace referencia a la tabla categoría, donde se almacena un valor elegido por el usuario PoC.
131
7. incidente
Almacena la información referente a los eventos que son catalogados como incidentes de
seguridad de la información, según previa categorización dada por la norma ISO 27035.
Columna Tipo de Dato
PK NN Dominio AI FK Valor por Defecto
Descripción
Idincidente Serial X Es el Identificador de tabla, es de tipo auto incremental. Para cada registro nuevo se asigna automáticamente.
idcate integer X Hace referencia a la tabla categoría, donde se almacena un valor elegido por el usuario PoC.
Observaciones character Descripción del incidente de seguridad de la información
fechclas date Fecha de clasificación de incidente
idevento integer X La clave que hace referencia a la tabla evento de la cual se registra el incidente.
idusuario character X Registro de usuario que gestiona el incidente.
tipoincidente character Indica de qué tipo de incidente es el que reporta.
comactivo character Este valor hace referencia al
132
componente afecto directamente por el incidente de seguridad
desactivo character Descripción del tipo de componente activo.
fechinvestigacion Date Se registra la fecha en que inicia la investigación para la gestión del incidente.
fechsolucion Date La fecha en que se registra la solución al incidente.
fechfinimpacto Date Se registra la fecha en que finaliza el impacto del incidente.
fechfininves Date Se registra la fecha en que finaliza la investigación para la gestión del incidente.
autores character Autores externos que participan en la gestión del incidente.
desautores character Descripción de los autores que participan.
motivacion character Se registra posible causa de realización de evento.
133
desmotivacion character Descripción de la motivación que causo el evento.
accionespendientes character Son las acciones que están pendientes desarrollar en la gestión del incidente.
accionesplaneadas character Son las acciones que se encuentran en el planteamiento de acción para gestionar el incidente.
accionestomadas character Son las acciones que después de planeadas son ejecutadas.
notificaciones character Registra las notificaciones que se harán en la gestión del incidente.
conclusiones Carácter Se registran las conclusiones que se sacan de la gestión realizada al incidente.
8. vulnerabilidad
Tabla donde se reporta y se le hace seguimiento a las vulnerabilidades reportadas.
Columna Tipo de Dato
PK NN Dominio AI FK Valor por Defecto
Descripción
Idvul serial X Es el Identificador de tabla, es de tipo auto incremental. Para
134
cada registro nuevo se asigna automáticamente.
descripción character Hace referencia a la descripción de la vulnerabilidad que se está reportando.
fechreporte date Es la fecha en que se descubre la vulnerabilidad.
estado character Es el estado en el cual se encuentra la vulnerabilidad.
fechocurrio date El registro de la fecha en que ocurrió la vulnerabilidad.
fechdescubrio date Registro de fecha en que se descubre la vulnerabilidad
idusuario integer X Es la referencia al id del usuario quien reporta, que es de perfil ISIRT.
desestado character Descripción del estado de la vulnerabilidad
confirmacion character Se registra si la vulnerabilidad es confirmada
fechconfirmacion date Fecha en que se confirma vulnerabilidad.
solucion Character Registro de la solución a la vulnerabilidad.
135
dessolucion Character Descripción de la solución de la vulnerabilidad.
9. Impacto
La tabla impacto registra los componentes que determina el impacto causado por el incidente.
Columna Tipo de Dato
PK NN Dominio AI FK Valor por Defecto
Descripción
idimpacto integer X Es el Identificador de tabla, es de tipo auto incremental. Para cada registro nuevo se asigna automáticamente.
idincidente integer Relación de incidente el cual se categorizara con un impacto.
nombre character Nombre del impacto por incidente
directriz character Directriz afectada con el incidente
valor character Valor que causo incidente.
costo character Costo que tuvo incidente.
136
ANEXO H
MANUAL DEL PROGRAMADOR
1. REQUERIMIENTOS DE HARDWARE
Los requerimientos mínimos para poder ejecutar la aplicación son:
Processor AMD E-450 APU whit Radeon (tm) HD Graphics 1.65 GHz
Memoria RAM 1.00 GB
Unidad de disco duro de 80 GB
Tarjeta de red 10, 100
Unidad lectora de Memorias
Mouse
Teclado
Monitor
2. REQUERIMIENTOS DE SOFTWARE
Para el buen funcionamiento del sistema de información, y poder ejecutarlo en un
Equipo de desarrollo local, se recomienda tener las siguientes herramientas de
Software:
Lamp server 2.0
Netbeans IDE 7.2.1
Zend Framework versión 2.1
137
¿Qué es lamp?
El acrónimo LAMP se refiere a un conjunto de subsistemas de software necesarios
para alcanzar una solución global, en este caso configurar sitios web o Servidores
dinámicos con un esfuerzo reducido.
En las tecnologías LAMP esto se consigue mediante la unión de las siguientes
tecnologías:
* Linux, el sistema operativo;
* Apache, el servidor web;
* MySQL, el gestor de bases de datos;
* Perl, PHP, o Python, lenguajes de programación.
Fuente: http://es.wikipedia.org/wiki/LAMP
Prerrequisitos Antes de comenzar, debemos tener una cuenta de usuario que no sea root en el servidor.
Paso 1 - Instalar Apache
El servidor web Apache es actualmente el más famoso de los servidores web en
el mundo. Por ese motivo lo hace idóneo como elección para montar un hosting
web.
Vamos a instalar Apache de una forma sencilla utilizando el administrador de
paquetes de Ubuntu, apt. Vamos a utilizar la aplicación sudo que nos va a permitir
realizar operaciones como super usuario. Para realizar la instalación ejecutamos
los siguientes comandos en la terminal:
sudo apt -get update
sudo apt -get install apache2
138
Una vez instalado podemos verificar que está instalado, ejecutando en el
navegador http://localhost
Lo que tenemos que ver en el navegador es la página web de Apache por defecto
para la distribución, que ofrece información del servicio. Nos debe salir algo como
esto:
Paso 2 - Instalar MySQL
Una vez el servidor web se encuentra operativo, el siguiente paso es instalar la
base de datos. MySQL es un sistema de base de datos, que en este caso no será
el motor utilizado, ya que Lamp requiere configuración previa de MySql para
proceder a configurar otro motor de base de datos.
Para instalarlo vamos a utilizar de nuevo la herramienta apt. En la terminal
ejecutamos lo siguiente:
139
$ apt-get install mysql-server php5-mysql
El paquete mysql-server instalará el servidor MySQL y el paquete php5-
mysql dará el soporte de PHP a la base de datos.
Seguidamente instalaremos Postgres como motor de base de datos para la
aplicación Ixion
El procedimiento de instalación crea una cuenta de usuario llamado postgres que
se asocia con el papel de Postgres por defecto. Para utilizar Postgres, tendremos
que iniciar sesión en esa cuenta. Puede hacerlo escribiendo:
Se le pedirá su contraseña de usuario normal y luego se le dará el intérprete de
comandos para elpostgres usuario.
Paso 3 - Instalar PHP
Para su instalación debemos ejecutar lo siguiente:
$ sudo apt-get install php5 libapache2-mod-php5 php5-mcrypt
El paquete de php5 instalará en nuestro sistema el soporte de php en sí, el
paquete libapache2-mod-php5 proveerá el soporte de php para Apache y el
paquete php5-mcrypt ofrece las librerías1 de diversos sistemas de encriptación
para php.
El siguiente paso es configurar Apache para modificar la forma en que el servidor
sirve los ficheros cuando un directorio es solicitado.
sudo update apt-get
sudo apt-get install postgresql-contrib postgresql
sudo -i -u postgres
140
Para hacer esto, editamos el fichero de configuración /etc/apache2/mods-enabled/dir.conf. Podemos utilizar nuestro editor de textos favorito (vim, nano, gedit, etc), siempre utilizando sudo:
$ sudo vim /etc/apache2/mods-enabled/dir.conf
Una vez abierto, vamos a buscar este trozo de código:
<IfModule mod_dir.c> DirectoryIndex index.html index.cgi index.pl index.php index.xhtml index.htm </IfModule>
Y movemos el fichero index.php a la primera posición de búsqueda:
<IfModule mod_dir.c> DirectoryIndex index.php index.html index.cgi index.pl index.xhtml index.htm </IfModule>
Tras ellos para que se apliquen los cambios en el servidor se debe reiniciar el
servicio, ejecutando el siguiente comando:
$ sudo service apache2 restart
Instalando módulos de PHP
Para ampliar las funcionalidades de PHP, podemos instalar módulos adicionales.
Para ver los módulos y librerías que tenemos disponibles, hacemos una búsqueda
en el repositorio de nuestro sistema ejecutando el siguiente comando:
$ apt-cache search php5-
El resultado será una lista de componentes opcionales que podemos instalar,
incluyendo una breve descripción de cada uno:
141
php5-cgi - server-side, HTML-embedded scripting language (CGI binary) php5-cli - command-line interpreter for the php5 scripting language php5-common - Common files for packages built from the php5 source php5-curl - CURL module for php5 php5-dbg - Debug symbols for PHP5 php5-dev - Files for PHP5 module development php5-gd - GD module for php5 . . .
Para obtener una información más pormenorizada de un componente concreto
podemos ejecutar el siguiente comando:
$ apt-cache show nombre_paquete
Una vez ejecutado, en el campo Descripción podremos ver dicha información.
Si finalmente queremos instalar un componente concreto podemos instalarlo con
nuestra herramienta apt del siguiente modo:
$ sudo apt-get install php5-modulo
Si queremos instalar más de un componente podemos hacerlo en la misma línea
de instalación del siguiente modo:
$ sudo apt-get install paquete1 paquete2 …
Paso 4 - Probar el procesamiento de PHP en nuestro servidor Web
Para poder probar si nuestro sistema está correctamente configurado para PHP
debemos crearnos un script sencillo y alojarlo en el servidor.
142
Llamaremos a este fichero de script como informacion.php. Para que Apache
encuentre el fichero y lo sirva correctamente, debemos salvar dicho fichero en un
directorio especifico, que normalmente es llamado “web root”.
En Ubuntu 14.04, este directorio está localizado en /var/www/html. Crearemos el
fichero en dicha localización editando directamente sobre el directorio del siguiente
modo:
$ sudo vim /var/www/html/informacion.php
Con el editor de texto abierto, agregamos el siguiente código PHP dentro del
fichero:
<?php phpinfo(); ?>
Y lo salvamos.
La función phpinfo() nos mostrará una página generada de forma dinámica
referente a la información del servidor, con datos del estado del servicio, versión
de php, módulos instalados, etc.
Es momento de probar si nuestro servidor está preparado para mostrar de forma
correcta el contenido del script PHP. Para poder realizar esto, en el navegador
indicaremos la dirección ip del servidor seguido del fichero php, escribiendo en la
barra de navegación lo siguiente:
http://ip_servidor/informacion.php
La página que debería aparecer sería algo así:
143
Si aparece esto, significa que PHP está funcionando como se espera. Debemos eliminar el fichero para no dejar información residual en nuestro servidor. Esto se hace ejecutando el siguiente comando:
$ sudo rm /var/www/html/informacion.php
144
NetBeans Es un entorno de desarrollo integrado libre, hecho principalmente para el lenguaje de programación Java. Existe además un número importante de módulos para Extenderlo. NetBeans IDE es un producto libre y gratuito sin restricciones de uso. NetBeans es un proyecto de código abierto de gran éxito con una gran base de usuarios, una comunidad en constante crecimiento, y con cerca de 100 socios en todo el mundo. Sun MicroSystems fundó el proyecto de código abierto NetBeans en junio de 2000 y continúa siendo el patrocinador principal de los proyectos. 3.2.2 Descarga de Netbeans IDE 7.2.1 Para descargarlo de forma gratuita en la página http://netbeans.org/, en la sección de descargas.
Nota: Se debe tener presente que a la hora de descargar Netbeans para poder ejecutar y trabajar en el proyecto, debe tener el soporte para PHP, como se muestra en la siguiente figura.
145
Instalación de Netbeans 8.0.2 Cuando NetBeans ya esté en su disco descargado, solo se debe dar doble clic sobre el ejecutable y verá el siguiente diálogo: #sudo add-apt-repository ppa:webupd8team/java Actualizamos
146
#sudo apt-get update y Procedemos a instalar:
#sudo apt-get install oracle-java8-installer
Aceptamos
147
nos pregunta si aceptamos los términos le damos click en SI y ya está ahora proseguimos con la instalación de Netbeans 8.0 Una vez hecho esto ahora estaremos seguros de que no nos fallara nada para la instalación de nuestro IDE , ya descargado nos colocamos en la carpeta Descargas (o donde hayan descargado) abrimos una terminal y digitamos lo siguiente: $cd Descargas
148
Ahora le damos permiso de ejecución : $sudo chmod +x netbeans-7.4-php-linux.sh
nos aparecerán una ventanas les damos aceptar y listo:
149
y tenemos instalado Netbeans 8.0
150
Anexo I
Manual de Usuario
Introducción
En el presente manual de usuario se indica la forma adecuada de utilizar las
posibilidades que brinda la aplicación Ixion-ud en lo que tiene que ver con la
gestión de incidentes de seguridad de la información con forme indica la norma
ISO 27035 para tal fin.
El aplicativo surge con la necesidad de brindar una opción concreta a la Oficina
Asesora de Sistemas en su búsqueda de implementar una política de seguridad y
de modular un sistema de gestión de seguridad de la información ISO 27001, para
la gestión de incidentes de seguridad de la información. Lo que implica un
procedimiento adecuado como lo indica la norma, dándole solución a los
incidentes presentados.
En el aplicativo se reportan eventos de seguridad, reportes que puede hacer
cualquier persona que haga uso de las aplicaciones de la Universidad. Y existe
varios perfiles que atiendes estos reportes por niveles dependiendo su rol.
151
1. Home IXION
Página de inicio de la aplicación donde encontrara información general
relacionada al tema concreto de seguridad de la información y sobre la universidad
ligada completamente a esta con un acceso directo a la página principal de la
universidad.
Ademes encontrar las opciones básicas y principales de la aplicación a las cuales
tiene acceso para reportar y consultar eventos.
152
2. Inicio de sesión
La vista de inicio de sesión, es la portada para el login de los usuarios ya
registrados, y que dependiendo de su perfil, muestra las opciones a las que tiene
acceso, por ejemplo, el usuario invitado puede reportar eventos, consultar eventos
e incidentes.
3. Registro en el sistema
El registro en el sistema es la vista en la que se agregan usuarios con su
respectivo perfil, a esta tiene acceso inicialmente el usuario quien va a reportar un
evento, para tener un registro de este. También el usuario administrador puede
acceder a esta vista cuando quiere agregar un usuario del sistema con perfil PoC,
ISIRT o Admin.
153
4. Reporte de eventos
En esta vista cualquier usuario puede entrar e ingresar información básica
relacionada con algún tipo de anomalía informática presentada en alguna de las
aplicaciones de la universidad.
5. Consulta de eventos e incidentes
La consulta de eventos se realiza de igual forma por todos los usuarios. Y
especialmente esta vista sirve de ayuda para los gestores tanto PoC como ISIRT
para su gestión en la atención y resolución del evento o incidente.
154
6. Clasificar incidente
La clasificación de incidente sucede cuando el evento reportado eleva su
categoría y se constituye en una probabilidad significativa de comprometer las
operaciones, es decir, afecta directamente los activos de información.
155
7. Genera informes
La gestión de incidentes de seguridad de la información llevada por la aplicación
IXION-UD es perfectamente medible dentro de un proceso de evaluación
constante y enmarcada dentro de la política de seguridad de la información de la
Universidad. Es por esto que la aplicación permite la generación de informes de la
gestión realizada, filtrando la información según como sea esta requerida.
![SEGURIDAD - sophia.javeriana.edu.co · inapropiados (ataques e incidentes) y riesgos de seguridad [1]. ... • Capacidad para desplegar en alta disponibilidad (SI o NO) • Presencia](https://static.fdocuments.ec/doc/165x107/5bdcc1d809d3f2d8568b5aba/seguridad-inapropiados-ataques-e-incidentes-y-riesgos-de-seguridad-1.jpg)
