Seguridad en Web Services

Ricardo Seguel P. rseguel@neosecure.cl

Mayo de 2005.

Resumen La creciente tendencia de las organizaciones a escala mundial de proveer Web Services para

aumentar su capacidad de interacción con los usuarios y principalmente con otras organizaciones

en un modelo de integración de aplicaciones y servicios (SOA, Service Oriented Architecture), y los

riesgos a la seguridad de la información derivados de esta tendencia son un nuevo desafío para

desarrollar nuevos modelos de evaluación de la seguridad en una organización y la consecuente

mitigación de sus vulnerabilidades. Este informe muestra el escenario actual de las amenazas a la

seguridad de los Web Services y recomienda un modelo y acciones preventivas para disminuir el

riesgo de una organización que desee implementar Web Services, que está desarrollando o ya los

tiene en producción.

Introducción

La definición de Web Service de la W3C

(WWW Consortium) [1] es: “Un Web Service

es un sistema de software interoperable

diseñado para dar apoyo a la interacción

máquina a máquina sobre una red”. Esta

interacción se realiza por medio de mensajes

SOAP (Simple Object Access Protocol)

transportados a través del protocolo HTTP

mediante una serialización XML en conjunto

con otros estándares Web. Un Web Service

es descrito utilizando el estándar WSDL

(Web Service Description Language) y

almacenado en un repositorio UDDI

(Universal Description and Discovery

Interface).

La Figura 1 muestra el esquema de relación

de las tres tecnologías que conforman un

Web Service: SOAP, WSDL y UDDI. Para

que un Web Service funcione como tal, se

necesita la interacción de dos entes, un

consumidor y un proveedor del servicio. El

proveedor pone a disposición un servicio

describiéndolo por medio del estándar WSDL

y almacenando su descripción en un registro

UDDI. El consumidor consulta el registro

UDDI buscando el servicio que desea

obteniendo la descripción WSDL con el cual

puede construir los mensajes SOAP

apropiados enviándolos a través de una

2

conexión HTTP(S)1 para comunicarse con el

servicio.

El estándar WSDL provee múltiples formas

para interactuar con un servicio, por ejemplo,

un mismo servicio podría ser descrito para

estar disponible por medio de mensajes

SOAP enviados a través de HTTP(S) en un

servidor y por medio de mensajes RMI/IIOP

enviados a través de TCP/IP a otro servidor.

Sin perjuicio de lo anterior, en la Figura 1 se

describe el caso en el cual se utilizan

mensajes SOAP enviados por medio de

HTTP(S) ya que representa un modo de

acceso abierto y ubicuo a un servicio a través

de Internet, y es en éste escenario en donde

la seguridad de los Web Services se ve

disminuida.

Figura 1: Relación entre WSDL, UDDI y

SOAP en un Web Service.

Debilidades de los Web Services

La debilidad principal de los Web Services

está dada por el modelo de interacción entre

1 Se utilizará HTTP(S) para abreviar “HTTP

y/o HTTPS”.

el consumidor y el proveedor del servicio. De

la Figura 1 se puede observar lo siguiente:

El proveedor debe describir el servicio

utilizando el estándar WSDL dando los

detalles de cómo comunicarse con él. Esta

descripción da bastante y preciada

información a un consumidor malicioso para

reunir antecedentes fácilmente al consultar el

registro UDDI.

Lo anterior da una ventaja al consumidor

malicioso de Web Services por sobre un

usuario malicioso de Aplicaciones Web ya

que para este último es menos fácil saber

qué tipo de parámetros espera la aplicación y

qué contenido devolverá al navegador

(browser) para ser desplegadas al usuario.

Por otra parte, podemos descubrir otras

debilidades al realizar un paralelo entre las

Aplicaciones Web y Web Services ya que

comparten características similares:

• Los Web Services pertenecen a la capa

de Aplicación del modelo OSI al igual

que las Aplicaciones Web.

Las organizaciones se han preocupado

de mitigar las vulnerabilidades de las

capas inferiores utilizando Firewalls, IDS,

HIDS y Antivirus (Figura 2), pero han

dejado desprotegida la capa donde

residen las aplicaciones con las cuales

realizan transacciones con sus clientes y

usuarios, en particular, los Web Services

son una tecnología que permite

implementar una Arquitectura Orientada

a los Servicios (SOA, Service Oriented

Architecture) con un énfasis en las

transacciones entre empresas (B2B,

3

Business to Business) donde no siempre

es necesaria una relación previa. Esto

representa un atractivo económico

