Sistema de Información Gerencial: Trabajo Nº 2

Volver

Seguridad en las Aplicaciones Web

Grupo Nº 1

Nixon Vicent
Alejandro Alfonzo
Alí Evies
Eudyn Castro

Introducción

Cada día nos adaptamos más al uso de nuevas tecnologías, dejando en ocasiones de lado el tema de la seguridad lo que se puede incidir notablemente en la credibilidad y privacidad de los datos de los usuarios de determinadas aplicaciones, como por ejemplo: el correo electrónico, el pago de productos y servicios, entre otros.

Actualmente en la Web existen un sin número de aplicaciones que son o pueden ser vulnerables ante cualquier ataque, para solucionar esto se debe hacer un análisis completo y detallado de todos los factores internos y externos que intervienen en la aplicación Web.

Las vulnerabilidades de las aplicaciones Web se puede agrupar en dos categorías: La primera de ellas hace referencia a aquellas vulnerabilidades que alteran la plataforma (Linux y Windows) y la segunda categoría, contiene las vulnerabilidades que afectan a la propia aplicación y que se muestran por medio de errores de programación que pueden sacar a la luz datos confidenciales, como información de tarjetas de créditos, datos personales del usuario, entre otros.

La Plataforma

Las aplicaciones Web son mucho más que un simple carrito de compras, un sistema de pagos en línea o un buen diseño orientado al usuario. La mayoría de las aplicaciones de comercio electrónico utilizan una arquitectura de tres capas, por lo que cada aplicación Web posee un conjunto de servidores que llevan a cabo diferentes funciones.

Servidor Web: Se encarga de dar respuestas a las solicitudes de un usuario, a través, de un navegador Web. Algunos de los Servidores Web más conocidos son: Apache e IIS.

Servidor de Aplicaciones: Se encarga de la manipulación, interpretación y presentación de los datos al usuario. Por lo general el servidor de aplicación puede formar parte del Servidor Web. Tal es el caso de Apache y PHP o ASP e IIS.

Base de datos: Es el último de arquitectura de tres capas y es el encargado del almacenamiento de los datos que son presentados al usuario por medio de la aplicación Web.

Cada uno de los componentes de esta arquitectura posee un conjunto de vulnerabilidades lo que se representa un gran peligro en la integridad de una aplicación Web.


Gráfico que muestra la infraestructura de tres capas junto con la interacción de un navegador Web. (Extraído de la ayuda de DreamWeaver 8.0 Acceso a una base de datos)

Las tareas que comúnmente se realizan para auditar La Plataforma son las siguientes:

1 – Identificar el Rol del Servidor: Consiste en determinar la función del servidor, los datos manejados y los servidores con lo que tiene o puede tener interacción.

2- Determinar el sistema operativo y su versión.

3 – Determinar los parches aplicados en el Sistema Operativo y la aplicación: Se debe comprobar las últimas actualizaciones o parches que posee el sistema operativo y el servidor Web.

4 - Escaneo de puertos abiertos: Realizar un escaneo de puertos TCP y UDP. Puertos de aplicaciones: 7000, 8000, etc. Puertos de administración: 22, 23, 2301, 3389, 10000, Puertos de Proxy 8080. Puertos de Sistema: 79, 111, etc.

5 – Determinar el tipo de servidor Web, los parches instalados y los componentes o módulos adicionales: Ésta información permitirá localizar vulnerabilidades conocidas, probar funcionalidades y buscar archivos HTML comunes.

6 – Investigar vulnerabilidades conocidas.


La Aplicación

En el análisis de seguridad se debe estudiar el sitio Web describiendo sistemáticamente sus páginas, funciones y parámetros para así identificar problemas comunes como por ejemplo: validaciones incorrectas, problemas con el uso de sesiones, entre otros.

Las tareas que comúnmente se realizan para auditar aplicaciones Web son las siguientes:

1 - Identificar la estructura de directorios y archivos: Consiste en navegar por el sitio e ir tomando nota de todos los archivos y directorios para conocer todos los archivos que intervienen en el sitio Web.

2 – Identificar los mecanismos de autenticación de usuario autorizado: Se refiere determinar cuales son los métodos de autenticación utilizados en la aplicación, además de conocer los mecanismos de cifrado para las claves de usuario, por ejemplo: Base64, MD5, MD4, entre otros.

3 – Puntualizar todos los mecanismos de autorización (Niveles o Roles de Usuarios): Se refiere al ingreso en la aplicación Web con usuarios de diferentes niveles de acceso sobre la información manejada a fin de ver las funciones y elementos que cambian según el nivel del usuario.

4 – Proteger los niveles de autorización: Consiste en verificar los procesos de gestiones de sesiones de usuarios y el control de los niveles de autorización.

5 – Identificar los archivos de complemento (.css, .txt, .inc, .htr): Estos archivos generalmente contienen información sobre la configuración de los navegadores o información sobre la aplicación; por lo que se debe revisar que no contengan comentarios realizados por los programadores. Del mismo también existen archivos que almacenan contraseñas y datos de los usuarios.

6 – Identificar y proteger los archivos de inclusión (include): se debe localizar los directorios que contienen archivos “include” o archivos de inclusión. Generalmente estos archivos contienen variables y constantes de la aplicación, cadenas de conexión a la base de datos y sentencias SQL.

7 – Identificar los formularios utilizados para el envío de data ya que se consideran unos de los elementos más vulnerables de toda aplicación Web, debido a que tienen contacto un directo con el usuario.

8 – Identificar y validar los diferentes métodos de envío de datos (GET, POST): Se refiere a determinar la manera en que los datos viajan desde el formulario hasta la página que los procesa a fin de garantizar que se reciban datos desde el método que se requiera. Es recomendado utilizar el método POST para el tratamiento de valores importantes.

Igualmente se debe hacer uso de la Inyección SQL, Repetición de Sesiones, Validación de datos para detectar posibles errores en los parámetros.

9 – Identificar los posibles ataques a los directorios: consiste en verificar que los usuarios no puedan tener acceso a archivos ubicados fuera o dentro de la carpeta que se define como pública o raíz dentro de la aplicación Web, ejemplo: “html_public/”.

10 – Identificar secciones en la aplicación que permitan subir archivos directamente al servidor. Dentro de las secciones que pueden visualizar los usuarios registrados, por lo general se incluyen formularios que permiten la carga de archivos directamente al servidor los cuales pueden tener un contenido no deseado que pueda alterar la aplicación.

11 – Realización de diferentes pruebas bajo múltiples ambientes a fin provocar posibles errores.

12 – Determinar las páginas que requieren SSL: Se refiere a determinar el tipo de datos manejados por cada página a fin de verificar si se requiere la aplicación o no de certificados de seguridad en las mismas.


En los últimos años la masificación del Internet a nivel mundial, se ha multiplicado, y son numerosos los sistemas de información que se desarrollan en un ambiente Web, ya que con el uso del Internet se eliminan las barreras de las distancias y también de los horarios; es decir, los usuarios pueden utilizarlos en el momento que lo requiera sin importan el tiempo y el lugar.

La Web que ofrece un acceso abierto a un conjunto de información que explícitamente se hace pública. En ese sentido, los especialistas del área tecnológica deben considerar poder limitar el acceso a documentos reservados o útiles para un conjunto restringido de personas. En relación a lo mencionado anteriormente se puede expresar que existen dos tipos de restricciones para esos casos:

  1. Limitación de acceso en función de direcciones IP o dominio. Sólo los usuarios de un dominio u organización tendrán acceso a la información.
  2. Limitación de acceso por nombres de usuario y claves de acceso. Sólo los usuarios que conozcan una clave de acceso válida pueden acceder a la información.

