Proyecto

PROYECTO
Desarrollo de una Propuesta Metodolgica para Determinar la Seguridad en una

Aplicacin Web

MARTHA ASCENCIO MENDOZA
PEDRO JULIN MORENO PATIO

UNIVERSIDAD TECNOLOGICA DE PEREIRA
FACULTAD DE INGENIERAS
PROGRAMA DE INGENIERA DE SISTEMAS Y COMPUTACIN
PEREIRA
2011

PROYECTO


INVESTIGACIN

UNIVERSIDAD TECNOLOGICA DE PEREIRA
FACULTAD DE INGENIERAS
PROGRAMA DE INGENIERA DE SISTEMAS Y COMPUTACIN
PEREIRA
2011

Nota aceptacin:

_____________________________
_____________________________
_____________________________
_____________________________

______________________________________
Firma Jurado

______________________________________
Firma Jurado

Pereira, 2011
1

DEDICATORIA

Para nuestras familias.

El Presente proyecto est dedicado a mi familia, mi esposo Luis Giraldo y mis hijos
Jorge Luis y Diego Alejandro Giraldo Ascencio quienes con su amor, sacrificio y
apoyo incondicional me ayudaron a culminar esta etapa en mi proyecto de vida.


A mi madre Nelly Patio Ordoez por su dedicacin y apoyo incondicional en todo
el tiempo que me dio nimos en esta etapa tan importante, a mi Padre Pedro
Pablo Moreno Moreno por siempre aconsejarme y llevarme por los buenos
caminos, a mis hermanos Juan Pablo Moreno Patio y Gessler Anderson Moreno
Patio por acompaarme para lograr esta meta.


2

AGRADECIMIENTOS

Al Decano de la Facultad de Ingenieras: EEFC, el Ingeniero Jos Gilberto Vargas
Cano y al Director del Programa de Ingeniera de Sistemas, el Ingeniero Carlos
Augusto Meneses por su orientacin y su constante apoyo a lo largo de la carrera.

Al Ingeniero Jovanny Antonio Castao Meja por inspirarnos a lo que debe ser un
Ingeniero de Sistemas, su importancia y papel en la sociedad, por su pasin y
esfuerzo al tratar de transmitir sus enseanzas y aporte al Programa de Ingeniera
de Sistemas.

Igualmente, agradezco a mis profesores de la Universidad Tecnolgica de Pereira
por su conocimiento, paciencia y ayuda para permitirnos culminar nuestro
proyecto.

3

GLOSARIO

TICs: Tecnologas de la Informacin y la Comunicacin.

APLICACIN WEB: En Ingeniera del Software una aplicacin Web es aquella que
los usuarios pueden utilizar accediendo a un servidor web a travs de un
Navegador, por lo tanto estas aplicaciones se codifican en lenguajes soportados
por el navegador, entre los lenguajes se encuentran Html, CSS, Java Script.

NAVEGADOR WEB: Es un programa que permite visualizar documentos de
hipertexto, que combinan texto, imgenes, sonido, video, animaciones, enlaces,
links o hipervnculos.

SERVIDOR WEB: Un servidor Web es un ordenador en el que se ejecuta un
programa servidor HTTP (Hypertext Transfer Protocol), por lo que puede
blicar un sitio web en
Internet, en una intranet o en una extranet
1
.

HTTP: Este es uno de los protocolos ms importantes que se utilizan dentro de
Internet es el protocolo que rige la comunicacin entre un cliente que utiliza un
navegador Web. La funcin principal de un servidor Web es poner a disposicin de
clientes pginas Web.

LENGUAJE DE PROGRAMACIN: Un lenguaje de Programacin es un idioma
artificial que permite crear programas y software.

HTML: Es un lenguaje demarcado que permite la construccin de pginas web.

VULNERABILIDAD: Es un fallo de seguridad. Es la debilidad en un sistema
permitiendo a un atacante violar la confidencialidad, integridad, disponibilidad,
control de acceso y consistencia del sistema o de sus datos o aplicaciones.

RIESGO: Se denomina riesgo a la posibilidad de que se materialice o no una
amenaza aprovechando una vulnerabilidad.

MAGERIT: Metodologa de anlisis y gestin de riesgos de los sistemas de
informacin.

AMENAZA: En sistemas de informacin una amenaza es la presencia de uno o
ms factores de diversa ndole (personas, mquinas o sucesos) que de tener la
oportunidad atacaran al sistema aprovechando el nivel de vulnerabilidad
ocasionando serios daos.

1
BROCHARD, Johnny, INTERNET INFORMATION SERVICES 6, Servidor Web
4

ATAQUE: El ataque es la materializacin de una amenaza.

IMPACTO: El impacto son las consecuencias de la materializacin de una o ms
amenazas sobre los activos, es decir son los daos causados.

ACTIVOS: Los activos son los recursos que pertenecen al sistema de informacin
o que estn relacionados con ste: Datos, Software, Hardware, Redes, Soporte
(DVD, Tarjetas de memoria, Discos duros externos), Personal.

SEGURIDAD INFORMTICA: Es la disciplina que se ocupa de disear las
normas, procedimientos, mtodos y tcnicas destinados a conseguir un sistema
de informacin seguro y confiable.

AUDITORA: Es la actividad consistente en la emisin de una opinin profesional
sobre si el objeto sometido a anlisis representa adecuadamente la realidad que
pretende reflejar o cumple con las condiciones que han sido acordadas en el nivel
de servicio
2
.

AUDITORA INFORMTICA: La auditora es un anlisis pormenorizado de un
sistema de informacin que permite descubrir, identificar y corregir
vulnerabilidades en los activos que lo componen y en los procesos que se
realizan. Su finalidad es verificar que se cumplen los objetivos de la poltica de
seguridad de la organizacin. Proporciona una imagen real y actual del estado de
seguridad de un sistema de informacin
3
.

PROTOCOLO DE SEGURIDAD: Un protocolo de seguridad es un conjunto de
programas que usan esquemas de seguridad criptogrfica
4
.

PRUEBAS DE INTRUSIN (PENTEST): Un test de penetracin es el arte de
ejecutar hacking tico donde un grupo de especialistas en seguridad de la
informacin verifican y documentan la seguridad o los controles de proteccin de
una plataforma tecnolgica con las mismas tcnicas de un hacker/cracker con el
fin de lograr comprometer a algn activo alcanzable por algn punto de la
superficie de ataque de un sistema
5
.

WEB SHELL: Aplicacin web para ejecutar comandos de sistema operativo.

FRAMEWORK: Es un entorno de trabajo que posibilita hacer las cosas
rpidamente a travs de herramientas.

2
SCHNEIDER, Ben. Outsourcing: La herramienta de gestin que revoluciona el mundo de los
negocios, Grupo EDITORIAL NORMA, Pg. 183
3
AGUILERA, Purificacin. Seguridad Informtica, EDITEX, Pg. 22
4
LPEZ BROX, Antonio. Promociones en espacios comerciales, EDITORIAL VERTICE, Pg. 395
5
MCCLURE, SM Stuart. Hackers, Secretos y soluciones para seguridad de redes , Osborne-
McGrawHill, 2001
5

PRUEBA DE CONCEPTO: La prueba de concepto refiere a una demostracin que
en principio demuestre cmo un sistema puede ser protegido o ser comprometido,
sin la necesidad de construir un equipo de trabajo completo para ese propsito
6
.

CGI: De sus siglas en Ingls Common Gateway Interface, Es una interfaz que
posibilita ejecutar solicitudes de clientes en aplicaciones externas al Servidor Web,
que por lo general estn escritas en lenguajes de scripting.

SHELL: Intrprete de comandos que posibilita el acceso a servicios del sistema
operativo.

EXPLOIT: Software creado con la finalidad de explotar y aprovechar una
vulnerabilidad hueco de seguridad.

METASPLOIT: Es un framework con un conjunto de herramientas y exploits, que
posibilitan el acceso a un sistema con vulnerabilidades o huecos de seguridad.

CONSOLA: Es una interfaz de Usuario que posibilita el uso de una Shell par a
ejecutar acciones en el sistema operativo.

COMANDO: Es un software que es ejecutado a travs de una Shell.

6
WORDLINGO, Prueba de concepto [En lnea],
<http://www.worldlingo.com/ma/enwiki/es/Proof_of_concept#In_security>, [Citado el 31 de Agosto
de 2011]
6

CONTENIDO

DEDICATORIA .....................................................................................................................................1
AGRADECIMIENTOS ..........................................................................................................................2
GLOSARIO...........................................................................................................................................3
INTRODUCCIN .................................................................................................................................8
1. TITULO .....................................................................................................................................9
2. FORMULACIN DEL PROBLEMA ...................................................................................... 10
3. JUSTIFICACION ................................................................................................................... 11
4. OBJETIVO GENERAL Y ESPECFICOS ............................................................................. 13
4.1 OBJETIVO GENERAL ...................................................................................................... 13
4.2 OBJETIVOS ESPECFICOS ............................................................................................. 13
5. MARCO REFERENCIAL ....................................................................................................... 14
5.1 MARCO TERICO ........................................................................................................... 14
5.1.1 APLICACIN WEB ............................................................................................................ 14
5.1.2 SEGURIDAD INFORMTICA ........................................................................................... 17
5.1.3 SEGURIDAD EN APLICACIONES WEB .......................................................................... 27
5.1.4 VULNERABILIDADES EN LA WEB .................................................................................. 28
5.1.5 HERRAMIENTAS DE PRUEBAS DE INTRUSIN ........................................................... 31
5.1.6 LA SERIE 27000 ............................................................................................................... 45
5.1.6.1 LA ISO 27001 ............................................................................................................ 45
5.1.7 METODOLOGA OWASP ................................................................................................. 53
5.1.8 METODOLOGA ISSAF .................................................................................................... 59
5.2 MARCO NORMATIVO ...................................................................................................... 67
5.2.1 LEY 1273 DE 2009 ............................................................................................................ 67
6. PROPUESTA METODOLGICA.......................................................................................... 68
6.1 ENFOQUE DE CAJA NEGRA .......................................................................................... 68
6.2 ENFOQUE DE CAJA BLANCA ......................................................................................... 69
6.2.1 CICLO DE DESARROLLO DEL SOFTWARE .................................................................. 70
7. RECOMENDACIONES ......................................................................................................... 73
8. CONCLUSIONES ................................................................................................................. 74
9. REFERENCIAS BIBLIOGRFICAS ..................................................................................... 75

7

TABLA DE ILUSTRACIONES

Ilustracin 1 - Arquitectura Cliente Servidor ................................ ................................ ..... 14
Ilustracin 2 - Lenguajes de Programacin Web ................................ .............................. 15
Ilustracin 3 - Funcionamiento de una Pgina Web ................................ ......................... 16
Ilustracin 4 - Seguridad Informtica ................................ ................................ ................ 17
Ilustracin 5 - Gestin de Riesgos ................................ ................................ ................... 18
Ilustracin 6 - Resumen Seguridad Informtica ................................ ............................... 26
Ilustracin 7 - Mapa de la gua para construir aplicaciones y servicios web seguros ....... 27
Ilustracin 8 - Cliente OPENVAS para buscar vulnerabilidades ................................ ...... 31
Ilustracin 9 - Cliente Nessus para buscar vulnerabilidades ................................ ............ 32
Ilustracin 10 - Escaneo de Servicios con NMAP ................................ ............................ 33
Ilustracin 11 - Escaneo de una aplicacin Web con NIKTO ................................ ........... 34
Ilustracin 12 - Ataque de Inyeccin SQL con SQLMAP ................................ .................. 35
Ilustracin 13 - Resultado del Ataque de Inyeccin SQL con SQLNINJA ......................... 36
Ilustracin 14 - Funcionamiento de ataque XSS con XSSER ................................ .......... 37
Ilustracin 15 - Parmetros necesarios para Iniciar XSSER ................................ ............ 37
Ilustracin 16 - Resultado del ataque de XSSER ................................ ............................. 38
Ilustracin 17 - Escaneo de URL con Fimap ................................ ................................ .... 39
Ilustracin 18 - Interfaz y Consola de depuracin de CSRFTESTER ............................... 40
Ilustracin 19 - Prueba de Intrusin con Owasp Mantra ................................ ................... 41
Ilustracin 20 - Estado del Escaneo, Owasp Mantra ................................ ........................ 41
Ilustracin 21 - Escaneo con Websecurify ................................ ................................ ....... 42
Ilustracin 22 - Reporte Websecurify ................................ ................................ ............... 43
Ilustracin 23 - Herramientas Backtrack ................................ ................................ .......... 44
Ilustracin 24 - Histrico de la ISO 27001 ................................ ................................ ........ 46
Ilustracin 25 - Modelo de Proceso PDCA ................................ ................................ ....... 47
Ilustracin 26 - Etapa de Planeacin................................ ................................ ................ 48
Ilustracin 27 - Etapa de Implementacin ................................ ................................ ........ 50
Ilustracin 28 - Etapa de Seguimiento ................................ ................................ ............. 51
Ilustracin 29 - Etapa de Mejora Continua ................................ ................................ ....... 52
Ilustracin 30 - Incremento de los costes de reparar bugs de seguridad en el SDLC ...... 53
Ilustracin 31 - Flujo de trabajo de la Metodologa OWASP ................................ ............. 58
Ilustracin 32 - Metodologa ISSAF ................................ ................................ ................. 60
Ilustracin 33 - Propuesta Metodolgica ................................ ................................ .......... 72

8

INTRODUCCIN

La informacin es el activo ms importante para toda organizacin, asegurarla trae
beneficios y credibilidad para ella, entonces cabe preguntarnos Dnde se
encuentra la informacin o qu la manipula?. Es esencial saber que hoy en da la
informacin se encuentra en una aplicacin software, pero es muy importante
conocer que el auge de las TICs y el Cloud Computing ha llevado a adquirir o
desarrollar aplicaciones orientadas a la Web.

Por esto debemos preguntarnos Est la informacin segura?, por lo tanto no
podemos dejar de hablar de la seguridad en aplicaciones Web, ya que a partir de
ellas podemos obtener informacin. Ofrecer una propuesta metodolgica para
determinar la seguridad en una aplicacin web puede ser de gran utilidad.