bastante mayor para un usuario

malicioso ya que en las Aplicaciones

Web generalmente se realizan

transacciones con personas (B2C

Business to Consumer y C2C Consumer

to Consumer).

Figura 2: Las Aplicaciones Web y Web

Services han quedado desprotegidas.

• Los Web Services utilizan HTTP(S) para

el envío de mensajes SOAP. Por lo

general para el protocolo HTTP(S) se

utilizan los puertos de conexión

estándares 80 y 443 los cuales son

permitidos en la mayoría de los Firewalls

de Red de la mayoría de las

organizaciones (Figura 3). Estos

Firewalls no poseen la capacidad de

analizar el tráfico HTTP(S) y menos aún

las sentencias XML de los mensajes

SOAP que circulan por este protocolo.

Por otra parte, HTTPS provee seguridad

en la comunicación mientras los

mensajes son transportados, no cuando

los mensajes son emitidos y/o recibidos

por los participantes, además no permite

intermediarios2 y no provee no-

repudiación3.

• Los Web Services son accesibles desde

Internet por cualquier usuario conectado

a la red. Debido a la diversidad de

formas de acceso a Internet que hay en

la actualidad (PDAs, Notebooks,

Teléfono, Wi-Fi, Bluetooth) y a la

ubicuidad que dan a un usuario, el nivel

de exposición de la organización

aumenta y por ende su clasificación de

riesgo. Este riesgo variará entre una

organización y otra ya que una puede

proveer servicios que sólo entreguen

información, mientras que otra puede

proveer servicios que realicen

transacciones críticas para su negocio.

• Los Web Services acceden al back-end

de la organización. El diseño en tres

capas de las Aplicaciones Web (Capa de

presentación, Capa de Control, Capa de

Aplicación) también se aplica a Web

Services ya que éstos son aplicaciones

Web que interactúan máquina a máquina

los cuales pueden acceder al back-end

de la organización (Figura 3).

2 Los mensajes SOAP pueden ser

transportados utilizando intermediarios que pueden inspeccionarlos y agregar o procesar encabezados. 3 No-repudiación, en este contexto, significa

que se puede verificar que el participante de la comunicación no puede negar su acción.

4

Figura 3: Acceso a los Web Services por

medio del protocolo HTTP(S).

• Los Web Services son una aplicación de

software y por lo tanto pueden tener

debilidades en su diseño, en su etapa de

desarrollo y de pruebas. En general, el

diseño y desarrollo de toda aplicación de

software considera un comportamiento

esperado de un usuario y un flujo de

datos de entrada y salida, pero no se

lleva a cabo un adecuado control de

comportamientos inesperados de un

usuario. La interacción de un usuario

con las aplicaciones Web es estática, en

cambio la interacción entre máquinas en

Web Services es dinámica.

Vulnerabilidades y ataques

De acuerdo a las debilidades anteriormente

expuestas aparecen una serie de

vulnerabilidades que afectan a los tres pilares

de la seguridad de la Información:

Confidencialidad, Integridad y Disponibilidad.

Las vulnerabilidades actualmente

reconocidas en Web Services son similares a

las identificadas en las Aplicaciones Web4,

pero con la diferencia que todo el tráfico de

4 OWASP [2] tiene identificadas las diez

vulnerabilidades de seguridad más críticas de las Aplicaciones Web.

datos se realiza utilizando estándares

basados en el lenguaje XML.

Las vulnerabilidades de los Web Services se

pueden clasificar de la siguiente forma:

I. Vulnerabilidades estructurales

II. Vulnerabilidades semánticas

I. Vulnerabilidades estructurales

Las vulnerabilidades estructurales son

aquellas que pueden ser atacadas

interviniendo las líneas de comunicación de

los participantes (consumidor, intermediarios,

servidor) que intercambian mensajes SOAP.

En esta clasificación podemos identificar las

siguientes vulnerabilidades:

1. Interceptación de mensajes.

El envío de mensajes por medio del protocolo

HTTP permite a un atacante interceptar y leer

los mensajes SOAP dando lugar a otros

posibles ataques:

• Alteración de mensajes: La

información del mensaje es alterada

al modificar, remover o reemplazar

información del encabezado o del

cuerpo5 del mensaje.

• Confidencialidad: La información del

mensaje es leída por un agente no

autorizado.

• Mensajes Falsificados: Se

construyen mensajes falsos a partir

5 Un mensaje SOAP consiste en un sobre

(envelope) que contiene cero o más encabezados (headers) y un cuerpo que contiene la carga (payload) o información de la transacción.