Otro aspecto que está cobrando especial importancia es la seguridad de la información que se intercambia en el Web. La explotación comercial de Internet exige disponer de sistemas de comunicación seguros, capaces de adaptarse a las necesidades de los nuevos servicios, como la compra electrónica ó la banca a distancia.

En estos servicios, se manejan dos conceptos fundamentales, la autentificación (garantizar que tanto el usuario de un cliente Web como un determinado servidor de información son quienes dicen ser) y la confidencialidad (hacer que la información intercambiada no pueda ser interceptada por terceros).

Por otra parte, con los sistemas de comunicación actualmente en uso, es técnicamente posible ‘pinchar' un enlace de comunicaciones e interceptar el contenido de las comunicaciones TCP/IP que por él se transmiten. Es por eso, que cuando se envía información privada, por ejemplo un número de tarjeta de crédito en un formulario de compra, es vital garantizar que la información sea recibida exclusivamente por su destinatario, y que la identidad es la esperada.

Es importante contar con un sistema de seguridad cuando se crea, administra y se usa un sistema en la Web, es necesaria su utilización para la seguridad de todos los usuarios. Sin embargo, hoy por hoy existen organizaciones que descuidan el campo de la seguridad, la cual es vital para asegurar y garantizar la confiabilidad de todos los datos aportados por los usuarios en el sistema.


Para aplicar un control de seguridad en la Web se debe realizar lo siguiente

Control de acceso a la información: Se utiliza para limitar el acceso a determinados documentos de un servidor Web, en función del origen y tipo de petición. La forma de hacerlo varía con el entorno en el que se publican las páginas (sistema operativo y servidor HTTP, principalmente); en general, todas las soluciones pasan por definir un fichero que contiene las diferentes limitaciones de acceso, en un formato característico del servidor HTTP. En algunos casos se utiliza un fichero global con las restricciones de acceso o bien un fichero por cada directorio al que se quiere limitar el acceso.

Cuando un cliente Web accede a un fichero protegido, el servidor devuelve un código de error asociado a la falta de permisos para realizar la operación (código 401). Si el acceso se realiza desde un dominio o dirección IP prohibida, no será posible acceder a la información desde ese sistema. Cuando la protección se basa en nombres y claves de acceso, el browser solicitará estos datos y los enviará al servidor para que sean verificados. Las claves de acceso se envían al servidor por diferentes sistemas, sin codificar (sencillo pero inseguro) o codificadas (DES o Kerberos, por ejemplo). Será el propio servidor HTTP el que informe sobre la manera en que se deben enviar estas claves de acceso.

Es importante mencionar, que el intercambio seguro de información a través de una red abierta e insegura como Internet ha obligado a desarrollar numerosos sistemas de encriptación y autentificación de las transacciones, destinados a cubrir tres problemas fundamentales:

  • Conocer la identidad real de los clientes y servidores que se comunican , de forma que ambos dispongan de algún sistema para verificar la identidad del otro. Este tipo de identificación tiene particular importancia en las cibertiendas, ya que al enviar un número de VISA para realizar un pago se tiene que estar seguro de que el destinatario es quien dice ser.
  • Garantizar que la transferencia de datos sólo pueda ser entendida por las aplicaciones que se comunican, utilizando métodos criptográficos para codificar todos los datos intercambiados, y evitar las ‘escuchas' en la red.
  • Garantizar la integridad de los datos enviados , teniendo capacidad de detectar cualquier cambio, intencionado o no, en los mismos.

En ese sentido, los métodos criptográficos tradicionales operan a partir de una palabra ó frase llave, que sirve para codificar y descodificar los datos intercambiados. Está llave debe ser conocida por los dos extremos de la comunicación, por lo que el punto débil de este método es justamente el proceso de difusión de la llave. Se han ideado diversos sistemas para realizar un intercambio seguro de las llaves, por lo general haciendo que cambien con el tiempo, pero casi todos tienen algún punto débil.