La propuesta metodolgica incluye componentes del estndar ISO 27001 y de
metodologas existentes, tales como OWASP e ISSAF.

Para hablar de seguridad de la informacin, no s puede dejar de hablar de ISO
27001, debido a que es el estndar de facto para la seguridad en la informacin,
que ofrece un modelo para el establecimiento, implementacin, operacin,
monitorizacin, revisin, mantenimiento y mejoras de todos los procesos que
involucran la seguridad de la informacin en una organizacin por medio del
Sistema de Gestin de la Seguridad de la Informacin (SGSI).

OWASP es una metodologa que tiene en cuenta la seguridad en el ciclo de
desarrollo del software (SDLC). Por otro lado, ISSAF es una metodologa para
pruebas de intrusin en un sistema informtico.

Los captulos 1 al 4 contienen el titulo, formulacin del problema, justificacin y
objetivos respectivamente. En el captulo 5 se abordan los conceptos tericos que
sirven de base para la elaboracin de la propuesta, entre ellos se tiene aplicacin
Web, Seguridad Informtica, Seguridad en aplicaciones Web, Vulnerabilidades en
la Web, Herramientas de pruebas de Intrusin, ISO 27001, Metodologa OWASP e
ISSAF.

En el captulo 6 se presenta una propuesta metodolgica para determinar la
seguridad en una aplicacin web bajo dos enfoques, el de caja negra y caja
blanca. Los ltimos tres captulos contienen las recomendaciones, las
conclusiones y la bibliografa respectivamente.

9

1. TITULO

Desarrollo de una propuesta metodolgica para determinar la seguridad en una
aplicacin web.

10

2. FORMULACIN DEL PROBLEMA

Durante aos las aplicaciones web han sido vulneradas, permitiendo que agentes
no autorizados tengan acceso a datos confidenciales y causando prdida de
informacin. Colombia es el cuarto pas ms vulnerable de Amrica Latina luego
de Brasil, Mxico y Venezuela
7
.

Este siglo ha sido catalogado como el siglo de la informacin
8
, por lo tanto son los
datos y la informacin los que generan el activo ms importante, de manera que
ofrecer una aplicacin web con altos niveles de seguridad, integridad y
confiabilidad, es vital para las operaciones de cualquier negocio
9
.

Otro de los factores que infieren en esta problemtica es la falta de garanta a
nivel empresarial respecto a la seguridad de los datos y aplicaciones.
Aproximadamente el 60% de las empresas, no cuentan con una estrategia
documentada de la seguridad en la informacin, y adems solo el 28% tienen
considerados los riesgos en sus planes de accin
10
.

La seguridad informtica en aplicaciones Web se ha convertido en un tema de
importancia, vislumbrado a travs de las cifras considerables que estn invirtiendo
las empresas para contrarrestar y prevenir los ataques a los que estn expuestas,
siendo vulnerables a muchos de estos riesgos.

Cabe entonces, preguntarse, s desarrollar una propuesta metodolgica para
determinar el nivel de seguridad informtica en las empresas , servir como gua
para adoptar mecanismos de proteccin y poder contar con un conjunto de
recomendaciones que las orienten como parte de la estrategia de seguridad?.

7
FEDESOFT, Colombia es el cuarto pas ms vulnerable de Amrica Latina en seguridad
informtica [En lnea], <http://www.fedesoft.org/noticiastic/colombia-es-el-cuarto-pais-mas-
vulnerable-de-america-latina-en-seguridad-informatica>, [Citado el 31 de Agosto de 2011]
8
Stuart McClure, SM, Hackers, Secretos y soluciones para seguridad de redes, Osborne-
McGrawHill, 2001
9
UNIVERSIDAD AUTNOMA DEL CARIBE, Test de penetracin como apoyo a la evaluacin
de riesgos en seguridad de la informacin [En lnea],
<http://www.uac.edu.co/images/stories/publicaciones/revistas_cientificas/prospectiva/volumen-7-
no-1/articulo5-v7n1.pdf>, [Citado el 31 de Agosto de 2011]
10
FEDESOFT, 60% de las empresas no tienen estrategia de seguridad [En lnea],
<http://www.fedesoft.org/noticiastic/60-de-las-empresas-no-tienen-estrategia-de-seguridad>,
[Citado el 31 de Agosto de 2011]
11

3. JUSTIFICACION

Las TICs, (Tecnologas de Informacin y Comunicacin), especialmente el Internet
han abierto un sin nmero de posibilidades de acceso a la informacin y de igual
manera se han generado nuevos riesgos que involucran la seguridad de la misma.
Este es un momento crtico de cambio, pues hay una gran apertura en las
comunicaciones y las posibilidades para compartir informacin en internet
demandan ms seguridad para cada accin que se tome
11
.

En este contexto, los ejercicios de riesgos y controles propios de las empresas,
para establecer y analizar los activos de informacin, han dejado de que
para transformarse da a da en una disciplina que adopta
la organizacin, para lograr como parte de su gestin, que la informacin sea una
ventaja clave y competitiva frente a su entorno de negocio
12
.

Actualmente, con el auge del Cloud Computing todo el desarrollo de apl icaciones
est siendo orientada a la web, lo cual conlleva una gran responsabilidad por
parte de los desarrolladores y proveedores de servicios en internet.

Una aplicacin web con altos niveles de seguridad, es un elemento diferenciador,
generador de confianza y valor para la empresa, sus clientes y grupos de inters.
Las empresas en Latinoamrica cada vez ms encuentran en la seguri dad de la
informacin una forma para marcar la diferencia como socio estratgico del
negocio
13
.

Adems la continua evolucin de las TICs exige que los nuevos ingenieros se
adapten rpido a los cambios, a las tendencias del mercado y propone el
planteamiento de nuevas soluciones. Para esto es vital contar con herramientas
robustas para revisar el nivel de calidad y seguridad de las aplicaciones,
generando por consiguiente nuevas oportunidades de trabajo en un rea que
continuamente exige la participacin de profesionales en seguridad informtica
14
.

11
AMRTEGUI T. Diego J., Ciberseguridad y Ciberterrorismo [En lnea],
<http://www.acis.org.co/fileadmin/Revista_119/Informe_Diego_Amortegui.pdf>, [Citado el 02 de
Septiembre de 2011]
12
CANO Jeimy J., Ciberseguridad y ciberdefensa: Dos tendencias emergentes en un contexto
global [En lnea], <http://www.acis.org.co/fileadmin/Revista_119/Editorial.pdf>, [Citado el 02 de
Septiembre de 2011]
13
ASOCIACIN DE INGENIEROS DE SISTEMAS, Seguridad de la informacin en Latinoamrica,
Tendencias 2011 [En lnea],
<http://www.acis.org.co/fileadmin/Revista_119/Informe_Latinoamerica_2011.pdf>, [Citado el 02 de
Septiembre de 2011]
14
ASOCIACIN DE INGENIEROS DE SISTEMAS, Seguridad de la informacin en Latinoamrica,
Tendencias 2011 [En lnea],
<http://www.acis.org.co/fileadmin/Revista_119/Informe_Latinoamerica_2011.pdf>, [Citado el 02 de
Septiembre de 2011]
12

Este proyecto busca obtener una metodologa que pueda brindar beneficios tales
como:

Para las empresas que tienen presencia en la web, una herramienta
metodolgica que le permitir determinar que vulnerabilidades posee la
aplicacin web.

Para los Ingenieros de sistemas y auditores de Sistemas, una
herramienta til para su trabajo que lo mantendr a la vanguardia de las
nuevas exigencias del mercado.

Para la academia, un punto de partida que enriquecer el contenido del
rea de Auditoria de Sistemas.

13

4. OBJETIVO GENERAL Y ESPECFICOS

4.1 OBJETIVO GENERAL

Desarrollar una propuesta metodolgica para determinar la seguridad en una
aplicacin web.
4.2 OBJETIVOS ESPECFICOS

Analizar los conceptos y fundamentos de seguridad en aplicaciones web.

Determinar los tipos de vulnerabilidades en las aplicaciones web.

Determinar que herramientas existen actualmente para deteccin de
vulnerabilidades en aplicaciones web.

Determinar las caractersticas principales de algunas metodologas existentes
para la seguridad en aplicaciones web.

Documentar la propuesta metodolgica para determinar la seguridad en una
aplicacin web.

14

5. MARCO REFERENCIAL

5.1 MARCO TERICO

5.1.1 APLICACIN WEB

En Inge
acceso a travs de un navegador Web sobre una red, ya sea Internet o una
Intranet. Es de agregar que las aplicaciones web son codificadas en un lenguaje
soportado por un navegador (Mozilla Firefox, Google Chrome, Internet Explorer,
entre otros).

Una Aplicacin Web es un tipo especial de aplicacin Cliente/Servidor, en el que el
Cliente (Navegador Web), el Servidor (Servidor Web) y el Protocolo (HTTP) canal
de comunicacin estn estandarizados y no es creado por el programador de
aplicaciones
15
.

Ilustracin 1 - Arquitectura Cliente Servidor
16

El Cliente, gestiona las peticiones del usuario y la recepcin de las pginas que
provienen del servidor, igualmente, interpreta los documentos HTML y sus
recursos.
El Servidor, es el programa residente que espera peticiones: demonio (Daemon)
en Unix y Servicio en servidores de Microsoft. En el servidor se encuentran

15
Lujn Mora Sergio, Programacin en Internet: Clientes Web, Editorial Club Universitario, Pg. 8
16
Ingeniera de Requerimientos, Arquitectura de Tres Capas [En lnea], <http://proy-
pnfi.foroactivo.net/search.forum?search_author=Admin&show_results=posts>, [Citado el 5 de
Septiembre de 2011]
15

pginas estticas, Scripts o programas que al ser invocados se ejecutan y dan
como resultado una pgina HTML
17
.
Actualmente existen diferentes lenguajes de programacin para hacer desarrollos
en la web, estos han ido surgiendo de acuerdo a las tendencias y necesidades de
las plataformas. En el inicio del Internet las aplicaciones web creadas fueron
realizadas mediantes lenguajes estticos, posteriormente con el desarrollo y el
avance de nuevas tecnologas surgen nuevas necesidades que dio lugar al
desarrollo de Lenguajes Dinmicos de Programacin que utilizan Bases de Datos
y permiten interactuar con los usuarios.
LENGUAJES WEB
18

En programacin un lenguaje es un conjunto de smbolos y reglas que permiten
desarrollar programas definiendo su estructura, expresiones y significado de sus
elementos. Esto sin lugar a dudas permite facilitar la tarea de programacin, ya
que posibilita ser ledos y escritos por personas representando los cdigos de
manera simblica.

Ilustracin 2 - Lenguajes de Programacin Web
HTML: Es el lenguaje de marcado predominante para la construccin de pginas
web. Es usado para describir la estructura y el contenido en forma de texto, as
como para complementar el texto con objetos tales como imgenes
19
.
JavaScript: Es un lenguaje de scripting orientado a objetos utilizado para acceder
a objetos en aplicaciones. Se utiliza principalmente, integrado en un navegador

17
Universidad de Alicante, Qu es una aplicacin Web [En lnea],
<http://rua.ua.es/dspace/bitstream/10045/4412/5/03c-AplicacionesWeb.pdf>, [Citado el 5 de
Septiembre de 2011]
18
Wikispaces,

Lenguajes de Programacin [En lnea],
<http://cervantes1bachdyg.wikispaces.com/lenguajes_programacion>, [Citado el 5 de Septiembre
de 2011]
19
CODEBOX, Glosario [En lnea], <http://www.codebox.es/glosario>, [Citado el 5 de Septiembre de
2011]
16

web permitiendo el desarrollo de interfaces de usuario mejoradas y pginas web
dinmicas
20
.

PHP: Es un lenguaje de programacin utilizado para la creacin del sitio web.
PHP es un lenguaje de script interpretado en el lado del servidor utilizado para la
generacin de pginas web dinmicas, embebidas en pginas HTML y ejecutadas
en el servidor. PHP no necesita ser compilado para ejecutarse. Para su
funcionamiento necesita tener instalado Apache con las libreras de PHP. La
mayor parte de su sintaxis ha sido tomada de C, Java y Perl con algunas
caractersticas especficas
21
.

Python: Es lenguaje de programacin que busca principalmente la facilidad para
hacer las cosas, este no maneja tipos (lo hace automticamente), lo cual facilita la
vida al programador, adems el cdigo no es compilado sino interpretado.

En el siguiente grfico se explica cmo funciona una aplicacin web. De manera
general, el cliente hace una solicitud al Servidor Web y ste la procesa,
entregndole cdigo HTML, ste puede ser esttico (No se genera el cdigo
HTML desde un lenguaje de programacin sino que directamente se entrega ste)
dinmico (generado a travs de lenguajes de programacin web como JAVA,
ASP.NET, PHP, entre otros), luego el cdigo HTML es interpretado por el cliente
(navegador Web) y es mostrado de manera amigable al Usuario Final.

Ilustracin 3 - Funcionamiento de una Pgina Web
22

20
PORTAL HACKER, Programacin en General [En lnea],
<http://www.portalhacker.net/index.php/topic,115175.0/wap2.html>, [Citado el 6 de Septiembre de
2011]
21
New Web Star, Los diferentes lenguajes de programacin para la web [En lnea],
<http://www.newwebstar.com/ebooks/133193-los-diferentes-lenguajes-de-programaciun-para-
la.html>, [Citado el 6 de Septiembre de 2011]
22
Ingeniera de Requerimientos, Arquitectura de Software [En lnea], <http://proy-
pnfi.foroactivo.net/search.forum?search_author=Admin&show_results=posts>, [Citado el 7 de
Septiembre de 2011]
17

5.1.2 SEGURIDAD INFORMTICA

El objetivo de la seguridad informtica ser mantener la integridad, disponibilidad,
privacidad (sus aspectos fundamentales), control y autenticidad de la informacin
manejada por computadora
23
.

Ilustracin 4 - Seguridad Informtica
24

