Seguridad en Web Services
Ricardo Seguel P. [email protected]
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.