5

de la copia de algunos o todos los

mensajes interceptados para iniciar

una nueva comunicación con el

servidor.

• Spoofing6 del servidor: Es una

variación del anterior en el cual se

impersona al servidor.

• Seguridad forzada: Las sentencias

de seguridad de un mensaje son

forzadas para obtener información no

autorizada.

• Repetición de partes de mensajes:

Se envían mensajes con porciones

de otros mensajes para ganar

acceso a información no autorizada o

para causar que el receptor efectúe

alguna acción.

2. Man-in-the-middle

Los mensajes SOAP pueden ser

transportados por intermediarios los cuales

pueden ser comprometidos por un atacante

para engañar al consumidor y al proveedor

enviándoles mensajes impersonando a

ambos, aún cuando se utilice encriptación ya

que el atacante puede ser capaz de obtener

la clave de sesión.

3. Spoofing

Un atacante puede impersonar a uno o varios

participantes confiables (autenticados) de la

comunicación de mensajes SOAP para

obtener información no autorizada o causar

que una de las partes ejecute una acción no

autorizada.

6 Spoofing es utilizar la identidad de otro para

realizar una acción (impersonar).

4. Repetición de mensajes

Los mensajes SOAP son interceptados por

un atacante y luego repetidos hacia el

destino. Este ataque se utiliza para reunir

información confidencial para eventuales

ataques futuros o transacciones fraudulentas.

5. Denegación de Servicio

Un atacante puede interceptar un mensaje,

eventualmente modificar el encabezado y el

cuerpo (rutas y/o sentencias XML) y enviarlo

repetidamente para sobrecargar el servicio

del intermediario o del destino final con lo

cual logra que el servidor o el intermediario

no pueda atender a un consumidor legítimo.

II. Vulnerabilidades semánticas

Las vulnerabilidades semánticas son

aquellas que son atacadas por debilidades

en la codificación y procesamiento de los

mensajes SOAP.

Los Web Services están basados en el

lenguaje XML el cual entrega un alto nivel de

detalle para realizar la descripción del

servicio (utilizando WSDL), su publicación

(en el registro UDDI) y ejecución (por medio

de mensajes SOAP). Este nivel de detalle

conlleva una etapa de procesamiento de las

sentencias con un alto consumo de recursos

computacionales (CPU, Memoria y Red) por

parte de los participantes de la comunicación

(consumidor, intermediarios, proveedor).

Las vulnerabilidades más comunes dentro de

esta clasificación son las siguientes:

6

1. Entradas inválidas

Los parámetros enviados al servidor en un

mensaje SOAP no son debidamente

validados por el Web Service con lo cual un

atacante puede enviar mensajes con código

malicioso tanto en el encabezado como en el

cuerpo del mensaje para ejecutar una acción

no autorizada.

2. Control de acceso débil

El control de acceso para los consumidores

de un servicio no tiene las restricciones

adecuadas para evitar que un atacante

acceda al servicio con permisos de

consumidores válidos para obtener

información y realizar acciones autorizadas.

3. Autenticación y manejo de sesión

débiles

Una política débil de contraseñas del

proveedor de un Web Service puede permitir

que un atacante descubra las contraseñas

por medio de ataques de diccionario y de

fuerza bruta7. Lo anterior también se cumple

para claves de sesión cuya encriptación no

es la mejor debido a debilidades del

algoritmo de encriptación o por el largo de las

claves.

Esta vulnerabilidad permitiría a un atacante

utilizar la identidad de consumidores

autorizados para obtener información o

efectuar alguna acción autorizada por el

servicio.

7 Los ataques de fuerza bruta buscan

descubrir una contraseña mediante la prueba de todas las opciones posibles, en cambio un ataque de diccionario se basa en información que posee el atacante para acotar el dominio de búsqueda.

4. Cross Site Scripting

Esta vulnerabilidad también se conoce como

XML Encapsulation y se basa en un débil

control de los elementos XML de un mensaje

SOAP. El lenguaje XML puede permitir a un

atacante embeber código malicioso dentro de

los elementos de un mensaje SOAP para

ganar acceso no autorizado en el servicio,

obtener información de sesiones de

consumidores que acceden el servicio, o

para engañar a otros consumidores.

5. Buffer Overflows

El diseño y desarrollo de un Web Service

debe considerar el manejo de entradas en los

elementos del código XML con un largo

máximo de caracteres, de lo contrario

permitiría a un atacante enviar mensajes al