As pues, la seguridad Informtica no es otra cosa que la capacidad de
salvaguardar intacta y protegida la informacin en un sistema informtico. Sin
embargo, la seguridad Informtica abarca mucho ms que la proteccin de la
informacin, pero sin duda es sta el activo ms atractivo para los hackers,
teniendo en cuenta que la informacin es la base econmica de las empresas.

La Seguridad Informtica se basa en tres principios fundamentales:

Confidencialidad
Integridad
Disponibilidad

La confidencialidad es la seguridad de que los datos no son vistos por personas
ajenas a la organizacin y que no tienen permiso para ello. As pues, para
controlar la confidencialidad de los datos se requiere la verificacin y autorizacin.

23
ALDEGANI, Gustavo. Miguel. Seguridad Informtica. MP EDICIONES. ARGENTINA. 1997. Pg.
22
24
SOFTTRON NET, Seguridad Informtica [En lnea],
<http://www.softtron.net/002/index.php/seguridad>, [Citado el 7 de Septiembre de 2011]
18

La Integridad se centra en que la informacin no sea manipulada, alterada o
cambiada por el sistema que la almacena o por entes externos no autorizados.
Para mantener la Integridad de la informacin entre quien enva y quien recibe, se
emplean tcnicas criptogrficas de cifrado que aseguran que la informacin no es
modificada
25
.

La Disponibilidad, segn el Programa MAGERIT, es el grado en que la informacin
est en el lugar, momento y forma en que es requerido por personal autorizado,
es decir, un sistema seguro debe mantener la informacin disponible para los
usuarios que la requieran.

Un posible mtodo de ataque a un sistema informtico es la denegacin de
servicio, que es lo opuesto a la disponibilidad, esto significa que el usuario no
puede obtener del sistema los recursos requeridos
26
.

5.1.2.1 GESTIN DE RIESGO EN LA SEGURIDAD INFORMTICA
27

La Gestin de Riesgo es un mtodo para determinar, analizar, valorar y clasificar
el riesgo para posteriormente implementar mecanismos que permitan controlarlo.
La Gestin de Riesgo se divide en cuatro fases, Anlisis, Clasificacin, Reduccin
y Control, las cuales se citan a continuacin:

Ilustracin 5 - Gestin de Riesgos

25
ASENSIO, Gonzalo. Seguridad en Internet, EDITORIAL NOWTILUS, Pg. 15.
26
AGUILERA, Purificacin. Seguridad Informtica, EDITORIAL EDITEX, Pg. 11.
27
ERB, Markus, Gestin de Riesgo en la Seguridad Informtica [En lnea],
<http://protejete.wordpress.com/gestion_rieso/gestion_riesgo_si/>, [Citado el 7 de Septiembre de
2011]
19

Anlisis: En la fase de anlisis se determina los componentes del sistema
que requieren proteccin, las vulnerabilidades que lo debilitan y las
amenazas que lo ponen en peligro, con el objetivo de revelar su grado de
riesgo. Por lo tanto al identificar las vulnerabilidades y las amenazas del
sistema, permitir conocer los riesgos potenciales que atentan la seguridad
del sistema.

Clasificacin: En la fase de Clasificacin se determina si los riesgos
encontrados y los riesgos restantes son aceptables.

Reduccin: En la fase de Reduccin se define e implementa las medidas de
proteccin y de igual forma se sensibiliza y capacita a los usuarios
conforme a las necesidades.

Control: En la fase de Control se analiza el funcionamiento, la efectividad y
el cumplimiento de las medidas y si es el caso ajustarlas.

5.1.2.2 ANALISIS DE RIESGOS
28

Cuando se quiere dotar de seguridad a un sistema informtico es necesario
determinar los elementos o activos que requieren proteccin, identificar el nivel de
vulnerabilidad de cada uno frente a determinadas amenazas y valorar el impacto
que un ataque ocasionara sobre el sistema informtico.

Los activos son los recursos que pertenecen al sistema de informacin, se pueden
clasificar en:

Datos: Los datos son el ncleo (core) de la organizacin, toda empresa u
organizacin depende de sus datos y stos pueden ser: Econmicos,
fiscales, recurso humano, clientes o proveedores.

Software: Son el conjunto de aplicaciones instaladas que se encuentran en
los equipos, que hacen parte del sistema de informacin, estas
aplicaciones reciben, gestionan o transforman los datos.

Hardware: Conjunto de equipos (Servidores y Terminales) que contienen
las aplicaciones y permiten su funcionamiento, de igual manera almacenan
los datos del sistema de informacin.

Redes: Representa la va de comunicacin y transmisin de datos.

28
AGUILERA, Purificacin. Seguridad Informtica, EDITORIAL EDITEX, Pg. 12-27.
20

Soportes: Son los lugares donde la informacin queda registrada y
almacenada durante un periodo de tiempo o de manera permanente:
Tarjetas de memoria, Discos duros, DVD, CD.

Personal: Est conformado por las personas que interactan con el sistema
de informacin: Programadores, Administradores, Usuarios internos y
externos. Estudios calculan que se producen ms fallos de seguridad por
intervencin humana que por los fallos de software.

AMENAZAS

Una amenaza es la presencia de uno o ms factores (Personas, mquinas o
sucesos) que de tener la oportunidad atacan al sistema aprovechando el nivel de
vulnerabilidad y causando daos sustanciales.

Existen diferentes tipos de amenazas que pueden afectar el sistema, entre las
cuales se encuentran las amenazas fsicas, ambientales, software malicioso, robo,
destruccin o modificacin de la informacin, errores intencionados o no de los
usuarios, entre otros.

Segn el origen las amenazas se clasifican en:

Accidentales: Las amenazas pueden ser incendios, inundaciones, fallos en
los equipos, en redes, sistemas operativos o en software, errores humanos.

Intencionadas: Las amenazas intencionadas son debidas a la accin
humana, ejemplo de ello son la inyeccin de software malicioso, intrusin
informtica, robo o hurto. Este tipo de amenaza puede ser originada desde
fuera de la empresa o dentro de la misma organizacin.

Segn el dao o intervencin las amenazas se pueden clasificar en 4 grupos:
Interrupcin, interceptacin, Modificacin y Fabricacin.

Interrupcin: El objetivo de sta amenaza es deshabilitar el acceso a la
informacin. Esta amenaza se puede llevar a cabo destruyendo
componentes fsicos como el disco duro, saturando los canales de
comunicacin o bloqueando el acceso a los datos.

Interceptacin: La Interceptacin es el acceso no autorizado a un
determinado recurso del sistema con el objetivo de captar informacin
confidencial de la organizacin.

21

Modificacin: Esta amenaza no solo accede a la informacin sino que
adems la modifica.

Fabricacin: Esta amenaza agrega informacin falsa en el conjunto de
informacin del sistema.

Para poder realizar un anlisis de riesgo en un sistema de informacin es
necesario:

i. Ejecutar un proceso secuencial de anlisis de activos.
ii. Identificar las vulnerabilidades.
iii. Identificar y valorar las amenazas.
iv. Identificar las medidas de seguridad existentes.
v. Identificar los objetivos de seguridad de la informacin en la organizacin.
vi. Determinar la medicin de los riesgos, el impacto del ataque.
vii. Seleccionar las medidas de proteccin.

5.1.2.3 CONTROL DE RIESGOS

Luego de realizar un anlisis de los riesgos es necesario determinar qu servicios
posee el sistema de informacin y cuales quedan al descubierto para
posteriormente aplicar mecanismos de seguridad que permitan dotar al sistema de
elementos suficientes para cumplir con los objetivos de la organizacin.

5.1.2.3.1 Servicios de Seguridad

Entre los servicios de seguridad se encuentran:

Integridad: La integridad asegura que los datos del sistema de informacin
no han sido alterados por personas no autorizadas y el contenido de los
mensajes recibidos es el correcto.

Confidencialidad: La confidencialidad por su parte proporciona proteccin
contra la revelacin voluntaria o accidental de los datos en una
comunicacin.

Disponibilidad: La disponibilidad permite que la informacin est
disponible cuando la requiera personal autorizado.

Autenticacin: La autenticacin se refiere a que el sistema debe ser capaz
de verificar que un usuario identificado que accede a un sistema de
informacin es efectivamente quien dice ser.
22

No repudio: El no repudio consiste en no poder negar haber emitido una
informacin que s se emiti y en no poder negar su recepcin, cuando s
fue recibida.

Control de acceso: En el control de acceso solo podrn acceder a
recursos del sistema usuarios con autorizacin.

5.1.2.3.2 Mecanismos De Seguridad

Los mecanismos de seguridad se clasifican segn la funcin que desempeen,
estos pueden ser Preventivos, Detectores o Correctores.

Preventivos: Los mecanismos preventivos actan antes de que se
produzca un ataque, su misin principal es evitar el ataque.

Detectores: Los mecanismos detectores actan cuando el ataque se ha
efectuado y antes de que ste cause daos en el sistema.

Correctores: Los mecanismos correctores actan despus de que se ha
presentado un ataque y se haya producido daos. Su principal objetivo es
el de corregir las consecuencias del dao.

Existen otros mecanismos de seguridad que dependen del sistema de
informacin, de su funcin y de los riesgos a los que se expone el sistema, entre
los cuales se encuentran los mecanismos de seguridad fsicos y lgicos.

Los Mecanismos de Seguridad Fsicos y Lgicos tienen como misin prevenir,
detectar o corregir ataques al sistema, asegurando que los servicios de seguridad
queden cubiertos.

a) Seguridad Fsica: Su objetivo es proteger al sistema de peligros fsicos y
lgicos. Un ejemplo de ellos son los dispositivos fsicos de proteccin como
los pararrayos, detectores de humo, cortafuegos por hardware, etc. Y por
otro lado se encuentran las copias de respaldo o copias de seguridad de la
informacin.

b) Seguridad Lgica: Su principal objetivo es proteger digitalmente la
informacin. A continuacin se citan algunos de ellos:

Control de acceso: Utilizando nombres de usuario y contrasea.

23

Cifrado de datos: Los datos se enmascaran utilizando algoritmos de
encriptacin. Fortalece la confidencialidad.

Antivirus: Estos detectan e impiden la entrada de virus y software
malicioso. Protege la integridad de la informacin.

Cortafuegos: Los cortafuegos son dispositivos de software, hardware
o mixtos que restringen el acceso al sistema. Protege la integridad
de la informacin.

Firma digital: Es utilizada para la transmisin de mensajes
telemticos y en la gestin de documentos electrnicos. Protege la
integridad y confidencialidad de la informacin.

Certificados digitales: Son documentos digitales que garantizan que
una persona es quien dice ser. Protege la Integridad y
confidencialidad de la informacin.

Las redes inalmbricas necesitan precauciones adicionales tales como el
usar un SSID (Service Set Identifier) que no es otra cosa que darle un
nombre a la red, preferiblemente un nombre que no llame mucho la
atencin. Otra precaucin es proteger la red mediante claves encriptadas
WPA (Wifi Protected Access). Y por ltimo el Filtrado de direcciones MAC
(Media Access Control), este es un mecanismo de acceso al sistema
mediante hardware, el cual solo admite determinadas direcciones.

5.1.2.4 HERRAMIENTA DE ANLISIS Y GESTIN DE RIESGOS

Los objetivos y normas de seguridad estn recopilados en las Polticas de
seguridad de cualquier organizacin.

5.1.2.4.1 Poltica de Seguridad

La poltica de seguridad recopila los objetivos de la organizacin en materia de
seguridad del sistema de informacin, los cuales se encuentran categorizados en
cuatro grupos.

a) El primero de ellos es identificar las necesidades de seguridad y los riesgos
que amenazan el sistema de informacin y de igual forma evaluar el
impacto frente a un eventual ataque.

24

b) Tomar todas las medidas de seguridad que deban implementarse para
afrontar los riesgos de cada activo.

c) Determinar las reglas y los procedimientos que deben aplicarse para
afrontar los riegos.

d) Detectar todas las vulnerabilidades del sistema de informacin y controlar
los fallos que se producen en los activos.

e) Por ltimo definir un plan de contingencia.

5.1.2.4.2 Auditora

La Auditora es un examen minucioso de un sistema de informacin, que permite
identificar y corregir vulnerabilidades en los activos que lo conforman y en los
procesos que se realizan.

La finalidad de la Auditora es verificar que se cumplan los objetivos de la Poltica
de Seguridad de la organizacin, as pues proporciona una imagen real y actual
del estado de seguridad de un sistema de informacin.

Luego de realizar una Auditora, es decir, de realizar un anlisis e identificar
vulnerabilidades, el Auditor elabora un informe que debe contener una descripcin
de los activos y procesos analizados, una evaluacin de las vulnerabilidades
detectadas, una verificacin del cumplimiento de la normatividad y una propuesta
de medidas preventivas y correctivas.

Existen herramientas para evaluar la seguridad en un sistema de informacin,
stas pueden ser manuales o software especfico para auditora. Con respecto a
las Manuales, stas pueden ser por observacin directa de los activos,
mediciones, cuestionarios, entrevistas, pruebas de funcionamientos entre otras. La
herramienta de software de Auditora se le conoce por las siglas CAAT (Computer
Assisted Audit Techniques), stas ayudan a mejorar la eficiencia de una Auditora,
ya que proporcionan una imagen total o parcial en tiempo real de un sistema de
informacin emitiendo luego un informe de las vulnerabilidades encontradas.

5.1.2.4.3 Plan de Contingencia

El Plan de Contingencia contiene las medidas preventivas y de recuperacin frente
a cualquier tipo de amenaza. Estas pueden ser de tres tipos:

25

Plan de Respaldo: En el plan de respaldo se aplican medidas preventivas
ante cualquier amenaza para evitar que se produzcan daos. Por ejemplo,
Copias de respaldo.

Plan de Emergencia: En el plan de emergencia se determina qu medidas
tomar cuando se est materializando una amenaza o cuando acaba de
producirse. Por ejemplo, restaurar las copias de seguridad.

Plan de Recuperacin: En el plan de recuperacin se indican las medidas
que se aplicarn cuando se ha producido un desastre. El objetivo principal
es evaluar el impacto y regresar a un estado normal de funcionamiento del
sistema.

5.1.2.4.4 Modelos de Seguridad