La mayoría de los intercambios seguros de información se realizan según un sistema denominado Criptografía de Clave Pública ; cada extremo de la comunicación dispone de dos claves, una pública que cualquiera puede solicitar y conocer, y otra privada, cuya seguridad es fundamental para el éxito de la codificación . Para enviar un mensaje seguro a una persona, se solicita su clave pública, con la que se codifica el mensaje . El sistema garantiza que el mensaje resultante sólo puede ser descodificado con la clave privada del destinatario.

El siguiente paso es asegurar la correcta identidad del destinatario . Para ello, se han creado las autoridades de certificación, organizaciones o empresas que distribuyen certificados, unos documentos digitales que contienen la identidad y clave pública de una determinada organización. Cuando se establece una conexión segura con un servidor HTTP, es posible acudir a una de estas autoridades de certificación para verificar su identidad. Una de las autoridades de certificación más conocidas es Verisign (www.verisign.com) , una empresa que proporciona diversos tipos de certificados, personales o para empresas, tras un proceso de verificación de la identidad del solicitante (previo pago de una tasa).

Los clientes Web tienen una pequeña base de datos con las claves públicas de diversas autoridades de certificación, a partir de las cuales se pueden verificar las claves públicas de otros servidores. De esta forma, si se codifica un mensaje con la clave pública de un determinado servicio Web, la información enviada sólo podrá ser interpretada por el destinatario del mensaje.

Por otra parte, a partir de la criptografía de clave pública se ha desarrollado SSL (Secure Sockets Layer) , un sistema de codificación de información propuesto por Netscape que codifica toda la información transferida al nivel de conexiones TCP, por lo que es compatible con todos los protocolos y servicios de Internet. SSL está incluido en los clientes Web de Netscape, Microsoft, IBM. El establecimiento de una conexión SSL consta de las siguientes fases:

El cliente y el servidor intercambian sus certificados de autenticidad (el cliente no tiene necesariamente uno). Estos certificados se validan con una autoridad de certificación. Este procedimiento es el llamado ‘sistema de autentificación de RSA'

El cliente genera una clave aleatoria, que envía al servidor tras codificarla con la clave pública de este; el servidor hace un proceso similar. De esta forma, las claves de encriptación sólo pueden ser conocidas por el cliente y el servidor.

Esas llaves se utilizan para encriptar todos los datos intercambiados. El sistema criptográfico empleado en este punto es elegido como el más seguro entre todos los conocidos por el cliente y el servidor (por ejemplo, RC2, RC5, DES o IDEA). Adicionalmente, se puede utilizar un sistema de firma digital de los contenidos, como MD5. El SSL combina criptografía de clave pública, para el intercambio de las claves de cifrado, y criptografía de clave privada, para el intercambio de información. Esto es necesario porque la criptografía de clave pública implica muchos más cálculos que la otra, por lo que no es factible para mantener una conexión cifrada.

Cabe destacar, que la base de cualquier sistema de codificación es el tamaño de la llave empleada para encriptar el contendido de los mensajes . Con SSL, se pueden utilizar varios tamaños de llave desde 40 bits. En la actualidad, las llaves de 40 bits pueden ser desencriptadas en un tiempo razonablemente corto empleando sistemas informáticos de alto rendimiento, cosa mucho más complicada con las llaves de 128 bits o más. Sin embargo, países como Estados Unidos impone restricciones para exportar fuera de su país aplicaciones que utilicen codificación de más de 40 bits. Estas restricciones no se aplican a los sistemas de autentificación de identidad, que pueden utilizar llaves de cualquier longitud.

Otro sistema bastante utilizado es S-HTTP, una versión de HTTP que incorpora criptografía de clave pública para la autentificación y el intercambio seguro de datos. Sin embargo, S-HTTP sólo puede utilizarse para intercambiar datos entre clientes y servidores Web, mientras que SSL actúa de forma transparente para cualquier aplicación de comunicaciones TCP/IP.