servicio con un largo inesperado provocando

que el servicio sea comprometido debido a

una falla o accediendo a información o

procesos de sistema.

6. Injection Flaws

Dado que un atacante puede embeber

código malicioso en los mensajes SOAP, es

posible enviar mensajes con fragmentos de

sentencias SQL utilizando caracteres

especiales u otros comandos de sistema

para obtener información no autorizada del

servicio. El atacante debe tener un

conocimiento previo de cuál es la tecnología

detrás del Web Service para embeber (o

inyectar) las sentencias y comandos

necesarios para efectuar el ataque.

7

7. Manejo inapropiado de errores

Un manejo inapropiado de las condiciones de

error mientras el Web Service está operando

normalmente puede entregar información

valiosa del sistema a un atacante que envía

mensajes inválidos ya que puede utilizarla

para inferir más información para un posterior

ataque que pueda causar la falla del servicio

u obtener más información por medio de

inyección de código. Esta vulnerabilidad va

asociada a un débil diseño, desarrollo y

pruebas del Web Service.

8. Contenido Malicioso

Un Web Service que necesita intercambiar

datos binarios (imágenes, audio, video,

archivos ejecutables) utiliza mensajes SOAP

con archivos adjuntos. Estos archivos deben

ser enviados como parámetro de un

elemento XML del mensaje y para ello se

codifican con Base 64 o MIME. Dada esta

característica, un atacante podría enviar virus

o troyanos para causar alguna falla en el

Web Service y el sistema subyacente.

9. Denegación de servicio

Este tipo de vulnerabilidad es una de las más

difíciles de mitigar debido a que las

organizaciones no están preparadas para la

variedad de amenazas existentes.

Los ataques están asociados principalmente

a un mal manejo de las entradas para un

Web Service y a la débil configuración de los

sistemas. Los ataques más comunes son:

i. Envío de ráfagas de mensajes SOAP

inválidos para que el servidor utilice

toda su capacidad de procesamiento en

condiciones de error y con ello no

pueda atender ningún requerimiento de

los demás consumidores, o incluso

causar la falla del sistema. Este ataque

aprovecha el débil manejo de las

condiciones de error de un Web

Service.

ii. Envío de ráfagas de mensajes SOAP

de gran tamaño provocando que el

servidor quede totalmente ocupado o

fuera de línea para atender a los

consumidores. Este ataque aprovecha

la vulnerabilidad de Buffer Overflow.

iii. Envío de ráfagas de mensajes SOAP

cuyo cuerpo (payload) es

excesivamente grande para que un

servidor los procese quedando fuera de

línea.

iv. External Entity: Los mensajes SOAP

pueden referenciar entidades externas

para entradas XML que son

procesadas (interpretadas) por el

proveedor del servicio. Si una de

estas entidades está comprometida por

un atacante, puede causar que el Web

Service abra archivos arbitrarios y/o

conexiones TCP provocando una

denegación del servicio.

v. Schema Poisoning: Un esquema XML

describe instrucciones pre-procesadas

para la interpretación de un documento

XML. Un atacante podría comprometer

(alterar) un esquema para que en el

momento de la interpretación de los

elementos XML del mensaje SOAP

provoque un alto uso de recursos

computacionales en el servidor. Por

otra parte, el atacante podría alterar el

8

esquema para obtener información y

ejecutar acciones no autorizadas.

vi. Envío de ráfagas de mensajes SOAP

con archivos adjuntos de gran tamaño

para provocar una falla en el servidor

para que no responda a los

requerimientos de otros consumidores.

vii. Envío de mensajes SOAP con archivos

adjuntos de código malicioso (virus,

troyanos, macros) para causar una falla

en el servicio y/o en el sistema del

proveedor.

10. Configuración Insegura

La seguridad de la plataforma sobre la cual

funcionan los Web Services de una

organización es primordial. Un atacante

podría afectar las instalaciones y sistemas de

la organización si no se mantiene un fuerte

control de acceso de las aplicaciones y Web

Services al back-end utilizando un ataque o

una combinación de los ataques antes

enumerados.

Según Gartner Group los Web Services

reabrirán el 70% de los caminos de ataque

cerrados por los Firewalls de red.

Desafíos a la Seguridad de los Web

Services

En la actualidad existen recomendaciones

para abordar la seguridad de los Web

Services a través de marcos de trabajo

definidos por OASIS[3] la cual es una

organización para la estandarización de Web

Services con la cooperación de las empresas

tecnológicas más grandes del mundo.