Un modelo de seguridad es la expresin formal de una poltica de seguridad y se
utiliza como directriz para evaluar los sistemas de informacin. Los modelos de
seguridad se pueden clasificar en tres grupos:

a) Matriz de acceso. Considera tres elementos bsicos: el sujeto, objeto y tipo
de acceso, es decir, un sujeto tiene o no permisos de acceso a un objeto
del sistema. De esta manera se controla la integridad y confidencialidad de
los datos.

b) Acceso basado en funciones de control (RBAC Role Access Base Control):
en este caso el acceso no se define en funcin de quin es el sujeto sino de
qu funcin tiene. Este modelo controla la confidencialidad y la integridad
de los datos.

c) Multinivel. Se basa en la jerarquizacin de los datos, es decir, todos los
datos son importantes, pero unos son ms privados que otros.

26

El siguiente mapa conceptual resume a groso modo la Seguridad Informtica:

Ilustracin 6 - Resumen Seguridad Informtica

27

5.1.3 SEGURIDAD EN APLICACIONES WEB
29

La organizacin Open Web Application Security Project (OWASP) elabor una
gua para construir Aplicaciones Web Seguras y Servicios Web Seguros. Esta gua
toma en cuenta desde las vulnerabilidades ms antiguas como la Inyeccin SQL,
hasta las ms actuales como suplantacin de identidad, sesiones, el cumplimiento
de reglas y cuestiones de privacidad. Esto con el objetivo de ayudar a los
desarrolladores, revisores de cdigo, arquitectos de Software, entre otros, a tener
pautas para evitar stos problemas en el desarrollo, como otros mecanismos para
hacer de las aplicaciones web ms seguras.

Principalmente la gua tiene en cuenta seguridad en aplicaciones Web y servicios,
con ejemplos en los lenguajes de programacin: J2EE, ASP.NET, PHP.

La gua para construir Aplicaciones y servicios Web Seguros est compuesta por
los siguientes tems:

Ilustracin 7 - Mapa de la gua para construir aplicaciones y servicios web seguros

29
OWASP Foundation, gua para construir aplicaciones y servicios web seguros [En lnea],
<https://www.owasp.org/images/b/b2/OWASP_Development_Guide_2.0.1_Spanish.pdf>, [Citado el
12 de Septiembre de 2011]
28

5.1.4 VULNERABILIDADES EN LA WEB
30

Son todos aquellos problemas de seguridad que afectan las pginas web, por lo
general estos problemas permiten modificacin y extraccin de la informacin, lo
cual es muy grave para las organizaciones la mayora de stos son registrados
por medio de un identificador de CVE (Common Vulnerabilty Exposure), l cual es
un diccionario de los problemas de seguridad encontrados en la Internet.

A continuacin se hablar de algunas de ellas:

a) CROSS SITE SCRIPTING (XSS):

Es una tcnica Hacking que permite a un atacante explotar vulnerabilidades en
aplicaciones web e inyectar scripts del lado del cliente en stas. Un ataque exitoso
puede permitir al atacante secuestrar sesiones de usuario, robar informacin
sensible o cambiar informacin en el sitio web.

Hay dos tipos principales de XSS:

No persistente reflejado
Persistente almacenado
El no persistente reflejado. Este ataque es uno de los ms comunes, la raz de
la vulnerabilidad es el manejo inapropiado (falta de validacin) de solicitudes de
datos HTTP por el cdigo del servidor, permitiendo a los sitios maliciosos reflejar
cdigo malicioso y atacar a otros usuarios. El principal vector de ataque es
usualmente un mensaje de correo que contiene una URL maliciosa, cuando el
usuario da clic en la URL, el cdigo malicioso es ejecutado. Esta vulnerabilidad
aprovecha el concepto de arquitectura cliente servidor (Servidor WEB
Navegador Web), el navegador ejecuta el cdigo porque cree que es el cdigo
original y no uno alterado.

El persistente o almacenado. Este ataque no requiere usuarios que den clic en
una URL con el fin de ejecutar cdigo malicioso. En este caso el cdigo es capaz
de vivir en el servidor vulnerable y est embebido en el cdigo HTML. Una vez
ms, este tipo de ataque es el resultado directo de validaciones pobres en el lado
del servidor, lo que permite forzar entradas maliciosas que pueden ser mostradas
en el sitio web. Este tipo de ataque es particularmente riesgoso, no solo porque no
requiere una intervencin directa del usuario sino porque tiene un alcance global
ms peligroso.

30
HP DVLabs, The 2011 Mid-Year top cyber security risks report [En lnea],
<http://www.hpenterprisesecurity.com/collateral/report/CyberSecurityRisksReport.pdf>, [Citado el
29

b) INYECCIN DE CDIGO SQL (SQL Injection):

Esta vulnerabilidad surge de las malas prcticas de programacin en las
solicitudes HTTP (POST y GETs), as un atacante aprovecha el mal manejo de
stas, inyectando cdigo SQL adicional, por ejemplo:

consultas SQL y el atacante
puede aprovecharse para modificar la consulta y sacar informacin.

c) EJECUCIN DE COMANDOS (Command Execution):

Este tipo de vulnerabilidad toma ventaja de la falta de validacin en las entradas
en un sitio web, donde el atacante puede correr comandos del sistema operativo
en la aplicacin web vulnerada. Generalmente, esta vulnerabilidad permite
aprovechar, que los datos de usuario son pasados como parmetros a
operaciones de entrada y salida, para as aadir comandos de sistema operativo
por medio de caracteres especiales como pipe (|).

d) DESBORDAMIENTO DE BUFFER (Buffer Overflow):

Es un ataque que ocurre cuando un usuario malicioso sobrecarga la memoria del
sistema temporal (llamada buffer) para causar estragos en la mquina de la
vctima. A menudo, los atacantes tambin incluyen cdigo de instruccin para
aprovechar ms la vulnerabilidad, como por ejemplo ejecutar cdigo malicioso,
acceder o modificar datos confidenciales o incluso enviar informacin al atacante.

e) DENEGACIN DE SERVICIO (DoS):

Es un tipo de vulnerabilidad que permite a un atacante agotar los recursos
informticos de un sistema, por medio de millones de solicitudes, agotando
recursos como CPU, Memoria, acceso a la red, que imposibilitan el acceso a dicho
sistema.

Este ataque tiene una variante llamada Ataque de Denegacin de Servicio
Distribuido (DDoS), en el cual varios computadores infectados con virus atacan el
servidor objetivo desde muchos lugares.

30

f) CROSS-SITE REQUEST FORGERY (CSRF
31
):

Es un ataque que fuerza a la victima a cargar una pgina que contiene una
solicitud maliciosa, es maliciosa en el sentido en que hereda la identidad y
privilegios de la victima para ejecutar acciones no deseadas en ella, como por
ejemplo, cambiar la direccin de correo de la vctima, la direccin del hogar, o la
contrasea.

g) INCLUSIN REMOTA DE ARCHIVOS (Remote File Inclusion
32
):

libreras
por ejemplo:

$incfile = $_REQUEST["pag"]
include($incfile.".php")

Si observamos desde la URL: http://ejemplo.com/?pag=pagina1.php

El valor asignado a pag es pagina1.php, pero imaginemos si en lugar de
pagina1.php hubiera un link hacia otro sitio que tenga una web Shell, algo como:

http://ejemplo.com/?pag=www.shellremota.com

Lo cual posibilitara la ejecucin de comandos, modificacin del sitio, entre otros.

31
OWASP Foundation, Cross-Site Request Forgery (CSRF) [En lnea],
<https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)>, [Citado el 13 de
Septiembre de 2011]
32
The Web Application Security Consortium, Remote File Inclusion [En lnea],
<http://projects.webappsec.org/w/page/13246955/Remote%20File%20Inclusion>, [Citado el 13 de
Septiembre de 2011]
31

5.1.5 HERRAMIENTAS DE PRUEBAS DE INTRUSIN

5.1.5.1 HERRAMIENTAS DE ANALISIS DE SISTEMA OPERATIVO Y
SERVICIOS

a) OPENVAS (Open Vulnerability Assessment System), es un framework de
cdigo abierto que analiza a profundidad que vulnerabilidades poseen los
servicios que tiene instalado un Sistema Operativo, ste genera un reporte de
utilidad que posteriormente se usa para parchear y corregir los problemas de
seguridad de stos.

La siguiente grfica muestra el cliente de Conexin de OpenVas, para iniciar
sesin con el usuario y contrasea.

Ilustracin 8 - Cliente OPENVAS para buscar vulnerabilidades
33

b) NESSUS, es un escner de vulnerabilidades que ofrece diariamente
actualizaciones sobres problemas de seguridad, posibilitando analizar qu tipo

33
La bitcora de Gabriel, Instalando OpenVas [En lnea],
<http://labitacoradegabriel.wordpress.com/2010/05/28/instalando-openvas/>, [Citado el 13 de
Septiembre de 2011]
32

de problemas se encuentran en nuestros sistemas, para posteriormente
parcharlos.

Nessus posee un cliente para Windows y Linux. Este cliente se conecta al
Servidor Nessus y agrega los hosts objetivo para buscar las vulnerabilidades.
En la siguiente imagen se observa el cliente para Windows, donde el smbolo
:

Ilustracin 9 - Cliente Nessus para buscar vulnerabilidades
34

c) NMAP, es una herramienta para escanear que servicios estn disponibles y en
que puertos, es muy til para descubrir qu tipo de Sistema Operativo tiene el
host analizado, como tambin que versiones de servicios y software tiene
instalado.

34
ClubHACKMag, Nessus [En lnea], <http://chmag.in/article/apr2010/nessus>, [Citado el 14 de
Septiembre de 2011]
33

En la siguiente imagen podemos observar un escaneo con nmap a los hosts
scanme.nmap.org y d0ze, el parmetro -A es para habilitar la deteccin de
Sistema Operativo y -T4 para una ejecucin rpida.

Ilustracin 10 - Escaneo de Servicios con NMAP
35

35
LYON, Gordon, Nmap [En lnea], <http://nmap.org>, [Citado el 14 de Septiembre de 2011]
34

5.1.5.2 HERRAMIENTAS PARA EXPLOTAR VULNERABILIDADES WEB

a) NIKTO
36

Es un escner de cdigo abierto que lleva a cabo mltiples pruebas exhaustivas
en los servidores web, incluyendo alrededor de 6400 archivos cgi potencialmente
peligrosos, revisa adems alrededor de 1200 versiones desactualizadas de
servidores, y problemas especficos de ms de 270 servidores. ste tambin
chequea la configuracin y opciones del servidor, para tratar de identificar que
software trae instalado, como tambin la versin del servidor web.

El parmetro -h especfica el host o dominio objetivo como podemos ver en la
siguiente grfica:

Ilustracin 11 - Escaneo de una aplicacin Web con NIKTO
37

36
INC CIRT, Nikto [En lnea], <http://cirt.net/nikto2>, [Citado el 14 de Septiembre de 2011]
37
iEntry Network, Nikto Core version 2.01 Released [En lnea],
<http://www.linuxhaxor.net/?p=648>, [Citado el 19 de Septiembre de 2011]
35

b) SQLMAP
38

Es una herramienta de prueba de intrusin para automatizar el proceso de
deteccin y explotacin de fallas de inyeccin SQL, con el fin de tomar el control
de la base de datos. ste viene con un poderoso motor de deteccin que posee
una amplia gama de pruebas, para acceder al sistema operativo y ejecutar
consultas SQL.

La herramienta se ejecuta de la siguiente manera:

python sqlmap.py -u http://www.justice.gov.al/index.php?gj=gj1--dbs

Donde -u es la URL o el enlace y --dbs es para enumerar las bases de datos
disponibles.

Ilustracin 12 - Ataque de Inyeccin SQL con SQLMAP
39

38
SQLMAP Developers, SQLMAP [En lnea], <http://sqlmap.sourceforge.net/>, [Citado el 19 de
Septiembre de 2011]
39
Hack Community, How to hack almost every site with sqlmap [En lnea],
<http://www.hackcommunity.com/Thread-SQL-how-to-hack-almost-every-site-with-sqlmap>, [Citado
el 19 de Septiembre de 2011]
36

c) SQLNINJA
40

El principal objetivo de esta herramienta es explotar las vulnerabilidades de
inyeccin SQL en aplicaciones Web que utilizan Microsoft SQL Server.

Sqlninja se diferencia de otras herramientas, debido a que ellas estn centradas a
extraer informacin, en cambio Sqlninja se centra en conseguir una Shell
interactiva con el servidor de bases de datos.

Para poder iniciar el ataque es necesario configurar el archivo sqlninja.conf que se
encuentra en el mismo directorio de la herramienta, de la siguiente forma:

host = 172.16.24.151 # Host a atacar
port = 80 # Puerto
method = GET # Mtodo HTTP GET
page = /default.asp # Pgina principal del aplicativo
stringstart = id=1 # Variable GET y su valor de iniciacin
stringend =
lhost = 172.16.24.150 # IP donde se ejecuta el anlisis
msfpath = /opt/metasploit3/msf3/ # Path de metasploit Framework

Luego desde la consola ejecutamos:
# ./sqlninja -m test

En la siguiente grfica se observa el resultado de la ejecucin del comando:

Ilustracin 13 - Resultado del Ataque de Inyeccin SQL con SQLNINJA
41

d) XSSer
42

que automatiza la deteccin y explotacin,
para reportar vulnerabilidades XSS en aplicaciones web. Adems posee varias

40
ICESURFER, SQLNINJA [En lnea], <http://sqlninja.sourceforge.net/sqlninja-howto.html#s1>,
[Citado el 19 de Septiembre de 2011]
41
Selvi Savater, Jose, SQLNINJA [En lnea], <http://www.pentester.es/2010/12/sql-injection-hasta-
la-cocina-ms-sql.html>, [Citado el 20 de Septiembre de 2011]
42
XSSer Workgroup, XSSer [En lnea], <http://xsser.sourceforge.net/>, [Citado el 20 de Septiembre
de 2011]
37

opciones para tratar de eludir ciertos filtros y varias tcnicas especiales que tratan
de evitar la inyeccin de cdigo.

En la siguiente grfica se explica el funcionamiento, donde a una variable por
ventana un mensaje de texto:

Ilustracin 14 - Funcionamiento de ataque XSS con XSSER

En esta otra grfica se explica un ataque bsico, donde python XSSer.py es el
comando, -u es el dominio o host a atacar y -g especifica el archivo y su respectiva
variable por GETs:

Ilustracin 15 - Parmetros necesarios para Iniciar XSSER

38

El resultado de este comando se puede observar en la siguiente grfica. En la cual
se muestra una inyeccin de XSS exitosa y la URL del ataque.

Ilustracin 16 - Resultado del ataque de XSSER
43

.
e) FIMAP
44

Es una pequea herramienta hecha en python que encuentra, prepara, audita y
explota errores de inclusin local y remota de archivos en aplicaciones web.

En la imagen se puede observar el origen de la vulnerabilidad y el modo de
ejecucin de fimap. Donde -u es el host o dominio objetivo.

Una vez ejecutada la herramienta, se muestra que archivos son vulnerables a
Remote File Inclusion (RFI).

43
Ethical Hacking-Your Way To The World Of IT Security, XSSer- Cross Site Scripting Penetration
Tool [En lnea], <http://www.ehacking.net/2011/02/xsser-cross-site-scripting-penetration.html>,
44
Karim, Iman, FIMAP [En lnea], <http://code.google.com/p/fimap/>, [Citado el 20 de Septiembre
de 2011]
39

Ilustracin 17 - Escaneo de URL con Fimap
45

f) CSRFTESTER
46

Es una herramienta de cdigo abierto desarrollada en JAVA que acta como un
servidor proxy que depura las solicitudes HTTP en el navegador Web en busca de
vulnerabilidades de tipo CSRF. Cabe resaltar que para utilizar esta aplicacin se
debe tener la mquina virtual de JAVA.

Una vez ejecutada, sta abre el puerto 8008 (Modo proxy). Adems el puerto debe
configurarse en el navegador Web, donde se interceptarn todas las solicitudes
HTTP en bsqueda de vulnerabilidades CSRF, para iniciar ste modo basta con
observarse mejor en la siguiente imagen:

45
DALLA PIAZZA, Alessio, Fimap: Scanner LFI(Local File Inclusion ) and RFI(Remote File
Inclusion) [En lnea], <http://www.clshack.it/en/fimap-scanner-lfilocal-file-inclusion-and-rfiremote-file-
inclusion.html>, [Citado el 21 de Septiembre de 2011]
46
OWASP FOUNDATION, CSRFTESTER [En lnea],
<https://www.owasp.org/index.php/CSRFTester_Usage>, [Citado el 21 de Septiembre de 2011]
40

Ilustracin 18 - Interfaz y Consola de depuracin de CSRFTESTER
47

g) OWASP MANTRA

Mantra es una coleccin de herramientas libres y de cdigo abierto, integradas en
un navegador basado en Firefox, la mayora de estas herramientas son conocidas
como complementos o extensiones del navegador.

Lo primero para ejecutar estas herramientas es abrir la URL objetivo, en este caso

como se observa en la siguiente imagen:

47
Selvi Savater, Jose, Creando PoC CSRF: CSRFTester 1.0 [En lnea],
<http://www.pentester.es/2010/05/creando-poc-csrf-csrftester-10.html>, [Citado el 21 de
Septiembre de 2011]
41

Ilustracin 19 - Prueba de Intrusin con Owasp Mantra

Ilustracin 20 - Estado del Escaneo, Owasp Mantra

42

h) WEBSECURIFY

Es un complemento disponible para los navegadores Google Chrome y Firefox
que utiliza un motor de reconocimiento de vulnerabilidades Web, tambin est
disponible para versiones de escritorio en MAC, Windows y Linux.

Para este caso se usar como una extensin del navegador. En la siguiente
imagen se observa como inicia el proceso para el sitio http://isc.utp.edu.co:

Ilustracin 21 - Escaneo con Websecurify

43

El resultado del escaneo es mostrado como reporte de una manera muy
interesante, dando una serie de recomendaciones:

Ilustracin 22 - Reporte Websecurify

5.1.5.3 SISTEMA OPERATIVO PARA PRUEBAS DE INTRUSIN

Hoy en da Backtrack ha sido un sistema operativo que ha ganado terreno en el
campo de la Seguridad informtica.

Backtrack es un arsenal de herramientas de pruebas de intrusin, basada en un
Sistema Operativo tipo Linux, que ayuda a profesionales de la seguridad a realizar
las evaluaciones necesarias a sistemas de informacin, para encontrar que
problemas de seguridad los afectan
48
.

Backtrack funciona en modo LIVECD, es decir, solo se carga en Memoria RAM sin
necesidad de instalarse, pero tambin tiene un modo de instalacin para tener el
sistema operativo permanentemente.

48
Offensive Security, Backtrack [En lnea], <http://www.backtrack-linux.org/>, [Citado el 26 de
Septiembre de 2011]
44

Cabe anotar que muchas de las herramientas anteriormente mencionadas estn
disponibles en este sistema operativo, adems de otras que podrn ser muy tiles,
stas se encuentran en el men Backtrack y por consola en /pentest/web.

Ilustracin 23 - Herramientas Backtrack

45

5.1.6 LA SERIE 27000
49

La serie ISO/IEC 27000 es un conjunto de estndares de seguridad que contienen
las mejores prcticas recomendadas en Seguridad de la Informacin, a
continuacin se resumen algunas de ellas:

ISO 27001: La norma ISO 27001 contiene los requisitos para implantacin del
sistema de gestin de seguridad de la informacin (SGSI). Es certificable.

ISO 27002: Es una gua de buenas prcticas que describe los objetivos de control
y controles recomendables en la seguridad de la informacin.

ISO 27005: Establece las directrices para la Gestin del riesgo en la seguridad de
la informacin.

ISO 27007: Consiste en una gua de auditora de un Sistema de Gestin de
Seguridad en la Informacin.

ISO 27032: Es una gua relativa a la Ciberseguridad.

ISO 27034: Su fecha prevista de publicacin es Diciembre de 2011. La ISO 27034,
servir como una gua de seguridad en aplicaciones.

5.1.6.1 LA ISO 27001

La informacin es un bien intangible vital para el funcionamiento de cualquier
empresa. En la actualidad las organizaciones se estn viendo obligadas a darle
mayor importancia a la conservacin y aseguramiento de la informacin y a los
mecanismos tecnolgicos que la procesan.

Para una adecuada Administracin de la Seguridad de la Informacin en una
organizacin es necesario establecer un sistema que aborde esta tarea de una
forma clara, sistemtica, documentada basada en objetivos precisos de seguridad
y una valoracin de los riesgos a los que est expuesta la informacin de la
organizacin.

La ISO/IEC 27000, es un conjunto de estndares desarrollados que proporcionan
un punto de referencia en la gestin de la seguridad de la informacin para
cualquier organizacin. A continuacin se relacionan las distintas normas que
componen la Serie ISO 27000:

49
ISO27000.ES, ISO 27000 [En lnea], <http://www.iso27000.es/download/doc_iso27000_all.pdf>,
[Citado el 3 de Octubre de 2011]
46

Desde el ao 1901 la organizacin Britnica British Standards Institution (BSI) es
responsable de la publicacin de normas importantes que han sido el marco
referencial de diferentes organizaciones.

En 1995 la British Standards Institution publica la norma BS 7799 con el objeto de
proporcionar a cualquier empresa un conjunto de buenas prcticas para la gestin
de la seguridad de la informacin.

En la siguiente ilustracin se visualiza la historia de la ISO 27001:

Ilustracin 24 - Histrico de la ISO 27001
47

El Estandar para la seguridad de la Informacin ISO 27001 fue diseado para
proveer un modelo para el establecimiento, implementacin, operacin,
monitorizacin, revisin, mantenimiento y mejoras de todos lo procesos que
involucran la Seguridad de la Informacin en una organizacin por medio del
Sistema de la Gestin de la Seguridad de la Informacin (SGSI).

La ISO 27001 adopta el modelo del proceso (PDCA) Planear Hacer Chequear
Actuar, que se puede aplicar a los procesos SGSI. La siguiente figura ilustra el
proceso:
Ilustracin 25 - Modelo de Proceso PDCA

A continuacin se detalla cada una de las actividades que se llevan a cabo en la
Planificacin, Implementacin, Seguimiento y Mejora continua:

48

5.1.6.1 PLANIFICACIN

Ilustracin 26 - Etapa de Planeacin

Definir alcance del SGSI. El SGSI no tiene por qu abarcar toda la
organizacin, pero es recomendable iniciar por un alcance limitado.

Definir poltica de seguridad. Las polticas de seguridad deben incluir un
marco general y los objetivos de seguridad de la informacin de la
organizacin. Es de vital importancia alinear la gestin de riesgos con los
requisitos del negocio, legales y contractuales en cuanto a seguridad de
igual manera establecer criterios de evaluacin y que estos sean
aprobados por la Direccin. La poltica de seguridad es un documento que
no es otra cosa que una declaracin de intenciones de la Direccin.

Definir el enfoque de evaluacin de riesgos. Es necesario definir una
metodologa de evaluacin de riesgos apropiada para el SGSI y las
necesidades de la organizacin, de igual manera desarrollar criterios de
aceptacin de riesgos y determinar el nivel de riesgo aceptable.

Inventario de activos: El Inventario de activos son todos aquellos activos de
informacin que tienen algn valor para la empresa u organizacin y se
encuentra dentro del alcance del SGSI.

49

Identificar amenazas y vulnerabilidades. Las amenazas y vulnerabilidades
es todo aquello que afecta a los activos del inventario (La Informacin).

Identificar los impactos. Es todo aquello que podra suponer una prdida de
la confidencialidad, integridad o disponibilidad de cada uno de los activos.

Anlisis y evaluacin de los riesgos. El anlisis y evaluacin de los riesgos
es evaluar el dao resultante de un fallo de seguridad, es decir, que una
amenaza externa aproveche una vulnerabilidad interna y la probabilidad de
ocurrencia del fallo estimar el nivel de riesgo resultante y determinar si el
riesgo es aceptable (en funcin de los niveles definidos previamente) o
requiere tratamiento.

Identificar y evaluar opciones para el tratamiento del riesgo. El riesgo puede
ser reducido o mitigado mediante controles, eliminado, si se elimina el
activo, aceptado o transferido, ya sea utilizando un seguro o a travs de
outsourcing.

Seleccin de controles. Se seleccionan controles para el tratamiento del
riesgo en funcin de la evaluacin.

Aprobacin por parte de la Direccin del riesgo y autorizacin de implantar
el SGSI. Es de aclarar que los riesgos de seguridad de la informacin son
riesgos de la organizacin por ende es la Direccin quien puede tomar
decisiones sobre su aceptacin o tratamiento.

Confeccionar una Declaracin de Aplicabilidad, la llamada SOA (Statement
of Applicability) es un resumen de las decisiones tomadas en cuanto al
tratamiento del riesgo.

50

5.1.6.2 IMPLEMENTACIN

Ilustracin 27 - Etapa de Implementacin

Definir el plan de tratamiento de riesgos: Que identifique las acciones,
recursos, responsabilidades y prioridades en la gestin de los riesgos de
seguridad de la informacin.

Implantar plan de tratamiento de riesgos: Con la meta de alcanzar los
objetivos de control identificados.

Implementar los controles: Todos los que se seleccionaron en la fase
anterior.

Formacin y concienciacin: De todo el personal en lo relativo a la
seguridad de la informacin.

Desarrollo del marco normativo necesario: normas, manuales,
procedimientos e instrucciones.

Gestionar las operaciones del SGSI y todos los recursos que se le asignen.

Implantar procedimientos y controles de deteccin y respuesta a incidentes
de seguridad.

51

5.1.6.3 SEGUIMIENTO

Ilustracin 28 - Etapa de Seguimiento
Ejecutar procedimientos y controles de monitorizacin y revisin: En esta
etapa se detectan errores en resultados de procesamiento e incidentes de
seguridad.

Revisar regularmente la eficacia del SGSI: Esta revisin se hace en funcin
de los resultados de auditoras de seguridad, incidentes, mediciones de
eficacia, sugerencias y feedback de todos los interesados.

Medir la eficacia de los controles: Se realiza para verificar que se cumple
con los requisitos de seguridad.

Revisar regularmente la evaluacin de riesgos: Cualquier cambio en la
organizacin, tecnologa, procesos y objetivos de negocio, amenazas,
eficacia de los controles o el entorno tienen una influencia sobre los riesgos
evaluados, el riesgo residual y el nivel de riesgo aceptado.

Realizar regularmente auditoras internas: Con el fin de determinar si los
controles, procesos y procedimientos del SGSI mantienen la conformidad
con los requisitos de ISO 27001.

Revisar regularmente el SGSI por parte de la Direccin: Con el objetivo de
determinar si el alcance definido sigue siendo el adecuado, de igual forma,
identificar mejoras al proceso del SGSI, la poltica de seguridad o a los
objetivos de seguridad de la informacin.

52

Registrar acciones y eventos que puedan tener impacto en la eficacia o el
rendimiento del SGSI: sirven como evidencia documental de conformidad
con los requisitos y uso eficaz del SGSI.

5.1.6.4 MEJORA CONTINUA

Ilustracin 29 - Etapa de Mejora Continua
Implantar mejoras: Poner en marcha todas las mejoras que se hayan
propuesto en la fase anterior.

Acciones correctivas: Para solucionar no conformidades detectadas.

Acciones preventivas: Para prevenir potenciales no conformidades.

Comunicar las acciones y mejoras: A todos los interesados y con el nivel
adecuado de detalle.

Asegurarse de que las mejoras alcanzan los objetivos pretendidos: La
eficacia de cualquier accin, medida o cambio debe comprobarse siempre.

53

5.1.7 METODOLOGA OWASP
50

La metodologa OWASP (Open Web Application Security Project) est diseada
como un marco de trabajo que ayude en el proceso del ciclo de desarrollo del
software (SDLC), sta provee una solucin flexible que mejora el proceso de
desarrollo, teniendo en cuenta desde el inicio el tema de la seguridad en la
ingeniera de software.