Los clientes Web muestran avisos de advertencia cuando la conexión pasa de modo normal a modo seguro y viceversa (el candado o llave abiertos de la esquina inferior izquierda de Netscape Navigator ó Internet Explorer).

Un Certificado Digital, es un documento digital mediante el cual un tercero confiable (una autoridad de certificación) garantiza la vinculación entre la identidad de un sujeto o entidad y su clave pública.

Si bien existen variados formatos para certificados digitales, los más comúnmente empleados se rigen por el estándar UIT-T X.509. El certificado contiene usualmente el nombre de la entidad certificada, un número serial, fecha de expiración, una copia de la clave pública del titular del certificado (utilizada para la verificación de su firma digital), y la firma digital de la autoridad emisora del certificado de forma que el receptor pueda verificar que esta última ha establecido realmente la asociación.


Certificados de Seguridad

Formato de certificado digital

Un certificado emitido por una entidad de certificación autorizada, además de estar firmado digitalmente por ésta, debe contener por lo menos lo siguiente:

•  Nombre, dirección y domicilio del suscriptor.

•  Identificación del suscriptor nombrado en el certificado.

•  El nombre, la dirección y el lugar donde realiza actividades la entidad de certificación.

•  La clave pública del usuario.

•  La metodología para verificar la firma digital del suscriptor impuesta en el mensaje de datos.

•  El número de serie del certificado.

•  Fecha de emisión y expiración del certificado.

Emisores de certificados:

Cualquier individuo ó nstitución puede generar un certificado digital pero si éste emisor no es reconocido por quienes interactuaran con el propietario del certificado, es casi igual a que si no hubiese sido firmado. Por ello los emisores deben acreditarse para así ser reconocidos por otras personas, comunidades, empresas o países y que su firma tenga validez.

La gran mayoría de los emisores tiene fines comerciales, y otros, gracias al sistema de Anillo de confianza pueden otorgar gratuitamente certificados en todo el mundo, como:

•  CAcert.org , emisor administrado por la comunidad con base legal en Australia.

•  Thawte , sólo para certificados personales. Emisor propiedad de Verisign.

Pero para que un certificado digital tenga validez legal, el prestador de Servicios de Certificación debe acreditarse en cada país de acuerdo a la normativa que cada uno defina.

Autoridad de certificación:

En criptografía una Autoridad de certificación, certificadora o certificante ( AC o CA por sus siglas en inglés Certification Authority ) es una entidad de confianza, responsable de emitir y revocar loscertificados digitales o certificados , utilizados en la firma electrónica, para lo cual se emplea la criptografía de clave pública . Jurídicamente es un caso particular de Prestador de Servicios de Certificación.

La Autoridad de Certificación , por sí misma o mediante la intervención de unaAutoridad de Registro , verifica la identidad del solicitante de un certificado antes de su expedición o, en caso de certificados expedidos con la condición de revocados, elimina la revocación de los certificados al comprobar dicha identidad.

Los certificados son documentos que recogen ciertos datos de su titular y su clave pública y están firmados electrónicamente por la Autoridad de Certificación utilizando su clave privada. La Autoridad de Certificación es un tipo particular de Prestador de Servicios de Certificación que legitima ante los terceros que confían en sus certificados la relación entre la identidad de un usuario y su clave pública. La confianza de los usuarios en la CA es importante para el funcionamiento del servicio y justifica la filosofía de su empleo, pero no existe un procedimiento normalizado para demostrar que una CA merece dicha confianza.

Un certificado revocado es un certificado que no es válido aunque se emplee dentro de su período de vigencia. Un certificado revocado tiene la condición de suspendido si su vigencia puede restablecerse en determinadas condiciones.

Solicitud de un certificado:

El mecanismo habitual de solicitud de un certificado de servidor web a una CA consiste en que la entidad solicitante, utilizando ciertas funciones del software de servidor web, completa ciertos datos identificativos (entre los que se incluye el localizador URL del servidor) y genera una pareja de claves pública/privada.