OASIS define WS-Security (Web Services

Security) para tratar las siguientes

consideraciones:

• Las relaciones de confianza entre las

organizaciones podrían necesitar la

definición de contratos legales y

responsabilidades.

• Los requerimientos a un Web Service

deberían ser autenticados y autorizados

apropiadamente.

• Los mensajes hacia y desde un Web

Service deberían ser protegidos de

accesos y modificación no autorizados.

WS- Security no es un reemplazo de alguna

tecnología de seguridad sino que provee un

modelo unificado que utiliza las tecnologías

existentes y que permite que las aplicaciones

intercambien mensajes SOAP de forma

segura.

WS-Security provee mecanismos extensibles

y flexibles, pero esta extensibilidad puede

afectar la interoperabilidad de las distintas

plataformas tecnológicas.

WS-I (Web Services Interoperability

Organization) [4] es una organización

apoyada por las empresas tecnológicas más

grandes del mundo, y que define cómo se

deberían cumplir los requerimientos de

interoperabilidad al utilizar un conjunto de

tecnologías que aseguran la transmisión de

los mensajes SOAP.

Según la WS-I los desafíos de seguridad en

la transmisión mensajes SOAP son los

siguientes:

9

• Identificación y Autenticación de las

partes.

• Identificación y Autenticación de los

datos de origen.

• Integridad de los datos: Integridad en el

transporte y del mensaje SOAP.

• Confidencialidad de los datos:

Confidencialidad en el transporte y del

mensaje SOAP.

• Unicidad del mensaje SOAP.

Los estándares que permiten abordar estos

desafíos son los siguientes:

• WS-Security (Web Services Security),

provee un marco de trabajo para el

transporte seguro de mensajes SOAP.

• WS-Trust, describe un modelo

conceptual de confianza que permite que

los Web Services interoperen en forma

segura.

• WS-Policy, describe un marco de trabajo

para definir permisos y restricciones de

las políticas de seguridad entre los

participantes de la transmisión de los

mensajes SOAP.

• WS-SecureConversation, define un

marco de trabajo para manejar y

autenticar el intercambio de mensajes

SOAP incluyendo su contexto de

seguridad.

• WS-Federation, define cómo establecer

relaciones de confianza entre dominios

de seguridad.

• WS-Privacy, describe la sintaxis y

semántica para la comunicación privada

de políticas de seguridad para Web

Services e instancias de datos en

mensajes.

• WS-Authorization, describe cómo las

políticas de acceso para un Web Service

son especificadas y gestionadas.

• SAML (Security Assertion Markup

Language), provee un marco de trabajo

para intercambiar información en forma

segura.

• XACML (eXtensible Access Control

Markup Language), es un lenguaje para

escribir políticas de control de acceso.

• XKMS (XML Key Management

Specification), es un mecanismo basado

en XML para la gestión de una

Infraestructura de Clave Pública (PKI).

• XML Encryption, es un mecanismo para

encriptar partes de un documento XML.

• XML Signature, es un mecanismo para

firmar partes de un documento XML.

Prevención y Mitigación

Los Web Services han ampliado el campo de

acción de los usuarios maliciosos para

cometer sus delitos. Una buena política de

seguridad de la información en las

organizaciones es un buen punto de partida

para disminuir el riesgo al cual están

expuestos.

Existe una variedad de amenazas y cada una

de ellas con un alto impacto en la seguridad

de la información de una organización, y es

aún mayor si su modelo de negocios se basa

principalmente en Internet. Es por ello que

es necesario definir nuevos modelos de

10

evaluación del riesgo de la seguridad de la

información para aquellas organizaciones

que están inmersas en una arquitectura

orientada a los servicios (SOA, Service

Oriented Architecture). Estos modelos deben

considerar lo siguiente:

• La política de seguridad de la

Información de la organización y su

aplicabilidad.

• La evaluación de riesgo de la

organización antes de implementar Web

Services.

• Las medidas de mitigación existentes

antes de implementar Web Services.

• Indicadores del riesgo basados en la

interacción con sus clientes y con las

otras organizaciones.

A partir de la evaluación basada en estos

modelos se puede tener claridad para saber

en qué áreas poner mayor énfasis y definir

un camino para iniciar un plan de seguridad

de la información cuyo objetivo final será el

nivel de seguridad deseado por la

organización. Este camino es largo, de

mejora continua, pero flexible y con hitos

específicos a corto y mediano plazo.

Los hitos que se pueden definir a mediano

plazo se refieren a metas específicas para la