En la siguiente grfica observamos cmo se hace ms costoso reparar un
problema de seguridad en el ciclo de desarrollo del Software, es decir, entre ms
avanzado est el proceso ms costoso va ser arreglarlo.

Ilustracin 30 - Incremento de los costes de reparar bugs de seguridad en el SDLC

Estructuralmente esta metodologa consta de las siguientes fases:

FASE 1: Antes de empezar el desarrollo

Es importante antes de empezar todo desarrollo de software tener en cuenta lo
siguiente:

Comprobar si el ciclo de desarrollo del Software (SDLC) incluye de manera
nativa el proceso de la seguridad
Comprobar si los estndares y polticas de seguridad adecuados estn
implementados
Desarrollar criterios de medicin y mtricas

50
OWASP FOUNDATION, Metodologa OWASP [En lnea],
<https://www.owasp.org/images/8/80/Gu%C3%ADa_de_pruebas_de_OWASP_ver_3.0.pdf>,
[Citado el 10 de Octubre de 2011]
54

FASE 1.1. Revisin de estndares y polticas

Asegurar que las polticas, documentacin y estndares estn siendo
implementados, fija una trayectoria a seguir para todos los integrantes del equipo
de desarrollo.

Por lo tanto si se est desarrollando software en PHP, debe haber un estndar
para desarrollar aplicaciones seguras en PHP, si se va a realizar un modulo que
maneja cifrado es importante obtener los estndares de criptografa.

FASE 1.2 Desarrollo de mtricas y criterios de medicin

Si antes de empezar el desarrollo se tiene claro qu se quiere medir, la
recoleccin de informacin en puntos clave del desarrollo mostrar ms
claramente cmo van los procesos, para as tomar acciones correctivas y mejoras.

FASE 2: Durante el diseo y la definicin

El proceso de Ingeniera de software es de vital importancia para obtener un
producto de excelente calidad, un mal diseo y definicin puede significar perdida
de dinero y clientes para las organizaciones, por lo que tener en cuenta la
seguridad es un factor clave en el negocio.

FASE 2.1 Revisin de los requisitos de seguridad

Los requerimientos de seguridad, definen como funciona una aplicacin desde el
punto de vista de seguridad, por lo tanto es fundamental ser lo ms claro posible
con la definicin de stos, adems se deben probar y evaluar para corregir
deficiencias y obtener mejoras, para que el equipo de trabajo alcance lo que se
planteo.

En este proceso es esencial tener en cuenta los siguientes mecanismos de
seguridad:

Gestin de Usuarios (reinicio de contrasea, cifrado de contrasea, etc.).
Autenticacin.
Autorizacin.
Confidencialidad de los datos.
Integridad.
Contabilidad.
55

Gestin de Sesiones.
Seguridad de Transporte.
Separacin de Sistemas en niveles.
Privacidad.

FASE 2.2 Revisin de diseo de arquitectura

Anteriormente se mencion la importancia de tener todo documentado, por lo que
tener muy bien documentada la arquitectura es significativo, es decir, tener todos
los modelos, documentos, entre otros, a disponibilidad del equipo de trabajo,
ayuda a comprobar si lo que se dise a partir de los requerimientos si fue
aplicado y si tiene un nivel adecuado de seguridad, adems de detectar problemas
de seguridad que no se hayan tenido en cuenta o malos diseos.

Identificar estos problemas en esta fase temprana de desarrollo ayuda a ahorrar
costos, y en sta los cambios pueden hacerse mucho ms efectivos, tanto que se
puede avisar las vulnerabilidades encontradas al arquitecto de software para su
gil correccin.

FASE 2.3 Creacin y revisin de modelos UML

Cuando el diseo y la arquitectura han sido finalizados, es una buena prctica
modelarlos bajo la metodologa UML, debido a que sta describe mejor el
funcionamiento de las aplicaciones.

No se debe ignorar el hecho de reunir al equipo de trabajo para comprender los
modelos UML y mejorarlos.

FASE 2.4 Creacin y revisin de modelos de amenaza

Teniendo total compresin del modelamiento UML, es decir, el funcionamiento de
la aplicacin, se debe ahora hacer el modelado de amenazas realistas, l cual
debe asegurar que las amenazas son mitigadas por medio de la modificacin del
diseo original.

56

FASE 3: Durante el desarrollo

Llegar del diseo a la implementacin puede inferir en cambios de diseo durante
el desarrollo, por lo general son cambios pequeos, los cuales pueden haber sido
pasados por alto durante la etapa de diseo, por otro lado si hay problemas en la
arquitectura y diseo, los desarrolladores deben afrontar decisiones muy difciles,
stos problemas pueden ser debidos a polticas y estndares insuficientes.

FASE 3.1 Inspeccin de cdigos por fases

En esta fase el equipo de seguridad debe realizar una inspeccin minuciosa de
cdigo por fases de alto nivel, es decir, ellos deben reunirse con los
desarrolladores y en algunas ocasiones con los arquitectos, para conseguir una
explicacin del funcionamiento del cdigo, el diseo y arquitectura
respectivamente, para as, obtener una retroalimentacin de los diferentes actores
y revisar si el diseo, arquitectura e implementacin coinciden. En esta etapa el
propsito no es revisar el cdigo sino mirar el flujo de programacin, su esquema y
la estructura del cdigo.

FASE 3.2 Revisiones de cdigo

En esta subfase se tiene en consideracin la etapa anterior, ya que ella es el
punto de partida para mirar la congruencia del desarrollo. A partir de aqu el
equipo de seguridad o la persona encarga de sta puede empezar a buscar
vulnerabilidades en el desarrollo.

FASE 4: Durante la implementacin

FASE 4.1 Pruebas de intrusin en aplicaciones

Luego de haber revisado la congruencia entre los requisitos, el diseo y la revisin
del cdigo, se asume que se identifican todas las incidencias, de no ser as, es
decir, no se identifican los problemas, las pruebas de intrusin son un mecanismo
adicional de comprobacin que puede ayudar a detectarlas

FASE 4.2 Comprobacin de gestin de configuraciones

Luego de haber determinado que la aplicacin es segura, puede haber detalles de
configuracin que pueden hacer que sta sea vulnerada, por esto comprobar la
instalacin y configuracin de sta, es de vital importancia para evitar problemas
de seguridad.

57

FASE 5: Mantenimiento y operaciones

FASE 5.1 Ejecucin de revisin de la administracin operativa

En esta fase se debe documentar y ejecutar de manera detallada el proceso para
la gestin operativa de la aplicacin y su infraestructura.

FASE 5.2 Ejecucin de comprobaciones peridicas de mantenimiento

Debido a que en ocasiones se solicitan cambios en la aplicacin o infraestructura
se deben hacer comprobaciones mensuales o trimestrales para saber si no han
sido introducidos nuevos riesgos de seguridad y si la seguridad sigue intacta.

FASE 5.3 Asegurar la verificacin de cambios

La gestin del cambio es esencial en esta fase, debido a que si se genera un
cambio se debe comprobar si ste fue hecho, para as verificar que la seguridad
no ha sido afectada.

58

En la siguiente grfica se resume todo el proceso de la metodologa OWASP,
explicada anteriormente:

Ilustracin 31 - Flujo de trabajo de la Metodologa OWASP

59

5.1.8 METODOLOGA ISSAF
51

La metodologa de pruebas de intrusin ISSAF (Information Systems Security
Assessment Framework) est diseada para evaluar la red, sistemas y
aplicaciones. ste se enfoca en 3 fases y 9 pasos de evaluacin.

Las 3 fases son:

Fase I: Planeacin y preparacin

Fase II: Evaluacin

Fase III: Presentacin de Informes

FASE I: Planeacin y preparacin

Esta fase comprende los pasos para el intercambio de informacin inicial,
planificar y prepararse para la prueba. Antes de la prueba de intrusin, se firmar
un acuerdo formal entre ambas partes, (Empresa y auditor de seguridad), para
proveer un mecanismo bsico de proteccin legal. Tambin se debe especificar el
grupo de trabajo, las fechas exactas, los tiempos de la prueba, ruta de
escalamiento y otras evaluaciones.

Las actividades previstas en esta fase son:

Identificacin de contactos de parte y parte.

Reuniones abiertas para confirmar el alcance, enfoque y metodologa.

Estar de acuerdo en los casos de prueba especficos y rutas de
escalamiento.

FASE II: Evaluacin

En esta fase es en realidad en la que se va a llevar a cabo la prueba de intrusin.
Esta fase aplica un enfoque por capas, en donde cada capa representa un mayor
nivel de acceso a los activos de la informacin. Las capas son las siguientes:

1. Recopilacin de Informacin.
2. Mapeo de la Red.
3. Identificacin de vulnerabilidades.

51
Open Information System Security Group, Metodologa de Pruebas de Intrusin ISSAF [En
lnea], <www.oissg.org/wiki/index.php?title=PENETRATION_TESTING_METHODOLOGY>, [Citado
el 15 de Octubre de 2011]
60

4. Intrusin.
5. Ganando acceso y escalando privilegios.
6. Enumeracin adicional.
7. Comprometiendo usuarios/sitios remotos.
8. Manteniendo acceso.
9. Cubriendo rastros.

Estas capas estn representadas en el siguiente grfico:

Ilustracin 32 - Metodologa ISSAF
1) Recoleccin de Informacin: La recoleccin de informacin incluye el uso de
internet para encontrar datos y conceptos sobre el objetivo (Empresa y/o persona),
usando mtodos, tcnicos (DNS y Whois) y no tcnicos como motores de
61

bsqueda, grupos de noticias, listas de correo, etc. Esta es la etapa inicial de una
auditora de seguridad de la informacin, que muchas personas tienden a pasar
por alto. Cuando se realiza cualquier tipo de prueba en un sistema de informacin,
la recopilacin de informacin y minera de datos son esenciales, porque
proporcionan toda la informacin posible para iniciar las siguientes fases.

En la recopilacin de informacin, es importante ser lo ms imaginativo posible. Se
debe intentar explorar todas las vas posibles para obtener una mayor
comprensin del objetivo y sus recursos. Cualquier cosa que se consiga en esta
etapa de la prueba es til: folletos de la empresa, tarjetas de visita, anuncios en
peridicos, documentos internos, y as sucesivamente.

La recoleccin de informacin no requiere que el auditor establezca contacto con
el objetivo. La informacin se recoge (principalmente) a partir de fuentes pblicas
en Internet y de las organizaciones que mantienen la informacin pblica (por
ejemplo, agencias de impuestos, bibliotecas, etc.)

Esta seccin de la evaluacin es muy importante para el auditor. Las evaluaciones
son generalmente limitadas en tiempo y recursos. Por lo tanto, es fundamental
identificar los puntos que probablemente son ms vulnerables, y centrarse en
ellos. Incluso las mejores herramientas son intiles si no se utilizan
adecuadamente en el lugar y tiempo correcto. Es por eso que los auditores
experimentados invierten una importante cantidad de tiempo en la recopilacin de
informacin.

2) Mapeo de la Red: La informacin que tenga que ver con la red se toma de la
seccin anterior y se expande para producir una topologa de red probable del
objetivo. Muchas herramientas y aplicaciones se pueden utilizar en esta etapa
para ayudar al descubrimiento de informacin tcnica sobre los hosts y redes
involucrados en la prueba.

Encontrar hosts disponibles.

Escaneo de puertos y servicios.

Mapeo del permetro de red (enrutadores, cortafuegos).

Identificacin de servicios crticos.

Identificacin del tipo de Sistema Operativo.

Identificacin de rutas.

Identificacin de versiones y software en los servicios
62

Para ser efectivo, el mapeo de red debe realizarse de acuerdo al plan. Este plan
incluir probables puntos dbiles y/o puntos ms importantes para la organizacin
auditada y tendr en consideracin toda la informacin obtenida en la seccin
anterior.

El mapeo de red ayudar al auditor a completar la informacin previamente
adquirida y a confirmar o descartar algunas hiptesis sobres los sistemas objetivo
(por ejemplo, marcas de software/hardware, configuracin, arquitectura, relaciones
con otros recursos y relaciones con procesos de negocio).

3) Identificacin de vulnerabilidades: Antes de comenzar esta seccin, el
auditor debe escoger los puntos especficos a probar y la manera de como
probarlos. Durante la identificacin de vulnerabilidades, el auditor tendr que
realizar varias actividades para detectar y explotar los puntos dbiles. Estas
actividades incluyen:

Identificar los servicios vulnerables usando servicios de banners.

Realizar escaneo de vulnerabilidades conocidas. La informacin con
respecto a vulnerabilidades conocidas puede ser obtenida de anuncios de
seguridad, de bases de datos pblicas como SecurityFocus, CVE o los
anuncios de CERT.

Realizar la verificacin de falsos positivos y falsos negativos (por ejemplo,
correlacin de vulnerabilidades y con informacin previamente adquirida).

Enumerar las vulnerabilidades descubiertas.

Estimar el impacto probable (clasificar las vulnerabilidades encontradas)

Identificar las rutas de ataque y escenarios para la explotacin.

4) Intrusin: Aqu el auditor intentar obtener acceso no autorizado, para eludir
las medidas de seguridad y tratar de llegar al mayor nivel de acceso posible. Este
proceso se debe dividir en los siguientes pasos:

Encontrar una prueba de concepto cdigo/herramienta: Encontrar cdigos
fuentes disponibles en repositorios propios o pblicos para encontrar
vulnerabilidades. Si el cdigo est en su propio repositorio de confianza y
ha sido probado a fondo, se puede utilizar directamente, de lo contrario se
debe probar el cdigo en un entorno aislado.

63

Desarrollar herramientas/scripts: En algunas circunstancias ser necesario
(y rentable) para el auditor.

Hacer pruebas de concepto cdigo/herramienta.

o Personalizar prueba de concepto cdigo/herramienta.

o Probar pruebas de concepto cdigo/herramienta en un entorno
aislado.

Usar pruebas de concepto frente al objetivo: La prueba de concepto
cdigo/herramienta es utilizada frente al objetivo para obtener mayor
cantidad de puntos de acceso no autorizados como sea posible.

Verificar o desaprobar la existencia de vulnerabilidades: Solo los auditores
pueden confirmar o desaprobar vulnerabilidades definitivamente.