Con esa información el software de servidor compone unfichero que contiene una petición CSR ( Certificate Signing Request) en formato PKCS#10 que contiene la clave pública y que se hace llegar a la CA elegida. Esta, tras verificar por sí o mediante los servicios de una RA (Registration Authority, Autoridad de Registro) la información de identificación aportada y la realización del pago, envía el certificado firmado al solicitante, que lo instala en el servidor web con la misma herramienta con la que generó la petición CSR.

La Jerarquía de Certificación:

Las CA disponen de sus propios certificados públicos, cuyas claves privadas asociadas son empleadas por las CA para firmar los certificados que emiten. Un certificado de CA puede estar auto-firmado cuando no hay ninguna CA de rango superior que lo firme. Este es el caso de los certificados de CA raíz, el elemento inicial de cualquier jerarquía de certificación. Una jerarquía de certificación consiste en una estructura jerárquica de CA s en la que se parte de una CA auto-firmada, y en cada nivel, existe una o más CA s que pueden firmar certificados de entidad final (titular de certificado: servidor web, persona,aplicación desoftware) o bien certificados de otras CA subordinadas plenamente identificadas y cuya Política de Certificación sea compatible con las CA s de rango superior.

Confianza en la CA

Una de las formas por las que se establece la confianza en una CA para un usuario consiste en la "instalación" en el ordenador del usuario (tercero que confía) del certificado autofirmado de la CA raíz de la jerarquía en la que se desea confiar. El proceso de instalación puede hacerse, en sistemas operativos de tipo Windows, haciendo doble click en el fichero que contiene el certificado (con la extensión "crt") e iniciando así el "asistente para la importación de certificados". Por regla general el proceso hay que repetirlo por cada uno de los navegadores que existan en el sistema, tales como Opera (navegador),irefox o Internet Explorer, y en cada caso con sus funciones específicas de importación de certificados.

Si está instalada una CA en el repositorio de CAs de confianza de cada navegador, cualquier certificado firmado por dicha CA se podrá validar, ya que se dispone de la clave pública con la que verificar la firma que lleva el certificado. Cuando el modelo de CA incluye una jerarquía, es preciso establecer explícitamente la confianza en los certificados de todas las cadenas de certificación en las que se confíe. Para ello, se puede localizar sus certificados mediante distintos medios de publicación en internet, pero también es posible que un certificado contenga toda la cadena de certiificación necesaria para ser instalado con confianza.

Misión de las CA

Finalmente, las CA también se encargan de la gestión de los certificados firmados. Esto incluye las tareas de revocación de certificados que puede instar el titular del certificado o cualquier tercero con interés legítimo ante la CA por e-mail, teléfono o intervención presencial. La lista denominada CRL ( Certificate Revocation List) contiene los certificados que entran en esta categoría, por lo que es responsabilidad de la CA publicarla y actualizarla debidamente. Por otra parte, otra tarea que debe realizar una CA es la gestión asociada a la renovación de certificados por caducidad o revocación.

Si la CA emite muchos certificados, corre el riesgo de que sus CRL sean de gran tamaño, lo que hace poco práctica su descarga para los terceros que confían. Por ese motivo desarrollan mecanismos alternativos de consulta de validez de los certificados, como servidores basados en los protocolos OCSP y SCVP .

CA de personas y de servidores :

Los certificados de "entidad final" a veces designan personas (y entonces se habla de "certificados cualificados") y a veces identifican servidores web (y entonces los certificados se emplean dentro del protocolo SSL para que las comunicaciones con el servidor se protejan con un cifrado robusto de 128 bits)

CAs Públicas y Privadas :

Una CA puede ser o bien publica o bien privada. Los certificados de CA (certificados raíz) de las CAs públicas pueden o no estar instalados en los navegadores pero son reconocidos como entidades confiables, frecuentemente en función de la normativa del país en el que operan. Las CAs públicas emiten los certificados para la población en general (aunque a veces están focalizadas hacia algún colectivo en concreto) y además firman CAs de otras organizaciones.