seguridad de los Web Services, entre ellos:

• Aumentar la seguridad de la plataforma

tecnológica de la organización.

• Mitigar las vulnerabilidades descubiertas

en los Web Services existentes en

producción y en desarrollo.

• Utilizar las mejores prácticas para las

etapas de diseño, desarrollo y prueba de

los Web Services. Si la organización

utiliza outsourcing de esta área, debe

verificar que quien le presta el servicio

cumpla con estos requisitos. Un modelo

de desarrollo seguro de software es el

definido por SSE-CMM [5].

• Definir controles para la operación y

mantenimiento de los Web Services.

• Definir un plan de recuperación ante

desastres.

• Definir un plan de continuidad del

negocio.

Los hitos definidos a corto plazo son metas

específicas derivadas de la evaluación para

cumplir con las medidas de mediano plazo.

Algunos ejemplos son:

• Mitigar las vulnerabilidades de la red.

• Aumentar los controles de acceso al

back-end.

• Definir controles de autenticación y

autorización para los consumidores de

un servicio.

• Utilizar comunicación segura para el

intercambio de mensajes SOAP.

• Definir un sistema de control de cambios

para el desarrollo de los Web Services.

Dado que este modelo de prevención y

mitigación involucra a toda la organización,

un cambio en sus procesos y en la

mentalidad organizacional, la puesta en

marcha de este plan y el logro de las metas a

corto plazo pueden retrasarse. Sin embargo,

la organización puede tomar medidas

preventivas y de mitigación a priori que

deben estar asesoradas por especialistas de

11

la seguridad de la información con el objetivo

que estas medidas apunten a establecer un

paso previo a la puesta en marcha de un

modelo de prevención y mitigación. Por

ejemplo, una organización puede tomar las

siguientes medidas:

• Utilizar un Firewall para la capa de

Aplicaciones que sea capaz de analizar

el tráfico HTML para las aplicaciones

Web, y XML para los Web Services.

• Validar el uso de los esquemas XML en

los Web Services.

• Monitorear los eventos registrados por el

Firewall de Aplicaciones y obtener

estadísticas para la definición de

métricas que sirvan para establecer

medidas de riesgo.

• Establecer políticas de comunicación

comunes con las organizaciones que

utilicen sus Web Services.

Las medidas anteriores disminuyen el riesgo

al cual está expuesta la organización en un

mediano plazo y de ninguna forma

constituyen medidas suficientes para quedar

protegidos de todas las amenazas existentes

y de las aún no conocidas.

Conclusión

Los Web Services permiten la comunicación

entre plataformas heterogéneas por medio

del protocolo HTTP(S) el cual es permitido

por la mayoría de los Firewalls de red. Por

otra parte, para utilizar Web Services se debe

publicar una descripción completa del

servicio en un registro público. Estas dos

características representan una brecha de

seguridad que puede ser aprovechada por

usuarios maliciosos para cometer ataques a

una organización para obtener información

confidencial para realizar operaciones

fraudulentas, y para degradar el nivel de

servicio.

Para prevenir y mitigar el riesgo de estas

amenazas se recomienda utilizar un modelo

de prevención y mitigación, o tomar medidas

preventivas a priori para implementarlas en

un corto plazo.

La tendencia mundial en el uso de Web

Services es creciente y los desafíos

inherentes a la seguridad de la información

son cada vez mayores. Sin embargo, existen

tecnologías y estándares para abordar estos

desafíos, la dificultad está en llevarlos a la

práctica de la mejor forma.

Referencias

[1] W3C: http://www.w3.org

[2] OWASP: http://www.owasp.org

[3] OASIS: http://www.oasis-open.org

[4] WS-I: http://www.ws-i.org,

[5] SSE-CMM: http://www.sse-cmm.org

12

Sobre el Autor

Ricardo Seguel P. es Ingeniero de Seguridad

del área de Seguridad de Aplicaciones de

Neosecure S.A. Esta área ofrece servicios

de ingeniería y consultoría a aquellas

empresas que quieran evaluar sus

aplicaciones, mitigar sus vulnerabilidades e

implementar las mejores prácticas de

seguridad de la información para sus

Aplicaciones Web y Web Services.

Sobre Neosecure S.A.

Neosecure S.A. es la empresa líder en Chile

en soluciones de seguridad de la

información. Es la primera empresa en Chile

que obtiene la certificación BS 7799-2 que

otorga la BSI (British Standars Institution) y

segunda a en el mundo en certificar su SOC

(Security Operation Center) bajo esta norma.