Documentar las conclusiones: Esta documentacin contiene explicaciones
detalladas de las vas de explotacin, el impacto de la auditoria y pruebas
de la existencia de la vulnerabilidad.

5) Ganando acceso y escalando privilegios: Las actividades en esta seccin
permiten a los auditores confirmar y documentar intrusiones posibles y/o
propagacin de ataques automatizados. Esto permite una mejor evaluacin del
impacto para la organizacin.

Ganando acceso: obtener privilegios mnimos. Ganar los privilegios mnimos
es posible por medio de acceso a cuentas sin privilegios a travs de varios
medios, incluyendo:

Descubrir combinaciones de usuario/contrasea (por ejemplo, ataques de
diccionario, ataques de fuerza bruta).

Descubrir contraseas vacas o contraseas por defecto en las cuentas del
sistema.

Explotar configuraciones por defecto de fabricantes (parmetros de
configuracin de red, contraseas, entre otros).

Descubrimiento de los servicios pblicos que permiten ciertas operaciones
dentro del sistema (por ejemplo, escribir/crear/leer archivos).

64

Escalando privilegios: En esta etapa el objetivo es obtener privilegios de
administrador, las principales barreras son las actualizaciones, endurecimiento del
sistema y herramientas de integridad del sistema (incluyendo antivirus), que
pueden detectar y en algunos casos bloquear la accin en la prueba de concepto
de explotacin.

6) Enumeracin adicional:

Obtener contraseas encriptadas con cracking offline (sin conexin a
internet), por ejemplo, con el archivo de contraseas SAM de Windows o
con los archivos /etc/passwd y /etc/shadow en sistemas Linux.

Obtener contraseas (texto plano o encriptadas) usando sniffing u otras
tcnicas.

Rastrear el trfico y analizarlo.

Recoger las cookies y usarlas para explotar sesiones y para ataques de
contrasea.

Recolectar correos electrnicos.

Identificar rutas y redes.

Mapear redes internas.

Realizar los pasos del 1 al 6 de nuevo con este sistema como punto de partida.

7) Comprometiendo usuarios/sitios remotos: Un solo agujero de seguridad es
suficiente para exponer toda la red, independientemente de qu tan seguro el
permetro de red pueda ser.

Las comunicaciones entre usuarios/sitios remotos y redes empresariales pueden
ser con mtodos de autenticacin y cifrado, como VPN, para asegurar que los
datos no sean modificados mientras viajan en la red, sin embargo, esto no
garantiza que los extremos de comunicacin no han sido comprometidos.

En tales escenarios el auditor debe tratar de comprometer a los usuarios remotos,
trabajadores virtuales y/o sitios remotos de una empresa. Los que pueden dar
acceso privilegiado a la red interna.

65

8) Mantener el acceso: El software de tnel, puertas traseras y rootkits, entre
otros, no se usan a menudo debido al riesgo de que un atacante los descubra y
obtengan acceso privilegiado al sistema.

9) Cubrir los rastros: Es una prctica normal durante las pruebas de intrusin
para actuar lo ms abierto posible (Excepto cuando es solicitado por el cliente) y
para producir informacin en detalle y registros de todas las actividades, por lo que
esta seccin de abajo es principalmente para fines de referencia:

Ocultar archivos: Ocultar archivos es importante si el auditor requiere ocultar
actividades que se han hecho durante las pruebas de intrusin. Esto tambin es
importante para ocultar las herramientas y no tenerlas que subir cada vez que se
quiera ejecutar una operacin.

Borrar registros: Lo importante de esta fase es entender que si un atacante
experimentado tiene acceso al sistema, ste intentar borrar las evidencias de los
registros del sistema. Esto solo es efectivo sino hay un servidor remoto que
registre las actividades del sistema.

FASE III: Presentacin de informes

a) Informe Verbal: Si en el transcurso de las pruebas de intrusin se encuentra
una vulnerabilidad en el sistema, se debe informar inmediatamente a la
organizacin para que sea consciente del problema.

b) Informe Final: Tras la finalizacin de todos los casos de prueba definidos en el
alcance del trabajo, se debe hacer un informe escrito que describa los
resultados de las pruebas con las recomendaciones de mejora respectivas. El
informe deber ajustarse a una estructura bien documentada, de la siguiente
manera:

Resumen de gestin.

Alcance del proyecto (y partes del alcance de salida).

Herramientas que han sido usadas (incluyendo exploits).

Fechas y tiempos de las pruebas en el sistema.

Cada salida de las pruebas realizadas (excluyendo los casos de anlisis de
vulnerabilidades que pueden ser incluidos como archivos adjuntos).

Una lista de vulnerabilidades identificadas con las recomendaciones de
cmo resolverlas.
66

Una lista de puntos de accin (Qu recomendacin realizar primero, cul es
la solucin recomendada).

c) Limpiar el sistema de las pruebas de intrusin realizadas: Remover todas
las herramientas, archivos, software que se hayan instalado en el sistema. En
el caso de no poderlos quitar, informar al cliente, para que ste tome las
acciones necesarias.

67

5.2 MARCO NORMATIVO

5.2.1 LEY 1273 DE 2009
52

Los tres principios fundamentales de la seguridad son la confidencialidad, la
integridad y la disponibilidad como se cit anteriormente. Para preservar estos
principios el Congreso de Colombia aprob la Ley 1273 de 2009, que pretende
proteger la informacin, los datos y la preservacin integral de los sistemas que
utilicen tecnologas de la informacin y las Comunicaciones.

La ley en su primer captulo tiene en cuenta los siguientes artculos, que son los
ms esenciales y directos con la informacin:

Acceso abusivo a un sistema informtico.

Obstaculizacin ilegtima de sistema informtico o red de telecomunicacin.

Interceptacin de datos informticos.

Dao informtico.

Uso de software malicioso.

Violacin a datos personales.

Suplantacin de sitios web para capturar datos personales.

Circunstancias de agravacin punitiva.

Esta ley es de gran importancia como un apoyo legal para proteger la informacin
de las organizaciones o personas, ya que no estn exentas a estos probl emas.
Adems conocer las multas y penas de estas violaciones, posibilitan un
mecanismo de respuesta rpido de las organizaciones o personas para defender
su activo ms importante que es la informacin.

52
Secretara del Senado, Ley1273 de 2009 [En lnea],
<http://www.secretariasenado.gov.co/senado/basedoc/ley/2009/ley_1273_2009.html>, [Citado el 3
de Octubre de 2011]
68

6. PROPUESTA METODOLGICA

6.1 ENFOQUE DE CAJA NEGRA

Bsicamente consiste en el anlisis de la ejecucin de herramientas en la
bsqueda de vulnerabilidades. Este enfoque tambin es conocido como pruebas
de intrusin, el auditor no conoce el funcionamiento interno de la aplicacin web
(el cdigo fuente no est disponible) y utiliza tcnicas de pruebas automatizadas,
que son capaces de generar y enviar datos secuenciales o aleatorios a una
aplicacin web o a las solicitudes HTTP, esta tcnica es conocida tambin como
Fuzzing
53
.

La prueba de Intrusin ser llevada a cabo en las siguientes fases:

Recoleccin de Informacin.

Mapeo de la red.

Identificacin de vulnerabilidades.

Intrusin.

Presentacin del reporte.

Recoleccin de informacin: En esta fase se recolecta toda la informacin
posible (desde Internet, peridicos, anuncios) de la organizacin que se quiere
auditar, como, correos, direcciones, nombres, proveedores, infraestructura, etc.
Con el fin de hacer un mapa general de la organizacin.

Mapeo de la red: En esta fase se identifica que servicios y puertos tiene abierto el
servidor Web donde se encuentra alojada la aplicacin Web, este proceso puede
hacerse con la herramienta nmap. Cuando se empieza a analizar la red se revisa
la seguridad tanto fsica como lgica, ya que cualquiera de las dos puede ser un
hueco de seguridad para vulnerar el sistema.

Identificacin de vulnerabilidades: En esta fase se usan las herramientas de
pruebas de intrusin mencionadas anteriormente, aunque si se identifican algunas
herramientas adicionales, stas pueden utilizarse.

53
VIEIRA, Marco., ANTUNES, Nuno., MADEIRA, Henrique.
University of Coimbra, Portugal, 2009.
69

Intrusin: Una vez encontradas las vulnerabilidades, se descartan cuales son
falsos positivos. Luego de haberlas clasificado, explotarlas y revisar si el sistema
ha sido comprometido.

Presentacin de Reporte: Esta fase es la ms importante, debido que con ella se
demuestra que el sistema es o no seguro.

El reporte debe contener:

Fecha.

Duracin de las pruebas de Intrusin.

Persona responsable de las pruebas de Intrusin.

Vulnerabilidades clasificadas por categora e impacto.

Puntos por donde se logr el acceso.

6.2 ENFOQUE DE CAJA BLANCA

La esencia de este enfoque es analizar el cdigo fuente en bsqueda de
vulnerabilidades. Esto puede traer una serie de complicaciones si el cdigo es
muy complejo, debido a que se dificulta encontrar los problemas de seguridad.

Por lo tanto se plantea hacer estos anlisis en el ciclo de desarrollo del Software
(SDLC) para quitarle complejidad a ste problema, en conjunto con el Sistema de
Gestin de la seguridad de la Informacin (la norma ISO 27001), que es el
estndar de facto que las organizaciones deben certificar para demostrar que
ofrecen seguridad en la informacin de sus clientes, adems de darle una gestin
eficiente a los riesgos y vulnerabilidades. A continuacin se citan consideraciones
adicionales a tener en cuenta en la fase de desarrollo.

La seguridad como requerimiento adicional. Los clientes siempre hacen
requerimientos de cmo quieren sus aplicaciones, pero la seguridad no siempre es
tenida en cuenta, por esto tener la seguridad como algo adicional en el desarrollo
del producto, trae un valor agregado y una reputacin especial hacia la
organizacin. Por lo tanto, se aplicar este enfoque en la metodologa.

70

6.2.1 CICLO DE DESARROLLO DEL SOFTWARE

a) Anlisis

En esta fase inicial se plantea todos los requerimientos de seguridad de la
aplicacin Web. Estos requerimientos deben tener en cuenta lo siguiente:

Mecanismos de Captcha para evitar ataques de fuerza bruta en los
formularios.

Mecanismos de intentos fallidos de autenticacin, como por ejemplo
bloquear un mximo de intentos fallidos por direccin IP.

Mecanismos de cifrado de contraseas en la base de datos.

Mecanismos para evitar vulnerabilidades en la aplicacin Web. Este ltimo
debe definirse en la poltica de programacin Segura.

b) Diseo

El arquitecto de software debe tener en cuenta los requerimientos anteriormente
mencionados en el diseo del software, adems de esto, debe estar en continuo
contacto con los desarrolladores y el equipo de seguridad la persona encargada
de sta, para construir un diseo en donde no se pase por alto ningn
requerimiento de seguridad.

c) Desarrollo

En esta etapa es fundamental la poltica de Programacin Segura, la cual debe
definirse de forma clara y entendible por todo el equipo de trabajo, tambin debe
explicar cmo se identifican los problemas de seguridad en aplicaciones Web
(Vulnerabilidades) y como no generar stos problemas, adems esta poltica debe
ser leda y tenida en cuenta muy en detalle por el equipo de desarrollo. Para
desarrollar esta poltica, la gua de OWASP para construir aplicaciones y servicios
web seguros
54
ser de mucha utilidad.

En esta etapa el equipo de seguridad debe hacer un anlisis de cdigo minucioso,
es decir, cada vez que el equipo de desarrollo termine un modulo o un
requerimiento, este debe ser analizado en bsqueda de alguna vulnerabilidad,
adems de si se est cumpliendo la poltica de programacin segura, en caso de

54
OWASP Foundation, gua para construir aplicaciones y servicios web seguros [En lnea],
<https://www.owasp.org/images/b/b2/OWASP_Development_Guide_2.0.1_Spanish.pdf>, [Citado el
19 de Octubre de 2011]
71

que no se est cumpliendo se debe informar al equipo desarrollo para que haya
una retroalimentacin y la poltica se cumpla a cabalidad.

Este anlisis de cdigo puede ser efectuado con herramientas como:

Pixy.
Google CodeSearchDiggity.
FindBugs.
FxCop.

Es esencial recalcar, que el uso de herramientas es til, pero la revisin manual
por el equipo de seguridad es ms minuciosa y precisa.

d) Instalacin

El sistema Operativo donde se instale la aplicacin Web influye en su seguridad, la
configuracin e instalacin debe ser afinada para que el aplicativo opere en las
condiciones de seguridad ptimas.

En esta fase se debe tener en cuenta lo siguiente:

Pruebas y controles de seguridad en la aplicacin Web (Pruebas de
Intrusin).

Ocultar versiones de Sistema Operativo y Servidor Web.

Comprobacin y seguridad del Sistema Operativo tanto a nivel lgico como
fsico.

e) Mantenimiento

Los clientes por lo general siempre piden cambios en el software una vez
terminado, por consiguiente se debe tener un buen manejo y control de los nuevos
requerimientos, con correlacin a los requerimientos de seguridad.

En esta fase se deben aplicar pruebas peridicas para comprobar la seguridad y el
funcionamiento de la aplicacin.

Todos los procesos que manejen informacin deben ser monitoreados y
gestionados por el SGSI. Por lo tanto la correlacin entre el enfoque de caja
blanca y el SGSI asegurar un proceso de gestin ms eficiente ante los
incidentes como las vulnerabilidades y riesgos que afecten la informacin,
generando as un modelo complementario.
72

Adems la comunicacin, la aplicacin de las polticas y documentacin, entre los
equipos de trabajo (desarrolladores, arquitectos, equipo de seguridad o persona
encargada de sta) es clave para lograr el xito en este enfoque, ya que garantiza
que el proceso de desarrollo incluye la seguridad y no se pasa nada por alto.

Por otro lado, una vez el producto est terminado, es decir, hay un producto final,
se puede aplicar el enfoque de caja negra, para hacer un anlisis ms exhaustivo
de la seguridad y tomar acciones correctivas.