Anteriormente, se explicaron los pasos y los detalles a nivel de seguridad en la Web, a continuación se muestran las mejores empresas dedicadas al ramo de la seguridad:


THAWTE

Thawte Consulting: Es una empresa especializada en certificados de seguridad digitales por Internet. Thawte fue fundada en 1995 por Mark Shuttleworth en Sudáfrica y ahora es una de las mayores empresas en su sector. En el año 1999 VeriSign compró las acciones de Thawte a Shuttleworth por 575 millones de dólares .

Esta empresa ofrece los siguientes servicios:

PARA ¿NECESITA? SABER MÁS ENLACES RÁPIDOS

Comerciantes

Empresas de alojamiento Web

Distribuidores

Registradores de dominios

Empresas

Instituciones educacionales

Socios tecnológicos

Protección de un servidor Web

Administración de múltiples certificados

Protección de su código

Protección de su E-mail

Ofrezca la mayor codificación posible

Sólo thawte protege los Nombres de dominio internacionalizados (IDN)

Cuándo es un sitio Web realmente seguro

Regístrese para recibir nuestro boletín de noticias

Datos sobre los protocolos SSL

Adquisición de certificados SSL

Renovación de certificados SSL

Obtenga un presupuesto

Compruebe el estado de su petición

Adquisición de licencias adicionales

Reemisión de certificados SSL


VeriSign

es una empresa de seguridad informática famosa por ser una autoridad de certificación reconocida mundialmente. La misma emite certificados digitales RSA para su uso en las transmisiones seguras por SSL , principalmente para la protección de sitios en internet en su acceso por https . Asimismo, provee las direcciones internet en .com y .net .

En VeriSign gestionan los sistemas que controlan dominios .com y .net, y procesan 31.000 millones de direcciones Web y correos electrónicos cada día.

Proporcionan soluciones de seguridad de varios niveles que protegen los clientes, la marca, el sitio Web y las redes de cada organización. Así como también ofrecen servicios de seguridad gestionada, consultoría de seguridad, soluciones de autenticación fuerte, servicios contra phishing y servicios de seguridad comercial a organizaciones de todo el mundo. Aseguran más de 750.000 servidores Web de todo el mundo.

VeriSign ofrece soluciones expresamente orientadas a operadores, empresas de productos de consumo y al por menor, entidades de servicios financieros, organizaciones de asistencia médica y biosanitarias, empresas de multimedia y entretenimiento y al sector público.

Estándar de Seguridad

ISO/IEC 17799 (también ISO 27002)

Es un estándar para la seguridad de la información publicado por primera vez como ISO/IEC 17799:2000 por International Organization for Standardization y por la comisión International Electrotechnical Commission en el año 2000 y con el título de Information technology - Security techniques - Code of practice for information security management . Tras un periodo de revisión y actualización de los contenidos del estándar se publicó en el año 2005 el documento actualizado denominado ISO/IEC 17799:2005. El estándar ISO/IEC 17799 tiene su origen en Imagen: La norma británica British Standard BS 7799-1 que fue publicada por primera vez en 1995.

En países como España existe una publicación nacional UNE-ISO/IEC 17799 que fue elaborada por el comité técnico AEN/CTN 71 y titulada Código de buenas prácticas para la Gestión de la Seguridad de la Información que es una copia idéntica y traducida del Inglés de la Norma Internacional ISO/IEC 17799:2000. Por otra parte, en Perú la ISO/IEC 17799:2000 es de uso obligatorio en todas las instituciones públicas desde el año 2004, estandarizando de esta forma los diversos proyectos y metodologías en este campo, respondiendo a la necesidad de seguridad por el uso intensivo de Internet y redes de datos institucionales, la supervisión de su cumplimiento esta a cargo de la Oficina Nacional de Gobierno Electrónico e Informática.

Es importante mencionar que ISO/IEC 17799 proporciona recomendaciones de las mejores prácticas en la gestión de la seguridad de la información a todos los interesados y responsables en iniciar, implantar o mantener sistemas de gestión de la seguridad de la información. La seguridad de la Información se define en el estándar como la preservación de la confidencialidad (asegurando que sólo quienes estén autorizados pueden acceder a la información), integridad (asegurando que la información y sus métodos de proceso son exactos y completos) y disponibilidad (asegurando que los usuarios autorizados tienen acceso a la información y a sus activos asociados cuando lo requieran) .

La versión de 2005 del estándar incluye las siguientes once secciones principales:

  • Política de seguridad
  • Aspectos organizativos para la seguridad
  • Clasificación y control de activos
  • Seguridad ligada al personal
  • Seguridad física y del entorno
  • Gestión de comunicaciones y operaciones
  • Control de accesos
  • Desarrollo y mantenimiento de sistemas
  • Gestión de incidentes de seguridad de la información
  • Gestión de continuidad de negocio
  • Conformidad

Certificación:


Las norma ISO/IEC 17799 es una guía de buenas prácticas y no especifica los requisitos necesarios que puedan permitir el establecimiento de un sistema de certificación adecuado para este documento.
La norma ISO/IEC 27001 (Information technology - Security techniques - Information security management systems - Requirements) sí es certificable y especifica los requisitos necesarios para establecer, implantar, mantener y mejorar un Sistema de Gestión de la Seguridad de la Información según el famoso “Círculo de Deming”: PDCA - acrónimo de Plan, Do, Check, Act (Planificar, Hacer, Verificar, Actuar). Es consistente con las mejores prácticas descritas en ISO/IEC 17799 y tiene su origen en la norma británica British Standard BS 7799-2 publicada por primera vez en 1998 y que se elaboró con el propósito de poder certificar los Sistemas de Gestión de la Seguridad de la Información implantados en las organizaciones y por medio de un proceso formal de auditoria realizado por un tercero.


Conclusiones

Para la realización correcta de un examen de seguridad se debe primero hacer un análisis exhaustivo de la aplicación Web. Este proceso consiste en hacer una recopilación de información sobre La Plataforma en la que se encuentra implementada la aplicación Web y sobre la misma aplicación.

El analizar una aplicación Web desde el punto de vista de la seguridad, no se requiere ser un experto programador, pero si se debe contar con una visión global y un enfoque sistemático que permita entender toda la tecnología que la rodea, a fin de dar soluciones prácticas a problemas que por lo general pueden ser comunes y de los cuales ya tienen una solución bien definida.

Referencias Bibliográficas

Desarrollo Web (2002) Guía para el desarrollo de aplicaciones web seguras. Disponible en: http://www.desarrolloweb.com/articulos/996.php. [Consultado el 05 de Marzo de 2008]

Escudero, Alberto (2006) Seguridad en aplicaciones Web. Disponible en: http://it46.se/downloads/ courses/security/es/07_Web_PHP_Security/es_security_B7A_websecurity_escuderoa.pdf. [Consultado el 02 de Marzo de 2008].

J.F. (2007). Inyección SQL en Aplicaciones Web. Disponible en: http://informatica-practica.net/solocodigo/index.php/2007/09/05/inyeccion-sql-en-aplicaciones-web-i/. [Consultado el 05 de Marzo de 2008].

Microsoft Corporation (s.f.). Procedimientos de seguridad básicos para aplicaciones Web. Disponible en: http://msdn.microsoft.com/library/spa/default.asp?url=/library/SPA/vbcon/html/vbconBestSecurityPracticesForWebApplications.asp . [Consultado el 6 de Marzo 2008].

Shema, Mike (2004). Hackers de Sitios Web. .Editorial McGraw-Hill.

Hosted by www.Geocities.ws

1