En los dos enfoques, si se encuentra una vulnerabilidad, el impacto sobre la
informacin es muy alto, por lo tanto el nivel de seguridad es bajo, si por el
contrario no se encuentran vulnerabilidades el nivel de seguridad es alto.

En el siguiente grfico se resume el funcionamiento de la metodologa propuesta:

Ilustracin 33 - Propuesta Metodolgica

73

7. RECOMENDACIONES

Mantener el Sistema Operativo donde se aloja la aplicacin Web
actualizado, debido a que puede ser una puerta de entrada o hueco de
seguridad.

Incluir dentro de la Poltica de Seguridad las polticas de Programacin
Segura, para mitigar las vulnerabilidades.

Incluir dentro de los equipos existentes en el proceso de desarrollo al
equipo de seguridad, quienes estarn presentes en cada una de las fases
del proceso de desarrollo contribuyendo con los controles de seguridad.

Incluir mecanismos de seguridad fsicos tales como cortafuegos, IDS
(Sistema de Deteccin de Intrusos), entre otros, para detectar posibles
ataques al sistema y contrarrestarlos.

Utilizar planes de contingencia para preservar el principio de disponibilidad,
por si un sistema informtico ha sido vulnerado.

Si se identifican responsables de ataques informticos al sistema, utilizar la
normatividad 1273 de 2009 para proteger la organizacin y judicializar a los
responsables.

74

8. CONCLUSIONES

La seguridad en las aplicaciones debe considerarse desde el desarrollo,
debido a que reparar huecos de seguridad cuando la aplicacin est
terminada puede resultar muy costoso, inclusive en algunas ocasiones
cuando las aplicaciones son demasiado robustas y grandes es ms
econmico hacerlas de nuevo que reparar los huecos de seguridad.

Las organizaciones ven la seguridad como un costo y no como un valor
agregado que proporciona prestigio y confiabilidad con los clientes.

Las metodologas existentes se especializan cada una en un rea, OWASP,
en el ciclo de desarrollo del software de aplicaciones web seguras, ISO
27001, en seguridad de la informacin e ISSAF, para las pruebas de
intrusin. Por lo tanto cada una de ellas no son sustituibles la una a la otra,
por el contrario se complementan y aportan a la seguridad desde sus
enfoques.

La norma ISO 27034 es una norma que est en desarrollo (Estar
disponible a finales del 2011), la cual busca crear una gua para el diseo y
programacin de aplicaciones seguras que involucre los controles de
seguridad en el ciclo de desarrollo del software, aspectos incluidos en la
propuesta metodolgica de este proyecto.

En el ciclo de desarrollo del software los desarrolladores no conocen las
vulnerabilidades de las aplicaciones Web, por esto es importante establecer
dentro de la poltica de seguridad las polticas de programacin segura (Si
se programan en varios lenguajes) para que ellos las conozcan y eviten
cometer estos problemas.

Actualmente existen muchas herramientas que ayudan a detectar
vulnerabilidades a travs de pruebas de intrusin o revisiones de cdigo
que son gratuitas y libres, entonces es importante identificarlas para
incluirlas en el proceso de desarrollo del software.

Como las metodologas existentes son complementarias, la propuesta
metodolgica se basa en ellas para tener en cuenta los diferentes enfoques
de seguridad.

75

9. REFERENCIAS BIBLIOGRFICAS

[1] BROCHARD, Johnny, INTERNET INFORMATION SERVICES 6, Servidor Web

[2] SCHNEIDER, Ben. Outsourcing: La herramienta de gestin que revoluciona el
mundo de los negocios, Grupo EDITORIAL NORMA, Pg. 183

[3] AGUILERA, Purificacin. Seguridad Informtica, EDITEX, Pg. 22

[4] LPEZ BROX, Antonio. Promociones en espacios comerciales, EDITORIAL
VERTICE, Pg. 395

[5] SM Stuart. Hackers, Secretos y soluciones para seguridad de redes, Osborne-
McGrawHill, 2001

[6] WORDLINGO, Prueba de concepto [En lnea],
<http://www.worldlingo.com/ma/enwiki/es/Proof_of_concept#In_security>, [Citado
el 31 de Agosto de 2011]

[7] FEDESOFT, Colombia es el cuarto pas ms vulnerable de Amrica Latina en
seguridad informtica [En lnea], <http://www.fedesoft.org/noticiastic/colombia-es-
el-cuarto-pais-mas-vulnerable-de-america-latina-en-seguridad-informatica>,
[Citado el 31 de Agosto de 2011]

[8] Stuart McClure, SM, Hackers, Secretos y soluciones para seguridad de redes,
Osborne-McGrawHill, 2001

[9] UNIVERSIDAD AUTNOMA DEL CARIBE, Test de penetracin como apoyo a
la evaluacin de riesgos en seguridad de la informacin [En lnea],
<http://www.uac.edu.co/images/stories/publicaciones/revistas_cientificas/prospecti
va/volumen-7-no-1/articulo5-v7n1.pdf>, [Citado el 31 de Agosto de 2011]

[10] FEDESOFT, 60% de las empresas no tienen estrategia de seguridad [En
lnea], <http://www.fedesoft.org/noticiastic/60-de-las-empresas-no-tienen-
estrategia-de-seguridad>, [Citado el 31 de Agosto de 2011]

[11] AMRTEGUI T. Diego J., Ciberseguridad y Ciberterrorismo [En lnea],
<http://www.acis.org.co/fileadmin/Revista_119/Informe_Diego_Amortegui.pdf>,

[12] CANO Jeimy J., Ciberseguridad y ciberdefensa: Dos tendencias emergentes
en un contexto global [En lnea],
<http://www.acis.org.co/fileadmin/Revista_119/Editorial.pdf>, [Citado el 02 de
Septiembre de 2011]

76

[13] ASOCIACIN DE INGENIEROS DE SISTEMAS, Seguridad de la informacin
en Latinoamrica, Tendencias 2011 [En lnea],
<http://www.acis.org.co/fileadmin/Revista_119/Informe_Latinoamerica_2011.pdf>,

[14] ASOCIACIN DE INGENIEROS DE SISTEMAS, Seguridad de la informacin
en Latinoamrica, Tendencias 2011 [En lnea],
<http://www.acis.org.co/fileadmin/Revista_119/Informe_Latinoamerica_2011.pdf>,

[15] Lujn Mora Sergio, Programacin en Internet: Clientes Web, Editorial Club
Universitario, Pg. 8

[16] Ingeniera de Requerimientos, Arquitectura de Tres Capas [En lnea],
<http://proy-
pnfi.foroactivo.net/search.forum?search_author=Admin&show_results=posts>,

[17] Universidad de Alicante, Qu es una aplicacin Web [En lnea],
<http://rua.ua.es/dspace/bitstream/10045/4412/5/03c-AplicacionesWeb.pdf>,

[18] Wikispaces, Lenguajes de Programacin [En lnea],
<http://cervantes1bachdyg.wikispaces.com/lenguajes_programacion>, [Citado el 5
de Septiembre de 2011]

[19] CODEBOX, Glosario [En lnea], <http://www.codebox.es/glosario>, [Citado el

[20] PORTAL HACKER, Programacin en General [En lnea],
<http://www.portalhacker.net/index.php/topic,115175.0/wap2.html>, [Citado el 6 de
Septiembre de 2011]

[21] New Web Star, Los diferentes lenguajes de programacin para la web [En
lnea], <http://www.newwebstar.com/ebooks/133193-los-diferentes-lenguajes-de-
programaciun-para-la.html>, [Citado el 6 de Septiembre de 2011]

[22] Ingeniera de Requerimientos, Arquitectura de Software [En lnea],
<http://proy-
pnfi.foroactivo.net/search.forum?search_author=Admin&show_results=posts>,

[23] ALDEGANI, Gustavo. Miguel. Seguridad Informtica. MP EDICIONES.
ARGENTINA. 1997. Pg. 22

77

[24] SOFTTRON NET, Seguridad Informtica [En lnea],
<http://www.softtron.net/002/index.php/seguridad>, [Citado el 7 de Septiembre de
2011]

[25] ASENSIO, Gonzalo. Seguridad en Internet, EDITORIAL NOWTILUS, Pg. 15.

[26] AGUILERA, Purificacin. Seguridad Informtica, EDITORIAL EDITEX, Pg.
11.

[27] ERB, Markus, Gestin de Riesgo en la Seguridad Informtica [En lnea],
<http://protejete.wordpress.com/gestion_rieso/gestion_riesgo_si/ >, [Citado el 7 de
Septiembre de 2011]

[28] AGUILERA, Purificacin. Seguridad Informtica, EDITORIAL EDITEX, Pg.
12-27.

[29] OWASP Foundation, gua para construir aplicaciones y servicios web seguros
[En lnea],
<https://www.owasp.org/images/b/b2/OWASP_Development_Guide_2.0.1_Spanis
h.pdf>, [Citado el 12 de Septiembre de 2011]

[30] HP DVLabs, The 2011 Mid-Year top cyber security risks report [En lnea],
<http://www.hpenterprisesecurity.com/collateral/report/CyberSecurityRisksReport.p
df>, [Citado el 12 de Septiembre de 2011]

[31] OWASP Foundation, Cross-Site Request Forgery (CSRF) [En lnea],
<https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)>, [Citado

[32] The Web Application Security Consortium, Remote File Inclusion [En lnea],
<http://projects.webappsec.org/w/page/13246955/Remote%20File%20Inclusion>,

[33] La bitcora de Gabriel, Instalando OpenVas [En lnea],
<http://labitacoradegabriel.wordpress.com/2010/05/28/instalando-openvas/>,

[34] ClubHACKMag, Nessus [En lnea], <http://chmag.in/article/apr2010/nessus>,

[35] LYON, Gordon, Nmap [En lnea], <http://nmap.org>, [Citado el 14 de
Septiembre de 2011]

[36] INC CIRT, Nikto [En lnea], <http://cirt.net/nikto2>, [Citado el 14 de Septiembre
de 2011]
78

[37] iEntry Network, Nikto Core version 2.01 Released [En lnea],
<http://www.linuxhaxor.net/?p=648>, [Citado el 19 de Septiembre de 2011]

[38] SQLMAP Developers, SQLMAP [En lnea], <http://sqlmap.sourceforge.net/>,

[39] Hack Community, How to hack almost every site with sqlmap [En lnea],
<http://www.hackcommunity.com/Thread-SQL-how-to-hack-almost-every-site-with-
sqlmap>, [Citado el 19 de Septiembre de 2011]

[40] ICESURFER, SQLNINJA [En lnea], <http://sqlninja.sourceforge.net/sqlninja-
howto.html#s1>, [Citado el 19 de Septiembre de 2011]

[41] Selvi Savater, Jose, SQLNINJA [En lnea],
<http://www.pentester.es/2010/12/sql-injection-hasta-la-cocina-ms-sql.html>,

[42] XSSer Workgroup, XSSer [En lnea], <http://xsser.sourceforge.net/>, [Citado

[43] Ethical Hacking-Your Way to the World of IT Security, XSSer- Cross Site
Scripting Penetration Tool [En lnea], <http://www.ehacking.net/2011/02/xsser-
cross-site-scripting-penetration.html>, [Citado el 20 de Septiembre de 2011]

[44] Karim, Iman, FIMAP [En lnea], <http://code.google.com/p/fimap/>, [Citado el

[45] DALLA PIAZZA, Alessio, Fimap: Scanner LFI(Local File Inclusion ) and
RFI(Remote File Inclusion) [En lnea], <http://www.clshack.it/en/fimap-scanner-
lfilocal-file-inclusion-and-rfiremote-file-inclusion.html>, [Citado el 21 de Septiembre
de 2011]

[46] OWASP FOUNDATION, CSRFTESTER [En lnea],
<https://www.owasp.org/index.php/CSRFTester_Usage>, [Citado el 21 de
Septiembre de 2011]

[47] Selvi Savater, Jose, Creando PoC CSRF: CSRFTester 1.0 [En lnea],
<http://www.pentester.es/2010/05/creando-poc-csrf-csrftester-10.html>, [Citado el

[48] Offensive Security, Backtrack [En lnea], <http://www.backtrack-linux.org/>,

79

[49] ISO27000.ES, ISO 27000 [En lnea],
<http://www.iso27000.es/download/doc_iso27000_all.pdf>, [Citado el 3 de Octubre
de 2011]

[50] OWASP FOUNDATION, Metodologa OWASP [En lnea],
<https://www.owasp.org/images/8/80/Gu%C3%ADa_de_pruebas_de_OWASP_ver
_3.0.pdf>, [Citado el 10 de Octubre de 2011]

[51] Open Information System Security Group, Metodologa de Pruebas de
Intrusin ISSAF [En lnea],
<www.oissg.org/wiki/index.php?title=PENETRATION_TESTING_METHODOLOGY
>, [Citado el 15 de Octubre de 2011]

[52] Secretara del Senado, Ley1273 de 2009 [En lnea],
<http://www.secretariasenado.gov.co/senado/basedoc/ley/2009/ley_1273_2009.ht
ml>, [Citado el 3 de Octubre de 2011]

[53] VIEIRA, Marco., ANTUNES, Nuno., MADEIRA, Henrique.
Scanne
Informatics Engineering University of Coimbra, Portugal, 2009.

[54] OWASP Foundation, gua para construir aplicaciones y servicios web seguros
[En lnea],
<https://www.owasp.org/images/b/b2/OWASP_Development_Guide_2.0.1_Spanis
h.pdf>, [Citado el 19 de Octubre de 2011]

[55] SILGADO QUIJANO, Felipe Antonio, Gestin de la inseguridad de las
aplicaciones: Un enfoque prctico [En lnea],
<http://www.acis.org.co/fileadmin/Base_de_Conocimiento/VIII_JornadaSeguridad/
08-GestionInseguridadAplicacionesUnEnfoquePractico.pdf>, [Citado en algunas
partes de la imagen de la propuesta metodolgica el 19 de Octubre de 2011]

Proyecto

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proyecto

Cargado por

Copyright:

Formatos disponibles

PROYECTO

Desarrollo de una Propuesta Metodolgica para Determinar la Seguridad en una

También podría gustarte